GitOps: كلمة طنانة أخرى أم طفرة في الأتمتة؟

يلاحظ معظمنا مصطلحًا جديدًا آخر في عالم مدونات أو مؤتمرات تكنولوجيا المعلومات، عاجلاً أم آجلاً يطرح سؤالاً مماثلاً: "ما هذا؟" مجرد كلمة طنانة أخرى، أو "كلمة طنانة" أو شيء يستحق حقًا الاهتمام الدقيق والدراسة والوعد بآفاق جديدة؟ نفس الشيء حدث لي مع هذا المصطلح جيت أوبس قبل حين. مسلح بالعديد من المقالات الموجودة، بالإضافة إلى معرفة الزملاء من الشركة GitLab، حاولت معرفة نوع هذا الوحش، وكيف قد يبدو استخدامه عمليًا.

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

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

لقد استوفت الخدمات السحابية هذه المتطلبات بنجاح كبير وكانت هي التي أعطت زخمًا كبيرًا لتطوير هذا النهج IAC. هذا أمر مفهوم. ففي نهاية المطاف، جعلوا من الممكن تكوين مركز بيانات افتراضي بالكامل: فلا توجد خوادم فعلية، أو رفوف، أو مكونات الشبكة؛ ويمكن وصف البنية التحتية بالكامل باستخدام البرامج النصية وملفات التكوين.

إذن ما هو الفرق بالضبط؟ جيت أوبس من IAC؟ بهذا السؤال بدأت تحقيقي. وبعد التحدث مع زملائي، تمكنت من التوصل إلى المقارنة التالية:

جيت أوبس

IAC

يتم تخزين جميع التعليمات البرمجية في مستودع git

إصدار التعليمات البرمجية اختياري

وصف الكود التصريحي / العجز

كل من الأوصاف التصريحية والحتمية مقبولة

تسري التغييرات باستخدام آليات طلب الدمج/طلب السحب

الاتفاق والموافقة والتعاون اختيارية

تتم عملية طرح التحديث تلقائيًا

عملية طرح التحديث ليست موحدة (تلقائية، يدوية، نسخ الملفات، استخدام سطر الأوامر، وما إلى ذلك)

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

ومن ناحية أخرى، أصبح من الممكن أتمتة عمليات إدارة البنية التحتية. الآن يمكن القيام بذلك بشكل أسرع وأكثر موثوقية وأرخص. علاوة على ذلك، كانت مبادئ CI / CD معروفة بالفعل وشائعة بين مطوري البرامج. كان من الضروري فقط نقل وتطبيق المعرفة والمهارات المعروفة بالفعل إلى مجال جديد. ومع ذلك، تجاوزت هذه الممارسات التعريف القياسي للبنية التحتية كرمز، ومن هنا جاء هذا المفهوم جيت أوبس.

فضول جيت أوبسبالطبع، أيضًا في حقيقة أنه ليس منتجًا أو مكونًا إضافيًا أو نظامًا أساسيًا مرتبطًا بأي بائع. إنه نموذج ومجموعة من المبادئ، يشبه مصطلحًا آخر نعرفه: DevOps.

الشركة GitLab وقد قمنا بتطوير تعريفين لهذا المصطلح الجديد: النظري والعملي. لنبدأ بالنظري:

GitOps هي منهجية تأخذ أفضل مبادئ DevOps المستخدمة لتطوير التطبيقات، مثل التحكم في الإصدار والتعاون والتنسيق وCI/CD، وتطبيقها على تحديات أتمتة إدارة البنية التحتية.

جميع العمليات جيت أوبس أنا أعمل باستخدام الأدوات الموجودة. يتم تخزين جميع أكواد البنية التحتية في مستودع git المألوف بالفعل، وتخضع التغييرات لنفس عملية الموافقة مثل أي كود برنامج آخر، وتتم عملية الطرح تلقائيًا، مما يسمح لنا بتقليل الأخطاء البشرية وزيادة الموثوقية وإمكانية التكرار.

من الناحية العملية، وصفنا جيت أوبس على النحو التالي:

لقد ناقشنا بالفعل البنية التحتية كرمز كأحد المكونات الرئيسية لهذه الصيغة. دعونا نقدم بقية المشاركين.

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

لكن الواقع المختلط هو أيضًا وسيلة للتعاون والتفاعل والتواصل. المكان الذي يلعب فيه نظام الضوابط والتوازنات. من التعليقات البسيطة إلى الموافقات والموافقات الرسمية.

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

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

وإذا أصبحت فجأة مهتما بكيفية ظهور كل هذا في الممارسة العملية، فأنا أدعوك لإلقاء نظرة على موقعنا ماستر كلاس، حيث أخبرك خطوة بخطوة عن كيفية استخدام GitLab:

• تنفيذ المبادئ الأساسية لـ GitOps

• إنشاء وإجراء تغييرات على البنية التحتية السحابية (باستخدام Yandex Cloud كمثال)

• أتمتة الكشف عن انحراف النظام من الحالة المرغوبة باستخدام المراقبة النشطة

https://bit.ly/34tRpwZ

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