Ons word toenemend gevra oor die ontwikkeling van mikrodienste in Kubernetes. Ontwikkelaars, veral van geïnterpreteerde tale, wil kode vinnig in hul gunsteling IDE regstel en die resultaat sien sonder om te wag vir bou/ontplooiing - deur eenvoudig F5 te druk. En as dit by 'n monolitiese toepassing kom, was dit genoeg om 'n databasis en 'n webbediener (in Docker, VirtualBox...) plaaslik te installeer en dan onmiddellik ontwikkeling te geniet. Met die sny van monoliete in mikrodienste en die koms van Kubernetes, met die voorkoms van afhanklikhede van mekaar, alles . Hoe meer van hierdie mikrodienste, hoe meer probleme. Om weer ontwikkeling te geniet, moet jy meer as een of twee Docker-houers bymekaarmaak, en soms selfs meer as 'n dosyn... Oor die algemeen kan dit alles nogal baie tyd neem, aangesien dit ook op datum gehou moet word .
Op verskillende tye het ons verskillende oplossings vir die probleem probeer. En ek sal begin met die opgehoopte oplossings of bloot "krukke".
1. Krukke
Die meeste IDE's het die vermoë om kode direk op die bediener te wysig deur FTP/SFTP te gebruik. Hierdie pad is baie voor die hand liggend en ons het dadelik besluit om dit te gebruik. Die essensie daarvan kom neer op die volgende:
- In die pod van ontwikkelingsomgewings (dev/review), word 'n bykomende houer met SSH-toegang geloods en die publieke SSH-sleutel van die ontwikkelaar aanstuur wat die toepassing sal pleeg/ontplooi.
- By die beginstadium (binne die houer
prepare-app) dra die kode oor naemptyDirom toegang tot die kode te hê vanaf die toepassingshouers en die SSH-bediener.
Om die tegniese implementering van so 'n skema beter te verstaan, sal ek fragmente van die betrokke YAML-konfigurasies in Kubernetes verskaf.
Konfigurasies
1.1. waardes.yaml
ssh_pub_key:
vasya.pupkin: <ssh public key in base64>
Hier vasya.pupkin is die waarde van die veranderlike ${GITLAB_USER_LOGIN}.
1.2. ontplooiing.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. geheim.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 }}
Finale aanraking
Daarna is al wat oorbly om oor te dra :
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: die ontwikkelaar wat die ontplooiing van stapel gestuur het, kan met diensnaam koppel (hoe om veilig toegang tot die groepie te verleen, ) vanaf jou lessenaar via SFTP en wysig die kode sonder om te wag dat dit by die groep afgelewer word.
Dit is 'n heeltemal werkende oplossing, maar vanuit 'n implementeringsoogpunt het dit duidelike nadele:
- die behoefte om die Helm-kaart te verfyn, wat dit moeilik maak om in die toekoms te lees;
- kan slegs gebruik word deur die persoon wat die diens ontplooi het;
- jy moet onthou om dit dan met die plaaslike gids met die kode te sinchroniseer en dit aan Git te verbind.
2. Teleteenwoordigheid
Project is al lank bekend, maar ons, soos hulle sê, "het nie daarin geslaag om dit in die praktyk ernstig te probeer nie." Die vraag het egter sy werk gedoen en nou deel ons graag ons ervaring, wat nuttig kan wees vir lesers van ons blog - veral aangesien daar nog geen ander materiaal oor Telepresence op die spilpunt was nie.
Kortom, alles blyk nie so skrikwekkend te wees nie. Ons het alle aksies wat deur die ontwikkelaar uitgevoer moet word, in 'n Helm-tekslêer genaamd geplaas NOTES.txt. Dus, nadat die diens na Kubernetes ontplooi is, sien die ontwikkelaar instruksies vir die bekendstelling van die plaaslike ontwikkelaaromgewing in die GitLab-werklogboek:
!!! Разработка сервиса локально, в составе 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
#########################################################################Ons gaan nie in detail stilstaan by die stappe wat in hierdie instruksie beskryf word nie... met die uitsondering van die laaste een. Wat gebeur tydens die bekendstelling van Telepresence?
Werk met Telepresence
By opstart (met die laaste opdrag wat in die instruksies hierbo gespesifiseer is), stel ons:
- naamruimte waarin die mikrodiens loop;
- name van die ontplooiing en houer wat ons wil binnedring.
Die oorblywende argumente is opsioneel. As ons diens interaksie het met en vir die Kubernetes API , moet ons sertifikate/tokens op ons lessenaar monteer. Om dit te doen, gebruik die opsie --mount=true (Of --mount=/dst_path), wat die wortel (/) vanaf die Kubernetes-houer op ons lessenaar sal monteer. Hierna kan ons (afhangende van die bedryfstelsel en hoe die toepassing geloods word) die "sleutels" van die groep gebruik.
Kom ons kyk eers na die mees universele opsie om 'n toepassing te laat loop - in 'n Docker-houer. Om dit te doen sal ons die sleutel gebruik --docker-run en monteer die gids met die kode in die houer: -v `pwd`:/app
Neem asseblief kennis dat dit aanvaar dat dit vanaf die projekgids loop. Die toepassingskode sal in die gids gemonteer word /app in 'n houer.
Volgende: -v /tmp/app/var/run/secrets:/var/run/secrets — om die gids met die sertifikaat/token in 'n houer te monteer.
Hierdie opsie word uiteindelik gevolg deur die prent waarin die toepassing sal loop. NB: Wanneer jy 'n prent bou, moet jy spesifiseer CMD of ENTRYPOINT!
Wat presies gaan volgende gebeur?
- In Kubernetes, vir die gespesifiseerde ontplooiing, sal die aantal replikas na 0 verander word. In plaas daarvan sal 'n nuwe ontplooiing bekendgestel word - met 'n plaasvervangerhouer
backend. - 2 houers sal op die lessenaar begin: die eerste met Telepresence (dit sal instaanversoeke van/na Kubernetes), die tweede met die toepassing wat ontwikkel word.
- As ons in die houer met die toepassing uitvoer, sal al die ENV-veranderlikes wat deur Helm oorgedra is tydens ontplooiing vir ons beskikbaar wees, en alle dienste sal ook beskikbaar wees. Al wat oorbly is om die kode in jou gunsteling IDE te wysig en die resultaat te geniet.
- Aan die einde van die werk hoef jy net die terminaal waarin Telepresence loop, toe te maak (beëindig die sessie met Ctrl+C) - Docker-houers sal op die lessenaar stop, en in Kubernetes sal alles terugkeer na sy aanvanklike toestand. Al wat oorbly, is om te verbind, die MR uit te reik en dit oor te dra na hersiening/samesmelting/... (na gelang van jou werkvloei).
As ons nie die toepassing in 'n Docker-houer wil laat loop nie - ons ontwikkel byvoorbeeld nie in PHP nie, maar in Go, en bou dit steeds plaaslik - sal die bekendstelling van Telepresence selfs makliker wees:
telepresence --namespace {{ .Values.global.env }} --swap-deployment {{ .Chart.Name }}:backend --mount=trueAs die toepassing toegang tot die Kubernetes API verkry, sal jy die sleutelgids moet monteer (https://www.telepresence.io/howto/volumes). Daar is 'n nut vir Linux :
proot -b $TELEPRESENCE_ROOT/var/run/secrets/:/var/run/secrets bash
Na die bekendstelling van Telepresence sonder die opsie --docker-run alle omgewingsveranderlikes sal in die huidige terminaal beskikbaar wees, dus moet die toepassing daarin geloods word.
NB: Wanneer jy byvoorbeeld PHP gebruik, moet jy onthou om verskeie op_cache, apc en ander versnellers te deaktiveer vir ontwikkeling - anders sal die wysiging van die kode nie tot die gewenste resultaat lei nie.
Resultate van
Plaaslike ontwikkeling met Kubernetes is 'n probleem waarvan die oplossing groei in verhouding tot die verspreiding van hierdie platform. Toe ons relevante versoeke van ontwikkelaars (van ons kliënte) ontvang het, het ons dit met die eerste beskikbare middele begin oplos, wat egter nie hulself oor die langtermyn bewys het nie. Gelukkig het dit duidelik geword, nie net nou nie en nie net vir ons nie, so meer geskikte middele het reeds in die wêreld verskyn, en Telepresence is die bekendste van hulle (terloops, daar is ook van Google). Ons ervaring met die gebruik daarvan is nog nie so groot nie, maar dit gee ons reeds rede om dit by ons "kollegas in die winkel" aan te beveel - probeer dit!
PS
Ander uit die K8s wenke en truuks-reeks:
- «»;
- «»;
- «»;
- «»;
- «".
Bron: will.com