ProHoster > بلوق > إدارة > وضع العلامات على أساس المحتوى في werf builder: لماذا وكيف يعمل؟

وضع العلامات على أساس المحتوى في werf builder: لماذا وكيف يعمل؟

وضع العلامات على أساس المحتوى في werf builder: لماذا وكيف يعمل؟

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

طرح مجموعة من الخدمات المصغرة من مستودع Git واحد

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

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

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

وضع العلامات حسب فرع Git وعلامة Git

لنفترض أنه تم استخدام إستراتيجية وضع العلامات الأكثر شيوعًا - علامة أو فرع. بالنسبة لفروع 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 وإعادة تشغيل الموارد المقابلة بسبب تغيير اسم الصورة.

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

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

وضع العلامات بواسطة التزام Git

لدى werf أيضًا إستراتيجية وضع العلامات المرتبطة بالتزامات Git.

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

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

  • يمكن إنشاء التزام فارغ لا يغير أي ملفات، ولكن سيتم تغيير علامة Docker الخاصة بالصورة.
  • يمكن إنشاء التزام دمج لا يغير الملفات، ولكن سيتم تغيير علامة Docker الخاصة بالصورة.
  • يمكن إجراء التزام لتغيير تلك الملفات الموجودة في Git والتي لم يتم استيرادها إلى الصورة، وسيتم تغيير علامة Docker الخاصة بالصورة مرة أخرى.

وضع علامة على اسم فرع Git لا يعكس إصدار الصورة

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

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

إذا بدأ المستخدم في المخطط الحالي في إعادة بناء التزام قديم مرتبط بفرع معين، فسيقوم werf بإعادة كتابة الصورة باستخدام علامة Docker المقابلة مع نسخة حديثة من الصورة للالتزام القديم. تتعرض عمليات النشر باستخدام هذه العلامة من الآن فصاعدًا لخطر سحب نسخة مختلفة من الصورة عند إعادة تشغيل البودات، ونتيجة لذلك سيفقد تطبيقنا الاتصال بنظام 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، يُنصح بتبديل المشاريع القديمة إلى نظام العلامات الجديد، ولكن القديم علامة أو فرع لا يزال مدعوما.

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

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

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

PS

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

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

إضافة تعليق