Tip & trik Kubernetes: tentang pengembangan lokal dan Telepresence

Kami semakin banyak ditanya tentang pengembangan layanan mikro di Kubernetes. Pengembang, terutama bahasa interpretasi, ingin segera memperbaiki kode di IDE favorit mereka dan melihat hasilnya tanpa menunggu build/deployment - hanya dengan menekan F5. Dan jika menyangkut aplikasi monolitik, cukup menginstal database dan server web secara lokal (di Docker, VirtualBox...), dan kemudian segera menikmati pengembangan. Dengan pemotongan monolit menjadi layanan mikro dan kedatangan Kubernetes, dengan munculnya ketergantungan satu sama lain, semuanya itu menjadi sedikit lebih sulit. Semakin banyak layanan mikro ini, semakin banyak masalah. Untuk menikmati pengembangan lagi, Anda perlu meningkatkan lebih dari satu atau dua container Docker, dan terkadang bahkan lebih dari selusin... Secara umum, semua ini bisa memakan banyak waktu, karena juga perlu selalu diperbarui .

Pada waktu yang berbeda kami mencoba solusi berbeda untuk masalah tersebut. Dan saya akan mulai dengan akumulasi solusi atau sekadar "kruk".

1. Kruk

Kebanyakan IDE memiliki kemampuan untuk mengedit kode langsung di server menggunakan FTP/SFTP. Jalur ini sangat jelas dan kami segera memutuskan untuk menggunakannya. Esensinya adalah sebagai berikut:

1. Di pod lingkungan pengembangan (dev/review), kontainer tambahan diluncurkan dengan akses SSH dan meneruskan kunci SSH publik dari pengembang yang akan melakukan/menyebarkan aplikasi.
2. Pada tahap init (di dalam container prepare-app) transfer kode ke emptyDiruntuk memiliki akses ke kode dari wadah aplikasi dan server SSH.

Untuk lebih memahami implementasi teknis skema semacam itu, saya akan memberikan cuplikan konfigurasi YAML yang terlibat di Kubernetes.

Konfigurasi

1.1. nilai.yaml

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

Di sini vasya.pupkin adalah nilai variabelnya ${GITLAB_USER_LOGIN}.

1.2. penerapan.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 }}

Sentuhan terakhir

Setelah itu yang tersisa hanyalah transfer variabel gitlab-ci.yml yang 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: pengembang yang meluncurkan penerapan dapat terhubung berdasarkan nama layanan (cara memberikan akses ke cluster dengan aman, kami sudah memberi tahu) dari desktop Anda melalui SFTP dan edit kode tanpa menunggu kode dikirimkan ke cluster.

Ini adalah solusi yang sepenuhnya berfungsi, tetapi dari sudut pandang implementasi, solusi ini memiliki kelemahan yang jelas:

• perlunya menyempurnakan bagan Helm, sehingga sulit dibaca di masa mendatang;
• hanya dapat digunakan oleh orang yang menyebarkan layanan;
• Anda harus ingat untuk kemudian menyinkronkannya dengan direktori lokal dengan kode tersebut dan mengkomitnya ke Git.

2. Telepresensi

Proyek telepresence sudah dikenal cukup lama, tapi kami, seperti kata mereka, “belum sempat mencobanya secara serius dalam praktik.” Namun, permintaan telah melakukan tugasnya dan sekarang kami dengan senang hati berbagi pengalaman kami, yang mungkin berguna bagi pembaca blog kami - terutama karena belum ada materi lain tentang Telepresence di hub.

Singkatnya, semuanya ternyata tidak begitu menakutkan. Kami menempatkan semua tindakan yang memerlukan eksekusi oleh pengembang dalam file teks bagan Helm bernama NOTES.txt. Jadi, setelah menerapkan layanan ke Kubernetes, pengembang melihat instruksi untuk meluncurkan lingkungan pengembang lokal di log pekerjaan 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 membahas secara rinci langkah-langkah yang dijelaskan dalam instruksi ini... kecuali yang terakhir. Apa yang terjadi saat peluncuran Telepresence?

Bekerja dengan Telepresence

Saat startup (menggunakan perintah terakhir yang ditentukan dalam instruksi di atas), kami menetapkan:

• namespace tempat layanan mikro berjalan;
• nama penerapan dan wadah yang ingin kita tembus.

