Gabungan 3 arah menyang werf: penyebaran menyang Kubernetes kanthi Helm "ing steroid"

Apa sing kita (lan ora mung kita) wis ngenteni suwe: werf, utilitas Open Source kanggo mbangun aplikasi lan ngirim menyang Kubernetes, saiki ndhukung pangowahan nggunakake patch gabungan 3 arah! Saliyane iki, iku bisa kanggo nggunakake sumber K8s ana menyang Rilis Helm tanpa mbangun sumber daya iki.

Yen cendhak banget, banjur kita sijine WERF_THREE_WAY_MERGE=enabled - kita entuk penyebaran "kaya ing kubectl apply", kompatibel karo instalasi Helm 2 sing wis ana lan malah luwih cilik.

Nanging ayo miwiti karo teori: apa sejatine patch 3-way-merge, kepiye carane wong nggawe pendekatan kanggo ngasilake, lan kenapa pentinge ing proses CI / CD kanthi infrastruktur basis Kubernetes? Lan sawise iku, ayo ndeleng apa 3-way-merge ing werf, mode apa sing digunakake kanthi standar lan cara ngatur.

Apa iku patch 3-way-merge?

Dadi, ayo miwiti tugas nggulung sumber daya sing diterangake ing YAML manifests menyang Kubernetes.

Kanggo nggarap sumber daya, API Kubernetes nawakake operasi dhasar ing ngisor iki: nggawe, nambal, ngganti lan mbusak. Dianggep manawa kanthi bantuan kasebut perlu kanggo mbangun sumber daya sing terus-terusan sing trep menyang kluster. kepriye?

perintah imperatif kubectl

Pendekatan pisanan kanggo ngatur obyek ing Kubernetes yaiku nggunakake perintah imperatif kubectl kanggo nggawe, ngowahi, lan mbusak obyek kasebut. Cukup:

• tim kubectl run sampeyan bisa mbukak Penyebaran utawa Proyek:

  kubectl run --generator=deployment/apps.v1 DEPLOYMENT_NAME --image=IMAGE

• tim kubectl scale - ngganti jumlah replika:

  kubectl scale --replicas=3 deployment/mysql

• lan liya-liyane.

Pendekatan iki bisa uga katon trep ing pandang sepisanan. Nanging ana masalah:

1. Iku angel otomatisasi.
2. Carane nggambarake konfigurasi ing Git? Kepiye carane mriksa owah-owahan sing kedadeyan ing kluster?
3. Carane nyedhiyani reproducibility konfigurasi nalika miwiti maneh?
4. ...

Cetha manawa pendekatan iki ora cocog karo nyimpen aplikasi lan infrastruktur minangka kode (IaC; utawa malah GitOps minangka pilihan sing luwih modern, entuk popularitas ing ekosistem Kubernetes). Mula, prentah kasebut ora nampa pangembangan luwih lanjut ing kubectl.

Nggawe, entuk, ngganti lan mbusak operasi

Kanthi utami cipta iku prasaja: ngirim manifest menyang operasi create kube api lan sumber daya wis digawe. Perwakilan YAML saka manifest bisa disimpen ing Git lan digawe nggunakake printah kubectl create -f manifest.yaml.

С njabut uga prasaja: sulih padha manifest.yaml saka Git menyang tim kubectl delete -f manifest.yaml.

Operasi replace ngijini sampeyan kanggo rampung ngganti konfigurasi sumber karo sing anyar, tanpa nggawé ulang sumber daya. Iki tegese sadurunge nggawe owah-owahan menyang sumber daya, iku logis kanggo takon versi saiki karo operasi get, ngganti lan nganyari karo operasi replace. kube apiserver dibangun ing ngunci optimistis lan, yen sawise surgery get obyek wis diganti, banjur operasi replace ora bakal lulus.

Kanggo nyimpen konfigurasi ing Git lan nganyari nggunakake ngganti, sampeyan kudu nindakake operasi get, gabungke konfigurasi saka Git karo apa sing ditampa, lan eksekusi replace. Kanthi gawan, kubectl mung ngidini sampeyan nggunakake printah kubectl replace -f manifest.yamlngendi manifest.yaml - Manifestasi sing wis disiapake kanthi lengkap (ing kasus kita, gabungan) sing kudu diinstal. Pranyata pangguna kudu ngetrapake manifests gabungan, lan iki minangka perkara sing ora pati penting ...

Iku uga worth kang lagi nyimak sing sanadyan manifest.yaml lan disimpen ing Git, kita ora bisa ngerti luwih dhisik apa perlu nggawe obyek utawa nganyari - iki kudu ditindakake dening piranti lunak pangguna.

Total: bisa kita mbangun rollout terus-terusan mung nggunakake nggawe, ngganti lan mbusak, mesthekake yen konfigurasi infrastruktur disimpen ing Git bebarengan karo kode lan CI trep / CD?

Ing asas, kita bisa ... Kanggo iki sampeyan kudu ngleksanakake operasi gabungan manifesto lan sawetara jinis ikatan sing:

• mriksa anané obyek ing kluster,
• nggawe sumber daya wiwitan,
• nganyari utawa mbusak.

Nalika nganyari, elinga yen sumber daya bisa diganti wiwit pungkasan get lan kanthi otomatis nangani kasus ngunci optimistis - gawe nyoba nganyari bola-bali.

Nanging, kok reinvent setir nalika kube-apiserver nawakake cara liya kanggo nganyari sumber daya: operasi patch, kang relieves pangguna sawetara saka masalah diterangake?

Tembelan

Saiki kita menyang patch.

Patch minangka cara utama kanggo ngetrapake owah-owahan menyang obyek sing ana ing Kubernetes. Operasi patch kerjane kaya iki:

• pangguna kube-apiserver kudu ngirim tembelan ing wangun JSON lan nemtokake obyek kasebut,
• lan apiserver dhewe bakal menehi hasil karo kahanan saiki obyek lan nggawa menyang wangun sing dibutuhake.

Ngunci optimis ora dibutuhake ing kasus iki. Operasi iki luwih deklaratif tinimbang ngganti, sanajan ing wiwitan bisa uga katon sebaliknya.

Kanthi cara iki:

• nggunakake operasi create kita nggawe obyek miturut manifest saka Git,
• kanthi pitulung saka delete - mbusak yen obyek ora dibutuhake maneh,
• kanthi pitulung saka patch - kita ngganti obyek, nggawa menyang wangun sing diterangake ing Git.

Nanging, kanggo nindakake iki, sampeyan kudu nggawe patch bener!

Cara kerja patch ing Helm 2: 2-way-merge

Nalika sampeyan nginstal release pisanan, Helm nindakake operasi kasebut create kanggo sumber daya grafik.

Nalika nganyari release Helm kanggo saben sumber:

• nimbang tembelan antarane versi sumber daya saka bagan sadurunge lan versi bagan saiki,
• ditrapake patch iki.

Kita bakal nelpon patch iki Patch gabungan 2 arah, amarga 2 manifesto melu nggawe:

• sumber daya saka release sadurungé,
• resource manifest saka sumber daya saiki.

Nalika njabut operasi delete ing kube apiserver diarani sumber daya sing diumumake ing release sadurungé, nanging ora diumumake ing saiki.

Pendekatan patch gabungan 2 duwe masalah: ndadékaké menyang ora sinkron karo kahanan nyata sumber daya ing kluster lan manifest ing Git.

Ilustrasi masalah kanthi conto

• Ing Git, grafik nyimpen manifest ing lapangan image Panyebaran prakara ubuntu:18.04.
• Panganggo liwat kubectl edit diganti Nilai saka lapangan iki kanggo ubuntu:19.04.
• Nalika masang maneh grafik Helm ora ngasilake tembelan, amarga lapangan image ing versi rilis sadurungé lan ing grafik saiki padha.
• Sawise disebarake maneh image Sisa ubuntu:19.04, sanajan grafik ngandika ubuntu:18.04.

Kita entuk desynchronization lan ilang declarativeness.

Apa sumber daya sing disinkronake?

Umumé ngandika lengkap Ora mungkin entuk pertandhingan antarane manifes sumber daya ing kluster sing mlaku lan manifes saka Git. Amarga ing nyata nyata bisa uga ana anotasi / label layanan, wadhah tambahan lan data liyane sing ditambahake lan dibusak saka sumber daya kanthi dinamis dening sawetara pengontrol. Kita ora bisa lan ora pengin nyimpen data iki ing Git. Nanging, kita pengin kolom sing kita jelasake ing Git njupuk nilai sing cocog nalika diluncurake.

Pranyata umum banget aturan sumber sing disinkronake: nalika mbukak sumber daya, sampeyan mung bisa ngganti utawa mbusak kolom kasebut kanthi jelas ing manifest saka Git (utawa ditemtokake ing versi sadurunge lan saiki wis dibusak).

Patch gabungan 3 arah

ide utama Patch gabungan 3 arah: ngasilake tembelan antarane versi aplikasi pungkasan saka manifest saka Git lan versi target saka manifest saka Git, njupuk menyang akun versi saiki manifest saka kluster mlaku. Tembelan sing diasilake kudu tundhuk karo aturan sumber sing disinkronake:

