ما هو GitOps؟

ملحوظة. ترجمة.: بعد منشور حديث مادة فيما يتعلق بطرق السحب والدفع في GitOps، رأينا اهتمامًا بهذا النموذج بشكل عام، ولكن كان هناك عدد قليل جدًا من المنشورات باللغة الروسية حول هذا الموضوع (ببساطة لا يوجد أي شيء على حبري). لذلك، يسعدنا أن نلفت انتباهكم إلى ترجمة مقال آخر - وإن كان ذلك منذ عام تقريبًا! - من شركة Weaveworks، التي صاغ رئيسها مصطلح "GitOps". يشرح النص جوهر النهج والاختلافات الرئيسية عن النهج الحالي.

منذ عام نشرنا مقدمة إلى GitOps. في ذلك الوقت، شاركنا كيف أطلق فريق Weaveworks برنامج SaaS يعتمد بالكامل على Kubernetes وقام بتطوير مجموعة من أفضل الممارسات الإرشادية للنشر والإدارة والمراقبة في بيئة سحابية أصلية.

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

وسرعان ما أدركنا أن هناك حاجة إلى وصف جديد، يقدم:

1. عدد كبير من الأمثلة والقصص؛
2. تعريف محدد لـ GitOps؛
3. مقارنة مع التسليم المستمر التقليدي.

حاولنا في هذه المقالة تغطية كل هذه المواضيع. يوفر مقدمة محدثة لـ GitOps ومنظور المطور وCI/CD. نحن نركز في المقام الأول على Kubernetes، على الرغم من إمكانية تعميم النموذج.

تعرف على GitOps

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

ينشر فريق Bob أنظمة الإنتاج في السحابة. تعمل تطبيقاتهم الأساسية على GKE، مع الاستفادة من Kubernetes على Google Cloud. بالإضافة إلى ذلك، يستخدمون أدوات البيانات والتحليلات المختلفة في عملهم.

لم تكن شركة Family Insurance تهدف إلى استخدام الحاويات، ولكنها انخرطت في حماسة Docker. وسرعان ما اكتشفت الشركة أن GKE سهلت نشر المجموعات لاختبار الميزات الجديدة وبلا جهد. تمت إضافة Jenkins لـ CI وQuay لتنظيم سجل الحاويات، وتمت كتابة البرامج النصية لـ Jenkins التي دفعت الحاويات والتكوينات الجديدة إلى GKE.

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

ثم تعلموا عن GitOps. وتبين أن هذا القرار هو بالضبط ما يحتاجون إليه للمضي قدمًا بثقة.

لقد سمعت أليس وبوب عن Git وDevOps والبنية التحتية كمسارات عمل للتعليمات البرمجية لسنوات. ما يميز GitOps هو أنه يقدم مجموعة من أفضل الممارسات - النهائية والمعيارية - لتنفيذ هذه الأفكار في سياق Kubernetes. هذا الموضوع ارتفع مرارا وتكرارا، بما في ذلك في مدونة ويفيوركس.

تقرر شركة Family Insurance تنفيذ GitOps. تمتلك الشركة الآن نموذج تشغيل آلي متوافق مع Kubernetes والجمع سرعة مع استقرارلأنهم:

• وجدت أن إنتاجية الفريق تضاعفت دون أن يصاب أحد بالجنون؛
• توقفت عن تقديم البرامج النصية. وبدلاً من ذلك، يمكنهم الآن التركيز على الميزات الجديدة وتحسين الأساليب الهندسية - على سبيل المثال، تقديم عمليات طرح كناري وتحسين الاختبار؛
• لقد قمنا بتحسين عملية النشر بحيث نادرًا ما تتعطل؛
• حصلت على فرصة لاستعادة عمليات النشر بعد فشل جزئي دون تدخل يدوي؛
• تم شراؤها مستعملةоثقة أكبر في أنظمة التسليم. اكتشفت أليس وبوب أنه بإمكانهما تقسيم الفريق إلى فرق خدمات صغيرة تعمل بالتوازي؛
• يمكنهم إجراء 30-50 تغييرًا على المشروع يوميًا من خلال جهود كل مجموعة وتجربة تقنيات جديدة؛
• من السهل جذب مطورين جدد إلى المشروع، الذين لديهم الفرصة لنشر تحديثات الإنتاج باستخدام طلبات السحب في غضون ساعات قليلة؛
• اجتياز التدقيق بسهولة في إطار SOC2 (للامتثال لمقدمي الخدمات بمتطلبات الإدارة الآمنة للبيانات؛ اقرأ المزيد، على سبيل المثال، هنا - تقريبا. ترجمة.).

