ProHoster > Блог > Administracija > Kubernetes savjeti i trikovi: o lokalnom razvoju i Teleprisutnosti

Kubernetes savjeti i trikovi: o lokalnom razvoju i Teleprisutnosti

Kubernetes savjeti i trikovi: o lokalnom razvoju i Teleprisutnosti

Sve češće nas pitaju o razvoju mikroservisa u Kubernetesu. Programeri, posebno interpretiranih jezika, žele brzo ispraviti kod u svom omiljenom IDE-u i vidjeti rezultat bez čekanja na build/deployment - jednostavnim pritiskom na F5. A kada je riječ o monolitnoj aplikaciji, bilo je dovoljno lokalno instalirati bazu podataka i web server (u Dockeru, VirtualBoxu...), a zatim odmah uživati ​​u razvoju. Sa rezanjem monolita u mikroservise i dolaskom Kubernetesa, sa pojavom zavisnosti jednih od drugih, sve postalo je malo teže. Što je više ovih mikroservisa, to je više problema. Da biste ponovo uživali u razvoju, potrebno je da podignete više od jednog ili dva Docker kontejnera, a ponekad i više od deset... Generalno, sve ovo može da potraje dosta vremena, jer treba i da se ažurira .

U različito vrijeme smo pokušavali različita rješenja problema. I počet ću s nagomilanim zaobilaznim rješenjima ili jednostavno „štakama“.

1. Štake

Većina IDE-ova ima mogućnost uređivanja koda direktno na serveru koristeći FTP/SFTP. Ovaj put je vrlo očigledan i odmah smo odlučili da ga iskoristimo. Njegova suština se svodi na sljedeće:

  1. U pod razvojnim okruženjima (dev/review), pokreće se dodatni kontejner sa SSH pristupom i prosljeđivanjem javnog SSH ključa programera koji će urezati/razmjestiti aplikaciju.
  2. U početnoj fazi (unutar kontejnera prepare-app) prenesite kod na emptyDirda imate pristup kodu iz kontejnera aplikacija i SSH servera.

Kubernetes savjeti i trikovi: o lokalnom razvoju i Teleprisutnosti

Da bih bolje razumeo tehničku implementaciju takve šeme, daću fragmente uključenih YAML konfiguracija u Kubernetesu.

Konfiguracije

1.1. vrijednosti.yaml

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

to je vasya.pupkin je vrijednost varijable ${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 }}

Final touch

Nakon toga ostaje samo da se prebacite potrebne gitlab-ci.yml varijable:

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: programer koji je pokrenuo implementaciju može se povezati po imenu usluge (kako sigurno odobriti pristup klasteru, već smo rekli) sa vaše radne površine putem SFTP-a i uredite kod bez čekanja da bude isporučen u klaster.

Ovo je potpuno funkcionalno rješenje, ali sa stanovišta implementacije ima očigledne nedostatke:

  • potreba za preciziranjem Helmove karte, što otežava čitanje u budućnosti;
  • može koristiti samo osoba koja je postavila uslugu;
  • morate zapamtiti da ga zatim sinkronizirate s lokalnim direktorijem s kodom i predate ga Gitu.

2. Teleprisutnost

Projekat Teleprisutnost poznato je dosta dugo, ali mi, kako kažu, „nismo stigli da to ozbiljno isprobamo u praksi“. Međutim, potražnja je učinila svoje i sada rado dijelimo svoje iskustvo, koje bi moglo biti od koristi čitaocima našeg bloga – pogotovo jer na hubu još nije bilo drugih materijala o Telepresenceu.

Ukratko, pokazalo se da sve nije tako strašno. Sve radnje koje zahtijevaju izvršenje od strane programera smjestili smo u tekstualnu datoteku Helmovog grafikona pod nazivom NOTES.txt. Stoga, nakon postavljanja usluge na Kubernetes, programer vidi upute za pokretanje lokalnog razvojnog okruženja u GitLab dnevniku poslova:

!!! Разработка сервиса локально, в составе 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ćemo se detaljno zadržavati na koracima opisanim u ovom uputstvu... sa izuzetkom posljednjeg. Šta se dešava tokom lansiranja Telepresence?

