Kubernetes aholkuak eta trikimailuak: tokiko garapenari eta telepresentziari buruz

Gero eta gehiago galdetzen digute Kubernetesen mikrozerbitzuak garatzeari buruz. Garatzaileek, batez ere interpretatutako hizkuntzak, beren IDE gogokoeneko kodea azkar zuzendu nahi dute eta emaitza ikusi eraikitze/inplementazioaren zain egon gabe - F5 sakatu besterik ez dago. Eta aplikazio monolitiko bati dagokionez, nahikoa zen lokalean datu-base bat eta web zerbitzari bat instalatzea (Docker, VirtualBox...), eta berehala garapenaz gozatzea. Monolitoak mikrozerbitzuetan moztearekin eta Kubernetesen etorrerarekin, elkarren arteko menpekotasunak agertuz, dena pixka bat zailagoa egin zen. Zenbat eta mikrozerbitzu gehiago, orduan eta arazo gehiago. Garapenaz berriro gozatzeko, Docker-eko edukiontzi bat edo bi baino gehiago altxatu behar dira, eta batzuetan dozena bat baino gehiago ere... Orokorrean, honek guztiak denbora dezente behar izan dezake, eguneratuta egon behar baita. .

Momentu ezberdinetan arazoari irtenbide desberdinak saiatu ginen. Eta pilatutako konponbideekin edo, besterik gabe, "makuluekin" hasiko naiz.

1. Makuluak

IDE gehienek kodea zuzenean editatzeko gaitasuna dute zerbitzarian FTP/SFTP erabiliz. Bide hau oso agerikoa da eta berehala erabaki genuen erabiltzea. Bere esentzia honako hauek dira:

1. Garapen-inguruneen multzoan (garapena/berrikuspena), edukiontzi gehigarri bat abiarazten da SSH sarbidearekin eta aplikazioa konprometitu/zabalduko duen garatzailearen SSH gako publikoa birbidaltzen du.
2. Hasierako fasean (edukiontziaren barruan prepare-app) transferitu kodea emptyDiraplikazioaren edukiontzietatik eta SSH zerbitzaritik kodeara sarbidea izateko.

Eskema horren inplementazio teknikoa hobeto ulertzeko, inplikatutako YAML konfigurazioen zatiak emango ditut Kubernetesen.

Konfigurazioak

1.1. balioak.yaml

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

Hemen vasya.pupkin aldagaiaren balioa da ${GITLAB_USER_LOGIN}.

1.2. hedapena.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. sekretua.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 }}

Azken ukitua

Horren ostean, transferitzea besterik ez da geratzen beharrezko gitlab-ci.yml aldagaiak:

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: inplementazioa abiarazi duen garatzaileak zerbitzuaren izenaren arabera konekta daiteke (nola segurtasunez eman klusterrako sarbidea, esan dugu jada) zure mahaigainetik SFTP bidez eta editatu kodea klusterera entregatu arte itxaron gabe.

Hau guztiz funtzionatzen duen irtenbidea da, baina ezarpenaren ikuspuntutik desabantaila nabariak ditu:

• Helm-en taula findu beharra, etorkizunean irakurtzea zailtzen duena;
• zerbitzua zabaldu duen pertsonak bakarrik erabil dezake;
• Gogoratu behar duzu gero tokiko direktorioarekin sinkronizatzea kodearekin eta Git-ekin konprometitzea.

2. Telepresentzia

Proiektu Telepresentzia Aspalditik ezagutzen da, baina guk, esaten duten moduan, «ez ginen praktikan serio probatzen». Hala ere, eskariak bere lana egin du eta orain pozik gaude gure esperientzia partekatzeko, gure blogaren irakurleentzat baliagarria izan daitekeena, batez ere zentroan oraindik Telepresentziari buruzko beste materialik ez dagoelako.

Laburbilduz, dena ez zen hain beldurgarria izan. Garatzailearen aldetik exekutatu behar duten ekintza guztiak Helm diagrama izeneko testu fitxategi batean kokatu ditugu NOTES.txt. Horrela, zerbitzua Kubernetes-en zabaldu ondoren, garatzaileak tokiko garapen-ingurunea abiarazteko argibideak ikusten ditu GitLab lan-erregistroan:

!!! Разработка сервиса локально, в составе 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
#########################################################################

Ez gara argibide honetan deskribatutako urratsetan sakonduko... azkenekoa izan ezik. Zer gertatzen da Telepresentzia abian jartzean?

Telepresentziarekin lan egitea

Abiaraztean (goiko argibideetan zehaztutako azken komandoa erabiliz), ezarri dugu:

• mikrozerbitzua exekutatzen ari den izen-espazioa;
• sartu nahi dugun hedapenaren eta edukiontziaren izenak.