ماذا حدث؟

GitOps هو شيئين:

1. النموذج التشغيلي لـ Kubernetes والسحابة الأصلية. وهو يوفر مجموعة من أفضل الممارسات لنشر المجموعات والتطبيقات الموجودة في حاويات وإدارتها ومراقبتها. تعريف أنيق في الشكل شريحة واحدة من لويس فيسيرا:
2. الطريق إلى إنشاء بيئة إدارة التطبيقات التي تركز على المطورين. نحن نطبق سير عمل Git على كل من العمليات والتطوير. يرجى ملاحظة أن هذا لا يتعلق فقط بـ Git Push، بل يتعلق أيضًا بتنظيم المجموعة الكاملة من أدوات CI/CD وUI/UX.

بضع كلمات عن جيت

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

كيف يعمل كوبيرنيتيس

في قصتنا، لجأ أليس وبوب إلى GitOps بعد العمل مع Kubernetes لفترة من الوقت. في الواقع، يرتبط GitOps ارتباطًا وثيقًا بـ Kubernetes - فهو نموذج تشغيلي للبنية التحتية والتطبيقات القائمة على Kubernetes.

ماذا يقدم Kubernetes للمستخدمين؟

فيما يلي بعض الميزات الرئيسية:

1. في نموذج Kubernetes، يمكن وصف كل شيء في شكل تصريحي.
2. يأخذ خادم Kubernetes API هذا الإعلان كمدخل ثم يحاول باستمرار إعادة المجموعة إلى الحالة الموضحة في الإعلان.
3. تعتبر الإعلانات كافية لوصف وإدارة مجموعة واسعة من أعباء العمل - "التطبيقات".
4. ونتيجة لذلك، تحدث تغييرات في التطبيق والمجموعة بسبب:
   • التغييرات في صور الحاوية؛
   • التغييرات في المواصفات التصريحية؛
   • أخطاء في البيئة - على سبيل المثال، تعطل الحاوية.

قدرات التقارب العظيمة في Kubernetes

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

• الأتمتة: توفر تحديثات Kubernetes آلية لأتمتة عملية تطبيق التغييرات بأمان وفي الوقت المناسب.
• التقارب: سيستمر Kubernetes في محاولة إجراء التحديثات حتى تنجح.
• العجز: تكرار تطبيقات التقارب يؤدي إلى نفس النتيجة .
• الحتمية: عندما تكون الموارد كافية، تعتمد حالة المجموعة المحدثة فقط على الحالة المطلوبة.

كيف يعمل جيتوبس

لقد تعلمنا ما يكفي عن Kubernetes لشرح كيفية عمل GitOps.

دعنا نعود إلى فرق الخدمات الصغيرة التابعة للتأمين على الأسرة. ماذا عليهم أن يفعلوا عادة؟ انظر إلى القائمة أدناه (إذا كانت هناك أي عناصر تبدو غريبة أو غير مألوفة، فيرجى التوقف عن الانتقاد والبقاء معنا). هذه مجرد أمثلة على سير العمل القائم على Jenkins. هناك العديد من العمليات الأخرى عند العمل باستخدام أدوات أخرى.

الشيء الرئيسي هو أننا نرى أن كل تحديث ينتهي بتغييرات في ملفات التكوين ومستودعات Git. تؤدي هذه التغييرات على Git إلى قيام "مشغل GitOps" بتحديث المجموعة:

1. عملية العمل: "بناء جنكينز - الفرع الرئيسي".
قائمة المهام:

• يقوم Jenkins بدفع الصور الموسومة إلى Quay؛
• يقوم Jenkins بدفع مخططات التكوين والقيادة إلى حاوية التخزين الرئيسية؛
• تقوم الوظيفة السحابية بنسخ التكوين والمخططات من مجموعة التخزين الرئيسية إلى مستودع Git الرئيسي؛
• يقوم مشغل GitOps بتحديث المجموعة.

2. بناء جنكينز - فرع الإصدار أو الإصلاح العاجل:

• يقوم Jenkins بدفع الصور غير المميزة إلى Quay؛
• يقوم Jenkins بدفع مخططات التكوين وHelm إلى مجموعة التخزين المرحلي؛
• تقوم وظيفة السحابة بنسخ التكوين والمخططات من مجموعة التخزين المرحلي إلى مستودع Git المرحلي؛
• يقوم مشغل GitOps بتحديث المجموعة.

3. بناء جينكينز - تطوير أو تمييز الفرع:

• يقوم Jenkins بدفع الصور غير المميزة إلى Quay؛
• يقوم Jenkins بدفع مخططات التكوين وHelm إلى مجموعة تخزين التطوير؛
• تقوم وظيفة السحابة بنسخ التكوين والمخططات من مجموعة تخزين التطوير إلى مستودع تطوير Git؛
• يقوم مشغل GitOps بتحديث المجموعة.

4. إضافة عميل جديد:

• يقوم المدير أو المسؤول (LCM/ops) باستدعاء Gradle لنشر وتكوين موازنات تحميل الشبكة (NLBs) في البداية؛
• ينفذ LCM/ops تكوينًا جديدًا لإعداد النشر للتحديثات؛
• يقوم مشغل GitOps بتحديث المجموعة.

وصف موجز لـGitOps

1. قم بوصف الحالة المرغوبة للنظام بأكمله باستخدام المواصفات التصريحية لكل بيئة (في قصتنا، يحدد فريق بوب تكوين النظام بالكامل في Git).
   • مستودع Git هو المصدر الوحيد للحقيقة فيما يتعلق بالحالة المرغوبة للنظام بأكمله.
   • يتم إجراء كافة التغييرات على الحالة المطلوبة من خلال الالتزامات في Git.
   • جميع معلمات المجموعة المطلوبة يمكن ملاحظتها أيضًا في المجموعة نفسها. وبهذه الطريقة يمكننا تحديد ما إذا كانت متطابقة (تتقارب، CONVERGES) أو تختلف (تتباعد، تباعد) الحالات المرغوبة والمرصودة.
2. إذا اختلفت الحالات المرغوبة والمرصودة، فإن:
   • هناك آلية تقارب تعمل تلقائيًا عاجلاً أم آجلاً على مزامنة الحالة المستهدفة والحالة المرصودة. داخل المجموعة، يقوم Kubernetes بذلك.
   • تبدأ العملية على الفور مع تنبيه "تم الالتزام بالتغيير".
   • وبعد فترة زمنية قابلة للتكوين، يمكن إرسال تنبيه "فرق" إذا كانت الحالات مختلفة.
3. بهذه الطريقة، تؤدي جميع عمليات التنفيذ في Git إلى تحديثات غير فعالة وقابلة للتحقق للمجموعة.
   • التراجع هو التقارب إلى الحالة المرغوبة مسبقًا.
4. التقارب نهائي. يتم الإشارة إلى حدوثه من خلال:
   • لا توجد تنبيهات فرق لفترة معينة من الزمن.
   • تنبيه "متقارب" (على سبيل المثال خطاف الويب، حدث إعادة كتابة Git).

ما هو الاختلاف؟

دعنا نكررها مرة أخرى: يجب أن تكون جميع خصائص المجموعة المرغوبة قابلة للملاحظة في المجموعة نفسها.

بعض الأمثلة على الاختلاف:

• تغيير في ملف التكوين بسبب دمج الفروع في Git.
• تغيير في ملف التكوين بسبب التزام Git بواسطة عميل واجهة المستخدم الرسومية.
• تغييرات متعددة على الحالة المطلوبة بسبب العلاقات العامة في Git متبوعة ببناء صورة الحاوية وتغييرات التكوين.
• تغيير في حالة المجموعة بسبب خطأ، أو تعارض في الموارد يؤدي إلى "سلوك سيء"، أو ببساطة انحراف عشوائي عن الحالة الأصلية.

ما هي آلية التقارب؟

بعض الأمثلة:

• بالنسبة للحاويات والمجموعات، يتم توفير آلية التقارب بواسطة Kubernetes.
• يمكن استخدام نفس الآلية لإدارة التطبيقات والتصميمات المستندة إلى Kubernetes (مثل Istio وKubeflow).
• آلية لإدارة التفاعل التشغيلي بين Kubernetes ومستودعات الصور وGit مشغل GitOps Weave Flux، وهو جزء نسج سحابة.
• بالنسبة للآلات الأساسية، يجب أن تكون آلية التقارب تصريحية ومستقلة. من تجربتنا الخاصة يمكننا أن نقول ذلك Terraform الأقرب إلى هذا التعريف، ولكن لا يزال يتطلب السيطرة البشرية. وبهذا المعنى، توسع GitOps تقليد البنية التحتية كرمز.

يجمع GitOps بين Git ومحرك التقارب الممتاز لـ Kubernetes لتوفير نموذج للاستغلال.

يتيح لنا GitOps أن نقول: فقط تلك الأنظمة التي يمكن وصفها ومراقبتها هي التي يمكن أتمتتها والتحكم فيها.

تم تصميم GitOps للمكدس السحابي الأصلي بأكمله (على سبيل المثال، Terraform، وما إلى ذلك)

GitOps ليس مجرد Kubernetes. نريد أن يتم قيادة النظام بأكمله بشكل تصريحي واستخدام التقارب. نعني بالنظام بأكمله مجموعة من البيئات التي تعمل مع Kubernetes - على سبيل المثال، "مجموعة التطوير 1"، "الإنتاج"، وما إلى ذلك. تتضمن كل بيئة أجهزة ومجموعات وتطبيقات بالإضافة إلى واجهات للخدمات الخارجية التي توفر البيانات والمراقبة وما إلى ذلك.

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

هناك تركيز قوي على تطبيق مفاهيم GitOps على الطبقات الموجودة أعلى Kubernetes. في الوقت الحالي، توجد حلول من نوع GitOps لـ Istio وHelm وKsonnet وOpenFaaS وKubeflow، بالإضافة إلى Pulumi، على سبيل المثال، والتي تنشئ طبقة لتطوير التطبيقات للسحابة الأصلية.

Kubernetes CI/CD: مقارنة GitOps مع الأساليب الأخرى

كما ذكرنا، GitOps عبارة عن شيئين:

1. نموذج التشغيل لـ Kubernetes والسحابة الأصلية الموصوف أعلاه.
2. الطريق إلى بيئة إدارة التطبيقات التي تركز على المطورين.

بالنسبة للكثيرين، يعد GitOps في المقام الأول سير عمل يعتمد على دفعات Git. نحن نحبه أيضًا. ولكن هذا ليس كل شيء: دعونا الآن نلقي نظرة على خطوط أنابيب CI/CD.

يتيح GitOps النشر المستمر (CD) لـ Kubernetes

يقدم GitOps آلية نشر مستمرة تلغي الحاجة إلى "أنظمة إدارة نشر" منفصلة. يقوم Kubernetes بكل العمل نيابةً عنك.

