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 . 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:
- 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.
- Dastlabki bosqichda (konteyner ichida
prepare-app) kodni o'tkazingemptyDirdastur konteynerlari va SSH serveridan kodga kirish huquqiga ega bo'lish.
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 :
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, ) 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 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 , 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=trueAgar ilovangiz Kubernetes API-ga kirsa, siz katalogni kalitlar bilan o'rnatishingiz kerak bo'ladi (https://www.telepresence.io/howto/volumes). Linux yordamchi dastur mavjud :
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. 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
