🥇Kubernetes ráð og brellur: um staðbundna þróun og fjarviðveru

Við erum í auknum mæli spurð um þróun örþjónustu í Kubernetes. Hönnuðir, sérstaklega túlkuð tungumál, vilja fljótt leiðrétta kóða í uppáhalds IDE þeirra og sjá niðurstöðuna án þess að bíða eftir smíði/uppsetningu - með því einfaldlega að ýta á F5. Og þegar kom að einhæfu forriti var nóg að setja upp gagnagrunn og vefþjón á staðnum (í Docker, VirtualBox...) og njóta síðan þróunar strax. Með því að klippa einlita í örþjónustu og komu Kubernetes, með útliti háð hvort öðru, allt þetta varð aðeins erfiðara. Því meira af þessum örþjónustum, því meiri vandamál. Til að njóta þróunar aftur þarftu að hækka fleiri en einn eða tvo Docker gáma, og stundum jafnvel meira en tug... Almennt séð getur þetta allt tekið töluverðan tíma, þar sem það þarf líka að vera uppfært .

Á mismunandi tímum reyndum við mismunandi lausnir á vandamálinu. Og ég mun byrja á uppsöfnuðum lausnum eða einfaldlega „hækjur“.

1. Hækjur

Flestar IDE hafa getu til að breyta kóða beint á þjóninum með FTP/SFTP. Þessi leið er mjög augljós og við ákváðum strax að nota hana. Kjarni þess snýst um eftirfarandi:

Í hólf þróunarumhverfa (dev/review) er viðbótargámur settur af stað með SSH aðgangi og áframsendir opinbera SSH lykil þróunaraðilans sem mun skuldbinda/dreifa forritinu.
Á upphafsstigi (innan ílátsins prepare-app) flytja kóðann til emptyDirað hafa aðgang að kóðanum frá forritagámunum og SSH þjóninum.

Til að skilja betur tæknilega útfærslu slíks kerfis mun ég útvega brot af viðkomandi YAML stillingum í Kubernetes.

Stillingar

1.1. gildi.yaml

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