• kolom anyar sing ditambahake menyang versi target ditambahake nggunakake tembelan;
• kolom sing sadurunge ana ing versi aplikasi pungkasan lan ora ana ing versi target direset nggunakake tembelan;
• kolom ing versi obyek saiki sing beda karo versi target manifest dianyari nggunakake tembelan.

Iku ing prinsip iki sing ngasilake patch kubectl apply:

• versi manifest pungkasan sing ditrapake disimpen ing anotasi obyek kasebut,
• target - dijupuk saka file YAML sing ditemtokake,
• sing saiki saka kluster mlaku.

Saiki kita wis diurutake metu teori, iku wektu kanggo pitutur marang kowe apa kita nindakake ing werf.

Nglamar owah-owahan kanggo werf

Sadurunge, werf, kaya Helm 2, nggunakake patch 2-way-merge.

Ndandani patch

Kanggo ngalih menyang jinis patch anyar - 3-way-merge - langkah pisanan kita ngenalake sing diarani ndandani patch.

Nalika nyebarke, patch 2-way-merge standar digunakake, nanging werf uga nggawe tembelan sing bakal nyinkronake kahanan nyata sumber daya karo apa sing ditulis ing Git (tembelan kasebut digawe nggunakake aturan sumber sing padha sing disinkronake ing ndhuwur) .

Yen ana desynchronization, ing mburi penyebaran pangguna nampa PÈNGET karo pesen sing cocog lan tembelan sing kudu Applied kanggo nggawa sumber menyang wangun diselarasake. Patch iki uga direkam ing anotasi khusus werf.io/repair-patch. Dianggep yen tangan pangguna сам bakal aplikasi patch iki: werf ora bakal aplikasi ing kabeh.

Ngasilake patch ndandani minangka langkah sementara sing ngidini sampeyan bener-bener nyoba nggawe tambalan adhedhasar prinsip 3-way-merge, nanging ora nggunakake patch kasebut kanthi otomatis. Saiki, mode operasi iki diaktifake kanthi gawan.

Tembelan 3-way-merge mung kanggo rilis anyar

Wiwit 1 Desember 2019, versi beta lan alpha werf diwiwiti kanthi gawan nggunakake patch 3-cara-gabungan lengkap kanggo aplikasi owahan mung kanggo Rilis Helm anyar mbalek metu liwat werf. Rilis sing ana bakal terus nggunakake pendekatan 2-way-merge + patch patch.

Mode operasi iki bisa diaktifake kanthi tegas kanthi nyetel WERF_THREE_WAY_MERGE_MODE=onlyNewReleases saiki.

komentar: fitur muncul ing werf liwat sawetara rilis: ing saluran alpha dadi siap karo versi v1.0.5-alpha.19, lan ing saluran beta - karo v1.0.4-beta.20.

Tembelan 3-way-merge kanggo kabeh rilis

Wiwit tanggal 15 Desember 2019, versi beta lan alpha werf wiwit nggunakake tambalan gabungan 3 arah kanthi standar kanggo ngetrapake owah-owahan ing kabeh rilis.

Mode operasi iki bisa diaktifake kanthi tegas kanthi nyetel WERF_THREE_WAY_MERGE_MODE=enabled saiki.

Apa sing kudu ditindakake kanthi otomatis sumber daya?

Ana 2 jinis autoscaling ing Kubernetes: HPA (horizontal) lan VPA (vertikal).

Horisontal kanthi otomatis milih jumlah replika, vertikal - jumlah sumber daya. Jumlah replika lan syarat sumber daya ditemtokake ing manifest sumber (pirsani Resource Manifest). spec.replicas utawa spec.containers[].resources.limits.cpu, spec.containers[].resources.limits.memory и nggoleki).

Masalah: yen pangguna ngatur sumber daya ing bagan supaya nemtokake nilai tartamtu kanggo sumber daya utawa replika lan autoscalers diaktifake kanggo sumber daya iki, banjur saben panyebaran werf bakal ngreset nilai iki kanggo apa sing ditulis ing manifestation grafik. .

Ana rong solusi kanggo masalah kasebut. Kanggo miwiti, luwih becik ngindhari kanthi jelas nemtokake nilai skala otomatis ing manifes grafik. Yen opsi iki ora cocog kanggo sawetara alesan (contone, amarga iku trep kanggo nyetel watesan sumber daya dhisikan lan nomer replika ing bagan), banjur werf nawakake anotasi ing ngisor iki:

• werf.io/set-replicas-only-on-creation=true
• werf.io/set-resources-only-on-creation=true

Yen anotasi kasebut ana, werf ora bakal ngreset nilai sing cocog ing saben panyebaran, nanging mung bakal disetel nalika sumber kasebut wiwitane digawe.

