ملحوظة. ترجمة.: في مجتمع 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 مع .
- مخططات هيلم. تسمح لك مخططات Helm بإنشاء مجموعات من القوالب، وحاويات التهيئة، والسيارات الجانبية، وما إلى ذلك، والتي تُستخدم لنشر التطبيقات بخيارات تخصيص أكثر مرونة من النهج القائم على القالب. تعتمد هذه الطريقة على ملفات YAML القالبة. يملأها Helm بمعلمات مختلفة ثم يرسلها إلى Tiller، وهو أحد مكونات المجموعة الذي ينشرها في المجموعة ويسمح بالتحديثات وعمليات التراجع. الشيء المهم هو أن Helm يقوم فقط بإدراج القيم المطلوبة في القوالب ثم يطبقها بنفس الطريقة التي يتم بها في النهج التقليدي (اقرأ المزيد حول كيفية عمل كل ذلك وكيف يمكنك استخدامه في موقعنا - تقريبا. ترجمة.). هناك مجموعة واسعة من مخططات Helm الجاهزة التي تغطي مجموعة واسعة من المهام.
- أدوات بديلة. هناك العديد من الأدوات البديلة. القاسم المشترك بينهم جميعًا هو أنهم يحولون بعض ملفات القوالب إلى ملفات YAML قابلة للقراءة من Kubernetes ثم يستخدمونها.
في عملنا، نستخدم باستمرار مخططات Helm للأدوات المهمة (نظرًا لأن لديها الكثير من الأشياء الجاهزة بالفعل، مما يجعل الحياة أسهل بكثير) وملفات Kubernetes YAML "الخالصة" لنشر تطبيقاتنا الخاصة.
أسحب أدفع
في إحدى منشوراتي الأخيرة على مدونتي، قمت بتقديم الأداة ، والذي يسمح لك بإيداع القوالب في مستودع Git وتحديث النشر بعد كل التزام أو دفع للحاوية. تظهر تجربتي أن هذه الأداة هي واحدة من الأدوات الرئيسية في الترويج لنهج السحب، لذلك سأشير إليها كثيرًا. إذا كنت تريد معرفة المزيد عن كيفية استخدامه، هنا .
NB! تظل جميع فوائد استخدام GitOps كما هي لكلا الطريقتين.
النهج القائم على السحب
يعتمد أسلوب السحب على حقيقة أن كافة التغييرات يتم تطبيقها من داخل المجموعة. يوجد عامل داخل المجموعة يقوم بالتحقق بانتظام من مستودعات Git وDocker Registry المرتبطة. في حالة حدوث أية تغييرات عليها، يتم تحديث حالة المجموعة داخليًا. تعتبر هذه العملية بشكل عام آمنة للغاية، حيث لا يوجد عميل خارجي لديه حق الوصول إلى حقوق مسؤول المجموعة.
الايجابيات:
- لا يتمتع أي عميل خارجي بحقوق إجراء تغييرات على المجموعة؛ حيث يتم نشر كافة التحديثات من الداخل.
- تتيح لك بعض الأدوات أيضًا مزامنة تحديثات مخطط Helm وربطها بالمجموعة.
- يمكن فحص Docker Registry بحثًا عن الإصدارات الجديدة. في حالة توفر صورة جديدة، يتم تحديث مستودع Git والنشر إلى الإصدار الجديد.
- يمكن توزيع أدوات السحب عبر مساحات أسماء مختلفة باستخدام مستودعات وأذونات Git المختلفة. وبفضل هذا، يمكن استخدام نموذج متعدد المستأجرين. على سبيل المثال، قد يستخدم الفريق "أ" مساحة الاسم "أ"، وقد يستخدم الفريق "ب" مساحة الاسم "ب"، وقد يستخدم فريق البنية التحتية المساحة العمومية.
- كقاعدة عامة، الأدوات خفيفة الوزن للغاية.
- جنبا إلى جنب مع أدوات مثل المشغل ، يمكن تخزين الأسرار مشفرة في مستودع Git واسترجاعها داخل المجموعة.
- لا يوجد أي اتصال بخطوط أنابيب الأقراص المضغوطة نظرًا لأن عمليات النشر تحدث داخل المجموعة.
سلبيات:
- تعد إدارة أسرار النشر من مخططات Helm أكثر صعوبة من تلك العادية، حيث يجب إنشاؤها أولاً في شكل أسرار مختومة، على سبيل المثال، ثم يتم فك تشفيرها بواسطة مشغل داخلي، وبعد ذلك فقط تصبح متاحة لأداة السحب. ثم يمكنك تشغيل الإصدار في Helm بالقيم الموجودة في الأسرار المنشورة بالفعل. أسهل طريقة هي إنشاء سر بجميع قيم Helm المستخدمة للنشر وفك تشفيره وإلزامه بـ Git.
- عندما تتبع أسلوب السحب، فإنك تصبح مقيدًا بأدوات السحب. وهذا يحد من القدرة على تخصيص عملية النشر في المجموعة. على سبيل المثال، يعد Kustomize معقدًا لأنه يجب تشغيله قبل أن يتم الالتزام بالقوالب النهائية في Git. أنا لا أقول أنه لا يمكنك استخدام الأدوات المستقلة، ولكن من الصعب دمجها في عملية النشر الخاصة بك.
النهج القائم على الدفع
في أسلوب الدفع، يقوم نظام خارجي (أساسًا خطوط أنابيب الأقراص المضغوطة) بإطلاق عمليات النشر إلى المجموعة بعد الالتزام بمستودع Git أو في حالة نجاح مسار CI السابق. في هذا الأسلوب، النظام لديه حق الوصول إلى الكتلة.
الايجابيات:
- يتم تحديد الأمان من خلال مستودع Git وخط أنابيب البناء.
- يعد نشر مخططات Helm أسهل ويدعم مكونات Helm الإضافية.
- من السهل إدارة الأسرار لأنه يمكن استخدام الأسرار في خطوط الأنابيب ويمكن أيضًا تخزينها مشفرة في Git (اعتمادًا على تفضيلات المستخدم).
- لا يوجد أي اتصال بأداة محددة، حيث يمكن استخدام أي نوع.
- يمكن بدء تحديثات إصدار الحاوية من خلال مسار الإنشاء.
سلبيات:
- بيانات الوصول إلى المجموعة موجودة داخل نظام البناء.
- لا يزال تحديث حاويات النشر أسهل من خلال عملية السحب.
- الاعتماد الكبير على نظام الأقراص المضغوطة، نظرًا لأن خطوط الأنابيب التي نحتاجها ربما تكون مكتوبة في الأصل لـ Gitlab Runners، ثم يقرر الفريق الانتقال إلى Azure DevOps أو Jenkins... وسيتعين عليه ترحيل عدد كبير من خطوط أنابيب البناء.
النتائج: دفع أم سحب؟
وكما هو الحال عادة، فإن كل نهج له إيجابياته وسلبياته. بعض المهام يكون من الأسهل إنجازها بواحدة وأكثر صعوبة بأخرى. في البداية كنت أقوم بعمليات النشر يدويًا، ولكن بعد أن صادفت بعض المقالات حول Weave Flux، قررت تنفيذ عمليات GitOps لجميع المشاريع. بالنسبة للقوالب الأساسية، كان هذا أمرًا سهلاً، ولكن بعد ذلك بدأت أواجه صعوبات مع مخططات Helm. في ذلك الوقت، لم تقدم Weave Flux سوى نسخة بدائية من Helm Chart Operator، ولكن حتى الآن أصبحت بعض المهام أكثر صعوبة بسبب الحاجة إلى إنشاء الأسرار يدويًا وتطبيقها. يمكنك القول بأن أسلوب السحب أكثر أمانًا لأنه لا يمكن الوصول إلى بيانات اعتماد المجموعة خارج المجموعة، مما يجعلها أكثر أمانًا لدرجة أنها تستحق الجهد الإضافي.
وبعد بعض التفكير، توصلت إلى نتيجة غير متوقعة مفادها أن الأمر ليس كذلك. إذا تحدثنا عن المكونات التي تتطلب أقصى قدر من الحماية، فستتضمن هذه القائمة التخزين السري، وأنظمة CI/CD، ومستودعات Git. المعلومات الموجودة بداخلها ضعيفة للغاية وتحتاج إلى أقصى قدر من الحماية. بالإضافة إلى ذلك، إذا دخل شخص ما إلى مستودع Git الخاص بك وتمكن من دفع التعليمات البرمجية هناك، فيمكنه نشر ما يريد (سواء كان سحبًا أو دفعًا) والتسلل إلى أنظمة المجموعة. وبالتالي، فإن أهم المكونات التي تحتاج إلى الحماية هي مستودع Git وأنظمة CI/CD، وليس بيانات اعتماد المجموعة. إذا كانت لديك سياسات وضوابط أمان جيدة التكوين لهذه الأنواع من الأنظمة، وتم استخراج بيانات اعتماد المجموعة فقط في خطوط الأنابيب كأسرار، فقد لا يكون الأمان الإضافي لنهج السحب ذا قيمة كما كان يعتقد في الأصل.
لذا، إذا كان نهج السحب يتطلب عمالة كثيفة ولا يوفر فائدة أمنية، أليس من المنطقي استخدام نهج الدفع فقط؟ لكن قد يجادل شخص ما بأنك في نهج الدفع تكون مرتبطًا جدًا بنظام القرص المضغوط، وربما يكون من الأفضل عدم القيام بذلك حتى يكون من الأسهل تنفيذ عمليات الترحيل في المستقبل.
في رأيي (كما هو الحال دائمًا)، يجب عليك استخدام ما هو أكثر ملاءمة لحالة أو مجموعة معينة. شخصيًا، أستخدم كلا الطريقتين: Weave Flux لعمليات النشر القائمة على السحب والتي تتضمن في الغالب خدماتنا الخاصة، وأسلوب الدفع مع Helm والمكونات الإضافية، مما يجعل من السهل تطبيق مخططات Helm على المجموعة ويسمح لك بإنشاء الأسرار بسلاسة. أعتقد أنه لن يكون هناك حل واحد مناسب لجميع الحالات، لأن هناك دائمًا الكثير من الفروق الدقيقة وتعتمد على التطبيق المحدد. ومع ذلك، أوصي بشدة بـ GitOps - فهو يجعل الحياة أسهل كثيرًا ويحسن الأمان.
آمل أن تساعدك تجربتي في هذا الموضوع في تحديد الطريقة الأكثر ملاءمة لنوع النشر الخاص بك، ويسعدني سماع رأيك.
ملحوظة ملاحظة من المترجم
الجانب السلبي لنموذج السحب هو أنه من الصعب وضع البيانات المقدمة في Git، ولكن لا يوجد جانب سلبي يتمثل في أن مسار القرص المضغوط في نموذج السحب يعيش بشكل منفصل عن الطرح ويصبح بشكل أساسي مسار فئة تطبيق مستمر. لذلك، ستكون هناك حاجة إلى مزيد من الجهد لجمع حالتها من جميع عمليات النشر وتوفير الوصول بطريقة أو بأخرى إلى السجلات/الحالة، ويفضل أن يكون ذلك بالرجوع إلى نظام الأقراص المضغوطة.
وبهذا المعنى، يسمح لنا نموذج الدفع بتوفير بعض ضمانات الطرح على الأقل، لأنه يمكن جعل عمر خط الأنابيب مساويًا لعمر الطرح.
لقد جربنا كلا النموذجين وتوصلنا إلى نفس الاستنتاجات التي توصل إليها كاتب المقال:
- نموذج السحب مناسب لنا لتنظيم تحديثات مكونات النظام على عدد كبير من المجموعات (انظر. ).
- يعد نموذج الدفع المستند إلى GitLab CI مناسبًا تمامًا لطرح التطبيقات باستخدام مخططات Helm. وفي الوقت نفسه، تتم مراقبة بدء عمليات النشر داخل خطوط الأنابيب باستخدام الأداة . بالمناسبة، في سياق مشروعنا هذا، سمعنا عبارة "GitOps" المستمرة عندما ناقشنا المشكلات الملحة التي يواجهها مهندسو DevOps في منصتنا في KubeCon Europe'19.
PPS من المترجم
اقرأ أيضًا على مدونتنا:
- «"؛
- «"؛
- «"؛
- «".
يمكن للمستخدمين المسجلين فقط المشاركة في الاستطلاع. ، من فضلك.
هل تستخدم GitOps؟
-
نعم، نهج السحب
-
نعم، ادفع
-
نعم، سحب + دفع
-
نعم، شيء آخر
-
لا
صوت 30 مستخدمين. امتنع 10 مستخدما عن التصويت.
المصدر: www.habr.com