🥇Rilis Werf 1.1: peningkatan pada kolektor hari ini dan rencana untuk masa depan

wer adalah utilitas GitOps CLI open source kami untuk membangun dan mengirimkan aplikasi ke Kubernetes. Seperti yang dijanjikan, rilis versi v1.0 menandai dimulainya penambahan fitur baru pada werf dan merevisi pendekatan tradisional. Sekarang kami dengan bangga mempersembahkan rilis v1.1, yang merupakan langkah besar dalam pengembangan dan landasan untuk masa depan pengumpul werf. Versi saat ini tersedia di saluran 1.1 ea.

Rilis ini didasarkan pada arsitektur penyimpanan panggung baru dan optimalisasi kerja kedua kolektor (untuk Stapel dan Dockerfile). Arsitektur penyimpanan baru membuka kemungkinan penerapan rakitan terdistribusi dari beberapa host dan rakitan paralel pada host yang sama.

Optimalisasi pekerjaan meliputi menghilangkan perhitungan yang tidak diperlukan pada tahap penghitungan tanda tangan tahap dan mengubah mekanisme penghitungan file checksum menjadi lebih efisien. Pengoptimalan ini mengurangi waktu rata-rata pembangunan proyek menggunakan werf. Dan build idle, ketika semua tahapan ada di cache tahap-penyimpanan, sekarang sangat cepat. Umumnya, memulai ulang build akan memakan waktu kurang dari 1 detik! Hal ini juga berlaku pada tata cara verifikasi tahapan proses kerja tim. werf deploy и werf run.

Juga dalam rilis ini, strategi untuk menandai gambar berdasarkan konten muncul - penandaan berbasis konten, yang sekarang diaktifkan secara default dan satu-satunya yang direkomendasikan.

Mari kita lihat lebih dekat inovasi utama di werf v1.1, dan sekaligus memberi tahu Anda tentang rencana untuk masa depan.

Apa yang berubah di werf v1.1?

Format penamaan tahapan baru dan algoritma untuk memilih tahapan dari cache

Aturan pembuatan nama panggung baru. Sekarang setiap tahap pembangunan menghasilkan nama tahap unik, yang terdiri dari 2 bagian: tanda tangan (seperti di v1.0) ditambah pengidentifikasi sementara yang unik.

Misalnya, nama gambar panggung lengkap mungkin terlihat seperti ini:

werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835

...atau secara umum:

werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC

Berikut:

SIGNATURE adalah tanda tangan panggung, yang mewakili pengidentifikasi konten panggung dan bergantung pada riwayat pengeditan di Git yang mengarah ke konten ini;
TIMESTAMP_MILLISEC adalah pengidentifikasi gambar unik yang dijamin yang dihasilkan pada saat gambar baru dibuat.

Algoritme untuk memilih tahapan dari cache didasarkan pada pemeriksaan hubungan komitmen Git:

Werf menghitung tanda tangan pada tahapan tertentu.
В tahap-penyimpanan Mungkin ada beberapa tahapan untuk tanda tangan tertentu. Werf memilih semua tahapan yang cocok dengan tanda tangannya.
Jika tahap saat ini ditautkan ke Git (arsip git, tahap khusus dengan patch Git: install, beforeSetup, setup; atau git-latest-patch), lalu werf hanya memilih tahapan yang terkait dengan komit yang merupakan nenek moyang dari komit saat ini (yang merupakan nama build tersebut).
Dari sisa tahapan yang sesuai, satu dipilih - yang tertua berdasarkan tanggal pembuatan.

Panggung untuk cabang Git yang berbeda dapat memiliki tanda tangan yang sama. Tapi werf akan mencegah cache yang terkait dengan cabang berbeda digunakan di antara cabang-cabang ini, meskipun tanda tangannya cocok.

→ Dokumentasi.

Algoritma baru untuk membuat dan menyimpan tahapan dalam penyimpanan panggung

Jika, ketika memilih tahapan dari cache, werf tidak menemukan tahapan yang sesuai, maka proses perakitan tahapan baru dimulai.

Perhatikan bahwa beberapa proses (pada satu atau lebih host) dapat mulai membangun tahap yang sama pada waktu yang hampir bersamaan. Werf menggunakan algoritma pemblokiran optimis tahap-penyimpanan pada saat menyimpan gambar yang baru dikumpulkan tahap-penyimpanan. Dengan cara ini, ketika pembangunan tahap baru sudah siap, kami akan memblokirnya tahap-penyimpanan dan menyimpan gambar yang baru dikumpulkan di sana hanya jika gambar yang sesuai sudah tidak ada lagi di sana (berdasarkan tanda tangan dan parameter lainnya - lihat algoritme baru untuk memilih tahapan dari cache).

Gambar yang baru dirakit dijamin memiliki pengenal unik TIMESTAMP_MILLISEC (lihat format penamaan panggung baru). Dalam kasus di tahap-penyimpanan gambar yang cocok akan ditemukan, werf akan membuang gambar yang baru dikompilasi dan akan menggunakan gambar dari cache.

Dengan kata lain: proses pertama untuk menyelesaikan pembuatan gambar (yang tercepat) akan mendapatkan hak untuk menyimpannya dalam penyimpanan bertahap (dan kemudian gambar tunggal inilah yang akan digunakan untuk semua bangunan). Proses build yang lambat tidak akan pernah menghalangi proses yang lebih cepat untuk menyimpan hasil build pada tahap saat ini dan melanjutkan ke build berikutnya.

→ Dokumentasi.

Peningkatan kinerja pembuat Dockerfile

Saat ini, alur tahapan untuk gambar yang dibangun dari Dockerfile terdiri dari satu tahap - dockerfile. Saat menghitung tanda tangan, checksum file dihitung context, yang akan digunakan selama perakitan. Sebelum perbaikan ini, werf menelusuri semua file secara rekursif dan memperoleh checksum dengan menjumlahkan 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-pohon. Algoritme memperhitungkan catatan akun di .dockerignore dan melintasi pohon file secara rekursif hanya jika diperlukan. Dengan demikian, kita telah melepaskan diri dari pembacaan sistem file, dan ketergantungan algoritma pada ukurannya context tidak signifikan.

Algoritme juga memeriksa file yang tidak terlacak dan, jika perlu, memperhitungkannya dalam checksum.

Peningkatan kinerja saat mengimpor file

Versi werf v1.1 menggunakan server rsync saat mengimpor file dari artefak dan gambar. Sebelumnya, impor dilakukan dalam dua langkah menggunakan direktori mount dari sistem host.

Kinerja impor di macOS tidak lagi dibatasi oleh volume Docker, dan impor selesai dalam jangka waktu yang sama seperti Linux dan Windows.

Penandaan berbasis konten

Werf v1.1 mendukung apa yang disebut penandaan berdasarkan konten gambar - penandaan berbasis konten. Tag gambar Docker yang dihasilkan bergantung pada konten gambar tersebut.

Saat menjalankan perintah werf publish --tags-by-stages-signature или werf ci-env --tagging-strategy=stages-signature gambar yang diterbitkan dari apa yang disebut tanda tangan panggung gambar. Setiap gambar ditandai dengan tanda tangannya sendiri dari tahapan gambar ini, yang dihitung menurut aturan yang sama seperti tanda tangan biasa dari setiap tahap secara terpisah, tetapi merupakan pengidentifikasi umum gambar tersebut.

Tanda tangan tahapan gambar bergantung pada:

isi gambar ini;
sejarah perubahan Git yang menghasilkan konten ini.

Repositori Git selalu memiliki komit tiruan yang tidak mengubah konten file gambar. Misalnya, komit hanya dengan komentar atau komit gabungan, atau komit yang mengubah file-file di Git yang tidak akan diimpor ke dalam gambar.

Saat menggunakan penandaan berbasis konten, masalah restart pod aplikasi yang tidak perlu di Kubernetes karena perubahan nama gambar telah teratasi, meskipun konten gambar tidak berubah. Omong-omong, ini adalah salah satu alasan yang mencegah penyimpanan banyak layanan mikro dari satu aplikasi dalam satu repositori Git.

Selain itu, penandaan berbasis konten adalah metode penandaan yang lebih andal dibandingkan penandaan pada cabang Git, karena konten gambar yang dihasilkan tidak bergantung pada urutan eksekusi pipeline dalam sistem CI untuk merakit beberapa penerapan dari cabang yang sama.

Ini penting: mulai dari sekarang tahapan-tanda tangan - Apakah satu-satunya strategi pemberian tag yang direkomendasikan. Ini akan digunakan secara default dalam perintah werf ci-env (kecuali jika Anda secara eksplisit menentukan skema pemberian tag yang berbeda).

→ Dokumentasi. Publikasi terpisah juga akan dikhususkan untuk fitur ini. DIPERBARUI (3 April): Artikel dengan detail diterbitkan.

Tingkat pencatatan

Pengguna sekarang memiliki kesempatan untuk mengontrol output, mengatur tingkat logging dan bekerja dengan informasi debug. Opsi ditambahkan --log-quiet, --log-verbose, --log-debug.

Secara default, output berisi informasi minimum:

Saat menggunakan keluaran verbose (--log-verbose) Anda dapat melihat cara kerja werf:

Keluaran terperinci (--log-debug), selain informasi debug werf, juga berisi log perpustakaan yang digunakan. Misalnya, Anda dapat melihat bagaimana interaksi dengan Docker Registry terjadi, dan juga mencatat tempat-tempat yang menghabiskan banyak waktu:

Rencana selanjutnya

Peringatan! Opsi yang dijelaskan di bawah ini 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; tampilannya tidak memerlukan intervensi pengguna secara manual dalam konfigurasi yang ada.

Dukungan penuh untuk berbagai implementasi Docker Registry (BARU)

Versi: v1.1
Tanggal: Maret
Isu

Tujuannya adalah agar pengguna dapat menggunakan implementasi khusus tanpa batasan saat menggunakan werf.

Saat ini, kami telah mengidentifikasi serangkaian solusi berikut yang kami jamin dukungan penuhnya:

Default (perpustakaan/registrasi)*,
AWS ECR
Biru langit*,
Pusat Docker
GCR*,
Paket GitHub
Registri GitLab*,
Pelabuhan*,
Dermaga.

Solusi yang saat ini didukung penuh oleh werf ditandai dengan tanda bintang. Bagi yang lain ada dukungan, namun dengan keterbatasan.

Dua masalah utama dapat diidentifikasi:

Beberapa solusi tidak mendukung penghapusan tag menggunakan Docker Registry API, sehingga mencegah pengguna menggunakan pembersihan otomatis werf. Hal ini berlaku untuk Paket AWS ECR, Docker Hub, dan GitHub.
Beberapa solusi tidak mendukung apa yang disebut repositori bersarang (Docker Hub, Paket GitHub, dan Quay) atau mendukungnya, tetapi pengguna harus membuatnya secara manual menggunakan UI atau API (AWS ECR).

Kami akan menyelesaikan masalah ini dan masalah lainnya menggunakan API asli dari solusinya. Tugas ini juga mencakup mencakup seluruh siklus operasi werf dengan pengujian untuk masing-masing siklus.

Pembuatan gambar terdistribusi (↑)

Versi: v1.2 v1.1 (prioritas penerapan fitur ini telah ditingkatkan)
Tanggal: Maret-April Maret
Isu

Saat ini, werf v1.0 dan v1.1 hanya dapat digunakan pada satu host khusus untuk operasi pembuatan dan penerbitan image serta penerapan aplikasi ke Kubernetes.

Untuk membuka kemungkinan kerja werf yang terdistribusi, ketika pembangunan dan penerapan aplikasi di Kubernetes diluncurkan pada beberapa host yang sewenang-wenang dan host ini tidak menyimpan statusnya di antara build (pelari sementara), werf diharuskan untuk mengimplementasikan kemampuan untuk menggunakan Docker Registry sebagai penyimpanan panggung.

Sebelumnya, ketika proyek werf masih bernama dapp, memiliki peluang seperti itu. Namun, kami menemui sejumlah masalah yang perlu dipertimbangkan saat mengimplementasikan fungsi ini di werf.

Catatan. Fitur ini tidak mengharuskan kolektor untuk bekerja di dalam pod Kubernetes, karena Untuk melakukan ini, Anda perlu menghilangkan ketergantungan pada server Docker lokal (di pod Kubernetes tidak ada akses ke server Docker lokal, karena prosesnya sendiri berjalan dalam sebuah container, dan werf tidak dan tidak akan mendukung bekerja dengan server Docker melalui jaringan). Dukungan untuk menjalankan Kubernetes akan diterapkan secara terpisah.

Dukungan resmi untuk GitHub Actions (BARU)

Versi: v1.1
Tanggal: Maret
Isu

Termasuk dokumentasi werf (bagian referensi и membimbing), serta GitHub Action resmi untuk bekerja dengan werf.

Selain itu, ini akan memungkinkan werf untuk bekerja pada pelari fana.

Mekanisme interaksi pengguna dengan sistem CI akan didasarkan pada penempatan label pada permintaan tarik untuk memulai tindakan tertentu dalam membangun/meluncurkan aplikasi.

Pengembangan lokal dan penerapan aplikasi dengan werf (↓)

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

Tujuan utamanya adalah mencapai satu konfigurasi terpadu untuk menerapkan aplikasi baik secara lokal maupun dalam produksi, tanpa tindakan rumit, langsung dari kotaknya.

werf juga diharuskan memiliki mode operasi yang memudahkan untuk mengedit kode aplikasi dan langsung menerima umpan balik dari aplikasi yang sedang berjalan untuk debugging.

Algoritma pembersihan baru (BARU)

Versi: v1.1
Tanggal: April
Isu

Dalam versi werf v1.1 saat ini dalam prosedur cleanup Tidak ada ketentuan untuk membersihkan gambar untuk skema penandaan berbasis konten - gambar ini akan terakumulasi.

Selain itu, versi werf saat ini (v1.0 dan v1.1) menggunakan kebijakan pembersihan yang berbeda untuk gambar yang dipublikasikan di bawah skema penandaan: Cabang Git, tag Git, atau komitmen Git.

Algoritme baru untuk membersihkan gambar berdasarkan riwayat penerapan di Git, yang disatukan untuk semua skema penandaan, telah ditemukan:

Simpan tidak lebih dari N1 gambar yang terkait dengan N2 komitmen terbaru untuk setiap git HEAD (cabang dan tag).
Simpan tidak lebih dari N1 gambar tahap yang terkait dengan komitmen terbaru N2 untuk setiap git HEAD (cabang dan tag).
Simpan semua image yang digunakan dalam sumber daya klaster Kubernetes (semua konteks kube dari file konfigurasi dan namespace dipindai; Anda dapat membatasi perilaku ini dengan opsi khusus).
Simpan semua gambar yang digunakan dalam manifes konfigurasi sumber daya yang disimpan dalam rilis Helm.
Sebuah gambar dapat dihapus jika tidak dikaitkan dengan HEAD mana pun dari git (misalnya, karena HEAD yang terkait itu sendiri telah dihapus) dan tidak digunakan dalam manifes apa pun di cluster Kubernetes dan rilis Helm.

Pembuatan gambar paralel (↓)

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

Versi werf saat ini mengumpulkan gambar dan artefak yang dijelaskan di werf.yaml, secara berurutan. Penting untuk memparalelkan proses perakitan tahapan gambar dan artefak yang independen, serta memberikan keluaran yang nyaman dan informatif.

* Catatan: tenggat waktu telah diubah karena peningkatan prioritas untuk penerapan perakitan terdistribusi, yang akan menambah lebih banyak kemampuan penskalaan horizontal, serta penggunaan werf dengan GitHub Actions. Perakitan paralel adalah langkah pengoptimalan berikutnya, memberikan skalabilitas vertikal saat merakit satu proyek.

Transisi ke Helm 3 (↓)

Versi: v1.2
Tanggal: Februari-Maret Mei*

Termasuk migrasi ke basis kode baru helm 3 dan cara yang terbukti dan nyaman untuk memigrasikan instalasi yang ada.

*Catatan: beralih ke Helm 3 tidak akan menambah fitur signifikan pada werf, karena semua fitur utama Helm 3 (penggabungan 3 arah dan tanpa anakan) sudah diterapkan di werf. Apalagi werf punya fitur tambahan selain yang ditunjukkan. Namun transisi ini tetap dalam rencana kami dan akan dilaksanakan.