Kanggo rincian liyane, ndeleng dokumentasi project kanggo HPA и VPA.

Larang nggunakake patch 3-way-merge

Pangguna saiki bisa nglarang panggunaan patch anyar ing werf nggunakake variabel lingkungan WERF_THREE_WAY_MERGE_MODE=disabled. Nanging, miwiti Wiwit tanggal 1 Maret 2020, larangan iki ora bakal ditrapake maneh. lan mung bisa nggunakake patch 3-way-merge.

Adoption saka sumber daya ing werf

Nguwasani cara nglamar owah-owahan karo 3-way-merge patch ngidini kita langsung ngleksanakake fitur kayata nggunakake sumber daya sing ana ing kluster menyang release Helm.

Helm 2 duwe masalah: sampeyan ora bisa nambah sumber daya menyang grafik manifests sing wis ana ing kluster tanpa nggawé ulang sumber iki saka awal (ndeleng. #6031, #3275). Kita mulang werf kanggo nampa sumber daya sing ana kanggo release. Kanggo nindakake iki, sampeyan kudu nginstal anotasi ing versi saiki sumber daya saka kluster mlaku (contone, nggunakake kubectl edit):

"werf.io/allow-adoption-by-release": RELEASE_NAME

Saiki sumber daya kudu diterangake ing grafik lan sabanjure werf nyebarke release karo jeneng cocok, sumber sing wis ana bakal ditampa ing release iki lan tetep ing kontrol. Menapa malih, ing proses nampa sumber kanggo release, werf bakal nggawa negara saiki sumber saka kluster mlaku kanggo negara diterangake ing grafik, nggunakake padha 3-cara-gabungan patch lan aturan sumber diselarasake.

komentar: setting WERF_THREE_WAY_MERGE_MODE ora mengaruhi adopsi sumber daya - ing kasus adopsi, patch 3-way-merge tansah digunakake.

Rincian - ing dokumentasi.

Kesimpulan lan rencana mangsa

Muga-muga sawise artikel iki dadi luwih jelas apa patch 3-way-merge lan ngapa dheweke teka. Saka sudut pandang praktis babagan pangembangan proyek werf, implementasine minangka langkah liya kanggo ningkatake penyebaran kaya Helm. Saiki sampeyan bisa lali babagan masalah karo sinkronisasi konfigurasi, sing asring muncul nalika nggunakake Helm 2. Ing wektu sing padha, fitur anyar sing migunani kanggo nggunakake sumber daya Kubernetes sing wis diunduh ditambahake ing release Helm.

Isih ana sawetara masalah lan tantangan karo panyebaran kaya Helm, kayata nggunakake template Go, sing bakal terus diatasi.

Informasi babagan cara nganyari sumber daya lan adopsi uga bisa ditemokake ing kaca dokumentasi iki.

Helm 3

Patut cathetan khusus dirilis mung dina liyane versi utama anyar saka Helm - v3 - kang uga nggunakake 3-cara-gabungan patch lan njaluk nyisihaken saka Tiller. Versi anyar saka Helm mbutuhake migrasi panginstalan sing ana kanggo ngowahi menyang format panyimpenan release anyar.

Werf, kanggo bagean kasebut, saiki wis nyingkirake nggunakake Tiller, ngalih menyang 3-way-merge lan ditambahake luwih akeh, nalika isih kompatibel karo instalasi Helm 2 sing ana (ora ana skrip migrasi sing kudu ditindakake). Mulane, nganti werf ngalih menyang Helm 3, pangguna werf ora kelangan kaluwihan utama Helm 3 liwat Helm 2 (werf uga duwe).

Nanging, ngalih werf menyang Helm 3 codebase ora bisa dihindari lan bakal kelakon ing mangsa cedhak. Dianggep iki bakal dadi werf 1.1 utawa werf 1.2 (saiki, versi utama werf yaiku 1.0; kanggo informasi luwih lengkap babagan piranti versi werf, waca. kene). Sajrone wektu iki, Helm 3 bakal duwe wektu kanggo stabil.

PS

Waca uga ing blog kita:

• Serangkaian cathetan babagan inovasi ing werf:
  • «Nggunakake werf kanggo muter metu denah Helm Komplek";
  • «Dhukungan kanggo monorepo lan multirepo ing werf lan apa Registry Docker apa karo";
  • «Sampeyan saiki bisa nggawe gambar Docker ing werf nggunakake Dockerfile biasa".
• «werf - alat kita kanggo CI/CD ing Kubernetes (review lan laporan video)";
• «Gawe lan nyebarake layanan mikro saka jinis sing padha karo werf lan GitLab CI";
• «Ngenalake Helm 3".

Source: www.habr.com