استفاده از Flux برای پیاده سازی GitOps در AWS

  • 17 بازدید
هادی بهادری
  • 20 فروردین 1403

مقدمه

در حالی که بسیاری از شرکت‌های سازمانی Kubernetes را در تولید خود پذیرفته‌اند، اغلب در مورد چگونگی دستیابی به استقرار مداوم، امنیت بالا، جداسازی مجوزها و ممیزی سردرگم هستند – همه اینها در حالی که از چابکی تجاری با چندین خوشه Kubernetes که در مراحل مختلف به طور همزمان اجرا می‌شوند، اطمینان دارند. استفاده از GitOps می‌تواند چنین استقرار مداومی را بر اساس خوشه‌های Kubernetes فعال کند، در حالی که الزامات سطح سازمانی مانند امنیت و جداسازی مجوزها را برآورده می‌کند.

در این وبلاگ، GitOps را در محیط EKS آمازون با استفاده از AWS CodeCommit، AWS CodePipeline و Flux پیاده سازی خواهیم کرد. نحوه راه‌اندازی یک گردش کاری GitOps که الزامات تولید را در این محیط EKS آمازون برآورده می‌کند را به تفصیل نشان خواهیم داد و نشان خواهیم داد که چگونه برنامه‌های میکروسرویس به یکپارچگی مداوم و تحویل مداوم در خط لوله CI/CD به سبک GitOps می‌رسند.

پیش نیازها
  • تجربه AWS
  • حساب AWS

GitOps چیست؟

GitOps راهی برای پیاده سازی مستمر برای برنامه های کاربردی ابری است. با استفاده از ابزارهایی که توسعه‌دهندگان از قبل با آن‌ها آشنا هستند – از جمله ابزارهای Git و Continuous Deployment، در هنگام بهره‌برداری از زیرساخت‌ها، روی یک تجربه توسعه‌دهنده محور تمرکز می‌کند.

ایده اصلی GitOps داشتن یک مخزن Git است که همیشه حاوی توضیحاتی توضیحی از زیرساخت مورد نظر در محیط تولید و یک فرآیند خودکار برای مطابقت دادن محیط تولید با وضعیت توصیف شده در مخزن باشد. اگر می خواهید یک برنامه جدید را مستقر کنید یا یک برنامه موجود را به روز کنید، فقط باید مخزن را به روز کنید. فرآیند خودکار همه چیز را کنترل می کند. این مانند داشتن کروز کنترل برای مدیریت برنامه های خود در تولید است.

چرا از GitOps استفاده کنیم؟

Git تنها منبع واقعی وضعیت مورد نیاز برای سیستم است. از استقرار تکرارپذیر و خودکار، مدیریت خوشه و نظارت پشتیبانی می کند. توسعه‌دهندگان از جریان‌های کاری Git که به خوبی در سازمان تثبیت شده‌اند، برای ساخت، آزمایش، اسکن و سایر مراحل یکپارچه‌سازی مداوم مجدداً استفاده می‌کنند. هنگامی که آخرین وضعیت سیستم در شعبه مخزن اصلی Git اعلام شد، از زنجیره ابزار GitOps برای تأیید استقرار، مشاهده هشدارها و تعمیر عملیات استفاده می شود. بر اساس اصول بنیادی اصلی GitOps، ما معتقدیم که GitOps بهترین راه برای استقرار مستمر خوشه‌های Kubernetes است. فرآیند به صورت زیر است:


بهترین روش های مبتنی بر آمازون EKS برای GitOps

خط لوله کلی CI/CD، با توجه به بهترین شیوه ها، در شکل زیر نشان داده شده است.


سه مخزن کد تحت مخزن AWS CodeCommit وجود دارد. یکی flux-repo است، مخزن پیکربندی برای Flux CD، که برای تعریف منابع مرتبط با Flux استفاده می شود. مورد دیگر microservices-repo است که پیکربندی‌های اپلیکیشن میکروسرویس و فایل‌های استقرار را ذخیره می‌کند. سومین منبع برنامه مخزن منبع برای خدمات تجاری است. در این پست از یک پروژه فرانت اند به عنوان نمونه استفاده می شود. ما از AWS CodePipeline برای ادغام مداوم در خط لوله CI/CD استفاده کردیم، تصویر داکر را در Amazon ECR ذخیره و ذخیره کردیم، و موتور سی دی Flux را به عنوان یک pod در محیط EKS آمازون مستقر کردیم.

گردش کار اصلی این است:
  • مهندسان کد نویسی کد می نویسند و کد نهایی را به app-repo فشار می دهند.
  • تغییرات کد در app-repo ماشه AWS CodePipeline.
  • AWS CodePipeline کد را ویرایش و بسته بندی می کند، تصاویر کانتینر را تولید می کند و آنها را به مخزن تصویر کانتینر/Amazon ECR فشار می دهد.
  • موتور سی دی Flux که در محیط EKS کار می کند، به طور منظم مخزن تصویر ظرف ECR را اسکن می کند و ابرداده تصویر ظرف را برای برنامه ها می کشد.
  • آدرس تصویر کانتینر جدید به طور خودکار با فایل استقرار برنامه ذخیره شده در microservices-repo از طریق git commit/push همگام‌سازی می‌شود که نسخه جدیدی از تصویر کانتینر شناسایی شود.
  • Flux به طور منظم پیکربندی های برنامه و فایل های استقرار را از Flux-repo می کشد. از آنجایی که مخزن Flux-repo به microservices-repo ارجاع می دهد، Flux سازگاری وضعیت اجرای بار کاری خوشه را با انتظاراتی که در فایل های microservices-repo شرح داده شده است، بررسی می کند. اگر تفاوتی وجود داشته باشد، Flux به طور خودکار کلاستر EKS را قادر می‌سازد تا تفاوت‌ها را همگام‌سازی کند تا اطمینان حاصل شود که بارهای کاری در حالت مورد انتظار اجرا می‌شوند.

از آنجایی که مفهوم GitOps و معماری خط لوله CI/CD را توضیح داده ایم، از یک مورد برای تکمیل این عمل با مرور چهار ماژول زیر استفاده خواهیم کرد:

  • استقرار زیرساخت ابری با استفاده از Infrastructure as Code (IaC)
  • Flux CD را روی خوشه AWS EKS مستقر کنید
  • گردش کار GitOps را با استفاده از Flux CD اجرا کنید
  • پیاده سازی خودکار بر اساس تصاویر با استفاده از گردش کار GitOps

1-استقرار زیرساخت ابری با IaC

یکی از اصول اساسی DevOps این است که زیرساخت با کد دارای وضعیت برابر است. زیرساخت به عنوان کد (IaC) از کد برای فعال کردن استقرار زیرساخت ابری و مدیریت محیط ابری استفاده می کند. مهندسان کدنویسی از فایل‌های پیکربندی یا کد برای تعریف زیرساخت و ایجاد آن با کدگذاری استفاده می‌کنند تا از سازگاری و تکرارپذیری اطمینان حاصل کنند. با IaC، مهندسان کدنویسی همچنین چرخه حیات منابع را مدیریت می‌کنند، مانند تعاریف زیرساخت میزبانی در مخازن کنترل نسخه، و استفاده از یکپارچه‌سازی/استقرار مداوم (CI/CD) که با برنامه‌نویسی برای تغییر تعریف IaC، هماهنگ‌سازی محیط‌ها سازگار است. (به عنوان مثال، توسعه، آزمایش، تولید) با تغییرات کدهای IaC. علاوه بر این، برگشت خودکار در صورت خرابی امکان پذیر است و تشخیص دریفت به شناسایی تفاوت ها از حالت مورد انتظار کمک می کند.

در فضای ابری، مهندسان برنامه نویسی می توانند از کیت توسعه ابری AWS (CDK) برای ساخت مدل زیرساخت خود با پایتون، جاوا و تایپ اسکریپت استفاده کنند. CDK مؤلفه‌های پیشرفته‌ای به نام Constructs ارائه می‌کند که منابع ابری را با مقادیر پیش‌فرض معتبر از قبل پیکربندی می‌کنند. همچنین به مهندسان این امکان را می دهد که ساختارهای سفارشی خود را مطابق با نیازهای سازمان خود بنویسند و به اشتراک بگذارند. همه اینها به پروژه ها سرعت می بخشد.

1.1 یک پروژه با CDK CLI ایجاد کنید

یک پروژه CDK TypeScript با cdk init ایجاد کنید، که ساختار پوشه را ایجاد می کند و ماژول های مورد نیاز پروژه TypeScript CDK را نصب می کند.

cdk init --language typescript

1.2 با EKS Blueprints یک خوشه EKS ایجاد کنید

EKS Blueprints به شما کمک می‌کند تا خوشه‌های کامل EKS را بسازید که به طور کامل با نرم‌افزار عملیاتی مورد نیاز برای استقرار و اجرای بارهای کاری بوت استرپ شده‌اند. با EKS Blueprints، پیکربندی را برای وضعیت مطلوب محیط EKS خود، مانند صفحه کنترل، گره‌های کارگر و افزودنی‌های Kubernetes، به عنوان یک طرح IaC توصیف می‌کنید. پس از پیکربندی یک طرح اولیه، می‌توانید از آن برای حذف محیط‌های سازگار در چندین حساب AWS و منطقه با استفاده از اتوماسیون مستمر استفاده کنید.

می‌توانید از EKS Blueprints برای راه‌اندازی آسان یک خوشه EKS با افزونه‌های Amazon EKS و همچنین طیف گسترده‌ای از افزونه‌های منبع باز محبوب، از جمله Prometheus، Karpenter، Nginx، Traefik، AWS Load Balancer Controller، Fluent Bit، Keda استفاده کنید. ، ArgoCD و موارد دیگر. EKS Blueprints همچنین به شما کمک می‌کند تا کنترل‌های امنیتی مرتبط مورد نیاز برای اجرای بارهای کاری از چندین تیم در یک کلاستر را پیاده‌سازی کنید.

دایرکتوری Quickstart را ایجاد کنید و سپس کدهای زیر را برای نصب وابستگی های پروژه اجرا کنید.

mkdir quickstart
cd quickstart
npm install @aws-quickstart/eks-blueprints

lib/quickstart-stack.ts را باز کنید و کد EKS Blueprints زیر را اضافه کنید.

import * as cdk from 'aws-cdk-lib';
import { Construct } from 'constructs';
import * as blueprints from '@aws-quickstart/eks-blueprints';
import { KubernetesVersion } from 'aws-cdk-lib/aws-eks';
export class QuickstartStack extends cdk.Stack {
constructor(scope: Construct, id: string, props?: cdk.StackProps) {
super(scope, id, props);
const account = props?.env?.account!;
const region = props?.env?.region!;
const clusterProvider = new blueprints.GenericClusterProvider({
version: KubernetesVersion.V1_23,
managedNodeGroups: [
{
id: "default-ng",
desiredSize: 2,
minSize: 1,
maxSize: 2,
}
]
});
const cluster = blueprints.EksBlueprint.builder()
.clusterProvider(clusterProvider)
.account(account)
.region(region)
.addOns(
new blueprints.AwsLoadBalancerControllerAddOn,
)
.teams();
}
}

در مرحله قبل، یک خوشه EKS ایجاد کردیم، NodeGroup آن را تعریف کردیم و افزونه AwsLoadBalancerController را اضافه کردیم.


در حالی که استقرار یک پشته با ابزار خط فرمان CDK راحت است، توصیه می کنیم یک خط لوله خودکار برای استقرار و به روز رسانی زیرساخت EKS راه اندازی کنید. این امر استقرار توسعه، آزمایش و تولید را در سراسر مناطق آسان تر می کند.

CodePipelineStack ساختاری برای تحویل مداوم برنامه های AWS CDK است. هنگامی که کد منبع یک برنامه AWS CDK در Git آپلود می شود، پشته به طور خودکار نسخه های جدید را می سازد، آزمایش می کند و اجرا می کند. اگر هر مرحله یا پشته برنامه اضافه شود، به طور خودکار خود را برای استقرار این مراحل یا پشته های جدید پیکربندی مجدد می کند.

سپس، دستور cdk deploy را برای استقرار پشته اجرا می کنیم.

در نهایت، از دستوری استفاده کردیم تا تأیید کنیم که متعادل کننده بار برنامه با موفقیت نصب شده است.

$ kubectl get pod -n kube-system
NAME READY STATUS RESTARTS AGE
aws-load-balancer-controller-6bd49cfb7-2cvlk 1/1 Running 0 5m31s
aws-load-balancer-controller-6bd49cfb7-7lcwd 1/1 Running 0 5m31s
aws-node-9hsvz 1/1 Running 0 99m
coredns-66cb55d4f4-gdcqg 1/1 Running 0 106m
coredns-66cb55d4f4-gmzjt 1/1 Running 0 106m
kube-proxy-wr5jn 1/1 Running 0 99m

1.3 خلاصه

در این بخش، مفهوم IaC را معرفی کردیم، هنگام نصب افزونه AWS Application Load Balancer، یک خوشه EKS سفارشی با CDK ایجاد کردیم. پیش نیازی برای دسترسی به صفحات وب میکروسرویس ها در آینده فراهم می کند. در زیر خلاصه ای از این بخش آمده است:

  • یک پروژه CDK را با استفاده از cdk init راه اندازی کرد.
  • با اضافه کردن پلاگین AWS Application Load Balancer، یک خوشه EKS را به سرعت با EKS Blueprint تعریف کرد.

2. Fluxcd را در آمازون EKS Cluster مستقر کنید

Flux CD یک ابزار تحویل مداوم است که توسط Weaveworks توسعه یافته و منبع باز برای CNCF است. امروزه به دلیل راه اندازی آسان و توانایی آن در درک تغییرات Kubernetes به طور گسترده مورد استفاده قرار می گیرد. یکی از ویژگی‌های مهم این است که به تیم‌ها اجازه می‌دهد تا استقرار Kubernetes خود را به روشی اعلامی مدیریت کنند. Flux CD فایل های مانیفست Kubernetes ذخیره شده در مخزن منبع را با خوشه Kubernetes با نظرسنجی منظم مخزن همگام می کند. Flux CD تضمین می کند که خوشه Kubernetes همیشه با پیکربندی تعریف شده در مخزن منبع هماهنگ است، بدون اینکه نگران وضعیت عملیاتی kube ctl یا نظارت بر حجم کاری با ابزارها و خدمات اضافی باشید. پس بیایید Flux را نصب کنیم.

2.1 نصب Flux CLI

Flux CLI یک فایل اجرایی باینری برای همه پلتفرم‌ها است که می‌توانید آن را از صفحه انتشار GitHub دانلود کنید.

curl -s https://fluxcd.io/install.sh | sudo bash

2.2 اعتبارنامه AWS CodeCommit را آماده کنید

ما باید یک کاربر ایجاد کنیم و از CodeCommit به عنوان منبع Git و همچنین دسترسی مورد نیاز AWS CodeCommit توسط اعتبار HTTPS Git استفاده کنیم.

2.3 Flux را روی Cluster نصب کنید

کدهای GitOps آماده شده را کلون کنید. ساختار پروژه به شرح زیر است:

.
├── apps // Define Application
│ ├── base // Application Infrastructure Layer
│ └── overlays // Application Overlays Layer
├── clusters // Cluster configuration portal
│ └── dev-cluster
├── infrastructure // Infrastructure Shared Components
│ ├── base // Infrastructure Infrastructure layer
│ └── overlays // Infrastructure Overlays layer
└── README.md

Flux را روی خوشه Kubernetes نصب کنید و آن را پیکربندی کنید تا از مخزن Git با بوت استرپ flux مدیریت کند. اگر اجزای Flux در کلاستر وجود داشته باشد، دستور bootstrapping در صورت نیاز ارتقاء را انجام می دهد. بوت استرپر بی قدرت است و فرمان را می توان با خیال راحت چند بار اجرا کرد. نام کاربری و رمز عبور را در دستور زیر با اعتبار HTTPS Git برای AWS CodeCommit جایگزین کنید.

flux bootstrap git \ 
--url=https://git-codecommit.us-west-2.amazonaws.com/v1/repos/gitops \ 
--username=__replace_with_your_Git_credential_username__ \ 
--password=__replace_with_your_Git_credential_password__ \ 
--token-auth=true \ 
--path="./clusters/dev-cluster" \ 
--components-extra=image-reflector-controller,image-automation-controller

از git pull برای بررسی به‌روزرسانی‌هایی که بوت استرپر انجام می‌دهند استفاده کنید. سه فایل جدید در دایرکتوری clusters/dev-cluster/flux-system مخزن Git ظاهر می شود:

  • gotk-components.yaml: شش کنترلر Flux را تعریف کرد: helm، Kustomize، منبع، اعلان، اتوماسیون تصویر، و بازتاب دهنده تصویر.
  • gotk-sync.yaml: منبع Git Flux، Source Controller در کد مانیتورینگ کلاستر در مخزن GitOps تغییر می کند و تغییرات مربوطه را انجام می دهد.
  • kustomization.yaml: پیکربندی چند خوشه ای.

