Cunsiglii è trucchi di Kubernetes: nantu à u sviluppu lucale è a Telepresenza

Ci hè sempre più dumandatu nantu à u sviluppu di microservizi in Kubernetes. I sviluppatori, in particulare di e lingue interpretate, volenu curregà rapidamente u codice in u so IDE preferitu è ​​vede u risultatu senza aspittà per a creazione / implementazione - semplicemente premendu F5. È quandu si trattava di una applicazione monolitica, bastava à stallà in u locu una basa di dati è un servitore web (in Docker, VirtualBox...), è poi gode subitu u sviluppu. Cù u tagliu di monoliti in i microservizi è l'arrivu di Kubernetes, cù l'apparizione di dependenzii l'un à l'altru, tuttu hè diventatu un pocu più difficiule. Più di sti microservizi, più prublemi. Per prufittà di u sviluppu di novu, avete bisognu di crià più di unu o dui cuntenituri Docker, è qualchì volta ancu più di una duzina... In generale, tuttu questu pò piglià assai tempu, postu chì hè ancu bisognu di mantene l'aghjurnamentu. .

In tempi diversi avemu pruvatu diverse suluzioni à u prublema. E cumminciaraghju cù e soluzioni accumulate o simpricimenti "crutches".

1. Crutches

A maiò parte di l'IDE anu a capacità di edità codice direttamente nantu à u servitore cù FTP / SFTP. Sta strada hè assai evidenti è avemu subitu decisu di usà. A so essenza si riduce à i seguenti:

1. In u pod di l'ambienti di sviluppu (dev/review), un containeru supplementu hè lanciatu cù accessu SSH è trasmette a chjave publica SSH di u sviluppatore chì cummetterà / implementà l'applicazione.
2. À u stadiu init (in u cuntinuu prepare-app) trasferisce u codice à emptyDirper avè accessu à u codice da i cuntenituri di l'applicazione è u servitore SSH.

Per capisce megliu l'implementazione tecnica di un tali schema, furniraghju frammenti di e cunfigurazioni YAML implicate in Kubernetes.

Cunfigurazioni

1.1. valori.yaml

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

hè vasya.pupkin hè u valore di a variabile ${GITLAB_USER_LOGIN}.

1.2. implementazione.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. sicretu.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 }}

Toccu finale

Dopu tuttu ciò chì resta hè di trasferimentu variabili necessarii 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: u sviluppatore chì hà lanciatu l'implementazione pò cunnette per nome di serviziu (cume cuncede in modu sicuru l'accessu à u cluster, avemu digià dettu) da u vostru desktop via SFTP è edità u codice senza aspittà chì sia mandatu à u cluster.

Questa hè una soluzione cumpletamente funzionante, ma da u puntu di vista di l'implementazione hà svantaghji evidenti:

• a necessità di raffinà u graficu Helm, chì face difficiuli di leghje in u futuru;
• pò esse usatu solu da a persona chì hà implementatu u serviziu;
• avete bisognu di ricurdà di poi sincronizà cù u repertoriu lucale cù u codice è impegnà in Git.

2. Telepresenza

U prugettu Telepresenza hè cunnisciutu per un bellu pezzu, ma noi, cum'è dicenu, "ùn avemu micca ghjuntu à pruvà seriu in pratica". Tuttavia, a dumanda hà fattu u so travagliu è avà simu felici di sparte a nostra sperienza, chì pò esse utile à i lettori di u nostru blog - soprattuttu perchè ùn ci sò micca stati altri materiali nantu à a Telepresenza in u hub.

In cortu, tuttu hè diventatu micca cusì paura. Avemu postu tutte l'azzioni chì necessitanu l'esekzione da parte di u sviluppatore in un schedariu di testu Helm chart chjamatu NOTES.txt. Cusì, dopu avè implementatu u serviziu à Kubernetes, u sviluppatore vede l'istruzzioni per lancià l'ambiente di dev locale in u logu di travagliu 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
#########################################################################

Ùn avaremu micca in detail nantu à i passi descritti in questa struzzione ... cù l'eccezzioni di l'ultimu. Cosa succede durante u lanciu di Telepresence?

U travagliu cù Telepresence

À l'iniziu (aduprendu l'ultimu cumandamentu specificatu in l'istruzzioni sopra), avemu stabilitu:

• namespace in quale u microserviziu hè in esecuzione;
• nomi di implementazione è cuntainer chì vulemu penetrà.

