نصائح وحيل Kubernetes: حول التنمية المحلية و Telepresence

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

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

1. العكازات

معظم IDEs لديها القدرة على تحرير الشفرة مباشرة على الخادم باستخدام FTP / SFTP. هذه الطريقة واضحة للغاية وقررنا استخدامها على الفور. جوهرها على النحو التالي:

1. في حافظة بيئات التطوير (تطوير / مراجعة) ، يتم تشغيل حاوية إضافية مع إمكانية الوصول عبر SSH وإعادة توجيه مفتاح SSH العام للمطور الذي سيقوم بتنفيذ / نشر التطبيق.
2. في مرحلة التهيئة (داخل حاوية prepare-app ) نقوم بنقل الكود إلى emptyDir أجل الوصول إلى الكود من الحاويات التي تحتوي على التطبيق وخادم SSH.

لفهم أفضل للتنفيذ التقني لمثل هذا المخطط ، سأقدم شظايا من تكوينات YAML المعنية في Kubernetes.

تكوينات

1.1. values.yaml

 ssh_pub_key: vasya.pupkin: <ssh public key in base64> 

هنا vasya.pupkin هي قيمة المتغير ${GITLAB_USER_LOGIN} .

1.2. deployment.yaml

 ... {{ if eq .Values.global.debug "yes" }} volumes: - name: ssh-pub-key secret: defaultMode: 0600 secretName: {{ .Chart.Name }}-ssh-pub-key - name: app-data emptyDir: {} initContainers: - name: prepare-app {{ tuple "backend" . | include "werf_container_image" | indent 8 }} volumeMounts: - name: app-data mountPath: /app-data command: ["bash", "-c", "cp -ar /app/* /app-data/" ] {{ end }} containers: {{ if eq .Values.global.debug "yes" }} - name: ssh image: corbinu/ssh-server volumeMounts: - name: ssh-pub-key readOnly: true mountPath: /root/.ssh/authorized_keys subPath: authorized_keys - name: app-data mountPath: /app ports: - name: ssh containerPort: 22 protocol: TCP {{ end }} - name: backend volumeMounts: {{ if eq .Values.global.debug "yes" }} - name: app-data mountPath: /app {{ end }} command: ["/usr/sbin/php-fpm7.2", "--fpm-config", "/etc/php/7.2/php-fpm.conf", "-F"] ... 

1.3. secret.yaml

 {{ if eq .Values.global.debug "yes" }} apiVersion: v1 kind: Secret metadata: name: {{ .Chart.Name }}-ssh-pub-key type: Opaque data: authorized_keys: "{{ first (pluck .Values.global.username .Values.ssh_pub_key) }}" {{ end }} 

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

بعد ذلك ، يبقى فقط تمرير المتغيرات الضرورية إلى gitlab-ci.yml :

 dev: stage: deploy script: - type multiwerf && source <(multiwerf use 1.0 beta) - type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose) - werf deploy --namespace ${CI_PROJECT_NAME}-stage --set "global.env=stage" --set "global.git_rev=${CI_COMMIT_SHA}" --set "global.debug=yes" --set "global.username=${GITLAB_USER_LOGIN}" tags: - build 

Voila: يمكن للمطور الذي أطلق عملية النشر الاتصال باستخدام اسم الخدمة ( قلنا لك بالفعل كيفية إصدار الوصول إلى الكتلة بأمان) من سطح المكتب عبر SFTP وتعديل الرمز دون انتظار تسليمها إلى المجموعة.

هذا حل فعال تمامًا ، ولكن من وجهة نظر التنفيذ ، فإن له عيوبًا واضحة:

• الحاجة إلى تحسين مخطط هيلم ، مما يزيد من تعقيد قراءته ؛
• يمكن فقط لشخص قام بنشر الخدمة استخدامه ؛
• تحتاج إلى تذكر مزامنته مع الدليل المحلي مع الرمز والالتزام في Git.

2. التواجد عن بعد

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

باختصار ، لم يكن الأمر مخيفًا للغاية. جميع الإجراءات التي تتطلب التنفيذ من قبل المطور ، وضعناها في ملف نصي من مخطط Helm ، يسمى NOTES.txt . وبالتالي ، يرى المطور بعد نشر الخدمة في Kubernetes تعليمات لبدء بيئة dev المحلية في سجل وظائف GitLab:

 !!!   ,   Kubernetes !!! *   * *       VPN * *     kubectl ( https://kubernetes.io/docs/tasks/tools/install-kubectl/ ) * *  config-  kubectl (  ~/.kube/config) * *     telepresence ( https://www.telepresence.io/reference/install ) * *    Docker * *    reporter     https://gitlab.site.com/group/app * *    registry  /  GitLab (  ): ######################################################################### docker login registry.site.com ######################################################################### *   ######################################################################### telepresence --namespace {{ .Values.global.env }} --swap-deployment {{ .Chart.Name }}:backend --mount=/tmp/app --docker-run -v `pwd`:/app -v /tmp/app/var/run/secrets:/var/run/secrets -ti registry.site.com/group/app/backend:v8 ######################################################################### 

لن نتطرق إلى الخطوات الموضحة في هذا الدليل ... باستثناء الأخير. ماذا يحدث أثناء إطلاق Telepresence؟

العمل مع التواجد عن بعد

في البداية (حسب آخر أمر تم تحديده في الإرشادات أعلاه) ، قمنا بتعيين:

• مساحة الاسم (مساحة الاسم) التي يتم فيها تشغيل خدمة microservice ؛
• أسماء النشر والحاوية التي نريد اختراقها.

الوسائط المتبقية اختيارية. إذا كانت خدمتنا تتفاعل مع Kubernetes API وتم إنشاء ServiceAccount لها ، فنحن نحتاج إلى تحميل الشهادات / الرموز المميزة على سطح مكتبنا. للقيام بذلك ، استخدم الخيار - --mount=true (أو - --mount=/dst_path ) ، والذي سيحمل الجذر (/) من الحاوية في Kubernetes إلى سطح مكتبنا. بعد ذلك ، يمكننا (اعتمادًا على نظام التشغيل وطريقة تشغيل التطبيق) استخدام "المفاتيح" من المجموعة.

أولاً ، فكر في خيار تشغيل التطبيق الأكثر تنوعًا - في حاوية Docker. للقيام بذلك ، استخدم --docker-run التبديل --docker-run وقم بتحميل الدليل مع الكود الموجود في الحاوية: -v `pwd`:/app

يرجى ملاحظة أن هذا ينطوي على بدء من الدليل مع المشروع. سيتم تثبيت رمز /app في دليل /app في الحاوية.

التالي: -v /tmp/app/var/run/secrets:/var/run/secrets - لتحميل الدليل مع الشهادة / الرمز المميز في الحاوية.

يتبع هذا الخيار أخيرًا الصورة التي سيتم تشغيل التطبيق بها. ملاحظة : عند إنشاء صورة ، يجب عليك تحديد CMD أو ENTRYPOINT !

ماذا سيحدث بعد ذلك؟

• في Kubernetes ، بالنسبة للنشر المحدد ، سيتم تغيير عدد النسخ المتماثلة إلى 0. وبدلاً من ذلك ، سيتم إطلاق نشر جديد - مع الحاوية backend المستبدلة.
• على سطح المكتب ، سيتم تشغيل حاويتين: الأولى - مع Telepresence (ستقوم بالاتصال بالطلبات من / إلى Kubernetes) والثانية - مع تطوير التطبيق.
• إذا كانت exec'nitsya في الحاوية مع التطبيق ، فسنكون قادرين على الوصول إلى جميع المتغيرات ENV التي مرت بها هيلم أثناء النشر ، وكذلك جميع الخدمات المتاحة. كل ما تبقى هو تعديل الكود في IDE المفضل لديك والاستمتاع بالنتيجة.
• في نهاية العمل ، قم ببساطة بإغلاق المحطة حيث يتم تشغيل Telepresence (إنهاء الجلسة باستخدام Ctrl + C) ، ستتوقف حاويات Docker على سطح المكتب ، وسيعود كل شيء إلى حالته الأصلية في Kubernetes. كل ما تبقى هو الالتزام وإصدار MR وتمريره للمراجعة / دمج / ... (اعتمادًا على مهام سير العمل).

إذا كنا لا نريد تشغيل التطبيق في حاوية Docker - على سبيل المثال ، فإننا نقوم بتطويره ليس في PHP ، ولكن في Go ، ولا نزال نجمعه محليًا - سيكون إطلاق Telepresence أسهل:

 telepresence --namespace {{ .Values.global.env }} --swap-deployment {{ .Chart.Name }}:backend --mount=true 

إذا وصل التطبيق إلى Kubernetes API ، فستحتاج إلى تحميل الدليل بالمفاتيح . لنظام التشغيل Linux ، هناك أداة مساعدة proot :

 proot -b $TELEPRESENCE_ROOT/var/run/secrets/:/var/run/secrets bash 

بعد بدء Telepresence بدون --docker-run ، ستكون جميع متغيرات البيئة متاحة في الجهاز الطرفي الحالي ، لذلك تحتاج إلى بدء تشغيل التطبيق فيه.

ملحوظة : عند استخدام ، على سبيل المثال ، PHP ، تحتاج إلى أن تتذكر تعطيل مختلف op_cache و apc وغيرها من المسرعات للتنمية - وإلا فإن تحرير الكود لن ينتج النتيجة المرجوة.

النتائج

التنمية المحلية مع Kubernetes هي مشكلة تتزايد حاجتها إلى الحل بما يتناسب مع انتشار هذه المنصة. بعد تلقي الطلبات ذات الصلة من المطورين (من عملائنا) ، بدأنا في حلها بأول الوسائل المتاحة ، والتي ، ومع ذلك ، لم تثبت نفسها على مسافة طويلة. لحسن الحظ ، أصبح هذا واضحًا ليس فقط الآن وليس فقط بالنسبة لنا ، لذلك ظهرت بالفعل وسائل أكثر ملاءمة في العالم ، وتعد Telepresence أشهرها (بالمناسبة ، لا يزال هناك skaffold من Google). تجربتنا في استخدامه ليست كبيرة ، ولكنها تعطي بالفعل سببًا للتوصية بـ "الزملاء" - جربه!

PS

بخلاف دورة نصائح وحيل K8s:

• " أدوات لمطوري التطبيقات التي تعمل على Kubernetes " ؛
• نصائح وحيل Kubernetes: صفحات خطأ مخصصة في NGINX Ingress ؛
• " نقل الموارد في مجموعة إلى إدارة هيلم 2 " ؛
• " بشأن تخصيص العقد والحمل على تطبيق الويب " ؛
• " الوصول إلى مواقع ديف " ؛
• " تسريع التمهيد لقواعد البيانات الكبيرة. "