ساخت زیرساخت ابری قوی و کارآمد AWS با Terraform و GitLab CI/CD.

نویسنده(های): جولیوس نیره نیامبوک

در ابتدا منتشر شد به سمت هوش مصنوعی.

از لحاظ تاریخی، مدیریت زیرساخت ابری شامل پیکربندی دستی روی کنسول‌های وب یا رابط‌های خط فرمان بود. این رویکرد مستعد خطاهای انسانی، ناسازگاری‌ها و حفظ کنترل‌های نسخه بود. پیچیدگی روزافزون محیط‌های ابری و تقاضا برای شیوه‌های مدیریت زیرساخت سریع‌تر، قابل اطمینان‌تر و قابل تکرار، نیاز به راه‌حل کارآمدتر را برجسته می‌کند.
زیرساخت به عنوان کد (IaC) یک تمرین DevOps است که از کد برای تعریف و استقرار زیرساخت استفاده می کند. Terraform توسط HarshiCorp یک ابزار IaC است که به شما امکان می دهد منابع ابری را با استفاده از زبانی به نام HashiCorp Configuration Language تعریف و تهیه کنید.
در این مقاله، منابع را بر روی AWS از طریق Terraform مستقر می‌کنیم و یک خط لوله CI/CD در Gitlab ایجاد می‌کنیم تا فرآیند استقرار را خودکار کند.

بخش اول: مقدمه

در این پروژه، زیرساخت AWS را تعریف می کنیم، کد terraform را می نویسیم که زیرساخت AWS ما را تعریف می کند، زیرساخت خود را ایجاد می کنیم، و ایجاد زیرساخت خود را با استفاده از خطوط لوله GitLab CI/CD خودکار می کنیم تا زمانی که تغییری ایجاد شد، خط لوله دستورات terraform را اجرا کند. ، و زیرساخت را به روز کنید. برای این پروژه به ابزارهای زیر نیاز دارید:

1. حساب AWS و یک حساب کاربری — ارائه دهنده منابع محاسبات ابری ترجیحی که الف ردیف آزاد.
2. AWS CLI – یک رابط خط فرمان برای احراز هویت اعتبار AWS ما.
3. Terraform – ابزار زیرساخت به عنوان کد برای استقرار منابع ابری از طریق کد. می توانید این را دنبال کنید آموزش برای نصب آن
4. حساب GitLab – برای ذخیره کد ما در یک مخزن و ایجاد خط لوله CI/CD ما.
5. هر ویرایشگر کدی را که ترجیح می دهید به عنوان مثال کد VS.

در اینجا لینک به مخزن GitLab که من با موفقیت در خود منعکس شده است GitHub.

GitHub – Jnyambok/Terraform-CI-CD-Pipeline: زیرساخت AWS که از VPC و آمازون تشکیل شده است…

زیرساخت AWS شامل یک نمونه VPC و آمازون EC2 است که از طریق Terraform مستقر شده است. مخزن منعکس شده از…

github.com

بخش دوم: تعریف زیرساخت

الف ابر خصوصی مجازی (VPC) یک بخش خصوصی و جدا شده از ابر AWS است که در آن می توانید منابع را راه اندازی کنید. این شبیه به یک مرکز داده خصوصی در فضای ابری عمومی است که به شما امکان می‌دهد پیکربندی، از جمله زیر شبکه‌ها، جداول مسیریابی و گروه‌های امنیتی را سفارشی کنید.
یک نمونه Elastic Compute Cloud (EC2). یک سرور مجازی در فضای ابری است که ظرفیت محاسباتی بر اساس تقاضا و منابعی مانند CPU، حافظه و ذخیره سازی را فراهم می کند.
الف گروه امنیتی یک پیکربندی فایروال برای سرویس‌های شما است که مشخص می‌کند چه پورت‌هایی روی دستگاه برای ترافیک ورودی باز هستند.

تصور کنید می خواهید یک برنامه در AWS ایجاد کنید. ابتدا یک VPC برای ارائه یک شبکه خصوصی برای برنامه وب خود ایجاد می کنید. سپس، نمونه های EC2 را در VPC برای اجرای برنامه خود راه اندازی می کنید. VPC، از طریق یک گروه امنیتی، پیکربندی های شبکه را برای نمونه های EC2 تعریف می کند تا اطمینان حاصل شود که آنها با یکدیگر و دنیای خارج ارتباط برقرار می کنند. این زیرساخت چیزی است که ما خواهیم ساخت.

یک تصویر ماشین آمازون (AMI) الگویی برای ایجاد نمونه های EC2 است. این شامل نرم افزار و اطلاعات پیکربندی مورد نیاز برای راه اندازی یک نمونه است. به آن به عنوان مجموعه ای از دستورالعمل های از پیش بسته بندی شده برای ساخت یک سرور مجازی فکر کنید.

