تقريبا. العابرة. : بعد النشر الأخير للمواد على طرق الدفع والدفع في GitOps ، رأينا اهتمامًا بهذا النموذج ككل ، ومع ذلك ، كان هناك عدد قليل جدًا من المنشورات باللغة الروسية حول هذا الموضوع (وهي ببساطة ليست في المحور). لذلك ، يسعدنا أن نلفت انتباهكم إلى ترجمة لمقال آخر - وإن كان منذ عام تقريبًا! - من شركة Weaveworks ، التي صاغ رئيسها مصطلح "GitOps". يشرح النص جوهر النهج والاختلافات الرئيسية عن تلك الموجودة.
قبل عام ، نشرنا
مقدمة إلى GitOps . ثم تحدثنا عن كيفية قيام فريق Weaveworks بإطلاق SaaS المستندة إلى Kubernetes ، ووضع مجموعة من أفضل الممارسات الإرشادية لنشر الإدارة والمراقبة في بيئة سحابية أصلية.
تحولت المقالة إلى أن تكون شعبية. بدأ أشخاص آخرون يتحدثون عن GitOps ، وبدأوا في نشر أدوات جديدة لدعم
git ،
والتطوير ،
والأسرار ،
والوظائف ،
والتكامل المستمر ، إلخ. ظهر
عدد كبير من المنشورات وحالات استخدام GitOps على موقعنا. ولكن بعض الناس لا يزال لديهم أسئلة. كيف يختلف النموذج عن
البنية التحتية التقليدية
كرمز والتسليم المستمر؟ هل من الضروري استخدام Kubernetes؟
قريبا ، أدركنا أن هناك حاجة إلى وصف جديد ، تقدم:
- عدد كبير من الأمثلة والقصص ؛
- التعريف المحدد لـ GitOps ؛
- مقارنة مع التسليم المستمر التقليدي.
في هذه المقالة ، حاولنا تغطية كل هذه المواضيع. ستجد فيه مقدمة محدثة لـ GitOps وإلقاء نظرة عليها من جانب المطورين و CI / CD. نركز بشكل أساسي على Kubernetes ، على الرغم من أنه يمكن تعميم النموذج.
تلبية GitOps
تخيل أليس. تدير شركة التأمين الأسري ، وهي شركة تقدم بوالص التأمين على السيارات والسيارات والعقارات والسفر للأشخاص الذين هم مشغولون للغاية لفهم الفروق الدقيقة في عقودهم. بدأ عملها كمشروع جانبي عندما عملت أليس في البنك كعالم بيانات. بمجرد أن أدركت أنها يمكن أن تستخدم خوارزميات الكمبيوتر المتقدمة لتحليل البيانات وتشكيل حزم التأمين بشكل أكثر كفاءة. قام المستثمرون بتمويل المشروع ، والآن تجلب شركتها أكثر من 20 مليون دولار سنويًا وتنمو بسرعة. حاليا ، 180 شخصا يعملون في وظائف مختلفة في ذلك. من بينها ، فريق تقني يقوم بتطوير وصيانة موقع وقاعدة بيانات وتحليل قاعدة العملاء. يقود فريق من 60 شخصًا بوب ، المدير الفني للشركة.
يقوم فريق بوب بنشر أنظمة الإنتاج في السحابة. يتم تشغيل تطبيقاتهم الرئيسية على GKE ، مستفيدة من Kubernetes على Google Cloud. بالإضافة إلى ذلك ، يستخدمون أدوات مختلفة للعمل مع البيانات والتحليلات في عملهم.
التأمين العائلي لن يستخدم الحاويات ، ولكنه كان مصابًا بالحماس تجاه Docker. اكتشف خبراء الشركة قريبًا أن GKE تجعل نشر المجموعات أمرًا سهلاً وسهلاً لاختبار الميزات الجديدة. تمت إضافة Jenkins for CI و Quay لتنظيم سجل الحاوية ، وتمت كتابة البرامج النصية لـ Jenkins التي تدفع أو حاويات وتكوينات جديدة في GKE.
لقد مر بعض الوقت. شعرت أليس وبوب بخيبة أمل في أداء النهج المختار وتأثيره على العمل. لم يؤد إدخال الحاويات إلى زيادة الإنتاجية كما كان يأمل الفريق. تعطلت عمليات النشر في بعض الأحيان ، ولم يكن من الواضح ما إذا كانت التغييرات في الكود هي السبب. اتضح أيضًا أنه من الصعب تتبع التغييرات في التكوينات. غالبًا ما كان من الضروري إنشاء مجموعة جديدة ونقل التطبيقات إليها ، لأنها كانت أسهل طريقة للتخلص من الفوضى التي تحول إليها النظام. كانت أليس تخشى أن يزداد الوضع سوءًا مع تطور التطبيق (بالإضافة إلى ذلك ، كان هناك مشروع جديد يعتمد على التعلم الآلي يتم تخميره). قام بوب بأتمتة معظم العمل ولم يفهم لماذا لا يزال خط الأنابيب غير مستقر ، ولا يتدرج بشكل جيد ويتطلب تدخلًا يدويًا من وقت لآخر؟
ثم علموا GitOps. تبين أن هذا القرار هو بالضبط ما يحتاجون إليه للمضي قدمًا بثقة.سمعت أليس وبوب عن سير العمل على أساس Git و DevOps والبنية التحتية كرمز لسنوات. تفرد GitOps هو أنه يجلب عددًا من أفضل الممارسات - القاطع والمعيارية - لتنفيذ هذه الأفكار في سياق Kubernetes.
لقد أثير هذا الموضوع
مرارًا وتكرارًا ، بما
في ذلك
مدونة Weaveworks .
التأمين على الأسرة تقرر تنفيذ GitOps. لدى الشركة الآن نموذج تشغيل تلقائي متوافق مع Kubernetes يجمع بين
السرعة والثبات ، لأنها:
- وجدت أن الفريق قد ضاعف من الإنتاجية وليس هناك من جنون ؛
- توقف خدمة النصوص. بدلاً من ذلك ، يمكنهم الآن التركيز على الميزات الجديدة وتحسين الأساليب الهندسية - على سبيل المثال ، تقديم قوائم الكناري وتحسين الاختبار ؛
- تحسين عملية النشر - الآن نادراً ما ينكسر ؛
- حصلت على فرصة لاستعادة عمليات النشر بعد الفشل الجزئي دون تدخل يدوي ؛
- اكتسبت ثقة أكبر في أنظمة الإمداد. وجد أليس وبوب أنه يمكن تقسيم الفريق إلى مجموعات تعمل في مجال الخدمات المصغرة وتعمل بالتوازي ؛
- يمكن إجراء 30-50 تغييرات في المشروع كل يوم بجهود كل مجموعة وتجربة تقنيات جديدة ؛
- يتم جذبهم بسهولة إلى المشروع من قبل المطورين الجدد الذين لديهم القدرة على نقل التحديثات على الإنتاج باستخدام طلبات السحب في غضون ساعات قليلة ؛
- المراجعة بسهولة داخل SOC2 (لتوافق مزودي الخدمة مع متطلبات الإدارة الآمنة للبيانات ؛ اقرأ المزيد ، على سبيل المثال ، هنا - الترجمة تقريبًا) .
ماذا حدث
GitOps شيئان:
- نموذج التشغيل ل Kubernetes والسحابة الأم. يوفر مجموعة من أفضل الممارسات لنشر وإدارة ومراقبة الكتل والتطبيقات ذات الحاوية. تعريف أنيق في شريحة واحدة من لويس فيسيرا :
- الطريق إلى إنشاء بيئة موجهة للمطور لإدارة التطبيقات. نحن نطبق سير العمل Git على كل من الاستغلال والتنمية. يرجى ملاحظة أن هذا لا يقتصر على Git push ، بل يتعلق بتنظيم المجموعة الكاملة من أدوات CI / CD و UI / UX.
بضع كلمات عن بوابة
إذا لم تكن معتادًا على أنظمة التحكم في الإصدار وسير العمل المستند إلى Git ، فننصحك بشدة أن تدرسها. في البداية ، قد يبدو العمل مع الفروع وطلبات السحب بمثابة السحر الأسود ، ولكن الايجابيات تستحق الجهد المبذول. هنا
مقال جيد لتبدأ.
كيف يعمل Kubernetes
في قصتنا ، تحولت أليس وبوب إلى GitOps بعد العمل مع Kubernetes لفترة من الوقت. في الواقع ، ترتبط GitOps ارتباطًا وثيقًا بـ Kubernetes - إنه نموذج تشغيلي للبنية التحتية والتطبيقات القائمة على Kubernetes.
ماذا يعطي Kubernetes المستخدمين؟
فيما يلي بعض الميزات الرئيسية:
- في نموذج Kubernetes ، يمكن وصف كل شيء بشكل تعريفي.
- يقبل خادم Kubernetes API مثل هذا الإعلان كمدخلات ، ثم يحاول باستمرار إحضار الكتلة إلى الحالة الموضحة في الإعلان.
- الإعلانات كافية لوصف وإدارة مجموعة واسعة من أعباء العمل - "التطبيقات".
- نتيجة لذلك ، فإن التغييرات في التطبيق والكتلة ترجع إلى:
- التغييرات في الصور الحاوية ؛
- تغييرات على المواصفات التصريحية ؛
- الأخطاء في البيئة - على سبيل المثال ، تعطل الحاويات.
قدرات التقارب الكبيرة ل Kubernetes
عندما يقوم المسؤول بإجراء تغييرات في التكوين ، سيقوم أخصائي Kubernetes بتطبيقها على الكتلة حتى
تقترب حالتها
من التكوين الجديد . هذا النموذج يعمل مع أي مورد Kubernetes ويمتد مع تعريفات الموارد المخصصة (CRDs). لذلك ، تتضمن عمليات نشر Kubernet الخصائص الرائعة التالية:
- الأتمتة : توفر تحديثات Kubernetes آلية لأتمتة عملية تطبيق التغييرات بشكل صحيح وفي الوقت المناسب.
- التقارب : سوف تستمر Kubernetes في محاولة التحديثات حتى النجاح.
- العاطفية : تطبيقات التقارب المتكررة تنتج نفس النتيجة.
- الحتمية : بالموارد الكافية ، تعتمد حالة الكتلة المحدثة فقط على الحالة المطلوبة.
كيف يعمل GitOps
لقد تعلمنا ما يكفي عن Kubernetes لشرح كيفية عمل GitOps.
دعنا نعود إلى فرق التأمين العائلي المتعلقة بالخدمات الصغيرة. ما الذي يتعين عليهم القيام به عادة؟ انظر إلى القائمة أدناه (إذا كانت أي نقاط فيها تبدو غريبة أو غير مألوفة - يرجى تأجيل النقد والبقاء معنا). هذه مجرد أمثلة على سير العمل في جينكينز. هناك العديد من العمليات الأخرى عند العمل مع الأدوات الأخرى.
الشيء الرئيسي هو أننا نرى أن كل تحديث ينتهي بالتغييرات على ملفات التكوين ومستودعات Git. هذه التغييرات في Git تتسبب في "عبارة GitOps" لتحديث الكتلة:
1. سير العمل: "
جنكينز بيلد - الفرع الرئيسي ".
قائمة المهام:
- جنكينز دفع الصور الموسومة في رصيف ؛
- Jenkins push'it config ومخططات Helm إلى دلو التخزين الرئيسي ؛
- تقوم وظيفة السحابة بنسخ التكوين والمخططات من دلو التخزين الرئيسي إلى مستودع git الرئيسي ؛
- تحديث بيان GitOps الكتلة.
2.
بناء جنكينز - فرع الإصلاح أو الإصلاح :
- جنكينز دفع 'الصور التي لا تحمل علامات في رصيف ؛
- جنكينز يدفع التكوين و Helm المخططات إلى دلو التخزين التدريج.
- تقوم وظيفة السحابة بنسخ التكوين والمخططات من دلو وحدة التخزين المؤقتة إلى محطة تخزين Git ؛
- تحديث بيان GitOps الكتلة.
3.
Jenkins بناء - تطوير أو فرع الميزة :
- جنكينز دفع 'الصور التي لا تحمل علامات في رصيف ؛
- جنكينز يدفع التكوين و Helm المخططات لتطوير دلو التخزين ؛
- تقوم وظيفة السحابة بنسخ التكوين والمخططات من دلو تخزين التطوير إلى مستودع تطوير البوابة ؛
- تحديث بيان GitOps الكتلة.
4.
إضافة عميل جديد :
- يستدعي مدير أو مسؤول (LCM / ops) Gradle لنشر وتكوين موازين تحميل الشبكة (NLBs) في البداية ؛
- يرتكب LCM / ops تهيئة جديدة لإعداد النشر للتحديثات ؛
- تحديث بيان GitOps الكتلة.
وصف قصير من GitOps
- صف الحالة المرغوبة للنظام بأكمله باستخدام المواصفات التعريفية لكل بيئة (في تاريخنا ، يحدد فريق بوب تكوين النظام بأكمله في Git).
- مستودع بوابة هو مصدر الحقيقة الوحيد فيما يتعلق بالحالة المطلوبة للنظام بأكمله.
- يتم إجراء جميع التغييرات على الحالة المطلوبة من خلال عمليات في Git.
- جميع المعلمات الكتلة المطلوبة يمكن ملاحظتها أيضا في الكتلة نفسها. وبالتالي ، يمكننا تحديد ما إذا كانت الحالات المرغوبة والمراقبة تتطابق (تتقارب ، تتقارب ) أو تختلف ( متباعدة ، متباعدة ).
- إذا كانت الحالات المرغوبة والمرصودة مختلفة ، عندئذٍ:
- هناك آلية تقارب تقوم تلقائيًا أو عاجلاً بمزامنة الحالات المستهدفة والحالات الملاحظة. داخل المجموعة ، تقوم Kubernetes بهذا.
- تبدأ العملية على الفور بإخطار "التغيير ملتزم".
- بعد فترة زمنية قابلة للتكوين ، يمكن إرسال تنبيه فرق إذا كانت الحالات مختلفة.
- وبالتالي ، فإن جميع التعهدات في Git تؤدي إلى تحديثات يمكن التحقق منها وعاطفية في الكتلة.
- التراجع هو التقارب إلى الحالة المطلوبة مسبقًا.
- التقارب نهائي. عن بدايته يشهد:
- عدم وجود تنبيهات "فرق" لفترة معينة من الوقت.
- تنبيه متقارب (على سبيل المثال ، webhook ، Git Writeback event).
ما هو الاختلاف؟
نكرر مرة أخرى:
يجب أن تكون كافة الخصائص المطلوبة من الكتلة يمكن ملاحظتها في الكتلة نفسها .
بعض الأمثلة على الاختلاف:
- تغيير في ملف التكوين بسبب دمج الفروع في بوابة.
- تغيير في ملف التكوين بسبب التزام في Git تم إجراؤه بواسطة عميل GUI.
- تغييرات متعددة في الحالة المطلوبة بسبب PR في Git مع التجميع اللاحق للصورة الحاوية والتغييرات في التكوين.
- تتغير حالة الكتلة بسبب خطأ أو تعارض في الموارد يؤدي إلى "سلوك سيء" أو مجرد انحراف عرضي عن الحالة الأصلية.
ما هي آلية التقارب؟
بعض الأمثلة:
- بالنسبة للحاويات والمجموعات ، توفر آلية التقارب Kubernetes.
- يمكن استخدام نفس الآلية لإدارة التطبيقات والتصميمات المستندة إلى Kubernetes (مثل Istio و Kubeflow).
- يتم توفير آلية إدارة التفاعل العملي بين Kubernetes ومستودعات الصور و Git بواسطة مشغل Weave Flux GitOps ، الذي يعد جزءًا من Weave Cloud .
- بالنسبة للآلات الأساسية ، يجب أن تكون آلية التقارب ذاتية التعريف وذاتية. من تجربتنا الخاصة ، يمكننا أن نقول أن Terraform هي الأقرب لهذا التعريف ، لكنها لا تزال تتطلب تحكمًا بشريًا. بهذا المعنى ، تقوم GitOps بتوسيع تقليد البنية التحتية ككود.
يجمع GitOps بين Git ومحرك التقارب الممتاز Kubernetes ، ويقدم نموذجًا للتشغيل.
تتيح GitOps لنا أن نعلن أن
الأنظمة التي يمكن وصفها وملاحظةها هي
فقط التي يمكن التحكم فيها تلقائيًا والتحكم فيها .
GitOps مخصصة للمجموع الأصلي السحابي بالكامل (مثل Terraform ، إلخ.)
GitOps ليس فقط Kubernetes. نريد إدارة النظام برمته بشكل تعريفي واستخدام التقارب. نعني بواسطة نظام بأكمله مجموعة من البيئات التي تعمل مع Kubernetes - على سبيل المثال ، "dev cluster 1" ، و "production" ، وما إلى ذلك. تتضمن كل بيئة آلات ، ومجموعات ، وتطبيقات ، بالإضافة إلى واجهات للخدمات الخارجية التي توفر البيانات والمراقبة و م. ع.
لاحظ مدى أهمية Terraform في هذه الحالة لمشكلة التمهيد. يجب نشر Kubernetes في مكان ما ، واستخدام Terraform يعني أنه يمكننا استخدام نفس سير عمل GitOps لإنشاء طبقة التحكم التي تقوم عليها Kubernetes والتطبيقات. هذا هو أفضل ممارسة جيدة.
يتم إيلاء الكثير من الاهتمام لتطبيق مفاهيم GitOps على الطبقات على Kubernetes. يوجد حاليًا حلول من نوع GitOps لـ Istio و Helm و Ksonnet و OpenFaaS و Kubeflow ، وكذلك ، على سبيل المثال ، Pulumi ، التي تخلق طبقة لتطوير التطبيقات السحابية الأصلية.
Kubernetes CI / CD: مقارنة GitOps مع الأساليب الأخرى
كما ذكر ، GitOps شيئان:
- النموذج التشغيلي لـ Kubernetes والسحابة الأصلية الموصوفة أعلاه.
- الطريق إلى تنظيم بيئة إدارة التطبيقات التي تركز على المطور.
بالنسبة للكثيرين ، GitOps هو في المقام الأول سير عمل Git القائم على الدفع. نحن نحبه أيضا. ولكن هذا ليس كل شيء: دعنا الآن ننظر إلى خطوط أنابيب CI / CD.
GitOps يوفر النشر المستمر (CD) ل Kubernetes
تقدم GitOps آلية نشر مستمرة تلغي الحاجة إلى "أنظمة إدارة النشر" المنفصلة. Kubernetes يفعل كل عمل لك.
- يتطلب تحديث التطبيق التحديث في Git. هذا هو ترقية المعاملات إلى الحالة المطلوبة. بعد ذلك يتم تنفيذ "النشر" داخل المجموعة بواسطة Kubernetes نفسها بناءً على وصف محدث.
- نظرًا لخصائص Kubernetes ، فإن هذه التحديثات متقاربة. يوفر هذا آلية للنشر المستمر تكون فيها جميع التحديثات ذرية.
- ملاحظة: يوفر Weave Cloud عامل تشغيل GitOps يدمج Git و Kubernetes ويسمح لك بتشغيل قرص مضغوط عن طريق مطابقة الحالة المرغوبة والحالية للمجموعة.
بدون kubectl والنصوص
تجنب استخدام Kubectl لترقية الكتلة ، وخاصة البرامج النصية لتجميع أوامر kubectl. بدلاً من ذلك ، باستخدام خط أنابيب GitOps ، يمكن للمستخدم ترقية نظام Kubernetes الخاص به من خلال Git.
تشمل الفوائد:
- صحة . يمكن تطبيق مجموعة من التحديثات وتقاربها والتحقق من صحتها نهائيًا ، مما يجعلنا أقرب إلى هدف النشر الذري. على العكس من ذلك ، لا يوفر استخدام البرامج النصية أي ضمانات للتقارب (المزيد حول هذا أدناه).
- الأمن. نقلاً عن Kelsey Hightower: "قصر الوصول إلى مجموعة Kubernetes على أدوات التشغيل الآلي والمسؤولين المسؤولين عن تصحيح الأخطاء أو صيانتها." انظر أيضًا منشوري حول الأمان والامتثال ، وكذلك مقالة حول القرصنة المنزلية عن طريق سرقة بيانات الاعتماد من نص جنكينز المكتوب بلا مبالاة.
- تجربة المستخدم . يفضح Kubectl آليات نموذج كائن Kubernetes ، وهو أمر معقد للغاية. من الناحية المثالية ، يجب أن يتفاعل المستخدمون مع النظام بمستوى أعلى من التجريد. هنا سأشير مرة أخرى إلى كيلسي وأوصي بالنظر في مثل هذه السيرة الذاتية .
الفرق بين CI و CD
تتحسن GitOps في طرز CI / CD الحالية.
خادم CI الحديث هو أداة للتنسيق. على وجه الخصوص ، إنها أداة لتنسيق خطوط أنابيب CI. وهي تشمل الإنشاءات والاختبار والدمج إلى صندوق السيارة ، إلخ. تعمل خوادم CI على أتمتة إدارة خطوط الأنابيب المعقدة متعددة الخطوات. يتمثل أحد الإغراءات الشائعة في إنشاء برنامج نصي لمجموعة تحديث Kubernetes وتنفيذه كعنصر خط أنابيب لدفع التغييرات إلى الكتلة. في الواقع ، هذا ما يفعله العديد من الخبراء. ومع ذلك ، هذا ليس الأمثل ، وهنا السبب.
يجب استخدام CI لإجراء تحديثات للجذع ، ويجب على مجموعة Kubernetes تغيير نفسها استنادًا إلى هذه التحديثات من أجل إدارة القرص المضغوط "داخليًا". نسمي هذا
نموذج السحب للقرص المضغوط ، على عكس نموذج الدفع CI. القرص المضغوط هو جزء من
تزامن وقت التشغيل .
لماذا لا يجب على خوادم CI إنشاء أقراص مضغوطة من خلال التحديثات المباشرة في Kubernetes
لا تستخدم خادم CI لتنظيم التحديثات المباشرة في Kubernetes كمجموعة من مهام CI. هذا هو النمط المضاد الذي تحدثنا عنه بالفعل على مدونتنا.دعنا نعود إلى أليس وبوب.
ما هي المشاكل التي واجهوها؟ يقوم خادم CI الخاص بـ Bob بتطبيق التغييرات على الكتلة ، ولكن إذا وقع في العملية ، فلن يعرف Bob الحالة التي تكون فيها الكتلة (أو يجب أن تكون) وكيفية إصلاحها. وينطبق الشيء نفسه إذا نجحت.
لنفترض أن فريق بوب قام بتجميع صورة جديدة ثم قام بتصحيح عمليات النشر الخاصة بهم لنشر الصورة (كل ذلك من خط أنابيب CI).
إذا تم إنشاء الصورة بشكل طبيعي ، لكن خط الأنابيب يقع ، فسيتعين على الفريق معرفة ما يلي:
- هل تم نشر التحديث؟
- هل بدأنا بناء جديد؟ — ?
- , ?
- ? ( )?
Git' , . - push' , - ; --., CI- CD:
Helm'e: Helm, GitOps-, Flux-Helm . . Helm , .GitOps Continuous Delivery Kubernetes
GitOps , , . , , . , , GitOps .
Kubernetes
. Git :
- , Git .
- Runtime GitOps, . Git .
?
- : , , Git . , CI runtime-. « » (immutability firewall) , . 72-87 .
- CI- Git- : GitOps . CI- Git-, . Continuous Delivery CI-/Git- . cloud native. GitOps .
- : Git , Weave Flux ( Weave Cloud) runtime. , Kubernetes , Git . GitOps, .
استنتاج
GitOps , CI/CD:
, cloud native.
- , runbook' ( — . .) , deployment'.
- cloud native- , .
, . GitOps - .
PS من المترجم
اقرأ أيضًا في مدونتنا: