Ne pyetemi gjithnjë e më shumë për zhvillimin e mikroshërbimeve në Kubernetes. Zhvilluesit, veçanërisht të gjuhëve të interpretuara, duan të korrigjojnë shpejt kodin në IDE-në e tyre të preferuar dhe të shohin rezultatin pa pritur për ndërtimin/vendosjen - thjesht duke shtypur F5. Dhe kur bëhej fjalë për një aplikacion monolit, mjaftonte të instaloni lokalisht një bazë të dhënash dhe një server në internet (në Docker, VirtualBox...), dhe më pas të shijoni menjëherë zhvillimin. Me prerjen e monoliteve në mikroshërbime dhe ardhjen e Kubernetes, me shfaqjen e varësive nga njëri-tjetri, gjithçka . Sa më shumë të jenë këto mikroshërbime, aq më shumë probleme. Për të shijuar përsëri zhvillimin, ju duhet të ngrini më shumë se një ose dy kontejnerë Docker, dhe ndonjëherë edhe më shumë se një duzinë... Në përgjithësi, e gjithë kjo mund të marrë mjaft kohë, pasi duhet gjithashtu të mbahet i përditësuar .
Në periudha të ndryshme kemi provuar zgjidhje të ndryshme për problemin. Dhe unë do të filloj me zgjidhjet e grumbulluara ose thjesht "paterica".
1. Paterica
Shumica e IDE-ve kanë aftësinë për të redaktuar kodin direkt në server duke përdorur FTP/SFTP. Kjo rrugë është shumë e qartë dhe menjëherë vendosëm ta përdorim. Thelbi i tij zbret në sa vijon:
- Në grupin e mjediseve të zhvillimit (dev/rishikim), lëshohet një kontejner shtesë me akses SSH dhe përcjellë çelësin publik SSH të zhvilluesit i cili do të angazhojë/shpërndajë aplikacionin.
- Në fazën fillestare (brenda enës
prepare-app) transferoni kodin teemptyDirpër të pasur akses në kodin nga kontejnerët e aplikacionit dhe serveri SSH.
Për të kuptuar më mirë zbatimin teknik të një skeme të tillë, unë do të jap fragmente të konfigurimeve të përfshira YAML në Kubernetes.
Konfigurimet
1.1. vlerat.yaml
ssh_pub_key:
vasya.pupkin: <ssh public key in base64>
Këtu vasya.pupkin është vlera e ndryshores ${GITLAB_USER_LOGIN}.
1.2. vendosje.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. sekret.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 }}
Prekja e fundit
Pas kësaj, gjithçka që mbetet është transferimi :
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: zhvilluesi që nisi vendosjen mund të lidhet me emrin e shërbimit (si të jepet në mënyrë të sigurt aksesi në grup, ) nga desktopi juaj nëpërmjet SFTP dhe modifikoni kodin pa pritur që ai të dorëzohet në grup.
Kjo është një zgjidhje plotësisht funksionale, por nga pikëpamja e zbatimit ka disavantazhe të dukshme:
- nevoja për të përmirësuar tabelën Helm, gjë që e bën të vështirë leximin në të ardhmen;
- mund të përdoret vetëm nga personi që ka vendosur shërbimin;
- ju duhet të mbani mend që më pas ta sinkronizoni atë me drejtorinë lokale me kodin dhe ta angazhoni atë në Git.
2. Teleprezenca
Projekt është njohur për një kohë të gjatë, por ne, siç thonë ata, "nuk arritëm ta provonim seriozisht në praktikë". Megjithatë, kërkesa e ka bërë punën e saj dhe tani jemi të lumtur të ndajmë përvojën tonë, e cila mund të jetë e dobishme për lexuesit e blogut tonë - veçanërisht pasi nuk ka pasur ende materiale të tjera rreth Telepresence në qendër.
Me pak fjalë, gjithçka doli të ishte jo aq e frikshme. Ne vendosëm të gjitha veprimet që kërkojnë ekzekutim nga ana e zhvilluesit në një skedar teksti të diagramit Helm të quajtur NOTES.txt. Kështu, pas vendosjes së shërbimit në Kubernetes, zhvilluesi sheh udhëzime për nisjen e mjedisit lokal të dev në regjistrin e punës 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
#########################################################################Nuk do të ndalemi në detaje në hapat e përshkruar në këtë udhëzim... me përjashtim të atij të fundit. Çfarë ndodh gjatë lansimit të Telepresence?
Puna me Telepresence
Në nisje (duke përdorur komandën e fundit të specifikuar në udhëzimet e mësipërme), vendosëm:
- hapësira e emrave në të cilën funksionon mikroshërbimi;
- emrat e dislokimit dhe kontejnerit që duam të depërtojmë.
Argumentet e mbetura janë fakultative. Nëse shërbimi ynë ndërvepron me dhe për Kubernetes API , duhet të montojmë certifikatat/shenjat në desktopin tonë. Për ta bërë këtë, përdorni opsionin --mount=true (Ose --mount=/dst_path), i cili do të montojë rrënjën (/) nga kontejneri Kubernetes në desktopin tonë. Pas kësaj, ne mund (në varësi të sistemit operativ dhe mënyrës se si lëshohet aplikacioni) të përdorim "çelësat" nga grupi.
Së pari, le të shohim opsionin më universal për ekzekutimin e një aplikacioni - në një kontejner Docker. Për ta bërë këtë ne do të përdorim çelësin --docker-run dhe montoni direktorinë me kodin në kontejner: -v `pwd`:/app
Ju lutemi vini re se kjo supozon ekzekutimin nga drejtoria e projektit. Kodi i aplikacionit do të montohet në drejtori /app në një enë.
Next: -v /tmp/app/var/run/secrets:/var/run/secrets — për të montuar drejtorinë me certifikatën/tokenin në një kontejner.
Ky opsion në fund pasohet nga imazhi në të cilin do të ekzekutohet aplikacioni. NB: Kur ndërtoni një imazh, duhet të specifikoni CMD ose ENTRYPOINT!
Çfarë saktësisht do të ndodhë më pas?
- Në Kubernetes, për vendosjen e specifikuar, numri i kopjeve do të ndryshohet në 0. Në vend të kësaj, do të nisë një vendosje e re - me një kontejner zëvendësues
backend. - 2 kontejnerë do të hapen në desktop: i pari me Telepresence (do të kërkojë proxy nga/në Kubernetes), i dyti me aplikacionin në zhvillim.
- Nëse ekzekutojmë në kontejnerin me aplikacionin, atëherë të gjitha variablat ENV të transferuara nga Helm gjatë vendosjes do të jenë të disponueshme për ne dhe të gjitha shërbimet do të jenë gjithashtu të disponueshme. E tëra që mbetet është të modifikoni kodin në IDE-në tuaj të preferuar dhe të shijoni rezultatin.
- Në fund të punës, ju vetëm duhet të mbyllni terminalin në të cilin po funksionon Telepresence (përfundoni seancën me Ctrl+C) - Kontejnerët Docker do të ndalen në desktop, dhe në Kubernetes gjithçka do të kthehet në gjendjen e saj fillestare. Gjithçka që mbetet është të angazhoheni, të lëshoni MR dhe ta transferoni atë në rishikim/bashkim/… (në varësi të rrjedhës suaj të punës).
Nëse nuk duam ta ekzekutojmë aplikacionin në një kontejner Docker - për shembull, ne zhvillojmë jo në PHP, por në Go, dhe ende e ndërtojmë atë në nivel lokal - nisja e Telepresence do të jetë edhe më e thjeshtë:
telepresence --namespace {{ .Values.global.env }} --swap-deployment {{ .Chart.Name }}:backend --mount=trueNëse aplikacioni hyn në Kubernetes API, do t'ju duhet të montoni direktorinë e çelësave (https://www.telepresence.io/howto/volumes). Ekziston një mjet për Linux :
proot -b $TELEPRESENCE_ROOT/var/run/secrets/:/var/run/secrets bash
Pas lëshimit të Telepresence pa opsion --docker-run të gjitha variablat e mjedisit do të jenë të disponueshme në terminalin aktual, kështu që aplikacioni duhet të hapet në të.
NB: Kur përdorni, për shembull, PHP, duhet të mbani mend të çaktivizoni op_cache, apc dhe përshpejtues të tjerë për zhvillim - përndryshe redaktimi i kodit nuk do të çojë në rezultatin e dëshiruar.
Rezultatet e
Zhvillimi lokal me Kubernetes është një problem, zgjidhja e të cilit po rritet në raport me përhapjen e kësaj platforme. Duke marrë kërkesat përkatëse nga zhvilluesit (nga klientët tanë), filluam t'i zgjidhim ato me mjetet e para të disponueshme, të cilat, megjithatë, nuk u dëshmuan për një kohë të gjatë. Për fat të mirë, kjo është bërë e qartë jo vetëm tani dhe jo vetëm për ne, kështu që mjetet më të përshtatshme tashmë janë shfaqur në botë, dhe Telepresence është më e famshmja prej tyre (nga rruga, ekziston edhe nga Google). Përvoja jonë e përdorimit të tij nuk është ende aq e madhe, por tashmë na jep arsye t'ua rekomandojmë atë "kolegëve tanë në dyqan" - provojeni!
PS
Të tjera nga seria e këshillave dhe trukeve K8s:
- «"?
- «"?
- «"?
- «"?
- «'.
Burimi: www.habr.com