بررسی کنید که آیا Flux با موفقیت نصب شده است با flux get kustomizations –watch. خروجی شبیه به:

$ flux get kustomizations --watch
NAME REVISION SUSPENDED READY MESSAGE 
flux-system master/83b7e66 False True Applied revision: master/83b7e66
infrastructure master/83b7e66 False True Applied revision: master/83b7e66

اجزای مستقر شده توسط flux-system را با kubectl -n flux-system get pod,services بررسی کنید. خروجی به صورت زیر خواهد بود:

$ kubectl -n flux-system get pod,services
NAME READY STATUS RESTARTS AGE
pod/helm-controller-88f6889c6-sblvd 1/1 Running 0 11m
pod/image-automation-controller-6c5f7bbbd9-8xskk 1/1 Running 0 11m
pod/image-reflector-controller-78949bb4b4-bqn4m 1/1 Running 0 11m
pod/kustomize-controller-784bd54978-s82dq 1/1 Running 0 11m
pod/notification-controller-648bbb9db7-627zs 1/1 Running 0 11m
pod/source-controller-79f7866bc7-gdt95 1/1 Running 0 11m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/notification-controller ClusterIP 172.20.60.72 <none> 80/TCP 11m
service/source-controller ClusterIP 172.20.133.44 <none> 80/TCP 11m
service/webhook-receiver ClusterIP 172.20.196.178 <none> 80/TCP 11m

2.4 خلاصه

در این قسمت از دستور flux bootstrap برای نصب Flux در خوشه Kubernetes استفاده کردیم و سه فایل پیکربندی مهم را معرفی کردیم: gotk-components.yaml، gotk-sync.yaml و kustomization.yaml. در زیر خلاصه ای از این بخش آمده است:

  • نصب کلاینت Flux
  • ایجاد یک کاربر IAM و اعتبار CodeCommit
  • نصب Flux در خوشه آمازون EKS و فعال کردن ویژگی به روز رسانی خودکار تصویر

3. گردش کار GitOps را با Flux CD اجرا کنید

برای لاین ها CI/CD GitOps، تغییرات پیکربندی و تغییرات وضعیت در خوشه‌های EKS و بارهای کاری در حال اجرا بر روی آن ناشی از تغییرات کد در Git است (که توسط درخواست‌های فشار یا کشش git ایجاد می‌شود. GitOps درخواست pull را توصیه می‌کند). خط لوله سنتی CI/CD با موتور CI کار می‌کند و ایجاد/اعمال یا نصب/ارتقای فرمان kubectl برای استقرار خوشه را راه‌اندازی می‌کند. بنابراین، GitOps یک خط لوله CI/CD کارآمدتر و مختصرتر ایجاد می کند.

ما یک برنامه کاربردی خاص – “جوراب فروشی” – و تمرین های عملی را نشان خواهیم داد تا نشان دهیم که چگونه به یکپارچگی و تحویل مداوم در خط لوله GitOps CI/CD دست می یابد.

3.1 درباره Sock Shop

ما از قسمت رو به کاربر فروشگاه اینترنتی جوراب فروشی به عنوان نمونه استفاده خواهیم کرد. با Spring Boot، Go Kit و Node ساخته شده است – و در ظروف Docker بسته بندی شده است. به عنوان یک “Microservice Standard Demo” نشان می دهد:

  • بهترین شیوه ها برای استقرار میکروسرویس ها (از جمله نمونه هایی از اشتباهات)
  • قابلیت های استقرار بین پلتفرمی
  • مزایای یکپارچه سازی / استقرار مداوم
  • ماهیت مکمل DevOps و میکروسرویس ها
  • یک برنامه کاربردی “واقعی” قابل آزمایش برای پلتفرم های مختلف ارکستراسیون

پروژه فروشگاه جوراب متشکل از 8 میکروسرویس front-end و back-end است که قسمت جلویی یک صفحه وب است که توسط NodeJS ایجاد شده است. نام پروژه این است: front-end در اینجا. و از طریق درخواست‌های http به چندین سرویس بک‌اند دسترسی پیدا می‌کند که عبارتند از: سفارش، پرداخت، مدیریت کاربر، مدیریت محصول و سبد خرید و غیره. داده‌های سرویس‌های بک‌اند در MongoDB و MySQL ذخیره می‌شوند.

معماری مرجع به شرح زیر است:


3.2 درباره Kustomize

علاوه بر تنظیم گردش کار GitOps، ما همچنین باید نحوه پیکربندی Kubernetes را نیز بدانیم. با افزایش پیچیدگی سیستم و پیچیدگی محیط، حفظ مدیریت مبتنی بر موجودی منابع سنتی (yaml) به طور فزاینده ای دشوار می شود. موارد استفاده پیچیده تجاری، محیط های متعدد (توسعه، آزمایش، پیش از انتشار، تولید)، و تعداد زیادی از موجودی منابع yaml نیاز به نگهداری و مدیریت دارند. اگرچه Helm می تواند برخی از مشکلات را حل کند، مانند مدیریت یکپارچه فایل های منابع پراکنده، توزیع برنامه، ارتقاء، بازگشت و غیره، اما Helm مقابله با تفاوت های کوچک بین محیط ها را دشوارتر می کند. همچنین مستلزم تسلط بر نحو پیچیده DSL (Syntax قالب) است که مانع بالایی برای شروع است. بنابراین، ابزار مدیریت پیکربندی اعلامی Kustomize متولد شد. Kustomize به تیم ها کمک می کند تا مقادیر زیادی از منابع YAML Kubernetes را در محیط ها و تیم های مختلف مدیریت کنند. این به تیم‌ها کمک می‌کند تا تفاوت‌های کوچک در محیط‌ها را به روشی سبک مدیریت کنند، پیکربندی‌های منابع را قابل استفاده مجدد می‌کند، تلاش‌های کپی و تغییر را کاهش می‌دهد و همچنین خطاهای پیکربندی را تا حد زیادی کاهش می‌دهد. کل فرآیند پیکربندی برنامه نیازی به یادگیری اضافی از نحو قالب ندارد.

