التجميع الديناميكي ونشر صور Docker باستخدام werf باستخدام موقع مثال للوثائق التي تم إصدارها

لقد تحدثنا بالفعل عن أداة gitOps werf الخاصة بنا أكثر من مرة ، لكننا نود هذه المرة مشاركة تجربة بناء الموقع مع وثائق المشروع - werf.io (نسخته الروسية هي ru.werf.io ). هذا موقع ثابت ثابت ، ولكن التجميع مثير للاهتمام لأنه مبني باستخدام عدد ديناميكي من القطع الأثرية.



انتقل إلى الفروق الدقيقة في بنية الموقع: إنشاء قائمة عامة لجميع الإصدارات والصفحات التي تحتوي على معلومات حول الإصدارات ، إلخ. - نحن لن نفعل. بدلاً من ذلك ، نركز على مشكلات وميزات التجميع الديناميكي وقليلًا على عمليات CI / CD المصاحبة.

مقدمة: كيف يتم ترتيب الموقع

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

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

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

يتوفر أحدث إصدار من werf في كل قناة في قائمة اختيار الإصدار على الموقع. بشكل افتراضي ، يتم فتح إصدار القناة الأكثر ثباتًا للإصدار الأخير على werf.io/documentation - يتم فهرستها أيضًا بواسطة محركات البحث. تتوفر وثائق القناة على عناوين فردية (على سبيل المثال ، werf.io/v1.0-beta/documentation للإصدار التجريبي 1.0).

المجموع ، يحتوي الموقع على الإصدارات التالية:

1. الجذر (يفتح بشكل افتراضي)
2. لكل قناة تحديث نشطة لكل إصدار (على سبيل المثال ، werf.io/v1.0-beta ).

لإنشاء إصدار معين من موقع في الحالة العامة ، يكفي jekyll build باستخدام أدوات Jekyll عن طريق تشغيل الأمر المناسب ( jekyll build ) في دليل /docs لمستودع werf ، بعد التبديل إلى علامة Git للإصدار المطلوب.

يبقى فقط لإضافة ما يلي:

• الأداة المساعدة نفسها (werf) تستخدم للتجميع ؛
• تستند عمليات CI / CD إلى GitLab CI ؛
• وكل هذا ، بالطبع ، يعمل في Kubernetes.

المهام

نقوم الآن بصياغة المهام التي تأخذ في الاعتبار جميع التفاصيل الموضحة:

1. بعد تغيير إصدار werf على أي قناة تحديث ، يجب تحديث الوثائق الموجودة على الموقع تلقائيًا .
2. للتطوير ، يجب أن تكون قادرًا على عرض الإصدارات الأولية للموقع من حين لآخر.

يجب إجراء إعادة تجميع الموقع بعد تغيير الإصدار على أي قناة من علامات Git المقابلة ، ولكن في عملية بناء الصورة ، سنحصل على الميزات التالية:

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

اتضح أن التجميع يعتمد على تغيير البيانات الخارجية .

تطبيق

اختيار النهج

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

ذهبنا على طريق تجميع جميع الإصدارات اللازمة في صورة واحدة . توجد احصائيات مجمعة لجميع إصدارات الموقع في حاوية مع NGINX ، وتأتي حركة المرور إلى النشر المقابل من خلال NGINX Ingress. بنية بسيطة - تطبيق عديم الحالة - تجعل من السهل توسيع نطاق التوزيع (حسب الحمل) باستخدام Kubernetes نفسه.

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

werf vs git clone والتحف

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

هنا تأتي أداة werf لمساعدتك في تنفيذ التخزين المؤقت الذكي وتسمح باستخدام المستودعات الخارجية . سيؤدي استخدام werf لإضافة رمز من المستودع إلى تسريع عملية الإنشاء بشكل كبير تقوم werf أساسًا باستنساخ المستودع مرة واحدة ، ثم يتم fetch فقط إذا لزم الأمر. بالإضافة إلى ذلك ، عند إضافة بيانات من المستودع ، يمكننا فقط تحديد الأدلة اللازمة (في حالتنا ، هذا هو دليل docs ) ، مما يقلل بشكل كبير من كمية البيانات المضافة.

نظرًا لأن Jekyll هي أداة مصممة لتجميع الإحصائيات وليست ضرورية في الصورة النهائية ، فسيكون من المنطقي تجميعها في قطعة أثرية ، واستيراد نتيجة التحويل البرمجي فقط إلى الصورة النهائية.

