Konsiloj kaj lertaĵoj de Kubernetes: pri loka evoluo kaj Teleĉeesto

Ni estas ĉiam pli demandataj pri evoluado de mikroservoj en Kubernetes. Programistoj, precipe de interpretitaj lingvoj, volas rapide korekti kodon en sia plej ŝatata IDE kaj vidi la rezulton sen atendi konstruon/deplojon - per simple premado F5. Kaj se temas pri monolita aplikaĵo, sufiĉis loke instali datumbazon kaj retservilon (en Docker, VirtualBox...), kaj poste tuj ĝui evoluadon. Kun la tranĉo de monolitoj en mikroservojn kaj la alveno de Kubernetes, kun la apero de dependecoj unu de la alia, ĉio ĝi fariĝis iom pli malfacila. Ju pli da ĉi tiuj mikroservoj, des pli da problemoj. Por denove ĝui disvolviĝon, necesas levi pli ol unu aŭ du Docker-ujojn, kaj foje eĉ pli ol dekduon... Ĝenerale, ĉio ĉi povas preni sufiĉe da tempo, ĉar ĝi ankaŭ devas esti ĝisdatigita. .

En malsamaj tempoj ni provis malsamajn solvojn al la problemo. Kaj mi komencos per la amasigitaj solvoj aŭ simple "lambastonoj".

1. Lambastonoj

Plej multaj IDEoj havas la kapablon redakti kodon rekte sur la servilo uzante FTP/SFTP. Ĉi tiu vojo estas tre evidenta kaj ni tuj decidis uzi ĝin. Ĝia esenco resumiĝas al la sekvanta:

1. En la podo de evolumedioj (dev/revizio), plia ujo estas lanĉita kun SSH-aliro kaj plusendado de la publika SSH-ŝlosilo de la programisto, kiu transdonos/deplojos la aplikaĵon.
2. En la komenca stadio (ene de la ujo prepare-app) transdoni la kodon al emptyDirhavi aliron al la kodo de la aplikaĵujo kaj la SSH-servilo.

Por pli bone kompreni la teknikan efektivigon de tia skemo, mi provizos fragmentojn de la implikitaj YAML-agordoj en Kubernetes.

Agordoj

1.1. valoroj.yaml

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

estas vasya.pupkin estas la valoro de la variablo ${GITLAB_USER_LOGIN}.

1.2. deplojo.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. sekreta.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 }}

fina tuŝo

Post tio restas nur translokigo postulataj gitlab-ci.yml variabloj:

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: la programisto kiu lanĉis la deplojon povas konektiĝi per servonomo (kiel sekure doni aliron al la areto, ni jam diris) de via labortablo per SFTP kaj redaktu la kodon sen atendi ke ĝi estos liverita al la areto.

Ĉi tio estas tute funkcia solvo, sed el efektiviga vidpunkto ĝi havas evidentajn malavantaĝojn:

• la bezono rafini la Helm-diagramon, kio malfaciligas la legadon estonte;
• povas esti uzata nur de la persono kiu deplojis la servon;
• vi devas memori poste sinkronigi ĝin kun la loka dosierujo kun la kodo kaj transigi ĝin al Git.

2. Teleĉeesto

La projekto Teleĉeesto estas konata dum sufiĉe longa tempo, sed ni, kiel oni diras, "ne klopodis serioze provi ĝin praktike." Tamen postulo plenumis sian laboron kaj nun ni ĝojas kundividi nian sperton, kiu povas esti utila al legantoj de nia blogo - precipe ĉar ankoraŭ ne estis aliaj materialoj pri Teleĉeesto en la nabo.

Resume, ĉio montriĝis ne tiom timiga. Ni metis ĉiujn agojn, kiuj postulas ekzekuton de la programisto en tekstdosieron Helm-diagramon nomitan NOTES.txt. Tiel, post deplojado de la servo al Kubernetes, la programisto vidas instrukciojn por lanĉi la lokan dev-medion en la laborprotokolo de GitLab:

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

Ni ne detale detale pri la paŝoj priskribitaj en ĉi tiu instrukcio... escepte de la lasta. Kio okazas dum la lanĉo de Telepresence?

Laborante kun Teleĉeesto

Ĉe ekfunkciigo (uzante la lastan komandon specifitan en la supraj instrukcioj), ni starigas:

• nomspaco en kiu la mikroservo funkcias;
• nomoj de la deplojo kaj ujo, kiujn ni volas penetri.

La ceteraj argumentoj estas laŭvolaj. Se nia servo interagas kun kaj por la Kubernetes API создан ServiceAccount, ni devas munti atestilojn/ĵetonojn sur nia labortablo. Por fari tion, uzu la opcion --mount=true (aŭ --mount=/dst_path), kiu montos la radikon (/) de la Kubernetes-ujo al nia labortablo. Post ĉi tio, ni povas (depende de la OS kaj kiel la aplikaĵo estas lanĉita) uzi la "ŝlosilojn" de la areto.

Unue, ni rigardu la plej universalan opcion por ruli aplikaĵon - en Docker-ujo. Por fari tion ni uzos la ŝlosilon --docker-run kaj muntu la dosierujon kun la kodo en la ujon: -v `pwd`:/app

Bonvolu noti, ke tio supozas ruladon de la projekta dosierujo. La aplika kodo estos muntita en la dosierujo /app en ujo.

Sekva: -v /tmp/app/var/run/secrets:/var/run/secrets — munti la dosierujon kun la atestilo/ĵetono en ujon.

Ĉi tiu opcio estas finfine sekvata de la bildo en kiu ruliĝos la aplikaĵo. NB: Konstruante bildon, vi devas specifi CMD aŭ ENTRYPOINT!

Kio ĝuste okazos poste?

• En Kubernetes, por la specifita Deplojo, la nombro da kopioj estos ŝanĝita al 0. Anstataŭe, nova Deplojo estos lanĉita - kun anstataŭa ujo. backend.
• 2 ujoj lanĉos sur la labortablo: la unua kun Teleĉeesto (ĝi prokuros petojn de/al Kubernetes), la dua kun la aplikaĵo evoluanta.
• Se ni efektivigas en la ujon kun la aplikaĵo, tiam ĉiuj ENV-variabloj transdonitaj de Helm dum disfaldo estos disponeblaj por ni, kaj ĉiuj servoj ankaŭ estos disponeblaj. Restas nur redakti la kodon en via plej ŝatata IDE kaj ĝui la rezulton.
• Fine de la laboro, vi nur bezonas fermi la terminalon, en kiu funkcias Telepresence (finu la sesion per Ctrl+C) - Docker-ujoj ĉesos sur la labortablo, kaj en Kubernetes ĉio revenos al sia komenca stato. Restas nur fari, elsendi la MR kaj transdoni ĝin al revizio/kunfandi/... (depende de viaj laborfluoj).

Se ni ne volas ruli la aplikaĵon en Docker-ujo - ekzemple, ni disvolvas ne en PHP, sed en Go, kaj ankoraŭ konstruas ĝin loke - lanĉi Telepresence estos eĉ pli simpla:

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

Se via aplikaĵo aliras la Kubernetes API, vi devos munti la dosierujon de ŝlosiloj (https://www.telepresence.io/howto/volumes). Estas ilo por Linukso radiko:

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

Post lanĉo de Telepresence sen la opcio --docker-run ĉiuj mediovariabloj estos disponeblaj en la nuna terminalo, do la aplikaĵo devas esti lanĉita en ĝi.

NB: Kiam vi uzas, ekzemple, PHP, vi devas memori malŝalti diversajn op_cache, apc kaj aliajn akceliloj por disvolviĝo - alie redakti la kodon ne kondukos al la dezirata rezulto.

Rezultoj

Loka disvolviĝo kun Kubernetes estas problemo, kies solvo kreskas proporcie al la disvastigo de ĉi tiu platformo. Ricevante koncernajn petojn de programistoj (de niaj klientoj), ni komencis solvi ilin per la unuaj disponeblaj rimedoj, kiuj tamen ne pruvis sin dum longa tempo. Feliĉe, tio evidentiĝis ne nur nun kaj ne nur al ni, do jam aperis en la mondo pli taŭgaj rimedoj, kaj Teleĉeesto estas la plej fama el ili (cetere ekzistas ankaŭ skafaldo de Guglo). Nia sperto pri uzado de ĝi ankoraŭ ne estas tiel bonega, sed ĝi jam donas al ni kialon rekomendi ĝin al niaj "kolegoj en la butiko" - provu ĝin!

PS

Aliaj el la serio de konsiletoj kaj lertaĵoj K8s:

• «Konsiloj kaj lertaĵoj de Kubernetes: kutimaj eraraj paĝoj en NGINX Ingress»;
• «Transdonante rimedojn kurantajn en areto al administrado de Helm 2»;
• «Pri noda atribuo kaj ŝarĝoj sur TTT-apliko»;
• «Aliro al dev-ejoj»;
• «Akcelo de ekfunkciigo por grandaj datumbazoj".

fonto: www.habr.com