Kustomize مشکلات فوق را به روش های زیر حل می کند:
  • Kustomize پیکربندی برنامه را در محیط های مختلف از طریق Base & Overlays حفظ می کند.
  • Kustomize از Patch برای استفاده مجدد از پیکربندی و پیاده سازی پایه استفاده می کند و استفاده مجدد از منبع از طریق بخش تفاوت بین توضیحات Overlay و پیکربندی برنامه پایه به دست می آید.
  • Kustomize فایل های بومی Kubernetes YAML را بدون نیاز به یادگیری نحو DSL مدیریت می کند.

طبق وب سایت رسمی، Kustomize به یک ابزار مدیریت پیکربندی بومی برای Kubernetes تبدیل شده است که به کاربران امکان می دهد تنظیمات برنامه را بدون قالب سفارشی کنند. Kustomize از مفاهیم بومی K8s برای کمک به ایجاد و استفاده مجدد از پیکربندی‌های منبع (YAML) استفاده می‌کند و به کاربران این امکان را می‌دهد که از یک فایل توصیف برنامه (YAML) به عنوان پایه (Base YAML) استفاده کنند و سپس فایل توضیحات مورد نیاز را برای برنامه کاربردی مستقر نهایی از طریق Overlays ایجاد کنند.


3.3 پیکربندی چند خوشه

با درک ابزار مدیریت پیکربندی Kustomize، ما از Kustomization (پایه، پوشش‌ها) برای فعال کردن تبدیل استقرار چند خوشه‌ای استفاده می‌کنیم.

ما دو دایرکتوری در پروژه میکروسرویس ایجاد کردیم: دایرکتوری پایه برای ذخیره فایل های پیکربندی کامل منبع (YAML) و دایرکتوری overlays برای ذخیره محیط های مختلف یا پیکربندی دیفرانسیل خوشه.

به عنوان مثال، در این مورد، فایل پیکربندی کامل برای میکروسرویس، full-demo.yaml است و آن را در پوشه اصلی کپی می کنیم.

cp deploy/kubernetes/complete-demo.yaml deploy/kubernetes/base/complete-demo.yaml

سپس فایل را از طریق kustomization.yaml ارجاع می دهیم:

# deploy/kubernetes/base/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ./complete-demo.yaml

برای محیط توسعه، در صورت وجود الزامات دیفرانسیل، مانند تغییر تعداد پورت‌های سرویس و کپی، فقط تنظیمات دیفرانسیل را در فایل overlays/development/kustomization.yaml بدون کپی و تغییر کامل-demo.yaml موجود پیکربندی کنید.

3.4 استقرار Microservices با GitOps Workflow

پس از تکمیل پشتیبانی چند خوشه ای برای میکروسرویس ها، باید Flux بداند که پیکربندی میکروسرویس ها تغییر کرده است، بنابراین آدرس CodeCommit مخزن میکروسرویس ها (microservices-repo) را در مخزن Flux (flux-repo) ثبت می کنیم.

3.4.1 افزودن آدرس مخزن Microservices

ما به مخزن Flux در زیر پوشه لایه برنامه/برنامه‌ها باز می‌گردیم:

.
├── base
│ ├── kustomization.yaml
│ └── sock-shop
│ ├── kustomization.yaml
│ ├── namespace.yaml
│ ├── rbac.yaml
│ └── tenant.yaml
└── overlays
└── development
├── kustomization.yaml
└── sock-shop
└── kustomization.yaml

فایل tenant.yaml را در apps/base/sock-shop/ باز کنید و MICRO_SERVICES_REPO را با آدرس microservices جایگزین کنید: https://git-codecommit.xxx.amazonaws.com/v1/repos/microservices-repo.

apiVersion: source.toolkit.fluxcd.io/v1beta1
kind: GitRepository
metadata:
name: sock-shop-tenant
namespace: sock-shop
spec:
interval: 1m
url: __MICRO_SERVICES_REPO__
ref:
branch: main
secretRef:
name: microservices-basic-access-auth
......

3.4.2 افزودن اعتبار CodeCommit

حساب و رمز عبور را برای «آماده کردن اعتبارنامه‌های AWS CodeCommit» پیدا کنید. قبل از اجرای دستور، مقدار داده ها را به کدگذاری base64 تبدیل کنید.

سپس فایل base/sock-shop/basic-access-auth.yaml را باز کنید و BASE64_USERNAME و BASE64_PASSWORD را با کدگذاری base64 ایجاد شده جایگزین کنید:

---
apiVersion: v1
kind: Secret
metadata:
name: microservices-basic-access-auth
namespace: sock-shop
type: Opaque
data:
username: __BASE64_USERNAME__
password: __BASE64_PASSWORD__

3.4.3 استقرار

با اضافه شدن آدرس Git میکروسرویس در مخزن پیکربندی Flux، Flux به طور خودکار تغییرات پیکربندی خود را اسکن می کند. هنگامی که کدها متعهد شدند، Flux بررسی می‌کند که آیا میکروسرویس‌هایی در خوشه مستقر شده‌اند و آیا با تعریف مخزن Git مطابقت دارند یا خیر، در غیر این صورت، Flux به طور خودکار میکروسرویس‌ها را در خوشه مستقر می‌کند.

