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