🥇Mengalih keluar cawangan ciri lapuk dalam gugusan Kubernetes

Hello! Cawangan ciri (aka deploy preview, review app) - masa ini bukan sahaja cawangan induk digunakan, tetapi juga setiap permintaan tarik ke URL unik. Anda boleh menyemak sama ada kod berfungsi dalam persekitaran pengeluaran; ciri ini boleh ditunjukkan kepada pengaturcara atau pakar produk lain. Semasa anda bekerja dalam permintaan tarik, setiap penggunaan semasa komit baharu untuk kod lama akan dipadamkan dan penggunaan baharu untuk kod baharu dilancarkan. Soalan mungkin timbul apabila anda menggabungkan permintaan tarik ke dalam cawangan induk. Anda tidak lagi memerlukan cawangan ciri, tetapi sumber Kubernetes masih berada dalam kelompok.

Lebih lanjut mengenai cawangan ciri

Satu pendekatan untuk membuat cawangan ciri dalam Kubernetes ialah menggunakan ruang nama. Ringkasnya, konfigurasi pengeluaran kelihatan seperti ini:

kind: Namespace
apiVersion: v1
metadata:
  name: habr-back-end
...

kind: Deployment
apiVersion: apps/v1
metadata:
  namespace: habr-back-end
spec:
  replicas: 3
...

Untuk cawangan ciri, ruang nama dicipta dengan pengecamnya (contohnya, nombor permintaan tarik) dan beberapa jenis awalan/paspasan (contohnya, -pr-):

kind: Namespace
apiVersion: v1
metadata:
  name: habr-back-end-pr-17
...

kind: Deployment
apiVersion: apps/v1
metadata:
  namespace: habr-back-end-pr-17
spec:
  replicas: 1
...

Secara umum, saya menulis Operator Kubernetes (aplikasi yang mempunyai akses kepada sumber kluster), pautan ke projek di Github. Ia mengalih keluar ruang nama yang dimiliki oleh cawangan ciri lama. Dalam Kubernetes, jika anda memadamkan ruang nama, sumber lain dalam ruang nama itu juga dipadamkan secara automatik.

$ kubectl get pods --all-namespaces | grep -e "-pr-"
NAMESPACE            ... AGE
habr-back-end-pr-264 ... 4d8h
habr-back-end-pr-265 ... 5d7h

Anda boleh membaca tentang cara melaksanakan cawangan ciri ke dalam kelompok di sini и di sini.

Motivasi

Mari lihat kitaran hayat permintaan tarik biasa dengan penyepaduan berterusan (continuous integration):

Kami menolak komitmen baharu kepada cawangan.
Pada binaan, linter dan/atau ujian dijalankan.
Konfigurasi permintaan tarik Kubernetes dijana dengan cepat (contohnya, nombornya dimasukkan ke dalam templat siap).
Menggunakan kubectl apply, konfigurasi ditambahkan pada cluster (deploy).
Permintaan tarik digabungkan ke dalam cawangan induk.

Semasa anda bekerja dalam permintaan tarik, setiap penggunaan semasa komit baharu untuk kod lama akan dipadamkan dan penggunaan baharu untuk kod baharu dilancarkan. Tetapi apabila permintaan tarik digabungkan ke dalam cawangan induk, hanya cawangan induk akan dibina. Akibatnya, ternyata kami sudah terlupa tentang permintaan tarik dan sumber Kubernetesnya masih dalam kelompok.

Cara menggunakannya

Pasang projek dengan arahan di bawah:

$ kubectl apply -f https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/configs/production.yml

Cipta fail dengan kandungan berikut dan pasang melalui kubectl apply -f:

apiVersion: feature-branch.dmytrostriletskyi.com/v1
kind: StaleFeatureBranch
metadata:
  name: stale-feature-branch
spec:
  namespaceSubstring: -pr-
  afterDaysWithoutDeploy: 3

Parameter ruang namaSubrentetan diperlukan untuk menapis ruang nama untuk permintaan tarik daripada ruang nama lain. Sebagai contoh, jika kluster mempunyai ruang nama berikut: habr-back-end, habr-front-end, habr-back-end-pr-17, habr-back-end-pr-33, maka calon untuk pemadaman adalah habr-back-end-pr-17, habr-back-end-pr-33.

Parameter afterDaysWithoutDeploy diperlukan untuk memadam ruang nama lama. Sebagai contoh, jika ruang nama dicipta 3 дня 1 час belakang, dan parameter menunjukkan 3 дня, ruang nama ini akan dipadamkan. Ia juga berfungsi dalam arah yang bertentangan jika ruang nama dibuat 2 дня 23 часа belakang, dan parameter menunjukkan 3 дня, ruang nama ini tidak akan dipadamkan.

Terdapat satu lagi parameter, ia bertanggungjawab untuk kekerapan mengimbas semua ruang nama dan menyemak untuk hari tanpa penggunaan - semakEveryMinutes. Secara lalai ia adalah sama 30 минутам.

Как это работает

Dalam amalan, anda memerlukan:

buruh pelabuhan untuk bekerja dalam persekitaran terpencil.
Minikube akan meningkatkan kluster Kubernetes secara tempatan.
kubectl — antara muka baris arahan untuk pengurusan kluster.

Kami meningkatkan kluster Kubernetes secara tempatan:

$ 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 kluster tempatan secara lalai:

$ kubectl config use-context minikube
Switched to context "minikube".

Muat turun konfigurasi untuk persekitaran pengeluaran:

