ProHoster > Blog > uprava > 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 viš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 izgradnju/uvođenje - jednostavnim pritiskom na F5. A kada je u pitanju monolitna aplikacija, dovoljno je bilo lokalno instalirati bazu podataka i web server (u Docker, VirtualBox...), pa odmah uživati ​​u razvoju. Rezanjem monolita na mikroservise i dolaskom Kubernetesa, pojavom međusobnih ovisnosti, sve postalo je malo teže. Što više ovih mikroservisa, to više problema. Da biste ponovno uživali u razvoju, trebate podignuti više od jednog ili dva Docker kontejnera, a ponekad čak i više od desetak... Općenito, sve to može potrajati dosta vremena, jer također treba biti ažuran .

U različitim vremenima pokušavali smo različita rješenja problema. I počet ću s nagomilanim zaobilaznim putevima ili jednostavno "štakama".

1. Štake

Većina IDE-a ima mogućnost uređivanja koda izravno na poslužitelju koristeći FTP/SFTP. Ovaj put je vrlo očit i odmah smo ga odlučili koristiti. Njegova se suština svodi na sljedeće:

  1. U paketu razvojnih okruženja (dev/review), pokreće se dodatni spremnik sa SSH pristupom i prosljeđivanjem javnog SSH ključa programera koji će predati/postaviti aplikaciju.
  2. U početnoj fazi (unutar spremnika prepare-app) prenesite kod na emptyDirimati pristup kodu iz aplikacijskih spremnika i SSH poslužitelja.

Kubernetes savjeti i trikovi: o lokalnom razvoju i teleprisutnosti

Kako bih bolje razumio tehničku implementaciju takve sheme, pružit ću fragmente uključenih YAML konfiguracija u Kubernetesu.

Konfiguracije

1.1. vrijednosti.yaml

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

Ovdje vasya.pupkin je vrijednost varijable ${GITLAB_USER_LOGIN}.

1.2. raspoređivanje.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. tajna.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 }}

Završni dodir

Nakon toga ostaje samo prijenos potrebne varijable 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: programer koji je pokrenuo implementaciju može se povezati prema nazivu usluge (kako sigurno odobriti pristup klasteru, već smo rekli) sa svoje radne površine putem SFTP-a i uredite kod bez čekanja da se isporuči u klaster.

Ovo je potpuno radno rješenje, ali sa stajališta implementacije ima očite nedostatke:

  • potreba za doradom Helm karte, što otežava čitanje u budućnosti;
  • može koristiti samo osoba koja je postavila uslugu;
  • morate ga zapamtiti zatim sinkronizirati s lokalnim imenikom s kodom i predati ga Gitu.

2. Teleprisutnost

Projekt TelePresence poznata je već dosta dugo, ali mi, kako se to kaže, “nismo stigli ozbiljno isprobati u praksi”. Međutim, potražnja je učinila svoje i sada smo sretni što možemo podijeliti svoje iskustvo, koje bi moglo biti korisno čitateljima našeg bloga - pogotovo jer još nije bilo drugih materijala o Telepresenceu na čvorištu.

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

!!! Разработка сервиса локально, в составе 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 ovoj uputi... s izuzetkom posljednjeg. Što se događa tijekom pokretanja Telepresencea?

Rad s Telepresenceom

Prilikom pokretanja (pomoću posljednje naredbe navedene u gornjim uputama), postavljamo:

  • prostor imena u kojem se mikroservis izvodi;
  • imena rasporeda i kontejnera u koji želimo prodrijeti.

Preostali argumenti nisu obavezni. Ako naša usluga komunicira s i za Kubernetes API ServiceAccount stvoren, moramo montirati certifikate/tokene na našu radnu površinu. Da biste to učinili, upotrijebite opciju --mount=true (Ili --mount=/dst_path), koji će montirati root (/) iz Kubernetes spremnika na našu radnu površinu. Nakon toga možemo (ovisno o OS-u i načinu pokretanja aplikacije) koristiti “ključeve” iz klastera.

Prvo, pogledajmo najuniverzalniju opciju za pokretanje aplikacije – u Docker spremniku. Da bismo to učinili, koristit ćemo ključ --docker-run i montirajte direktorij s kodom u spremnik: -v `pwd`:/app

Imajte na umu da ovo pretpostavlja pokretanje iz direktorija projekta. Aplikacijski kod bit će postavljen u imenik /app u kontejneru.

Sljedeća: -v /tmp/app/var/run/secrets:/var/run/secrets — za montiranje imenika s certifikatom/tokenom u spremnik.

Ovu opciju na kraju prati slika u kojoj će se aplikacija pokrenuti. NB: Kada gradite sliku, morate navesti CMD ili ENTRYPOINT!

Što će se točno dogoditi sljedeće?

  • U Kubernetesu, za navedenu implementaciju, broj replika će se promijeniti na 0. Umjesto toga, pokrenut će se nova implementacija - sa zamjenskim spremnikom backend.
  • 2 spremnika pokrenut će se na radnoj površini: prvi s Telepresenceom (on će proxy zahtjeve od/na Kubernetes), drugi s aplikacijom koja se razvija.
  • Ako izađemo u spremnik s aplikacijom, bit će nam dostupne sve ENV varijable koje je Helm prenio tijekom implementacije, a bit će nam dostupne i sve usluge. Sve što preostaje je urediti kod u vašem omiljenom IDE-u i uživati ​​u rezultatu.
  • Na kraju rada samo trebate zatvoriti terminal u kojem je pokrenut Telepresence (prekinuti sesiju s Ctrl+C) – Docker kontejneri će stati na radnoj površini, a u Kubernetesu će se sve vratiti u početno stanje. Sve što preostaje je obvezati se, izdati MR i prenijeti ga na pregled/spajanje/… (ovisno o vašim tijekovima rada).

Ako ne želimo pokrenuti aplikaciju u Docker spremniku - na primjer, razvijamo se ne u PHP-u, već u Go-u, i dalje je gradimo lokalno - pokretanje Telepresencea bit će 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 Telepresencea bez opcije --docker-run sve varijable okruženja bit će dostupne u trenutnom terminalu, tako da se aplikacija mora pokrenuti 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.

Rezultati

Lokalni razvoj uz Kubernetes je problem čije rješavanje raste proporcionalno širenju ove platforme. Primivši relevantne zahtjeve programera (naših klijenata), počeli smo ih rješavati prvim dostupnim sredstvima, koja se, međutim, nisu dugoročno pokazala. Srećom, to je postalo očito ne samo sada i ne samo nama, pa su se u svijetu već pojavila prikladnija sredstva, a među njima je najpoznatiji Telepresence (usput, postoji i skela od Googlea). Naše iskustvo korištenja još nije toliko veliko, ali već nam daje razloga da ga preporučimo našim “kolegama u trgovini” – probajte!

PS

Ostalo iz serije savjeta i trikova K8s:

Izvor: www.habr.com

Dodajte komentar