ProHoster > Blog > Uprava > Kubernetes nasveti in triki: o lokalnem razvoju in teleprisotnosti

Kubernetes nasveti in triki: o lokalnem razvoju in teleprisotnosti

Kubernetes nasveti in triki: o lokalnem razvoju in teleprisotnosti

Vse pogosteje nas sprašujejo o razvoju mikrostoritev v Kubernetesu. Razvijalci, zlasti tolmačenih jezikov, želijo hitro popraviti kodo v svojem najljubšem IDE in videti rezultat, ne da bi čakali na gradnjo/razmestitev - s preprostim pritiskom na F5. In ko je šlo za monolitno aplikacijo, je bilo dovolj, da smo lokalno namestili bazo podatkov in spletni strežnik (v Docker, VirtualBox ...), nato pa takoj uživali v razvoju. Z rezanjem monolitov v mikrostoritve in prihodom Kubernetesa, s pojavom medsebojnih odvisnosti je vse postalo je malo težje. Več kot je teh mikrostoritev, več je težav. Če želite znova uživati ​​v razvoju, morate dvigniti več kot enega ali dva Docker kontejnerja, včasih celo več kot ducat ... Na splošno lahko vse to vzame precej časa, saj je treba tudi posodabljati .

V različnih časih smo poskušali različne rešitve problema. In začel bom z nakopičenimi rešitvami ali preprosto "berglami".

1. Bergle

Večina IDE-jev ima možnost urejanja kode neposredno na strežniku s pomočjo FTP/SFTP. Ta pot je zelo očitna in takoj smo se odločili zanjo. Njegovo bistvo je naslednje:

  1. V pod razvojnih okolij (dev/review) se zažene dodaten vsebnik z dostopom SSH in posredovanjem javnega ključa SSH razvijalca, ki bo izdal/razmestil aplikacijo.
  2. Na začetni stopnji (znotraj vsebnika prepare-app) prenesite kodo na emptyDirimeti dostop do kode iz vsebnikov aplikacij in strežnika SSH.

Kubernetes nasveti in triki: o lokalnem razvoju in teleprisotnosti

Da bi bolje razumeli tehnično izvedbo takšne sheme, bom zagotovil fragmente vključenih konfiguracij YAML v Kubernetesu.

Konfiguracije

1.1. vrednosti.yaml

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

Tukaj vasya.pupkin je vrednost spremenljivke ${GITLAB_USER_LOGIN}.

1.2. uvajanje.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. skrivnost.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 }}

Zadnji dotik

Po tem ostane le prenos zahtevane spremenljivke gitlab-ci.yml:

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: razvijalec, ki je zagnal uvajanje, se lahko poveže z imenom storitve (kako varno odobriti dostop do gruče, smo že povedali) z namizja prek SFTP in uredite kodo, ne da bi čakali, da bo dostavljena v gručo.

To je popolnoma delujoča rešitev, vendar ima z izvedbenega vidika očitne pomanjkljivosti:

  • potreba po izpopolnitvi Helmove karte, zaradi česar je v prihodnosti težko brati;
  • lahko uporablja le oseba, ki je storitev uvedla;
  • ne pozabite ga nato sinhronizirati z lokalnim imenikom s kodo in ga predati Gitu.

2. Teleprisotnost

Projekt Teleprisotnost je poznan že precej časa, vendar ga, kot pravijo, »nismo uspeli resno preizkusiti v praksi«. Vendar je povpraševanje opravilo svoje delo in zdaj z veseljem delimo svojo izkušnjo, ki bo morda koristna za bralce našega bloga - še posebej, ker na vozlišču še ni bilo nobenega drugega gradiva o teleprisotnosti.

Skratka, vse se je izkazalo, da ni tako strašljivo. Vsa dejanja, ki zahtevajo izvedbo s strani razvijalca, smo umestili v besedilno datoteko grafikona Helm, imenovano NOTES.txt. Tako po uvedbi storitve v Kubernetes razvijalec vidi navodila za zagon lokalnega razvijalskega okolja v dnevniku opravil GitLab:

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

Ne bomo se podrobneje ukvarjali s koraki, opisanimi v tem navodilu ... z izjemo zadnjega. Kaj se zgodi med lansiranjem Telepresence?

