Petua & kiat Kubernetes: tentang pembangunan tempatan dan Telepresence

Kami semakin ditanya tentang membangunkan perkhidmatan mikro dalam Kubernetes. Pembangun, terutamanya bahasa yang ditafsirkan, ingin membetulkan kod dalam IDE kegemaran mereka dengan cepat dan melihat hasilnya tanpa menunggu binaan/pengerahan - dengan hanya menekan F5. Dan apabila ia datang kepada aplikasi monolitik, ia sudah cukup untuk memasang pangkalan data dan pelayan web secara tempatan (dalam Docker, VirtualBox...), dan kemudian segera menikmati pembangunan. Dengan pemotongan monolit ke dalam perkhidmatan mikro dan ketibaan Kubernetes, dengan kemunculan kebergantungan antara satu sama lain, semuanya ia menjadi lebih sukar. Lebih banyak perkhidmatan mikro ini, lebih banyak masalah. Untuk menikmati pembangunan semula, anda perlu menaikkan lebih daripada satu atau dua bekas Docker, dan kadangkala lebih daripada sedozen... Secara umumnya, semua ini boleh mengambil masa yang agak lama, kerana ia juga perlu dikemas kini. .

Pada masa yang berbeza kami mencuba penyelesaian yang berbeza untuk masalah itu. Dan saya akan mulakan dengan penyelesaian terkumpul atau hanya "tongkat".

1. Tongkat

Kebanyakan IDE mempunyai keupayaan untuk mengedit kod terus pada pelayan menggunakan FTP/SFTP. Laluan ini sangat jelas dan kami segera memutuskan untuk menggunakannya. Intipatinya bermuara kepada perkara berikut:

1. Dalam pod persekitaran pembangunan (dev/review), bekas tambahan dilancarkan dengan akses SSH dan memajukan kunci SSH awam pembangun yang akan melaksanakan/menggunakan aplikasi.
2. Pada peringkat init (dalam bekas prepare-app) pindahkan kod ke emptyDiruntuk mempunyai akses kepada kod daripada bekas aplikasi dan pelayan SSH.

Untuk lebih memahami pelaksanaan teknikal skim sedemikian, saya akan menyediakan serpihan konfigurasi YAML yang terlibat dalam Kubernetes.

Konfigurasi

1.1. nilai.yaml

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

ia adalah vasya.pupkin ialah nilai pembolehubah ${GITLAB_USER_LOGIN}.

1.2. penempatan.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. rahsia.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 }}

Sentuhan akhir

Selepas itu yang tinggal hanyalah pemindahan pembolehubah gitlab-ci.yml diperlukan:

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: pembangun yang melancarkan penggunaan boleh menyambung dengan nama perkhidmatan (cara memberikan akses kepada kluster dengan selamat, kami sudah beritahu) dari desktop anda melalui SFTP dan edit kod tanpa menunggu ia dihantar ke kluster.

Ini adalah penyelesaian yang berfungsi sepenuhnya, tetapi dari sudut pelaksanaan ia mempunyai kelemahan yang jelas:

• keperluan untuk memperhalusi carta Helm, yang menjadikannya sukar untuk dibaca pada masa hadapan;
• hanya boleh digunakan oleh orang yang menggunakan perkhidmatan;
• anda perlu ingat untuk kemudian menyegerakkannya dengan direktori tempatan dengan kod dan menyerahkannya kepada Git.

2. Telepresence

Projek telepresence telah diketahui sejak sekian lama, tetapi kami, seperti yang mereka katakan, "tidak dapat mencubanya secara serius dalam amalan." Walau bagaimanapun, permintaan telah melaksanakan tugasnya dan kini kami gembira untuk berkongsi pengalaman kami, yang mungkin berguna kepada pembaca blog kami - terutamanya kerana belum ada bahan lain tentang Telepresence di hab itu.

Pendek kata, semuanya ternyata tidak begitu menakutkan. Kami meletakkan semua tindakan yang memerlukan pelaksanaan di pihak pembangun dalam fail teks carta Helm yang dipanggil NOTES.txt. Oleh itu, selepas menggunakan perkhidmatan kepada Kubernetes, pembangun melihat arahan untuk melancarkan persekitaran pembangun setempat dalam log kerja 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
#########################################################################

Kami tidak akan membincangkan secara terperinci tentang langkah-langkah yang diterangkan dalam arahan ini... kecuali yang terakhir. Apakah yang berlaku semasa pelancaran Telepresence?

Bekerja dengan Telepresence

Pada permulaan (menggunakan arahan terakhir yang dinyatakan dalam arahan di atas), kami menetapkan:

• ruang nama di mana perkhidmatan mikro berjalan;
• nama penempatan dan bekas yang ingin kami tembusi.

