ProHoster > блог > Администрација > Совети и трикови на Kubernetes: за локалниот развој и Телеприсуството

Совети и трикови на Kubernetes: за локалниот развој и Телеприсуството

Совети и трикови на Kubernetes: за локалниот развој и Телеприсуството

Сè повеќе нè прашуваат за развој на микросервиси во Кубернетес. Програмерите, особено на толкуваните јазици, сакаат брзо да го поправат кодот во нивниот омилен IDE и да го видат резултатот без да чекаат за изградба/распоредување - со едноставно притискање на F5. А кога станува збор за монолитна апликација, доволно беше локално да се инсталира база на податоци и веб сервер (во Docker, VirtualBox...), а потоа веднаш да уживате во развојот. Со сечењето на монолитните во микросервиси и доаѓањето на Кубернетите, со појавата на зависности една од друга, сè стана малку потешко. Колку повеќе од овие микроуслуги, толку повеќе проблеми. За повторно да уживате во развојот, треба да подигнете повеќе од еден или два Docker контејнери, а понекогаш дури и повеќе од десетина... Во принцип, сето ова може да потрае доста време, бидејќи исто така треба да се ажурира. .

Во различни периоди пробавме различни решенија за проблемот. И ќе започнам со акумулираните решенија или едноставно „патерици“.

1. Патерици

Повеќето IDE имаат можност да го уредуваат кодот директно на серверот користејќи FTP/SFTP. Овој пат е многу очигледен и веднаш решивме да го искористиме. Нејзината суштина се сведува на следново:

  1. Во подлогата за развојни средини (dev/преглед), се лансира дополнителен контејнер со SSH пристап и проследување на јавниот SSH клуч на развивачот кој ќе ја изврши/расположи апликацијата.
  2. Во почетната фаза (во контејнерот prepare-app) префрлете го кодот на emptyDirда има пристап до кодот од контејнерите на апликацијата и SSH серверот.

Совети и трикови на Kubernetes: за локалниот развој и Телеприсуството

За подобро да ја разберам техничката имплементација на таквата шема, ќе дадам фрагменти од вклучените YAML конфигурации во Kubernetes.

конфигурации

1.1. вредности.yaml

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

Тука vasya.pupkin е вредноста на променливата ${GITLAB_USER_LOGIN}.

1.2. распоредување.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. тајна.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 }}

Конечен допир

После тоа останува само да се префрли потребни gitlab-ci.yml променливи:

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: развивачот кој го започна распоредувањето може да се поврзе по име на услугата (како безбедно да се додели пристап до кластерот, веќе кажавме) од вашата работна површина преку SFTP и уредете го кодот без да чекате да се достави до кластерот.

Ова е целосно работно решение, но од гледна точка на имплементација има очигледни недостатоци:

  • потребата за усовршување на табелата на Хелм, што го отежнува читањето во иднина;
  • може да се користи само од лицето кое ја распоредило услугата;
  • треба да запомните потоа да го синхронизирате со локалниот директориум со кодот и да го предадете на Git.

2. Телеприсутност

Проект Теле-присуство е познат подолго време, но ние, како што велат, „не успеавме сериозно да го пробаме во пракса“. Сепак, побарувачката ја заврши својата работа и сега со задоволство го споделуваме нашето искуство, што може да биде корисно за читателите на нашиот блог - особено што сè уште нема други материјали за Telepresence на центарот.

Накратко, сè се покажа дека не е толку страшно. Ги сместивме сите дејства што бараат извршување од страна на развивачот во текстуална датотека наречена Helm chart NOTES.txt. Така, по распоредувањето на услугата на Kubernetes, развивачот гледа инструкции за стартување на локалната околина за развој во дневникот за работни места на 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
#########################################################################

Ние нема да се задржиме во детали на чекорите опишани во оваа инструкција... со исклучок на последниот. Што се случува за време на лансирањето на Telepresence?

Работа со Telepresence

