🥇Kubernetes-vinkkejä ja temppuja: paikallisesta kehityksestä ja Telepresencesta

Meiltä kysytään yhä enemmän mikropalvelujen kehittämisestä Kubernetesissa. Kehittäjät, erityisesti tulkittujen kielten, haluavat korjata koodin nopeasti suosikki-IDE-ympäristössään ja nähdä tuloksen odottamatta rakentamista/käyttöönottoa - yksinkertaisesti painamalla F5. Ja kun kyse oli monoliittisesta sovelluksesta, riitti asentaa paikallisesti tietokanta ja web-palvelin (Dockerissa, VirtualBoxissa...) ja sitten heti nauttia kehityksestä. Monoliittien leikkaamisen mikropalveluiksi ja Kubernetesin tulon myötä riippuvuuksien ilmaantuessa toisiinsa kaikki siitä tuli vähän vaikeampaa. Mitä enemmän näitä mikropalveluita, sitä enemmän ongelmia. Kehityksestä nauttimiseksi on nostettava enemmän kuin yksi tai kaksi Docker-konttia, joskus jopa yli tusina... Yleensä tämä kaikki voi viedä melko paljon aikaa, koska se on myös pidettävä ajan tasalla. .

Yritimme eri aikoina erilaisia ratkaisuja ongelmaan. Ja aloitan kertyneistä kiertotavoista tai yksinkertaisesti "sauvoista".

1. kainalosauvat

Useimmat IDE:t pystyvät muokkaamaan koodia suoraan palvelimella FTP/SFTP:n avulla. Tämä polku on hyvin ilmeinen ja päätimme heti käyttää sitä. Sen olemus tiivistyy seuraavaan:

Kehitysympäristöissä (dev/review) käynnistetään ylimääräinen säilö, jossa on SSH-yhteys ja joka välittää sovelluksen sitoutuvan tai käyttöön ottavan kehittäjän julkisen SSH-avaimen.
Alkuvaiheessa (säiliön sisällä prepare-app) siirrä koodi osoitteeseen emptyDirpäästäksesi koodiin sovellussäiliöistä ja SSH-palvelimesta.

Ymmärtääkseni paremmin tällaisen järjestelmän teknistä toteutusta tarjoan katkelmia mukana olevista YAML-kokoonpanoista Kubernetesissa.

Kokoonpanot

1.1. arvot.yaml

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

Täällä vasya.pupkin on muuttujan arvo ${GITLAB_USER_LOGIN}.

1.2. käyttöönotto.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. salaisuus.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 }}

Lopullinen kosketus

Sen jälkeen jää vain siirto vaaditut gitlab-ci.yml-muuttujat:

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: käyttöönoton käynnistänyt kehittäjä voi muodostaa yhteyden palvelun nimellä (miten klusterin käyttöoikeus myönnetään turvallisesti, olemme jo kertoneet) työpöydältäsi SFTP:n kautta ja muokkaa koodia odottamatta sen toimittamista klusteriin.

Tämä on täysin toimiva ratkaisu, mutta toteutuksen kannalta sillä on ilmeisiä haittoja:

tarve tarkentaa Helm-kaaviota, mikä vaikeuttaa sen lukemista tulevaisuudessa;
voi käyttää vain palvelun käyttöön ottaja;
sinun täytyy muistaa synkronoida se paikallisen hakemiston kanssa koodilla ja sitoa se Gitiin.

2. Telepresence

Hanke Telepresence on ollut tiedossa jo pitkään, mutta me, kuten sanotaan, "emme päässeet vakavasti kokeilemaan sitä käytännössä". Kysyntä on kuitenkin tehnyt tehtävänsä ja nyt jaamme mielellämme kokemuksiamme, joista voi olla hyötyä blogimme lukijoille - varsinkin kun hubissa ei ole vielä ollut muuta materiaalia Telepresencesta.

Lyhyesti sanottuna kaikki ei osoittautunut niin pelottavalta. Sijoitimme kaikki toiminnot, jotka vaativat kehittäjän suorittamista Helm chart -tekstitiedostoon nimeltä NOTES.txt. Siten, kun palvelu on otettu käyttöön Kubernetesiin, kehittäjä näkee GitLab-työlokissa ohjeet paikallisen kehittäjäympäristön käynnistämiseksi:

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

Emme käsittele yksityiskohtaisesti tässä ohjeessa kuvattuja vaiheita... viimeistä lukuun ottamatta. Mitä tapahtuu Telepresencen julkaisun aikana?

Työskentely Telepresencen kanssa

Käynnistettäessä (käyttäen yllä olevissa ohjeissa määritettyä viimeistä komentoa) asetimme:

nimiavaruus, jossa mikropalvelu on käynnissä;
käyttöönoton ja kontin nimet, joihin haluamme päästä.

Loput argumentit ovat valinnaisia. Jos palvelumme on vuorovaikutuksessa Kubernetes API:n kanssa ja sitä varten Palvelutili luotu, meidän on asennettava varmenteita/tunnuksia työpöydällemme. Voit tehdä tämän käyttämällä vaihtoehtoa --mount=true (tai --mount=/dst_path), joka asentaa juuren (/) Kubernetes-säilöstä työpöydällemme. Tämän jälkeen voimme (käyttöjärjestelmästä ja sovelluksen käynnistämisestä riippuen) käyttää klusterin "avaimia".

Tarkastellaan ensin yleisintä vaihtoehtoa sovelluksen suorittamiseen - Docker-säiliössä. Käytämme tätä varten avainta --docker-run ja liitä hakemisto koodineen säilöön: -v `pwd`:/app

Huomaa, että tämä edellyttää, että se suoritetaan projektihakemistosta. Sovelluskoodi liitetään hakemistoon /app säiliössä.

Seuraava: -v /tmp/app/var/run/secrets:/var/run/secrets — liittää hakemiston, jossa on varmenne/tunnus, säiliöön.

Tätä vaihtoehtoa seuraa lopulta kuva, jossa sovellus suoritetaan. NB: Kun rakennat kuvaa, sinun on määritettävä CMD tai ENTRYPOINT!

Mitä oikein tapahtuu seuraavaksi?

Kubernetesissa määritetyn käyttöönoton replikoiden määräksi muutetaan 0. Sen sijaan käynnistetään uusi käyttöönotto - korvaavan säilöllä backend.
Kaksi konttia käynnistyy työpöydällä: ensimmäinen Telepresencella (se lähettää välityspyyntöjä Kubernetesiltä/Kubernetesille), toinen kehitteillä olevan sovelluksen kanssa.
Jos suoritamme konttiin sovelluksen kanssa, niin kaikki Helmin käyttöönoton aikana siirtämät ENV-muuttujat ovat käytettävissämme ja kaikki palvelut ovat myös saatavilla. Jäljelle jää vain muokata koodia suosikki-IDE:ssäsi ja nauttia tuloksesta.
Työn lopussa sinun tarvitsee vain sulkea pääte, jossa Telepresence on käynnissä (lopettaa istunto Ctrl+C:llä) - Docker-säilöt pysähtyvät työpöydälle, ja Kubernetesissa kaikki palaa alkuperäiseen tilaan. Jäljelle jää vain sitoutuminen, MR:n myöntäminen ja sen siirtäminen tarkasteluun/yhdistämiseen/… (työnkuluistasi riippuen).

Jos emme halua ajaa sovellusta Docker-säiliössä - esimerkiksi emme kehitä PHP:llä vaan Golla ja rakennamme sen silti paikallisesti - Telepresencen käynnistäminen on vielä yksinkertaisempaa:

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

Jos sovellus käyttää Kubernetes API:ta, sinun on liitettävä avainhakemisto (https://www.telepresence.io/howto/volumes). Linuxille on apuohjelma juuri:

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

Telepresencen käynnistämisen jälkeen ilman vaihtoehtoa --docker-run kaikki ympäristömuuttujat ovat saatavilla nykyisessä päätteessä, joten sovellus on käynnistettävä siinä.

NB: Esimerkiksi PHP:tä käytettäessä tulee muistaa poistaa käytöstä erilaisia op_cache, apc ja muut kiihdytit kehitystä varten - muuten koodin muokkaaminen ei johda haluttuun tulokseen.

Tulokset

Paikallinen kehittäminen Kuberneteksen kanssa on ongelma, jonka ratkaisu kasvaa suhteessa tämän alustan leviämiseen. Saatuaan asiaankuuluvat pyynnöt kehittäjiltä (asiakkailtamme) aloimme ratkaista niitä ensimmäisillä käytettävissä olevilla keinoilla, jotka eivät kuitenkaan osoittautuneet pitkällä aikavälillä. Onneksi tämä ei ole tullut ilmeiseksi vain nyt eikä vain meille, joten sopivampia keinoja on jo ilmestynyt maailmaan, ja Telepresence on niistä tunnetuin (muuten, siellä on myös rakennustelineet Googlelta). Kokemuksemme sen käytöstä ei ole vielä niin suuri, mutta se antaa jo aihetta suositella sitä "kaupan kollegoillemme" - kokeile!

PS.

Muita K8s-vinkkejä ja temppuja -sarjasta:

Lähde: will.com

Kubernetes-vinkkejä ja temppuja: paikallisesta kehityksestä ja telepresencesta