استخدام Flux لتنفيذ GitOps على AWS

  • 399 المشاهدات
  • قراءة دقيقة واحدة
هادي بهادوري
  • 8 أبريل 2024
0 الأسهم
0
0
0
0
0
الأسهم
0
0
0
0

مقدمة

في حين اعتمدت العديد من الشركات الكبرى نظام Kubernetes في إنتاجها، إلا أنها غالبًا ما تواجه حيرةً بشأن كيفية تحقيق النشر المستمر، والأمان العالي، وعزل الأذونات، والتدقيق، مع ضمان مرونة الأعمال مع تشغيل مجموعات Kubernetes متعددة في وقت واحد وفي مراحل مختلفة. يتيح استخدام GitOps هذا النشر المستمر المستند إلى مجموعات Kubernetes، مع تلبية متطلبات مستوى المؤسسة، مثل الأمان وعزل الأذونات.

في هذه المدونة، سنُطبّق GitOps في بيئة Amazon EKS باستخدام AWS CodeCommit وAWS CodePipeline وFlux. سنشرح بالتفصيل كيفية إعداد سير عمل GitOps الذي يُلبي متطلبات الإنتاج في بيئة Amazon EKS هذه، ونُبيّن كيف تُحقّق تطبيقات الخدمات المُصغّرة التكامل والتسليم المُستمرّين في خط أنابيب CI/CD بنمط GitOps.

المتطلبات الأساسية
  • تجربة AWS
  • حساب AWS

ما هو GitOps؟

GitOps هي طريقة لتوفير النشر المستمر لتطبيقات السحابة. تُركز على تجربة مُركزة على المُطور، مع الاستفادة من البنية التحتية باستخدام أدوات مُعتادة على استخدامها من قِبل المُطورين، بما في ذلك أدوات Git والنشر المُستمر.

الفكرة الأساسية لـ GitOps هي وجود مستودع Git يحتوي دائمًا على وصفٍ دقيق للبنية التحتية في بيئة الإنتاج، بالإضافة إلى عملية آلية لضبط بيئة الإنتاج بما يتوافق مع الحالة الموضحة في المستودع. إذا كنت ترغب في نشر تطبيق جديد أو تحديث تطبيق موجود، فما عليك سوى تحديث المستودع. العملية الآلية تتولى كل شيء. الأمر أشبه بإدارة تطبيقاتك في بيئة الإنتاج باستخدام نظام تحكم آلي.

لماذا تستخدم GitOps؟

Git هو المصدر الحقيقي الوحيد لحالة النظام. فهو يدعم النشر المتكرر والآلي، وإدارة المجموعات، والمراقبة. يُعيد المطورون استخدام سير عمل Git الراسخة في المؤسسة للبناء والاختبار والفحص، وغيرها من خطوات التكامل المستمر. بمجرد تثبيت أحدث حالة نظام على فرع مستودع Git الرئيسي، تُستخدم سلسلة أدوات GitOps للتحقق من النشر، وعرض التنبيهات، وإصلاح العمليات. بناءً على مبادئ GitOps الأساسية، نعتقد أن GitOps هو أفضل طريقة لنشر مجموعات Kubernetes بشكل مستمر. تتم العملية كما يلي:


أفضل الممارسات المستندة إلى Amazon EKS لـ GitOps

يظهر خط أنابيب CI/CD الإجمالي، وفقًا لأفضل الممارسات، في الشكل أدناه.


يوجد ثلاثة مستودعات للأكواد ضمن مستودع AWS CodeCommit. واحد مستودع التدفق هو مستودع التكوين لـ قرص فلوكس سي دي، والتي تستخدم لتحديد الموارد المتعلقة بـ تدفق الآخر هو microservices-repo، الذي يخزن إعدادات تطبيق microservices وملفات النشر. والثالث هو تطبيق مستودع المصدر لخدمات الأعمال. يستخدم هذا المنشور مشروع واجهة أمامية كمثال. نستخدم AWS CodePipeline للتكامل المستمر في خط الأنابيب. CI/CD لقد استخدمنا صورة Docker في أمازون ECR لقد قمنا بالحفظ والحفظ ونشرنا محرك Flux CD كجراب في بيئة Amazon EKS.