L'argumenti restanti sò opzionali. Se u nostru serviziu interagisce cù è per l'API Kubernetes ServiceAccount creatu, avemu bisognu di muntà certificati / tokens in u nostru desktop. Per fà questu, utilizate l'opzione --mount=true (o --mount=/dst_path), chì monterà a radica (/) da u cuntinuu Kubernetes à u nostru desktop. Dopu questu, pudemu (secondu u SO è cumu l'applicazione hè lanciata) aduprà e "chjavi" da u cluster.

Prima, fighjemu l'opzione più universale per eseguisce una applicazione - in un containeru Docker. Per fà questu avemu aduprà a chjave --docker-run è muntate u cartulare cù u codice in u containeru: -v `pwd`:/app

Per piacè nutate chì questu assume chì eseguisce da u cartulare di u prughjettu. U codice di l'applicazione serà muntatu in u cartulare /app in un cuntainer.

Next: -v /tmp/app/var/run/secrets:/var/run/secrets - per muntà u cartulare cù u certificatu / token in un containeru.

Questa opzione hè infine seguita da l'imaghjini in quale l'applicazione correrà. NB: Quandu custruisce una maghjina, duvete specificà CMD o ENTRYPOINT!

Cosa accadrà esattamente dopu?

• In Kubernetes, per u Deployment specificatu, u numeru di rèpliche serà cambiatu à 0. Invece, un novu Deployment serà lanciatu - cù un containeru sustitutu. backend.
• I cuntenituri 2 seranu lanciati nantu à u desktop: u primu cù Telepresence (proxy richieste da / à Kubernetes), u sicondu cù l'applicazione chì hè sviluppata.
• Se eseguimu in u cuntinuu cù l'applicazione, allora tutte e variabili ENV trasferiti da Helm durante a implementazione seranu dispunibili per noi, è tutti i servizii seranu ancu dispunibili. Tuttu ciò chì resta hè di edità u codice in u vostru IDE preferitu è ​​gode di u risultatu.
• À a fine di u travagliu, basta à chjude u terminal in quale Telepresence hè in esecuzione (terminà a sessione cù Ctrl + C) - I cuntenituri Docker si fermanu nantu à u desktop, è in Kubernetes tuttu torna à u so statu iniziale. Tuttu ciò chì resta hè di impegnà, emette u MR è trasferisce à rivisione / fusione / ... (secondu i vostri flussi di travagliu).

Se ùn vulemu micca eseguisce l'applicazione in un containeru Docker - per esempiu, sviluppemu micca in PHP, ma in Go, è ancu custruite in u locu - lancià Telepresence serà ancu più simplice:

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

Se l'applicazione accede à l'API Kubernetes, vi tuccherà à muntà u cartulare chjave (https://www.telepresence.io/howto/volumes). Ci hè una utilità per Linux prova:

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

Dopu avè lanciatu Telepresence senza l'opzione --docker-run tutte e variabili di l'ambiente seranu dispunibili in u terminal attuale, cusì l'applicazione deve esse lanciata in questu.

NB: Quandu aduprate, per esempiu, PHP, duvete ricurdà di disattivà varii op_cache, apc è altri acceleratori per u sviluppu - altrimenti edità u codice ùn porta micca à u risultatu desideratu.

Risultati

U sviluppu lucale cù Kubernetes hè un prublema chì a suluzione cresce in proporzione à l'adopzione di sta piattaforma. Ricevendu dumande pertinenti da i sviluppatori (da i nostri clienti), avemu cuminciatu à risolve cù i primi mezi dispunibuli, chì, però, ùn anu micca pruvatu à longu andà. Fortunatamente, questu hè diventatu evidenti micca solu avà è micca solu per noi, cusì i mezi più adattati sò digià apparsu in u mondu, è a Telepresenza hè a più famosa di elli (per via, ci hè ancu scaffold da Google). A nostra sperienza di usà ùn hè micca cusì grande, ma ci dà digià ragiò di ricumandemu à i nostri "culleghi in a buttrega" - pruvate!

PS

Altru da a serie di cunsiglii è trucchi K8s:

• «Cunsiglii è trucchi Kubernetes: pagine d'errore persunalizate in NGINX Ingress";
• «Trasferimentu di risorse in esecuzione in u cluster sottu u cuntrollu di Helm 2";
• «Circa l'assignazione di nodi è i carichi nantu à l'applicazione web";
• «Accessu à i siti di sviluppu";
• «Accelerazione di bootstrap per grandi basa di dati».

Source: www.habr.com