🥇Kubernetes padomi un triki: par vietējo attīstību un telepresence

Mums arvien biežāk tiek jautāts par mikropakalpojumu attīstību Kubernetes. Izstrādātāji, īpaši tulkoto valodu, vēlas ātri izlabot kodu savā iecienītākajā IDE un redzēt rezultātu, negaidot izveidi/izvietošanu — vienkārši nospiežot taustiņu F5. Un, runājot par monolītu lietojumprogrammu, pietika ar datu bāzes un tīmekļa servera lokālu instalēšanu (Docker, VirtualBox ...), un pēc tam nekavējoties izbaudiet attīstību. Ar monolītu sagriešanu mikropakalpojumos un Kubernetes ienākšanu, parādoties atkarībām vienam no otra, viss kļuva nedaudz grūtāk. Jo vairāk šo mikropakalpojumu, jo vairāk problēmu. Lai atkal izbaudītu attīstību, ir jāpaceļ vairāk nekā viens vai divi Docker konteineri, un dažreiz pat vairāk nekā ducis... Kopumā tas viss var aizņemt diezgan daudz laika, jo arī tas ir jāatjaunina. .

Dažādos laikos mēs izmēģinājām dažādus problēmas risinājumus. Un sākšu ar uzkrātajiem risinājumiem jeb vienkāršiem “kruķiem”.

1. Kruķi

Lielākajai daļai IDE ir iespēja rediģēt kodu tieši serverī, izmantojot FTP/SFTP. Šis ceļš ir ļoti acīmredzams, un mēs nekavējoties nolēmām to izmantot. Tās būtība ir šāda:

Izstrādes vidi (izstrādātājs/pārskatīšana) tiek palaists papildu konteiners ar SSH piekļuvi un tā izstrādātāja publiskās SSH atslēgas pārsūtīšanu, kurš veiks/izvietos lietojumprogrammu.
Sākuma stadijā (konteinerā prepare-app) pārsūtiet kodu uz emptyDirlai piekļūtu kodam no lietojumprogrammu konteineriem un SSH servera.

Lai labāk izprastu šādas shēmas tehnisko realizāciju, sniegšu Kubernetes iesaistīto YAML konfigurāciju fragmentus.

Konfigurācijas

1.1. vērtības.yaml

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

Šeit vasya.pupkin ir mainīgā vērtība ${GITLAB_USER_LOGIN}.

1.2. izvietošana.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. noslēpums.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 }}

Galīgais pieskāriens

Pēc tam atliek tikai pārsūtīt nepieciešamie gitlab-ci.yml mainīgie:

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: izstrādātājs, kurš uzsāka izvietošanu, var izveidot savienojumu, izmantojot pakalpojuma nosaukumu (kā droši piešķirt piekļuvi klasterim, mēs jau teicām) no darbvirsmas, izmantojot SFTP, un rediģējiet kodu, negaidot, līdz tas tiks piegādāts klasterim.

Šis ir pilnībā funkcionējošs risinājums, taču no ieviešanas viedokļa tam ir acīmredzami trūkumi:

nepieciešamība precizēt Helm diagrammu, kas apgrūtina lasīšanu nākotnē;
var izmantot tikai persona, kas izvietojusi pakalpojumu;
jums jāatceras, ka pēc tam tas jāsinhronizē ar vietējo direktoriju ar kodu un jāiekļauj Git.

2. Telepresence

Projekts Tele klātbūtne ir zināms jau diezgan ilgu laiku, bet mēs, kā saka, “nespējām to nopietni izmēģināt praksē”. Tomēr pieprasījums ir darījis savu, un tagad mēs ar prieku dalāmies pieredzē, kas var noderēt mūsu emuāra lasītājiem - jo īpaši tāpēc, ka centrmezglā vēl nav bijuši citi materiāli par Telepresence.

Īsāk sakot, viss izrādījās ne tik biedējoši. Visas darbības, kuras izstrādātājam ir jāizpilda, mēs ievietojām Helm diagrammas teksta failā, ko sauc NOTES.txt. Tādējādi pēc pakalpojuma izvietošanas Kubernetes izstrādātājs GitLab darbu žurnālā redz instrukcijas vietējās izstrādātāja vides palaišanai:

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

Mēs sīkāk neapspriedīsim šajā instrukcijā aprakstītās darbības... izņemot pēdējo. Kas notiek Telepresence palaišanas laikā?

Darbs ar Telepresence

Startējot (izmantojot pēdējo komandu, kas norādīta iepriekš sniegtajos norādījumos), mēs iestatījām:

