Vi får allt fler frågor om att utveckla mikrotjänster i Kubernetes. Utvecklare, särskilt av tolkade språk, vill snabbt korrigera koden i sin favorit-IDE och se resultatet utan att vänta på bygg/installation - genom att helt enkelt trycka på F5. Och när det kom till en monolitisk applikation räckte det med att lokalt installera en databas och en webbserver (i Docker, VirtualBox...), och sedan omedelbart njuta av utvecklingen. Med skärningen av monoliter till mikrotjänster och ankomsten av Kubernetes, med uppkomsten av beroenden av varandra, allt . Ju fler av dessa mikrotjänster, desto fler problem. För att kunna njuta av utvecklingen igen behöver du höja mer än en eller två Docker-containrar, och ibland till och med mer än ett dussin... I allmänhet kan allt detta ta ganska lång tid, eftersom det också måste hållas uppdaterat .
Vid olika tillfällen försökte vi olika lösningar på problemet. Och jag börjar med de ackumulerade lösningarna eller helt enkelt "kryckorna".
1. Kryckor
De flesta IDE:er har möjlighet att redigera kod direkt på servern med hjälp av FTP/SFTP. Den här vägen är väldigt uppenbar och vi bestämde oss direkt för att använda den. Dess essens kokar ner till följande:
- I podden av utvecklingsmiljöer (dev/review) lanseras en extra behållare med SSH-åtkomst och vidarebefordran av den offentliga SSH-nyckeln för utvecklaren som kommer att commit/distribuera applikationen.
- I det inledande skedet (inom behållaren
prepare-app) överför koden tillemptyDirför att få tillgång till koden från applikationsbehållarna och SSH-servern.
För att bättre förstå den tekniska implementeringen av ett sådant schema kommer jag att tillhandahålla fragment av de involverade YAML-konfigurationerna i Kubernetes.
konfigurationer
1.1. värden.yaml
ssh_pub_key:
vasya.pupkin: <ssh public key in base64>
Här vasya.pupkin är variabelns värde ${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. secret.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 }}
Slutlig touch
Efter det återstår bara att överföra :
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: utvecklaren som lanserade distributionen kan ansluta med tjänstens namn (hur man säkert beviljar åtkomst till klustret, ) från ditt skrivbord via SFTP och redigera koden utan att vänta på att den ska levereras till klustret.
Detta är en helt fungerande lösning, men ur implementeringssynpunkt har den uppenbara nackdelar:
- behovet av att förfina Helm-diagrammet, vilket gör det svårt att läsa i framtiden;
- kan endast användas av den person som distribuerade tjänsten;
- du måste komma ihåg att sedan synkronisera den med den lokala katalogen med koden och överföra den till Git.
2. Telenärvaro
Projekt har varit känt ganska länge, men vi, som de säger, "kom inte för att seriöst pröva det i praktiken." Efterfrågan har dock gjort sitt och nu delar vi gärna med oss av vår erfarenhet, som kan vara användbar för läsarna av vår blogg - speciellt eftersom det inte har funnits något annat material om Telepresence på navet ännu.
Kort sagt, allt visade sig inte vara så läskigt. Vi placerade alla åtgärder som kräver exekvering från utvecklarens sida i en Helm chart-textfil som heter NOTES.txt. Sålunda, efter att ha distribuerat tjänsten till Kubernetes, ser utvecklaren instruktioner för att starta den lokala dev-miljön 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 kommer inte att uppehålla oss i detalj vid stegen som beskrivs i denna instruktion... med undantag för den sista. Vad händer under lanseringen av Telepresence?
Jobbar med Telepresence
Vid start (med det sista kommandot som anges i instruktionerna ovan), ställer vi in:
- namnutrymme där mikrotjänsten körs;
- namnen på driftsättningen och behållaren vi vill penetrera.
De återstående argumenten är valfria. Om vår tjänst interagerar med och för Kubernetes API , måste vi montera certifikat/tokens på vårt skrivbord. För att göra detta, använd alternativet --mount=true (eller --mount=/dst_path), som kommer att montera roten (/) från Kubernetes-behållaren till vårt skrivbord. Efter detta kan vi (beroende på OS och hur applikationen startas) använda "nycklarna" från klustret.
Låt oss först titta på det mest universella alternativet för att köra en applikation - i en Docker-behållare. För att göra detta använder vi nyckeln --docker-run och montera katalogen med koden i behållaren: -v `pwd`:/app
Observera att detta förutsätter att det körs från projektkatalogen. Applikationskoden kommer att monteras i katalogen /app i en behållare.
Nästa: -v /tmp/app/var/run/secrets:/var/run/secrets — för att montera katalogen med certifikatet/token i en behållare.
Detta alternativ följs slutligen av bilden där applikationen kommer att köras. NB: När du bygger en bild måste du ange CMD eller ENTRYPOINT!
Vad exakt kommer att hända härnäst?
- I Kubernetes, för den angivna distributionen, kommer antalet repliker att ändras till 0. Istället kommer en ny distribution att lanseras - med en ersättningsbehållare
backend. - 2 behållare kommer att starta på skrivbordet: den första med Telepresence (den kommer att proxyförfrågningar från/till Kubernetes), den andra med applikationen som utvecklas.
- Om vi kör in i behållaren med applikationen kommer alla ENV-variabler som överförs av Helm under distributionen att vara tillgängliga för oss, och alla tjänster kommer också att vara tillgängliga. Allt som återstår är att redigera koden i din favorit-IDE och njuta av resultatet.
- I slutet av arbetet behöver du bara stänga terminalen där Telepresence körs (avsluta sessionen med Ctrl+C) - Docker-behållare stoppas på skrivbordet, och i Kubernetes kommer allt att återgå till sitt ursprungliga tillstånd. Allt som återstår är att begå, utfärda MR och överföra den till granskning/sammanfogning/... (beroende på dina arbetsflöden).
Om vi inte vill köra applikationen i en Docker-behållare - till exempel utvecklar vi inte i PHP, utan i Go, och fortfarande bygger det lokalt - kommer det att bli ännu enklare att starta Telepresence:
telepresence --namespace {{ .Values.global.env }} --swap-deployment {{ .Chart.Name }}:backend --mount=trueOm programmet får åtkomst till Kubernetes API måste du montera nyckelkatalogen (https://www.telepresence.io/howto/volumes). Det finns ett verktyg för Linux :
proot -b $TELEPRESENCE_ROOT/var/run/secrets/:/var/run/secrets bash
Efter att ha startat Telepresence utan alternativet --docker-run alla miljövariabler kommer att vara tillgängliga i den aktuella terminalen, så applikationen måste startas i den.
NB: När du använder till exempel PHP måste du komma ihåg att inaktivera olika op_cache, apc och andra acceleratorer för utveckling - annars leder inte redigering av koden till önskat resultat.
Resultat av
Lokal utveckling med Kubernetes är ett problem vars lösning växer i proportion till spridningen av denna plattform. När vi fick relevanta förfrågningar från utvecklare (från våra kunder) började vi lösa dem med de första tillgängliga medlen, vilket dock inte visade sig på långa vägar. Lyckligtvis har detta blivit uppenbart inte bara nu och inte bara för oss, så mer lämpliga medel har redan dykt upp i världen, och Telepresence är den mest kända av dem (förresten, det finns också från Google). Vår erfarenhet av att använda den är ännu inte så stor, men den ger oss redan anledning att rekommendera den till våra "kollegor i butiken" - prova den!
PS
Annat från K8s tips & tricks-serien:
- «";
- «";
- «";
- «";
- «".
Källa: will.com