🥇Kubernetes تجاویز اور چالیں: مقامی ترقی اور ٹیلی پریزنس کے بارے میں

ہم سے Kubernetes میں مائیکرو سروسز تیار کرنے کے بارے میں تیزی سے پوچھا جاتا ہے۔ ڈویلپرز، خاص طور پر تشریح شدہ زبانوں کے، اپنے پسندیدہ IDE میں کوڈ کو تیزی سے درست کرنا چاہتے ہیں اور صرف F5 دبانے سے - تعمیر/تعیناتی کا انتظار کیے بغیر نتیجہ دیکھنا چاہتے ہیں۔ اور جب بات یک سنگی ایپلی کیشن کی ہو، تو مقامی طور پر ڈیٹا بیس اور ویب سرور (ڈوکر، ورچوئل باکس میں...) انسٹال کرنا کافی تھا، اور پھر فوری طور پر ترقی سے لطف اندوز ہوں۔ مائیکرو سروسز میں monoliths کے کاٹنے اور Kubernetes کی آمد کے ساتھ، ایک دوسرے پر انحصار کی ظاہری شکل کے ساتھ، سب کچھ یہ تھوڑا زیادہ مشکل ہو گیا. ان مائیکرو سروسز میں سے زیادہ، زیادہ مسائل. دوبارہ ترقی سے لطف اندوز ہونے کے لیے، آپ کو ایک یا دو سے زیادہ ڈوکر کنٹینرز اٹھانے ہوں گے، اور بعض اوقات ایک درجن سے بھی زیادہ... عام طور پر، اس سب میں کافی وقت لگ سکتا ہے، کیونکہ اسے بھی اپ ٹو ڈیٹ رکھنے کی ضرورت ہے۔ .

مختلف اوقات میں ہم نے مسئلے کے مختلف حل آزمائے۔ اور میں جمع شدہ کام یا صرف "بیساکھیوں" سے شروع کروں گا۔

1. بیساکھی

زیادہ تر IDEs میں FTP/SFTP کا استعمال کرتے ہوئے براہ راست سرور پر کوڈ میں ترمیم کرنے کی صلاحیت ہوتی ہے۔ یہ راستہ بہت واضح ہے اور ہم نے فوری طور پر اسے استعمال کرنے کا فیصلہ کیا۔ اس کا جوہر درج ذیل پر ابلتا ہے:

ترقی کے ماحول (dev/review) کے پوڈ میں، SSH رسائی کے ساتھ ایک اضافی کنٹینر لانچ کیا جاتا ہے اور اس ڈویلپر کی عوامی SSH کلید کو آگے بڑھایا جاتا ہے جو ایپلیکیشن کا ارتکاب/تعینات کرے گا۔
ابتدائی مرحلے پر (کنٹینر کے اندر prepare-app) کوڈ کو منتقل کریں۔ emptyDirایپلیکیشن کنٹینرز اور SSH سرور سے کوڈ تک رسائی حاصل کرنے کے لیے۔

ایسی اسکیم کے تکنیکی نفاذ کو بہتر طور پر سمجھنے کے لیے، میں Kubernetes میں شامل YAML کنفیگریشنز کے ٹکڑے فراہم کروں گا۔

تشکیلات

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 کے ذریعے اور کوڈ کو کلسٹر تک پہنچانے کا انتظار کیے بغیر اس میں ترمیم کریں۔

یہ ایک مکمل طور پر کام کرنے والا حل ہے، لیکن نفاذ کے نقطہ نظر سے اس کے واضح نقصانات ہیں:

ہیلم چارٹ کو بہتر کرنے کی ضرورت، جو مستقبل میں پڑھنا مشکل بناتا ہے۔
صرف وہی شخص استعمال کرسکتا ہے جس نے سروس کو تعینات کیا ہو۔
آپ کو یاد رکھنے کی ضرورت ہے کہ پھر اسے کوڈ کے ساتھ لوکل ڈائرکٹری کے ساتھ ہم آہنگ کریں اور اسے گٹ سے کمٹ کریں۔