nosaukumu telpa, kurā darbojas mikropakalpojums;
izvietošanas un konteinera nosaukumi, kuros vēlamies iekļūt.

Pārējie argumenti nav obligāti. Ja mūsu pakalpojums mijiedarbojas ar Kubernetes API un par to Pakalpojuma konts ir izveidots, mums ir jāmontē sertifikāti/marķieri uz mūsu darbvirsmas. Lai to izdarītu, izmantojiet opciju --mount=true (Vai --mount=/dst_path), kas pievienos sakni (/) no Kubernetes konteinera mūsu darbvirsmā. Pēc tam mēs varam (atkarībā no OS un lietojumprogrammas palaišanas veida) izmantot klastera “taustiņus”.

Vispirms apskatīsim universālāko lietojumprogrammas palaišanas iespēju - Docker konteinerā. Lai to izdarītu, mēs izmantosim atslēgu --docker-run un pievienojiet direktoriju ar kodu konteinerā: -v `pwd`:/app

Lūdzu, ņemiet vērā, ka tas tiek veikts no projekta direktorijas. Lietojumprogrammas kods tiks uzstādīts direktorijā /app konteinerā.

Nākamais: -v /tmp/app/var/run/secrets:/var/run/secrets — uzstādīt direktoriju ar sertifikātu/marķieri konteinerā.

Pēc šīs opcijas beidzot tiek parādīts attēls, kurā lietojumprogramma darbosies. NB: veidojot attēlu, jums ir jānorāda CMD vai ENTRYPOINT!

Kas tieši notiks tālāk?

Programmā Kubernetes norādītajai izvietošanai reprodukciju skaits tiks mainīts uz 0. Tā vietā tiks palaists jauns izvietojums — ar aizstājēju konteineru. backend.
Uz darbvirsmas tiks palaisti 2 konteineri: pirmais ar Telepresence (tā starpniekservera pieprasījumus no/uz Kubernetes), otrais ar lietojumprogrammu, kas tiek izstrādāta.
Ja mēs izpildīsim konteinerā ar lietojumprogrammu, mums būs pieejami visi Helm izvietošanas laikā pārsūtītie ENV mainīgie, kā arī visi pakalpojumi. Atliek tikai rediģēt kodu savā iecienītākajā IDE un baudīt rezultātu.
Darba beigās jums vienkārši jāaizver terminālis, kurā darbojas Telepresence (pārtrauciet sesiju ar Ctrl+C) - Docker konteineri apstāsies uz darbvirsmas, un Kubernetes viss atgriezīsies sākotnējā stāvoklī. Atliek tikai apņemties, izsniegt MR un pārsūtīt to pārskatīšanai/apvienošanai/… (atkarībā no jūsu darbplūsmām).

Ja mēs nevēlamies palaist lietojumprogrammu Docker konteinerā — piemēram, mēs izstrādājam nevis PHP, bet gan Go un joprojām veidojam to lokāli, Telepresence palaišana būs vēl vienkāršāka:

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

Ja lietojumprogramma piekļūst Kubernetes API, jums būs jāpievieno atslēgu direktorijs (https://www.telepresence.io/howto/volumes). Linux ir utilīta sakne:

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

Pēc Telepresence palaišanas bez opcijas --docker-run visi vides mainīgie būs pieejami pašreizējā terminālī, tāpēc lietojumprogramma ir jāpalaiž tajā.

NB: Lietojot, piemēram, PHP, jāatceras izstrādei atslēgt dažādus op_cache, apc un citus paātrinātājus - pretējā gadījumā koda rediģēšana nenovedīs pie vēlamā rezultāta.

Rezultāti

Vietējā attīstība ar Kubernetes ir problēma, kuras risinājums pieaug proporcionāli šīs platformas izplatībai. Saņemot attiecīgus pieprasījumus no izstrādātājiem (no mūsu klientiem), mēs sākām tos risināt ar pirmajiem pieejamajiem līdzekļiem, kas tomēr nav pierādījuši sevi ilgtermiņā. Par laimi, tas ir kļuvis acīmredzams ne tikai tagad un ne tikai mums, tāpēc pasaulē jau ir parādījušies piemērotāki līdzekļi, un Telepresence ir slavenākais no tiem (starp citu, ir arī sastatnes no Google). Mūsu lietošanas pieredze vēl nav tik liela, taču tā jau dod pamatu to ieteikt mūsu “kolēģiem veikalā” – izmēģiniet!

PS

Citi no K8s padomu un triku sērijas:

Avots: www.habr.com

Kubernetes padomi un triki: par vietējo attīstību un telepresence