الكتابة werf.yaml

لذلك ، قررنا أن نقوم بتجميع كل إصدار في قطعة أثرية منفصلة. ومع ذلك ، لا نعرف كم من هذه القطع الفنية ستكون أثناء التجميع ، وبالتالي لا يمكننا كتابة تكوين تجميع ثابت (بالمعنى الدقيق للكلمة ، لا يزال بإمكاننا ذلك ، لكنه لن يكون فعالًا تمامًا).

يتيح لك werf استخدام قوالب Go في ملف التكوين الخاص بك ( werf.yaml ) ، وهذا يجعل من الممكن إنشاء تهيئة " werf.yaml " اعتمادًا على البيانات الخارجية (ما تحتاجه!). البيانات الخارجية في حالتنا هي معلومات حول الإصدارات والإصدارات ، والتي على أساسها نجمع العدد الضروري من القطع الأثرية ونتيجة لذلك ، نحصل على صورتين: werf-doc و werf-dev للعمل على مسارات مختلفة.

يتم تمرير البيانات الخارجية من خلال متغيرات البيئة. هنا هو تكوينها:

• RELEASES - سطر مع قائمة الإصدارات والإصدار الحالي المقابل من werf ، في شكل قائمة ، مفصولة بمسافة ، بالتنسيق <_>%<_> . مثال: 1.0%v1.0.4-beta.20
• CHANNELS - سطر يحتوي على قائمة من القنوات والإصدار الحالي المقابل من werf ، في شكل قائمة ذات فراغ قيم في التنسيق <>%<_> . مثال: 1.0-beta%v1.0.4-beta.20 1.0-alpha%v1.0.5-alpha.22
• ROOT_VERSION - إصدار إصدار werf للعرض بشكل افتراضي على الموقع (ليس من الضروري دائمًا عرض الوثائق لأعلى رقم إصدار). مثال: v1.0.4-beta.20
• REVIEW_SHA - تجزئة الالتزام بالمراجعة التي تحتاج منها إلى تجميع إصدار حلقة الاختبار.

سيتم ملؤها هذه المتغيرات في خط أنابيب GitLab CI ، وكيف بالضبط هو موضح أدناه.

أولاً وقبل كل شيء ، من أجل الراحة ، نقوم بتعريف متغيرات Go-template في werf.yaml تعيين قيم لها من متغيرات البيئة:

 {{ $_ := set . "WerfVersions" (cat (env "CHANNELS") (env "RELEASES") | splitList " ") }} {{ $Root := . }} {{ $_ := set . "WerfRootVersion" (env "ROOT_VERSION") }} {{ $_ := set . "WerfReviewCommit" (env "REVIEW_SHA") }} 

وصف قطعة أثرية لتجميع احصائيات إصدار الموقع هو نفسه عمومًا بالنسبة لجميع الحالات التي نحتاجها (بما في ذلك إنشاء إصدار الجذر ، بالإضافة إلى إصدار دائرة dev). لذلك ، سنضعها في كتلة منفصلة باستخدام دالة التعريف - لإعادة استخدامها لاحقًا مع include . سنقوم بتمرير الوسائط التالية إلى القالب:

• Version - إصدار تم إنشاؤه (اسم العلامة) ؛
• Channel - اسم قناة التحديث التي يتم إنشاء الأداة بها ؛
• Commit - تجزئة التجزئة إذا تم إنشاء قطعة أثرية لمراجعة الالتزام ؛
• السياق.

يجب أن يكون اسم قطعة أثرية فريدًا. يمكننا تحقيق ذلك ، على سبيل المثال ، عن طريق إضافة اسم القناة (قيمة المتغير .Channel ) لاحقة لاسم قطعة أثرية: artifact: doc-{{ .Channel }} . لكن عليك أن تفهم أنه عند الاستيراد من القطع الأثرية ، ستحتاج إلى الرجوع إلى نفس الأسماء.

عند وصف قطعة أثرية ، يتم استخدام ميزة werf مثل mount . يسمح لك التثبيت باستخدام دليل خدمة build_dir بحفظ ذاكرة التخزين المؤقت Jekyll بين خطوط الأنابيب ، مما يسرع عملية إعادة البناء بشكل كبير .

