ProHoster > Blogi > Haldamine > Kubernetese näpunäited ja nipid: kohaliku arengu ja telepresence'i kohta

Kubernetese näpunäited ja nipid: kohaliku arengu ja telepresence'i kohta

Kubernetese näpunäited ja nipid: kohaliku arengu ja telepresence'i kohta

Üha enam küsitakse meilt Kubernetes mikroteenuste arendamise kohta. Arendajad, eriti tõlgitud keelte puhul, soovivad kiiresti oma lemmik-IDE-s koodi parandada ja näha tulemust ilma ehitamist/juurutamist ootamata – vajutades lihtsalt klahvi F5. Ja kui rääkida monoliitsest rakendusest, siis piisas andmebaasi ja veebiserveri lokaalsest installimisest (Dockeris, VirtualBoxis...) ja seejärel kohe arendust nautida. Monoliitide mikroteenusteks lõikamisega ja Kubernetese tulekuga koos üksteisest sõltuvuste ilmnemisega on kõik läks natuke raskemaks. Mida rohkem neid mikroteenuseid, seda rohkem probleeme. Et uuesti arendust nautida, tuleb üles tõsta rohkem kui üks-kaks Dockeri konteinerit ja vahel isegi üle tosina... Üldiselt võib see kõik võtta päris palju aega, kuna ka seda tuleb ajakohasena hoida .

Erinevatel aegadel proovisime probleemile erinevaid lahendusi. Ja ma alustan kogunenud lahendustest või lihtsalt "karkudest".

1. Kargud

Enamikul IDE-del on võimalus FTP/SFTP abil koodi otse serveris redigeerida. See tee on väga ilmne ja otsustasime kohe seda kasutada. Selle olemus taandub järgmisele:

  1. Arenduskeskkondade kaustas (dev/review) käivitatakse täiendav konteiner, millel on SSH-juurdepääs ja mis edastab rakenduse siduva/juurutava arendaja avaliku SSH-võtme.
  2. Algstaadiumis (mahuti sees prepare-app) edastage kood aadressile emptyDirjuurdepääsuks rakenduse konteinerite ja SSH-serveri koodile.

Kubernetese näpunäited ja nipid: kohaliku arengu ja telepresence'i kohta

Sellise skeemi tehnilise teostuse paremaks mõistmiseks pakun Kubernetesis kaasatud YAML-i konfiguratsioonide fragmente.

Konfiguratsioonid

1.1. väärtused.yaml

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

see on vasya.pupkin on muutuja väärtus ${GITLAB_USER_LOGIN}.

1.2. juurutamine.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. salajane.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 }}

Lõplik puudutus

Pärast seda jääb üle vaid üle kanda nõutavad gitlab-ci.yml muutujad:

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: juurutuse käivitanud arendaja saab ühenduse luua teenuse nime järgi (kuidas turvaliselt anda juurdepääs klastrile, me juba rääkisime) oma töölaualt SFTP kaudu ja redigeerige koodi, ootamata, kuni see klastris toimetatakse.

See on täiesti töötav lahendus, kuid rakendamise seisukohast on sellel ilmselged puudused:

  • Helmi diagrammi täpsustamise vajadus, mis raskendab selle lugemist tulevikus;
  • saab kasutada ainult teenuse juurutanud isik;
  • Peate meeles pidama, et sünkroonige see koodiga kohaliku kataloogiga ja kinnitage see Giti.

2. Telekohalolu

Projekt Teleesitus on tuntud juba pikka aega, kuid me, nagu öeldakse, "ei jõudnud seda tõsiselt praktikas proovida." Nõudlus on aga oma töö teinud ja nüüd jagame hea meelega oma kogemust, mis võib meie ajaveebi lugejatele kasulikuks osutuda – seda enam, et muid materjale Telepresence’i kohta keskuses veel ilmunud ei ole.

Ühesõnaga, kõik osutus mitte nii hirmutavaks. Panime kõik toimingud, mis nõuavad arendaja täitmist Helm diagrammi tekstifaili nimega NOTES.txt. Seega näeb arendaja pärast teenuse juurutamist Kubernetesesse GitLabi töölogis juhiseid kohaliku arendajakeskkonna käivitamiseks:

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

Me ei peatu üksikasjalikult selles juhendis kirjeldatud sammudel... välja arvatud viimane. Mis juhtub Telepresence'i käivitamise ajal?