سير العمل الأساسي هو:
  • يقوم مهندسو البرمجة بكتابة الكود ثم يرسلون الكود النهائي إلى مستودع التطبيق.
  • تؤدي تغييرات الكود في مستودع التطبيق إلى تشغيل AWS CodePipeline.
  • يقوم AWS CodePipeline بتحرير الكود وتعبئته وإنشاء صور الحاويات ودفعها إلى مستودع صور الحاويات/Amazon ECR.
  • يقوم محرك Flux CD، الذي يعمل في بيئة EKS، بفحص مستودع صور حاوية ECR بشكل منتظم وسحب بيانات تعريف صور الحاوية للتطبيقات.
  • يتم مزامنة عنوان URL لصورة الحاوية الجديدة تلقائيًا مع ملف نشر التطبيق المخزن في مستودع الخدمات المصغرة عبر git commit/push عند اكتشاف إصدار جديد من صورة الحاوية.
  • يسحب Flux بانتظام ملفات تكوينات التطبيقات والنشر من مستودع Flux. ونظرًا لأن مستودع Flux يُشير إلى مستودع الخدمات المصغرة، يتحقق Flux من اتساق حالة تنفيذ عبء عمل المجموعة مع التوقعات الموضحة في ملفات مستودع الخدمات المصغرة. في حال وجود أي اختلافات، يُمكّن Flux تلقائيًا مجموعة EKS من مزامنة هذه الاختلافات لضمان تشغيل أحمال العمل في الحالة المتوقعة.

بعد أن شرحنا مفهوم GitOps وهندسة خط أنابيب CI/CD، سنستخدم حالة لإكمال هذا التمرين من خلال مراجعة الوحدات الأربع التالية:

  • نشر البنية التحتية السحابية باستخدام البنية التحتية كرمز (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 باستخدام مخططات EKS

تساعدك مخططات EKS على بناء مجموعات EKS متكاملة، مُجهزة بالكامل بالبرامج التشغيلية اللازمة لنشر أحمال العمل وتشغيلها. باستخدام مخططات EKS، يمكنك وصف التكوين للحالة المطلوبة لبيئة EKS، مثل لوحة التحكم، وعُقد العمل، وإضافات Kubernetes، كمخطط IaC. بمجرد تكوين المخطط، يمكنك استخدامه لنشر بيئات متسقة عبر حسابات ومناطق AWS متعددة باستخدام الأتمتة المستمرة.

يمكنك استخدام مخططات EKS لإعداد مجموعة EKS بسهولة باستخدام مكونات Amazon EKS الإضافية، بالإضافة إلى مجموعة واسعة من المكونات الإضافية مفتوحة المصدر الشائعة، بما في ذلك Prometheus وKarpenter وNginx وTraefik وAWS Load Balancer Controller وFluent Bit وKeda وArgoCD وغيرها. كما تساعدك مخططات EKS على تطبيق عناصر التحكم الأمنية اللازمة لتشغيل أحمال العمل من فرق متعددة على مجموعة.

دليل البدء السريع قم بإنشاء التعليمات البرمجية التالية ثم قم بتشغيلها لتثبيت تبعيات المشروع.

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

lib/quickstart-stack.ts افتح وأدخل الرمز. مخططات EKS أضف ما يلي.

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، وأنشأنا مجموعة EKS مخصصة باستخدام CDK أثناء تثبيت ملحق AWS Application Load Balancer. يوفر هذا شرطًا أساسيًا للوصول إلى صفحات ويب الخدمات المصغرة مستقبلًا. فيما يلي ملخص لهذا القسم:

  • تم إطلاق مشروع CDK باستخدام cdk init.
  • من خلال إضافة البرنامج الإضافي AWS Application Load Balancer، قمت بسرعة بتعريف مجموعة EKS باستخدام EKS Blueprint.

2. نشر Fluxcd على مجموعة Amazon EKS

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 عبر بيانات اعتماد Git HTTPS.

2.3 تثبيت Flux على المجموعة

استنسخ كود 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 Bootstrapping. في حال وجود مكونات Flux في المجموعة، سيقوم أمر Bootstrapping بإجراء الترقيات اللازمة. عملية 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، وsource، وnotification، وimage automation، وimage reflector.
  • 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 باستخدام الأمر 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 على مجموعة Amazon EKS وتمكين ميزة التحديث التلقائي للصورة

3. تنفيذ سير عمل GitOps باستخدام Flux CD

بالنسبة لأنابيب GitOps CI/CD، تُدار تغييرات التكوين والحالة في مجموعات EKS وأحمال العمل التي تعمل عليها من خلال تغييرات الكود في Git (التي تُولّدها طلبات git push أو pull. يُوصي GitOps بطلبات pull). يعمل أنبوب CI/CD التقليدي مع محرك CI ويُفعّل أمر إنشاء/تطبيق أو تثبيت/ترقية kubectl لنشر المجموعة. وبالتالي، يُنشئ GitOps أنبوب CI/CD أكثر كفاءةً ودقةً.

سنوضح تطبيقًا محددًا - "Sock Shop" - وتمارين عملية لإظهار كيفية تحقيق التكامل والتسليم المستمر في خط أنابيب GitOps CI / CD.

3.1 حول متجر الجوارب

سنستخدم الجزء المُوجّه للمستخدم من متجر جورب إلكتروني كمثال. تم بناؤه باستخدام Spring Boot وGo Kit وNode، وهو مُجمّع في حاويات Docker. كما يُوضّح "العرض التوضيحي القياسي للخدمات المصغرة":

  • أفضل الممارسات لنشر الخدمات المصغرة (بما في ذلك أمثلة الأخطاء)
  • إمكانيات النشر عبر الأنظمة الأساسية
  • فوائد التكامل/النشر المستمر
  • الطبيعة التكميلية لـ DevOps والخدمات المصغرة
  • تطبيق "حقيقي" قابل للاختبار لمنصات التنسيق المختلفة

يتكون مشروع متجر الجوارب من 8 خدمات مجهرية أمامية وخلفية، وهي الواجهة الأمامية لصفحة ويب مُنشأة بواسطة NodeJS. اسم المشروع هنا: front-end. ويصل المشروع إلى العديد من الخدمات الخلفية عبر طلبات http، والتي تشمل: الطلب، والدفع، وإدارة المستخدمين، وإدارة المنتجات، وسلة التسوق، وغيرها. تُخزَّن بيانات الخدمات الخلفية في MongoDB وMySQL.

الهندسة المعمارية المرجعية هي كما يلي:


3.2 حول Kustomize

بالإضافة إلى إعداد سير عمل GitOps، نحتاج أيضًا إلى معرفة كيفية تهيئة Kubernetes. مع تزايد تعقيد النظام والبيئة، تزداد صعوبة الحفاظ على إدارة مخزون الموارد التقليدية (YAML). تتطلب حالات الاستخدام التجارية المعقدة، والبيئات المتعددة (التطوير، الاختبار، ما قبل الإصدار، الإنتاج)، وعدد كبير من مخزون موارد YAML الصيانة والإدارة. على الرغم من قدرة Helm على حل بعض المشكلات، مثل الإدارة الموحدة لملفات الموارد المتفرقة، وتوزيع التطبيقات، والترقية، والاستعادة، وغيرها، إلا أن Helm يُصعّب التعامل مع الاختلافات الطفيفة بين البيئات. كما يتطلب إتقان بناء جملة DSL (صيغة القالب) المعقدة، وهو ما يُشكّل عائقًا كبيرًا أمام الدخول. وهكذا، وُلدت أداة إدارة التكوين التصريحية 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) ودليل التراكبات لتخزين بيئات مختلفة أو تكوينات مجموعة متباينة.

