🥇Tips & trik Kubernetes: babagan pembangunan lokal lan Telepresence

Kita tambah akeh takon babagan ngembangake layanan mikro ing Kubernetes. Pangembang, utamane basa sing diinterpretasikake, pengin cepet mbenerake kode ing IDE favorit lan ndeleng asil tanpa ngenteni mbangun / penyebaran - kanthi mung mencet F5. Lan nalika nerangake aplikasi monolitik, iku cukup kanggo nginstal database lokal lan server web (ing Docker, VirtualBox ...), lan banjur langsung seneng pembangunan. Kanthi nglereni monoliths menyang microservices lan rawuh saka Kubernetes, karo katon dependensi ing saben liyane, kabeh dadi rada angel. Luwih akeh layanan mikro iki, luwih akeh masalah. Kanggo seneng pembangunan maneh, sampeyan kudu ngunggahake luwih saka siji utawa loro kontaner Docker, lan kadhangkala malah luwih saka rolas ... Umumé, kabeh iki bisa njupuk cukup akeh wektu, amarga iku uga kudu tetep anyar. .

Ing wektu sing beda-beda, kita nyoba macem-macem solusi kanggo masalah kasebut. Lan aku bakal miwiti karo workarounds akumulasi utawa mung "kruk".

1. Kruk

Umume IDE duwe kemampuan kanggo ngowahi kode langsung ing server nggunakake FTP/SFTP. Path iki cetha banget lan kita langsung mutusake kanggo nggunakake. Inti saka iku ing ngisor iki:

Ing polong lingkungan pangembangan (dev / review), wadhah tambahan diluncurake kanthi akses SSH lan nerusake kunci SSH umum pangembang sing bakal nindakake / nyebarake aplikasi kasebut.
Ing tataran init (ing wadhah prepare-app) transfer kode menyang emptyDirduwe akses menyang kode saka wadhah aplikasi lan server SSH.

Kanggo luwih ngerti implementasine technical saka rencana kuwi, aku bakal nyedhiyani pecahan saka konfigurasi YAML melu ing Kubernetes.

Konfigurasi

1.1. nilai.yaml

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

iku vasya.pupkin yaiku nilai variabel ${GITLAB_USER_LOGIN}.

1.2. penyebaran.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. rahasia.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 }}

tutul pungkasan

Sawise kabeh sing isih ana yaiku transfer variabel gitlab-ci.yml dibutuhake:

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: pangembang sing ngluncurake penyebaran bisa nyambung kanthi jeneng layanan (carane kanthi aman menehi akses menyang kluster, kita wis ngomong) saka desktop liwat SFTP lan ngowahi kode kasebut tanpa ngenteni dikirim menyang kluster.

Iki minangka solusi sing bisa digunakake, nanging saka sudut pandang implementasine, ana kekurangan sing jelas:

perlu kanggo nyaring grafik Helm, kang ndadekake angel diwaca ing mangsa;
mung bisa digunakake dening wong sing ngirim layanan;
sampeyan kudu ngelingi banjur nyinkronake karo direktori lokal karo kode lan tundhuk menyang Git.

2. Telepresence

Proyek kasebut telepresence wis dikenal kanggo wektu sing cukup suwe, nanging kita, kaya sing dikandhakake, "ora bisa nyoba kanthi serius ing praktik." Nanging, panjaluk wis rampung lan saiki kita seneng nuduhake pengalaman, sing bisa migunani kanggo para pamaca blog kita - utamane amarga durung ana bahan liyane babagan Telepresence ing hub.

Ing cendhak, kabeh dadi ora medeni. Kita nyelehake kabeh tumindak sing mbutuhake eksekusi ing bagean pangembang ing file teks grafik Helm sing diarani NOTES.txt. Dadi, sawise nggunakake layanan kasebut menyang Kubernetes, pangembang ndeleng instruksi kanggo ngluncurake lingkungan dev lokal ing log proyek 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
#########################################################################

Kita ora bakal manggon kanthi rinci babagan langkah-langkah sing diterangake ing pandhuan iki ... kajaba sing pungkasan. Apa sing kedadeyan sajrone peluncuran Telepresence?

Nggarap Telepresence

Ing wiwitan (nggunakake printah pungkasan sing ditemtokake ing pandhuan ing ndhuwur), kita nyetel:

namespace ing ngendi microservice lagi mlaku;
jeneng penyebaran lan wadhah sing arep kita tembus.

Argumentasi sing isih ana opsional. Yen layanan kita sesambungan karo lan kanggo API Kubernetes ServiceAccount digawe, kita kudu masang sertifikat/token ing desktop kita. Kanggo nindakake iki, gunakake pilihan kasebut --mount=true (utawa --mount=/dst_path), sing bakal masang root (/) saka wadhah Kubernetes menyang desktop kita. Sawise iki, kita bisa (gumantung saka OS lan carane aplikasi dibukak) nggunakake "tombol" saka kluster.

Pisanan, ayo goleki opsi paling universal kanggo mbukak aplikasi - ing wadhah Docker. Kanggo nindakake iki, kita bakal nggunakake tombol --docker-run lan pasang direktori kanthi kode menyang wadhah: -v `pwd`:/app

Elinga yen iki nganggep mlaku saka direktori proyek. Kode aplikasi bakal dipasang ing direktori /app ing wadhah.

Sabanjure: -v /tmp/app/var/run/secrets:/var/run/secrets - kanggo masang direktori karo sertifikat / token menyang wadhah.

Opsi iki pungkasane diterusake karo gambar ing ngendi aplikasi bakal mbukak. NB: Nalika mbangun gambar, sampeyan kudu nemtokake CMD utawa ENTRYPOINT!

Apa persis sing bakal kelakon sabanjure?

Ing Kubernetes, kanggo Deployment sing ditemtokake, jumlah replika bakal diganti dadi 0. Nanging, Deployment anyar bakal diluncurake - kanthi wadhah pengganti. backend.
2 kontainer bakal diluncurake ing desktop: sing pertama karo Telepresence (bakal njaluk proxy saka / menyang Kubernetes), sing nomer loro karo aplikasi sing dikembangake.
Yen kita eksekusi menyang wadhah kanthi aplikasi kasebut, kabeh variabel ENV sing ditransfer dening Helm sajrone panyebaran bakal kasedhiya kanggo kita, lan kabeh layanan uga kasedhiya. Kabeh sing isih ana yaiku ngowahi kode ing IDE favorit lan nikmati asile.
Ing pungkasan karya, sampeyan mung kudu nutup terminal sing Telepresence mlaku (mungkasi sesi karo Ctrl + C) - kontaner Docker bakal mandheg ing desktop, lan ing Kubernetes kabeh bakal bali menyang negara wiwitan. Kabeh sing isih ana yaiku tundhuk, ngetokake MR lan transfer menyang review / gabung / ... (gumantung saka alur kerja sampeyan).

Yen kita ora pengin mbukak aplikasi ing wadhah Docker - contone, kita ora berkembang ing PHP, nanging ing Go, lan isih nggawe lokal - ngluncurake Telepresence bakal luwih gampang:

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

Если приложение обращается к Kubernetes API, потребуется смонтировать директорию с ключами (https://www.telepresence.io/howto/volumes). Для Linux есть утилита oyod:

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

Sawise ngetokake Telepresence tanpa pilihan --docker-run kabeh variabel lingkungan bakal kasedhiya ing terminal saiki, supaya aplikasi kudu dibukak ing.

NB: Nalika nggunakake, contone, PHP, sampeyan kudu elinga mateni macem-macem op_cache, apc lan akselerator liyane kanggo pembangunan - yen nyunting kode ora bakal mimpin kanggo asil sing dipengini.

Hasil

Pangembangan lokal karo Kubernetes minangka masalah sing solusine saya tambah akeh ing proporsi panyebaran platform iki. Nampa panjalukan sing cocog saka pangembang (saka klien kita), kita wiwit ngrampungake kanthi cara sing kasedhiya, sing, nanging, ora mbuktekake awake dhewe sajrone jangka panjang. Begjanipun, iki wis dadi ketok ora mung saiki lan ora mung kanggo kita, supaya cara sing luwih cocok wis muncul ing donya, lan Telepresence iku sing paling misuwur (ing cara, ana uga skaffold saka Google). Pengalaman kita nggunakake durung apik banget, nanging wis menehi alesan kanggo menehi rekomendasi menyang "rekan-rekan ing toko" - coba!