Telepresence'iga töötamine

Käivitamisel (kasutades ülaltoodud juhistes määratud viimast käsku) määrame:

  • nimeruum, milles mikroteenus töötab;
  • juurutuse ja konteineri nimed, kuhu tahame tungida.

Ülejäänud argumendid on valikulised. Kui meie teenus suhtleb Kubernetes API-ga ja selle jaoks Teenusekonto loodud, peame oma töölauale paigaldama sertifikaadid/märgid. Selleks kasutage valikut --mount=true (Või --mount=/dst_path), mis ühendab juure (/) Kubernetese konteinerist meie töölauale. Pärast seda saame (olenevalt operatsioonisüsteemist ja rakenduse käivitamise viisist) kasutada klastrist pärinevaid "klahve".

Kõigepealt vaatame kõige universaalsemat võimalust rakenduse käitamiseks – Dockeri konteineris. Selleks kasutame võtit --docker-run ja ühendage kataloog koos koodiga konteinerisse: -v `pwd`:/app

Pange tähele, et see eeldab käivitamist projekti kataloogist. Rakenduse kood paigaldatakse kataloogi /app konteineris.

Järgmine: -v /tmp/app/var/run/secrets:/var/run/secrets — kataloogi koos sertifikaadi/märgiga ühendamiseks konteinerisse.

Sellele valikule järgneb lõpuks pilt, milles rakendus töötab. NB: Pildi ehitamisel peate täpsustama CMD või ENTRYPOINT!

Mis täpselt edasi saab?

  • Kubernetesis muudetakse määratud juurutuse puhul koopiate arvuks 0. Selle asemel käivitatakse uus juurutus – koos asenduskonteineriga backend.
  • Töölaual käivitub 2 konteinerit: esimene koos Telepresence'iga (see puhverserveri päringuid Kubernetesist/kubernetesse), teine ​​arendatava rakendusega.
  • Kui täidame rakendusega konteinerisse, siis on kõik Helmi poolt juurutamise käigus üle kantud ENV muutujad meile kättesaadavad ning samuti on saadaval kõik teenused. Jääb üle vaid oma lemmik-IDE-s koodi redigeerida ja tulemust nautida.
  • Töö lõpus peate lihtsalt sulgema terminali, milles Telepresence töötab (lõpetage seanss klahvikombinatsiooniga Ctrl+C) - Dockeri konteinerid peatuvad töölaual ja Kubernetesis naaseb kõik algolekusse. Jääb üle vaid siduda, väljastada MR ja see üle vaadata/ühendada/… (olenevalt teie töövoogudest).

Kui me ei soovi rakendust Dockeri konteineris käivitada – näiteks arendame me mitte PHP-s, vaid Go-s ja ehitame selle siiski kohapeal – on Telepresence'i käivitamine veelgi lihtsam:

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

Kui rakendus pääseb juurde Kubernetes API-le, peate ühendama võtmete kataloogi (https://www.telepresence.io/howto/volumes). Linuxi jaoks on utiliit juur:

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

Pärast Telepresence'i käivitamist ilma valikuta --docker-run kõik keskkonnamuutujad on praeguses terminalis saadaval, seega tuleb rakendus selles käivitada.

NB: Kasutades näiteks PHP-d, tuleb meeles pidada, et keelata arenduseks erinevad op_cache, apc ja muud kiirendid – vastasel juhul ei vii koodi redigeerimine soovitud tulemuseni.

Tulemused

Kohalik arendus Kubernetesega on probleem, mille lahendus kasvab võrdeliselt selle platvormi kasutuselevõtuga. Saanud arendajatelt (klientidelt) asjakohaseid taotlusi, asusime neid lahendama esimeste olemasolevate vahenditega, mis aga pika aja jooksul ennast ei tõestanud. Õnneks pole see ilmselgeks saanud mitte ainult praegu ja mitte ainult meile, nii et maailmas on juba sobivamaid vahendeid ilmunud ja Telepresence on neist tuntuim (muide, on ka karkass Google'ilt). Meie kasutuskogemus pole veel nii suur, kuid juba annab põhjust seda soovitada oma “kolleegidele poes” – proovige järele!

PS

Muud K8s näpunäidete ja nippide seeriast:

Allikas: www.habr.com

Lisa kommentaar