2. ٹیلی پریزنس

پروجیکٹ ٹیلیفینس کافی عرصے سے جانا جاتا ہے، لیکن ہم، جیسا کہ وہ کہتے ہیں، "عملی طور پر اسے سنجیدگی سے آزمانے میں کامیاب نہیں ہوئے۔" تاہم، ڈیمانڈ نے اپنا کام کر دیا ہے اور اب ہمیں اپنا تجربہ بتاتے ہوئے خوشی ہو رہی ہے، جو ہمارے بلاگ کے قارئین کے لیے کارآمد ہو سکتا ہے - خاص طور پر چونکہ ابھی تک اس مرکز پر ٹیلی پریزنس کے بارے میں کوئی اور مواد موجود نہیں ہے۔

مختصر میں، سب کچھ اتنا خوفناک نہیں نکلا. ہم نے وہ تمام کارروائیاں رکھی ہیں جن کے لیے ڈویلپر کی جانب سے عمل درآمد کی ضرورت ہوتی ہے ہیلم چارٹ ٹیکسٹ فائل میں 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 کے ساتھ اور اس کے لیے تعامل کرتی ہے۔ سروس اکاؤنٹ بنایا گیا۔، ہمیں اپنے ڈیسک ٹاپ پر سرٹیفکیٹس/ٹوکنز کو ماؤنٹ کرنے کی ضرورت ہے۔ ایسا کرنے کے لیے آپشن کا استعمال کریں۔ --mount=true (یا --mount=/dst_path)، جو روٹ (/) کو کبرنیٹس کنٹینر سے ہمارے ڈیسک ٹاپ پر ماؤنٹ کرے گا۔ اس کے بعد، ہم (OS پر منحصر ہے اور ایپلیکیشن کیسے شروع کی گئی ہے) کلسٹر سے "کیز" استعمال کر سکتے ہیں۔

سب سے پہلے، آئیے ایک ڈوکر کنٹینر میں - ایپلیکیشن چلانے کے لیے سب سے عالمگیر آپشن کو دیکھیں۔ ایسا کرنے کے لیے ہم کلید استعمال کریں گے۔ --docker-run اور کوڈ کے ساتھ ڈائریکٹری کو کنٹینر میں ماؤنٹ کریں: -v `pwd`:/app

براہ کرم نوٹ کریں کہ یہ پروجیکٹ ڈائرکٹری سے چل رہا ہے۔ درخواست کوڈ ڈائریکٹری میں نصب کیا جائے گا /app ایک کنٹینر میں.

: اگلا -v /tmp/app/var/run/secrets:/var/run/secrets — سرٹیفکیٹ/ٹوکن کے ساتھ ڈائریکٹری کو کنٹینر میں ماؤنٹ کرنے کے لیے۔

یہ آپشن آخر میں اس تصویر کے بعد آتا ہے جس میں ایپلی کیشن چلے گی۔ NB: تصویر بناتے وقت، آپ کو ضرور بتانا چاہیے۔ CMD یا ENTRYPOINT!

بالکل آگے کیا ہوگا؟

