🥇Keluaran Werf 1.1: penambahbaikan dalam pengumpul hari ini dan rancangan untuk masa depan

werf ialah utiliti GitOps CLI sumber terbuka kami untuk membina dan menghantar aplikasi kepada Kubernetes. Seperti yang dijanjikan, keluaran versi v1.0 menandakan permulaan menambah ciri baharu pada werf dan menyemak semula pendekatan tradisional. Kini kami berbesar hati mempersembahkan keluaran v1.1, yang merupakan langkah besar dalam pembangunan dan asas untuk masa hadapan pengumpul werf. Versi kini tersedia dalam saluran 1.1 ea.

Asas keluaran adalah seni bina baharu storan pentas dan pengoptimuman kerja kedua-dua pengumpul (untuk Stapel dan Dockerfile). Seni bina storan baharu membuka kemungkinan untuk melaksanakan himpunan teragih daripada berbilang hos dan himpunan selari pada hos yang sama.

Pengoptimuman kerja termasuk menyingkirkan pengiraan yang tidak perlu pada peringkat pengiraan tandatangan peringkat dan menukar mekanisme untuk mengira jumlah semak fail kepada yang lebih cekap. Pengoptimuman ini mengurangkan purata masa pembinaan projek menggunakan werf. Dan binaan terbiar, apabila semua peringkat wujud dalam cache peringkat-penyimpanan, kini benar-benar pantas. Dalam kebanyakan kes, memulakan semula binaan akan mengambil masa kurang daripada 1 saat! Ini juga terpakai pada prosedur untuk mengesahkan peringkat dalam proses kerja pasukan. werf deploy и werf run.

Juga dalam keluaran ini, strategi untuk menandai imej mengikut kandungan muncul - penandaan berasaskan kandungan, yang kini didayakan secara lalai dan satu-satunya yang disyorkan.

Mari kita lihat dengan lebih dekat inovasi utama dalam werf v1.1, dan pada masa yang sama memberitahu anda tentang rancangan untuk masa hadapan.

Apakah yang telah berubah dalam werf v1.1?

Format dan algoritma penamaan peringkat baharu untuk memilih peringkat daripada cache

Peraturan penjanaan nama pentas baharu. Kini setiap binaan peringkat menjana nama peringkat yang unik, yang terdiri daripada 2 bahagian: tandatangan (seperti dalam v1.0) serta pengecam sementara yang unik.

Sebagai contoh, nama imej pentas penuh mungkin kelihatan seperti ini:

werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835

...atau secara umum:

werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC

Di sini:

SIGNATURE ialah tandatangan pentas, yang mewakili pengecam kandungan pentas dan bergantung pada sejarah suntingan dalam Git yang membawa kepada kandungan ini;
TIMESTAMP_MILLISEC ialah pengecam imej unik yang dijamin yang dihasilkan pada masa imej baharu dibina.

Algoritma untuk memilih peringkat daripada cache adalah berdasarkan pada memeriksa hubungan komit Git:

Werf mengira tandatangan peringkat tertentu.
В peringkat-penyimpanan Mungkin terdapat beberapa peringkat untuk tandatangan yang diberikan. Werf memilih semua peringkat yang sepadan dengan tandatangan.
Jika peringkat semasa dipautkan ke Git (git-archive, peringkat tersuai dengan tampung Git: install, beforeSetup, setup; atau git-latest-patch), kemudian werf hanya memilih peringkat yang dikaitkan dengan komit yang merupakan nenek moyang komit semasa (yang binaan dipanggil).
Daripada baki peringkat yang sesuai, satu dipilih - yang tertua mengikut tarikh penciptaan.

Satu peringkat untuk cawangan Git yang berbeza boleh mempunyai tandatangan yang sama. Tetapi werf akan menghalang cache yang dikaitkan dengan cawangan berbeza daripada digunakan antara cawangan ini, walaupun tandatangan sepadan.

→ Dokumentasi.

Algoritma baharu untuk mencipta dan menyimpan peringkat dalam storan peringkat

Jika, apabila memilih peringkat dari cache, werf tidak menemui peringkat yang sesuai, maka proses memasang peringkat baru dimulakan.

