تمت مناقشة موضوع المخزون الإكتروني أكثر من مرة ، وكقاعدة عامة ، يتسبب في نقاش نشط للغاية. إنشاء
werf كأداة مفتوحة المصدر مصممة لتحسين عملية
تجميع رمز التطبيق من صور Git إلى Docker (وتسليمها لاحقًا إلى Kubernetes) ، لا نفكر كثيرًا في الخيار الأفضل. بالنسبة لنا ، من الأساسي توفير كل ما هو ضروري لأنصار الآراء المختلفة (إذا كان هذا لا يتعارض مع المنطق السليم ، بالطبع).
يعد الدعم الأخير لـ mono-repo in werf مثالاً جيدًا. لكن أولاً ، دعونا نرى كيف يرتبط هذا الدعم عمومًا باستخدام werf وما علاقة Docker Registry به ...
مشاكل
تخيل هذا الموقف. الشركة لديها العديد من فرق التطوير المشاركة في مشاريع مستقلة. تعمل معظم التطبيقات على Kubernetes ، وبالتالي ، يتم نقلها في حاويات. لتخزين الحاويات والصور ، مطلوب سجل. تستخدم الشركة Docker Hub مع حساب
COMPANY واحد كهذا السجل. على غرار معظم أنظمة تخزين الكود المصدري ،
لا يسمح لك Docker Hub بإنشاء تسلسل هرمي متداخل لمستودعات التخزين مثل
COMPANY/PROJECT/IMAGE . في هذه الحالة ... كيف يمكن الاحتفاظ بتطبيقات غير متجانسة في السجل بهذا التقييد دون إنشاء حساب منفصل لكل مشروع؟
ربما يكون الموقف الموصوف مألوفًا لشخص ما بشكل مباشر ، ولكن دعنا نفكر في مسألة تنظيم تخزين التطبيقات بشكل عام ، أي دون الرجوع إلى المثال أعلاه و Docker Hub.
طرق الحل
إذا كان التطبيق
مترابطًا ، يتم
عرضه في صورة واحدة ، ثم لا توجد أسئلة ونقوم فقط بحفظ الصور في مستودع المشروع.
عندما يتم تقديم الطلب في شكل عدة مكونات ، خدمات
microservices ، فمن الضروري اختيار نهج معين. باستخدام مثال لتطبيق ويب نموذجي يتكون من صورتين:
frontend backend ، الخيارات الممكنة هي كما يلي:
- تخزين الصور في مستودعات متداخلة منفصلة:
- قم بتخزين كل شيء في مستودع واحد ، واتخذ اسم الصورة في العلامة ، على سبيل المثال ، على النحو التالي:
ملحوظة : في الواقع ، لا يزال هناك خيار لتخزين PROJECT-frontend PROJECT-backend و PROJECT-backend في مستودعات مختلفة ، لكننا لن ننظر في الأمر بسبب تعقيد الدعم والتنظيم وتوزيع الحقوق بين المستخدمين.دعم Werf
في البداية ، اقتصر werf على المستودعات المتداخلة - لحسن الحظ ، تدعم معظم السجلات هذه الميزة. بدءًا من الإصدار
v1.0.4-alpha.3 ، تمت إضافة العمل مع السجلات التي
لا يتم
دعم التداخل فيها ، و Docker Hub بينها. من هذه اللحظة ، كان لدى المستخدم خيار كيفية تخزين صور التطبيق.
يتوفر التطبيق كجزء من الخيار
--images-repo-mode=multirepo|monorepo (افتراضيًا ،
multirepo ، أي التخزين في مستودعات متداخلة). إنه يحدد الأنماط التي يتم بها تخزين الصور في السجل. يكفي اختيار الوضع المرغوب فيه عند استخدام الأوامر الأساسية ، وسيظل كل شيء آخر على حاله.
نظرًا لأن معظم خيارات werf يمكن ضبطها
بمتغيرات البيئة ، في أنظمة CI / CD ، يكون وضع التخزين سهلًا على المستوى العالمي للمشروع بأكمله. على سبيل المثال ،
في حالة GitLab ، فقط أضف متغير البيئة في إعدادات المشروع:
الإعدادات -> CI / CD -> المتغيرات: WERF_IMAGES_REPO_MODE: multirepo|monorepo .
إذا تحدثنا عن نشر الصور وتطبيق التطبيقات (يمكنك قراءة المزيد حول هذه العمليات في المقالات المقابلة من الوثائق:
نشر العملية وعملية النشر ) ، فإن الوضع يحدد بشكل حصري القالب الذي يمكنك من خلاله العمل مع الصورة.
الشيطان بالتفصيل
الفرق والصعوبة الرئيسية عند إضافة طريقة تخزين جديدة هي أثناء عملية تنظيف السجل
(للاطلاع على خيارات التنظيف التي يدعمها werf ، راجع عملية التنظيف ) .
عند التنظيف ، يأخذ werf في الاعتبار الصور المستخدمة في مجموعات Kubernetes ، وكذلك السياسات التي يهيئها المستخدم. تستند السياسات إلى تقسيم العلامات إلى استراتيجيات. الاستراتيجيات المدعومة حاليا:
- 3 الاستراتيجيات المتعلقة بالحركة البدائية ، مثل العلامة والفرع والالتزام ؛
- 1 استراتيجية للعلامات المخصصة.
نقوم بحفظ المعلومات حول استراتيجية العلامات عند نشر الصورة في تسميات الصورة النهائية. المعنى نفسه - ما يسمى
علامة التعريف - ضروري لتطبيق بعض السياسات. على سبيل المثال ، عند حذف فرع أو علامة من مستودع Git ، من المنطقي حذف الصور
غير المستخدمة المرتبطة من السجل ، والتي يتم تغطيتها بواسطة جزء من سياساتنا.
عند الحفظ في مستودع واحد (
monorepo ) ، بالإضافة إلى علامة التعريف ، يمكن أيضًا تخزين اسم الصورة في علامة الصورة:
PROJECT: frontend -META-TAG . لفصلها ، لم نقدم أي فاصل محدد ، لكننا ببساطة أضفنا القيمة اللازمة إلى تسمية الصورة النهائية عند النشر.
ملحوظة : إذا كنت مهتمًا بالنظر في كل ما تم وصفه في الكود المصدري ، يمكن أن يكون PR 1684 بمثابة نقطة انطلاق.في هذه المقالة ، لن نولي مزيدًا من الاهتمام للمشكلات ومبررات النهج الذي نتبعه: حول استراتيجيات وضع العلامات وتخزين البيانات في الملصقات وعملية النشر ككل - تم توضيح كل ذلك بالتفصيل في تقرير أصدره مؤخرًا ديمتري ستولياروف: "
werf هي أداتنا لـ CI / CD في Kubernetes . "
تلخيص
لم يكن الافتقار إلى دعم السجل دون تداخل عامل حظر لنا أو المستخدمين الذين عرفناهم - يمكنك دائمًا رفع سجل صور منفصل (أو التبديل إلى "حاوية حاوية" الشرطية في Google Cloud) ... ومع ذلك ، فإن إزالة هذا التقييد بدا منطقياً لجعل الأداة أكثر ملاءمة المجتمع DevOps واسعة. عند تنفيذه ، واجهنا الصعوبة الرئيسية في معالجة آلية تنظيف سجل الحاوية. الآن بعد أن أصبح كل شيء جاهزًا ، من الجيد أن نعرف أنه أصبح أكثر سهولة بالنسبة لشخص ما ، ونحن (كمطورين رئيسيين للمشروع) لا نواجه صعوبات كبيرة في زيادة دعم هذه الميزة.
ابق معنا قريبًا
وسنخبرك عن الابتكارات الأخرى في
مجال !
PS
اقرأ أيضًا في مدونتنا: