„Kubernetes“ patarimai ir gudrybės: apie vietinę plėtrą ir „Telepresence“.

Mūsų vis dažniau klausiama apie mikropaslaugų kūrimą Kubernetes. Kūrėjai, ypač interpretuojamų kalbų, nori greitai pataisyti kodą savo mėgstamoje IDE ir pamatyti rezultatą nelaukdami, kol bus sukurtas / įdiegtas – tiesiog paspausdami F5. O kalbant apie monolitinę aplikaciją, pakako lokaliai įdiegti duomenų bazę ir žiniatinklio serverį (Docker, VirtualBox...), o tada iškart mėgautis kūrimu. Supjaustant monolitus į mikropaslaugas ir atėjus Kubernetes, atsiradus priklausomybėms vienas nuo kito, viskas pasidarė šiek tiek sunkiau. Kuo daugiau šių mikropaslaugų, tuo daugiau problemų. Norint vėl mėgautis plėtra, reikia pakelti ne vieną ir ne du Docker konteinerius, o kartais net ne vieną dešimtį... Apskritai visa tai gali užtrukti gana daug laiko, nes ir jį reikia nuolat atnaujinti .

Skirtingu metu bandėme skirtingus problemos sprendimus. Ir pradėsiu nuo sukauptų problemų sprendimo būdų arba tiesiog „ramentų“.

1. Ramentai

Dauguma IDE turi galimybę redaguoti kodą tiesiai serveryje naudojant FTP/SFTP. Šis kelias labai akivaizdus ir mes iškart nusprendėme juo pasinaudoti. Jo esmė yra tokia:

1. Kūrimo aplinkų grupėje (kūrėjas / peržiūra) paleidžiamas papildomas konteineris su SSH prieiga ir kūrėjo, kuris įsipareigos / įdiegs programą, viešasis SSH raktas.
2. Pradiniame etape (konteinerio viduje prepare-app) perkelkite kodą į emptyDirturėti prieigą prie kodo iš programų konteinerių ir SSH serverio.

Kad geriau suprasčiau techninį tokios schemos įgyvendinimą, pateiksiu Kubernetes susijusių YAML konfigūracijų fragmentus.

Konfigūracijos

1.1. vertybės.yaml

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

Čia vasya.pupkin yra kintamojo reikšmė ${GITLAB_USER_LOGIN}.

1.2. dislokavimas.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. paslaptis.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 }}

Galutinis prisilietimas

Po to belieka perkelti būtini gitlab-ci.yml kintamieji:

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: diegimą paleidęs kūrėjas gali prisijungti naudodamas paslaugos pavadinimą (kaip saugiai suteikti prieigą prie klasterio, mes jau pasakėme) iš darbalaukio per SFTP ir redaguokite kodą nelaukdami, kol jis bus pristatytas į grupę.

Tai visiškai veikiantis sprendimas, tačiau įgyvendinimo požiūriu jis turi akivaizdžių trūkumų:

• poreikis patobulinti vairo diagramą, dėl kurios ateityje sunku ją skaityti;
• gali naudotis tik paslaugą įdiegęs asmuo;
• turite atsiminti, kad tada sinchronizuoti jį su vietiniu katalogu su kodu ir įpareigoti jį Git.

2. Telepresence

Projektas Nuotolinis buvimas buvo žinomas gana seniai, bet mes, kaip sakoma, „nespėjome rimtai to išbandyti praktiškai“. Tačiau paklausa padarė savo darbą ir dabar džiaugiamės galėdami pasidalinti savo patirtimi, kuri gali būti naudinga mūsų tinklaraščio skaitytojams – juolab, kad centre dar nebuvo kitos medžiagos apie Telepresence.

Trumpai tariant, viskas pasirodė ne taip baisu. Visus veiksmus, kuriuos kūrėjas turi atlikti, patalpinome į Helm diagramos tekstinį failą, vadinamą NOTES.txt. Taigi, įdiegęs paslaugą Kubernetes, kūrėjas mato instrukcijas, kaip paleisti vietinę kūrėjo aplinką „GitLab“ darbo žurnale:

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

Mes nesigilinsime į šioje instrukcijoje aprašytus veiksmus... išskyrus paskutinį. Kas nutinka „Telepresence“ paleidimo metu?

Darbas su Telepresence

Paleidžiant (naudodami paskutinę komandą, nurodytą aukščiau pateiktose instrukcijose), nustatome:

• vardų sritis, kurioje veikia mikropaslauga;
• diegimo ir talpyklos, į kurią norime patekti, pavadinimai.

