Kubernetes: بناء صور عامل الميناء في كتلة

يمكنك استخدام kaniko لإنشاء صور Docker في حاوية أثناء الاستغناء عن Docker. دعونا نتعرف على كيفية تشغيل kaniko محليًا وفي مجموعة Kubernetes.

القادم سيكون كتاب متعدد

لنفترض أنك قررت إنشاء صور Docker في مجموعة Kubernetes (حسنًا ، تحتاج إلى). ما هو مناسب ، دعونا نلقي نظرة على مثال حقيقي ، بشكل أكثر وضوحًا.

سنتحدث أيضًا عن Docker-in-Docker وعن بديلها ، kaniko ، والذي يمكنك من خلاله إنشاء صور Docker دون استخدام Docker. أخيرًا ، سوف نتعلم كيفية تكوين تجميع الصور في مجموعة Kubernetes.

يوجد وصف عام ل Kubernetes في كتاب "Kubernetes in Action" ("Kubernetes in Action") .

مثال حقيقي

في الويب الأصلي ، لدينا العديد من صور Docker الخاصة التي يجب تخزينها في مكان ما. لذلك قمنا بتطبيق Docker Hub الخاص . يحتوي Docker Hub العام على ميزتين نعتني بهما بشكل خاص.

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

عادةً ما يتم استخدام Docker CLI مباشرة لتنفيذ هذه الوظائف:

$ docker build ... $ docker push ... 

لكن في نظام Kubernetes ، نستضيف حاويات استنادًا إلى صور Linux صغيرة أو أولية ، حيث لا يتم تضمين Docker افتراضيًا. إذا أردنا الآن استخدام Docker (مثل docker build... ) في حاوية ، فنحن بحاجة إلى شيء مثل Docker-in-Docker.

ما هو الخطأ في دوكر دوكر؟

لجمع صور الحاوية في Docker ، نحتاج إلى برنامج Docker قيد التشغيل في الحاوية ، وهو Docker-in-Docker. برنامج Docker daemon هو بيئة افتراضية ، والحاوية في Kubernetes هي بمفردها. وهذا هو ، إذا كنت ترغب في تشغيل البرنامج الخفي Docker في حاوية ، تحتاج إلى استخدام الافتراضية المتداخلة. للقيام بذلك ، قم بتشغيل الحاوية في الوضع المميز - للوصول إلى النظام المضيف. ولكن هذا يثير مشكلات أمنية: على سبيل المثال ، يجب عليك العمل مع أنظمة ملفات مختلفة (مضيف وحاوية) أو استخدام ذاكرة التخزين المؤقت للبناء من النظام المضيف. لهذا السبب لم نرغب في لمس Docker-in-Docker.

التعارف مع كانيكو

لا Docker-in-Docker وحدها ... هناك حل آخر - kaniko . هذه هي أداة مكتوبة في Go ، فهي تجمع الصور الحاوية من Dockerfile بدون Docker. ثم يرسلها إلى سجل Docker المحدد. يوصى بتكوين kaniko - استخدم صورة تنفيذية جاهزة يمكن تشغيلها كحاوية Docker أو حاوية في Kubernetes.

فقط ضع في اعتبارك أن kaniko لا يزال قيد التطوير ولا يدعم جميع أوامر Dockerfile ، على سبيل المثال - --chownflag COPY .

إطلاق Kaniko

إذا كنت ترغب في تشغيل kaniko ، فأنت بحاجة إلى تحديد عدة وسيطات لحاوية kaniko. قم أولاً بإدراج Dockerfile بكل تبعياته في حاوية kaniko. محلياً (في Docker) ، يتم -v <__>:<__> المعلمة -v <__>:<__> لهذا ، ويحتوي Kubernet على وحدات تخزين .

بعد إدراج Dockerfile التبعية في حاوية kaniko ، أضف الوسيطة --context ، فإنه يشير إلى المسار إلى الدليل المرفق (داخل الحاوية). الوسيطة التالية هي - --dockerfile . يشير إلى المسار إلى Dockerfile (بما في ذلك الاسم). وسيطة أخرى مهمة هي --destination مع عنوان URL الكامل لسجل Docker (بما في ذلك الاسم وعلامة الصورة).

الاطلاق المحلي

يبدأ Kaniko بعدة طرق. على سبيل المثال ، على الكمبيوتر المحلي باستخدام Docker (حتى لا تعبث مع نظام Kubernetes). قم بتشغيل kaniko باستخدام الأمر التالي:

 $ docker run \ -v $(pwd):/workspace \ gcr.io/kaniko-project/executor:latest \ --dockerfile=<path-to-dockerfile> \ --context=/workspace \ --destination=<repo-url-with-image-name>:<tag> 

في حالة تمكين المصادقة في سجل Docker ، يجب أولاً تسجيل الدخول إلى kaniko. للقيام بذلك ، قم بتوصيل config.jsonfile Docker المحلي بأوراق اعتماد سجل Docker إلى حاوية kaniko باستخدام الأمر التالي:

 $ docker run \ -v $(pwd):/workspace \ -v ~/.docker/config.json:/kaniko/.docker/config.json \ gcr.io/kaniko-project/executor:latest \ --dockerfile=<path-to-dockerfile> \ --context=/workspace \ --destination=<repo-url-with-image-name>:<tag> 

إطلاق في Kubernetes

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

أسهل طريقة هي حقن Dockerfile التبعية في حاوية kaniko باستخدام كائن PersistentVolumeClaim (في مثالنا ، يطلق عليه kaniko-workspace ). سيتم ربطها بالحاوية كدليل ، ويجب أن تكون جميع البيانات موجودة بالفعل في kaniko-workspace . دعنا نقول في حاوية أخرى يوجد بالفعل Dockerfile مع التبعيات في الدليل /my-build في kaniko-workspace .

لا تنس أنه في مشكلة AWS مع PersistentVolumeClaim. إذا قمت بإنشاء PersistentVolumeClaim في AWS ، فستظهر على عقدة واحدة فقط في نظام المجموعة AWS وستتوفر فقط هناك. (محدث: في الواقع ، عند إنشاء PVC ، سيتم إنشاء وحدة تخزين RDS في منطقة توفر عشوائي للمجموعة الخاصة بك. وبناءً على ذلك ، سيكون هذا المجلد متاحًا لجميع الأجهزة في هذه المنطقة. تتحكم Kubernetes نفسها في إطاره باستخدام هذه الـ PVC على عقدة في منطقة الإتاحة RDS volyuma. - تقريبًا.) لذلك ، إذا قمت بتشغيل Job kaniko وكانت هذه المهمة على عقدة أخرى ، فلن تبدأ ، لأن PersistentVolumeClaim غير متاح. دعونا نأمل أن يكون نظام ملفات الأمازون المرن متاحًا على Kubernetes قريبًا وستزول المشكلة. (محدثًا: يتم دعم EFS في Kubernetes بواسطة مزود التخزين . - تقريبًا )

عادةً ما يبدو مورد الوظيفة لبناء صور Docker كما يلي:

 apiVersion: batch/v1 kind: Job metadata: name: build-image spec: template: spec: containers: - name: build-image image: gcr.io/kaniko-project/executor:latest args: - "--context=/workspace/my-build" - "--dockerfile=/workspace/my-build/Dockerfile" - "--destination=<repo-url-with-image-name>:<tag>" volumeMounts: - name: workspace mountPath: /workspace volumes: - name: workspace persistentVolumeClaim: claimName: kaniko-workspace restartPolicy: Never backoffLimit: 3 

إذا كان السجل Docker الوجهة يتطلب المصادقة ، فقم بتمرير ملف config.json باستخدام بيانات الاعتماد إلى حاوية kaniko. أسهل طريقة هي توصيل PersistentVolumeClaim بحاوية تحتوي بالفعل على ملف config.json . سيتم تحميل PersistentVolumeClaim هنا ليس كدليل ، بل كملف في المسار /kaniko/.docker/config.json في حاوية /kaniko/.docker/config.json :

 apiVersion: batch/v1 kind: Job metadata: name: build-image spec: template: spec: containers: - name: build-image image: gcr.io/kaniko-project/executor:latest args: - "--context=/workspace/my-build" - "--dockerfile=/workspace/my-build/Dockerfile" - "--destination=<repo-url-with-image-name>:<tag>" volumeMounts: - name: config-json mountPath: /kaniko/.docker/config.json subPath: config.json - name: workspace mountPath: /workspace volumes: - name: config-json persistentVolumeClaim: claimName: kaniko-credentials - name: workspace persistentVolumeClaim: claimName: kaniko-workspace restartPolicy: Never backoffLimit: 3 

إذا كنت تريد التحقق من حالة مهمة kubectl ، فاستخدم kubectl . لتصفية الحالة عن طريق stdout ، قم بتشغيل الأمر:

 $ kubectl get job build-image -o go-template='{{(index .status.conditions 0).type}}' 

ملخص

لقد تعلمت من المقالة عندما Docker-in-Docker غير مناسب لبناء صور Docker في Kubernetes. حصلت على فكرة عن kaniko - بديل لـ Docker-in-Docker ، حيث يتم تجميع صور Docker بدون Docker. لقد تعلمنا أيضًا كيفية كتابة موارد الوظيفة لجمع صور Docker في Kubernetes. وأخيرًا ، رأوا كيفية اكتشاف حالة المهمة المستمرة.