بخش سوم: تعریف و پیکربندی ساختار Terraform.

پروژه های Terraform معمولاً به شکل زیر ساختار می شوند:

در Terraform، ماژول ها بلوک‌های قابل استفاده مجدد از کد زیرساخت هستند که منابع مرتبط را در یک واحد جمع‌بندی و سازماندهی می‌کنند و پیکربندی‌های شما را مدولارتر می‌کنند. تنظیمات VPC و EC2 ما در پوشه‌های پروژه ما تعریف شده‌اند. اینها ماژول های ما هستند. ما سه فایل اصلی داریم که در ماژول root تعریف شده اند.

1. اصلی tf – این فایل پیکربندی اولیه Terraform است. هنگامی که فایل در یک ماژول است، منابعی را که می‌خواهید تهیه کنید، یعنی ماشین‌های مجازی، پایگاه‌های داده و کانتینرها را تعریف می‌کند. هنگامی که فایل در پوشه ریشه است، به عنوان یک پیام رسان بین ماژول ها برای انتقال اطلاعات حیاتی عمل می کند.
2. ارائه دهنده tf (اختیاری) – این فایل ارائه دهندگان Terraform را برای تعامل با پلتفرم ها یا سرویس های ابری خاص پیکربندی می کند.
3. متغیر tf (اختیاری) – این فایل به شما کمک می کند تا متغیرهای قابل استفاده مجدد را با انواع و مقادیر پیش فرض اختیاری تعریف کنید. اگر زیرساخت ابری بزرگی دارید مفید است.

من این الگوی اولیه را برای این پروژه در GitHub خود ارائه کرده ام. برو جلو و gآن را می کشد این مخزن. برو از طریق پایه Terraform نحو برای درک

بیایید با پیکربندی Virtual Private Cloud خود شروع کنیم. به سمت خود حرکت کنید /vpc/main.tf و این بلوک را بچسبانید.

##We will create 1 vpc , 1 subnet and 1 security group
# A VPC is a private, isolated section of the AWS cloud where you can launch resources
resource "aws_vpc" "myvpc" {
cidr_block = "10.0.0.0/16"
enable_dns_hostnames = true
enable_dns_support = true
tags = {
Name = "myvpc"
}
}
#A subnet is a division of a VPC that defines a range of IP addresses.
resource "aws_subnet" "pb_sn" {
vpc_id = aws_vpc.myvpc.id
cidr_block = "10.0.1.0/24"
map_public_ip_on_launch = true
availability_zone = "eu-north-1a"
tags = {
Name = "pb_sn1"
}
}
#A security group is a virtual firewall that controls inbound and outbound traffic to resources within a VPC.
resource "aws_security_group" "sg" {
vpc_id = aws_vpc.myvpc.id
name = "my_sg"
description = "Public Security"
# Ingress refers to incoming traffic to a resource within the VPC. It specifies which ports and protocols can be accessed from outside the VPC.
#This rule allows inbound SSH traffic (port 22) from any IP addres
ingress {
from_port = 22
to_port = 22
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
#Egress refers to outgoing traffic from a resource within the VPC. It specifies which ports and protocols can be accessed from within the VPC
egress {
from_port = 0
to_port = 0
protocol = "-1" #This specifies that the rule applies to all protocols (TCP, UDP, ICMP, etc.).
cidr_blocks = ["0.0.0.0/0"] #This indicates that the rule applies to all destination IP addresses (the entire internet 
}
}
#In essence, this rule grants the security group complete outbound connectivity, allowing it to communicate with any resource on the internet. This might be useful for certain scenarios, but it's generally considered a security risk as it exposes the resources within the security group to potential threats

ما یک VPC، یک زیرشبکه که طیف وسیعی از آدرس‌های IP را ارائه می‌کند و یک گروه امنیتی را پیکربندی کرده‌ایم. بیایید EC2 خود را پیکربندی کنیم. به سمت خود حرکت کنید /ec2/main.tf و این بلوک را بچسبانید.

#An AMI (Amazon Machine Image) is a template for creating EC2 instances. It contains the software and configuration information required to launch an instance
resource "aws_instance" "server" {
ami = "
instance_type = "m5.large" #free tier limits
subnet_id = ""
security_groups = "" 
tags ={
Name = "myserver"
}
}

شما به یک شناسه AMI نیاز دارید که با شرایط اولیه این زیرساخت مطابقت داشته باشد. من یک AMI خوب برای استفاده از کاتالوگ AMI در AWS پیدا کردم. شناسه AMI (ami — xxxxxxxx) را کپی کنید. آن را روی تگ ami در کد خود قرار دهید.

ما به یک شناسه زیرشبکه و گروه امنیتی از ما نیاز داریم ماژول vpc برای استفاده در ماژول EC2 ما. ما به سمت خودمان خواهیم رفت /vpc/output.tf. و بلوک زیر را بچسبانید.

output "pb_sn" {
value = aws_subnet.pb_sn.id
}
output "sg" {
value = aws_security_group.sg.id
}

این فایل نشان می دهد که متغیرهایی وجود دارد که ما از فایل پیکربندی اصلی VPC خود انتظار داریم و آنها را به ماژول های دیگر منتقل می کنیم. در /ec2/variables.tf، ما متغیرهای مورد انتظار از ماژول های دیگر را تعریف می کنیم. این بلوک را بچسبانید:

variable "sg"{
}
variable "sn" {
}

را اصلی tf در پوشه ریشه ما جایی است که اطلاعات مهم را بین دو ماژول ارسال می کنیم. متغیرهایی را که ایجاد کرده ایم در ما پاس می کنیم /vpc/output.tf و آنها را به متغیرهای موجود اختصاص دهید /ec2/variables.tf. به پوشه ریشه خود بروید اصلی tf و چسباندن:

#This is the route module where will be passing all of the modules
module "vpc" {
source = "./vpc"
}
module "ec2" {
source = "./ec2"
sn = module.vpc.pb_sn
sg = module.vpc.sg
}

مدیریت دولتی هنگام کار با Infrastructure به عنوان کد حیاتی است. مدیریت حالت از نوشتن همزمان فایل حالت جلوگیری می کند و از یکپارچگی، همگام سازی، عملکرد و سازگاری داده ها اطمینان می دهد. حالت Terraform یک فایل JSON است که پیکربندی زیرساخت شما را ضبط می‌کند و Terraform را قادر می‌سازد تغییرات را ردیابی کند و ثبات را حفظ کند. معمولا، terraform درخواست قفل می‌کند، قفل‌های موجود را بررسی می‌کند و در صورت عدم وجود قفل، تغییرات را اعمال می‌کند. ما این کار را در فایلی به نام the انجام می دهیم باطن tf.

تصور کنید که در تیمی از توسعه دهندگان روی زیرساخت مشابه کار می کنید. به طور طبیعی، دسترسی اشتراکی در مورد این قفل‌ها توسط تیم برای نسخه‌سازی و پشتیبان‌گیری در صورتی که وضعیتی پیکربندی نشده باشد و نیاز به بازگشت مجدد باشد، بسیار مهم است. ما می توانیم این کار را با یک سطل AWS S3 که به عنوان محل ذخیره سازی فایل حالت Terraform شما عمل می کند (زمینی tfstate)، که متادیتا در مورد منابع زیرساخت شما و دینامو دی بی، که مکانیزم قفل را برای جلوگیری از تغییرات همزمان فراهم می کند.

به صفحه اصلی AWS خود بروید و جستجو کنید s3. مطابق شکل زیر یک سطل S3 ایجاد کنید.

یک پوشه در سطل s3 ایجاد کنید و نامی به آن بدهید که مانند ما عمل کند دولت در ما ./backend.tf فایل

به صفحه اصلی AWS خود بروید و جستجو کنید DynamoDB. مطابق شکل زیر جدولی با تنظیمات پیش فرض ایجاد کنید. اشتباهی که من مرتکب شدم هنگام نامگذاری کلید پارتیشن بود. مگر اینکه به صورت دستی پیکربندی شود، کلید پارتیشن به صورت پیش‌فرض تنظیم شده است.LockID”. کلید پارتیشن خود را نامگذاری کنیدLockID” و آن را ذخیره کنید.

در ریشه ما، یک را ایجاد کنید backend.tf بلوک زیر را فایل و پیست کنید:

terraform {
backend "s3" {
bucket = "mystatebucket99" #your S3 bucket's name
key = "state" #the folder you created in your S3
region = "eu-north-1" #your aws region
dynamodb_table = "mydynamotable" #your dynamo DB table name
}
}

برای نوشتن در منابع تازه ایجاد شده خود به مجوزهای لازم نیاز داریم. به سمت خود حرکت کنید IAM و مجوزهای زیر مطابق شکل زیر:
– AmazonEC2FullAccess
– AmazonDynamoDBFullAccess
– AmazonS3FullAccess

پس از تنظیم، پروژه شما به شکل زیر خواهد بود:

بخش چهارم: مقداردهی اولیه پروژه

ما باید از طریق CLI به حساب AWS خود متصل شویم. به نمایه کاربری خود بروید و از خود یادداشت کنید دسترسی به اعتبار. به CLI خود بروید و اعتبار مورد نیاز را وارد کنید:

aws configure - you will be prompted to enter your credentials

دستورات terraform زیر همان چیزی است که ما در خط لوله خود برای پیکربندی استفاده خواهیم کرد:

1. شروع زمین – مقداردهی اولیه، نصب ماژول فرزند و نصب پلاگین را انجام می دهد.
2. اعتبار سنجی زمینی – فایل های پیکربندی موجود در فهرست شما را تأیید می کند و به هیچ سرویس راه دور دسترسی ندارد.
3. پلان زمینی – نشان می دهد که بدون انجام واقعی اقدامات برنامه ریزی شده چه اقداماتی انجام خواهد شد.
4. terraform application -auto-approve – بسته به فایل های پیکربندی زیرساخت ایجاد یا به روز کنید. اضافه کردن تایید خودکار تغییرات را بدون نیاز به تایپ “بله” در طرح اعمال می کند
5. نابود کردن زمین – زیرساخت ها را نابود کند.

قسمت پنجم: ایجاد و استقرار خط لوله CI/CD

ما یک خط لوله CI/CD در GitLab برای اتوماسیون ایجاد خواهیم کرد. یک مخزن GitLab ایجاد کنید (آن را عمومی کنید) و پیوند را در مخزن کپی کنید. یک .gitignore اضافه کنید و اینها را کپی کنید مطالب به آن به CLI خود بروید و کد خود را به مخزن خود فشار دهید.

git remote add origin your-repository-link>
git remote -v -- used to view the configured remote repositories for your Git project
git checkout -b mlops -- creating a branch
git commit -m " Initial commit"
git push -u origin mlops

همیشه تمرین خوبی است که کد خود را به یک شعبه فشار دهید و بعداً ادغام کنید.

ما باید دو متغیر در GitLab از AWS ایجاد کنیم: یک کلید دسترسی و یک کلید دسترسی مخفی. به IAM خود -> کاربران -> کاربر ایجاد شده -> اعتبارنامه امنیتی -> کلیدهای دسترسی بروید. برای تولید کلید دسترسی ادامه دهید.

به صفحه اصلی GitLab خود بروید و کلیدهایی را که ایجاد کرده اید مانند شکل زیر ذخیره کنید. MY_AWS_KEY کلید دسترسی است در حالی که MY_AWS_ACCESS_KEY کلید دسترسی مخفی است.

به مخزن GitLab خود بروید. یک فایل جدید بسازید و نام آن را بگذارید .gitlab-ci.yml. این فایل خط لوله شما را در مورد اقدامات لازم برای برداشتن راهنمایی می کند.

پس از ایجاد، این بلوک کد را کپی کنید:

image:
name: registry.gitlab.com/gitlab-org/gitlab-build-images:terraform
entrypoint:
- '/usr/bin/env'
- 'PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
#This code tells the GitLab CI/CD pipeline to use a Docker image containing 
#Terraform and sets up the environment for the execution of Terraform commands
#within the container. This allows you to run your Terraform scripts without
#needing to install Terraform directly on the GitLab Runner machine
variables:
AWS_ACCESS_KEY_ID: ${MY_AWS_KEY}
AWS_SECRET_ACCESS_KEY : ${MY_AWS_ACCESS_KEY}
AWS_DEFAULT_REGION: "eu-north-1"
#initializes your variables
before_script:
- terraform --version
- terraform init
#instructs the steps to take before the pipeline begins running
#i.e checking the version and backend initialization
stages:
- validate
- plan
- apply
- destroy
validate:
stage: validate
script:
- terraform validate
plan:
stage: plan
script:
- terraform plan -out="planfile"
dependencies:
- validate
artifacts:
paths:
- planfile
#creates a planfile and stores it in artifacts
apply:
stage: apply
script:
- terraform apply -input=false "planfile"
dependencies:
- plan
when: manual
#the "when" only makes this stage possible after manual intervention
destroy: 
stage: destroy
script:
- terraform destroy --auto-approve
when: manual

فایل خود را ذخیره کنید و تغییرات خود را انجام دهید. از شما خواسته می شود خط لوله را راه اندازی کنید. آن را راه اندازی کنید و voila! جادو آغاز می شود.

پس از تکمیل، به صفحه اصلی AWS خود بروید و خواهید دید که زیرساخت شما ایجاد شده است.

ما با موفقیت یک زیرساخت ابری AWS قوی و کارآمد با Terraform و GitLab CI/CD ساخته‌ایم.

ممنون که مقاله من را خواندید.

منتشر شده از طریق به سمت هوش مصنوعی