minangka sarana open source GitOps CLI kanggo mbangun lan ngirim aplikasi menyang Kubernetes. Kaya janjine, ditandhani awal nambah fitur anyar kanggo werf lan mbenakake pendekatan tradisional. Saiki kita seneng menehi release v1.1, sing minangka langkah gedhe ing pembangunan lan dhasar kanggo masa depan kolektor werf. Versi saiki kasedhiya ing .
Basis rilis yaiku arsitektur anyar saka panyimpenan panggung lan optimalisasi karya loro kolektor (kanggo Stapel lan Dockerfile). Arsitèktur panyimpenan anyar mbukak kamungkinan kanggo ngleksanakake rakitan sing disebarake saka pirang-pirang host lan rakitan paralel ing host sing padha.
Optimasi karya kalebu nyingkirake kalkulasi sing ora perlu ing tahap ngetung tandha panggung lan ngganti mekanisme kanggo ngitung checksum file dadi luwih efisien. Optimasi iki nyuda wektu rata-rata proyek dibangun nggunakake werf. Lan idle mbangun, nalika kabeh tahapan ana ing cache tataran-panyimpenan, saiki cepet banget. Umume kasus, miwiti maneh mbangun bakal njupuk kurang saka 1 detik! Iki uga ditrapake kanggo prosedur verifikasi tahapan ing proses kerja tim. werf deploy и werf run.
Uga ing rilis iki, strategi kanggo menehi tag gambar miturut konten muncul - tagging adhedhasar isi, sing saiki diaktifake kanthi gawan lan mung siji sing disaranake.
Ayo dadi njupuk dipikir nyedhaki ing inovasi tombol ing werf v1.1, lan ing wektu sing padha pitutur marang kowe bab plans kanggo mangsa.
Apa wis diganti ing werf v1.1?
Format lan algoritma jeneng panggung anyar kanggo milih tahapan saka cache
Aturan generasi jeneng panggung anyar. Saiki saben mbangun panggung ngasilake jeneng panggung sing unik, sing dumadi saka 2 bagean: tandha (kaya ing v1.0) ditambah pengenal sementara sing unik.
Contone, jeneng gambar panggung lengkap bisa katon kaya iki:
werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835
... utawa umume:
werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC
Ing kene:
-
SIGNATUREminangka tandha panggung, sing makili pengenal isi panggung lan gumantung saka riwayat suntingan ing Git sing ndadékaké isi iki; -
TIMESTAMP_MILLISECminangka pengenal gambar unik sing dijamin sing digawe nalika gambar anyar dibangun.
Algoritma kanggo milih tahapan saka cache adhedhasar mriksa hubungane Git commits:
- Werf ngitung teken saka tataran tartamtu.
- В tataran-panyimpenan Bisa uga ana sawetara tahapan kanggo tandha tangan. Werf milih kabeh tahapan sing cocog karo tandha.
- Yen tataran saiki disambung menyang Git (git-archive, tataran khusus karo patch Git:
install,beforeSetup,setup; utawa git-latest-patch), banjur werf mung milih tahapan sing digandhengake karo komit sing dadi leluhur saka komit saiki (sing diarani mbangun). - Saka tahapan sing isih cocog, siji dipilih - sing paling tuwa miturut tanggal nggawe.
Tahap kanggo cabang Git sing beda bisa duwe tandha sing padha. Nanging werf bakal nyegah cache sing digandhengake karo cabang sing beda-beda supaya ora digunakake ing antarane cabang kasebut, sanajan tandha tangane cocog.
.
Algoritma anyar kanggo nggawe lan nyimpen tahapan ing panyimpenan panggung
Yen, nalika milih tahapan saka cache, werf ora nemokake tataran sing cocog, banjur proses ngumpulake tahapan anyar diwiwiti.
Elinga yen pirang-pirang proses (ing siji utawa luwih host) bisa miwiti mbangun panggung sing padha ing wektu sing padha. Werf nggunakake algoritma pamblokiran optimistis tataran-panyimpenan ing wayahe nyimpen gambar anyar diklumpukake ing tataran-panyimpenan. Kanthi cara iki, nalika mbangun tataran anyar siap, werf pamblokiran tataran-panyimpenan lan nyimpen gambar anyar diklumpukake ana mung yen gambar cocok ora ana maneh ana (kanthi teken lan paramèter liyane - deleng algoritma anyar kanggo milih tahapan saka cache).
A gambar anyar nglumpuk dijamin duwe pengenal unik dening TIMESTAMP_MILLISEC (deleng format jeneng panggung anyar). Ing kasus ing tataran-panyimpenan gambar cocok bakal ketemu, werf bakal discard gambar anyar nyawiji lan bakal nggunakake gambar saka cache.
Ing tembung liyane: proses pisanan rampung mbangun gambar (sing paling cepet) bakal entuk hak kanggo nyimpen ing tahap-simpenan (lan banjur iki siji gambar sing bakal digunakake kanggo kabeh mbangun). Proses mbangun sing alon ora bakal ngalangi proses sing luwih cepet kanggo nyimpen asil mbangun tahap saiki lan nerusake menyang bangunan sabanjure.
.
Peningkatan kinerja pembangun Dockerfile
Saiki, pipo tahapan kanggo gambar sing dibangun saka Dockerfile kasusun saka siji tahap - dockerfile. Nalika ngitung teken, checksum file diwilang context, sing bakal digunakake sajrone perakitan. Sadurunge dandan iki, werf mlaku kanthi rekursif kabeh file lan entuk checksum kanthi nyimpulake konteks lan mode saben file. Miwiti karo v1.1, werf bisa nggunakake checksums diitung sing disimpen ing gudang Git.
Algoritma adhedhasar . Algoritma njupuk cathetan akun ing .dockerignore lan ngliwati wit file kanthi rekursif mung yen perlu. Mangkono, kita wis decoupled saka maca sistem file, lan katergantungan saka algoritma ing ukuran context ora signifikan.
Algoritma uga mriksa file sing ora dilacak lan, yen perlu, njupuk menyang akun ing checksum.
Kinerja sing luwih apik nalika ngimpor file
Versi werf v1.1 nggunakake server rsync nalika . Sadurunge, ngimpor wis rampung ing rong langkah nggunakake direktori gunung saka sistem inang.
Kinerja impor ing macOS ora diwatesi maneh karo volume Docker, lan impor rampung ing wektu sing padha karo Linux lan Windows.
Tagging adhedhasar isi
Werf v1.1 ndhukung sing diarani menehi tag kanthi isi gambar - tagging adhedhasar isi. Tag saka gambar Docker sing diasilake gumantung karo isi gambar kasebut.
Nalika nindakake printah werf publish --tags-by-stages-signature utawa werf ci-env --tagging-strategy=stages-signature gambar diterbitake saka dadi-disebut teken panggung gambar. Saben gambar diwenehi tandha kanthi teken dhewe saka tahapan gambar iki, sing diitung miturut aturan sing padha karo teken biasa saben tahapan kanthi kapisah, nanging minangka pengenal umum gambar kasebut.
Tandha tahapan gambar gumantung ing:
- isi gambar iki;
- sejarah owah-owahan Git sing nyebabake konten iki.
Repositori Git tansah duwe dummy commits sing ora ngganti isi file gambar. Contone, commits mung komentar utawa merge commits, utawa commit sing ngganti file kasebut ing Git sing ora bakal diimpor menyang gambar.
Nalika nggunakake tagging adhedhasar konten, masalah miwiti maneh pod aplikasi sing ora perlu ing Kubernetes amarga owah-owahan ing jeneng gambar ditanggulangi, sanajan isi gambar ora diganti. Miturut cara, iki minangka salah sawijining alasan sing nyegah nyimpen akeh layanan mikro saka siji aplikasi ing repositori Git siji.
Uga, menehi tag adhedhasar isi minangka cara menehi tag sing luwih dipercaya tinimbang menehi tag ing cabang Git, amarga isi gambar sing diasilake ora gumantung saka urutan pipa sing dieksekusi ing sistem CI kanggo ngumpulake pirang-pirang komitmen saka cabang sing padha.
penting: wiwit saiki tataran-tandha Punika mung strategi menehi tag dianjurake. Iku bakal digunakake minangka standar ing printah werf ci-env (kajaba sampeyan nemtokake kanthi jelas skema tagging sing beda).
. Publikasi sing kapisah uga bakal ditrapake kanggo fitur iki. Dianyari (3 April): Artikel kanthi rincian .
Tingkat logging
Pangguna saiki duwe kesempatan kanggo ngontrol output, nyetel level logging lan nggarap informasi debugging. Pilihan ditambahake --log-quiet, --log-verbose, --log-debug.
Secara default, output ngemot informasi minimal:
Nalika nggunakake output verbose (--log-verbose) sampeyan bisa ndeleng cara kerjane werf:
Output rinci (--log-debug), saliyane informasi debugging werf, uga ngemot log perpustakaan sing digunakake. Contone, sampeyan bisa ndeleng kepiye interaksi karo Registry Docker, lan uga ngrekam papan sing akeh wektu digunakake:
rencana mangsa
Ati-ati Opsi sing diterangake ing ngisor iki ditandhani v1.1 bakal kasedhiya ing versi iki, akeh ing mangsa ngarep. Nganyari bakal teka liwat nganyari otomatis . Fitur kasebut ora mengaruhi bagean stabil saka fungsi v1.1; katon ora mbutuhake campur tangan pangguna manual ing konfigurasi sing wis ana.
Dhukungan lengkap kanggo macem-macem implementasi Docker Registry (NEW)
- Versi: v1.1
- Tanggal: Maret
Tujuane kanggo pangguna nggunakake implementasi adat tanpa watesan nalika nggunakake werf.
Saiki, kita wis nemtokake set solusi ing ngisor iki sing bakal njamin dhukungan lengkap:
- Default (perpustakaan/registri)*,
- AWS ECR
- Azure*,
- Docker Hub
- GCR*,
- Paket GitHub
- GitLab Registry*,
- Pelabuhan*,
- Quay.
Solusi sing saiki didhukung kanthi lengkap dening werf ditandhani karo tanda bintang. Kanggo wong liya ana dhukungan, nanging kanthi watesan.
Loro masalah utama bisa diidentifikasi:
- Sawetara solusi ora ndhukung penghapusan tag nggunakake Docker Registry API, nyegah pangguna nggunakake pembersihan otomatis werf. Iki bener kanggo AWS ECR, Docker Hub, lan Paket GitHub.
- Sawetara solusi ora ndhukung sing diarani repositori bersarang (Docker Hub, Paket GitHub lan Quay) utawa ora, nanging pangguna kudu nggawe kanthi manual nggunakake UI utawa API (AWS ECR).
Kita bakal ngrampungake masalah kasebut lan masalah liyane nggunakake solusi API asli. Tugas iki uga kalebu nutupi siklus lengkap operasi werf karo tes kanggo saben wong.
Bangun gambar sing disebarake (↑)
- Versi: v1.2 v1.1 (prioritas kanggo ngleksanakake fitur iki wis tambah)
- Tanggal: Maret-April Maret
Saiki, werf v1.0 lan v1.1 mung bisa digunakake ing siji host khusus kanggo operasi bangunan lan nerbitake gambar lan nyebarake aplikasi kasebut menyang Kubernetes.
Kanggo mbukak kemungkinan karya werf sing disebarake, nalika mbangun lan panyebaran aplikasi ing Kubernetes diluncurake ing sawetara host sing sewenang-wenang lan host kasebut ora nyimpen negara ing antarane mbangun (pelari sementara), werf dibutuhake kanggo ngetrapake kemampuan kanggo nggunakake. Registry Docker minangka toko panggung.
Sadurungé, nalika proyek werf isih disebut dapp, iku kesempatan kuwi. Nanging, kita wis nemokke sawetara masalah sing kudu dijupuk menyang akun nalika ngleksanakake fungsi iki ing werf.
komentar. Fitur iki ora mbutuhake kolektor kanggo bisa nang Kubernetes pods, amarga Kanggo nindakake iki, sampeyan kudu nyingkirake katergantungan ing server Docker lokal (ing pod Kubernetes ora ana akses menyang server Docker lokal, amarga proses kasebut dhewe mlaku ing wadhah, lan werf ora lan ora ndhukung. nggarap server Docker liwat jaringan). Dhukungan kanggo mbukak Kubernetes bakal ditindakake kanthi kapisah.
Dhukungan resmi kanggo Tindakan GitHub (NEW)
- Versi: v1.1
- Tanggal: Maret
Kalebu dokumentasi werf (bagean referensi и nuntun), uga Tindakan GitHub resmi kanggo nggarap werf.
Kajaba iku, bakal ngidini werf bisa nggarap pelari ephemeral.
Mekanika interaksi pangguna karo sistem CI bakal adhedhasar label panggonan ing panjalukan narik kanggo miwiti tumindak tartamtu kanggo mbangun / muter metu aplikasi.
Pangembangan lokal lan panyebaran aplikasi kanthi werf (↓)
- Versi: v1.1
- Tanggal: Januari-Februari April
Tujuan utama kanggo entuk konfigurasi terpadu siji kanggo nyebarake aplikasi ing lokal lan ing produksi, tanpa tumindak rumit, metu saka kothak.
werf uga kudu duwe mode operasi sing bakal trep kanggo ngowahi kode aplikasi lan langsung nampa umpan balik saka aplikasi sing mlaku kanggo debugging.
Algoritma pembersihan anyar (NEW)
- Versi: v1.1
- Tanggal: April
Ing versi saiki werf v1.1 ing prosedur cleanup Ora ana pranata kanggo ngresiki gambar kanggo skema tagging adhedhasar konten - gambar kasebut bakal nglumpukake.
Uga, versi werf saiki (v1.0 lan v1.1) nggunakake kabijakan pembersihan sing beda kanggo gambar sing diterbitake miturut skema tagging: cabang Git, tag Git utawa Git commit.
Algoritma anyar kanggo ngresiki gambar adhedhasar riwayat komitmen ing Git, sing digabungake kanggo kabeh skema menehi tag, wis diciptakake:
- Tansah ora luwih saka gambar N1 sing digandhengake karo komitmen paling anyar N2 kanggo saben git HEAD (cabang lan tag).
- Simpen ora luwih saka gambar panggung N1 sing digandhengake karo komitmen N2 paling anyar kanggo saben git HEAD (cabang lan tag).
- Simpen kabeh gambar sing digunakake ing sembarang sumber kluster Kubernetes (kabeh konteks kube file konfigurasi lan namespaces dipindai; sampeyan bisa matesi prilaku iki karo opsi khusus).
- Simpen kabeh gambar sing digunakake ing manifests konfigurasi sumber disimpen ing release Helm.
- Gambar bisa dibusak yen ora digandhengake karo HEAD saka git (contone, amarga HEAD sing cocog dhewe wis dibusak) lan ora digunakake ing manifes ing kluster Kubernetes lan ing rilis Helm.
Bangunan gambar paralel (↓)
- Versi: v1.1
- Tanggal: Januari-Februari April*
Versi werf saiki nglumpukake gambar lan artefak sing diterangake ing werf.yaml, kanthi runtut. Sampeyan perlu kanggo parallelize proses assembling orane tumrap sekolah sawijining gambar lan artefak, uga nyedhiyani output trep lan informatif.
* Cathetan: tenggat wektu wis diganti amarga tambah prioritas kanggo ngleksanakake perakitan sing disebarake, sing bakal nambah kemampuan skala horisontal, uga panggunaan werf karo Tindakan GitHub. Déwan paralel minangka langkah optimasi sabanjure, nyedhiyakake skalabilitas vertikal nalika ngrakit siji proyek.
Transisi menyang Helm 3 (↓)
- Versi: v1.2
- Tanggal: Februari-Maret Mei *
Kalebu migrasi menyang basis kode anyar lan bukti, cara trep kanggo migrasi instalasi ana.
* Wigati: ngalih menyang Helm 3 ora bakal nambah fitur penting kanggo werf, amarga kabeh fitur tombol Helm 3 (3-way-merge lan ora ana tiller) wis dipun ginakaken ing werf. Menapa malih, werf wis saliyane sing dituduhake. Nanging, transisi iki tetep ana ing rencana kita lan bakal ditindakake.
Jsonnet kanggo njlèntrèhaké konfigurasi Kubernetes (↓)
- Versi: v1.2
- Tanggal: Januari-Februari April-Mei
Werf bakal ndhukung katrangan konfigurasi kanggo Kubernetes ing format Jsonnet. Ing wektu sing padha, werf bakal tetep kompatibel karo Helm lan bakal ana pilihan format deskripsi.
Alesane yaiku template Go, miturut akeh wong, duwe alangan entri sing dhuwur, lan pemahaman kode template kasebut uga nandhang sangsara.
Kamungkinan kanggo ngenalake sistem deskripsi konfigurasi Kubernetes liyane (contone, Kustomize) uga dianggep.
Makarya ing Kubernetes (↓)
- Versi: v1.2
- Tanggal: April-Mei Mei-Juni
Sasaran: Priksa manawa gambar digawe lan aplikasi dikirim nggunakake pelari ing Kubernetes. Sing. Gambar anyar bisa dirakit, diterbitake, diresiki, lan disebarake langsung saka pods Kubernetes.
Kanggo ngleksanakake kemampuan iki, sampeyan kudu bisa nggawe gambar sing disebarake (ndeleng titik ndhuwur).
Uga mbutuhake dhukungan kanggo mode operasi pembangun tanpa server Docker (yaiku mbangun utawa mbangun kaya Kaniko ing ruang panganggo).
Werf bakal ndhukung bangunan ing Kubernetes ora mung karo Dockerfile, nanging uga karo pembangun Stapel kanthi mbangun maneh lan Ansible.
A langkah menyang pembangunan mbukak
Kita tresna masyarakat kita (, ) lan kita pengin luwih akeh wong kanggo mbantu nggawe werf luwih apik, ngerti arah sing kita tindakake, lan melu pembangunan.
Cukup bubar iki mutusaké kanggo ngalih menyang kanggo mbukak proses kerja tim kita. Saiki sampeyan bisa ndeleng rencana langsung, uga karya saiki ing wilayah ing ngisor iki:
- ;
- ;
- ;
- .
Akeh karya wis rampung karo masalah:
- Mbusak sing ora cocog.
- Sing ana digawa menyang format siji, kanthi jumlah rincian lan rincian sing cukup.
- Masalah anyar karo gagasan lan saran wis ditambahake.
Carane ngaktifake versi v1.1
Versi saiki kasedhiya ing (ing saluran Stabil и rock-padhet rilis bakal katon nalika stabil, Nanging ea dhewe wis cukup stabil kanggo nggunakake, amarga liwat saluran Alpha и beta). Diaktifake kanthi cara ing ngisor iki:
source $(multiwerf use 1.1 ea)
werf COMMAND ...kesimpulan
Arsitèktur panyimpenan panggung anyar lan optimasi pembangun kanggo pembangun Stapel lan Dockerfile mbukak kemungkinan kanggo ngleksanakake bangunan sing disebarake lan paralel ing werf. Fitur-fitur kasebut bakal katon ing rilis v1.1 sing padha lan bakal kasedhiya kanthi otomatis liwat mekanisme nganyari otomatis (kanggo pangguna ).
Ing rilis iki, strategi menehi tag adhedhasar isi gambar wis ditambahake - tagging adhedhasar isi, sing wis dadi strategi standar. Log perintah utama uga wis digarap maneh: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
Langkah penting sabanjure yaiku nambahake rakitan sing disebarake. Mbangun sing disebarake wis dadi prioritas sing luwih dhuwur tinimbang mbangun paralel wiwit v1.0 amarga nambahake nilai luwih akeh kanggo werf: skala vertikal saka pembangun lan dhukungan kanggo pembangun ephemeral ing macem-macem sistem CI / CD, uga kemampuan kanggo nggawe dhukungan resmi kanggo Tindakan GitHub . Mulane, tenggat wektu implementasine kanggo majelis paralel diganti. Nanging, kita makarya kanggo ngleksanakake loro kemungkinan sanalika bisa.
Tindakake warta! Lan aja lali ngunjungi kita ing kanggo nggawe masalah, golek sing wis ana lan nambah plus, nggawe PR, utawa mung nonton pembangunan proyek.
PS
Waca uga ing blog kita:
- «»
- «";
- Serangkaian cathetan babagan inovasi ing werf:
- «";
- «";
- «";
- «".
Source: www.habr.com