🥇مقدمة إلى GitOps لـ OpenShift

سنتحدث اليوم عن مبادئ ونماذج GitOps، وكذلك كيفية تنفيذ هذه النماذج على منصة OpenShift. يتوفر دليل تفاعلي حول هذا الموضوع رابط.

باختصار، GitOps عبارة عن مجموعة من الممارسات لاستخدام طلبات سحب Git لإدارة تكوينات البنية التحتية والتطبيقات. يتم التعامل مع مستودع Git في GitOps كمصدر واحد للمعلومات حول حالة النظام، وأي تغييرات على هذه الحالة يمكن تتبعها وتدقيقها بالكامل.

إن فكرة تتبع التغيير في GitOps ليست جديدة بأي حال من الأحوال، فقد تم استخدام هذا النهج منذ فترة طويلة بشكل شبه عالمي عند العمل مع الكود المصدري للتطبيق. يقوم GitOps ببساطة بتنفيذ ميزات مماثلة (المراجعات وطلبات السحب والعلامات وما إلى ذلك) في البنية التحتية وإدارة تكوين التطبيقات ويوفر فوائد مماثلة كما في حالة إدارة التعليمات البرمجية المصدر.

لا يوجد تعريف أكاديمي أو مجموعة قواعد معتمدة لـ GitOps، فقط مجموعة من المبادئ التي بنيت عليها هذه الممارسة:

يتم تخزين الوصف التعريفي للنظام في مستودع Git (التكوينات والمراقبة وما إلى ذلك).
يتم إجراء تغييرات الحالة من خلال طلبات السحب.
تتم مطابقة حالة الأنظمة قيد التشغيل مع البيانات الموجودة في المستودع باستخدام طلبات Git Push.

مبادئ GitOps

يتم وصف تعريفات النظام على أنها كود المصدر

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

يتم تعيين الحالة والتكوين المطلوبين للأنظمة وإصدارها في Git

من خلال تخزين الحالة المرغوبة للأنظمة وإصدارها في Git، يمكننا بسهولة نشر التغييرات وإعادتها إلى الأنظمة والتطبيقات. يمكننا أيضًا استخدام آليات أمان Git للتحكم في ملكية الكود والتحقق من صحته.

يمكن تطبيق تغييرات التكوين تلقائيًا عبر طلبات السحب

باستخدام طلبات سحب Git، يمكننا التحكم بسهولة في كيفية تطبيق التغييرات على التكوينات في المستودع. على سبيل المثال، يمكن إعطاؤها لأعضاء الفريق الآخرين للمراجعة أو إجراؤها من خلال اختبارات CI، وما إلى ذلك.

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

إصلاح مشكلة الانجراف غير المنضبط للتكوينات

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

نماذج GitOps لـ OpenShift

مُصالح الموارد على مستوى المجموعة

وفقًا لهذا النموذج، تحتوي المجموعة على وحدة تحكم مسؤولة عن مقارنة موارد Kubernetes (ملفات YAML) في مستودع Git مع الموارد الحقيقية للمجموعة. إذا تم اكتشاف تناقضات، ترسل وحدة التحكم إشعارات وربما تتخذ إجراءً لتصحيح التناقضات. يتم استخدام نموذج GitOps هذا في Anthos Config Management وWeaveworks Flux.

مُصالح الموارد الخارجية (الدفع)

يمكن اعتبار هذا النموذج بمثابة اختلاف عن النموذج السابق، عندما يكون لدينا وحدة تحكم واحدة أو أكثر مسؤولة عن مزامنة الموارد في أزواج "مستودع Git - مجموعة Kubernetes". الفرق هنا هو أن كل مجموعة مُدارة لا تحتوي بالضرورة على وحدة تحكم منفصلة خاصة بها. غالبًا ما يتم تعريف أزواج مجموعات Git - k8s على أنها CRDs (تعريفات الموارد المخصصة)، والتي يمكن أن تصف كيفية إجراء وحدة التحكم للمزامنة. ضمن هذا النموذج، تقوم وحدات التحكم بمقارنة مستودع Git المحدد في CRD مع موارد مجموعة Kubernetes، والتي تم تحديدها أيضًا في CRD، وتنفيذ الإجراءات المناسبة بناءً على نتائج المقارنة. على وجه الخصوص، يتم استخدام نموذج GitOps هذا في ArgoCD.

GitOps على منصة OpenShift

إدارة البنية التحتية Kubernetes متعددة المجموعات

مع انتشار Kubernetes والشعبية المتزايدة لاستراتيجيات السحابة المتعددة والحوسبة المتطورة، يتزايد أيضًا متوسط عدد مجموعات OpenShift لكل عميل.

على سبيل المثال، عند استخدام حوسبة الحافة، يمكن نشر مجموعات عميل واحد بالمئات أو حتى الآلاف. ونتيجة لذلك، فهو مجبر على إدارة العديد من مجموعات OpenShift المستقلة أو المنسقة في السحابة العامة وفي مكان العمل.

في هذه الحالة، يجب حل الكثير من المشاكل، على وجه الخصوص:

التحكم في أن المجموعات في حالة متطابقة (التكوينات، والمراقبة، والتخزين، وما إلى ذلك)
إعادة إنشاء (أو استعادة) المجموعات بناءً على حالة معروفة.
إنشاء مجموعات جديدة بناءً على حالة معروفة.
قم بطرح التغييرات على مجموعات OpenShift المتعددة.
استرجاع التغييرات عبر مجموعات OpenShift المتعددة.
ربط التكوينات القالبة ببيئات مختلفة.

تكوينات التطبيق

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

في هذه الحالة، يجب حل المهام التالية:

تأكد من حركة التطبيقات (الثنائيات، والتكوينات، وما إلى ذلك) بين المجموعات (المطور، والمرحلة، وما إلى ذلك).
قم بنشر التغييرات على التطبيقات (الثنائيات، والتكوينات، وما إلى ذلك) في العديد من مجموعات OpenShift.
استرجاع التغييرات التي تم إجراؤها على التطبيقات إلى حالة معروفة سابقة.

حالات استخدام OpenShift GitOps

1. تطبيق التغييرات من مستودع Git

يمكن لمسؤول المجموعة تخزين تكوينات مجموعة OpenShift في مستودع Git وتطبيقها تلقائيًا لإنشاء مجموعات جديدة بسهولة وإحضارها إلى حالة مماثلة للحالة المعروفة المخزنة في مستودع Git.

2. التزامن مع المدير السري

سيستفيد المسؤول أيضًا من القدرة على مزامنة كائنات OpenShift السرية مع البرامج المناسبة مثل Vault لإدارتها باستخدام الأدوات التي تم إنشاؤها خصيصًا لهذا الغرض.

3. التحكم في تكوينات الانجراف

سيكون المشرف مؤيدًا فقط إذا قام OpenShift GitOps نفسه بتحديد التناقضات بين التكوينات الحقيقية وتلك المحددة في المستودع والتحذير منها، حتى يتمكنوا من الاستجابة بسرعة للانجراف.

4. الإخطارات حول الانجراف التكوين

إنها مفيدة في الحالة التي يريد فيها المسؤول التعرف بسرعة على حالات انحراف التكوين من أجل اتخاذ الإجراءات المناسبة بسرعة بنفسه.

5. المزامنة اليدوية للتكوينات عند الانجراف

يسمح للمسؤول بمزامنة مجموعة OpenShift مع مستودع Git في حالة انحراف التكوين، لإعادة المجموعة بسرعة إلى حالة معروفة سابقة.

6. المزامنة التلقائية للتكوينات عند الانجراف

يمكن للمسؤول أيضًا تكوين مجموعة OpenShift للمزامنة تلقائيًا مع المستودع عند اكتشاف الانجراف، بحيث يتطابق تكوين المجموعة دائمًا مع التكوينات في Git.

7. عدة مجموعات - مستودع واحد

يمكن للمسؤول تخزين تكوينات العديد من مجموعات OpenShift المختلفة في مستودع Git واحد وتطبيقها بشكل انتقائي حسب الحاجة.

8. التسلسل الهرمي لتكوينات المجموعة (الميراث)

يمكن للمسؤول تعيين تسلسل هرمي لتكوينات المجموعة في المستودع (المرحلة، المنتج، محفظة التطبيقات، وما إلى ذلك مع الوراثة). بمعنى آخر، يمكن تحديد ما إذا كان يجب تطبيق التكوينات على مجموعة واحدة أو أكثر.

على سبيل المثال، إذا قام المسؤول بتعريف التسلسل الهرمي "مجموعات الإنتاج (المنتج) → مجموعات النظام X → مجموعات الإنتاج للنظام X" في مستودع Git، فسيتم تطبيق مجموعة من التكوينات التالية على مجموعات الإنتاج للنظام X:

التكوينات المشتركة بين كافة مجموعات الإنتاج.
التكوينات لمجموعة System X.
تكوينات مجموعة إنتاج النظام X.

9. تجاوزات القوالب والتكوين

يمكن للمسؤول تجاوز مجموعة من التكوينات الموروثة وقيمها، على سبيل المثال، لضبط التكوين لمجموعات محددة سيتم تطبيقها عليها.

10. تضمين واستبعاد انتقائي للتكوينات وتكوينات التطبيق

يمكن للمسؤول تحديد شروط تطبيق أو عدم تطبيق تكوينات معينة على مجموعات ذات خصائص معينة.

11. دعم القالب

سيستفيد المطورون من القدرة على اختيار كيفية تحديد موارد التطبيق (Helm Chart، Kubernetes yaml الخالص، وما إلى ذلك) من أجل استخدام التنسيق الأكثر ملاءمة لكل تطبيق محدد.

أدوات GitOps على منصة OpenShift

أرجوكسد

يطبق 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 Server

# 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. للقيام بذلك، سنقوم أولاً بنشر تطبيق 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. يمكن أن يكون هذا هو نفس المستودع الخاص برمز التطبيق، أو مستودعًا منفصلاً تم إنشاؤه خصيصًا لعمليات النشر. يوصى بالحصول على أذونات صارمة في المستودع حيث سيتم تخزين الأسرار والمسارات والأشياء الأخرى الحساسة للأمان هناك.

في مثالنا، سنقوم بإنشاء مستودع عام جديد على GitHub. يمكنك تسميتها كما تريد، فنحن نستخدم اسم blogpost.

إذا لم يتم تخزين ملفات كائن YAML محليًا أو في Git، فسيتعين عليك استخدام ثنائيات oc أو kubectl. في لقطة الشاشة أدناه نطلب YAML لمساحة الاسم والنشر والخدمة والمسار. قبل ذلك، قمنا باستنساخ المستودع الذي تم إنشاؤه حديثًا والقرص المضغوط فيه.

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

لنقم الآن بتحرير ملف Deployment.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 المستودع الذي أنشأناه، والذي يحتوي على رمز التطبيق من مثالنا. فقط تأكد من تحديد المستودع الدقيق الذي قمت بإنشائه مسبقًا.

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 على تطبيقنا، يجب أن نرى أن حالة التطبيق قد تغيرت إلى صحي أو متزامن. وهذا يعني أن جميع الموارد الموجودة في مستودع 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 في البداية بأي شكل من الأشكال.

المصدر: www.habr.com

مقدمة إلى GitOps لـ OpenShift