• يتطلب تحديث التطبيق التحديث في Git. يعد هذا تحديثًا للمعاملات إلى الحالة المطلوبة. يتم بعد ذلك "النشر" داخل المجموعة بواسطة Kubernetes نفسها بناءً على الوصف المحدث.
• ونظرًا لطبيعة كيفية عمل Kubernetes، فإن هذه التحديثات متقاربة. يوفر هذا آلية للنشر المستمر حيث تكون كافة التحديثات ذرية.
• ملاحظة: نسج سحابة يقدم مشغل GitOps الذي يدمج Git وKubernetes ويسمح بتنفيذ القرص المضغوط من خلال التوفيق بين الحالة المطلوبة والحالية للمجموعة.

بدون kubectl والبرامج النصية

يجب عليك تجنب استخدام Kubectl لتحديث مجموعتك، وخاصة تجنب استخدام البرامج النصية لتجميع أوامر kubectl. بدلاً من ذلك، باستخدام مسار GitOps، يمكن للمستخدم تحديث مجموعة Kubernetes الخاصة به عبر Git.

الفوائد تشمل:

1. يمين. ويمكن تطبيق مجموعة من التحديثات وتقاربها والتحقق من صحتها في النهاية، مما يجعلنا أقرب إلى هدف الانتشار الذري. في المقابل، استخدام البرامج النصية لا يوفر أي ضمان للتقارب (المزيد حول هذا أدناه).
2. أمن. نقلا عن Kelsey Hightower: "تقييد الوصول إلى مجموعة Kubernetes الخاصة بك إلى أدوات التشغيل الآلي والمسؤولين المسؤولين عن تصحيح الأخطاء أو صيانتها." أنظر أيضا منشوري حول السلامة والامتثال للمواصفات الفنية، وكذلك مقالة عن اختراق Homebrew عن طريق سرقة بيانات الاعتماد من نص جينكينز المكتوب بإهمال.
3. تجربة المستخدم. يعرض Kubectl آليات نموذج كائن Kubernetes المعقدة للغاية. ومن الناحية المثالية، يجب على المستخدمين التفاعل مع النظام على مستوى أعلى من التجريد. هنا سأشير مرة أخرى إلى كيلسي وأوصي بالمشاهدة مثل هذه السيرة الذاتية.

الفرق بين CI و CD

يعمل GitOps على تحسين نماذج CI/CD الحالية.

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

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

لماذا لا ينبغي لخوادم CI عمل الأقراص المضغوطة عبر التحديثات المباشرة في Kubernetes

لا تستخدم خادم CI لتنسيق التحديثات المباشرة لـ Kubernetes كمجموعة من وظائف CI. هذا هو النمط المضاد الذي نتحدث عنه وقال بالفعل على مدونتك.

دعنا نعود إلى أليس وبوب.

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

لنفترض أن فريق Bob قام ببناء صورة جديدة ثم قام بتصحيح عمليات النشر الخاصة به لنشر الصورة (كل ذلك من مسار CI).

إذا تم إنشاء الصورة بشكل طبيعي، ولكن فشل المسار، فسيتعين على الفريق معرفة ما يلي:

• هل تم طرح التحديث؟
• هل نطلق بناء جديد؟ هل سيؤدي ذلك إلى آثار جانبية غير ضرورية - مع إمكانية وجود نسختين من نفس الصورة غير القابلة للتغيير؟
• هل يجب أن ننتظر التحديث التالي قبل تشغيل البناء؟
• ما الخطأ الذي حدث بالضبط؟ ما هي الخطوات التي يجب تكرارها (وما هي الخطوات التي يمكن تكرارها بأمان)؟

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

للتلخيص، إليك سبب عدم تعامل خوادم CI مع الأقراص المضغوطة:

• البرامج النصية للتحديث ليست دائمًا حتمية؛ من السهل ارتكاب الأخطاء فيها.
• لا تتقارب خوادم CI مع نموذج المجموعة التعريفية.
• ومن الصعب ضمان العجز. يجب على المستخدمين فهم الدلالات العميقة للنظام.
• من الصعب التعافي من الفشل الجزئي.