Delo s teleprisotnostjo

Ob zagonu (z zadnjim ukazom, navedenim v zgornjih navodilih), nastavimo:

  • imenski prostor, v katerem se izvaja mikrostoritev;
  • imena razmestitve in vsebnika, v katerega želimo prodreti.

Preostali argumenti so neobvezni. Če naša storitev sodeluje z in za Kubernetes API ServiceAccount ustvarjen, moramo namestiti potrdila/žetone na namizje. Če želite to narediti, uporabite možnost --mount=true (Ali --mount=/dst_path), ki bo priklopil koren (/) iz vsebnika Kubernetes na naše namizje. Po tem lahko (odvisno od OS in načina zagona aplikacije) uporabimo “ključe” iz gruče.

Najprej si poglejmo najbolj univerzalno možnost za zagon aplikacije – v vsebniku Docker. Za to bomo uporabili ključ --docker-run in namestite imenik s kodo v vsebnik: -v `pwd`:/app

Upoštevajte, da to predvideva zagon iz imenika projekta. Koda aplikacije bo nameščena v imenik /app v posodi.

Naprej: -v /tmp/app/var/run/secrets:/var/run/secrets — za namestitev imenika s potrdilom/žetonom v vsebnik.

Tej možnosti na koncu sledi slika, v kateri se bo aplikacija izvajala. NB: Ko gradite sliko, morate določiti CMD ali ENTRYPOINT!

Kaj točno se bo zgodilo potem?

  • V Kubernetesu bo za določeno uvedbo število replik spremenjeno na 0. Namesto tega bo zagnana nova uvedba – z nadomestnim vsebnikom backend.
  • Na namizju se bosta zagnala 2 vsebnika: prvi s Telepresence (bo posredoval zahteve iz/na Kubernetes), drugi z aplikacijo v razvoju.
  • Če izvedemo v vsebnik z aplikacijo, potem nam bodo na voljo vse spremenljivke ENV, ki jih je med uvedbo prenesel Helm, na voljo pa bodo tudi vse storitve. Vse kar ostane je, da uredite kodo v svojem najljubšem IDE in uživate v rezultatu.
  • Na koncu dela morate le še zapreti terminal, v katerem teče Telepresence (zaključite sejo s Ctrl+C) – Docker vsebniki se bodo ustavili na namizju, v Kubernetesu pa se bo vse vrnilo v začetno stanje. Vse, kar ostane, je, da potrdite, izdate MR in ga prenesete v pregled/spojitev/… (odvisno od vašega poteka dela).

Če ne želimo zagnati aplikacije v vsebniku Docker - na primer, ne razvijamo v PHP, ampak v Go in jo še vedno gradimo lokalno - bo zagon Telepresence še enostavnejši:

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

Če aplikacija dostopa do API-ja Kubernetes, boste morali namestiti imenik ključev (https://www.telepresence.io/howto/volumes). Obstaja pripomoček za Linux korenina:

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

Po zagonu Telepresence brez možnosti --docker-run vse spremenljivke okolja bodo na voljo v trenutnem terminalu, zato je treba aplikacijo zagnati v njem.

NB: Ko uporabljate na primer PHP, ne pozabite onemogočiti različnih pospeševalnikov op_cache, apc in drugih za razvoj - sicer urejanje kode ne bo privedlo do želenega rezultata.

Rezultati

Lokalni razvoj s Kubernetesom je problem, katerega reševanje raste sorazmerno s širjenjem te platforme. Ko smo prejeli ustrezne zahteve razvijalcev (naših naročnikov), smo jih začeli reševati s prvimi razpoložljivimi sredstvi, ki pa se na dolgi rok niso izkazala. Na srečo je to postalo očitno ne šele zdaj in ne samo nam, zato so se v svetu že pojavila primernejša sredstva, med njimi pa je najbolj znana teleprisotnost (mimogrede, obstaja tudi oder iz Googla). Naše izkušnje z uporabo še niso tako velike, vendar nam že dajejo razlog, da ga priporočamo našim “kolegom v trgovini” - poskusite!

PS

Drugo iz serije nasvetov in zvijač K8s:

Vir: www.habr.com

Dodaj komentar