GitOps هو نهج بنية تحتية يأخذ أفضل ممارسات تطوير البرامج ويطبقها على أنظمة تكنولوجيا المعلومات. تم بناء GitOps على نموذج البنية التحتية كرمز لإنشاء نموذج بنية تحتية مؤتمت يكون تعاونيًا ويتم التحكم في الإصدار مثل التعليمات البرمجية الخاصة بك.
سيطلق فريق العمليات الحديثة خدمات جديدة بانتظام لكل عملية نشر. يجب أن تكون مثيلات الحاويات وقواعد البيانات وأجهزة الشبكة متاحة للنشر الناجح.
يعرّف GitOps الموارد التي سيتم توفيرها كملفات موجودة في مستودع Git. يسمح هذا لكل فرد في الفريق بالتحقق والمساهمة في البنية التحتية التي سيتم تكوينها. يمكنك استخدام خط أنابيب CI للتحقق من التكوين الخاص بك ودفعه أخيرًا إلى النظام الأساسي السحابي الخاص بك.
يبدو مستودع البنية التحتية في النهاية مثل مستودع البرامج إلى حد كبير. تقوم بإنشاء فرع لكل تغيير ، وتحديث ملف التكوين الخاص بك ، وإكمال المراجعة ، ثم الاندماج في الفرع الرئيسي. بعد ذلك ، ستعمل الأدوات الآلية (مثل Ansible أو Terraform) على تطبيق التغييرات على بيئتك. سير العمل هو نفس نموذج الفرع الذي تم إصداره والذي يستخدمه المطورون.
ما هو جيت؟
يشير Git in GitOps إلى نظام التحكم في إصدار Git. أصبحت Git أداة التحكم في التعليمات البرمجية المصدر المفضلة لمعظم المطورين. يحتوي على نموذج تخزين لامركزي ويؤكد على استخدام الفروع المحلية لتطوير التغييرات.
يسمح لك نظام التحكم في الإصدار بتكرار عملك بسهولة. يمكنك استخدام الفروع لمعالجة المكونات المستقلة بالتوازي قبل دمجها في الفرع الرئيسي الذي يمثل الإصدار “المُصدر” من المشروع. تدفع الرمز إلى مستودع مشترك (عادةً على خدمة مثل GitHub أو GitLab) لمشاركتها مع الآخرين.
البنية التحتية التصريحية
تكمن أكبر ميزة لـ GitOps في دورها كمصدر للحقيقة. يمكن لأي شخص فهم شكل البنية الأساسية الخاصة بك من خلال الرجوع إلى الملفات الموجودة في مستودع Git الخاص بك. سيكون لديك مجموعة من ملفات التكوين التي تحدد خصائص النظام.
عادة ما يكون ملف التكوين تصريحي في الأساس – يستخدمون المضارع لوصف النظام. أنت “تعلن” أنه يجب أن يكون هناك خمسة خوادم في البنية الخاصة بك ، بدلاً من تقديم قائمة بالأوامر لبدء الخوادم الخمسة مباشرةً. تقوم أداة التكوين الخاصة بك بتحويل بياناتك إلى سلسلة من الأوامر لدفع البنية التحتية الخاصة بك إلى الحالة المطلوبة.
هذا هو المكان الذي يأتي فيه التكامل المستمر (CI). سيقوم مطورو البرامج بتشغيل خطوط أنابيب آلية لإجراء اختبار الوحدة وإجراء تحليل ثابت ونشر أخيرًا في بيئة الإنتاج. سيقوم خط أنابيب فريق البنية التحتية النموذجي بفحص ملفات التكوين الخاصة بك بحثًا عن أخطاء في بناء الجملة قبل دفعها إلى الوكيل الذي يقوم بتطبيق التغييرات على نظامك.
القدرة على التحقق
تتيح لك القدرة على استخدام خطوط أنابيب CI لتنفيذ تغييرات البنية التحتية التحقق من أن هذه التغييرات تعمل بالفعل كما هو متوقع. يوفر GitOps أيضًا القدرة على التحقق باستمرار ، وسيقوم الوكلاء في البنية التحتية الخاصة بك بمراقبة الاختلافات باستمرار.
المستودع هو المصدر الوحيد للحقيقة. لذلك ، فإن أي اختلافات لوحظت في النظام الفعلي هي أخطاء يجب تصحيحها. إذا لم تعد الحالة الحالية تتطابق مع مطالبتك ، فيمكن للوكيل الذي لديه حق الوصول إلى المستودع والموارد المتوفرة اتخاذ خطوات لتصحيح الحالة الحالية.
يساعدك GitOps على مراقبة البنية التحتية الخاصة بك. يشرح ملف التكوين التعريفي كيف يدخل نظامك إلى حالته الحالية. يمكنك التحقق من التزامات Git الخاصة بالمستودع لفهم كيفية تطور البنية التحتية بمرور الوقت.
يمكن أن يوفر GitOps أيضًا طريقة للتراجع عن تغييرات البنية التحتية. أبسطها هو أن العودة إلى إرسال سابق سيؤدي إلى استعادة الإصدار السابق من ملف التكوين. ومع ذلك ، فإن التطبيق العملي لها يمكن أن يكون صعبًا. على الرغم من أنه يمكن استعادة الكود بمجرد الكتابة فوق النشر الحالي ، فليس من السهل “عكس” إنشاء البنية التحتية أو حذفها.
تحتاج إلى تقييم وكيل الطرح الذي تستخدمه لتحديد ما إذا كان التراجع احتمالًا واقعيًا. إذا لم تتمكن من النشر في مكانه ، فيمكنك على الأقل استعادة الالتزامات في المستودع وإعادة نشرها في بيئة نظيفة. بعد ذلك ، ستستخدم برنامج الاسترداد الخاص بك لاستعادة بياناتك.
تحديات GitOps
يعد عدم النضج أكبر عقبة أمام اعتماد GitOps. بالنسبة لفرق العمليات التي قد تكون عديمة الخبرة نسبيًا في مهام سير عمل التحكم في الإصدار ، لا يزال المصطلح غير شفاف.
تعتاد العديد من فرق البنية التحتية على ممارسات العمل التي شحذوها في العقود القليلة الماضية. يتصلون بالخادم عبر SSH ، ويقومون بإجراء التغييرات ، ويسجلونها في ويكي يتم الاحتفاظ به مركزيًا. لا يتم التحكم فيه ، لكنه بسيط وفعال.
يحل GitOps مشكلة نقص التحكم ويمكنه تحسين الرؤية في حالة النظام. في الوقت نفسه ، يتضمن منحنى التعلم تدفقات عمل منظمة ومجموعة مختلفة جدًا من الأدوات. لم يعد الوصول المباشر عبر SSH مناسبًا. بدلاً من ذلك ، يمكنك إجراء تغييرات عن طريق تحرير الملفات وانتظار تطبيق خط أنابيب CI.
عند تقديم GitOps إلى مؤسسة جديدة ، قد يكون الحصول على الدعم من الفريق ذي الصلة هو المشكلة الأكبر. كن مستعدًا لصناع القرار لإساءة فهم القيمة أو عدم إدراكها على الإطلاق. يشعر بعض الأشخاص بالإحباط لأنهم مضطرون إلى الإرسال والدمج وطلب الموافقة على التغييرات التي يمكنهم تنفيذها يدويًا باستخدام أوامر SSH السريعة. لا يزال GitOps لا يزال DevOps منذ بضع سنوات ، في انتظار اعتماد واسع النطاق خارج الأدبيات الفنية.
بالإضافة إلى المقاومة التنظيمية ، فإن GitOps لديها أيضًا نقاط ضعف عملية. التحدي المشترك هو الترويج لبيئات مختلفة متعددة. تتمثل إحدى الطرق الشائعة في تخصيص فرع خاص به لكل بيئة في المستودع. إذا كان لديك الكثير من البيئات ، فقد يصبح هذا سريعًا غير لائق. يمكن أن يعتمد نهج آخر على مستودعات متعددة ، ربما باستخدام وحدات Git الفرعية ، لكن هذا ينقل التكرار إلى مكان آخر.
لا يزال GitOps مفهومًا جديدًا ، ولا يوجد نموذج ثابت لتنفيذه. إذا لم تكن هناك بنية مرجعية ، فستحتاج إلى التجربة بشكل مستقل. هذا يضيف إلى قائمة المنظمات غير المعروفة التي تقيم قابلية تطبيق النموذج.
ذات صلة: استخدم CodeBuild و ECR و CodeDeploy لأتمتة التسليم المستمر في الحاويات
التعميم
GitOps هي طريقة لإدارة البنية التحتية لتكنولوجيا المعلومات التي تستخدم مستودعات Git كمصدر للحقيقة. تكتب ملف تكوين تعريفي لوصف الموارد التي سيتم توفيرها. يأخذ النظام الآلي هذه الملفات ويستخدمها لتحسين حالة البنية التحتية.
كمفهوم ، فإن GitOps لها معنى كبير. إنه يضيق الفجوة بين فريق التطوير وفريق العمليات من خلال سير عمل موحد. يمكنك فهم بنيتك الأساسية بشكل أفضل والقدرة على إصدار ومراجعة التغييرات.
ومع ذلك ، في كثير من الحالات ، لا يزال تنفيذ GitOps يمثل تحديًا. يتطلب دعم المنظمة ، ويقبل بعض أوجه القصور المتأصلة ، ويعد بحل المشكلات الفنية التي قد لا تتوقعها بالضرورة. يمكن للمؤسسات الملتزمة تمامًا بـ GitOps أن تتوقع رؤية قدر أكبر من الاتساق والتوحيد. ولكن بالنسبة للكثيرين الآخرين ، لا تكفي المزايا المقدمة لتحفيز تجاهل أوامر CLI في المحطة الطرفية لمسؤول النظام.