Ambil perhatian bahawa berbilang proses (pada satu atau lebih hos) boleh mula membina peringkat yang sama pada masa yang sama. Werf menggunakan algoritma penyekatan yang optimistik peringkat-penyimpanan pada saat menyimpan imej yang baru dikumpulkan peringkat-penyimpanan. Dengan cara ini, apabila binaan peringkat baharu sudah siap, werf menghalang peringkat-penyimpanan dan menyimpan imej yang baru dikumpulkan di sana hanya jika imej yang sesuai tidak lagi wujud di sana (dengan tandatangan dan parameter lain - lihat algoritma baharu untuk memilih peringkat daripada cache).

Imej yang baru dipasang dijamin mempunyai pengecam unik oleh TIMESTAMP_MILLISEC (lihat format penamaan peringkat baharu). Sekiranya dalam peringkat-penyimpanan imej yang sesuai akan ditemui, werf akan membuang imej yang baru disusun dan akan menggunakan imej dari cache.

Dalam erti kata lain: proses pertama untuk menyelesaikan membina imej (yang terpantas) akan mendapat hak untuk menyimpannya secara storan berperingkat (dan kemudian imej tunggal inilah yang akan digunakan untuk semua binaan). Proses binaan yang perlahan tidak akan menghalang proses yang lebih pantas daripada menyimpan hasil binaan peringkat semasa dan beralih ke binaan seterusnya.

→ Dokumentasi.

Prestasi pembina fail Docker yang dipertingkatkan

Pada masa ini, saluran paip peringkat untuk imej yang dibina daripada Dockerfile terdiri daripada satu peringkat - dockerfile. Semasa mengira tandatangan, jumlah semak fail dikira context, yang akan digunakan semasa pemasangan. Sebelum penambahbaikan ini, werf menelusuri semua fail secara rekursif dan memperoleh jumlah semak dengan menjumlahkan konteks dan mod setiap fail. Bermula dengan v1.1, werf boleh menggunakan jumlah semak yang dikira yang disimpan dalam repositori Git.

Algoritma adalah berdasarkan git ls-tree. Algoritma mengambil kira rekod dalam .dockerignore dan melintasi pokok fail secara rekursif hanya apabila perlu. Oleh itu, kami telah memisahkan daripada membaca sistem fail, dan pergantungan algoritma pada saiz context tidak ketara.

Algoritma juga menyemak fail yang tidak dijejaki dan, jika perlu, mengambil kiranya dalam jumlah semak.

Prestasi yang lebih baik apabila mengimport fail

Versi werf v1.1 menggunakan pelayan rsync apabila mengimport fail daripada artifak dan imej. Sebelum ini, pengimportan dilakukan dalam dua langkah menggunakan pelekap direktori daripada sistem hos.

Prestasi import pada macOS tidak lagi dihadkan oleh volum Docker, dan import selesai dalam jumlah masa yang sama seperti Linux dan Windows.

penandaan berasaskan kandungan

Werf v1.1 menyokong apa yang dipanggil penandaan oleh kandungan imej - penandaan berasaskan kandungan. Tag imej Docker yang terhasil bergantung pada kandungan imej tersebut.

Apabila menjalankan arahan werf publish --tags-by-stages-signature atau werf ci-env --tagging-strategy=stages-signature menerbitkan imej yang dipanggil tandatangan pentas gambar. Setiap imej ditandakan dengan tandatangan sendiri bagi peringkat imej ini, yang dikira mengikut peraturan yang sama seperti tandatangan biasa setiap peringkat secara berasingan, tetapi merupakan pengecam umum imej.

Tandatangan peringkat imej bergantung pada:

kandungan imej ini;
sejarah perubahan Git yang membawa kepada kandungan ini.

Repositori Git sentiasa mempunyai komitmen palsu yang tidak mengubah kandungan fail imej. Contohnya, commit dengan hanya ulasan atau merge commit, atau commit yang menukar fail tersebut dalam Git yang tidak akan diimport ke dalam imej.

Apabila menggunakan penandaan berasaskan kandungan, masalah memulakan semula pod aplikasi yang tidak perlu dalam Kubernetes disebabkan oleh perubahan dalam nama imej diselesaikan, walaupun kandungan imej tidak berubah. Dengan cara ini, ini adalah salah satu sebab yang menghalang menyimpan banyak perkhidmatan mikro satu aplikasi dalam satu repositori Git.

Selain itu, penandaan berasaskan kandungan ialah kaedah penandaan yang lebih dipercayai daripada penandaan pada cawangan Git, kerana kandungan imej yang terhasil tidak bergantung pada susunan saluran paip dilaksanakan dalam sistem CI untuk memasang berbilang komitmen bagi cawangan yang sama.

Ia adalah penting: bermula dari sekarang peringkat-tandatangan - Adakah satu-satunya strategi penandaan yang disyorkan. Ia akan digunakan secara lalai dalam arahan werf ci-env (melainkan anda menyatakan secara eksplisit skim penandaan yang berbeza).

→ Dokumentasi. Penerbitan berasingan juga akan dikhaskan untuk ciri ini. DIKEMASKINI (3 April): Artikel dengan butiran diterbitkan.

Tahap pembalakan

Pengguna kini mempunyai peluang untuk mengawal output, menetapkan tahap pengelogan dan bekerja dengan maklumat penyahpepijatan. Pilihan ditambah --log-quiet, --log-verbose, --log-debug.

Secara lalai, output mengandungi maklumat minimum:

Apabila menggunakan output verbose (--log-verbose) anda boleh melihat cara werf berfungsi:

Keluaran terperinci (--log-debug), sebagai tambahan kepada maklumat penyahpepijatan werf, juga mengandungi log perpustakaan terpakai. Sebagai contoh, anda boleh melihat cara interaksi dengan Docker Registry berlaku dan juga merekodkan tempat di mana sejumlah besar masa dihabiskan:

Rancangan masa hadapan

Amaran! Pilihan yang diterangkan di bawah ditandakan v1.1 akan tersedia dalam versi ini, kebanyakannya dalam masa terdekat. Kemas kini akan datang melalui kemas kini automatik apabila menggunakan multiwerf. Ciri ini tidak menjejaskan bahagian stabil fungsi v1.1; penampilannya tidak memerlukan campur tangan pengguna manual dalam konfigurasi sedia ada.

Sokongan penuh untuk pelbagai pelaksanaan Docker Registry (BARU)

Versi: v1.1
Tarikh: Mac
Isu

Matlamatnya adalah untuk pengguna menggunakan pelaksanaan tersuai tanpa sekatan apabila menggunakan werf.

Pada masa ini, kami telah mengenal pasti set penyelesaian berikut yang kami akan menjamin sokongan penuh:

Lalai (perpustakaan/pendaftaran)*,
AWS ECR
Azure*,
Hab Docker
GCR*,
Pakej GitHub
Pendaftaran GitLab*,
Pelabuhan*,
Dermaga.

Penyelesaian yang pada masa ini disokong sepenuhnya oleh werf ditandakan dengan asterisk. Bagi yang lain ada sokongan, tetapi dengan batasan.

Dua masalah utama boleh dikenalpasti:

Sesetengah penyelesaian tidak menyokong penyingkiran teg menggunakan Docker Registry API, menghalang pengguna daripada menggunakan pembersihan automatik werf. Ini benar untuk AWS ECR, Docker Hub dan Pakej GitHub.
Sesetengah penyelesaian tidak menyokong apa yang dipanggil repositori bersarang (Docker Hub, Pakej GitHub dan Quay) atau tidak, tetapi pengguna mesti menciptanya secara manual menggunakan UI atau API (AWS ECR).

Kami akan menyelesaikan masalah ini dan masalah lain menggunakan API asli penyelesaian. Tugas ini juga termasuk meliputi kitaran penuh operasi werf dengan ujian untuk setiap satu.

Binaan imej yang diedarkan (↑)

Versi: v1.2 v1.1 (keutamaan untuk melaksanakan ciri ini telah ditingkatkan)
Tarikh: Mac-April Mac
Isu

Pada masa ini, werf v1.0 dan v1.1 hanya boleh digunakan pada satu hos khusus untuk operasi membina dan menerbitkan imej serta menggunakan aplikasi ke Kubernetes.

Untuk membuka kemungkinan kerja werf yang diedarkan, apabila binaan dan penggunaan aplikasi dalam Kubernetes dilancarkan pada beberapa hos sewenang-wenangnya dan hos ini tidak menyimpan keadaan mereka antara binaan (pelari sementara), werf diperlukan untuk melaksanakan keupayaan untuk menggunakan Pendaftaran Docker sebagai kedai pentas.

Sebelum ini, apabila projek werf masih dipanggil dapp, ia mempunyai peluang sedemikian. Walau bagaimanapun, kami telah menghadapi beberapa isu yang perlu diambil kira semasa melaksanakan fungsi ini dalam werf.