ربما لاحظت أيضًا استخدام ملف releases.yml - هذا هو ملف YAML مع بيانات الإصدار المطلوبة من github.com (الأداة التي تم الحصول عليها عن طريق تنفيذ خط الأنابيب). تكون هناك حاجة عند تجميع الموقع ، ولكن في سياق المقالة ، نحن مهتمون بحقيقة أن قطعة أثرية واحدة فقط ، وهي قطعة أثرية لنسخة إصدار الموقع ، تعتمد على حالتها (في الأعمال الفنية الأخرى لا تكون هناك حاجة إليها).

يتم تطبيق ذلك باستخدام عامل التشغيل if go و {{ $Root.Files.Get "releases.yml" | sha256sum }} {{ $Root.Files.Get "releases.yml" | sha256sum }} في مرحلة المسرح . يعمل هذا كالتالي: عند تجميع قطعة أثرية لإصدار الجذر (المتغير .Channel هو root ) ، يؤثر تجزئة ملف .Channel على توقيع المرحلة بأكملها ، لأنه عنصر من مكونات اسم Ansible job (معلمة name ). وبالتالي ، عند تغيير محتويات ملف releases.yml ، سيتم إعادة بناء الأداة المقابلة.

انتبه أيضًا للعمل مع مستودع خارجي. تتم إضافة دليل /docs فقط إلى صورة قطعة أثرية من مستودع werf ، ووفقًا للمعلمات التي تم تمريرها ، تتم إضافة بيانات العلامة اللازمة أو التزام المراجعة على الفور.

لاستخدام قالب artifact لإنشاء وصف artifact للإصدارات المنقولة من القنوات والإصدارات ، ننظم حلقة على المتغير .WerfVersions في werf.yaml :

 {{ range .WerfVersions -}} {{ $VersionsDict := splitn "%" 2 . -}} {{ dict "Version" $VersionsDict._1 "Channel" $VersionsDict._0 "Root" $Root | include "doc_artifact" }} --- {{ end -}} 

لأن سوف تولد الحلقة العديد من القطع الأثرية (نأمل ذلك) ، من الضروري مراعاة الفاصل بينهما - التسلسل --- (لمزيد من المعلومات حول بناء جملة ملف التكوين ، انظر الوثائق ). وفقًا لما تم تحديده مسبقًا ، عند استدعاء القالب في حلقة ، نقوم بتمرير معلمات الإصدار وعنوان URL وسياق الجذر.

وبالمثل ، ولكن بدون حلقة ، ندعو قالب قطعة أثرية إلى "الحالات الخاصة": للإصدار الجذر ، وكذلك الإصدار من الالتزام المراجعة:

 {{ dict "Version" .WerfRootVersion "Channel" "root" "Root" $Root | include "doc_artifact" }} --- {{- if .WerfReviewCommit }} {{ dict "Version" "review" "Channel" "review" "Commit" .WerfReviewCommit "Root" $Root | include "doc_artifact" }} {{- end }} 

يرجى ملاحظة أنه لن يتم جمع .WerfReviewCommit المراجعة إلا إذا تم .WerfReviewCommit متغير .WerfReviewCommit .

القطع الأثرية جاهزة - حان وقت الاستيراد!

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


تحتوي الصورة الإضافية ، التي يتم عرضها ، إلى جانب الصورة الرئيسية ، على دارة dev ، على نسختين فقط من الموقع: الإصدار من مراجعة الالتزام والإصدار الجذر للموقع (توجد أصول عامة ، وإذا كنت تتذكر ، فقم بإصدار البيانات). وبالتالي ، فإن الصورة الإضافية من الصورة الرئيسية ستختلف فقط في قسم الاستيراد (وبالطبع ، في الاسم):

 image: werf-dev ... import: - artifact: doc-root add: /app/_main_site to: /app/main_site before: setup - artifact: doc-root add: /app/_ru_site to: /app/ru_site before: setup {{- if .WerfReviewCommit }} - artifact: doc-review add: /app/_main_site to: /app/main_site/review before: setup - artifact: doc-review add: /app/_ru_site to: /app/ru_site/review before: setup {{- end }} 

