GitOps عند الحافة
في السنوات القليلة الماضية، شهدنا اعتماد المزيد من المؤسسات لإطار العمل GitOps، وهو نموذج عمليات تطوير يستخدم Git كمستودع.
ظهر GitOps منذ عدة سنوات، لكنه أصبح أكثر شيوعًا مؤخرًا نتيجةً للحاويات والتعقيدات المرتبطة بالنشر والإدارة المتسقة لبيئات تشغيل الحاويات.
ما المشكلة التي يحاول GitOps حلها؟ حسنًا، إنه يعمل على أتمتة عمليات البرمجيات حتى تتمكن المؤسسات من التحسن في هندسة البرمجيات. ويُتيح لفرق التطبيقات الإصدار بشكل أكثر تكرارًا وتشغيل تطبيقات السحابة الأصلية بشكل أكثر فعالية.
سيستعرض هذا المقال إذا ما كان يمكن تطبيق GitOps على هياكل حوسبة الحافة، خاصةً عند إنشاء مسارات CI/CD التي يمكنها نشر التطبيقات على أجهزة الحافة البعيدة. للتكرار، الحافة تشمل الأجهزة بعيدة الحافة وصولًا إلى السحابة، مع حافة المؤسسة وحافة الشبكة على طول الطريق.
GitOps هو ممارسة عمليات تطوير تستخدم Git كمصدر وحيد للحقائق، حيث يتم تخزين حالة التخزين المطلوبة. يكون التركيز على أتمتة العمليات، انطلاقًا من مستودعات Git. على الرغم من أن اسمه في العنوان، فإن Git ليس المستودع الوحيد الذي يمكن استخدامه. إن الواجهات التي يوفرها Git هي التي تعمل على أتمتة العمليات. يستخدم GitOps في النهاية المعلومات المستخلصة من بيانات البناء لتحديد الحِزَم التي يجب إنشاؤها عند حدوث تغيير معين في التعليمات البرمجية.
في جوهره، يعتمد نموذج GitOps على نمط وحدة التحكم (Controller Pattern). ويتعزز ذلك أيضًا من خلال نمط وحدة التشغيل (Operator Pattern) في سياق Kubernetes أو OpenShift، حيث تُعَد وحدات التشغيل امتدادات برمجية تستخدم الموارد المخصصة لإدارة التطبيقات وعناصرها.
سيكون من الخطأ عدم ذكر Argo CD، وهي أداة GitOps التي تساعد على سير عمل GitOps. تُعَد Argo CD أداة إعلانية مفتوحة المصدر للتكامل المستمر والنشر المستمر (CI/CD) للتطبيقات. عند تنفيذها كوحدة تحكم في Kubernetes، تراقب Argo CD تعريفات التطبيقات والتكوينات الجارية باستمرار، وتقارن الحالة الحالية على المجموعة بالحالة المطلوبة المحددة في مستودع Git.
لكن GitOps ليس منتجًا واحدًا أو مكونًا إضافيًا أو منصة. تساعد مهام سير عمل GitOps الفِرَق على إدارة البنية التحتية لتكنولوجيا المعلومات من خلال العمليات التي يستخدمونها بالفعل في تطوير التطبيقات. للاقتباس من مدونة GitLab، يتطلب GitOps ثلاثة عناصر أساسية: GitOps = البنية التحتية ككود (IaC) + طلبات السحب أو الدمج (PRs أو MRs) + التكامل/النشر المستمر (CI/CD).
- IaC: البنية التحتية ككود هي ممارسة تخزين جميع إعدادات البنية التحتية على شكل كود. يستخدم GitOps مستودع Git كمصدر واحد للحقيقة لتعريفات البنية التحتية. يتتَبَّع Git جميع تغييرات إدارة الكود.
- PRs أو MRs: يستخدم GitOps طلبات السحب (PRs) أو طلبات الدمج (MRs) كآلية تغيير لإجراء جميع تحديثات البنية التحتية. هنا يمكن للفرق التعاون من خلال التقييمات والتعليقات، وحيث تتم الموافقات الرسمية.
- CI/CD: يعمل GitOps على أتمتة تحديثات البنية التحتية باستخدام سير عمل Git مع التكامل المستمر (CI) والنشر المستمر (CD). عند دمج التعليمات البرمجية الجديدة، يفعِّل مسار CI/CD التغيير في البيئة. أي انحراف في التكوين، مثل التغييرات اليدوية أو الأخطاء، يتم تجاوزه بواسطة أتمتة GitOps لتصبح البيئة متوافقة مع الحالة المطلوبة المحددة في Git، ما يوفر عمليات مستمرة (CO).
تعمل وحدات تشغيل Red Hat OpenShift على تبسيط التثبيت والتنسيق الآلي لأعباء العمل المعقدة. فهي تساعد على ترميز المنطق التشغيلي البشري لإدارة الخدمات التي تعمل كتطبيقات أصلية في Kubernetes، ما يسهِّل عمليات اليوم الثاني. تُعَد وحدة التشغيل جزءًا من برنامج يعمل في حجيرات على المجموعة، ويتفاعل مع خادم Kubernetes API. وحدة تشغيل OpenShift هي في الأساس وحدة تحكُّم مخصصة ويمكن أن تكون في الواقع وحدة تحكُّم خاصة بالتطبيق.
يسهّل Red Hat OpenShift الأمر على المطورين الذين يريدون استخدام GitOps من خلال توفير وحدات التشغيل اللازمة. بمجرد نشرها، يمكن عرضها ضمن قسم Installed Operators في OpenShift Console. وحدة تشغيل Red Hat OpenShift GitOps هي وحدة التشغيل الأساسية لأداة ArgoCD، أما وحدة تشغيل مسارات Red Hat OpenShift، التي يتم نشرها أيضًا، فهي وحدة التشغيل الأساسية لـ Tekton. انظر الشكل 3:
يمكن بعد ذلك استخدام وحدات التشغيل وواجهات برمجة التطبيقات المرتبطة بها لتشغيل واحد أو أكثر من مسارات GitOps التي يمكنها النشر في بيئات مختلفة مع سحب الحالة المطلوبة للتكوين من Git. قد تكون هذه البيئات التطويرية والاختبارية والإنتاجية المعتادة، أو تمتد لتشمل بيئات جغرافية مثل السحابة المؤسسية أو شبكة شركات الاتصالات أو عقد حوسبة الحافة.
يتم تصنيف موارد النشر إلى ثلاثة مجالات: البنية التحتية والخدمات والتطبيقات. تسهِّل هذه المجالات فصل وإدارة نشر الموارد ذات الصلة:
- البنية التحتية هي المكان الذي يتم فيه تحديد مساحات الأسماء ووحدات التخزين المطلوبة.
- الخدمات هي المكان الذي يتم فيه وصف مختلَف وحدات التشغيل اللازمة لإعداد المثيلات.
- التطبيقات هي المكان الذي يتم فيه تعداد التطبيقات التي سيتم ينشرها.
في مدونة سابقة، ناقشنا عمليات التطوير في مجال حوسبة الحافة؛ وهنا، نلقي نظرة على كيفية تطبيق GitOps في حوسبة الحافة. لقد أشرنا إلى الحواف الثلاث في حوسبة الحافة:
- حافة المؤسسة
- حافة الشبكة
- حافة الجهاز (أو الحافة البعيدة)
هناك أيضًا السحابة أو مركز بيانات المؤسسة. دعنا نلقِ نظرة متعمقة على هذه المجالات. إلى جانب بيئات الحافة، يصوِّر الشكل 4 أيضًا مجالات GitOps الثلاثة: البنية التحتية والخدمات والتطبيق.
السحابة / مركز بيانات المؤسسة
تشهد حوسبة الحافة انتشارًا لمجموعات OpenShift أو Kubernetes في معظم مراكز تكنولوجيا المعلومات. ولديها القدرة على الوصول إلى نطاق هائل من المئات إلى الآلاف من عمليات النشر لكل عميل. والنتيجة هي أن أقسام تكنولوجيا المعلومات في المؤسسات يجب أن تُدير عدة مجموعات تشغيل حاويات مستقلة أو متعاونة تعمل في البيئات المحلية و/أو على السحب العامة.
يُعَد ضمان أن تكون المجموعات في الحالة المطلوبة نفسها-سواء عند نشر تغيير أم التراجع عنه عبر سحابات متعددة- هو إحدى الفوائد الرئيسية التي يقدمها GitOps للشركات المعتمدة على حوسبة الحافة وإنترنت الأشياء.
حافة الشبكة
يمكن تطبيق نموذج GitOps عند حافة الشبكة، إذ إن أحد التحديات الرئيسية التي تواجه مزودي خدمات الاتصالات (CSPs) هو البحث عن تنسيق شبكاتهم وأتمتتها وإدارتها. بينما تُعَد تقنية الجيل الخامس (5G) ميزة للمستهلكين، فقد أدَّى كلٌّ من الشبكات المعرَّفة بالبرمجيات (SDNs) وتقسيم الشبكة بعرض نطاق مختلف والنشر الأسرع إلى ظهور تحديات لمزوِّدي خدمات الاتصالات.
يُعَد مسار النشر المؤتمت إحدى الطرق التي يمكن لمزوِّدي خدمات الاتصالات من خلالها تقديم الخدمات للعملاء بشكل أسرع. ووجود مستودع مركزي ونهج إعلاني لتوفير البنية التحتية للحاويات يعني وقتًا أسرع لتسويق الميزات الجديدة وطلبات التغيير. سيساعد مثل هذا النموذج على توفير وظائف الشبكة الافتراضية (VNFs) ووظائف الشبكة السحابية الأصلية (CNFs) على حافة الشبكة. يُتيح النقل بالحاويات لعناصر الشبكة إدارة مثل هذه الوظائف. أخيرًا، نظرًا لأن جميع أنشطة التكوين يتم تسجيلها وتخزينها في Git، فإن القدرة على تتبُّع التغييرات تُعَد أمرًا ضروريًا لأغراض الامتثال والتدقيق. هناك بعض المدونات ذات الصلة من WeaveWorks مذكورة في المراجع:
حافة المؤسسة
يتيح GitOps للمؤسسات النشر إلى أهداف متعددة في وقت واحد. ويسمح بطرح عمليات النشر الدقيقة. سيكون هذا مفيدًا للغاية عند نشر التطبيقات على المئات أو عشرات الآلاف من عقد الحافة، والتي تأتي بأشكال ومواصفات مختلفة وتستخدم بروتوكولات اتصال متنوعة - خاصةً إذا كانت عقد الحافة عبارة عن مجموعات طرفية صغيرة تستخدم Intel NUC أو NVIDIA Jetson.
يمكن أن يكون إطار العمل GitOps مفيدًا في نشر التطبيقات واستخدام مستودع Git كمصدر واحد للحقيقة. تبحث فرق عمليات تكنولوجيا المعلومات (ITOps)عن نشر التطبيقات وإدارتها وتشغيلها بشكل مستقل على عُقد الحافة، ويسهِّل ذلك استخدام وحدات التشغيل Red Hat OpenShift.
حافة الجهاز (أو الحافة البعيدة)
إن فائدة GitOps واضحة عند حافة الشبكة وحافة المؤسسة. تمثِّل أجهزة الحافة تحديًا مختلفًا؛ لأن سعة التخزين والحوسبة في بعض هذه الأجهزة لا تكفي لاستضافة خدمات GitOps وتشغيل التطبيقات.
تم إصدار توزيعات Kubernetes خفيفة الوزن، مثل K3s وK0s، لتلبية احتياجات حالات استخدام إنترنت الأشياء وحوسبة الحافة. تُتيح لنا القدرة على نشر توزيع Kubernetes خفيف الوزن على جهاز حافة تشغيل أداة GitOps مثل Argo CD. ستكون الأجهزة بعد ذلك قادرة على اعتماد نموذج السحب لاستطلاع مستودع Git للحالة المطلوبة ومزامنته مع الحالة المباشرة للمجموعة.
باستخدام GitOps، يمكنك حل مشكلات البنية التحتية وانتشار تكوين التطبيقات. تسهِّل وحدة تشغيل GitOps المدمجة في Red Hat OpenShift تنفيذ المسار الذي يعمل بواسطة Argo CD. يمكن لعملاء IBM Cloud Paks، بما في ذلك IBM Cloud Pak for Network Automation، الاستفادة من وحدات تشغيل Red Hat لتثبيت الموارد واستخدام إطار عمل GitOps لأتمتة عملية النشر والتحكم فيها.
تُعد مجموعة أدوات IBM Cloud Native Toolkit نقطة بداية رائعة. وهي مجموعة مفتوحة المصدر من الأصول التي تُتيح تطوير التطبيقات ونشر العمليات.
شكر خاص لكلٍّ من Hollis Chui وKavitha Bade لمراجعة المقال.