Nota. Ciri ini tidak memerlukan pengumpul untuk bekerja di dalam pod Kubernetes, kerana Untuk melakukan ini, anda perlu menyingkirkan pergantungan pada pelayan Docker tempatan (dalam pod Kubernetes tidak ada akses kepada pelayan Docker tempatan, kerana proses itu sendiri berjalan dalam bekas, dan werf tidak dan tidak akan menyokong bekerja dengan pelayan Docker melalui rangkaian). Sokongan untuk menjalankan Kubernetes akan dilaksanakan secara berasingan.

Sokongan rasmi untuk Tindakan GitHub (BARU)

Versi: v1.1
Tarikh: Mac
Isu

Termasuk dokumentasi werf (bahagian rujukan и membimbing), serta Tindakan GitHub rasmi untuk bekerja dengan werf.

Di samping itu, ia akan membolehkan werf bekerja pada pelari fana.

Mekanik interaksi pengguna dengan sistem CI akan berdasarkan meletakkan label pada permintaan tarik untuk memulakan tindakan tertentu untuk membina/melancarkan aplikasi.

Pembangunan tempatan dan penggunaan aplikasi dengan werf (↓)

Versi: v1.1
Tarikh: Januari-Februari April
Isu

Matlamat utama adalah untuk mencapai satu konfigurasi bersatu untuk menggunakan aplikasi secara tempatan dan dalam pengeluaran, tanpa tindakan yang rumit, di luar kotak.

werf juga dikehendaki mempunyai mod operasi di mana ia akan memudahkan untuk mengedit kod aplikasi dan serta-merta menerima maklum balas daripada aplikasi yang sedang berjalan untuk nyahpepijat.

Algoritma pembersihan baharu (BARU)

Versi: v1.1
Tarikh: April
Isu

Dalam versi semasa werf v1.1 dalam prosedur cleanup Tiada peruntukan untuk membersihkan imej untuk skim penandaan berasaskan kandungan - imej ini akan terkumpul.

Selain itu, versi semasa werf (v1.0 dan v1.1) menggunakan dasar pembersihan yang berbeza untuk imej yang diterbitkan di bawah skim penandaan: cawangan Git, teg Git atau komitmen Git.

Algoritma baharu untuk membersihkan imej berdasarkan sejarah komit dalam Git, disatukan untuk semua skema penandaan, telah dicipta:

Simpan tidak lebih daripada imej N1 yang dikaitkan dengan komitmen terkini N2 untuk setiap git HEAD (cawangan dan tag).
Simpan tidak lebih daripada imej peringkat N1 yang dikaitkan dengan komitmen terkini N2 untuk setiap git HEAD (cawangan dan tag).
Simpan semua imej yang digunakan dalam mana-mana sumber kluster Kubernetes (semua konteks kube fail konfigurasi dan ruang nama diimbas; anda boleh mengehadkan tingkah laku ini dengan pilihan khas).
Simpan semua imej yang digunakan dalam manifes konfigurasi sumber yang disimpan dalam keluaran Helm.
Imej boleh dipadamkan jika ia tidak dikaitkan dengan mana-mana HEAD daripada git (contohnya, kerana HEAD yang sepadan itu sendiri telah dipadamkan) dan tidak digunakan dalam mana-mana manifes dalam gugusan Kubernetes dan dalam keluaran Helm.

Binaan imej selari (↓)

Versi: v1.1
Tarikh: Januari-Februari April*

Versi semasa werf mengumpul imej dan artifak yang diterangkan dalam werf.yaml, secara berurutan. Ia adalah perlu untuk menyelaraskan proses memasang peringkat bebas imej dan artifak, serta menyediakan output yang mudah dan bermaklumat.

* Nota: tarikh akhir telah dialihkan disebabkan peningkatan keutamaan untuk melaksanakan pemasangan teragih, yang akan menambah lebih banyak keupayaan penskalaan mendatar, serta penggunaan werf dengan Tindakan GitHub. Perhimpunan selari ialah langkah pengoptimuman seterusnya, menyediakan kebolehskalaan menegak apabila memasang satu projek.

Peralihan kepada Helm 3 (↓)

Versi: v1.2
Tarikh: Februari-Mac Mei*

Termasuk pemindahan ke pangkalan kod baharu Helm 3 dan cara yang terbukti dan mudah untuk memindahkan pemasangan sedia ada.

* Nota: penukaran kepada Helm 3 tidak akan menambah ciri penting pada werf, kerana semua ciri utama Helm 3 (3-way-cantum dan tiada tiller) sudah dilaksanakan dalam werf. Lebih-lebih lagi, werf mempunyai ciri-ciri tambahan sebagai tambahan kepada yang ditunjukkan. Walau bagaimanapun, peralihan ini kekal dalam rancangan kami dan akan dilaksanakan.