پس از اجرای کد، دستور flux get kustomizations -watch را اجرا کنید و منتظر بمانید تا Flux به روز شود. وقتی وضعیت READY همه سفارشی سازی ها True باشد، استقرار کامل می شود.

غلاف ها و خدمات را در فضای نام فروشگاه جوراب، که در زیر نشان داده شده است، جستجو کنید:

$ kubectl get pod,service -n sock-shop
NAME READY STATUS RESTARTS AGE
pod/carts-b4d4ffb5c-z4jrj 1/1 Running 0 5m28s
pod/carts-db-6c6c68b747-jl5pd 1/1 Running 0 5m28s
pod/catalogue-759cc6b86-qdmvc 1/1 Running 0 5m28s
pod/catalogue-db-96f6f6b4c-zgp5z 1/1 Running 0 5m28s
pod/front-end-5c89db9f57-cvbdl 1/1 Running 0 5m28s
pod/orders-7664c64d75-lqwbm 1/1 Running 0 5m28s
pod/orders-db-659949975f-qv7pl 1/1 Running 0 5m28s
pod/payment-7bcdbf45c9-szrfq 1/1 Running 0 5m28s
pod/queue-master-5f6d6d4796-nkktx 1/1 Running 0 5m28s
pod/rabbitmq-5bcbb547d7-gzhn4 2/2 Running 0 5m28s
pod/session-db-7cf97f8d4f-9mz6v 1/1 Running 0 5m28s
pod/shipping-7f7999ffb7-95rlc 1/1 Running 0 5m27s
pod/user-68df64db9c-kh247 1/1 Running 0 5m27s
pod/user-db-6df7444fc-jlkp9 1/1 Running 0 5m27s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/carts ClusterIP 172.20.33.124 <none> 80/TCP 5m29s
service/carts-db ClusterIP 172.20.75.163 <none> 27017/TCP 5m29s
service/catalogue ClusterIP 172.20.92.254 <none> 80/TCP 5m29s
service/catalogue-db ClusterIP 172.20.242.255 <none> 3306/TCP 5m29s
service/front-end LoadBalancer 172.20.55.188 k8s-sockshop-frontend-12345678910-012345678910abc.elb.us-east-1.amazonaws.com 80:30001/TCP 5m29s
service/orders ClusterIP 172.20.8.252 <none> 80/TCP 5m29s
service/orders-db ClusterIP 172.20.40.212 <none> 27017/TCP 5m29s
service/payment ClusterIP 172.20.6.218 <none> 80/TCP 5m29s
service/queue-master ClusterIP 172.20.153.80 <none> 80/TCP 5m29s
service/rabbitmq ClusterIP 172.20.99.37 <none> 5672/TCP,9090/TCP 5m29s
service/session-db ClusterIP 172.20.37.111 <none> 6379/TCP 5m29s
service/shipping ClusterIP 172.20.43.252 <none> 80/TCP 5m29s
service/user ClusterIP 172.20.220.174 <none> 80/TCP 5m29s
service/user-db ClusterIP 172.20.70.57 <none> 27017/TCP 5m29s

به نام DNS AWS Load Balancer دسترسی پیدا کنید.


3.5 خلاصه

در این بخش، یک اپلیکیشن تجاری میکروسرویس، فروشگاه اینترنتی Sock Shop را معرفی کردیم و پیکربندی چند خوشه ای آن را تکمیل کردیم. ما همچنین یک گردش کار استاندارد GitOps بر اساس Flux ایجاد کردیم که به طور خودکار خوشه هدف را با تغییرات در فایل های پیکربندی همگام می کند تا استقرار میکروسرویس در خوشه EKS را تکمیل کند. در همین حال، یک ابزار کاربردی مدیریت پیکربندی K8s-Kustomize و نحوه مدیریت فایل های منابع برنامه را معرفی کردیم. در اینجا خلاصه ای از این بخش آمده است:

  • معرفی فروشگاه جوراب
  • یک ابزار مدیریت پیکربندی را بیاموزید – Kustomize (پایه، پوشش‌ها) و نحوه تغییر استقرار چند خوشه‌ای میکروسرویس.
  • یک گردش کار GitOps بسازید و میکروسرویس ها را مستقر کنید

4. استقرار خودکار مبتنی بر تصویر با گردش کار GitOps

ما میکروسرویس Front-end Sock Shop را به عنوان مثال برای نشان دادن فرآیند دقیق تغییرات کد، ساخت تصویر و انتشار سفارشی با گردش کار GitOps انتخاب کردیم.

4.1 تعریف CodePipeline CI

Front-end یک سرویس front-end خالص Node.js برای پشتیبانی از بسته بندی تصویر Docker است (برای جزئیات به معمار فروشگاه جوراب در فصل 3.1 مراجعه کنید). برای تعریف فرآیند CI اجرا شده در CodePipeline، یک فایل buildspec.yml را به کد منبع پروژه front-end اضافه کنید:

version: 0.2
phases:
pre_build:
commands:
- echo Logging in to Amazon ECR...
- aws --version
- AWS_ACCOUNT_ID=`echo $REPOSITORY_URI|cut -d"." -f1`
- AWS_DEFAULT_REGION=`echo $REPOSITORY_URI|cut -d"." -f4`
- echo $AWS_ACCOUNT_ID $AWS_DEFAULT_REGION
- aws ecr get-login-password --region $AWS_DEFAULT_REGION | docker login --username AWS --password-stdin $REPOSITORY_HOST
- COMMIT_HASH=$(echo $CODEBUILD_RESOLVED_SOURCE_VERSION | cut -c 1-7)
- IMAGE_TAG=main-$COMMIT_HASH-$CODEBUILD_BUILD_NUMBER
- echo $IMAGE_TAG
build:
commands:
- echo Build started on `date`
- echo Building the Docker image...
- docker build -t $REPOSITORY_URI:latest .
- docker tag $REPOSITORY_URI:latest $REPOSITORY_URI:$IMAGE_TAG
post_build:
commands:
- echo Build completed on `date`
- echo Pushing the Docker images...
- docker push $REPOSITORY_URI:latest
- docker push $REPOSITORY_URI:$IMAGE_TAG

این فرآیند CI به طور خودکار یک تصویر می‌سازد و در صورت تغییر کد فرانت‌اند، آن را در مخزن ECR weaveworksdemos/front-end آپلود می‌کند. فرمت تگ تصویر [شاخه]-[متعهد]-[شماره ساخت] است.

4.2 به روز رسانی خودکار تصویر

هنگامی که در یک محیط چابک با یکپارچگی مداوم کار می کنید، مانند هنگام آزمایش توسعه، به روز رسانی مخزن GitOps یا استفاده از اسکریپت ها برای مدیریت تصاویر سرویس های جدید می تواند یک دردسر واقعی باشد. خوشبختانه، Flux دارای یک ویژگی عالی به روز رسانی خودکار تصویر است که از این کار برای شما مراقبت می کند. برای استفاده از آن، تنها کاری که باید انجام دهید این است که مؤلفه به روز رسانی تصویر را در پیکربندی خود فعال کنید. اگر هنوز این کار را انجام نداده‌اید، جای نگرانی نیست، فقط پارامترهای –components-extra=image-reflector-controller,image-automation-controller را هنگام تکرار Flux bootstrap اضافه کنید تا فعال شود.

برای دستیابی به به روز رسانی خودکار مبتنی بر تصویر، باید مراحل زیر را انجام دهیم:

  • مخزن تصویر میکروسرویس جلویی را ثبت کنید تا به Flux اجازه دهید به صورت دوره ای گزارشگر مخزن تصویر ECR را در پروژه جلویی اسکن کند.
  • اعتبارنامه ها را برای دسترسی به مخزن تصویر پیکربندی کنید. Flux برای دسترسی به مخزن تصویر ECR برای خواندن اطلاعات تصویر به اعتبار نیاز دارد.
  • خط مشی به روز رسانی تصویر را تنظیم کنید. در بیشتر موارد، ما نمی خواهیم که تمام تغییرات نسخه های تصویر هر بار سی دی را فعال کنند. درعوض، ما فقط می‌خواهیم که کد شاخه (اصلی) مشخص شده، CD را راه‌اندازی کند. برای برآوردن این نیاز به یک خط مشی به روز رسانی ویژه نیاز است.

در ادامه عملیات فوق را یکی یکی تکمیل می کنیم.

4.2.1 افزودن خط مشی تصویر به قسمت جلویی مخزن Git

در پروژه microservices-repo، ما از پوشش‌های Kustomization در محیط DEV برای جایگزینی microservice front-end با نسخه سفارشی‌شده و به‌روز شده استفاده خواهیم کرد. فایل deploy/kubernetes/overlays/development/kustomization.yaml را تغییر دهید. (توجه: ACCOUNT_ID را با ACCOUNT_ID خود جایگزین کنید).

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ../../base
images:
- name: weaveworksdemos/front-end
newName: __ACCOUNT_ID__.dkr.ecr.us-west-2.amazonaws.com/weaveworksdemos/front-end # {"$imagepolicy": "sock-shop:sock-shop-front-end:name"}
newTag: latest # {"$imagepolicy": "sock-shop:sock-shop-front-end:tag"}

4.2.2 ثبت Front-End یک Microservice تحت Flux-repo

در پروژه flux-repo، یک فایل apps/overlays/development/sock-shop/registry.yaml جدید ایجاد کنید و ACCOUNT_ID را با ACCOUNT_ID خود جایگزین کنید.

---
apiVersion: image.toolkit.fluxcd.io/v1beta1
kind: ImageRepository
metadata:
name: sock-shop-front-end
namespace: sock-shop
spec:
image: __ACCOUNT_ID__.dkr.ecr.xxxx.amazonaws.com/weaveworksdemos/front-end
interval: 1m0s

4.2.3 پیکربندی اعتبار دسترسی برای Amazon ECR

دو روش برای اعتبارنامه آمازون ECR در Flux وجود دارد.

  • مکانیزم احراز هویت خودکار (کنترل کننده بازتابنده تصویر به تنهایی اعتبارنامه ها را بازیابی می کند، فقط برای: Amazon ECR، GCP GCR، Azure ACR)
  • به طور مرتب اعتبارنامه ها (در خوشه از طریق Secret ذخیره می شود) با CronJob
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- gotk-components.yaml
- gotk-sync.yaml
patches:
- patch: |-
- op: add
path: /spec/template/spec/containers/0/args/-
value: --aws-autologin-for-ecr
target:
version: v1
group: apps
kind: Deployment
name: image-reflector-controller
namespace: flux-system

4.2.4 تنظیم خط مشی به روز رسانی تصویر

فایل gitops/apps/overlays/development/sock-shop/policy.yaml را اضافه کنید. قوانین زیر با نسخه‌های تصویر مانند master-d480788-1، master-d480788-2 و master-d480788-3 مطابقت دارند.