كما هو مذكور أعلاه ، لن يتم إنشاء قطعة أثرية لالتزام المراجعة فقط عندما يبدأ REVIEW_SHA متغير البيئة REVIEW_SHA . قد لا يكون من الممكن إنشاء صورة werf-dev على الإطلاق إذا لم يكن هناك REVIEW_SHA بيئة REVIEW_SHA ، ولكن حتى يتم تنظيف سياسات werf المستندة إلى werf لصور Docker للعمل مع صورة werf-dev ، فإننا نتركها يتم جمعها فقط مع قطعة أثرية إصدار الجذر (على أي حال ، تجميعها بالفعل) ، لتبسيط هيكل خط الأنابيب.

الجمعية جاهزة! نمر إلى CI / CD والفروق الدقيقة الهامة.

خط أنابيب في GitLab CI وميزات التجميع الديناميكي

عند بدء التجميع ، نحتاج إلى تعيين متغيرات البيئة المستخدمة في werf.yaml . لا ينطبق هذا على متغير REVIEW_SHA ، الذي سنقوم بتعيينه عند استدعاء خط الأنابيب من خطاف GitHub.

سنقوم بإنشاء البيانات الخارجية الضرورية في البرنامج النصي Bash الخاص بـ create_artifacts ، والذي سينتج عنه تحصيلان GitLab في خط أنابيب:

• releases.yml ملف مع بيانات الإصدار ،
• ملف common_envs.sh يحتوي على متغيرات البيئة للتصدير.

ستجد محتويات ملف generate_artifacts في مستودع مثالنا . الحصول على البيانات ليس موضوع المقالة ، ولكن ملف common_envs.sh مهم بالنسبة لنا ، لأن عمل werf يعتمد عليه. مثال على محتوياته:

 export RELEASES='1.0%v1.0.6-4' export CHANNELS='1.0-alpha%v1.0.7-1 1.0-beta%v1.0.7-1 1.0-ea%v1.0.6-4 1.0-stable%v1.0.6-4 1.0-rock-solid%v1.0.6-4' export ROOT_VERSION='v1.0.6-4' 

يمكنك استخدام إخراج مثل هذا البرنامج النصي ، على سبيل المثال ، باستخدام وظيفة Bash source .

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

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

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

سوف نستقبل ونلتقط بيانات خارجية في المرحلة الأولى من خط الأنابيب في GitLab ( Prebuild ) وننقلها إلى أبعد من ذلك كأداة GitLab CI . سيسمح لك ذلك ببدء وإعادة تشغيل مهام خطوط الأنابيب (إنشاء ونشر وتنظيف) بنفس التكوين في werf.yaml .

محتويات مرحلة Prebuild لملف .gitlab - ci.yml :

 Prebuild: stage: prebuild script: - bash ./generate_artifacts 1> common_envs.sh - cat ./common_envs.sh artifacts: paths: - releases.yml - common_envs.sh expire_in: 2 week 

عن طريق التقاط البيانات الخارجية في أحد القطع الأثرية ، يمكنك إنشاء ونشر باستخدام مراحل خط أنابيب GitLab CI القياسية: الإنشاء والنشر. نطلق خط الأنابيب بخطافات من مستودع gerHub werf (على سبيل المثال عند تغيير المخزون في GitHub). يمكن أخذ البيانات الخاصة بهم في خصائص مشروع GitLab في إعدادات CI / CD -> قسم مشغلات خطوط الأنابيب ، ثم إنشاء Webhook المطابق ( الإعدادات -> Webhooks ) في GitHub.

ستبدو مرحلة الإنشاء كما يلي:

 Build: stage: build script: - type multiwerf && . $(multiwerf use 1.0 alpha --as-file) - type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose) - source common_envs.sh - werf build-and-publish --stages-storage :local except: refs: - schedules dependencies: - Prebuild 

ستضيف GitLab اثنين من الأعمال الفنية من مرحلة Prebuild إلى مرحلة البناء ، لذلك نحن تصدير المتغيرات مع المدخلات المعدة باستخدام source common_envs.sh . نبدأ مرحلة التجميع في جميع الحالات ، باستثناء إطلاق خط الأنابيب في الموعد المحدد. وفقًا للجدول الزمني ، سيتم إطلاق خط الأنابيب للتنظيف - لا نحتاج إلى الإنشاء في هذه الحالة.

