تقريبا. العابرة. : في مجتمع Kubernetes ، يكتسب اتجاه يسمى GitOps شعبية ، كما رأينا شخصيًا من خلال زيارة KubeCon Europe 2019. صاغ هذا المصطلح مؤخرًا نسبيًا من قبل رئيس Weaveworks - Alexis Richardson - ويعني استخدام أدوات مألوفة للمطورين (Git ، من أين الاسم نفسه) لحل المشاكل التشغيلية. على وجه الخصوص ، نحن نتحدث عن استغلال Kubernetes من خلال تخزين تكويناته في Git ونشر التغييرات على الكتلة تلقائيًا. يتحدث Matthias Jg عن طريقتين لهذه المجموعة في هذه المقالة.
في العام الماضي
(في الواقع ، حدث هذا رسميًا في أغسطس 2017 - الترجمة تقريبًا) ، ظهر نهج جديد لنشر التطبيقات في Kubernetes. يطلق عليه GitOps ، ويستند إلى الفكرة الأساسية المتمثلة في أن تتبع إصدار عمليات النشر يتم في بيئة مستودع Git آمنة.
المزايا الرئيسية لهذا النهج هي كما يلي :
- إصدارات النشر وتغيير السجل . يتم تخزين حالة الكتلة بأكملها في مستودع Git ، ويتم تحديث عمليات النشر فقط من خلال عمليات الالتزام. بالإضافة إلى ذلك ، يمكن تتبع جميع التغييرات باستخدام سجل الالتزام.
- الركلات باستخدام أوامر Git مألوفة .
git reset بسيطة تتيح لك تجاهل التغييرات في النشر ؛ الدول الماضية متاحة دائما. - استعداد التحكم في الوصول . عادةً ما يحتوي نظام Git على الكثير من البيانات السرية ، لذلك تولي معظم الشركات اهتمامًا خاصًا لحمايتها. وفقًا لذلك ، تمتد هذه الحماية لتشمل عمليات النشر.
- سياسات النشر . تدعم معظم أنظمة Git السياسات في البداية للفروع المختلفة - على سبيل المثال ، يمكن فقط لطلبات السحب فقط تحديث الرئيسي ، ويجب على عضو آخر في الفريق التحقق من التغييرات وقبولها. كما هو الحال مع التحكم في الوصول ، تنطبق نفس السياسات على تحديثات النشر.
كما ترون ، فإن طريقة GitOps لها العديد من المزايا. خلال العام الماضي ، اكتسب نهجين شعبية خاصة. واحد يعتمد على الدفع ، والآخر عند السحب. قبل النظر إليهم ، دعونا أولاً نرى شكل عمليات نشر Kubernetes النموذجية.
طرق النشر
في السنوات الأخيرة ، تم وضع طرق وأدوات نشر مختلفة في Kubernetes:
- بناءً على قوالب Kubernetes / Kustomize الأصلية . هذه هي أسهل طريقة لنشر التطبيقات على Kubernetes. يقوم المطور بإنشاء ملفات YAML الأساسية وتطبيقها. للتخلص من إعادة الكتابة المستمرة للنماذج نفسها ، تم تطوير Kustomize (يحول أنماط Kubernetes إلى وحدات). تقريبا. العابرة. : تم دمج Kustomize في kubectl مع إصدار Kubernetes 1.14 .
- الرسوم البيانية هيلم . تسمح لك مخططات Helm بإنشاء مجموعات من القوالب ، وحاويات init ، و sidecar'ov ، وما إلى ذلك ، والتي تُستخدم لنشر التطبيقات مع خيارات تكوين أكثر مرونة من النهج القائم على القوالب. تعتمد هذه الطريقة على ملفات قالب YAML. يقوم Helm بملئها بمعلمات متنوعة ثم يرسلها إلى Tiller ، مكون نظام المجموعة ، الذي يقوم بنشرها في المجموعة ويسمح بالتحديثات واسترجاعها. الشيء المهم هو أنه في الواقع ، يقوم Helm ببساطة بإدراج القيم اللازمة في القوالب ثم يطبقها بالطريقة نفسها التي يتم بها في النهج التقليدي (لمزيد من التفاصيل حول كيفية عمل كل هذا وكيف يمكنك استخدامه ، اقرأ مقالتنا عن Helm - تقريبا. .) . هناك مجموعة واسعة من مخططات Helm الجاهزة التي تغطي مجموعة واسعة من المهام.
- أدوات بديلة . هناك العديد من الأدوات البديلة. جميعهم متحدون من حقيقة أنهم يقومون بتحويل بعض ملفات القوالب إلى ملفات YAML الصديقة لـ Kubernetes ثم يقومون بتطبيقها.
في عملنا ، نستخدم باستمرار مخططات Helm للأدوات المهمة (نظرًا لأن الكثير منها جاهز بالفعل ، مما يبسط الحياة إلى حد كبير) وملفات Kubernetes "النظيفة" YAML لنشر تطبيقاتنا الخاصة.
سحب ودفع
في أحد تدويناتي الأخيرة للمدونة ، قمت بتقديم أداة
Weave Flux ، والتي تتيح لك إمكانية إنشاء قوالب إلى مستودع Git ونشر التحديث بعد كل حاوية التزام أو دفع. تُظهر تجربتي أن هذه الأداة هي إحدى الأدوات الرئيسية في الترويج لنهج السحب ، لذلك سأشير إليها غالبًا. إذا كنت تريد معرفة المزيد حول كيفية استخدامه ، فإليك
رابط للمقال .
NB! يتم الاحتفاظ بجميع فوائد استخدام GitOps لكلا النهجين.سحب النهج القائم
تعتمد طريقة السحب على حقيقة أن كل التغييرات يتم تطبيقها من داخل المجموعة. داخل المجموعة ، يوجد مشغل يقوم بفحص مستودعات Git and Docker Registry المرتبطة بشكل منتظم. في حالة حدوث أي تغييرات فيها ، يتم تحديث حالة الكتلة داخليًا. عادة ما يعتبر أن مثل هذه العملية آمنة للغاية ، حيث لا يوجد عميل خارجي لديه حق الوصول إلى حقوق مسؤول الكتلة.
الايجابيات:- لا يحق لأي عميل خارجي إجراء تغييرات على المجموعة ، حيث يتم نقل جميع التحديثات من الداخل.
- تسمح لك بعض الأدوات أيضًا بمزامنة التحديثات على مخططات Helm وربطها بمجموعة.
- يمكن مسح Docker Registry بحثًا عن إصدارات جديدة. في حالة ظهور صورة جديدة ، يتم تحديث مستودع Git والنشر إلى الإصدار الجديد.
- يمكن توزيع أدوات السحب عبر مساحات أسماء مختلفة باستخدام مستودعات Git وأذوناتها المختلفة. بفضل هذا ، من الممكن استخدام النموذج المتعدد. على سبيل المثال ، يمكن للفريق "أ" استخدام مساحة الاسم "أ" ، ويمكن للفريق "ب" استخدام مساحة الاسم "ب" ، ويمكن لفريق البنية التحتية استخدام المساحة العامة.
- كقاعدة عامة ، الأدوات خفيفة الوزن للغاية.
- بالإضافة إلى أدوات مثل بيان Bitnami Sealed Secrets ، يمكن تخزين الأسرار المشفرة في مستودع Git واسترجاعها داخل المجموعة.
- لا يوجد أي اتصال مع خطوط أنابيب CD ، حيث تحدث عمليات النشر داخل الكتلة.
سلبيات :
- تعد إدارة أسرار النشر من مخططات Helm أكثر تعقيدًا من المعتاد ، حيث يجب عليك أولاً توليدها ، على سبيل المثال ، الأسرار المختومة ، ثم فك تشفيرها باستخدام مشغل داخلي وفقط بعد أن تصبح متاحة لأداة السحب. ثم يمكنك إطلاق الإصدار في Helm مع القيم في الأسرار التي تم نشرها بالفعل. أسهل طريقة هي إنشاء سر باستخدام جميع قيم Helm المستخدمة للنشر وفك تشفيره والالتزام به في Git.
- باستخدام نهج السحب ، ستجد نفسك مرتبطًا بالأدوات التي تعمل على الجرار. هذا يحد من القدرة على تخصيص عملية نشر النشر في الكتلة. على سبيل المثال ، العمل مع Kustomize معقد بسبب حقيقة أنه يجب تنفيذه قبل وصول القوالب النهائية إلى Git. أنا لا أقول أنه لا يمكنك استخدام الأدوات الفردية ، ولكن يصعب دمجها في عملية النشر.
دفع بناء النهج
في طريقة الدفع ، يبدأ النظام الخارجي (خطوط أنابيب CD بشكل أساسي) في الانتشار إلى المجموعة بعد الالتزام بمستودع Git أو في حالة التنفيذ الناجح لخط أنابيب CI السابق. في هذا النهج ، لدى النظام حق الوصول إلى الكتلة.
الايجابيات :
- يتم تحديد الأمان بواسطة مستودع Git وخط أنابيب الإنشاء.
- إن نشر مخططات Helm أسهل ؛ فهناك دعم لإضافات Helm.
- الأسرار أسهل في إدارتها ، لأنه يمكن استخدام الأسرار في خطوط الأنابيب ، بالإضافة إلى تخزينها في Git في شكل مشفر (حسب تفضيلات المستخدم).
- عدم وجود ارتباط بأداة محددة ، حيث يمكن استخدام أي من أنواعها.
- يمكن تشغيل تحديثات إصدار الحاوية بواسطة خط أنابيب التجميع.
سلبيات :
- توجد البيانات للوصول إلى الكتلة داخل نظام الإنشاء.
- لا يزال تحديث حاويات النشر أسهل في عملية السحب.
- يعتمد هذا الأمر اعتمادًا كبيرًا على نظام الأقراص المضغوطة ، لأن خطوط الأنابيب التي نحتاجها ربما تكون مكتوبة أصلاً من أجل Gitlab Runners ، ثم يقرر الفريق التبديل إلى Azure DevOps أو Jenkins ... وسيتعين عليك ترحيل عدد كبير من خطوط أنابيب الإنشاء.
خلاصة القول: دفع أو سحب؟
كالعادة ، كل نهج له إيجابيات وسلبيات. بعض المهام أسهل في إنجازها مع واحد وأكثر صعوبة مع الآخر. في البداية ، قضيت عمليات النشر يدويًا ، لكن بعد أن صادفت العديد من المقالات حول Weave Flux ، قررت تنفيذ عمليات GitOps لجميع المشاريع. بالنسبة للقوالب الأساسية ، أصبح هذا الأمر سهلاً ، ولكن بعد ذلك بدأت أواجه صعوبات في العمل مع مخططات Helm. في ذلك الوقت ، لم تقدم Weave Flux إلا نسخة أولية من مشغل مخطط Helm ، لكن حتى الآن بعض المهام أكثر تعقيدًا بسبب الحاجة إلى إنشاء أسرار يدويًا وتطبيقها. يمكنك القول أن أسلوب السحب أكثر أمانًا ، نظرًا لأن بيانات اعتماد نظام المجموعة غير متوفرة خارجها ، وهذا يزيد من الأمان لدرجة أنه يكلف مجهودًا إضافيًا.
بعد التفكير قليلاً ، توصلت إلى نتيجة غير متوقعة مفادها أن هذا ليس كذلك. إذا تحدثنا عن المكونات التي تتطلب أقصى قدر من الحماية ، فستشمل هذه القائمة تخزين الأسرار وأنظمة CI / CD ، ومستودعات Git. المعلومات الموجودة بداخلها ضعيفة للغاية وتحتاج إلى حماية قصوى. بالإضافة إلى ذلك ، إذا دخل شخص ما إلى مستودع Git الخاص بك وكان بإمكانه دفع الرمز هناك ، فسيكون قادرًا على نشر كل ما يريد (بصرف النظر عن الطريقة المختارة ، سيكون السحب أو الدفع) والتسلل إلى أنظمة الكتلة. وبالتالي ، فإن أهم المكونات التي تتطلب الحماية هي أنظمة تخزين Git و CI / CD ، وليس بيانات اعتماد المجموعة. إذا كانت لديك سياسات وتدابير أمنية مضبوطة جيدًا للأنظمة من هذا النوع ، وتم استرداد بيانات اعتماد نظام المجموعة إلى أنابيب فقط كأسرار ، فقد لا يكون الأمان الإضافي لنهج السحب أكثر قيمة كما هو مطلوب في الأصل.
لذلك ، إذا كانت طريقة السحب تستغرق وقتًا أطول ولا تعطي ربحًا في الأمان ، فهل من المنطقي استخدام نهج الدفع فقط؟ لكن قد يقول شخص ما أنه في نهج الدفع ، فأنت مرتبط جدًا بنظام الأقراص المضغوطة ، وربما من الأفضل عدم القيام بذلك من أجل تسهيل عمليات الترحيل في المستقبل.
في رأيي (كما هو الحال دائمًا) ، يجب عليك استخدام ما هو أكثر ملاءمة لحالة معينة أو الجمع. أنا شخصياً أستخدم كلا الطريقتين: Weave Flux لعمليات النشر القائمة على السحب والتي تشمل خدماتنا بشكل أساسي ، ونهج الدفع مع Helm والإضافات التي تبسط تطبيق مخططات Helm على الكتلة وتتيح لك إنشاء أسرار بسهولة. أعتقد أنه لن يكون هناك أبدًا حل واحد يناسب جميع الحالات ، لأن هناك دائمًا الكثير من الفروق الدقيقة وتعتمد على التطبيق المحدد. في الوقت نفسه ، أوصي بشدة بـ GitOps - إنه يبسط الحياة بشكل كبير ويحسن الأمن.
آمل أن تساعد خبرتي في هذا الموضوع على تحديد الطريقة الأكثر ملاءمة لنوع النشر الخاص بك ، وسيسعدني معرفة رأيك.
ملاحظة ملاحظة من المترجم
في سلبيات نموذج السحب ، هناك نقطة حول حقيقة أنه من الصعب وضع بيانات واضحة في Git ، ولكن لا يوجد ناقص أن خط أنابيب CD في نموذج السحب يعيش بشكل منفصل عن بدء التشغيل ، وفي الواقع ، يصبح
خط أنابيب فئة
تطبيق مستمر . لذلك ، ستكون هناك حاجة إلى بذل مزيد من الجهود من أجل جمع حالتها من جميع عمليات النشر وإتاحة الوصول بطريقة أو بأخرى إلى السجلات / الحالة ، ويفضل أن يكون ذلك بالإشارة إلى نظام CD.
وبهذا المعنى ، يتيح لك نموذج الدفع إعطاء بعض الضمان على الأقل ، لأن عمر خط الأنابيب يمكن أن يكون مساوياً لعمر التشغيل.
اختبرنا كلا النموذجين وتوصلنا إلى نفس الاستنتاجات التي خلص إليها كاتب المقال:
- نموذج السحب مناسب لنا لتنظيم تحديثات مكونات النظام على عدد كبير من الكتل (راجع مقالة حول الملحق الإضافي ).
- يعد طراز الدفع المستندة إلى GitLab CI مناسبًا تمامًا لتطبيق التطبيقات باستخدام مخططات Helm. في عملية النشر التمهيدية هذه ، يتم رصد نشرها داخل خطوط الأنابيب باستخدام أداة werf . بالمناسبة ، في سياق مشروعنا ، سمعنا "GitOps" المستمرة عندما ناقشنا المشكلات الملحة لمهندسي DevOps في جناحنا في KubeCon Europe'19.
PPS من المترجم
اقرأ أيضًا في مدونتنا: