Vi bliver i stigende grad spurgt om udvikling af mikrotjenester i Kubernetes. Udviklere, især af fortolkede sprog, vil hurtigt rette kode i deres foretrukne IDE og se resultatet uden at vente på opbygning/implementering - ved blot at trykke på F5. Og når det kom til en monolitisk applikation, var det nok at installere en database og en webserver lokalt (i Docker, VirtualBox...), og så straks nyde udviklingen. Med opskæringen af monolitter til mikrotjenester og ankomsten af Kubernetes, med udseendet af afhængigheder af hinanden, alt . Jo flere af disse mikrotjenester, jo flere problemer. For at nyde udviklingen igen, skal du hæve mere end en eller to Docker-containere, og nogle gange endda mere end et dusin... Generelt kan alt dette tage ret lang tid, da det også skal holdes ajour. .
På forskellige tidspunkter prøvede vi forskellige løsninger på problemet. Og jeg starter med de akkumulerede løsninger eller blot "krykker".
1. Krykker
De fleste IDE'er har mulighed for at redigere kode direkte på serveren ved hjælp af FTP/SFTP. Denne vej er meget indlysende, og vi besluttede os straks for at bruge den. Dens essens koger ned til følgende:
- I poden af udviklingsmiljøer (dev/review) lanceres en ekstra container med adgang via SSH og videresendelse af den offentlige SSH-nøgle for udvikleren, som vil commitere/implementere applikationen.
- På startstadiet (i beholderen
prepare-app) overføre koden tilemptyDirat have adgang til koden fra applikationscontainerne og SSH-serveren.
For bedre at forstå den tekniske implementering af en sådan ordning, vil jeg levere fragmenter af de involverede YAML-konfigurationer i Kubernetes.
konfigurationer
1.1. værdier.yaml
ssh_pub_key:
vasya.pupkin: <ssh public key in base64>
Her vasya.pupkin er værdien af variablen ${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
Derefter er der kun tilbage at 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: udvikleren, der lancerede implementeringen, kan oprette forbindelse ved tjenestenavn (hvordan giver du sikkert adgang til klyngen, ) fra dit skrivebord via SFTP og rediger koden uden at vente på, at den bliver leveret til klyngen.
Dette er en fuldstændig fungerende løsning, men fra et implementeringssynspunkt har den åbenlyse ulemper:
- behovet for at forfine Helm-diagrammet, hvilket gør det vanskeligt at læse i fremtiden;
- kan kun bruges af den person, der har implementeret tjenesten;
- du skal huske at derefter synkronisere den med den lokale mappe med koden og commit den til Git.
2. Teletilstedeværelse
Projekt har været kendt i temmelig lang tid, men vi, som man siger, "nåede ikke for seriøst at prøve det i praksis." Efterspørgslen har dog gjort sit arbejde, og nu deler vi gerne ud af vores erfaring, som kan være nyttig for læsere af vores blog - især da der endnu ikke har været andre materialer om Telepresence på hub'en.
Kort sagt, alt viste sig ikke at være så skræmmende. Vi placerede alle handlinger, der kræver udførelse fra udviklerens side, i en Helm chart-tekstfil kaldet NOTES.txt. Efter at have installeret tjenesten til Kubernetes, ser udvikleren instruktioner til at starte det lokale dev-miljø i GitLab-jobloggen:
!!! Разработка сервиса локально, в составе 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 dvæle i detaljer ved de trin, der er beskrevet i denne instruktion... med undtagelse af den sidste. Hvad sker der under lanceringen af Telepresence?
Arbejder med Telepresence
Ved opstart (ved at bruge den sidste kommando specificeret i instruktionerne ovenfor), indstiller vi:
- navneområde, hvor mikrotjenesten kører;
- navnene på den installation og container, vi ønsker at trænge igennem.
De resterende argumenter er valgfrie. Hvis vores tjeneste interagerer med og for Kubernetes API , skal vi montere certifikater/tokens på vores skrivebord. For at gøre dette skal du bruge indstillingen --mount=true (eller --mount=/dst_path), som vil montere roden (/) fra Kubernetes-beholderen til vores skrivebord. Herefter kan vi (afhængigt af OS og hvordan applikationen startes) bruge "nøglerne" fra klyngen.
Lad os først se på den mest universelle mulighed for at køre en applikation - i en Docker-container. For at gøre dette bruger vi nøglen --docker-run og monter mappen med koden i beholderen: -v `pwd`:/app
Bemærk venligst, at dette forudsætter at køre fra projektbiblioteket. Applikationskoden vil blive monteret i mappen /app i en beholder.
Næste: -v /tmp/app/var/run/secrets:/var/run/secrets — for at montere biblioteket med certifikatet/tokenet i en container.
Denne mulighed efterfølges endelig af billedet, hvor applikationen kører. NB: Når du bygger et billede, skal du angive CMD eller ENTRYPOINT!
Hvad vil der helt præcist ske næste gang?
- I Kubernetes vil antallet af replikaer for den angivne implementering blive ændret til 0. I stedet vil en ny implementering blive lanceret - med en erstatningsbeholder
backend. - 2 containere vil starte på skrivebordet: den første med Telepresence (den vil proxy-anmodninger fra/til Kubernetes), den anden med applikationen, der udvikles.
- Hvis vi går ind i containeren med applikationen, vil alle ENV-variabler, der overføres af Helm under implementeringen, være tilgængelige for os, og alle tjenester vil også være tilgængelige. Det eneste, der er tilbage, er at redigere koden i din yndlings-IDE og nyde resultatet.
- I slutningen af arbejdet skal du bare lukke terminalen, hvor Telepresence kører (afslut sessionen med Ctrl+C) - Docker-containere stopper på skrivebordet, og i Kubernetes vender alt tilbage til sin oprindelige tilstand. Det eneste, der er tilbage, er at forpligte sig, udstede MR'en og overføre den til review/fusion/... (afhængigt af dine arbejdsgange).
Hvis vi ikke ønsker at køre applikationen i en Docker-container - for eksempel udvikler vi ikke i PHP, men i Go, og stadig bygger det lokalt - vil det være endnu nemmere at starte Telepresence:
telepresence --namespace {{ .Values.global.env }} --swap-deployment {{ .Chart.Name }}:backend --mount=trueHvis applikationen får adgang til Kubernetes API, skal du montere nøglebiblioteket (https://www.telepresence.io/howto/volumes). Der er et hjælpeprogram til Linux :
proot -b $TELEPRESENCE_ROOT/var/run/secrets/:/var/run/secrets bash
Efter lancering af Telepresence uden mulighed --docker-run alle miljøvariabler vil være tilgængelige i den aktuelle terminal, så applikationen skal startes i den.
NB: Ved brug af fx PHP skal du huske at deaktivere diverse op_cache, apc og andre acceleratorer til udvikling - ellers vil redigering af koden ikke føre til det ønskede resultat.
Resultaterne af
Lokal udvikling med Kubernetes er et problem, hvis løsning vokser i forhold til udbredelsen af denne platform. Da vi modtog relevante anmodninger fra udviklere (fra vores kunder), begyndte vi at løse dem med de første tilgængelige midler, som dog ikke viste sig i det lange løb. Heldigvis er dette blevet tydeligt ikke kun nu og ikke kun for os, så der er allerede dukket mere egnede midler op i verden, og Telepresence er den mest berømte af dem (der er i øvrigt også fra Google). Vores erfaring med at bruge det er endnu ikke så stor, men det giver os allerede grund til at anbefale det til vores "kolleger i butikken" - prøv det!
PS
Andet fra K8s tips & tricks-serien:
- «";
- «";
- «";
- «";
- «'.
Kilde: www.habr.com