werf adalah utilitas GitOps CLI open source kami untuk membangun dan mengirimkan aplikasi ke Kubernetes. Seperti yang dijanjikan, rilis v1.0 menandai awal penambahan fitur baru ke werf dan merevisi pendekatan yang sudah dikenal. Sekarang kami senang untuk merilis v1.1, yang merupakan langkah besar dalam pengembangan dan masa depan dalam wer kolektor . Versi saat ini tersedia di saluran 1.1 ea .Dasar dari rilis adalah arsitektur baru penyimpanan panggung dan optimalisasi karya kedua kolektor (untuk Stapel dan Dockerfile). Arsitektur penyimpanan baru membuka kemungkinan penerapan rakitan terdistribusi dari beberapa host dan rakitan paralel pada satu host.Optimalisasi pekerjaan termasuk menyingkirkan perhitungan yang tidak perlu pada tahap penghitungan tanda tangan tahap dan mengubah mekanisme untuk menghitung checksum file menjadi yang lebih efisien. Optimalisasi ini mengurangi waktu pembuatan rata-rata suatu proyek menggunakan werf. Dan idle builds, ketika semua stage ada di cache stage-storage , sekarang sangat cepat. Dalam kebanyakan kasus, memulai kembali perakitan akan lebih cepat daripada dalam 1 detik! Ini juga berlaku pada prosedur untuk memverifikasi tahapan selama pekerjaan tim werf deploydan werf run.Juga dalam rilis ini ada strategi untuk menandai gambar berdasarkan konten - penandaan berbasis konten , yang sekarang diaktifkan secara default dan merupakan satu-satunya yang direkomendasikan.Mari kita melihat lebih dekat inovasi utama di werf v1.1, dan pada saat yang sama berbicara tentang rencana untuk masa depan.Apa yang telah berubah di werf v1.1?
Format penamaan tahap baru dan algoritma pemilihan tahap cache
Aturan pembuatan nama panggung baru. Sekarang setiap rakitan tahap menghasilkan nama panggung yang unik, yang terdiri dari 2 bagian: tanda tangan (seperti dalam v1.0) ditambah pengenal sementara yang unik.Misalnya, nama lengkap gambar panggung dapat terlihat seperti ini:werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835... atau dalam bentuk umum:werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISECDi sini:SIGNATURE - ini adalah tanda tangan panggung, yang mewakili pengidentifikasi konten panggung dan tergantung pada riwayat suntingan di Git yang mengarah ke konten ini;TIMESTAMP_MILLISEC - Ini dijamin pengidentifikasi unik untuk gambar yang dihasilkan pada saat perakitan gambar baru.
Algoritma untuk memilih tahapan dari cache didasarkan pada memeriksa hubungan dari komitmen Git:- Werf menghitung tanda tangan dari beberapa tahap.
- Dalam penyimpanan tahap , ada beberapa tahap untuk tanda tangan yang diberikan. Werf memilih semua tahapan yang sesuai untuk tanda tangan.
- Jika tahap saat berhubungan dengan Git (git-arsip, pengguna langkah c Git-patch:
install, beforeSetup, setup, atau git-terbaru-Patch), maka Werf menyeleksi hanya langkah-langkah yang berhubungan dengan komit, yang merupakan nenek moyang saat komit (yang disebabkan perakitan ) - Dari tahapan yang sesuai yang tersisa, satu dipilih - yang tertua berdasarkan tanggal pembuatan.
Sebuah panggung untuk cabang Git yang berbeda dapat memiliki tanda tangan yang sama. Tetapi werf akan mencegah penggunaan cache yang terkait dengan cabang berbeda antara cabang-cabang ini, bahkan jika tanda tangan cocok.→ Dokumentasi .Algoritma baru untuk membuat dan menyimpan tahapan dalam penyimpanan panggung
Jika werf tidak menemukan tahap yang cocok selama pemilihan tahapan dari cache, proses pemasangan tahap baru dimulai.Perhatikan bahwa beberapa proses (pada satu atau lebih host) dapat mulai merakit tahap yang sama pada waktu yang hampir bersamaan. Werf menggunakan algoritme penguncian optimis tahap-penyimpanan ketika gambar yang baru dikumpulkan disimpan dalam tahap-penyimpanan . Jadi, ketika perakitan tahap baru siap, werf memblokir penyimpanan tahap dan menyimpan gambar yang baru dikumpulkan di sana hanya jika tidak ada gambar yang sesuai di sana (untuk tanda tangan dan parameter lainnya - lihat algoritma baru untuk memilih tahapan dari cache) .Gambar yang baru dipetik dijamin memiliki pengidentifikasi unik oleh TIMESTAMP_MILLISEC (lihat format penamaan panggung baru) . Jika gambar yang cocok ditemukan dalam penyimpanan tahap , werf akan membuang gambar yang baru dikumpulkan dan akan menggunakan gambar dari cache.Dengan kata lain: proses pertama yang selesai mengumpulkan gambar (tercepat) akan menerima hak untuk menyimpannya dalam penyimpanan tahap (dan kemudian gambar khusus ini akan digunakan untuk semua majelis). Proses perakitan lambat tidak akan pernah menghalangi proses yang lebih cepat dari menyimpan hasil perakitan dari tahap saat ini dan melanjutkan ke perakitan berikutnya.→ Dokumentasi .Peningkatan kinerja kolektor Dockerfile
Saat ini, pipeline stage untuk gambar yang dikompilasi dari Dockerfile terdiri dari satu stage - dockerfile. Saat menghitung tanda tangan, checksum dari file dipertimbangkan context, yang akan digunakan selama perakitan. Sebelum perbaikan ini, Werf secara traverse melintasi semua file dan menerima checksum, meringkas konteks dan mode setiap file. Dimulai dengan v1.1, werf dapat menggunakan checksum terhitung yang disimpan dalam repositori Git.Algoritma ini didasarkan pada git ls-tree . Algoritma memperhitungkan entri akun .dockerignoredan melewati secara rekursif melalui pohon file hanya jika perlu. Jadi, kami menyingkirkan membaca sistem file, dan ketergantungan algoritma pada ukuran contexttidak signifikan.Algoritma ini juga memeriksa file yang tidak terlacak dan, jika perlu, memperhitungkannya dalam checksum.Peningkatan kinerja saat mengimpor file
Werf v1.1 menggunakan server rsync ketika mengimpor file dari artefak dan gambar . Sebelumnya, pengimporan dilakukan dalam dua langkah menggunakan pemasangan direktori dari sistem host.Kinerja impor pada macOS tidak lagi terbatas pada volume Docker, dan impor dilakukan bersamaan dengan Linux dan Windows.Penandaan berbasis konten
Werf v1.1 mendukung apa yang disebut penandaan oleh konten gambar - penandaan berbasis konten . Tag untuk gambar Docker yang dihasilkan tergantung pada konten gambar-gambar ini.Ketika Anda menjalankan perintah werf publish --tags-by-stages-signatureatau werf ci-env --tagging-strategy=stages-signature, gambar yang diterbitkan dari apa yang disebut tanda tangan tahap gambar akan diuji . Setiap gambar ditandai dengan tanda tangannya sendiri dari tahapan gambar ini, yang dihitung sesuai dengan aturan yang sama seperti tanda tangan biasa dari setiap tahap secara terpisah, tetapi merupakan pengidentifikasi umum dari gambar tersebut.Tanda tangan dari tahapan gambar tergantung pada:- isi gambar ini;
- Dapatkan riwayat revisi yang mengarah ke konten ini.
Repositori Git selalu memiliki commit kosong yang tidak mengubah konten file gambar. Misalnya, komit dengan komentar saja, atau menggabungkan komit, atau komit yang mengubah file-file di Git yang tidak akan diimpor ke dalam gambar.Menggunakan penandaan berbasis konten memecahkan masalah restart aplikasi yang tidak perlu di Kubernetes karena perubahan nama gambar, bahkan jika konten gambar tidak berubah. By the way, ini adalah salah satu alasan yang membuatnya sulit untuk menyimpan banyak layanan microser dari satu aplikasi dalam repositori Git tunggal.Selain itu, penandaan berbasis konten adalah metode penandaan yang lebih andal daripada penandaan oleh cabang Git, karena konten gambar yang dihasilkan tidak tergantung pada urutan pelaksanaan jaringan pipa dalam sistem CI untuk mengumpulkan beberapa komitmen dari cabang yang sama.Penting: Mulai sekarang, tahap-tanda tangan adalah satu - satunya strategi pemberian tag yang disarankan . Ini akan digunakan secara default di tim werf ci-env(kecuali Anda secara eksplisit menentukan skema pemberian tag yang berbeda).→ Dokumentasi . Publikasi terpisah juga akan didedikasikan untuk fitur ini. DIPERBARUI (3 April): Artikel dengan perincian telah diterbitkan .Level pembalakan
Pengguna memiliki kesempatan untuk mengontrol output, mengatur level logging dan bekerja dengan informasi debug. Pilihan menambahkan --log-quiet, --log-verbose, --log-debug.Secara default, output berisi informasi minimum:
Ketika menggunakan output detail ( --log-verbose), Anda dapat melacak cara kerja werf:
Output detail ( --log-debug), selain informasi debug werf, juga berisi log perpustakaan yang digunakan. Misalnya, Anda dapat melihat bagaimana interaksi dengan Docker Registry terjadi, dan juga memperbaiki tempat-tempat di mana banyak waktu dihabiskan:
Rencana masa depan
Perhatian! Fitur yang diuraikan di bawah ditandai v1.1 akan tersedia dalam versi ini, banyak di antaranya dalam waktu dekat. Pembaruan akan datang melalui pembaruan otomatis saat menggunakan multiwerf . Fitur-fitur ini tidak mempengaruhi bagian stabil dari fungsi v1.1, penampilannya tidak memerlukan intervensi pengguna manual dalam konfigurasi yang ada.Dukungan penuh untuk berbagai implementasi Docker Registry (BARU)
- Versi: v1.1
- Tanggal: Maret
- Isu
Tujuannya adalah bahwa pengguna harus menggunakan implementasi sewenang-wenang tanpa batasan saat menggunakan werf.Sampai saat ini, kami telah mengidentifikasi serangkaian solusi berikut yang akan kami jamin dukungan penuh:- Default (perpustakaan / registri) *,
- AWS ECR,
- Azure *,
- Hub docker
- GCR *,
- Paket Github
- GitLab Registry *,
- Pelabuhan *,
- Dermaga.
Tanda bintang menunjukkan solusi yang saat ini didukung penuh oleh werf. Selebihnya ada dukungan, tetapi dengan keterbatasan.Dua masalah utama dapat dibedakan:- Beberapa solusi tidak mendukung penghapusan tag menggunakan Docker Registry API, yang tidak memungkinkan pengguna untuk menggunakan pembersihan otomatis yang diterapkan di werf. Ini berlaku untuk Paket AWS ECR, Docker Hub, dan GitHub.
- Beberapa solusi tidak mendukung repositori bersarang (Docker Hub, GitHub Packages and Quay) atau dukungan, tetapi pengguna harus membuatnya secara manual menggunakan UI atau API (AWS ECR).
Kami akan menyelesaikan ini dan masalah lain menggunakan API solusi asli. Tugas ini juga mencakup mencakup siklus werf penuh dengan tes untuk masing-masing.Perakitan gambar terdistribusi (↑)
Saat ini, werf v1.0 dan v1.1 hanya dapat digunakan pada satu host khusus untuk perakitan dan publikasi gambar dan penyebaran aplikasi di Kubernetes.Untuk membuka kemungkinan kerja terdistribusi werf, ketika perakitan dan penyebaran aplikasi di Kubernetes dimulai pada beberapa host sewenang-wenang dan host ini tidak mempertahankan statusnya di antara majelis (pelari sementara), werf diminta untuk mengimplementasikan kemungkinan menggunakan Docker Registry sebagai repositori tahap.Sebelumnya, ketika proyek werf masih disebut dapp, ia memiliki kesempatan seperti itu. Namun, kami menemukan sejumlah masalah yang harus dipertimbangkan ketika mengimplementasikan fungsi ini di werf.Catatan. Fitur ini tidak menyiratkan karya kolektor di dalam pod Kubernetes, seperti untuk melakukan ini, singkirkan ketergantungan pada server Docker lokal (di pod Kubernetes tidak ada akses ke server Docker lokal, karena proses itu sendiri sedang berjalan dalam wadah, dan werf tidak mendukung dan tidak akan mendukung bekerja dengan server Docker di jaringan). Dukungan untuk pekerjaan di Kubernetes akan diterapkan secara terpisah.Dukungan Resmi Tindakan GitHub (BARU)
- Versi: v1.1
- Tanggal: Maret
- Isu
Termasuk dokumentasi werf (bagian referensi dan panduan ), serta GitHub Action resmi untuk bekerja dengan werf.Selain itu, itu akan memungkinkan werf untuk bekerja pada pelari fana.Mekanisme interaksi pengguna dengan sistem CI akan didasarkan pada menempatkan label pada permintaan tarik untuk memulai tindakan tertentu untuk membangun / meluncurkan aplikasi.Pengembangan dan penyebaran aplikasi lokal dengan werf (↓)
- Versi: v1.1
- Tanggal:
Januari-Februari April - Isu
Tujuan utamanya adalah untuk mencapai konfigurasi tunggal terpadu untuk menyebarkan aplikasi baik secara lokal maupun dalam produksi, tanpa tindakan yang rumit, di luar kebiasaan.Werf juga memerlukan mode operasi di mana akan lebih mudah untuk mengedit kode aplikasi dan langsung menerima umpan balik dari aplikasi yang berfungsi untuk debugging.Algoritma pembersihan baru (BARU)
- Versi: v1.1
- Tanggal: April
- Isu
Dalam versi werf v1.1 saat ini, prosedur cleanuptidak menyediakan untuk membersihkan gambar untuk skema penandaan berbasis konten - gambar ini akan menumpuk.Juga, dalam versi werf saat ini (v1.0 dan v1.1), kebijakan pembersihan yang berbeda digunakan untuk gambar yang diterbitkan oleh skema penandaan: Git branch, Git tag, atau Git commit.Algoritme pembersihan gambar terpadu baru untuk semua skema penandaan ditemukan berdasarkan riwayat commit di Git:- Simpan tidak lebih dari N1 gambar yang terkait dengan N2 komit terakhir untuk masing-masing git HEAD (cabang dan tag).
- Simpan tidak lebih dari N1 gambar-tahapan yang terkait dengan N2 komit terakhir untuk masing-masing git HEAD (cabang dan tag).
- , - Kubernetes ( kube- namespace'; ).
- , , Helm-.
- , HEAD git (, HEAD ) Kubernetes Helm.
(↓)
Versi werf saat ini mengumpulkan gambar dan artefak yang dijelaskan werf.yamlsecara berurutan. Hal ini diperlukan untuk memparalelkan proses pemasangan tahapan independen gambar dan artefak, serta memberikan kesimpulan yang nyaman dan informatif.* Catatan: batas waktu digeser karena meningkatnya prioritas untuk mengimplementasikan perakitan terdistribusi, yang akan menambah lebih banyak fitur untuk penskalaan horizontal, serta penggunaan werf dengan Tindakan GitHub. Perakitan paralel adalah langkah optimasi berikutnya, memberikan skalabilitas vertikal saat merakit satu proyek.Beralih ke Helm 3 (↓)
- Versi: v1.2
- Tanggal:
Februari-Maret Mei *
Ini termasuk transisi ke basis kode Helm 3 yang baru dan cara yang terbukti dan nyaman untuk memigrasi instalasi yang ada.* Catatan: beralih ke Helm 3 tidak akan menambahkan fitur signifikan ke werf, karena semua fitur utama Helm 3 (penggabungan 3 arah dan kurangnya penggarap) sudah diterapkan di werf. Selain itu, werf memiliki fitur tambahan selain yang ditunjukkan. Namun, transisi ini tetap dalam rencana kami dan akan diimplementasikan.Jsonnet untuk deskripsi konfigurasi Kubernetes (↓)
- Versi: v1.2
- Tanggal:
Januari-Februari April-Mei
Werf akan mendukung deskripsi konfigurasi untuk Kubernetes dalam format Jsonnet. Pada saat yang sama, werf akan tetap kompatibel dengan Helm dan dimungkinkan untuk memilih format deskripsi.Alasannya adalah kenyataan bahwa pola bahasa Go, menurut banyak orang, memiliki ambang masuk yang besar, dan kejelasan kode dari pola-pola ini juga menderita.Opsi lain untuk menerapkan sistem deskripsi konfigurasi Kubernetes (seperti Kustomize) juga dipertimbangkan.Bekerja di dalam Kubernetes (↓)
- Versi: v1.2
- Tanggal:
April- Mei-Juni
Tujuan: Untuk memastikan perakitan gambar dan pengiriman aplikasi menggunakan pelari di Kubernetes. Itu kumpulan gambar baru, publikasi mereka, pembersihan dan penyebaran dapat terjadi langsung dari pod Kubernetes.Untuk mewujudkan fitur ini, pertama-tama Anda perlu kemampuan untuk membuat gambar secara didistribusikan (lihat paragraf di atas) .Itu juga memerlukan dukungan untuk mode operasi build tanpa server Docker (mis., Build mirip Kaniko atau build in userspace).Werf akan mendukung pembangunan Kubernet tidak hanya dengan Dockerfile, tetapi juga dengan pembuat Stapelnya dengan penambahan ulang bertahap dan Ansible.Langkah menuju pengembangan sumber terbuka
Kami mencintai komunitas kami ( GitHub , Telegram ) dan kami ingin semakin banyak orang membantu membuat werf menjadi lebih baik, memahami ke arah mana kami bergerak, dan berpartisipasi dalam pengembangan.Baru-baru ini, diputuskan untuk beralih ke papan proyek GitHub untuk membuka alur kerja tim kami. Sekarang Anda dapat melihat rencana langsung, serta pekerjaan yang sedang berlangsung di bidang-bidang berikut:Banyak pekerjaan yang telah dilakukan dengan masalah:- Dihapus tidak relevan.
- Yang ada dikurangi menjadi satu format, cukup banyak detail dan detail.
- Menambahkan masalah baru dengan ide dan saran.
Cara mengaktifkan versi v1.1
Versi saat ini tersedia di saluran 1.1 ea ( rilis di saluran stabil dan rock-solid akan muncul saat mereka stabil, tetapi ea sendiri sudah cukup stabil untuk digunakan, karena melewati saluran alfa dan beta ). Ini diaktifkan melalui multiwerf dengan cara berikut:source $(multiwerf use 1.1 ea)
werf COMMAND ...
Kesimpulan
Arsitektur store stage yang baru dan kinerja kolektor yang dioptimalkan untuk kolektor Stapel dan Dockerfile membuka kemungkinan penerapan rakitan terdistribusi dan paralel di werf. Fitur-fitur ini akan segera muncul dalam rilis yang sama v1.1 dan akan tersedia secara otomatis melalui mekanisme pembaruan otomatis (untuk pengguna multi- user ).Dalam rilis ini, strategi penandaan berbasis konten ditambahkan , yang menjadi strategi default. Log juga didesain ulang perintah-perintah dasar: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.Langkah penting berikutnya adalah menambah majelis yang didistribusikan. Rakitan terdistribusi sejak v1.0 telah menjadi prioritas yang lebih tinggi daripada rakitan paralel, karena mereka menambah nilai werf: penskalaan vertikal kolektor dan dukungan untuk kolektor sementara di berbagai sistem CI / CD, serta kemampuan untuk membuat dukungan resmi untuk Tindakan GitHub. Oleh karena itu, waktu pelaksanaan majelis paralel telah bergeser. Namun, kami berupaya untuk mewujudkan kedua kemungkinan dengan cepat.Ikuti beritanya! Dan jangan lupa mampir ke GitHub kami untuk membuat masalah, temukan yang sudah ada dan beri nilai tambah, buat PR, atau saksikan saja perkembangan proyek.PS
Baca juga di blog kami: