ProHoster > Blog > Adminisztráció > Kubernetes tippek és trükkök: a helyi fejlesztésről és a Telepresence-ről

Kubernetes tippek és trükkök: a helyi fejlesztésről és a Telepresence-ről

Kubernetes tippek és trükkök: a helyi fejlesztésről és a Telepresence-ről

Egyre gyakrabban kérdeznek bennünket a Kubernetes mikroszolgáltatásainak fejlesztéséről. A fejlesztők, különösen az értelmezett nyelvek esetében, gyorsan szeretnék kijavítani a kódot kedvenc IDE-jükben, és látni akarják az eredményt anélkül, hogy megvárnák a felépítést/telepítést – egyszerűen az F5 megnyomásával. Ha pedig monolitikus alkalmazásról volt szó, akkor elég volt helyben telepíteni egy adatbázist és egy webszervert (Dockerben, VirtualBoxban...), és utána azonnal élvezni a fejlesztést. A monolitok mikroszolgáltatásokba vágásával és a Kubernetes megjelenésével, az egymástól való függőség megjelenésével minden kicsit nehezebb lett. Minél több ilyen mikroszolgáltatás, annál több probléma. Ahhoz, hogy újra élvezhessük a fejlesztést, egy-két Docker-konténernél többet kell felemelni, sőt néha egy tucatnál is többet... Általánosságban elmondható, hogy mindez elég sok időt vehet igénybe, hiszen ezt is naprakészen kell tartani .

Különböző időpontokban különböző megoldásokat próbáltunk a problémára. És kezdem a felhalmozott kerülő megoldásokkal vagy egyszerűen csak „mankókkal”.

1. Mankók

A legtöbb IDE képes közvetlenül a kiszolgálón szerkeszteni a kódot FTP/SFTP használatával. Ez az út nagyon kézenfekvő, és azonnal úgy döntöttünk, hogy használjuk. Lényege a következőkben rejlik:

  1. A fejlesztői környezetek podjában (dev/review) egy további konténer indul SSH-hozzáféréssel, és továbbítja az alkalmazást véglegesítő/telepítő fejlesztő nyilvános SSH-kulcsát.
  2. A kezdeti szakaszban (a tartályon belül prepare-app) vigye át a kódot ide emptyDirhogy hozzáférjen a kódhoz az alkalmazástárolókból és az SSH-kiszolgálóról.

Kubernetes tippek és trükkök: a helyi fejlesztésről és a Telepresence-ről

Egy ilyen séma technikai megvalósításának jobb megértése érdekében a Kubernetes érintett YAML-konfigurációinak töredékeit közlöm.

Konfigurációk

1.1. értékek.yaml

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

Itt vasya.pupkin a változó értéke ${GITLAB_USER_LOGIN}.

1.2. telepítés.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. titkos.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 }}

Végső érintés

Ezek után már csak az áthelyezés marad hátra szükséges gitlab-ci.yml változók:

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: a telepítést elindító fejlesztő szolgáltatásnév alapján csatlakozhat (hogyan biztosítson biztonságos hozzáférést a fürthöz, már elmondtuk).

Ez egy teljesen működő megoldás, de megvalósítási szempontból nyilvánvaló hátrányai vannak:

  • a Helm-diagram finomításának szükségessége, ami megnehezíti az olvasást a jövőben;
  • csak a szolgáltatást telepítő személy használhatja;
  • emlékeznie kell arra, hogy szinkronizálja a helyi könyvtárral a kóddal, és véglegesítse a Gitben.

2. Telejelenlét

Terv TelePresence elég régóta ismert, de mi, ahogy mondani szokás, „nem jutottunk el addig, hogy a gyakorlatban komolyan kipróbáljuk”. A kereslet azonban megtette a dolgát, és most örömmel osztjuk meg tapasztalatainkat, amelyek hasznosak lehetnek blogunk olvasói számára - főleg, hogy a Telepresence-ről más anyagok még nem jelentek meg a hubon.

Röviden, minden kiderült, nem olyan ijesztő. Minden olyan műveletet, amely végrehajtást igényel a fejlesztő részéről, egy Helm chart szövegfájlba helyeztük el NOTES.txt. Így a szolgáltatás Kubernetesben történő üzembe helyezése után a fejlesztő a GitLab munkanaplójában látja a helyi fejlesztői környezet elindítására vonatkozó utasításokat:

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

Az ebben az utasításban leírt lépésekkel nem foglalkozunk részletesen... az utolsó kivételével. Mi történik a Telepresence indulásakor?