Hér vasya.pupkin er gildi breytunnar ${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. leyndarmál.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 snerta

Eftir það er allt eftir að flytja nauðsynlegar gitlab-ci.yml breytur:

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: verktaki sem setti dreifinguna af stað getur tengst með þjónustuheiti (hvernig á að veita aðgang að þyrpingunni á öruggan hátt, við sögðum þegar) frá skjáborðinu þínu í gegnum SFTP og breyttu kóðanum án þess að bíða eftir að hann verði afhentur í þyrpinguna.

Þetta er algjörlega vinnandi lausn, en frá útfærslusjónarmiði hefur hún augljósa ókosti:

nauðsyn þess að betrumbæta Helm töfluna, sem gerir það erfitt að lesa í framtíðinni;
er aðeins hægt að nota af þeim sem notaði þjónustuna;
þú þarft að muna að samstilla það síðan við staðbundna möppuna með kóðanum og skuldbinda það til Git.

2. Fjarviðvera

Project Fjarvist hefur verið þekkt í nokkuð langan tíma, en við, eins og þeir segja, "komumst ekki í það að reyna það alvarlega í reynd." Hins vegar hefur eftirspurn skilað sínu og nú erum við ánægð að deila reynslu okkar, sem gæti nýst lesendum bloggsins okkar - sérstaklega þar sem ekkert annað efni hefur verið til um Telepresence á miðstöðinni ennþá.

Í stuttu máli, allt reyndist ekki svo skelfilegt. Við settum allar aðgerðir sem krefjast framkvæmdar af hálfu þróunaraðila í Helm chart textaskrá sem kallast NOTES.txt. Þannig, eftir að hafa dreift þjónustunni til Kubernetes, sér verktaki leiðbeiningar um að ræsa staðbundið þróunarumhverfi í GitLab vinnuskránni:

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

Við munum ekki dvelja í smáatriðum við skrefin sem lýst er í þessari leiðbeiningu... að undanskildu því síðasta. Hvað gerist við kynningu á Telepresence?

Að vinna með Telepresence

Við ræsingu (með því að nota síðustu skipunina sem tilgreind er í leiðbeiningunum hér að ofan), stillum við:

nafnrými þar sem örþjónustan er í gangi;
nöfn dreifingarinnar og ílátsins sem við viljum komast inn í.

Rökin sem eftir eru eru valkvæð. Ef þjónusta okkar hefur samskipti við og fyrir Kubernetes API Þjónustureikningur búinn til, við þurfum að festa vottorð/tákn á skjáborðið okkar. Til að gera þetta, notaðu valkostinn --mount=true (Eða --mount=/dst_path), sem mun tengja rótina (/) úr Kubernetes ílátinu á skjáborðið okkar. Eftir þetta getum við (fer eftir stýrikerfinu og hvernig forritið er ræst) notað „lyklana“ úr þyrpingunni.

Í fyrsta lagi skulum við skoða alhliða valkostinn til að keyra forrit - í Docker gámi. Til að gera þetta munum við nota lykilinn --docker-run og festu möppuna með kóðanum í ílátið: -v `pwd`:/app

Vinsamlegast athugaðu að þetta gerir ráð fyrir að keyra úr verkefnaskránni. Forritskóðinn verður settur inn í möppuna /app í gámi.

Next: -v /tmp/app/var/run/secrets:/var/run/secrets — til að tengja möppuna með vottorðinu/tákninu í gám.

Þessum valkosti er loksins fylgt eftir með myndinni sem forritið mun keyra á. NB: Þegar þú byggir mynd verður þú að tilgreina CMD eða ENTRYPOINT!

Hvað nákvæmlega mun gerast næst?

Í Kubernetes, fyrir tilgreinda dreifingu, verður fjölda eftirmynda breytt í 0. Í staðinn verður ný dreifing ræst - með staðgengilsíláti backend.
2 gámar munu opna á skjáborðinu: sá fyrsti með Telepresence (það mun umboðsbeiðnir frá/til Kubernetes), sá síðari með forritinu sem verið er að þróa.
Ef við förum inn í gáminn með forritinu, þá verða allar ENV breytur sem Helm fluttar á meðan á dreifingu stendur, tiltækar fyrir okkur og öll þjónusta verður einnig tiltæk. Allt sem er eftir er að breyta kóðanum í uppáhalds IDE þinni og njóta niðurstöðunnar.
Í lok vinnunnar þarftu bara að loka flugstöðinni þar sem Telepresence er í gangi (slíta lotunni með Ctrl+C) - Docker gámar hætta á skjáborðinu og í Kubernetes mun allt fara aftur í upphafsstöðu. Allt sem er eftir er að skuldbinda sig, gefa út MR og flytja það til endurskoðunar/sameiningu/... (fer eftir vinnuflæði þínu).

Ef við viljum ekki keyra forritið í Docker gámi - til dæmis, við þróum ekki í PHP, heldur í Go, og byggjum það samt á staðnum - að ræsa Telepresence verður enn einfaldara:

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

Ef forritið opnar Kubernetes API þarftu að tengja lyklaskrána (https://www.telepresence.io/howto/volumes). Það er tól fyrir Linux rót:

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

Eftir að hafa ræst Telepresence án valkosts --docker-run allar umhverfisbreytur verða tiltækar í núverandi flugstöð, þannig að forritið verður að vera ræst í henni.

NB: Þegar þú notar til dæmis PHP verður þú að muna að slökkva á ýmsum op_cache, apc og öðrum hröðum fyrir þróun - annars mun breyting kóðans ekki leiða til tilætluðrar niðurstöðu.

Niðurstöður

Staðbundin þróun með Kubernetes er vandamál sem lausnin fer vaxandi í hlutfalli við útbreiðslu þessa vettvangs. Þegar við fengum viðeigandi beiðnir frá þróunaraðilum (frá viðskiptavinum okkar), byrjuðum við að leysa þær með fyrstu tiltæku leiðunum, sem þó reyndust ekki til lengri tíma litið. Sem betur fer hefur þetta orðið augljóst, ekki aðeins núna og ekki aðeins fyrir okkur, svo hentugari aðferðir hafa þegar birst í heiminum og Telepresence er frægasta þeirra (við the vegur, það er líka skaffold frá Google). Reynsla okkar af notkun þess er ekki enn svo mikil, en hún gefur okkur nú þegar ástæðu til að mæla með því við "félaga okkar í búðinni" - prófaðu það!

PS

Annað úr K8s tips & tricks röðinni:

Heimild: www.habr.com

Kubernetes ráð og brellur: um staðbundna þróun og fjarviðveru