في مرحلة النشر ، نصف مهمتين - بشكل منفصل للنشر إلى دوائر الإنتاج و dev ، باستخدام قالب YAML:

 .base_deploy: &base_deploy stage: deploy script: - type multiwerf && . $(multiwerf use 1.0 alpha --as-file) - type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose) - source common_envs.sh - werf deploy --stages-storage :local dependencies: - Prebuild except: refs: - schedules Deploy to Production: <<: *base_deploy variables: WERF_KUBE_CONTEXT: prod environment: name: production url: werf.io only: refs: - master except: variables: - $REVIEW_SHA refs: - schedules Deploy to Test: <<: *base_deploy variables: WERF_KUBE_CONTEXT: dev environment: name: test url: werf.test.flant.com except: refs: - schedules only: variables: - $REVIEW_SHA 

تختلف المهام بشكل أساسي فقط عن طريق الإشارة إلى سياق الكتلة الذي يجب أن يقوم werf بتنفيذ عملية النشر ( WERF_KUBE_CONTEXT ) فيه وتحديد متغيرات البيئة الخاصة WERF_KUBE_CONTEXT ( environment.name و environment.url ) ، والتي يتم استخدامها بعد ذلك في قوالب مخطط Helm. لن يتم إعطاء محتوى القوالب ، لا يوجد شيء مثير للاهتمام لهذا الموضوع ، ولكن يمكنك العثور عليه في مستودع المقالات .

اللمسة النهائية

منذ إصدار إصدارات werf في كثير من الأحيان ، سيتم جمع صور جديدة في كثير من الأحيان ، وسوف ينمو Docker Registry باستمرار. لذلك ، من الضروري تكوين التنظيف التلقائي للصور حسب السياسة. من السهل جدا القيام به.

للتنفيذ سوف تحتاج:

• أضف خطوة تطهير إلى .gitlab-ci.yml ؛
• إضافة مهام التنظيف الدورية.
• تعيين متغير البيئة مع رمز وصول الكتابة.

أضف مرحلة التنظيف إلى .gitlab-ci.yml :

 Cleanup: stage: cleanup script: - type multiwerf && . $(multiwerf use 1.0 alpha --as-file) - type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose) - source common_envs.sh - docker login -u nobody -p ${WERF_IMAGES_CLEANUP_PASSWORD} ${WERF_IMAGES_REPO} - werf cleanup --stages-storage :local only: refs: - schedules 

لقد رأينا جميعًا تقريبًا هذا أعلى قليلاً - فقط للتنظيف ، تحتاج أولاً إلى تسجيل الدخول إلى Docker Registry برمز مميز له الحق في حذف الصور في Docker Registry (ليس لرمز مهمة GitLab CI الصادر تلقائيًا هذه الحقوق). يجب إدخال الرمز المميز في GitLab مسبقًا ويجب تحديد قيمته في متغير البيئة WERF_IMAGES_CLEANUP_PASSWORD للمشروع (إعدادات CI / CD -> متغيرات) .

تتم إضافة مهمة التنظيف مع الجدول الزمني الضروري في CI / CD ->
جداول.

هذا كل شيء: لن ينمو المشروع في Docker Registry باستمرار من الصور غير المستخدمة.

في نهاية الجزء العملي ، أتذكر أن القوائم الكاملة من المقالة متوفرة في Git :

• .gitlab-ci.yml ؛
• werf.yaml .

يؤدي

1. حصلنا على بنية بنية منطقية: قطعة أثرية واحدة لكل إصدار.
2. التجميع عالمي ولا يتطلب تغييرات يدوية عند إصدار إصدارات جديدة من werf: يتم تحديث الوثائق الموجودة على الموقع تلقائيًا.
3. يتم جمع صورتين لمحيطات مختلفة.
4. انها تعمل بسرعة ل يتم استخدام التخزين المؤقت إلى الحد الأقصى - عند إصدار إصدار جديد من werf أو استدعاء ربط GitHub لالتزام المراجعة ، تتم إعادة إنشاء قطعة أثرية مماثلة فقط مع نسخة معدلة.
5. لا داعي للتفكير في حذف الصور غير المستخدمة: سيؤدي تنظيف سياسة werf إلى الحفاظ على النظام في Docker Registry.

النتائج

• يسمح استخدام werf للتجميع بالعمل بسرعة بفضل التخزين المؤقت لكل من التجميع نفسه والتخزين المؤقت عند العمل مع المستودعات الخارجية.
• Git- . werf , fetch .
• Go- werf.yaml , .
• werf — , pipeline.
• werf , .

PS

:

• « Kubernetes »;
• « werf GitLab CI »;
• « werf Helm- »;
• « werf 1.0 stable: GitOps, ».