💐 💑 🧠 وضع العلامات المستندة إلى المحتوى في جامع werf: لماذا وكيف يعمل؟ 🛫 ⛰️ 💅🏾

werf هي أداة GitOps CLI مفتوحة المصدر الخاصة بنا لإنشاء التطبيقات وتقديمها إلى Kubernetes. في الإصدار v1.1 يحتوي على ميزة جديدة لمجمع الصور: وضع علامات على الصور حسب المحتوى ، أو العلامات المستندة إلى المحتوى . حتى الآن ، تضمن نظام وضع العلامات النموذجي في werf وضع علامات على صور Docker باستخدام علامة Git أو فرع Git أو Git ارتكاب. لكن كل هذه المخططات بها عيوب تم حلها بالكامل بواسطة إستراتيجية وضع العلامات الجديدة. تفاصيل عنها ولماذا هي جيدة - تحت القطع.

استرجاع مجموعة من الخدمات الدقيقة من مستودع Git واحد

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

هناك حالات تكون فيها الخدمات مستقلة حقًا ولا ترتبط بتطبيق واحد. في هذه الحالة ، سيتم وضعهم في مشاريع منفصلة وسيتم إصدارها من خلال عمليات CI / CD منفصلة في كل مشروع.

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

علامة Git وعلامة Git

لنفترض أنه يتم استخدام إستراتيجية وضع العلامات الأكثر شيوعًا - tag-or-branch . بالنسبة لفروع Git ، يتم وضع علامة على الصور باسم الفرع ، بالنسبة لفرع واحد في كل مرة لا توجد سوى صورة واحدة منشورة باسم هذا الفرع. بالنسبة لعلامات Git ، يتم تمييز الصور وفقًا لاسم العلامة.

عند إنشاء علامة Git جديدة - على سبيل المثال ، عند إصدار نسخة جديدة - سيتم إنشاء علامة Docker جديدة لجميع صور المشروع في Docker Registry:

myregistry.org/myproject/frontend:v1.1.10
myregistry.org/myproject/myservice1:v1.1.10
myregistry.org/myproject/myservice2:v1.1.10
myregistry.org/myproject/myservice3:v1.1.10
myregistry.org/myproject/myservice4:v1.1.10
myregistry.org/myproject/myservice5:v1.1.10
myregistry.org/myproject/database:v1.1.10

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

المشكلة : في حالة عدم تغيير vykata الفعلي (Git-tag) لمحتويات الصورة ، ولكن فقط علامة Docker التي تحدث بمجرد إعادة تشغيل هذا التطبيق ، وبناءً على ذلك ، بعض البساطة الممكنة. على الرغم من عدم وجود سبب حقيقي لإعادة التشغيل.

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

الالتزام بوضع العلامات على Git

لدى Werf أيضًا إستراتيجية وضع العلامات المتعلقة بتنفيذ عمليات Git.

Git-الالتزام هو معرّف محتويات مستودع Git ويعتمد على محفوظات تعديلات الملف في مستودع Git ، لذلك يبدو من المنطقي استخدامها لوضع علامة على الصور في Docker Registry.

ومع ذلك ، فإن وضع العلامات بواسطة Git ارتكاب لها نفس العيوب التي لها من قبل فروع Git أو علامات Git:

, , Docker- .
merge-, , Docker- .
, Git, , Docker- .

Git-

هناك مشكلة أخرى تتعلق باستراتيجية وضع العلامات لفروع Git.

يعمل وضع العلامات باسم الفرع ما دام يتم تجميع ارتباطات هذا الفرع بالتسلسل الزمني.

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

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

ما هو وضع العلامات المستندة إلى المحتوى؟

لذا ، ما هو بالضبط وضع العلامات على المحتوى - وضع علامات على الصور حسب المحتوى.

لإنشاء علامات Docker ، لا يتم استخدام بدائل Git (فرع Git ، علامة Git ...) ، ولكن المجموع الاختباري المرتبط بما يلي:

. - . , ;
Git. , Git- werf, -.

يعمل ما يسمى التوقيع على مراحل الصورة مثل علامة معرف .

تتكون كل صورة من مجموعة من الخطوات: from، before-install، git-archive، install، imports-after-install، before-setup، ، ... git-latest-patchإلخ. كل مرحلة لها معرف ، يعكس محتواها - مرحلة التوقيع (توقيع المرحلة) .