Rad sa Telepresence

Prilikom pokretanja (koristeći posljednju naredbu specificiranu u gornjim uputstvima), postavljamo:

  • imenski prostor u kojem mikroservis radi;
  • imena implementacije i kontejnera u koji želimo da prodremo.

Preostali argumenti su opcioni. Ako naša usluga stupa u interakciju sa i za Kubernetes API Servisni račun kreiran, moramo montirati certifikate/tokene na naš desktop. Da biste to učinili, koristite opciju --mount=true (ili --mount=/dst_path), koji će montirati root (/) iz Kubernetes kontejnera na našu radnu površinu. Nakon toga možemo (u zavisnosti od OS-a i načina na koji se aplikacija pokreće) koristiti „ključeve“ iz klastera.

Prvo, pogledajmo najuniverzalniju opciju za pokretanje aplikacije - u Docker kontejneru. Za to ćemo koristiti ključ --docker-run i montirajte direktorij s kodom u kontejner: -v `pwd`:/app

Imajte na umu da ovo pretpostavlja pokretanje iz direktorija projekta. Kod aplikacije će biti montiran u direktorij /app u kontejneru.

Sledeće: -v /tmp/app/var/run/secrets:/var/run/secrets — da montirate direktorij sa certifikatom/tokenom u kontejner.

Nakon ove opcije slijedi slika u kojoj će se aplikacija pokrenuti. NB: Kada pravite sliku, morate navesti CMD ili ENTRYPOINT!

Šta će se tačno desiti sledeće?

  • U Kubernetesu, za navedenu implementaciju, broj replika će biti promijenjen na 0. Umjesto toga, nova implementacija će biti pokrenuta - sa zamjenskim kontejnerom backend.
  • 2 kontejnera će se pokrenuti na desktopu: prvi sa Telepresence-om (on će proxy zahtjeve od/u Kubernetes), drugi sa aplikacijom koja se razvija.
  • Ako izvršimo u kontejner sa aplikacijom, tada će nam biti dostupne sve ENV varijable koje Helm prenese tokom implementacije, a biće dostupne i sve usluge. Ostaje samo da uredite kod u svom omiljenom IDE-u i uživate u rezultatu.
  • Na kraju rada potrebno je samo zatvoriti terminal u kojem je Telepresence pokrenut (prekinuti sesiju sa Ctrl+C) - Docker kontejneri će se zaustaviti na radnoj površini, a u Kubernetesu će se sve vratiti u početno stanje. Ostaje samo da se izvrši, izda MR i prenese ga na pregled/spajanje/… (u zavisnosti od toka posla).

Ako ne želimo pokrenuti aplikaciju u Docker kontejneru - na primjer, razvijamo ne u PHP-u, već u Go-u, i dalje je gradimo lokalno - pokretanje Telepresence-a će biti još jednostavnije:

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

Ako aplikacija pristupa Kubernetes API-ju, morat ćete montirati direktorij ključeva (https://www.telepresence.io/howto/volumes). Postoji uslužni program za Linux korijen:

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

Nakon pokretanja Telepresence bez opcije --docker-run sve varijable okruženja će biti dostupne u trenutnom terminalu, tako da aplikacija mora biti pokrenuta u njemu.

NB: Kada koristite, na primjer, PHP, morate zapamtiti da onemogućite razne op_cache, apc i druge akceleratore za razvoj - inače uređivanje koda neće dovesti do željenog rezultata.

Ishodi

Lokalni razvoj uz Kubernetes je problem čije rješenje raste proporcionalno širenju ove platforme. Primajući relevantne zahtjeve programera (od naših klijenata), počeli smo ih rješavati prvim dostupnim sredstvima, koji se, međutim, nisu dokazali na duge staze. Na sreću, to je postalo očigledno ne samo sada i ne samo nama, pa su se u svijetu već pojavila prikladnija sredstva, a Telepresence je najpoznatije od njih (usput, postoji i skaffold od Googlea). Naše iskustvo korištenja još nije tako veliko, ali nam već daje razlog da ga preporučimo našim “kolegama u radnji” - isprobajte!

PS

Ostali iz serije K8s tips & tricks:

izvor: www.habr.com

Dodajte komentar