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

مقدمة

في حين اعتمدت العديد من الشركات الكبرى نظام 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 -- لغة 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 أضف ما يلي.

استيراد * كـ cdk من 'aws-cdk-lib'؛ استيراد { Construct } من 'constructs'؛ استيراد * كمخططات من '@aws-quickstart/eks-blueprints'؛ استيراد { KubernetesVersion } من 'aws-cdk-lib/aws-eks'؛ تصدير فئة QuickstartStack تمتد إلى cdk.Stack { منشئ (النطاق: Construct، معرف: سلسلة، الدعائم؟: cdk.StackProps) { super (النطاق، معرف، الدعائم)؛ حساب ثابت = الدعائم؟.env؟.account!؛ منطقة ثابتة = الدعائم؟.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 الاسم جاهز الحالة إعادة التشغيل العمر aws-load-balancer-controller-6bd49cfb7-2cvlk 1/1 قيد التشغيل 0 5m31s aws-load-balancer-controller-6bd49cfb7-7lcwd 1/1 قيد التشغيل 0 5m31s aws-node-9hsvz 1/1 قيد التشغيل 0 99m coredns-66cb55d4f4-gdcqg 1/1 قيد التشغيل 0 106m coredns-66cb55d4f4-gmzjt 1/1 قيد التشغيل 0 106m kube-proxy-wr5jn 1/1 قيد التشغيل 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 المُعدّ. هيكل المشروع كالتالي:

. ├── التطبيقات // تعريف التطبيق │ ├── الأساس // طبقة البنية التحتية للتطبيق │ └── التراكبات // طبقة تراكبات التطبيق ├── العناقيد // بوابة تكوين العناقيد │ └── مجموعة المطورين ├── البنية التحتية // مكونات البنية التحتية المشتركة │ ├── الأساس // البنية التحتية طبقة البنية التحتية │ └── التراكبات // طبقة تراكبات البنية التحتية └── README.md

ثبّت Flux على مجموعة Kubernetes الخاصة بك وقم بتكوينه للإدارة من مستودع Git باستخدام Flux Bootstrapping. في حال وجود مكونات Flux في المجموعة، سيقوم أمر Bootstrapping بإجراء الترقيات اللازمة. عملية Bootstrapping غير فعالة، ويمكن تشغيل الأمر عدة مرات بأمان. استبدل اسم المستخدم وكلمة المرور في الأمر التالي ببيانات اعتماد HTTPS Git الخاصة بك لـ AWS CodeCommit.

تمهيد Flux git \ --url=https://git-codecommit.us-west-2.amazonaws.com/v1/repos/gitops \ --اسم المستخدم=__استبدال_باسم_مستخدم_Git_credential__ الخاص بك__ \ --كلمة المرور=__استبدال_باسم_مستخدم_Git_credential__ الخاص بك__ \ --token-auth=true \ --path="./clusters/dev-cluster" \ --components-extra=وحدة تحكم عاكس الصورة، وحدة تحكم أتمتة الصورة

استخدم 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 الاسم جاهز الحالة إعادة التشغيل العمر pod/helm-controller-88f6889c6-sblvd 1/1 قيد التشغيل 0 11m pod/image-automation-controller-6c5f7bbbd9-8xskk 1/1 قيد التشغيل 0 11m pod/image-reflector-controller-78949bb4b4-bqn4m 1/1 قيد التشغيل 0 11m pod/kustomize-controller-784bd54978-s82dq 1/1 قيد التشغيل 0 11m pod/notification-controller-648bbb9db7-627zs 1/1 قيد التشغيل 0 11m pod/source-controller-79f7866bc7-gdt95 1/1 قيد التشغيل 0 11م الاسم النوع CLUSTER-IP EXTERNAL-IP المنافذ العمر service/notification-controller ClusterIP 172.20.60.72 80/TCP 11m خدمة/وحدة تحكم المصدر ClusterIP 172.20.133.44 80/TCP 11m service/webhook-receiver ClusterIP 172.20.196.178 80/TCP 11م

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/kubernetes/complete-demo.yaml نشر/kubernetes/base/complete-demo.yaml

ثم نقوم بالإشارة إلى الملف عبر kustomization.yaml:

# deploy/kubernetes/base/kustomization.yaml apiVersion: kustomize.config.k8s.io/v1beta1 النوع: التخصيص الموارد: - ./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 ضمن مجلد طبقة التطبيق/التطبيقات:

. قاعدة

افتح ملف 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 النوع: GitRepository البيانات الوصفية: الاسم: sock-shop-tenant المساحة: sock-shop المواصفات: الفاصل الزمني: 1m url: __MICRO_SERVICES_REPO__ المرجع: الفرع: main secretRef: الاسم: 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 النوع: سري البيانات الوصفية: الاسم: microservices-basic-access-auth المساحة: sock-shop النوع: غير شفاف البيانات: اسم المستخدم: __BASE64_USERNAME__ كلمة المرور: __BASE64_PASSWORD__

3.4.3 النشر

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

بعد تنفيذ الكود، شغّل الأمر flux get kustomizations -watch وانتظر تحديث Flux. يكتمل النشر عندما تكون حالة "READY" لجميع التخصيصات "صحيح".

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

$ kubectl get pod,service -n sock-shop الاسم جاهز الحالة إعادة التشغيل العمر pod/carts-b4d4ffb5c-z4jrj 1/1 قيد التشغيل 0 5m28s pod/carts-db-6c6c68b747-jl5pd 1/1 قيد التشغيل 0 5m28s pod/catalogue-759cc6b86-qdmvc 1/1 قيد التشغيل 0 5m28s pod/catalogue-db-96f6f6b4c-zgp5z 1/1 قيد التشغيل 0 5m28s pod/front-end-5c89db9f57-cvbdl 1/1 قيد التشغيل 0 5m28s pod/orders-7664c64d75-lqwbm 1/1 قيد التشغيل 0 5m28s pod/orders-db-659949975f-qv7pl 1/1 قيد التشغيل 0 5m28s pod/payment-7bcdbf45c9-szrfq 1/1 قيد التشغيل 0 5m28s pod/queue-master-5f6d6d4796-nkktx 1/1 قيد التشغيل 0 5m28s pod/rabbitmq-5bcbb547d7-gzhn4 2/2 قيد التشغيل 0 5m28s pod/session-db-7cf97f8d4f-9mz6v 1/1 قيد التشغيل 0 5m28s pod/shipping-7f7999ffb7-95rlc 1/1 قيد التشغيل 0 5m27s pod/user-68df64db9c-kh247 1/1 قيد التشغيل 0 5m27s pod/user-db-6df7444fc-jlkp9 1/1 قيد التشغيل 0 5m27s الاسم النوع CLUSTER-IP EXTERNAL-IP المنافذ العمر service/carts ClusterIP 172.20.33.124 80/TCP 5m29s service/carts-db ClusterIP 172.20.75.163 27017/TCP 5m29s service/catalogue ClusterIP 172.20.92.254 80/TCP 5m29s service/catalogue-db ClusterIP 172.20.242.255 3306/خدمة TCP 5m29s/موازن التحميل الأمامي 172.20.55.188 k8s-sockshop-frontend-12345678910-012345678910abc.elb.us-east-1.amazonaws.com 80:30001/خدمة TCP 5m29s/طلبات ClusterIP 172.20.8.252 80/TCP 5m29s service/orders-db ClusterIP 172.20.40.212 27017/TCP 5m29s خدمة/دفع ClusterIP 172.20.6.218 80/TCP 5m29s service/queue-master ClusterIP 172.20.153.80 خدمة 80/TCP 5m29s/rabbitmq ClusterIP 172.20.99.37 5672/TCP،9090/TCP 5m29s service/session-db ClusterIP 172.20.37.111 6379/TCP 5m29s خدمة/شحن ClusterIP 172.20.43.252 80/TCP 5m29s خدمة/مستخدم ClusterIP 172.20.220.174 80/TCP 5m29s service/user-db ClusterIP 172.20.70.57 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 إلى الكود المصدري لمشروع الواجهة الأمامية:

الإصدار: 0.2 المراحل: ما قبل البناء: الأوامر: - صدى تسجيل الدخول إلى Amazon ECR... - aws --version - AWS_ACCOUNT_ID=`echo $REPOSITORY_URI|cut -d"." -f1` - AWS_DEFAULT_REGION=`echo $REPOSITORY_URI|cut -d"." -f4` - صدى $AWS_ACCOUNT_ID $AWS_DEFAULT_REGION - aws ecr get-login-password --region $AWS_DEFAULT_REGION | $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 began on `date` - echo Building the Docker image... - docker build -t $REPOSITORY_URI:latest. - علامة docker $REPOSITORY_URI:latest $REPOSITORY_URI:$IMAGE_TAG post_build: الأوامر: - echo تم الانتهاء من البناء في `date` - echo دفع صور Docker... - 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 الخاص بك).

إصدار واجهة برمجة التطبيقات: kustomize.config.k8s.io/v1beta1 النوع: موارد التخصيص: - ../../base الصور: - الاسم: weaveworksdemos/front-end الاسم الجديد: __ACCOUNT_ID__.dkr.ecr.us-west-2.amazonaws.com/weaveworksdemos/front-end # {"$imagepolicy": "sock-shop:sock-shop-front-end:name"} علامة جديدة: أحدث # {"$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 الخاص بك.

--- إصدار واجهة برمجة التطبيقات: image.toolkit.fluxcd.io/v1beta1 النوع: ImageRepository البيانات الوصفية: الاسم: sock-shop-front-end مساحة الاسم: sock-shop المواصفات: الصورة: __ACCOUNT_ID__.dkr.ecr.xxxx.amazonaws.com/weaveworksdemos/front-end الفاصل الزمني: 1m0s

4.2.3 تكوين بيانات اعتماد الوصول لـ Amazon ECR

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

• آلية المصادقة التلقائية (تستعيد Image Reflector Controller بيانات الاعتماد من تلقاء نفسها، فقط لـ: Amazon ECR، وGCP GCR، وAzure ACR)
• استرداد بيانات الاعتماد بشكل منتظم (المخزنة في المجموعة عبر Secret) باستخدام CronJob

إصدار واجهة برمجة التطبيقات: kustomize.config.k8s.io/v1beta1 النوع: التخصيص الموارد: - gotk-components.yaml - gotk-sync.yaml التصحيحات: - التصحيح: |- - العملية: إضافة المسار: /spec/template/spec/containers/0/args/- القيمة: --aws-autologin-for-ecr الهدف: الإصدار: v1 المجموعة: التطبيقات النوع: اسم النشر: وحدة تحكم عاكس الصورة المساحة: نظام التدفق

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 النوع: ImagePolicy البيانات الوصفية: الاسم: sock-shop-front-end المواصفات: imageRepositoryRef: الاسم: sock-shop-front-end الوسوم: النمط: '^main-[a-fA-F0-9]+-(?P .*)' استخراج: '$buidnumber' السياسة: عددية: الترتيب: تصاعدي

أضف الملف gitops/apps/overlays/development/sock-shop/image-automation.yaml. يُحدد Flux Image Automation مستودع Git لتكوين التطبيق، بما في ذلك الفرع والمسار ومعلومات أخرى.

--- إصدار واجهة برمجة التطبيقات: image.toolkit.fluxcd.io/v1beta1 النوع: ImageUpdateAutomation البيانات الوصفية: الاسم: sock-shop-front-end المواصفات: git: الخروج: المرجع: الفرع: الرئيسي الالتزام: المؤلف: البريد الإلكتروني: [email protected] الاسم: fluxcdbot قالب الرسالة: '{{range .Updated.Images}}{{println .}}{{end}}' الدفع: الفرع: الرئيسي الفاصل الزمني: 5m0s مرجع المصدر: النوع: Git اسم المستودع: sock-shop-tenant مساحة الاسم: sock-shop التحديث: المسار: ./deploy/kubernetes/overlays/development الاستراتيجية: المحددات

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 تم إجراء فحص ناجح، تم العثور على 20 علامة NAMESPACE NAME LATEST IMAGE READY MESSAGE sock-shop imagepolicy/sock-shop-front-end 267314483271.dkr.ecr.us-west-2.amazonaws.com/weaveworksdemos/front-end:master-1f49071-24 True تم حل أحدث علامة صورة لـ '267314483271.dkr.ecr.us-west-2.amazonaws.com/weaveworksdemos/front-end' إلى: master-1f49071-24 اسم مساحة الاسم آخر تشغيل مُعلّق جاهز الرسالة sock-shop imageupdateautomation/sock-shop-front-end 2022-09-18T14:43:51Z خطأ صحيح لم يتم إجراء أي تحديثات؛ آخر التزام 1ff6d91 في 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 صورة: صورة: 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.