أن تأتي متأخرا أفضل من ألا تأتي أبدا. أو كيف اقتربنا من ارتكاب خطأ جسيم من خلال عدم وجود دعم لملفات Dockerfiles العادية لإنشاء صور التطبيق.
سيكون حول - أداة GitOps التي تتكامل مع أي نظام CI / CD وتوفر إدارة دورة حياة التطبيق بالكامل ، مما يتيح لك:
- جمع ونشر الصور ،
- نشر التطبيقات على Kubernetes ،
- حذف الصور غير المستخدمة باستخدام سياسات خاصة.
تتمثل فلسفة المشروع في تجميع الأدوات منخفضة المستوى في نظام موحد واحد يمنح مهندسي DevOps التحكم في التطبيقات. إذا أمكن ، يجب استخدام المرافق الموجودة (مثل Helm و Docker). إذا لم يكن هناك حل لبعض المشاكل ، فيمكننا إنشاء وصيانة كل ما هو ضروري لذلك.
الخلفية: جامع الصور الخاص بك
هذا ما حدث مع منشئ الصور في werf: لقد افتقرنا إلى Dockerfile المعتاد. إذا انغمست لفترة وجيزة في تاريخ المشروع ، فقد تجلت هذه المشكلة بالفعل في الإصدارات الأولى من werf (ثم ).
أثناء إنشاء أداة لإنشاء التطبيقات في صور Docker ، أدركنا بسرعة أن Dockerfile لم يكن مناسبًا لنا لبعض المهام المحددة للغاية:
- الحاجة إلى تجميع تطبيقات الويب الصغيرة النموذجية وفقًا للمخطط القياسي التالي:
- تثبيت تبعيات التطبيق على مستوى النظام ،
- تثبيت حزمة من مكتبات تبعية التطبيق ،
- جمع الأصول ،
- والأهم من ذلك ، تحديث الكود في الصورة بسرعة وكفاءة.
- عند إجراء تغييرات على ملفات المشروع ، يجب على المنشئ إنشاء طبقة جديدة بسرعة عن طريق تصحيح الملفات التي تم تغييرها.
- إذا تغيرت ملفات معينة ، فيجب إعادة بناء المرحلة التابعة المقابلة.
اليوم ، هناك العديد من الاحتمالات الأخرى في صنبورنا ، لكن الرغبات والحوافز الأولية كانت على النحو التالي.
بشكل عام ، دون التفكير مرتين ، قمنا بتسليح أنفسنا بلغة البرمجة المستخدمة (انظر أدناه) وضرب الطريق - للتنفيذ DSL الخاصة! وفقًا لمجموعة المهام ، كان القصد من وصف عملية الإنشاء على مراحل وتحديد تبعيات هذه المراحل على الملفات. واستكملها صنبور خاص، والتي حولت DSL إلى الهدف النهائي - الصورة المجمعة. في البداية كان DSL في Ruby ، ولكن مثل - بدأ وصف تكوين أداة التجميع الخاصة بنا في ملف YAML.
التكوين القديم لـ dapp in Ruby
التكوين الفعلي لـ werf على YAML
تغيرت آلية المجمع أيضًا بمرور الوقت. في البداية ، قمنا ببساطة بإنشاء بعض Dockerfile المؤقت من التهيئة الخاصة بنا بسرعة ، ثم بدأنا في تشغيل تعليمات الإنشاء في حاويات مؤقتة وإجراء الالتزام.
NB: في الوقت الحالي ، تم تطوير أداة البناء الخاصة بنا ، والتي تعمل مع التكوين الخاص بها (في YAML) والتي تسمى Stapel builder ، بالفعل لتصبح أداة قوية إلى حد ما. يستحق وصفه التفصيلي مقالات منفصلة ، ويمكن العثور على التفاصيل الرئيسية في .
الوعي بالمشكلة
لكننا أدركنا ، وليس على الفور ، أننا ارتكبنا خطأً واحداً: لم نضف القدرة بناء الصور من خلال Dockerfile قياسي ودمجها في نفس البنية التحتية لإدارة التطبيقات من طرف إلى طرف (أي جمع الصور ونشرها وتنظيفها). كيف يمكنك إنشاء أداة نشر في Kubernetes وعدم تنفيذ دعم Dockerfile ، أي طريقة قياسية لوصف الصور لمعظم المشاريع؟ ..
بدلاً من الإجابة على مثل هذا السؤال ، نقدم الحل. ماذا لو كان لديك بالفعل Dockerfile (أو مجموعة من Dockerfiles) وتريد استخدام werf؟
NB: بالمناسبة ، لماذا تريد حتى استخدام werf؟ تتلخص الميزات الرئيسية في ما يلي:
- دورة إدارة التطبيق الكاملة بما في ذلك تنظيف الصور ؛
- القدرة على إدارة تجميع عدة صور دفعة واحدة من تكوين واحد ؛
- عملية نشر محسنة للرسوم البيانية المتوافقة مع Helm.
يمكن العثور على قائمة أكثر اكتمالا في .
لذا ، إذا اقترحنا سابقًا إعادة كتابة Dockerfile إلى التكوين الخاص بنا ، يسعدنا الآن أن نقول: "دعنا نبني Dockerfiles!"
كيف تستعمل؟
ظهر التنفيذ الكامل لهذه الميزة في الإصدار . المبدأ العام بسيط: يحدد المستخدم المسار إلى Dockerfile موجود في werf config ، ثم يقوم بتشغيل الأمر werf build... وهذا كل شيء - ستبني werf الصورة. لنفكر في مثال مجرد.
دعنا نعلن التالي Dockerfile في جذر المشروع:
FROM ubuntu:18.04
RUN echo Building ...
وسنعلن werf.yamlالذي يستخدم هذا Dockerfile:
configVersion: 1
project: dockerfile-example
---
image: ~
dockerfile: ./Dockerfile
الجميع! غادر جولة werf build:
بالإضافة إلى ذلك ، يمكنك التصريح بما يلي werf.yaml لإنشاء عدة صور دفعة واحدة من Dockerfiles مختلفة:
configVersion: 1
project: dockerfile-example
---
image: backend
dockerfile: ./dockerfiles/Dockerfile-backend
---
image: frontend
dockerfile: ./dockerfiles/Dockerfile-frontend
أخيرًا ، يتم أيضًا دعم تمرير معلمات بناء إضافية - مثل --build-arg и --add-host - عبر ملف werf config. يتوفر وصف كامل لتكوين صورة Dockerfile على .
كيف يعمل؟
أثناء عملية الإنشاء ، تعمل ذاكرة التخزين المؤقت القياسية للطبقات المحلية في Docker. ومع ذلك ، من المهم ، werf أيضا يدمج تكوين Dockerfile في بنيته التحتية. ماذا يعني هذا؟
- تتكون كل صورة مبنية من Dockerfile من مرحلة واحدة تسمى
dockerfile(المزيد حول ما هي المراحل في werf ، يمكنك أن تقرأ ). - للمرحلة
dockerfileيحسب werf توقيعًا يعتمد على محتويات تكوين Dockerfile. يؤدي تغيير تكوين Dockerfile إلى تغيير توقيع المرحلةdockerfileوسيبدأ werf في إعادة بناء تلك المرحلة باستخدام تكوين Dockerfile الجديد. إذا لم يتغير التوقيع ، فإن werf يأخذ الصورة من ذاكرة التخزين المؤقت (تم وصف المزيد حول استخدام التوقيعات في werf في ). - علاوة على ذلك ، يمكن نشر الصور المجمعة بالأمر
werf publish(أوwerf build-and-publish) واستخدامها للنشر في Kubernetes. سيتم تنظيف الصور المنشورة في Docker Registry باستخدام أدوات تنظيف werf القياسية ، أي سيكون هناك تنظيف تلقائي للصور القديمة (الأقدم من N أيام) والصور المرتبطة بفروع Git غير الموجودة والسياسات الأخرى.
يمكن العثور على مزيد من التفاصيل حول النقاط الموضحة هنا في الوثائق:
- ;
- ;
- .
ملاحظات واحتياطات
1. عنوان URL الخارجي في إضافة غير مدعوم
استخدام عنوان URL خارجي في توجيه غير مدعوم حاليًا. ADD. لن يقوم Werf بتشغيل إعادة البناء عندما يتغير مورد في عنوان URL المحدد. تم التخطيط لإضافة هذه الميزة قريبًا.
2. لا يمكنك إضافة .git إلى صورة
بشكل عام ، إضافة دليل .git في صورة ممارسة سيئة شريرة ، وإليك السبب:
- إذا
.gitيبقى في الصورة النهائية ، هذا ينتهك المبادئ : نظرًا لأن الصورة الناتجة يجب أن تكون مرتبطة بالتزام واحد ، فلا ينبغي أن يكون ذلك ممكنًاgit checkoutارتكاب تعسفي. -
.gitيزيد حجم الصورة (قد يكون المستودع كبيرًا نظرًا لحقيقة أنه تمت إضافة الملفات الكبيرة إليه مرة واحدة ثم حذفها). لن يعتمد حجم شجرة العمل المرتبطة فقط بالتزام معين على تاريخ العمليات في Git. في هذه الحالة ، الإضافة والإزالة اللاحقة.gitمن الصورة النهائية لن يعمل: ستستمر الصورة في الحصول على طبقة إضافية - هذه هي الطريقة التي يعمل بها Docker. - قد يؤدي Docker إلى إعادة بناء غير ضرورية حتى لو تم إنشاء نفس الالتزام من أشجار عمل مختلفة. على سبيل المثال ، يقوم GitLab بإنشاء أدلة منفصلة مستنسخة بتنسيق
/home/gitlab-runner/builds/HASH/[0-N]/yourprojectمع تمكين التجميع المتوازي. إعادة بناء إضافية سيكون بسبب حقيقة أن الدليل.gitمختلفة في الإصدارات المختلفة المستنسخة من نفس المستودع ، حتى لو تم إنشاء نفس الالتزام.
النقطة الأخيرة لها أيضًا عواقب عند استخدام werf. يتطلب Werf وجود ذاكرة التخزين المؤقت المدمجة عند تشغيل بعض الأوامر (على سبيل المثال ، werf deploy). أثناء تنفيذ هذه الأوامر ، يحسب werf توقيعات المرحلة للصور المحددة في werf.yaml، ويجب أن يكونوا في ذاكرة التخزين المؤقت للبناء ، وإلا فلن يتمكن الأمر من المتابعة. إذا كان توقيع المراحل يعتمد على المحتوى .git، ثم نحصل على ذاكرة تخزين مؤقت غير مستقرة للتغييرات في الملفات غير ذات الصلة ، ولن تتمكن werf من التغاضي عن مثل هذا الخطأ (لمزيد من التفاصيل ، راجع ).
بشكل عام، إضافة بعض الملفات المطلوبة فقط من خلال التعليمات ADD على أي حال يزيد من كفاءة وموثوقية الكتابات Dockerfile، وكذلك يحسن استقرار ذاكرة التخزين المؤقت التي تم جمعها بواسطة هذا Dockerfile، إلى التغييرات غير ذات الصلة في Git.
مجموع
كان طريقنا الأولي في كتابة أداة البناء الخاصة بنا لتلبية احتياجات محددة صعبًا وصادقًا ومباشرًا: بدلاً من استخدام العكازات أعلى ملف Dockerfile القياسي ، كتبنا الحل الخاص بنا باستخدام بناء جملة مخصص. وهذا يعطي مزاياها: يقوم جامع Stapel بعمله على أكمل وجه.
ومع ذلك ، في عملية كتابة المنشئ الخاص بنا ، فقدنا دعم ملفات Dockerfiles الموجودة بالفعل. تم الآن إصلاح هذا النقص ، وفي المستقبل نخطط لتطوير دعم Dockerfile جنبًا إلى جنب مع أداة إنشاء Stapel المخصصة للبنى الموزعة والبناء باستخدام Kubernetes (أي البناء على العدائين داخل Kubernetes ، كما هو الحال في kaniko).
لذا ، إذا كان لديك فجأة ملفان من Dockerfiles ... محاولة !
PS قائمة الوثائق حول هذا الموضوع
- ;
- ;
- ;
- ;
- ;
- ;
- .
اقرأ أيضًا على مدونتنا:".
المصدر: www.habr.com