يتم وضع علامة على الصورة النهائية ، التي تتكون من هذه المراحل ، بما يسمى توقيع مجموعة هذه المراحل - توقيع المراحل - والذي يتم تعميمه لجميع مراحل الصورة.

كل صورة من التكوين werf.yamlسيكون لها بشكل عام مثل هذا التوقيع الخاص بها ، وبالتالي علامة Docker.

يحل توقيع المرحلة كل هذه المشاكل:

مقاومة لأعمال git الفارغة.
مقاومة عمليات git التي تغير الملفات التي ليست ذات صلة بالصورة.
لا يؤدي إلى مشكلة في طحن الإصدار الحالي من الصورة عند إعادة تشغيل التجميعات لعمليات تنفيذ Git القديمة للفرع.

هذه هي استراتيجية وضع العلامات الموصى بها ويتم استخدامها افتراضيًا في werf لجميع أنظمة CI.

كيفية تمكين واستخدام في werf

ظهر الخيار المقابل للفريق werf publish: --tag-by-stages-signature=true|false

في نظام CI ، يتم تعيين استراتيجية وضع العلامات بواسطة الأمر werf ci-env. سابقا ، تم تحديد معلمة لذلك werf ci-env --tagging-strategy=tag-or-branch. الآن ، إذا حددت werf ci-env --tagging-strategy=stages-signatureهذا الخيار أم لا ، فسيستخدم werf إستراتيجية وضع العلامات بشكل افتراضي stages-signature. سيقوم الأمر werf ci-envتلقائيًا بتعيين العلامات اللازمة للأمر werf build-and-publish(أو werf publish) ، وبالتالي ، لا يلزم تحديد خيارات إضافية لهذه الأوامر.

على سبيل المثال ، الأمر:

werf publish --stages-storage :local --images-repo registry.hello.com/web/core/system --tag-by-stages-signature

... يمكن أن تخلق الصور التالية:

registry.hello.com/web/core/system/backend:4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d
registry.hello.com/web/core/system/frontend:f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6

هنا 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386dتوقيع مراحل الصورة backend، f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6وهو توقيع مراحل الصورة frontend.

عند استخدام وظائف خاصة werf_container_imageوفي werf_container_envقوالب Helm ، لا يلزم تغيير أي شيء: ستقوم هذه الوظائف تلقائيًا بإنشاء أسماء الصور الصحيحة.

تكوين مثال في نظام CI:

type multiwerf && source <(multiwerf use 1.1 beta)
type werf && source <(werf ci-env gitlab)
werf build-and-publish|deploy

يتوفر مزيد من معلومات التكوين في الوثائق:

مجموع

خيار جديد werf publish --tag-by-stages-signature=true|false.
القيمة الجديدة للخيار werf ci-env --tagging-strategy=stages-signature|tag-or-branch(إذا لم يكن محددًا ، فسيكون افتراضيًا stages-signature).
إذا تم استخدام خيارات وضع العلامات لعمليات تنفيذ Git من قبل ( WERF_TAG_GIT_COMMITأو الخيار werf publish --tag-git-commit COMMIT) ، فتأكد من التبديل إلى إستراتيجية وضع علامات توقيع المراحل .
من الأفضل أن تتحول المشاريع الجديدة على الفور إلى نظام وضع العلامات الجديد.
عند الترجمة إلى werf 1.1 ، يُنصح بتحويل المشاريع القديمة إلى نظام وضع العلامات الجديد ، ولكن لا تزال العلامة أو الفرع القديم مدعومة.

يعمل وضع العلامات المستند إلى المحتوى على حل جميع المشكلات الموضحة في المقالة:

استقرار اسم علامة عامل الميناء لتفريغ عمليات git.
يؤدي استقرار اسم علامة Docker إلى Git إلى تغيير الملفات غير ذات الصلة بالصورة.
لا يؤدي إلى مشكلة في طحن الإصدار الحالي من الصورة عند إعادة تشغيل التجميعات لالتزامات Git القديمة لفروع Git.

استخدمه! ولا تنس أن تسقط من خلال GitHub الخاص بنا لإنشاء مشكلة أو العثور على مشكلة موجودة ، أو وضع علامة زائد ، أو إنشاء العلاقات العامة ، أو مجرد مشاهدة تطور المشروع.

وضع العلامات المستندة إلى المحتوى في جامع werf: لماذا وكيف يعمل؟