Kubernetes میں، مخصوص تعیناتی کے لیے، نقل کی تعداد کو 0 میں تبدیل کر دیا جائے گا۔ اس کے بجائے، ایک نئی تعیناتی شروع کی جائے گی - ایک متبادل کنٹینر کے ساتھ backend.
2 کنٹینرز ڈیسک ٹاپ پر لانچ ہوں گے: پہلا ٹیلی پریزنس کے ساتھ (یہ Kubernetes سے/کو پراکسی درخواستیں کرے گا)، دوسرا ایپلیکیشن تیار ہونے کے ساتھ۔
اگر ہم ایپلی کیشن کے ساتھ کنٹینر میں عمل کرتے ہیں، تو تعیناتی کے دوران ہیلم کے ذریعے منتقل کیے گئے تمام ENV متغیر ہمارے لیے دستیاب ہوں گے، اور تمام خدمات بھی دستیاب ہوں گی۔ بس اپنے پسندیدہ IDE میں کوڈ میں ترمیم کرنا اور نتیجہ سے لطف اندوز ہونا باقی ہے۔
کام کے اختتام پر، آپ کو صرف وہ ٹرمینل بند کرنے کی ضرورت ہے جس میں Telepresence چل رہا ہے (Ctrl+C کے ساتھ سیشن ختم کریں) - Docker کنٹینرز ڈیسک ٹاپ پر رک جائیں گے، اور Kubernetes میں سب کچھ اپنی ابتدائی حالت میں واپس آجائے گا۔ جو کچھ باقی رہ جاتا ہے وہ ہے ارتکاب کرنا، MR جاری کرنا اور اسے جائزہ/ضمنی/… (آپ کے ورک فلو پر منحصر ہے) میں منتقل کرنا ہے۔

اگر ہم ایپلیکیشن کو ڈوکر کنٹینر میں نہیں چلانا چاہتے ہیں - مثال کے طور پر، ہم پی ایچ پی میں نہیں بلکہ گو میں تیار کرتے ہیں، اور پھر بھی اسے مقامی طور پر بناتے ہیں - ٹیلی پریزنس لانچ کرنا اور بھی آسان ہوگا:

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

اگر ایپلیکیشن Kubernetes API تک رسائی حاصل کرتی ہے، تو آپ کو کیز ڈائرکٹری (https://www.telepresence.io/howto/volumes) کو ماؤنٹ کرنے کی ضرورت ہوگی۔ لینکس کے لیے ایک افادیت ہے۔ پروٹ:

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

آپشن کے بغیر ٹیلی پریزنس لانچ کرنے کے بعد --docker-run تمام ماحولیاتی متغیرات موجودہ ٹرمینل میں دستیاب ہوں گے، اس لیے اس میں ایپلیکیشن لانچ کی جانی چاہیے۔

NB: مثال کے طور پر پی ایچ پی استعمال کرتے وقت، آپ کو ترقی کے لیے مختلف op_cache، apc اور دیگر سرعت کاروں کو غیر فعال کرنا یاد رکھنا چاہیے - بصورت دیگر کوڈ میں ترمیم کرنے سے مطلوبہ نتیجہ نہیں ملے گا۔

کے نتائج

Kubernetes کے ساتھ مقامی ترقی ایک ایسا مسئلہ ہے جس کا حل اس پلیٹ فارم کے پھیلاؤ کے تناسب سے بڑھ رہا ہے۔ ڈویلپرز (ہمارے کلائنٹس کی طرف سے) سے متعلقہ درخواستیں موصول کرتے ہوئے، ہم نے انہیں پہلے دستیاب ذرائع سے حل کرنا شروع کیا، تاہم، طویل فاصلے پر خود کو ثابت نہیں کیا۔ خوش قسمتی سے، یہ نہ صرف اب اور نہ صرف ہمارے لئے واضح ہو گیا ہے، لہذا دنیا میں پہلے ہی زیادہ مناسب ذرائع ظاہر ہو چکے ہیں، اور ٹیلی پریزنس ان میں سب سے مشہور ہے (ویسے، وہاں بھی ہے سکافولڈ گوگل سے)۔ اس کے استعمال کا ہمارا تجربہ ابھی اتنا اچھا نہیں ہے، لیکن یہ ہمیں پہلے سے ہی اپنے "دکان میں ساتھیوں" کو اس کی سفارش کرنے کی وجہ فراہم کرتا ہے - اسے آزمائیں!

PS

K8s ٹپس اینڈ ٹرکس سیریز سے دیگر:

ماخذ: www.habr.com

Kubernetes کے نکات اور چالیں: مقامی ترقی اور ٹیلی پریزنس کے بارے میں