Hujah yang selebihnya adalah pilihan. Jika perkhidmatan kami berinteraksi dengan dan untuk API Kubernetes ServiceAccount dibuat, kami perlu memasang sijil/token pada desktop kami. Untuk melakukan ini, gunakan pilihan --mount=true (Atau --mount=/dst_path), yang akan melekapkan akar (/) daripada bekas Kubernetes ke desktop kami. Selepas ini, kita boleh (bergantung pada OS dan cara aplikasi dilancarkan) menggunakan "kunci" daripada kluster.

Mula-mula, mari kita lihat pilihan paling universal untuk menjalankan aplikasi - dalam bekas Docker. Untuk melakukan ini, kami akan menggunakan kunci --docker-run dan lekapkan direktori dengan kod ke dalam bekas: -v `pwd`:/app

Sila ambil perhatian bahawa ini menganggap berjalan dari direktori projek. Kod aplikasi akan dipasang dalam direktori /app dalam bekas.

Next: -v /tmp/app/var/run/secrets:/var/run/secrets — untuk melekapkan direktori dengan sijil/token ke dalam bekas.

Pilihan ini akhirnya diikuti oleh imej di mana aplikasi akan dijalankan. NB: Apabila membina imej, anda mesti menentukan CMD atau ENTRYPOINT!

Apa sebenarnya yang akan berlaku seterusnya?

• Dalam Kubernetes, untuk Deployment yang ditentukan, bilangan replika akan ditukar kepada 0. Sebaliknya, Deployment baharu akan dilancarkan - dengan bekas pengganti backend.
• 2 bekas akan dilancarkan pada desktop: yang pertama dengan Telepresence (ia akan meminta proksi daripada/ke Kubernetes), yang kedua dengan aplikasi sedang dibangunkan.
• Jika kami melaksanakan ke dalam bekas dengan aplikasi, maka semua pembolehubah ENV yang dipindahkan oleh Helm semasa penggunaan akan tersedia kepada kami, dan semua perkhidmatan juga akan tersedia. Yang tinggal hanyalah mengedit kod dalam IDE kegemaran anda dan nikmati hasilnya.
• Pada penghujung kerja, anda hanya perlu menutup terminal di mana Telepresence sedang berjalan (menamatkan sesi dengan Ctrl+C) - Bekas Docker akan berhenti pada desktop, dan dalam Kubernetes semuanya akan kembali kepada keadaan asalnya. Apa yang tinggal adalah untuk membuat komitmen, mengeluarkan MR dan memindahkannya ke semakan/gabungan/… (bergantung pada aliran kerja anda).

Jika kami tidak mahu menjalankan aplikasi dalam bekas Docker - contohnya, kami tidak membangunkan dalam PHP, tetapi dalam Go, dan masih membinanya secara tempatan - melancarkan Telepresence akan menjadi lebih mudah:

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

Jika aplikasi mengakses API Kubernetes, anda perlu melekapkan direktori kunci (https://www.telepresence.io/howto/volumes). Terdapat utiliti untuk Linux akar:

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

Selepas melancarkan Telepresence tanpa pilihan --docker-run semua pembolehubah persekitaran akan tersedia dalam terminal semasa, jadi aplikasi mesti dilancarkan di dalamnya.

NB: Apabila menggunakan, sebagai contoh, PHP, anda mesti ingat untuk melumpuhkan pelbagai op_cache, apc dan pemecut lain untuk pembangunan - jika tidak, mengedit kod tidak akan membawa kepada hasil yang diingini.

Keputusan

Pembangunan tempatan dengan Kubernetes ialah masalah yang penyelesaiannya berkembang mengikut kadar penyebaran platform ini. Menerima permintaan yang berkaitan daripada pembangun (daripada pelanggan kami), kami mula menyelesaikannya dengan cara pertama yang tersedia, yang bagaimanapun, tidak membuktikan diri mereka dalam jangka masa panjang. Nasib baik, ini telah menjadi jelas bukan sahaja sekarang dan bukan sahaja kepada kita, jadi cara yang lebih sesuai telah muncul di dunia, dan Telepresence adalah yang paling terkenal daripada mereka (dengan cara ini, terdapat juga skaffold daripada Google). Pengalaman kami menggunakannya belum begitu hebat, tetapi ia sudah memberi kami alasan untuk mengesyorkannya kepada "rakan sekerja di kedai" kami - cubalah!

PS

Lain daripada siri petua & helah K8s:

• «Petua & kiat Kubernetes: halaman ralat tersuai dalam NGINX Ingress»;
• «Memindahkan sumber yang berjalan dalam kelompok kepada pengurusan Helm 2»;
• «Mengenai peruntukan dan beban nod pada aplikasi web»;
• «Akses kepada tapak pembangun»;
• «Mempercepatkan bootstrap untuk pangkalan data yang besar'.

Sumber: www.habr.com