ملاحظة حول Helm: إذا كنت تريد استخدام Helm، فنوصي بدمجه مع عامل GitOps مثل الجريان هيلم. وهذا سوف يساعد على ضمان التقارب. هيلم في حد ذاته ليس حتمية ولا ذرية.

GitOps هي أفضل طريقة لتنفيذ التسليم المستمر لـ Kubernetes

يقوم فريق Alice and Bob بتنفيذ GitOps ويكتشف أنه أصبح من الأسهل بكثير العمل مع منتجات البرمجيات والحفاظ على الأداء العالي والاستقرار. دعونا ننهي هذه المقالة برسم توضيحي يوضح كيف يبدو نهجهم الجديد. ضع في اعتبارك أننا نتحدث في الغالب عن التطبيقات والخدمات، ولكن يمكن استخدام GitOps لإدارة النظام الأساسي بأكمله.

نموذج التشغيل لـ Kubernetes

انظر إلى الرسم البياني التالي. يقدم Git ومستودع صور الحاوية كموارد مشتركة لدورتي حياة منسقتين:

• خط أنابيب للتكامل المستمر يقرأ الملفات ويكتبها إلى Git ويمكنه تحديث مستودع صور الحاوية.
• خط أنابيب Runtime GitOps الذي يجمع بين النشر والإدارة وإمكانية المراقبة. يقرأ ويكتب الملفات إلى Git ويمكنه تنزيل صور الحاوية.

ما هي النتائج الرئيسية؟

1. فصل المخاوف: يرجى ملاحظة أن كلا المسارين لا يمكنهما التواصل إلا عن طريق تحديث Git أو مستودع الصور. بمعنى آخر، يوجد جدار حماية بين CI وبيئة التشغيل. نحن نسميه "جدار الحماية الثابت" (جدار الحماية الثبات)نظرًا لأن جميع تحديثات المستودع تُنشئ إصدارات جديدة. لمزيد من المعلومات حول هذا الموضوع، راجع الشرائح 72-87 هذا العرض.
2. يمكنك استخدام أي خادم CI وGit: يعمل GitOps مع أي مكون. يمكنك الاستمرار في استخدام خوادم CI وGit المفضلة لديك ومستودعات الصور ومجموعات الاختبار. تتطلب جميع أدوات التسليم المستمر الأخرى الموجودة في السوق تقريبًا خادم CI/Git أو مستودع الصور الخاص بها. قد يصبح هذا عاملاً مقيدًا في تطوير السحابة الأصلية. مع GitOps، يمكنك استخدام الأدوات المألوفة.
3. الأحداث كأداة للتكامل: بمجرد تحديث البيانات في Git، يقوم Weave Flux (أو مشغل Weave Cloud) بإعلام وقت التشغيل. عندما يقبل Kubernetes مجموعة تغيير، يتم تحديث Git. يوفر هذا نموذج تكامل بسيط لتنظيم سير العمل لـ GitOps، كما هو موضح أدناه.

اختتام

يوفر GitOps ضمانات التحديث القوية التي تتطلبها أي أداة CI/CD حديثة:

• أتمتة؛
• التقارب.
• العجز الجنسي.
• الحتمية.

وهذا أمر مهم لأنه يقدم نموذجًا تشغيليًا لمطوري السحابة الأصليين.

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

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

PS من المترجم

اقرأ أيضًا على مدونتنا:

• «GitOps: مقارنة بين طرق السحب والدفع"؛
• «تقديم مكتبة kubedog لمراقبة موارد Kubernetes"؛
• «توسيع واستكمال Kubernetes (نظرة عامة وتقرير فيديو)".

يمكن للمستخدمين المسجلين فقط المشاركة في الاستطلاع. تسجيل الدخول، من فضلك.

هل كنت تعلم عن GitOps قبل ظهور هاتين الترجمتين على حبري؟

• نعم، كنت أعرف كل شيء

• فقط بشكل سطحي

• لا

صوت 35 مستخدمين. امتنع 10 مستخدما عن التصويت.

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