При стартување (со користење на последната команда наведена во упатствата погоре), поставивме:

  • именски простор во кој работи микросервисот;
  • имиња на распоредот и контејнерот во кој сакаме да навлеземе.

Останатите аргументи се опционални. Ако нашата услуга е во интеракција со и за Kubernetes API Создадена е сметка за услуга, треба да монтираме сертификати/токени на нашата работна површина. За да го направите ова, користете ја опцијата --mount=true (Или --mount=/dst_path), кој ќе го монтира коренот (/) од контејнерот Kubernetes на нашата работна површина. После ова, можеме (во зависност од оперативниот систем и како е стартувана апликацијата) да ги користиме „клучевите“ од кластерот.

Прво, да ја разгледаме најуниверзалната опција за водење апликација - во контејнер Docker. За да го направите ова, ќе го користиме клучот --docker-run и монтирајте го директориумот со кодот во контејнерот: -v `pwd`:/app

Ве молиме имајте предвид дека ова претпоставува извршување од директориумот на проектот. Кодот на апликацијата ќе биде монтиран во директориумот /app во контејнер.

Напред: -v /tmp/app/var/run/secrets:/var/run/secrets — да го монтирате директориумот со сертификатот/токенот во контејнер.

На оваа опција конечно следи сликата на која ќе работи апликацијата. NB: Кога градите слика, мора да наведете CMD или ENTRYPOINT!

Што точно ќе се случи следно?

  • Во Kubernetes, за наведеното Распоредување, бројот на реплики ќе се смени на 0. Наместо тоа, ќе биде лансиран нов Deployment - со заменски контејнер backend.
  • 2 контејнери ќе се стартуваат на работната површина: првиот со Telepresence (ќе посредува барања од/до Kubernetes), вториот со апликацијата што се развива.
  • Ако извршиме извршување во контејнерот со апликацијата, тогаш сите ENV променливи пренесени од Helm за време на распоредувањето ќе ни бидат достапни, а ќе ни бидат достапни и сите услуги. Останува само да го уредите кодот во омилениот IDE и да уживате во резултатот.
  • На крајот од работата, само треба да го затворите терминалот во кој работи Telepresence (завршете ја сесијата со Ctrl+C) - контејнерите на Docker ќе застанат на работната површина, а во Kubernetes сè ќе се врати во почетната состојба. Останува само да се обврзе, да се издаде MR и да се пренесе на преглед/спој/... (во зависност од вашите работни текови).

Ако не сакаме да ја извршиме апликацијата во контејнер Docker - на пример, не развиваме во PHP, туку во Go, а сепак ја градиме локално - стартувањето на Telepresence ќе биде уште поедноставно:

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

Ако апликацијата пристапи до Kubernetes API, ќе треба да го монтирате директориумот со клучеви (https://www.telepresence.io/howto/volumes). Постои алатка за Linux корен:

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

По лансирањето на Telepresence без опција --docker-run сите променливи на животната средина ќе бидат достапни во тековниот терминал, така што апликацијата мора да биде лансирана во него.

NB: Кога користите, на пример, PHP, мора да запомните да оневозможите различни op_cache, apc и други акцелератори за развој - инаку уредувањето на кодот нема да доведе до посакуваниот резултат.

Резултатите од

Локалниот развој со Kubernetes е проблем чие решение расте пропорционално со ширењето на оваа платформа. Добивајќи релевантни барања од програмери (од нашите клиенти), почнавме да ги решаваме со првите достапни средства, кои, сепак, не се покажаа на долги патеки. За среќа, тоа стана очигледно не само сега и не само кај нас, па во светот веќе се појавија посоодветни средства, а Telepresence е најпознат од нив (патем има и скеле од Google). Нашето искуство за користење сè уште не е толку големо, но веќе ни дава причина да го препорачаме на нашите „колеги во продавницата“ - пробајте го!

PS

Друго од серијата совети и трикови K8s:

Извор: www.habr.com

Додадете коментар