Vi blir stadig oftere spurt om utvikling av mikrotjenester i Kubernetes. Utviklere, spesielt av tolkede språk, ønsker å raskt korrigere kode i sin favoritt-IDE og se resultatet uten å vente på bygg/distribusjon - ved å trykke F5. Og når det kom til en monolitisk applikasjon, var det nok å lokalt installere en database og en webserver (i Docker, VirtualBox...), og deretter umiddelbart nyte utviklingen. Med kutting av monolitter til mikrotjenester og ankomsten av Kubernetes, med utseendet til avhengigheter av hverandre, alt . Jo flere av disse mikrotjenestene, jo flere problemer. For å nyte utviklingen igjen, må du heve mer enn én eller to Docker-containere, og noen ganger til og med mer enn et dusin... Generelt kan alt dette ta ganske mye tid, siden det også må holdes oppdatert .
Til forskjellige tider prøvde vi forskjellige løsninger på problemet. Og jeg starter med de akkumulerte løsningene eller bare "krykker".
1. Krykker
De fleste IDE-er har muligheten til å redigere kode direkte på serveren ved hjelp av FTP/SFTP. Denne veien er veldig åpenbar, og vi bestemte oss umiddelbart for å bruke den. Dens essens koker ned til følgende:
- I poden av utviklingsmiljøer (dev/review) lanseres en ekstra beholder med SSH-tilgang og videresending av den offentlige SSH-nøkkelen til utvikleren som skal forplikte/distribuere applikasjonen.
- På startstadiet (i beholderen
prepare-app) overføre koden tilemptyDirå ha tilgang til koden fra applikasjonsbeholderne og SSH-serveren.
For bedre å forstå den tekniske implementeringen av et slikt opplegg, vil jeg gi fragmenter av de involverte YAML-konfigurasjonene i Kubernetes.
Konfigurasjoner
1.1. verdier.yaml
ssh_pub_key:
vasya.pupkin: <ssh public key in base64>
Her vasya.pupkin er verdien av variabelen ${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. hemmelig.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 }}
Endelig berøring
Etter det gjenstår det bare å overføre :
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: utvikleren som lanserte distribusjonen kan koble til etter tjenestenavn (hvordan gi sikker tilgang til klyngen, ) fra skrivebordet ditt via SFTP og rediger koden uten å vente på at den skal leveres til klyngen.
Dette er en fullstendig fungerende løsning, men fra et implementeringssynspunkt har den åpenbare ulemper:
- behovet for å avgrense Helm-diagrammet, noe som gjør det vanskelig å lese i fremtiden;
- kan bare brukes av personen som distribuerte tjenesten;
- du må huske å deretter synkronisere den med den lokale katalogen med koden og overgi den til Git.
2. Teletilstedeværelse
Prosjekt har vært kjent i ganske lang tid, men vi, som de sier, "kom ikke rundt å seriøst prøve det i praksis." Etterspørselen har imidlertid gjort jobben sin, og nå deler vi gjerne vår erfaring, som kan være nyttig for lesere av bloggen vår - spesielt siden det ikke har vært noe annet materiale om Telepresence på huben ennå.
Kort sagt, alt viste seg å ikke være så skummelt. Vi plasserte alle handlinger som krever utførelse fra utviklerens side i en Helm chart-tekstfil kalt NOTES.txt. Derfor, etter å ha distribuert tjenesten til Kubernetes, ser utvikleren instruksjoner for lansering av det lokale utviklermiljøet i GitLab-jobbloggen:
!!! Разработка сервиса локально, в составе 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
#########################################################################Vi vil ikke dvele i detalj ved trinnene beskrevet i denne instruksjonen ... med unntak av den siste. Hva skjer under lanseringen av Telepresence?
Jobber med Telepresence
Ved oppstart (ved å bruke den siste kommandoen spesifisert i instruksjonene ovenfor), satte vi:
- navneområde der mikrotjenesten kjører;
- navnene på distribusjonen og beholderen vi ønsker å trenge gjennom.
De resterende argumentene er valgfrie. Hvis tjenesten vår samhandler med og for Kubernetes API , må vi montere sertifikater/tokens på skrivebordet vårt. For å gjøre dette, bruk alternativet --mount=true (eller --mount=/dst_path), som vil montere roten (/) fra Kubernetes-beholderen til skrivebordet vårt. Etter dette kan vi (avhengig av OS og hvordan applikasjonen startes) bruke "nøklene" fra klyngen.
La oss først se på det mest universelle alternativet for å kjøre en applikasjon - i en Docker-beholder. For å gjøre dette bruker vi nøkkelen --docker-run og monter katalogen med koden i beholderen: -v `pwd`:/app
Vær oppmerksom på at dette forutsetter å kjøre fra prosjektkatalogen. Applikasjonskoden vil bli montert i katalogen /app i en beholder.
Neste: -v /tmp/app/var/run/secrets:/var/run/secrets — for å montere katalogen med sertifikatet/tokenet i en beholder.
Dette alternativet etterfølges til slutt av bildet der applikasjonen skal kjøres. NB: Når du bygger et bilde, må du spesifisere CMD eller ENTRYPOINT!
Hva vil egentlig skje videre?
- I Kubernetes, for den angitte distribusjonen, vil antall replikaer endres til 0. I stedet vil en ny distribusjon bli lansert - med en erstatningsbeholder
backend. - 2 containere vil starte på skrivebordet: den første med Telepresence (den vil proxy-forespørsler fra/til Kubernetes), den andre med applikasjonen som utvikles.
- Hvis vi går inn i containeren med applikasjonen, vil alle ENV-variablene som overføres av Helm under distribusjon, være tilgjengelige for oss, og alle tjenester vil også være tilgjengelige. Alt som gjenstår er å redigere koden i din favoritt-IDE og nyte resultatet.
- På slutten av arbeidet trenger du bare å lukke terminalen der Telepresence kjører (avslutt økten med Ctrl+C) - Docker-beholdere stopper på skrivebordet, og i Kubernetes vil alt gå tilbake til sin opprinnelige tilstand. Alt som gjenstår er å forplikte seg, utstede MR og overføre den til gjennomgang/sammenslåing/... (avhengig av arbeidsflytene dine).
Hvis vi ikke ønsker å kjøre applikasjonen i en Docker-beholder - for eksempel utvikler vi ikke i PHP, men i Go, og fortsatt bygger den lokalt - vil lansering av Telepresence være enda enklere:
telepresence --namespace {{ .Values.global.env }} --swap-deployment {{ .Chart.Name }}:backend --mount=trueHvis applikasjonen får tilgang til Kubernetes API, må du montere nøkkelkatalogen (https://www.telepresence.io/howto/volumes). Det er et verktøy for Linux :
proot -b $TELEPRESENCE_ROOT/var/run/secrets/:/var/run/secrets bash
Etter å ha lansert Telepresence uten alternativet --docker-run alle miljøvariabler vil være tilgjengelige i gjeldende terminal, så applikasjonen må startes i den.
NB: Ved bruk av for eksempel PHP må du huske å deaktivere ulike op_cache, apc og andre akseleratorer for utvikling - ellers vil ikke redigering av koden føre til ønsket resultat.
Resultater av
Lokal utvikling med Kubernetes er et problem hvis løsning vokser i forhold til spredningen av denne plattformen. Etter å ha mottatt relevante forespørsler fra utviklere (fra våre kunder), begynte vi å løse dem med de første tilgjengelige midlene, som imidlertid ikke viste seg på lang sikt. Heldigvis har dette blitt åpenbart ikke bare nå og ikke bare for oss, så mer passende midler har allerede dukket opp i verden, og Telepresence er den mest kjente av dem (forresten, det er også fra Google). Vår erfaring med å bruke den er ennå ikke så stor, men den gir oss allerede grunn til å anbefale den til våre "kolleger i butikken" - prøv den!
PS
Annet fra K8s tips og triks-serien:
- «";
- «";
- «";
- «";
- «'.
Kilde: www.habr.com