ProHoster > Blog > Ma'muriyat > Kubernetes maslahatlari va fokuslari: mahalliy rivojlanish va Telepresence haqida

Kubernetes maslahatlari va fokuslari: mahalliy rivojlanish va Telepresence haqida

Kubernetes maslahatlari va fokuslari: mahalliy rivojlanish va Telepresence haqida

Bizdan Kubernetes-da mikroservislarni ishlab chiqish haqida ko'proq so'rashadi. Ishlab chiquvchilar, ayniqsa talqin qilinadigan tillar, F5 tugmasini bosish orqali o'zlarining sevimli IDE-dagi kodni tezda tuzatishni va natijani yaratish/o'rnatishni kutmasdan ko'rishni xohlashadi. Va monolit dastur haqida gap ketganda, ma'lumotlar bazasi va veb-serverni (Docker, VirtualBox-da ...) mahalliy o'rnatish va keyin darhol rivojlanishdan zavqlanish kifoya edi. Monolitlarni mikroservislarga kesish va Kubernetesning kelishi bilan bir-biriga bog'liqlik paydo bo'lishi bilan hamma narsa biroz qiyinlashdi. Ushbu mikroservislar qancha ko'p bo'lsa, muammolar shunchalik ko'p bo'ladi. Rivojlanishdan yana zavq olish uchun siz bir yoki ikkitadan ortiq Docker konteynerlarini, ba'zan esa o'ndan ortiq konteynerlarni ko'tarishingiz kerak ... Umuman olganda, bularning barchasi juda ko'p vaqtni olishi mumkin, chunki uni ham yangilab turish kerak. .

Turli vaqtlarda biz muammoning turli xil echimlarini sinab ko'rdik. Va men to'plangan vaqtinchalik echimlar yoki oddiygina "tayoqchalar" bilan boshlayman.

1. Qo'ltiq tayoqchalari

Ko'pgina IDElar FTP/SFTP yordamida to'g'ridan-to'g'ri serverda kodni tahrirlash imkoniyatiga ega. Bu yo'l juda aniq va biz darhol undan foydalanishga qaror qildik. Uning mohiyati quyidagilardan iborat:

  1. Rivojlanish muhitida (dev/review) qo'shimcha konteyner ishga tushiriladi va SSH-ga kirish va dasturni amalga oshiradigan/joylashtiradigan ishlab chiquvchining umumiy SSH kalitini yo'naltiradi.
  2. Dastlabki bosqichda (konteyner ichida prepare-app) kodni o'tkazing emptyDirdastur konteynerlari va SSH serveridan kodga kirish huquqiga ega bo'lish.

Kubernetes maslahatlari va fokuslari: mahalliy rivojlanish va Telepresence haqida

Bunday sxemaning texnik amalga oshirilishini yaxshiroq tushunish uchun men Kubernetes-da YAML konfiguratsiyasining qismlarini taqdim etaman.

Konfiguratsiya

1.1. qadriyatlar.yaml

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

u vasya.pupkin o'zgaruvchining qiymati hisoblanadi ${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. maxfiy.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 }}

oxirgi teginish

Shundan so'ng faqat transfer qilish qoladi zarur gitlab-ci.yml o'zgaruvchilari:

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: joylashtirishni ishga tushirgan ishlab chiquvchi xizmat nomi bo'yicha ulanishi mumkin (klasterga qanday qilib xavfsiz kirishni ta'minlash, allaqachon aytdik) SFTP orqali ish stolingizdan o'ting va kodni klasterga yetkazilishini kutmasdan tahrirlang.

Bu to'liq ishlaydigan yechim, ammo amalga oshirish nuqtai nazaridan u aniq kamchiliklarga ega:

  • Helm diagrammasini takomillashtirish zarurati, bu kelajakda o'qishni qiyinlashtiradi;
  • faqat xizmatdan foydalangan shaxs foydalanishi mumkin;
  • keyin uni mahalliy katalog bilan kod bilan sinxronlashtirishni va uni Git-ga topshirishni unutmasligingiz kerak.

2. Telepresensiya

Loyiha Telepresensiya anchadan beri ma'lum, ammo biz, ular aytganidek, "amalda jiddiy sinab ko'rishga ulgurmadik". Biroq, talab o'z ishini bajardi va endi biz o'z tajribamizni baham ko'rishdan mamnunmiz, bu bizning blogimiz o'quvchilari uchun foydali bo'lishi mumkin - ayniqsa, telepresence haqida hali markazda boshqa materiallar mavjud emas.

Qisqasi, hamma narsa unchalik qo'rqinchli emas edi. Biz ishlab chiquvchi tomonidan bajarilishini talab qiladigan barcha amallarni Helm diagrammasi matn fayliga joylashtirdik. NOTES.txt. Shunday qilib, xizmatni Kubernetes-ga o'rnatgandan so'ng, ishlab chiquvchi GitLab ish jurnalida mahalliy ishlab chiquvchi muhitni ishga tushirish bo'yicha ko'rsatmalarni ko'radi:

!!! Π Π°Π·Ρ€Π°Π±ΠΎΡ‚ΠΊΠ° сСрвиса локально, Π² составС 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
#########################################################################

Biz ushbu yo'riqnomada tasvirlangan qadamlar haqida batafsil to'xtalmaymiz ... oxirgisi bundan mustasno. Telepresence ishga tushirilganda nima sodir bo'ladi?