---
apiVersion: image.toolkit.fluxcd.io/v1beta1
kind: ImagePolicy
metadata:
name: sock-shop-front-end
spec:
imageRepositoryRef:
name: sock-shop-front-end
filterTags:
pattern: '^main-[a-fA-F0-9]+-(?P<buidnumber>.*)'
extract: '$buidnumber'
policy:
numerical:
order: asc

فایل gitops/apps/overlays/development/sock-shop/image-automation.yaml را اضافه کنید. پیکربندی خودکار تصویر Flux یک مخزن Git را برای پیکربندی برنامه، از جمله شاخه، مسیر، و اطلاعات دیگر مشخص می‌کند.

---
apiVersion: image.toolkit.fluxcd.io/v1beta1
kind: ImageUpdateAutomation
metadata:
name: sock-shop-front-end
spec:
git:
checkout:
ref:
branch: main
commit:
author:
email: fluxcdbot@users.noreply.github.com
name: fluxcdbot
messageTemplate: '{{range .Updated.Images}}{{println .}}{{end}}'
push:
branch: main
interval: 5m0s
sourceRef:
kind: GitRepository
name: sock-shop-tenant
namespace: sock-shop
update:
path: ./deploy/kubernetes/overlays/development
strategy: Setters

4.3 انتشار و تأیید

ما کل فرآیند به‌روزرسانی خودکار تصویر را با اصلاح کد منبع جلویی تأیید می‌کنیم.

4.3.1 کد فرانت اند را به روز کنید

پاورقی صفحه جلویی را تغییر دهید و فایل را تغییر دهید: front-end/public/footer.html.


4.3.2 CodePipeline را بررسی کنید

تغییرات کد در قسمت جلویی به طور خودکار باعث اجرای CodePipeline می شود.


4.3.3 تأیید تغییر نسخه تصویر ECR

پس از تکمیل CodePipeline، وارد کنسول آمازون ECR شوید تا نسخه تصویر weaveworksdemos/front-end را بررسی کنید:


4.3.4 بررسی اطلاعات تصویر شار

از طریق Flux CLI، بررسی کنید که آیا ImageRepository و ImagePolicy با موفقیت آخرین نسخه را بازیابی کرده اند یا خیر.

$ flux get images all --all-namespaces
NAMESPACE NAME LAST SCAN SUSPENDED READY MESSAGE 
sock-shop imagerepository/sock-shop-front-end 2022-09-18T14:46:45Z False True successful scan, found 20 tags
NAMESPACE NAME LATEST IMAGE READYMESSAGE 
sock-shop imagepolicy/sock-shop-front-end 267314483271.dkr.ecr.us-west-2.amazonaws.com/weaveworksdemos/front-end:master-1f49071-24 True Latest image tag for '267314483271.dkr.ecr.us-west-2.amazonaws.com/weaveworksdemos/front-end' resolved to: master-1f49071-24
NAMESPACE NAME LAST RUN SUSPENDED READY MESSAGE 
sock-shop imageupdateautomation/sock-shop-front-end 2022-09-18T14:43:51Z False True no updates made; last commit 1ff6d91 at 2022-09-18T14:34:40Z

4.3.5 کد منبع Microservice به طور خودکار به روز می شود

Flux به طور خودکار نسخه تصویر جلویی را به روز کرد. آخرین commit توسط fluxcdbot انجام شد و تگ تصویر با موفقیت به آخرین نسخه اصلاح شد: master-1f49071-24.


4.3.6 تأیید نسخه تصویر پاد

تأیید نام غلاف با kubectl get pod -n sock-shop | grep front-end. جزئیات غلاف را با kubectl بررسی کنید describe pod/front-end-759476784b-9r2rt -n sock-shop | grep Image: برای تایید به روز رسانی نسخه تصویر. به صورت زیر نشان می دهد:

$ kubectl describe pod/front-end-759476784b-9r2rt -n sock-shop | grep Image:
Image: 267314483271.dkr.ecr.us-west-2.amazonaws.com/weaveworksdemos/front-end:master-1f49071-24

4.3.7 تأیید کنید که صفحه استاتیک به روز بوده است


4.4 خلاصه

در این بخش، کل فرآیند استقرار خودکار را بر اساس تصاویر به تفصیل شرح داده ایم. به طور خلاصه، ما از قابلیت نظارت مداوم Flux برای مخازن تصویر استفاده می کنیم. هنگامی که تغییری در نسخه تصویر شناسایی می شود، به طور خودکار پیکربندی تصویر را در مخزن Git تغییر می دهد و با اتصال به گردش کار استاندارد GitOps در بخش قبلی، استقرار خودکار را تکمیل می کند. برای خلاصه کردن این بخش:

  • اجرای فرآیند CI از طریق CodePipeline برای دستیابی به یکپارچه سازی مداوم کدهای فرانت اند.
  • مکان یابی و اصلاح فایل پیکربندی کسب و کار با حاشیه نویسی Flux.
  • پیکربندی سیاست به‌روزرسانی تصویر Flux برای فعال کردن Flux برای نظارت بر نسخه‌های خاص تصاویر و استقرار کامل خودکار.

نتیجه

این مقاله بر نحوه استفاده از FluxCD برای خودکار کردن انتشار میکروسرویس‌ها در خوشه آمازون EKS در ابر و همچنین بهترین روش‌ها برای خطوط لوله GitOps تمرکز دارد. GitOps یک روش تحویل مداوم است که مجموعه ای از بهترین شیوه ها را در بر می گیرد. در صورتی که ابزارهای CI/CD مطابق با اصول اولیه GitOps باشند، هیچ محدودیت سختی برای ساخت ابزارهای CI/CD وجود ندارد.

[تعداد: 1   میانگین: 5/5]
در این مقاله:
,
پست نوشته شده توسط:
دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

مقاله قبل
مقاله بعد
شاید دوست داشته باشید