Gainerako argumentuak aukerakoak dira. Gure zerbitzuak Kubernetes APIarekin eta horretarako elkarreragiten badu Zerbitzu-kontua sortu da, ziurtagiriak/tokenak muntatu behar ditugu gure mahaigainean. Horretarako, erabili aukera --mount=true (Edo --mount=/dst_path), erroa (/) Kubernetes edukiontzitik gure mahaigainera muntatuko duena. Horren ostean, (OSaren eta aplikazioa abiarazten den moduaren arabera) klusterreko "gakoak" erabil ditzakegu.

Lehenik eta behin, ikus dezagun aplikazio bat exekutatzeko aukerarik unibertsalena: Docker edukiontzi batean. Horretarako tekla erabiliko dugu --docker-run eta muntatu direktorioa edukiontzian kodearekin: -v `pwd`:/app

Kontuan izan honek proiektuaren direktoriotik exekutatzen dela suposatzen duela. Aplikazioaren kodea direktorioan muntatuko da /app edukiontzi batean.

Hurrengoa: -v /tmp/app/var/run/secrets:/var/run/secrets — Ziurtagiria/tokena duen direktorioa edukiontzi batean muntatzeko.

Aukera honi azkenik aplikazioa exekutatuko den irudia dator. NB: Irudi bat eraikitzerakoan, zehaztu behar duzu CMD edo ENTRYPOINT!

Zer gertatuko da zehazki gero?

• Kubernetes-en, zehaztutako Inplementaziorako, erreplika kopurua 0-ra aldatuko da. Horren ordez, Inplementazio berri bat abiaraziko da, ordezko edukiontzi batekin. backend.
• Mahaigainean 2 edukiontzi abiaraziko dira: lehenengoa Telepresence-rekin (Kubernetes-etik/rako eskaerak proxy egingo ditu), bigarrena garatzen ari den aplikazioarekin.
• Aplikazioarekin edukiontzian exekutatzen bagara, Helm-ek inplementazioan zehar transferitutako ENV aldagai guztiak eskuragarri egongo dira guretzat, eta zerbitzu guztiak ere eskuragarri egongo dira. Zure gogoko IDEan kodea editatzea eta emaitzaz gozatzea besterik ez da geratzen.
• Lanaren amaieran, Telepresence exekutatzen ari den terminala itxi besterik ez duzu behar (saioa amaitu Ctrl+C) - Docker edukiontziak mahaigainean geldituko dira, eta Kubernetesen dena hasierako egoerara itzuliko da. Konpromisoa egitea, MR jaulkitzea eta berrikusi/batera/... transferitzea besterik ez da geratzen (zure lan-fluxuen arabera).

Ez badugu aplikazioa Docker edukiontzi batean exekutatu nahi (adibidez, PHPn ez garatzen, Go-n baizik eta lokalean eraikitzen dugu), Telepresence abiaraztea are errazagoa izango da:

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

Aplikazioa Kubernetes APIra sartzen bada, gakoen direktorioa muntatu beharko duzu (https://www.telepresence.io/howto/volumes). Linux-erako erabilgarritasun bat dago froga:

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

Aukerarik gabe Telepresence abiarazi ondoren --docker-run ingurune-aldagai guztiak eskuragarri egongo dira uneko terminalean, beraz, aplikazioa bertan abiarazi behar da.

NB: PHP erabiltzean, adibidez, gogoratu behar duzu hainbat op_cache, apc eta beste azeleragailu batzuk desgaitu behar dituzula garapenerako; bestela, kodea editatzeak ez du nahi den emaitza ekarriko.

Emaitzak

Tokiko garapena Kubernetesekin plataforma honen hedapenarekin proportzioan hazten ari den arazoa da. Garatzaileen (gure bezeroen) eskaera garrantzitsuak jasota, eskuragarri dauden lehen bitartekoekin konpontzen hasi ginen, baina ez ziren denbora luzean frogatu. Zorionez, hori agerikoa bihurtu da ez orain bakarrik eta ez guretzat bakarrik, beraz, munduan baliabide egokiagoak agertu dira jada, eta Telepresentzia da horietako ospetsuena (bide batez, badago ere aldamioa Google-tik). Erabiltzeko dugun esperientzia oraindik ez da hain handia, baina dagoeneko gure "dendako lankideei" gomendatzeko arrazoia ematen digu - proba ezazu!

PS

K8s aholku eta trikimailu serieko beste batzuk:

• «Kubernetes-en aholkuak eta trikimailuak: errore-orri pertsonalizatuak NGINX Ingress-en»;
• «Kluster batean exekutatzen diren baliabideak Helm 2 kudeaketara transferitzea»;
• «Web aplikazio bateko nodoen esleipenari eta kargari buruz»;
• «Garatzaile guneetarako sarbidea»;
• «Datu-base handietarako bootstrap bizkortzea'.

Iturria: www.habr.com