Jsonnet untuk menerangkan konfigurasi Kubernetes (↓)

Versi: v1.2
Tarikh: Januari-Februari April-Mei

Werf akan menyokong penerangan konfigurasi untuk Kubernetes dalam format Jsonnet. Pada masa yang sama, werf akan kekal serasi dengan Helm dan akan ada pilihan format penerangan.

Sebabnya ialah templat Go, menurut ramai orang, mempunyai halangan kemasukan yang tinggi, dan kebolehfahaman kod templat ini juga terjejas.

Kemungkinan untuk memperkenalkan sistem penerangan konfigurasi Kubernetes lain (contohnya, Kustomize) juga sedang dipertimbangkan.

Bekerja di dalam Kubernetes (↓)

Versi: v1.2
Tarikh: April-Mei Mei-Jun

Matlamat: Memastikan imej dibina dan aplikasi dihantar menggunakan pelari dalam Kubernetes. Itu. Imej baharu boleh dipasang, diterbitkan, dibersihkan dan digunakan terus daripada pod Kubernetes.

Untuk melaksanakan keupayaan ini, anda perlu membina imej yang diedarkan terlebih dahulu (lihat titik di atas).

Ia juga memerlukan sokongan untuk mod pengendalian pembina tanpa pelayan Docker (iaitu binaan atau binaan seperti Kaniko dalam ruang pengguna).

Werf akan menyokong pembinaan pada Kubernetes bukan sahaja dengan Dockerfile, tetapi juga dengan pembina Stapelnya dengan binaan semula berperingkat dan Ansible.

Satu langkah ke arah pembangunan terbuka

Kami sayangkan komuniti kami (GitHub, Telegram) dan kami mahu lebih ramai orang membantu menjadikan werf lebih baik, memahami hala tuju yang kami tuju, dan mengambil bahagian dalam pembangunan.

Baru-baru ini diputuskan untuk beralih kepada Papan projek GitHub untuk mendedahkan proses kerja pasukan kami. Kini anda boleh melihat rancangan segera, serta kerja semasa dalam bidang berikut:

Banyak kerja telah dilakukan dengan isu:

Mengalih keluar yang tidak berkaitan.
Yang sedia ada dibawa ke satu format, dengan jumlah butiran dan butiran yang mencukupi.
Isu baharu dengan idea dan cadangan telah ditambah.

Bagaimana untuk mendayakan versi v1.1

Versi kini tersedia dalam saluran 1.1 ea (dalam saluran stabil и batu-pepejal keluaran akan muncul apabila penstabilan berlaku, walau bagaimanapun ea sendiri sudah cukup stabil untuk digunakan, kerana melalui saluran alfa и beta). Diaktifkan melalui multiwerf dengan cara berikut:

source $(multiwerf use 1.1 ea)
werf COMMAND ...

Kesimpulan

Seni bina storan peringkat baharu dan pengoptimuman pembina untuk pembina Stapel dan Dockerfile membuka kemungkinan untuk melaksanakan binaan teragih dan selari dalam werf. Ciri ini tidak lama lagi akan muncul dalam keluaran v1.1 yang sama dan akan tersedia secara automatik melalui mekanisme autokemas kini (untuk pengguna multiwerf).

Dalam keluaran ini, strategi penandaan berdasarkan kandungan imej telah ditambah - penandaan berasaskan kandungan, yang telah menjadi strategi lalai. Log arahan utama juga telah diolah semula: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.

Langkah penting seterusnya ialah menambah perhimpunan yang diedarkan. Binaan yang diedarkan telah menjadi keutamaan yang lebih tinggi daripada binaan selari sejak v1.0 kerana ia menambah lebih nilai pada werf: penskalaan menegak pembina dan sokongan untuk pembina sementara dalam pelbagai sistem CI/CD, serta keupayaan untuk membuat sokongan rasmi untuk Tindakan GitHub . Oleh itu, tarikh akhir pelaksanaan untuk perhimpunan selari telah dialihkan. Walau bagaimanapun, kami sedang berusaha untuk melaksanakan kedua-dua kemungkinan secepat mungkin.

Ikuti berita! Dan jangan lupa kunjungi kami di GitHubuntuk mencipta isu, cari isu yang sedia ada dan tambah tambah, buat PR atau hanya menonton pembangunan projek.

keluaran werf 1.1: penambahbaikan pembina hari ini dan rancangan untuk masa hadapan