على سبيل المثال، في هذه الحالة، ملف التكوين الكامل للخدمة المصغرة هو 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 دون نسخ وتغيير ملف full-demo.yaml الموجود.

3.4 نشر الخدمات المصغرة باستخدام سير عمل GitOps

بعد الانتهاء من دعم المجموعات المتعددة للخدمات المصغرة، يحتاج Flux إلى معرفة أن تكوين الخدمات المصغرة قد تغير، لذلك نقوم بتسجيل عنوان URL الخاص بـ CodeCommit لمستودع الخدمات المصغرة (microservices-repo) في مستودع Flux (flux-repo).

3.4.1 إضافة عنوان مستودع الخدمات المصغرة

نعود إلى مستودع 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 بعنوان URL الخاص بالخدمات المصغرة: 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" لجميع التخصيصات "صحيح".

ابحث عن القرون والخدمات في مساحة اسم متجر الجوارب، كما هو موضح أدناه:

$ 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

لقد اخترنا خدمة Sock Shop الأمامية كمثال لإظهار العملية التفصيلية لتغييرات التعليمات البرمجية وبناء الصورة والإصدار المخصص باستخدام سير عمل GitOps.

4.1 تعريف CodePipeline CI

الواجهة الأمامية عبارة عن خدمة Node.js أمامية خالصة لدعم حزم صور Docker (للمزيد من التفاصيل، راجع Sock Shop Architect في الفصل 3.1). لتحديد عملية CI التي تُنفَّذ في CodePipeline، أضف ملف buildspec.yml إلى الكود المصدري لمشروع الواجهة الأمامية:

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

تُنشئ عملية التكامل المستمر هذه صورةً تلقائيًا وتُحمّلها إلى مستودع ECR weaveworksdemos/front-end عند تغيّر شيفرة الواجهة الأمامية. تنسيق وسم الصورة هو [branch]-[commit]-[build number].

4.2 التحديث التلقائي للصورة