$ curl https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/configs/production.yml > stale-feature-branch-production-configs.yml

Memandangkan konfigurasi pengeluaran dikonfigurasikan untuk menyemak ruang nama lama, dan kluster kami yang baru dibangkitkan tidak mempunyainya, kami akan menggantikan pembolehubah persekitaran IS_DEBUG pada true. Dengan nilai ini parameter afterDaysWithoutDeploy tidak diambil kira dan ruang nama tidak disemak selama beberapa hari tanpa menggunakan, hanya untuk kejadian subrentetan (-pr-).

Jika anda berada di Linux:

$ sed -i 's|false|true|g' stale-feature-branch-production-configs.yml

Jika anda berada di macOS:

$ sed -i "" 's|false|true|g' stale-feature-branch-production-configs.yml

Memasang projek:

$ kubectl apply -f stale-feature-branch-production-configs.yml

Menyemak bahawa sumber telah muncul dalam kelompok StaleFeatureBranch:

$ kubectl api-resources | grep stalefeaturebranches
NAME                 ... APIGROUP                             ... KIND
stalefeaturebranches ... feature-branch.dmytrostriletskyi.com ... StaleFeatureBranch

Kami menyemak sama ada pengendali telah muncul dalam kelompok:

$ kubectl get pods --namespace stale-feature-branch-operator
NAME                                           ... STATUS  ... AGE
stale-feature-branch-operator-6bfbfd4df8-m7sch ... Running ... 38s

Jika anda melihat lognya, ia sedia untuk memproses sumber StaleFeatureBranch:

$ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator
... "msg":"Operator Version: 0.0.1"}
...
... "msg":"Starting EventSource", ... , "source":"kind source: /, Kind="}
... "msg":"Starting Controller", ...}
... "msg":"Starting workers", ..., "worker count":1}

Kami memasang siap sedia fixtures (konfigurasi sedia untuk memodelkan sumber kluster) untuk sumber StaleFeatureBranch:

$ kubectl apply -f https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/fixtures/stale-feature-branch.yml

Konfigurasi menunjukkan untuk mencari ruang nama dengan subrentetan -pr- sekali masuk 1 минуту.:

apiVersion: feature-branch.dmytrostriletskyi.com/v1
kind: StaleFeatureBranch
metadata:
  name: stale-feature-branch
spec:
  namespaceSubstring: -pr-
  afterDaysWithoutDeploy: 1 
  checkEveryMinutes: 1

Operator telah bertindak balas dan bersedia untuk menyemak ruang nama:

$ 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"}

Tetapkan fixtures, mengandungi dua ruang nama (project-pr-1, project-pr-2) dan mereka deployments, services, ingress, dan sebagainya:

$ 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 menyemak bahawa semua sumber di atas telah berjaya 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 termasuk debug, ruang nama project-pr-1 и project-pr-2, oleh itu semua sumber lain perlu dipadamkan serta-merta tanpa mengambil kira parameter afterDaysWithoutDeploy. Ini boleh dilihat dalam 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 menyemak ketersediaan sumber, ia akan berada dalam status Terminating (proses pemadaman) atau sudah dipadam (output arahan 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 boleh mengulangi proses penciptaan fixtures beberapa kali dan pastikan ia dikeluarkan dalam masa seminit.

Alternatif

Apakah yang boleh dilakukan dan bukannya pengendali yang bekerja dalam kelompok? Terdapat beberapa pendekatan, semuanya tidak sempurna (dan kekurangannya adalah subjektif), dan setiap orang memutuskan sendiri apa yang terbaik untuk projek tertentu:

Padamkan cawangan ciri semasa binaan penyepaduan berterusan cawangan induk.
- Untuk melakukan ini, anda perlu mengetahui permintaan tarik yang berkaitan dengan komit yang sedang dibina. Memandangkan ruang nama cawangan ciri mengandungi pengecam permintaan tarik - nombornya, atau nama cawangan, pengecam perlu sentiasa dinyatakan dalam komit.
- Pembinaan cawangan induk gagal. Sebagai contoh, anda mempunyai peringkat berikut: muat turun projek, jalankan ujian, bina projek, buat keluaran, hantar pemberitahuan, kosongkan cawangan ciri permintaan tarik terakhir. Jika binaan gagal semasa menghantar pemberitahuan, anda perlu memadamkan semua sumber dalam kluster secara manual.
- Tanpa konteks yang betul, memadamkan cawangan ciri dalam binaan induk adalah tidak jelas.
Menggunakan webhooks (contoh).
- Ini mungkin bukan pendekatan anda. Sebagai contoh, dalam Jenkins, hanya satu jenis saluran paip menyokong keupayaan untuk menyimpan konfigurasinya dalam kod sumber. Apabila menggunakan webhooks, anda perlu menulis skrip anda sendiri untuk memprosesnya. Skrip ini perlu diletakkan dalam antara muka Jenkins, yang sukar untuk dikekalkan.
Untuk menulis Cronjob dan tambahkan gugusan Kubernetes.
- Menghabiskan masa untuk menulis dan menyokong.
- Pengendali sudah berfungsi dalam gaya yang sama, didokumenkan dan disokong.

Terima kasih atas perhatian anda terhadap artikel tersebut. Pautan ke projek di Github.

Sumber: www.habr.com

Mengalih keluar cawangan ciri yang sudah lapuk dalam gugusan Kubernetes

Lebih lanjut mengenai cawangan ciri

Motivasi

Cara menggunakannya

Как это работает

Alternatif

Tambah komen Batal reply