Argumen lainnya bersifat opsional. Jika layanan kami berinteraksi dengan dan untuk API Kubernetes Akun Layanan dibuat, kita perlu memasang sertifikat/token di desktop kita. Untuk melakukan ini, gunakan opsi --mount=true (Atau --mount=/dst_path), yang akan memasang root (/) dari container Kubernetes ke desktop kita. Setelah ini, kita dapat (tergantung pada OS dan bagaimana aplikasi diluncurkan) menggunakan “kunci” dari cluster.

Pertama, mari kita lihat opsi paling universal untuk menjalankan aplikasi - dalam wadah Docker. Untuk melakukan ini kita akan menggunakan kuncinya --docker-run dan pasang direktori dengan kode ke dalam wadah: -v `pwd`:/app

Harap dicatat bahwa ini mengasumsikan dijalankan dari direktori proyek. Kode aplikasi akan dipasang di direktori /app dalam sebuah wadah.

Selanjutnya: -v /tmp/app/var/run/secrets:/var/run/secrets — untuk memasang direktori dengan sertifikat/token ke dalam wadah.

Pilihan ini terakhir diikuti dengan gambar dimana aplikasi akan dijalankan. NB: Saat membuat gambar, Anda harus menentukan CMD или ENTRYPOINT!

Apa sebenarnya yang akan terjadi selanjutnya?

• Di Kubernetes, untuk Deployment yang ditentukan, jumlah replika akan diubah menjadi 0. Sebagai gantinya, Deployment baru akan diluncurkan - dengan container pengganti backend.
• 2 container akan diluncurkan di desktop: yang pertama dengan Telepresence (ini akan mem-proxy permintaan dari/ke Kubernetes), yang kedua dengan aplikasi yang sedang dikembangkan.
• Jika kita mengeksekusinya ke dalam container dengan aplikasi tersebut, maka semua variabel ENV yang ditransfer oleh Helm selama penerapan akan tersedia untuk kita, dan semua layanan juga akan tersedia. Yang tersisa hanyalah mengedit kode di IDE favorit Anda dan menikmati hasilnya.
• Di akhir pekerjaan, Anda hanya perlu menutup terminal tempat Telepresence berjalan (akhiri sesi dengan Ctrl+C) - container Docker akan berhenti di desktop, dan di Kubernetes semuanya akan kembali ke keadaan semula. Yang tersisa hanyalah berkomitmen, menerbitkan MR dan mentransfernya ke tinjauan/penggabungan/… (tergantung pada alur kerja Anda).

Jika kita tidak ingin menjalankan aplikasi dalam container Docker - misalnya, kita tidak mengembangkannya di PHP, tetapi di Go, dan masih membangunnya secara lokal - meluncurkan Telepresence akan lebih mudah:

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

Jika aplikasi mengakses API Kubernetes, Anda perlu memasang direktori kunci (https://www.telepresence.io/howto/volumes). Ada utilitas untuk Linux akar:

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

Setelah meluncurkan Telepresence tanpa opsi --docker-run semua variabel lingkungan akan tersedia di terminal saat ini, sehingga aplikasi harus diluncurkan di dalamnya.

NB: Saat menggunakan, misalnya, PHP, Anda harus ingat untuk menonaktifkan berbagai op_cache, apc, dan akselerator lainnya untuk pengembangan - jika tidak, mengedit kode tidak akan memberikan hasil yang diinginkan.

Hasil

Pembangunan lokal dengan Kubernetes merupakan masalah yang solusinya semakin berkembang seiring dengan penyebaran platform ini. Menerima permintaan yang relevan dari pengembang (dari klien kami), kami mulai menyelesaikannya dengan cara pertama yang tersedia, namun tidak terbukti dalam jangka panjang. Untungnya, hal ini menjadi jelas tidak hanya sekarang dan tidak hanya bagi kita, jadi cara yang lebih cocok telah muncul di dunia, dan Telepresence adalah yang paling terkenal (omong-omong, ada juga perancah dari Google). Pengalaman kami dalam menggunakannya belum begitu bagus, tetapi ini sudah memberi kami alasan untuk merekomendasikannya kepada “rekan di toko” kami - cobalah!

PS

Lainnya dari seri tips & trik K8s:

• «Kiat & trik Kubernetes: halaman kesalahan khusus di NGINX Ingress»;
• «Mentransfer sumber daya yang berjalan di cluster ke manajemen Helm 2»;
• «Tentang alokasi dan pemuatan node pada aplikasi web»;
• «Akses ke situs pengembang»;
• «Mempercepat bootstrap untuk database besar'.

Sumber: www.habr.com