اليوم سوف نتحدث عن مبادئ ونماذج GitOps ، وكذلك كيفية تنفيذ هذه النماذج على منصة OpenShift. دليل على الانترنت لهذا الموضوع متاح
هنا .
باختصار ، GitOps عبارة عن مجموعة من الأساليب العملية لاستخدام طلبات السحب Git لإدارة تكوينات البنية التحتية والتطبيق. يُعد مستودع Git داخل GitOps بمثابة مصدر واحد للمعلومات حول حالة النظام ، ويتم مراقبة وتدقيق أي تغييرات في هذه الحالة بشكل كامل.
ليست فكرة تغيير التعقب في GitOps جديدة بأي حال من الأحوال ؛ فقد تم استخدام هذا النهج منذ وقت طويل في كل مكان تقريبًا عند العمل باستخدام شفرة مصدر التطبيق. تنفذ GitOps ببساطة وظائف مماثلة (مراجعة الشيكات ، طلبات السحب ، العلامات ، إلخ) عند إدارة تكوينات البنية التحتية والتطبيق وتعطي مزايا مماثلة كما في حالة إدارة شفرة المصدر.
بالنسبة إلى GitOps ، لا يوجد تعريف أكاديمي أو مجموعة قواعد معتمدة ، فقط مجموعة من المبادئ التي تستند إليها هذه الممارسة:
- يتم تخزين الوصف التعريفي للنظام في مستودع Git (التكوينات ، المراقبة ، إلخ).
- يتم إجراء تغييرات الحالة من خلال طلبات السحب.
- تتوافق حالة الأنظمة قيد التشغيل مع البيانات الموجودة في المستودع باستخدام طلبات دفع Git.
مبادئ GitOps
- يتم تعريف تعريفات النظام على أنها شفرة المصدر.
يعتبر تكوين النظام رمزًا ، لذلك يمكن تخزينه وإصداره تلقائيًا في مستودع Git ، والذي يعد مصدر الحقيقة الوحيد. هذا النهج يجعل من السهل لبدء والتغييرات العودة إلى النظم.
- يتم تعيين الحالة المطلوبة وتكوين النظام وإصدارهما في Git
من خلال تخزين وإصدار الإصدار Git في الحالة المرغوبة للأنظمة ، نحصل على القدرة على استرجاع التغييرات إلى الأنظمة والتطبيقات بسهولة. يمكننا أيضًا استخدام آليات أمان Git للتحكم في ملكية الشفرة والتحقق من صحتها.
- يمكن تطبيق تغييرات التكوين تلقائيًا باستخدام طلبات السحب.
باستخدام طلبات Git pull ، يمكننا التحكم بسهولة في كيفية تطبيق التغييرات على التكوينات في المستودع. على سبيل المثال ، يمكن إرسالها للتحقق لأعضاء الفريق الآخرين أو إجراء اختبارات CI ، إلخ.
وفي الوقت نفسه ، لا تحتاج إلى منح سلطة المشرف إلى اليمين واليسار. لتنفيذ تغييرات التكوين ، يكون لدى المستخدمين أذونات كافية في مستودع Git حيث يتم تخزين هذه التكوينات.
- إصلاح غير المنضبط تكوينات الانجراف
عندما يتم تخزين الحالة المطلوبة للنظام في مستودع Git ، لا يمكننا إيجاد سوى البرامج التي تتحكم في أن الحالة الحالية للنظام تتوافق مع حالته المطلوبة. إذا لم يكن الأمر كذلك ، فينبغي لهذا البرنامج - وفقًا للإعدادات - إما إصلاح التناقض من تلقاء نفسه أو إخطارنا بانجراف التكوين.
نماذج GitOps ل OpenShift
على الكتلة الكتلة الموارد
وفقًا لهذا النموذج ، تحتوي المجموعة على وحدة تحكم مسؤولة عن مقارنة موارد Kubernetes (ملفات YAML) في مستودع Git مع موارد نظام المجموعة الحقيقية. في حالة وجود تباينات ، يرسل جهاز التحكم إخطارات ، وربما يتخذ تدابير للقضاء على التناقضات. يتم استخدام هذا النموذج GitOps بواسطة Anthos Config Management و Weaveworks Flux.
المراجع الموارد الخارجية (دفع)
يمكن اعتبار هذا النموذج تباينًا للنموذج السابق ، عندما يكون لدينا وحدة تحكم واحدة أو أكثر مسؤولة عن مزامنة الموارد في أزواج "Git repository - Kubernetes cluster". الفرق هنا هو أن كل كتلة تتم إدارتها ليس من الضروري أن يكون لها وحدة تحكم منفصلة خاصة بها. غالبًا ما يتم تعريف أزواج الكتل Git - k8s على أنها تعريف CRDs للموارد المخصصة ، والتي تصف كيفية قيام وحدة التحكم بإجراء المزامنة. ضمن هذا النموذج ، تقوم وحدات التحكم بمقارنة مستودع Git المحدد في CRD مع موارد مجموعة Kubernetes ، والتي تم تعريفها أيضًا في CRD ، وتنفيذ الإجراءات المقابلة بناءً على نتائج المقارنة. على وجه الخصوص ، يتم استخدام نموذج GitOps في ArgoCD.
GitOps على منصة OpenShift
Multicluster Kubernetes Infrastructure Management
مع انتشار Kubernetes والشعبية المتزايدة للاستراتيجيات متعددة السحابية والحوسبة المتطورة ، زاد أيضًا متوسط عدد مجموعات OpenShift لكل عميل.
على سبيل المثال ، عند استخدام الحوسبة الطرفية ، يمكن نشر مجموعات من عميل واحد بالمئات أو حتى الآلاف. نتيجة لذلك ، يضطر إلى إدارة العديد من مجموعات OpenShift المستقلة أو المنسقة في السحابة العامة والمقدمة.
في الوقت نفسه ، يجب حل الكثير من المشكلات ، على وجه الخصوص:
- للتحكم في أن الكتل في حالة مماثلة (التكوينات ، المراقبة ، التخزين ، إلخ.)
- إعادة إنشاء (أو استعادة) المجموعات وفقًا لحالة معروفة.
- إنشاء مجموعات جديدة وفقا لحالة معروفة.
- سحب التغييرات على مجموعات OpenShift متعددة.
- استرجاع التغييرات إلى مجموعات OpenShift متعددة.
- ربط التكوينات منقوشة مع بيئات مختلفة.
تكوينات التطبيق
خلال دورة حياتها ، غالبًا ما تمر التطبيقات بسلسلة من المجموعات (ديف ، المسرح ، إلخ) قبل أن تدخل في مجموعة الإنتاج. بالإضافة إلى ذلك ، نظرًا لمتطلبات التوافر وقابلية التوسع ، ينشر العملاء في كثير من الأحيان تطبيقات على مجموعات متعددة داخل المباني أو في مناطق متعددة من النظام الأساسي السحابي العام.
في هذه الحالة ، من الضروري حل المشكلات التالية:
- تأكد من حركة التطبيقات (الثنائيات ، التكوينات ، وما إلى ذلك) بين الكتل (ديف ، المرحلة ، إلخ).
- نشمر التغييرات في التطبيقات (الثنائيات ، التكوينات ، إلخ) في العديد من مجموعات OpenShift.
- استرجاع التغييرات في التطبيقات إلى مستوى الحالة المعروفة السابقة.
OpenShift GitOps سيناريوهات الاستخدام
1. تطبيق التغييرات من مستودع بوابة
يمكن لمسؤول نظام المجموعة تخزين تكوينات نظام OpenShift في مستودع Git وتطبيقها تلقائيًا لإنشاء مجموعات جديدة دون بذل أي جهد إضافي وإحضارها إلى حالة مماثلة للحالة المعروفة المخزّنة في مستودع Git.
2. مزامنة مع Secret Manager
سيجد المسؤول أيضًا أنه من المفيد مزامنة كائنات OpenShift السرية مع البرامج المناسبة مثل Vault لإدارتها باستخدام أدوات تم إنشاؤها خصيصًا لهذا الغرض.
3. التحكم في تكوينات الانجراف
لن يكون المشرف مؤيدًا إلا إذا كان OpenShift GitOps سيكتشف ويحذر من التناقضات بين التكوينات الحقيقية والتكوينات المحددة في المستودع ، بحيث يمكنك الاستجابة بسرعة للانجراف.
4. التكوين الانجراف الإخطارات
سيكون مفيدًا عندما يرغب المسؤول في التعرف بسرعة على تكوينات الانجراف من أجل اتخاذ التدابير المناسبة من تلقاء نفسه بسرعة.
5. تزامن يدوي من التكوينات عند الانجراف
للسماح للمسؤول بمزامنة نظام OpenShift مع مستودع Git في حالة تكوينات الانجراف من أجل إرجاع الكتلة بسرعة إلى حالة معروفة سابقة.
6. لصناعة السيارات في تزامن تكوينات الانجراف
يمكن للمسؤول أيضًا تكوين نظام OpenShift للمزامنة تلقائيًا مع المستودع عند اكتشاف الانجراف ، بحيث يطابق تكوين الكتلة دائمًا التكوينات في Git.
7. مجموعات متعددة - مستودع واحد
يمكن للمشرف تخزين تكوينات العديد من مجموعات OpenShift المختلفة في مستودع Git واحد وتطبيقها بشكل انتقائي حسب الحاجة.
8. التسلسل الهرمي للتكوينات العنقودية (الميراث)
يمكن للمشرف تعيين التسلسل الهرمي لتكوينات الكتلة في المستودع (المرحلة ، prod ، محفظة التطبيقات ، وما إلى ذلك مع الميراث). بمعنى آخر ، يمكنه تحديد كيفية تطبيق التكوينات - على مجموعة واحدة أو عدة مجموعات.
على سبيل المثال ، إذا كان المسؤول يحدد التسلسل الهرمي "مجموعات الإنتاج (prod) ← مجموعات النظام X → مجموعات الإنتاج للنظام X" في مستودع Git ، ثم يتم تطبيق التكوينات التالية على مجموعات الإنتاج للنظام X:
- تشويش مشترك بين كل مجموعات الإنتاج.
- Configs لنظام الكتلة X.
- Configs لمجموعة إنتاج النظام X.
9. أنماط وتجاوزات التكوين
يمكن للمسؤول تجاوز مجموعة التكوينات الموروثة وقيمها ، على سبيل المثال ، لضبط التكوين لمجموعات محددة سيتم تطبيقها عليها.
10. انتقائي include'y و exclude'y عن التكوينات ، تكوين التطبيق
يمكن للمسؤول تعيين الشروط لتطبيق أو عدم تطبيق تكوينات معينة على مجموعات ذات خصائص معينة.
11. نمط الدعم
سيجد المطورون أنه من المفيد اختيار كيفية تحديد موارد التطبيق (مخطط Helm ، Kubernetes yaml الخالص ، وما إلى ذلك) من أجل استخدام التنسيق الأنسب لكل تطبيق محدد.
أدوات GitOps على منصة OpenShift
ArgoCD
تنفذ ArgoCD نموذج التوفيق بين الموارد الخارجية وتقدم واجهة مستخدم مركزية لتنظيم العلاقات بين المجموعات ومستودعات Git بطريقة من شخص لآخر. تشمل عيوب هذا البرنامج عدم القدرة على إدارة التطبيقات بينما لا يعمل ArgoCD.
الموقع الرسميالجريان
يطبق Flux نموذج التوفيق بين الموارد على مستوى المجموعة ، ونتيجة لذلك ، لا توجد إدارة مركزية لمستودع التعريف ، وهذه نقطة ضعيفة. من ناحية أخرى ، وبسبب عدم وجود مركزية على وجه التحديد ، يتم الحفاظ على القدرة على إدارة التطبيقات حتى عند فشل مجموعة واحدة.
الموقع الرسميتثبيت ArgoCD على OpenShift
يوفر ArgoCD واجهة سطر أوامر ممتازة ووحدة تحكم ويب ، لذلك لن نفكر في Flux والبدائل الأخرى هنا.
لنشر ArgoCD على النظام الأساسي OpenShift 4 ، اتبع هذه الخطوات كمسؤول نظام مجموعة:
نشر مكونات ArgoCD على منصة OpenShift
# Create a new namespace for ArgoCD components oc create namespace argocd # Apply the ArgoCD Install Manifest oc -n argocd apply -f https://raw.githubusercontent.com/argoproj/argo-cd/v1.2.2/manifests/install.yaml # Get the ArgoCD Server password ARGOCD_SERVER_PASSWORD=$(oc -n argocd get pod -l "app.kubernetes.io/name=argocd-server" -o jsonpath='{.items[*].metadata.name}')
صقل خادم ArgoCD ليتم رؤيته بواسطة OpenShift Route
# Patch ArgoCD Server so no TLS is configured on the server (--insecure) PATCH='{"spec":{"template":{"spec":{"$setElementOrder/containers":[{"name":"argocd-server"}],"containers":[{"command":["argocd-server","--insecure","--staticassets","/shared/app"],"name":"argocd-server"}]}}}}' oc -n argocd patch deployment argocd-server -p $PATCH # Expose the ArgoCD Server using an Edge OpenShift Route so TLS is used for incoming connections oc -n argocd create route edge argocd-server --service=argocd-server --port=http --insecure-policy=Redirect
نشر ArgoCD أداة CLI
# Download the argocd binary, place it under /usr/local/bin and give it execution permissions curl -L https://github.com/argoproj/argo-cd/releases/download/v1.2.2/argocd-linux-amd64 -o /usr/local/bin/argocd chmod +x /usr/local/bin/argocd
تغيير كلمة مرور المسؤول خادم ArgoCD
# Get ArgoCD Server Route Hostname ARGOCD_ROUTE=$(oc -n argocd get route argocd-server -o jsonpath='{.spec.host}') # Login with the current admin password argocd --insecure --grpc-web login ${ARGOCD_ROUTE}:443 --username admin --password ${ARGOCD_SERVER_PASSWORD} # Update admin's password argocd --insecure --grpc-web --server ${ARGOCD_ROUTE}:443 account update-password --current-password ${ARGOCD_SERVER_PASSWORD} --new-password
بعد الانتهاء من هذه الخطوات ، يمكنك العمل مع ArgoCD Server من خلال وحدة تحكم الويب ArgoCD WebUI أو أداة سطر الأوامر ArgoCD Cli.
https://blog.openshift.com/is-it-too-late-to-integrate-gitops/GitOps - لم يحن الوقت بعد
"لقد غادر القطار" - هذا ما يقولونه حول الموقف عندما تضيع فرصة القيام بشيء ما. في حالة OpenShift ، غالبًا ما تؤدي الرغبة في البدء فورًا في استخدام هذا النظام الأساسي الجديد إلى خلق مثل هذا الموقف من خلال إدارة وصيانة الطرق وعمليات النشر وغيرها من كائنات OpenShift. لكن هل الفرصة ضائعة دائمًا؟
متابعة لسلسلة من المقالات حول
GitOps ، سنقوم اليوم بعرض كيفية تحويل تطبيق تم إنشاؤه يدويًا وموارده إلى عملية معينة حيث تتحكم مجموعة أدوات GitOps في كل شيء. للقيام بذلك ، نقوم أولاً بنشر تطبيق httpd بأيدينا. توضح لقطة الشاشة أدناه كيف نقوم بإنشاء مساحة اسم ونشر وخدمة ، ثم نكشف عن هذه الخدمة لإنشاء مسار.
oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/namespace.yaml oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/deployment.yaml oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/service.yaml oc expose svc/httpd -n simple-app
لذلك ، لدينا تطبيق تم إنشاؤه يدويا. الآن يجب أن يتم نقلها تحت سيطرة GitOps دون فقدان توافرها. باختصار ، يفعل هذا:
- إنشاء مستودع Git للرمز.
- نحن تصدير الكائنات الحالية لدينا وتحميلها في مستودع Git.
- حدد مجموعة أدوات GitOps ونشرها.
- أضف مستودعنا إلى مجموعة الأدوات هذه.
- نحدد التطبيق في مجموعة أدوات GitOps الخاصة بنا.
- قم بإجراء تشغيل تجريبي للتطبيق باستخدام مجموعة أدوات GitOps.
- نقوم بمزامنة الكائنات باستخدام مجموعة أدوات GitOps.
- نقوم بتشغيل التقليم والمزامنة التلقائية للكائنات.
كما ذكرنا في
المقالة السابقة ، فإن GitOps لديها مصدر واحد فقط للمعلومات حول كل الكائنات في مجموعة (مجموعات) Kubernetes - مستودع Git. علاوة على ذلك ، ننطلق من فرضية أن مؤسستك تستخدم بالفعل مستودع Git. يمكن أن يكون عامًا أو خاصًا ، لكن يجب أن يكون متاحًا لمجموعات Kubernetes. يمكن أن يكون نفس المستودع كما هو الحال بالنسبة لرمز التطبيق ، أو مستودع منفصل تم إنشاؤه خصيصًا للنشر. يوصى أن يكون لديك أذونات صارمة في المستودع ، حيث سيتم تخزين الكائنات السرية والطرق والأشياء الحساسة للأمان هناك.
في مثالنا ، سنقوم بإنشاء مستودع عام جديد على جيثب. يمكنك تسمية ما تشاء ، نستخدم اسم blogpost.
إذا لم يتم تخزين ملفات YAML الخاصة بالكائنات محليًا أو في Git ، فسيتعين عليك استخدام ثنائيات oc أو kubectl. في لقطة الشاشة أدناه ، نطلب YAML لمساحة الاسم والنشر والخدمة والطريق. قبل ذلك ، قمنا باستنساخ المستودع المنشأ حديثًا وانتقلنا إليه باستخدام الأمر cd.
oc get namespace simple-app -o yaml --export > namespace.yaml oc get deployment httpd -o yaml -n simple-app --export > deployment.yaml oc get service httpd -o yaml -n simple-app --export > service.yaml oc get route httpd -o yaml -n simple-app --export > route.yaml
الآن قم بإصلاح ملف publish.yaml لإزالة حقل منه لا يمكن لمزامنة Argo CD مزامنته.
sed -i '/\sgeneration: .*/d' deployment.yaml
بالإضافة إلى ذلك ، تحتاج إلى تغيير المسار. سنقوم أولاً بتعيين المتغير متعدد الأسطر ، ثم نستبدل ingress: null بمحتويات هذا المتغير.
export ROUTE=" ingress:\\ - conditions:\\ - status: 'True'\\ type: Admitted" sed -i "s/ ingress: null/$ROUTE/g" route.yaml
لذلك ، مع فرز الملفات ، يبقى حفظها في مستودع Git. بعد ذلك ، يصبح هذا المستودع المصدر الوحيد للمعلومات ، ويجب حظر أي تغييرات يدوية على الكائنات.
git commit -am 'initial commit of objects' git push origin master
علاوة على ذلك ، ننتقل من حقيقة أن ArgoCD قد تم نشره بالفعل من أجلك (كيفية القيام بذلك ، راجع المنشور السابق). لذلك ، نضيف إلى Argo CD المخزون الذي أنشأناه والذي يحتوي على رمز التطبيق من مثالنا. فقط تأكد من تحديد المستودع الدقيق الذي قمت بإنشائه مسبقًا.
argocd repo add https://github.com/cooktheryan/blogpost
الآن قم بإنشاء التطبيق. يقوم التطبيق بتعيين القيم بحيث تتعرف مجموعة أدوات GitOps على المستودع ومسارات الاستخدام ، وأي OpenShift ضروري لإدارة الكائنات ، وأي فرع محدد من المستودع مطلوب ، وما إذا كان يجب مزامنة الموارد تلقائيًا.
argocd app create --project default \ --name simple-app --repo https://github.com/cooktheryan/blogpost.git \ --path . --dest-server https://kubernetes.default.svc \ --dest-namespace simple-app --revision master --sync-policy none
بعد تحديد التطبيق في القرص المضغوط Argo ، تبدأ مجموعة الأدوات هذه في التحقق من الكائنات التي تم نشرها بالفعل للتأكد من توافقها مع التعريفات الموجودة في المستودع. في مثالنا ، يتم تعطيل المزامنة التلقائية والتنظيف ، لذلك لا تتغير العناصر بعد. يرجى ملاحظة أنه في واجهة Argo CD ، سيحصل تطبيقنا على الحالة "Out of Sync" (غير متزامنة) ، نظرًا لعدم وجود تسمية على ملصق ArgoCD.
هذا هو السبب ، عندما نبدأ التزامن في وقت لاحق ، لن يتم تنفيذ إعادة نشر الكائنات.
قم الآن بتشغيل اختبار تشغيل للتأكد من عدم وجود أخطاء في ملفاتنا.
argocd app sync simple-app --dry-run
إذا لم تكن هناك أخطاء ، فيمكنك المتابعة إلى المزامنة.
argocd app sync simple-app
بعد تشغيل الأمر argocd get في تطبيقنا ، يجب أن نرى أن حالة التطبيق قد تغيرت إلى Healthy أو Synced. هذا يعني أن جميع الموارد في مستودع Git تتوافق الآن مع تلك الموارد التي تم نشرها بالفعل.
argocd app get simple-app Name: simple-app Project: default Server: https://kubernetes.default.svc Namespace: simple-app URL: https://argocd-server-route-argocd.apps.example.com/applications/simple-app Repo: https://github.com/cooktheryan/blogpost.git Target: master Path: . Sync Policy: <none> Sync Status: Synced to master (60e1678) Health Status: Healthy ...
ولكن الآن يمكنك تشغيل المزامنة التلقائية والتنظيف لضمان عدم إنشاء أي شيء يدويًا وفي كل مرة يتم إنشاء الكائن أو تحديثه في المستودع ، سيتم تنفيذ عملية النشر.
argocd app set simple-app --sync-policy automated --auto-prune
لذلك ، قمنا بنجاح بتحويل GitOps إلى تطبيق لم يستخدم GitOps في البداية بأي طريقة.