عند العمل في بيئة مرنة مع تكامل مستمر، كما هو الحال عند اختبار التطوير، أو تحديث مستودع GitOps، أو استخدام البرامج النصية لإدارة صور الخدمات الجديدة، قد يكون الأمر مُرهقًا للغاية. لحسن الحظ، يوفر Flux ميزة تحديث تلقائي للصور رائعة تُعنى بذلك. لاستخدامها، كل ما عليك فعله هو تفعيل مُكوّن تحديث الصورة في إعداداتك. إذا لم تقم بذلك بعد، فلا تقلق، ما عليك سوى إضافة المُعاملات –components-extra=image-reflector-controller,image-automation-controller عند تكرار عملية التمهيد Flux لتفعيلها.

لتحقيق التحديثات التلقائية المستندة إلى الصور، نحتاج إلى تنفيذ الخطوات التالية:

  • قم بتسجيل مستودع صور الخدمة المصغرة الأمامية للسماح لـ Flux بفحص مُراسل مستودع صور ECR بشكل دوري في مشروع الواجهة الأمامية.
  • قم بتكوين بيانات الاعتماد للوصول إلى مستودع الصور. يتطلب Flux بيانات اعتماد للوصول إلى مستودع صور ECR لقراءة معلومات الصورة.
  • عيّن سياسة تحديث الصورة. في معظم الحالات، لا نريد أن تُفعّل جميع التغييرات على إصدارات الصورة القرص المضغوط في كل مرة. بدلاً من ذلك، نريد فقط أن يُفعّل رمز الفرع (الجذر) المُحدّد القرص المضغوط. يلزم وجود سياسة تحديث خاصة لتلبية هذا الشرط.

بعد ذلك، سنقوم بإكمال العمليات المذكورة أعلاه واحدة تلو الأخرى.

4.2.1 إضافة سياسة الصورة إلى الواجهة الأمامية لمستودع Git

في مشروع مستودع الخدمات المصغرة، سنستخدم تراكبات التخصيص في بيئة التطوير (DEV) لاستبدال واجهة الخدمات المصغرة بإصدار مُخصص ومُحدّث. عدّل الملف 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 تسجيل الواجهة الأمامية لخدمة صغيرة ضمن 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

هناك طريقتان للحصول على بيانات اعتماد Amazon ECR في Flux.

  • آلية المصادقة التلقائية (تستعيد Image Reflector Controller بيانات الاعتماد من تلقاء نفسها، فقط لـ: 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 Image Automation مستودع Git لتكوين التطبيق، بما في ذلك الفرع والمسار ومعلومات أخرى.

---
apiVersion: image.toolkit.fluxcd.io/v1beta1
kind: ImageUpdateAutomation
metadata:
name: sock-shop-front-end
spec:
git:
checkout:
ref:
branch: main
commit:
author:
email: [email protected]
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، قم بتسجيل الدخول إلى وحدة التحكم Amazon ECR للتحقق من إصدار weaveworksdemos/صورة الواجهة الأمامية:


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 يتم تحديث كود مصدر الخدمة المصغرة تلقائيًا

قام Flux بتحديث صورة الواجهة الأمامية تلقائيًا. آخر عملية تأكيد تمت بواسطة 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 الصورة: للتحقق من تحديث إصدار الصورة، ستظهر الصورة كما يلي:

$ 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. عند اكتشاف أي تغيير في إصدار الصورة، يُغيّر Flux تلقائيًا إعدادات الصورة في مستودع Git، ويُكمل النشر الآلي بالاتصال بسير عمل GitOps القياسي المذكور في القسم السابق. لتلخيص هذا القسم:

  • قم بتشغيل عملية CI من خلال CodePipeline لتحقيق التكامل المستمر للكود الأمامي.
  • حدد موقع ملف تكوين الأعمال وقم بتعديله باستخدام تعليقات Flux.
  • قم بتكوين سياسة تحديث صورة Flux لتمكين Flux من مراقبة إصدارات محددة من الصور وأتمتة النشر بالكامل.

نتيجة

تُركز هذه المقالة على كيفية استخدام FluxCD لأتمتة نشر الخدمات المصغرة على مجموعة Amazon EKS في السحابة، بالإضافة إلى أفضل الممارسات لخطوط أنابيب GitOps. GitOps هي منهجية تسليم مستمر تتضمن مجموعة من أفضل الممارسات. لا توجد حدود صارمة لبناء أدوات CI/CD طالما أنها تلتزم بأساسيات GitOps.

في هذه المقالة:
,
تم كتابة التدوينة بواسطة:
يتبع
اترك تعليقاً

لن يتم نشر عنوان بريدك الإلكتروني. الحقول الإلزامية مشار إليها بـ *

المقال السابق
المقال التالي
قد يعجبك أيضاً