Munka a Telepresence szolgáltatással

Indításkor (a fenti utasításokban megadott utolsó paranccsal) beállítjuk:

  • névtér, amelyben a mikroszolgáltatás fut;
  • annak a telepítésnek és a tárolónak a neve, amelyen át akarunk hatolni.

A többi argumentum opcionális. Ha szolgáltatásunk együttműködik a Kubernetes API-val és a Kubernetes API számára ServiceAccount létrehozva, tanúsítványokat/tokeneket kell csatolnunk az asztalunkra. Ehhez használja a lehetőséget --mount=true (vagy --mount=/dst_path), amely a Kubernetes-tároló gyökérjét (/) csatolja az asztalunkra. Ezt követően (az operációs rendszertől és az alkalmazás indítási módjától függően) használhatjuk a klaszter „kulcsait”.

Először nézzük meg az alkalmazás futtatásának leguniverzálisabb lehetőségét - Docker-tárolóban. Ehhez a kulcsot fogjuk használni --docker-run és csatolja a kódot tartalmazó könyvtárat a tárolóba: -v `pwd`:/app

Kérjük, vegye figyelembe, hogy ez azt feltételezi, hogy a projektkönyvtárból fut. Az alkalmazás kódja be lesz csatolva a könyvtárba /app konténerben.

Következő: -v /tmp/app/var/run/secrets:/var/run/secrets — a tanúsítvánnyal/tokennel ellátott könyvtár beillesztése egy tárolóba.

Ezt az opciót végül az a kép követi, amelyben az alkalmazás futni fog. NB: Kép készítésekor meg kell adni CMD vagy ENTRYPOINT!

Pontosan mi lesz ezután?

  • A Kubernetesben a megadott telepítéshez a replikák száma 0-ra módosul. Ehelyett egy új telepítés indul – egy helyettesítő tárolóval. backend.
  • 2 konténer fog elindulni az asztalon: az első Telepresence-szel (proxy kéréseket küld a Kubernetesről/Kubernetes felé), a második a fejlesztés alatt álló alkalmazással.
  • Ha az alkalmazással együtt végrehajtjuk a konténerbe, akkor a Helm által a telepítés során átvitt összes ENV változó elérhető lesz számunkra, és az összes szolgáltatás is elérhető lesz. Nincs más hátra, mint szerkeszteni a kódot kedvenc IDE-jében, és élvezni az eredményt.
  • A munka végén csak be kell zárnia a terminált, amelyben a Telepresence fut (a munkamenetet a Ctrl + C billentyűkombinációval fejezze be) - A Docker-tárolók leállnak az asztalon, és a Kubernetesben minden visszatér a kezdeti állapotába. Már csak a kötelezettségvállalás, az MR kiadása és átadása az áttekintéshez/egyesítéshez/… (a munkafolyamatoktól függően).

Ha nem Docker konténerben szeretnénk futtatni az alkalmazást – például nem PHP-ben, hanem Go-ban fejlesztünk, és mégis helyben építjük – a Telepresence elindítása még egyszerűbb lesz:

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

Ha az alkalmazás hozzáfér a Kubernetes API-hoz, fel kell csatolnia a kulcsok könyvtárát (https://www.telepresence.io/howto/volumes). Van egy segédprogram Linuxhoz gyökér:

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

A Telepresence opció nélküli elindítása után --docker-run minden környezeti változó elérhető lesz az aktuális terminálon, ezért az alkalmazást abban kell elindítani.

NB: Például PHP használatakor ne felejtse el letiltani a különféle op_cache, apc és egyéb gyorsítókat a fejlesztéshez - különben a kód szerkesztése nem vezet a kívánt eredményhez.

Eredményei

A Kubernetes helyi fejlesztése olyan probléma, amelynek megoldása ennek a platformnak a terjedésével arányosan növekszik. A fejlesztőktől (ügyfeleinktől) érkező releváns kéréseket az első elérhető eszközökkel kezdtük megoldani, amelyek azonban hosszú távon nem bizonyultak. Szerencsére ez nem csak most és nem csak nekünk vált nyilvánvalóvá, így már megjelentek a világban erre alkalmasabb eszközök, amelyek közül a Telepresence a leghíresebb (egyébként van kerítés a Google-tól). Használati tapasztalataink még nem túl nagyok, de máris okot adunk arra, hogy „bolti kollégáinknak” ajánljuk – próbáljátok ki!

PS

Egyéb a K8s tippek és trükkök sorozatból:

Forrás: will.com

Hozzászólás