Jsonnet untuk menjelaskan 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 akan ada pilihan format deskripsi.

Alasannya adalah karena templat Go, menurut banyak orang, memiliki hambatan masuk yang tinggi, dan pemahaman kode templat ini juga buruk.

Kemungkinan untuk memperkenalkan sistem deskripsi konfigurasi Kubernetes lainnya (misalnya Kustomize) juga sedang dipertimbangkan.

Bekerja di dalam Kubernetes (↓)

Versi: v1.2
Tanggal: April-Mei Mei-Juni

Sasaran: Memastikan image dibuat dan aplikasi dikirimkan menggunakan runner di Kubernetes. Itu. Image baru dapat dibuat, dipublikasikan, dibersihkan, dan di-deploy langsung dari pod Kubernetes.

Untuk mengimplementasikan kemampuan ini, Anda harus mampu membuat gambar terdistribusi terlebih dahulu (lihat poin di atas).

Ini juga memerlukan dukungan untuk mode operasi pembuat tanpa server Docker (yaitu build mirip Kaniko atau build di ruang pengguna).

Werf akan mendukung pembangunan di Kubernetes tidak hanya dengan Dockerfile, tetapi juga dengan pembuat Stapel dengan pembangunan kembali bertahap dan Ansible.

Sebuah langkah menuju pembangunan terbuka

Kami mencintai komunitas kami (GitHub, Telegram) dan kami ingin semakin banyak orang yang membantu menjadikan kami lebih baik, memahami arah yang kami tuju, dan berpartisipasi dalam pembangunan.

Baru-baru ini diputuskan untuk beralih ke Papan proyek GitHub untuk mengungkapkan proses kerja tim kami. Sekarang Anda dapat melihat rencana jangka pendek, serta pekerjaan saat ini di bidang-bidang berikut:

Banyak pekerjaan telah dilakukan dengan masalah:

Menghapus yang tidak relevan.
Yang sudah ada dibawa ke dalam format tunggal, dengan jumlah detail dan detail yang memadai.
Masalah baru dengan ide dan saran telah ditambahkan.

Cara mengaktifkan versi v1.1

Versi saat ini tersedia di saluran 1.1 ea (di saluran stabil и sekeras batu rilis akan muncul saat stabilisasi terjadi ea sendiri sudah cukup stabil untuk digunakan, karena melewati saluran alfa и beta). Diaktifkan melalui multiwerf dengan cara berikut:

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

Kesimpulan

Arsitektur penyimpanan tahap baru dan optimalisasi pembangun untuk pembuat Stapel dan Dockerfile membuka kemungkinan penerapan pembangunan terdistribusi dan paralel di werf. Fitur-fitur ini akan segera muncul dalam rilis v1.1 yang sama dan akan tersedia secara otomatis melalui mekanisme pembaruan otomatis (untuk pengguna multiwerf).

Dalam rilis ini, strategi penandaan berdasarkan konten gambar telah ditambahkan - penandaan berbasis konten, yang telah menjadi strategi default. Log perintah utama juga telah dikerjakan ulang: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.

Langkah penting berikutnya adalah menambahkan rakitan terdistribusi. Build yang terdistribusi telah menjadi prioritas yang lebih tinggi dibandingkan build paralel sejak v1.0 karena build tersebut menambahkan nilai lebih pada werf: penskalaan vertikal pada builder dan dukungan untuk build ephemeral di berbagai sistem CI/CD, serta kemampuan untuk membuat dukungan resmi untuk GitHub Actions . Oleh karena itu, tenggat waktu pelaksanaan majelis paralel digeser. Namun, kami berupaya untuk mengimplementasikan kedua kemungkinan tersebut sesegera mungkin.

Ikuti beritanya! Dan jangan lupa kunjungi kami di GitHubuntuk membuat isu, mencari isu yang sudah ada dan menambahkan nilai plus, membuat PR, atau sekadar melihat perkembangan proyek.

rilis werf 1.1: peningkatan pada pembuat hari ini dan rencana untuk masa depan