Likę argumentai yra neprivalomi. Jei mūsų paslauga sąveikauja su Kubernetes API ir jai Paslaugos paskyra sukurta, turime įdiegti sertifikatus/žetonus savo darbalaukyje. Norėdami tai padaryti, naudokite parinktį --mount=true (Arba --mount=/dst_path), kuris prijungs šaknį (/) iš Kubernetes konteinerio į darbalaukį. Po to galime (priklausomai nuo OS ir programos paleidimo) naudoti klasterio „raktus“.

Pirmiausia pažvelkime į universaliausią programos paleidimo variantą – „Docker“ konteineryje. Norėdami tai padaryti, naudosime raktą --docker-run ir įdėkite katalogą su kodu į konteinerį: -v `pwd`:/app

Atkreipkite dėmesį, kad tai daroma iš projekto katalogo. Programos kodas bus įtrauktas į katalogą /app konteineryje.

Kitas: -v /tmp/app/var/run/secrets:/var/run/secrets — katalogą su sertifikatu/žetonu prijungti į konteinerį.

Galiausiai po šios parinkties rodomas vaizdas, kuriame bus paleista programa. NB: Kurdami vaizdą turite nurodyti CMD arba ENTRYPOINT!

Kas tiksliai bus toliau?

• „Kubernetes“ programoje nurodyto diegimo kopijų skaičius bus pakeistas į 0. Vietoj to bus paleistas naujas diegimas su pakaitiniu konteineriu backend.
• Darbalaukyje bus paleisti 2 konteineriai: pirmasis su „Telepresence“ (jis perduos užklausas iš / į Kubernetes), antrasis su kuriama programa.
• Jei mes įvesime į konteinerį su programa, visi ENV kintamieji, kuriuos Helm perdavė diegimo metu, bus prieinami ir visos paslaugos taip pat bus prieinamos. Belieka redaguoti kodą mėgstamoje IDE ir mėgautis rezultatu.
• Pasibaigus darbui, tereikia uždaryti terminalą, kuriame veikia Telepresence (nutraukti seansą Ctrl+C) – „Docker“ konteineriai sustos darbalaukyje, o „Kubernetes“ viskas grįš į pradinę būseną. Belieka įsipareigoti, išduoti MR ir perduoti jį peržiūrėti/sujungti/... (priklausomai nuo jūsų darbo eigos).

Jei nenorime paleisti programos „Docker“ konteineryje – pavyzdžiui, kuriame ne PHP, o „Go“ ir vis tiek kuriame ją vietoje, „Telepresence“ paleidimas bus dar paprastesnis:

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

Jei programa pasiekia Kubernetes API, turėsite prijungti raktų katalogą (https://www.telepresence.io/howto/volumes). Yra „Linux“ skirta programa šaknis:

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

Paleidus Telepresence be parinkties --docker-run visi aplinkos kintamieji bus pasiekiami dabartiniame terminale, todėl programa turi būti paleista jame.

NB: Kai naudojate, pavyzdžiui, PHP, turite nepamiršti išjungti įvairius op_cache, apc ir kitus kūrimo greitintuvus – kitaip kodo redagavimas nepasieks norimo rezultato.

rezultatai

Vietinė plėtra su Kubernetes yra problema, kurios sprendimas auga proporcingai šios platformos plitimui. Gavę atitinkamus kūrėjų (savo klientų) užklausas, pradėjome juos spręsti pirmomis turimomis priemonėmis, kurios, tačiau, per ilgą laiką nepasitvirtino. Laimei, tai tapo akivaizdu ne tik dabar ir ne tik mums, tad pasaulyje jau atsirado tinkamesnių priemonių, o Telepresence yra pati žinomiausia iš jų (beje, yra ir karkasas iš Google). Mūsų naudojimo patirtis dar nėra tokia didelė, bet tai jau suteikia pagrindo rekomenduoti jį savo „kolegoms parduotuvėje“ – išbandykite!

PS

Kiti iš K8s patarimų ir gudrybių serijos:

• «„Kubernetes“ patarimai ir gudrybės: pasirinktiniai klaidų puslapiai „NGINX Ingress“.»;
• «Grupėje veikiančių išteklių perkėlimas į Helm 2 valdymą»;
• «Apie mazgų paskirstymą ir įkėlimus žiniatinklio programoje»;
• «Prieiga prie kūrimo svetainių»;
• «Didelių duomenų bazių įkrovos spartinimas".

Šaltinis: www.habr.com