ProHoster > وبلاگ > اداره > نکات و ترفندهای Kubernetes: در مورد توسعه محلی و حضور از راه دور

نکات و ترفندهای Kubernetes: در مورد توسعه محلی و حضور از راه دور

نکات و ترفندهای Kubernetes: در مورد توسعه محلی و حضور از راه دور

به طور فزاینده ای در مورد توسعه میکروسرویس ها در Kubernetes سؤال می شود. توسعه دهندگان، به ویژه زبان های تفسیر شده، می خواهند به سرعت کد را در IDE مورد علاقه خود تصحیح کنند و نتیجه را بدون منتظر ساختن/استقرار مشاهده کنند - فقط با فشار دادن F5. و وقتی نوبت به یک برنامه یکپارچه رسید، کافی بود یک پایگاه داده و یک وب سرور (در Docker، VirtualBox...) را به صورت محلی نصب کنید و بلافاصله از توسعه لذت ببرید. با برش مونولیت ها به میکروسرویس ها و ورود کوبرنت ها، با ظهور وابستگی ها به یکدیگر، همه چیز کمی سخت تر شد. هر چه تعداد این میکروسرویس ها بیشتر باشد، مشکلات بیشتر می شود. برای اینکه دوباره از توسعه لذت ببرید، باید بیش از یک یا دو کانتینر Docker و گاهی اوقات حتی بیش از یک دوجین بالا ببرید... به طور کلی، همه اینها می تواند زمان زیادی را ببرد، زیرا باید به روز نگه داشته شود. .

در زمان‌های مختلف ما راه‌حل‌های مختلفی را برای حل مشکل امتحان کردیم. و من با راه حل های انباشته شده یا به سادگی "عصا" شروع خواهم کرد.

1. عصا

اکثر IDE ها توانایی ویرایش کد مستقیماً روی سرور را با استفاده از FTP/SFTP دارند. این مسیر بسیار واضح است و ما بلافاصله تصمیم گرفتیم از آن استفاده کنیم. ماهیت آن به موارد زیر خلاصه می شود:

  1. در غلاف محیط‌های توسعه (dev/review)، یک کانتینر اضافی با دسترسی SSH و ارسال کلید عمومی SSH توسعه‌دهنده راه‌اندازی می‌شود که برنامه را متعهد/استقرار می‌کند.
  2. در مرحله اولیه (در داخل ظرف prepare-app) کد را به emptyDirبرای دسترسی به کد از کانتینرهای برنامه و سرور SSH.

نکات و ترفندهای Kubernetes: در مورد توسعه محلی و حضور از راه دور

برای درک بهتر اجرای فنی چنین طرحی، بخش هایی از پیکربندی های YAML درگیر در Kubernetes را ارائه خواهم داد.

پیکربندی

1.1. ارزش ها.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 در هاب وجود نداشته است.

خلاصه، معلوم شد که همه چیز چندان ترسناک نیست. ما تمام اقداماتی را که نیاز به اجرا دارند از سوی توسعه‌دهنده در یک فایل متنی Helm chart قرار دادیم NOTES.txt. بنابراین، پس از استقرار سرویس در Kubernetes، توسعه‌دهنده دستورالعمل‌هایی را برای راه‌اندازی محیط توسعه‌دهنده محلی در گزارش کار 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 چه اتفاقی می افتد؟

کار با Telepresence

هنگام راه اندازی (با استفاده از آخرین دستور مشخص شده در دستورالعمل های بالا)، ما تنظیم می کنیم:

  • فضای نامی که میکروسرویس در آن اجرا می شود.
  • نام استقرار و کانتینری که می خواهیم به آن نفوذ کنیم.

آرگومان های باقی مانده اختیاری هستند. اگر سرویس ما با و برای Kubernetes API تعامل داشته باشد ServiceAccount ایجاد شد، باید گواهی ها/توکن ها را روی دسکتاپ خود نصب کنیم. برای این کار از گزینه استفاده کنید --mount=true (یا --mount=/dst_path، که ریشه (/) را از ظرف Kubernetes به دسکتاپ ما سوار می کند. پس از این، ما می توانیم (بسته به سیستم عامل و نحوه راه اندازی برنامه) از "کلیدهای" خوشه استفاده کنیم.

ابتدا، بیایید به جهانی ترین گزینه برای اجرای یک برنامه - در ظرف Docker نگاه کنیم. برای این کار از کلید استفاده می کنیم --docker-run و دایرکتوری با کد را در کانتینر سوار کنید: -v `pwd`:/app

لطفاً توجه داشته باشید که این فرض بر این است که از دایرکتوری پروژه اجرا شود. کد برنامه در دایرکتوری نصب می شود /app در یک ظرف

بعدی: -v /tmp/app/var/run/secrets:/var/run/secrets - برای سوار کردن دایرکتوری با گواهی/ژتون در یک ظرف.

این گزینه در نهایت با تصویری که برنامه در آن اجرا می شود دنبال می شود. NB: هنگام ساخت تصویر باید مشخص کنید CMD یا ENTRYPOINT!

بعد دقیقا چه اتفاقی خواهد افتاد؟

  • در Kubernetes، برای Deployment مشخص شده، تعداد Replica ها به 0 تغییر خواهد کرد. در عوض، یک Deployment جدید راه اندازی خواهد شد - با یک کانتینر جایگزین backend.
  • 2 کانتینر روی دسکتاپ راه اندازی می شود: اولی با Telepresence (از/به Kubernetes درخواست های پراکسی می کند)، دومی با برنامه در حال توسعه.
  • اگر در کانتینر برنامه اجرا کنیم، تمام متغیرهای ENV منتقل شده توسط Helm در حین استقرار در دسترس ما خواهند بود و تمام خدمات نیز در دسترس خواهند بود. تنها چیزی که باقی می ماند این است که کد را در IDE مورد علاقه خود ویرایش کنید و از نتیجه لذت ببرید.
  • در پایان کار، فقط باید ترمینالی که Telepresence در آن اجرا می شود را ببندید (جلسه را با Ctrl+C خاتمه دهید) - ظروف Docker روی دسکتاپ متوقف می شوند و در Kubernetes همه چیز به حالت اولیه خود باز می گردد. تنها چیزی که باقی می ماند این است که متعهد شوید، MR را صادر کنید و آن را به بررسی/ادغام/... منتقل کنید (بسته به گردش کار شما).

اگر نمی‌خواهیم برنامه را در یک ظرف Docker اجرا کنیم - برای مثال، ما نه در PHP، بلکه در Go توسعه می‌دهیم و همچنان آن را به صورت محلی می‌سازیم - راه‌اندازی Telepresence حتی ساده‌تر خواهد بود:

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

اگر برنامه به API Kubernetes دسترسی داشته باشد، باید دایرکتوری کلیدها (https://www.telepresence.io/howto/volumes) را نصب کنید. یک ابزار برای لینوکس وجود دارد ریشه:

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

پس از راه اندازی Telepresence بدون گزینه --docker-run تمام متغیرهای محیطی در ترمینال فعلی در دسترس خواهند بود، بنابراین برنامه باید در آن راه اندازی شود.

NB: هنگام استفاده به عنوان مثال از PHP، باید به یاد داشته باشید که op_cache، apc و دیگر شتاب دهنده ها را برای توسعه غیرفعال کنید - در غیر این صورت ویرایش کد به نتیجه دلخواه منجر نمی شود.

نمایش نتایج: از

توسعه محلی با Kubernetes مشکلی است که راه حل آن متناسب با گسترش این پلت فرم در حال رشد است. با دریافت درخواست‌های مربوطه از توسعه‌دهندگان (از مشتریانمان)، ما شروع به حل آنها با اولین ابزارهای موجود کردیم، که با این حال، در طولانی مدت خود را ثابت نکرد. خوشبختانه این امر نه تنها در حال حاضر و نه تنها برای ما آشکار شده است، بنابراین ابزارهای مناسب تری در حال حاضر در جهان ظاهر شده اند و Telepresence معروف ترین آنها است (به هر حال، همچنین وجود دارد داربست از گوگل). تجربه ما از استفاده از آن هنوز چندان عالی نیست، اما در حال حاضر دلیلی به ما می دهد تا آن را به "همکاران در فروشگاه" خود توصیه کنیم - آن را امتحان کنید!

PS

موارد دیگر از سری نکات و ترفندهای K8s:

منبع: www.habr.com

اضافه کردن نظر