Telepresence bilan ishlash

Ishga tushganda (yuqoridagi ko'rsatmalarda ko'rsatilgan oxirgi buyruq yordamida) biz quyidagilarni o'rnatamiz:

  • mikroservis ishlayotgan nomlar maydoni;
  • biz kirmoqchi bo'lgan joylashtirish va konteyner nomlari.

Qolgan argumentlar ixtiyoriy. Agar bizning xizmatimiz Kubernetes API bilan o'zaro aloqada bo'lsa ServiceAccount yaratildi, biz sertifikatlar/tokenlarni ish stolimizga o'rnatishimiz kerak. Buning uchun variantdan foydalaning --mount=true (yoki --mount=/dst_path), bu ildizni (/) Kubernetes konteyneridan ish stolimizga o'rnatadi. Shundan so'ng, biz (OTga va dastur qanday ishga tushirilganiga qarab) klasterdagi "kalitlar" dan foydalanishimiz mumkin.

Birinchidan, dasturni ishga tushirishning eng universal variantini - Docker konteynerida ko'rib chiqaylik. Buning uchun biz kalitdan foydalanamiz --docker-run va katalogni kod bilan konteynerga o'rnating: -v `pwd`:/app

Esda tutingki, bu loyiha katalogidan ishlashni nazarda tutadi. Ilova kodi katalogga o'rnatiladi /app konteynerda.

Keyingi: -v /tmp/app/var/run/secrets:/var/run/secrets β€” sertifikat/token bilan katalogni konteynerga oβ€˜rnatish.

Nihoyat, ushbu parametrdan so'ng dastur ishlaydigan rasm paydo bo'ladi. NB: Tasvirni yaratishda siz belgilashingiz kerak CMD yoki ENTRYPOINT!

Keyinchalik aniq nima bo'ladi?

  • Kubernetesda ko'rsatilgan joylashtirish uchun replikalar soni 0 ga o'zgartiriladi. Buning o'rniga yangi joylashtirish ishga tushiriladi - o'rnini bosuvchi konteyner bilan backend.
  • Ish stolida 2 ta konteyner ishga tushadi: birinchisi Telepresence bilan (u Kubernetes-dan/proksi-server so'rovlarini oladi), ikkinchisi dastur ishlab chiqilayotganda.
  • Agar biz dastur bilan konteynerga o'tkazsak, u holda Helm tomonidan tarqatish paytida uzatilgan barcha ENV o'zgaruvchilari biz uchun mavjud bo'ladi va barcha xizmatlar ham mavjud bo'ladi. Faqat sevimli IDE-dagi kodni tahrirlash va natijadan bahramand bo'lish qoladi.
  • Ish oxirida siz Telepresence ishlayotgan terminalni yopishingiz kerak bo'ladi (Ctrl+C bilan sessiyani to'xtating) - Docker konteynerlari ish stolida to'xtaydi va Kubernetesda hamma narsa dastlabki holatiga qaytadi. Qolgan narsa - MRni topshirish, berish va uni ko'rib chiqish/birlashtirish/... (ish oqimlaringizga qarab) o'tkazish.

Agar biz dasturni Docker konteynerida ishga tushirishni istamasak, masalan, biz PHP-da emas, balki Go-da ishlab chiqamiz va baribir uni mahalliy sifatida quramiz - Telepresence-ni ishga tushirish yanada osonlashadi:

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

Agar ilova Kubernetes API-ga kirsa, siz kalitlar katalogini o'rnatishingiz kerak bo'ladi (https://www.telepresence.io/howto/volumes). Linux uchun yordamchi dastur mavjud ildiz:

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

Variantsiz Telepresence-ni ishga tushirgandan so'ng --docker-run barcha muhit o'zgaruvchilari joriy terminalda mavjud bo'ladi, shuning uchun dastur unda ishga tushirilishi kerak.

NB: Masalan, PHP dan foydalanayotganda turli xil op_cache, apc va boshqa tezlatkichlarni ishlab chiqish uchun o'chirib qo'yishni unutmang - aks holda kodni tahrirlash istalgan natijaga olib kelmaydi.

natijalar

Kubernetes bilan mahalliy rivojlanish muammo bo'lib, uning yechimi ushbu platformaning tarqalishiga mutanosib ravishda o'sib bormoqda. Ishlab chiquvchilardan (mijozlarimizdan) tegishli so'rovlarni qabul qilib, biz ularni birinchi mavjud vositalar bilan hal qila boshladik, ammo bu uzoq vaqt davomida o'zini isbotlay olmadi. Yaxshiyamki, bu nafaqat hozir, balki biz uchun ham ayon bo'ldi, shuning uchun dunyoda ko'proq mos vositalar allaqachon paydo bo'lgan va Telepresence ularning eng mashhuridir (aytmoqchi, bu erda ham bor. skaffold Google'dan). Uni ishlatish bo'yicha bizning tajribamiz hali unchalik katta emas, lekin bu allaqachon uni "do'kondagi hamkasblarimizga" tavsiya qilishimizga asos beradi - sinab ko'ring!

PS

K8s maslahatlar va fokuslar seriyasidan boshqa:

Manba: www.habr.com

a Izoh qo'shish