ProHoster > blog > administrasi > Menghapus cabang fitur yang sudah ketinggalan zaman di cluster Kubernetes
Menghapus cabang fitur yang sudah ketinggalan zaman di cluster Kubernetes
Hi! Cabang fitur (alias menyebarkan pratinjau, meninjau aplikasi) - ini adalah saat tidak hanya cabang master disebarkan, tetapi juga setiap permintaan tarik ke URL unik. Anda dapat memeriksa apakah kode berfungsi di lingkungan produksi; fitur tersebut dapat ditampilkan kepada pemrogram lain atau spesialis produk. Saat Anda mengerjakan permintaan tarik, setiap penerapan penerapan baru saat ini untuk kode lama akan dihapus, dan penerapan baru untuk kode baru akan diluncurkan. Pertanyaan mungkin muncul ketika Anda menggabungkan permintaan tarik ke dalam cabang master. Anda tidak lagi memerlukan cabang fitur, namun sumber daya Kubernetes masih berada di cluster.
Lebih lanjut tentang cabang fitur
Salah satu pendekatan untuk membuat cabang fitur di Kubernetes adalah dengan menggunakan namespace. Singkatnya, konfigurasi produksinya terlihat seperti ini:
Untuk cabang fitur, namespace dibuat dengan pengidentifikasinya (misalnya, nomor permintaan penarikan) dan beberapa jenis awalan/postfix (misalnya, -pr-):
Secara umum, saya menulis Operator Kubernetes (aplikasi yang memiliki akses ke sumber daya cluster), tautan ke proyek di Github. Ini menghapus namespace milik cabang fitur lama. Di Kubernetes, jika Anda menghapus namespace, sumber daya lain di namespace tersebut juga akan terhapus secara otomatis.
$ kubectl get pods --all-namespaces | grep -e "-pr-"
NAMESPACE ... AGE
habr-back-end-pr-264 ... 4d8h
habr-back-end-pr-265 ... 5d7h
Anda dapat membaca tentang cara mengimplementasikan cabang fitur ke dalam sebuah cluster di sini ΠΈ di sini.
Motivasi
Mari kita lihat siklus hidup permintaan tarik dengan integrasi berkelanjutan (continuous integration):
Kami mendorong komitmen baru ke cabang.
Pada build, linter dan/atau pengujian dijalankan.
Konfigurasi permintaan tarik Kubernetes dibuat dengan cepat (misalnya, nomornya dimasukkan ke dalam templat yang sudah jadi).
Menggunakan kubectl apply, konfigurasi ditambahkan ke cluster (deploy).
Permintaan tarik digabungkan ke dalam cabang master.
Saat Anda mengerjakan permintaan tarik, setiap penerapan penerapan baru saat ini untuk kode lama akan dihapus, dan penerapan baru untuk kode baru akan diluncurkan. Namun ketika permintaan tarik digabungkan ke dalam cabang master, hanya cabang master yang akan dibangun. Akibatnya, ternyata kita sudah melupakan pull request tersebut, dan resource Kubernetes-nya masih ada di cluster.
Parameter namespaceSubstring diperlukan untuk memfilter namespace untuk permintaan tarik dari namespace lain. Misalnya, jika klaster memiliki namespace berikut: habr-back-end, habr-front-end, habr-back-end-pr-17, habr-back-end-pr-33, maka calon yang akan dihapus adalah habr-back-end-pr-17, habr-back-end-pr-33.
Parameter afterDaysWithoutDeploy diperlukan untuk menghapus namespace lama. Misalnya, jika namespace dibuat 3 Π΄Π½Ρ 1 ΡΠ°Ρ kembali, dan parameter menunjukkan 3 Π΄Π½Ρ, namespace ini akan dihapus. Ini juga bekerja dalam arah yang berlawanan jika namespace dibuat 2 Π΄Π½Ρ 23 ΡΠ°ΡΠ° kembali, dan parameter menunjukkan 3 Π΄Π½Ρ, namespace ini tidak akan dihapus.
Ada satu parameter lagi, yang bertanggung jawab atas seberapa sering memindai semua namespace dan memeriksa hari-hari tanpa penerapan - periksaSetiapMenit. Secara default itu sama 30 ΠΌΠΈΠ½ΡΡΠ°ΠΌ.
Bagaimana itu bekerja
Dalam praktiknya, Anda memerlukan:
Buruh pelabuhan untuk bekerja di lingkungan yang terisolasi.
Minikube akan meningkatkan cluster Kubernetes secara lokal.
kubectl β antarmuka baris perintah untuk manajemen cluster.
Kami mengembangkan cluster Kubernetes secara lokal:
$ minikube start --vm-driver=docker
minikube v1.11.0 on Darwin 10.15.5
Using the docker driver based on existing profile.
Starting control plane node minikube in cluster minikube.
Kami menunjukkan kubectl gunakan cluster lokal secara default:
$ kubectl config use-context minikube
Switched to context "minikube".
Karena konfigurasi produksi dikonfigurasi untuk memeriksa namespace lama, dan cluster kami yang baru dibuat tidak memilikinya, kami akan mengganti variabel lingkungan IS_DEBUG pada true. Dengan nilai ini parameternya afterDaysWithoutDeploy tidak diperhitungkan dan namespace tidak diperiksa selama berhari-hari tanpa penerapan, hanya untuk kemunculan substring (-pr-).
Jika Anda aktif Linux:
$ sed -i 's|false|true|g' stale-feature-branch-production-configs.yml
Jika Anda aktif macOS:
$ sed -i "" 's|false|true|g' stale-feature-branch-production-configs.yml
Kami memeriksa apakah operator telah muncul di cluster:
$ kubectl get pods --namespace stale-feature-branch-operator
NAME ... STATUS ... AGE
stale-feature-branch-operator-6bfbfd4df8-m7sch ... Running ... 38s
Jika Anda melihat lognya, ia siap memproses sumber daya StaleFeatureBranch:
Operator telah merespons dan siap memeriksa namespace:
$ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator
... "msg":"Stale feature branch is being processing.","namespaceSubstring":"-pr-","afterDaysWithoutDeploy":1,"checkEveryMinutes":1,"isDebug":"true"}
Mengatur fixtures, berisi dua namespace (project-pr-1, project-pr-2) dan mereka deployments, services, ingress, dan seterusnya:
$ kubectl apply -f https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/fixtures/first-feature-branch.yml -f https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/fixtures/second-feature-branch.yml
...
namespace/project-pr-1 created
deployment.apps/project-pr-1 created
service/project-pr-1 created
horizontalpodautoscaler.autoscaling/project-pr-1 created
secret/project-pr-1 created
configmap/project-pr-1 created
ingress.extensions/project-pr-1 created
namespace/project-pr-2 created
deployment.apps/project-pr-2 created
service/project-pr-2 created
horizontalpodautoscaler.autoscaling/project-pr-2 created
secret/project-pr-2 created
configmap/project-pr-2 created
ingress.extensions/project-pr-2 created
Kami memeriksa apakah semua sumber daya di atas telah berhasil dibuat:
$ kubectl get namespace,pods,deployment,service,horizontalpodautoscaler,configmap,ingress -n project-pr-1 && kubectl get namespace,pods,deployment,service,horizontalpodautoscaler,configmap,ingress -n project-pr-2
...
NAME ... READY ... STATUS ... AGE
pod/project-pr-1-848d5fdff6-rpmzw ... 1/1 ... Running ... 67s
NAME ... READY ... AVAILABLE ... AGE
deployment.apps/project-pr-1 ... 1/1 ... 1 ... 67s
...
Sejak kami menyertakannya debug, ruang nama project-pr-1 ΠΈ project-pr-2, oleh karena itu semua sumber daya lainnya harus segera dihapus tanpa memperhitungkan parameternya afterDaysWithoutDeploy. Ini dapat dilihat di log operator:
$ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator
... "msg":"Namespace should be deleted due to debug mode is enabled.","namespaceName":"project-pr-1"}
... "msg":"Namespace is being processing.","namespaceName":"project-pr-1","namespaceCreationTimestamp":"2020-06-16 18:43:58 +0300 EEST"}
... "msg":"Namespace has been deleted.","namespaceName":"project-pr-1"}
... "msg":"Namespace should be deleted due to debug mode is enabled.","namespaceName":"project-pr-2"}
... "msg":"Namespace is being processing.","namespaceName":"project-pr-2","namespaceCreationTimestamp":"2020-06-16 18:43:58 +0300 EEST"}
... "msg":"Namespace has been deleted.","namespaceName":"project-pr-2"}
Jika Anda memeriksa ketersediaan sumber daya, mereka akan berada dalam status Terminating (proses penghapusan) atau sudah dihapus (output perintah kosong).
$ kubectl get namespace,pods,deployment,service,horizontalpodautoscaler,configmap,ingress -n project-pr-1 && kubectl get namespace,pods,deployment,service,horizontalpodautoscaler,configmap,ingress -n project-pr-2
...
Anda dapat mengulangi proses pembuatannya fixtures beberapa kali dan pastikan semuanya dihapus dalam satu menit.
Alternatif
Apa yang bisa dilakukan selain operator yang bekerja di cluster? Ada beberapa pendekatan, semuanya tidak sempurna (dan kekurangannya bersifat subjektif), dan setiap orang memutuskan sendiri apa yang terbaik untuk proyek tertentu:
Hapus cabang fitur selama pembangunan integrasi berkelanjutan dari cabang master.
Untuk melakukan ini, Anda perlu mengetahui pull request mana yang terkait dengan commit yang sedang dibangun. Karena namespace cabang fitur berisi pengidentifikasi permintaan tarik - nomornya, atau nama cabang, pengidentifikasi harus selalu ditentukan dalam penerapan.
Pembangunan cabang master gagal. Misalnya, Anda memiliki tahapan berikut: mengunduh proyek, menjalankan pengujian, membangun proyek, membuat rilis, mengirim pemberitahuan, menghapus cabang fitur dari permintaan penarikan terakhir. Jika build gagal saat mengirim notifikasi, Anda harus menghapus semua sumber daya di cluster secara manual.
Tanpa konteks yang tepat, penghapusan cabang fitur di build master tidak akan terlihat jelas.
Ini mungkin bukan pendekatan Anda. Misalnya, di Jenkins, hanya satu jenis saluran yang mendukung kemampuan untuk menyimpan konfigurasinya dalam kode sumber. Saat menggunakan webhook, Anda perlu menulis skrip Anda sendiri untuk memprosesnya. Skrip ini harus ditempatkan di antarmuka Jenkins, yang sulit dipelihara.
Untuk menulis pekerjaan cron dan menambahkan cluster Kubernetes.
Menghabiskan waktu untuk menulis dan memberikan dukungan.
Operator sudah bekerja dengan gaya serupa, didokumentasikan dan didukung.