🐷 ➖ 😆 Memperkenalkan werf 1.0 stable: apa yang harus dilakukan GitOps dengan status, dan rencana 🐓 👩🏼‍🏫 📳

werf adalah utilitas open source GitOps CLI untuk membangun dan mengirimkan aplikasi ke Kubernetes. werf mendukung merakit gambar aplikasi menggunakan Dockerfile atau kolektor bawaannya sendiri (berdasarkan sintaks YAML, dengan dukungan yang mungkin dan pembangunan kembali secara bertahap berdasarkan Git). Format konfigurasi yang kompatibel dengan helm digunakan untuk mengirimkan aplikasi. Kode aplikasi, konfigurasi gambar yang dikumpulkan, dan konfigurasi peluncuran aplikasi disimpan dalam satu repositori Git.

Rilis stabil yang ditunggu-tunggu 1.0 adalah versi dasar dari utilitas yang dilengkapi fungsi (nomor versi persis dari rilis stabil pertama adalah 1.0.6) . Dalam versi dasar, werf mendukung siklus penuh pengiriman dan pemeliharaan aplikasi. Ini termasuk merakit gambar aplikasi, menyebarkan ke Kubernetes, dan membersihkan gambar yang tidak digunakan.

Penting bahwa dalam versi 1.0, semua operasi pada satu proyek ( build , deploy , cleanup ) harus dilakukan dari satu host. Ini berarti bahwa pekerja tetap harus digunakan dalam sistem CI. Pada saat yang sama, tidak ada batasan pada paralelisme tugas: tidak sepenuhnya menyelesaikan masalah ini. Anda juga dapat mendistribusikan berbagai proyek di antara pekerja yang berbeda.

Dalam artikel yang didedikasikan untuk rilis ini, kami akan melihat lebih dekat apa yang disediakan dan tidak disediakan versi ini, serta rencana kami untuk versi yang akan datang. Tetapi kita akan mulai dengan memahami pengertian istilah “GitOps” dan peran werf dalam proses integrasi berkelanjutan dan pengiriman aplikasi (CI / CD).

Mengapa werf adalah GitOps

Jadi apa yang kita maksud dengan GitOps dan area apa yang tidak tercakup?

Istilah "GitOps" diciptakan oleh Weaveworks sekitar 2,5 tahun yang lalu, dan kami baru-baru ini menerjemahkan sebuah artikel dari penulisnya yang mengungkapkan inti dari fenomena baru ini untuk blog. Dalam pemahaman kami, ide utama dan makna utama GitOps adalah bahwa Git adalah "sumber tunggal kebenaran" . Toko Git:

kode aplikasi
semua dependensi;
informasi tentang cara mengumpulkan kontainer;
informasi tentang cara menyebar ke Kubernetes;
dan lainnya

Dan kemudian ada "sesuatu" yang membuat kenyataan berubah sejalan dengan perubahan Git . Pendekatan ini dapat diimplementasikan tidak hanya dengan menginstal beberapa operator di Kubernetes yang memonitor Git, tetapi juga menggunakan utilitas konsol yang dapat dipanggil dari sistem CI apa pun. Selain itu, dari sudut pandang kami, pendekatan dengan utilitas CLI tidak memaksakan pembatasan yang tidak perlu: kita dapat melakukan CI dengan alat apa pun dan dengan sejumlah nuansa, memanggil utilitas CLI yang menyinkronkan "kenyataan" (yaitu Kubernetes) dengan keadaan Git .

werf menyediakan antarmuka CLI tingkat tinggi dengan perintah-perintah dasar untuk membangun dan menerbitkan gambar, mengirimkan aplikasi dan membersihkan gambar: werf build-and-publish , werf deploy , werf dismiss , werf cleanup . Diasumsikan bahwa perintah yang sangat mendasar ini tertanam dalam sistem CI tertentu dan menyediakan sinkronisasi yang diperlukan dengan kenyataan. Selain itu, werf juga menyediakan antarmuka CLI tingkat rendah untuk mengelola berbagai subsistem - lihat perintah manajemen tingkat rendah dalam dokumentasi.

Tidak masalah apakah CI / CD bawaan akan bekerja sesuai dengan model dorong atau tarik (baca lebih lanjut tentang mereka di sini ) , karena werf dapat dimasukkan ke dalam model apa pun . Pada saat yang sama, werf menutup masalah seperti bekerja dengan utilitas tingkat rendah yang terpisah seperti git , docker dan kubernetes api-server, menjadi "bagian yang hilang" untuk mengkonfigurasi aplikasi CI / CD terpadu.

Apa itu werf 1.0 stable

1. Perakitan, publikasi, dan pembersihan gambar

Jika aplikasi Anda membutuhkan pembuatan gambar Docker, maka menggunakan werf 1.0 Anda dapat:

jelaskan aturan untuk merakit gambar (Anda dapat memiliki beberapa) dalam satu konfigurasi werf.yaml ;
Kumpulkan gambar dan terbitkan ke Docker Registry
Bersihkan Docker Registry secara berkala untuk kebijakan khusus.

werf mendukung dua cara untuk menggambarkan perakitan : menghubungkan werf.yaml Dockerfiles yang ada dan instruksi untuk kolektor Stapel . Membangun dengan Stapel memiliki kelebihan: membangun kembali secara bertahap lebih cepat saat mengubah kode aplikasi di Git, menggunakan sintaks yang mungkin untuk perakitan, dan lainnya. Anda dapat mempelajari lebih lanjut tentang kolektor dan sintaks ini dalam dokumentasi , dan contoh penggunaannya disajikan dalam manual .

Skema yang berbeda untuk penandaan / pembuatan versi gambar yang dikumpulkan tersedia dengan mengacu pada komitmen Git, cabang dan tag.

Merakit gambar adalah tahap opsional penyebaran aplikasi dan dapat dilewati jika tidak ada gambar rakitan Anda sendiri.

2. Penyimpanan panggung hanya pada satu host

werf memperkenalkan konsep penyimpanan tahap. Perintah werf utama menggunakan penyimpanan panggung sebagai berikut:

Simpan hasil perakitan - Gambar Docker di toko panggung
menggunakan gambar dari toko panggung sebagai cache untuk membangun kembali dan untuk mengumpulkan gambar baru;
menggunakan repositori untuk mendapatkan informasi tentang gambar yang dikumpulkan untuk digunakan lebih lanjut (misalnya, ketika mengirimkan aplikasi ke Kubernetes).

Saat menggunakan satu aplikasi, penyimpanan satu tahap harus digunakan untuk semua tim (perakitan, publikasi, pembersihan gambar, penerapan aplikasi).

Dalam versi 1.0, hanya penyimpanan host lokal yang dapat bertindak sebagai penyimpanan stage (parameter yang sesuai untuk perintah adalah: --stages-storage=:local ). Saat menggunakan :local tahapan :local disimpan pada disk. Konsekuensi dari ini: werf 1.0 hanya dapat digunakan pada satu host untuk mengatur penyebaran aplikasi tunggal . Tuan rumah ini harus menyimpan data antara peluncuran perintah agar werf berfungsi dengan benar.

Dalam versi 1.0, tidak ada dukungan untuk menyimpan tahapan dalam penyimpanan eksternal, yang dengannya Anda dapat mengatur unit terdistribusi. Namun, fungsi seperti itu akan muncul di versi werf yang akan datang (lihat di bawah untuk lebih jelasnya) .

3. Luncurkan aplikasi dan periksa ketersediaan

Untuk menjalankan aplikasi, pengguna menjelaskan bagan dalam format yang kompatibel dengan Helm: seperangkat manifes Kubernet dan parameter templat.

werf meluncurkan aplikasi di Kubernetes dan memberikan jaminan bahwa itu dimulai dan berfungsi sebelum menyelesaikan proses peluncuran aplikasi. Ini termasuk output dari log komponen dan respons instan terhadap kesalahan peluncuran ketika terjadi kesalahan - perintah peluncuran akan turun dengan kode yang tidak nol. Jadi, ketika menggunakan werf rollout di CI / CD, kami mendapatkan umpan balik yang memadai dari perangkat lunak : aplikasi diunduh atau tidak, dan ada cukup informasi untuk debug dan memperbaiki masalah (tanpa harus menjalankan utilitas lain untuk menemukan masalah seperti kubectl ).

werf sepenuhnya kompatibel dengan instalasi Helm 2 yang ada, tetapi werf memiliki beberapa keunggulan di atasnya. Misalnya, sebagai mekanisme untuk memperbarui sumber daya, Kubernetes menggunakan tambalan 3-way-merge , dan ada juga kemungkinan menerima umpan balik ketika aplikasi dikirim ke cluster. Daftar lengkap perbedaan dijelaskan di halaman ini .

4. Hubungan gambar yang dikumpulkan dengan proses pengiriman aplikasi

werf mengintegrasikan gambar yang dikumpulkan ke dalam sistem tunggal, proses penandaan dan versi mereka dengan proses pengiriman aplikasi ke Kubernetes. Gambar yang dikumpulkan oleh werf dapat digunakan dalam templat deskripsi sumber daya Kubernetes.

Karena fungsi-fungsi ini kita dapat mengatakan bahwa werf menyediakan antarmuka tingkat yang lebih tinggi daripada Helm, Docker dan pembangun dan utilitas lain untuk digunakan secara terpisah. Antarmuka ini memungkinkan Anda untuk hanya mengintegrasikan werf ke sistem CI / CD yang ada dan tidak memecahkan masalah menggabungkan semua komponen yang digunakan - ia menangani tugas ini.

5. Integrasi dengan sistem CI / CD yang ada

Dalam versi 1.0, integrasi otomatis hanya tersedia dengan sistem GitLab CI . Untuk melakukan ini, perintah werf ci-env disediakan. Ini menerima informasi yang diperlukan dari sistem CI / CD dan secara otomatis mengkonfigurasi werf untuk bekerja dengan benar di lingkungan CI.

Anda dapat membaca lebih lanjut tentang cara integrasi dengan sistem CI / CD apa saja bekerja dalam manual ( tinjau , spesifik GitLab CI , integrasi dengan sistem lain ).

6. Pengembangan lintas platform untuk Linux, Windows dan macOS

werf 1.0 adalah file biner yang terhubung secara statis yang bekerja secara independen dengan rilis Docker dan Helm. Ketergantungan eksternal pada sistem host:

Daemon Docker Lokal
utilitas git.

werf dapat berjalan di salah satu sistem operasi dan lingkungan GNU / Linux, Windows, atau macOS. Selain itu, hasil perakitan akan sama terlepas dari sistem yang digunakan: tanda tangan yang sama dari tahap cache, pengisian tahap yang sama, terlepas dari sistem tempat tahap ini dikumpulkan. Perubahan dalam konfigurasi untuk bekerja di sistem yang berbeda juga tidak diperlukan.

Jadi, werf 1.0 menyediakan alat lintas platform untuk membangun dan mengirimkan aplikasi ke Kubernetes.

Perlu juga dicatat di sini bahwa werf mengumpulkan gambar Docker standar untuk bekerja di lingkungan Linux, tetapi wadah Windows tidak didukung dalam versi 1.0.

7. Meliputi fungsionalitas dengan tes

Saat ini 60% kode werf dicakup oleh tes integrasi e2e dan tes unit.

werf diuji pada semua OS yang didukung (Linux, Windows dan macOS) menggunakan GitHub Actions untuk mengatur peluncuran mereka. Beberapa detail pengujian juga tersedia pada Kode Iklim .

8. Versi werf

Saat ini, dengan rilis versi 1.0, sekitar 700 rilis telah dibuat dalam proyek ini.

werf menggunakan sistem rilis canggih dengan saluran stabilitas: alpha , beta , ea (akses awal) , stabil dan rock-solid . Posting ini waktunya bertepatan dengan rilis versi pertama 1.0 di saluran stabil . Perubahan tidak stabil pada versi pertama kali melalui rantai saluran dan akhirnya berakhir di rock-solid . Rilis sering dilakukan (kadang-kadang beberapa kali sehari) dan perubahan disampaikan terus menerus dalam "porsi kecil."

Saluran stabilitas dan banyak rilis sering memungkinkan Anda untuk mendapatkan umpan balik terus menerus tentang perubahan baru, kemampuan untuk dengan cepat mengembalikannya dan secara umum memastikan stabilitas tinggi dari perangkat lunak dan pada saat yang sama kecepatan pengembangan yang dapat diterima.

Poin penting adalah bahwa ketika beralih di antara versi 1.0-> 1.1, 1.1-> 1.2, perubahan werf dimungkinkan yang memerlukan intervensi manual oleh pengguna (ini bisa berupa skrip migrasi atau hanya instruksi untuk eksekusi manual yang dijelaskan dalam rilis). Memperbarui versi di dalam 1.0 (1.0.1, 1.0.2, ... 1.0.6-alpha.1, 1.0.6-beta.2, dll.) Memastikan bahwa perubahan manual tersebut tidak diperlukan.

Anda dapat membaca lebih lanjut tentang janji kompatibilitas ke belakang di sini .

Rencana selanjutnya

Berikut tampilan bidang kerja utama untuk versi yang akan datang dan perkiraan persyaratan untuk penerapannya:

1. Pengembangan dan penyebaran aplikasi lokal dengan werf

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.

Versi 1.1, Januari-Februari 2020

2. Penandaan berbasis konten

Memberi tag pada gambar saat dipublikasikan, hanya berdasarkan pada konten gambar ini. Tidak seperti mode dengan pengikatan pada komitmen Git, mode ini akan sepenuhnya menyingkirkan pembangunan kembali yang tidak perlu. Git-commit-id bukan pengidentifikasi universal untuk konten worktree (meskipun tergantung pada itu).

Dalam kasus di mana kode aplikasi tidak berubah, tetapi komit baru telah dibuat, mode penandaan saat ini untuk Git akan membuat gambar dengan nama baru ketika diterbitkan. Ini juga akan memerlukan pengembalian sumber daya menggunakan gambar ini di Kubernetes. Pada saat yang sama, isi gambar itu sendiri tidak berubah.

Untuk mengatasi masalah ini, werf akan memperkenalkan jenis penandaan baru berdasarkan perhitungan checksum konten aplikasi - penandaan berbasis konten .

Versi 1.1, Februari-Maret 2020

3. Transisi ke Helm 3

Ini termasuk transisi ke basis kode Helm 3 yang baru dan cara yang terbukti dan nyaman untuk memigrasi instalasi yang ada.

Versi 1.1, Februari-Maret 2020

4. Perakitan gambar paralel

Saat ini, werf 1.0 mengumpulkan semua tahapan gambar dan artefak yang dideklarasikan dalam werf.yaml secara berurutan. Membutuhkan kemampuan untuk memparalelkan proses perakitan tahap.

Versi: 1.1, Januari-Februari 2020

5. Perakitan gambar yang didistribusikan

Saat ini, werf 1.0 hanya dapat digunakan pada satu host khusus (lihat poin di atas tentang penyimpanan stage hanya pada satu host) .

Untuk membuka kemungkinan rakitan terdistribusi, ketika rakitan diluncurkan pada beberapa host dan host ini tidak mempertahankan statusnya di antara rakitan (pelari sementara), werf diminta untuk mengimplementasikan kemungkinan menggunakan Docker Registry sebagai repositori panggung.

Sebelumnya, ketika proyek werf juga disebut dapp, ia memiliki kesempatan seperti itu. Namun, kami menemukan sejumlah masalah yang harus dipertimbangkan ketika mengimplementasikan fungsi ini di werf.

Versi 1.2: Maret-April 2020

6. Jsonnet untuk menggambarkan konfigurasi Kubernetes

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 fakta bahwa templat bahasa Go, menurut banyak orang, memiliki ambang masuk yang besar, dan kejelasan kode templat ini juga menderita.

Opsi lain untuk menerapkan sistem deskripsi konfigurasi Kubernetes (seperti Kustomize) juga dipertimbangkan.

Versi 1.1: Januari-Februari 2020

7. Bekerja di dalam Kubernetes

Tujuan: Untuk memastikan perakitan gambar dan pengiriman aplikasi menggunakan pelari di Kubernetes. Yaitu kumpulan gambar baru, publikasi mereka, pembersihan dan penyebaran dapat terjadi langsung dari pod Kubernetes.

Untuk mewujudkan fitur ini, pertama-tama Anda perlu kemampuan untuk mendistribusikan gambar secara terdistribusi (lihat paragraf di atas) .

Ini juga memerlukan dukungan untuk mode operasi build tanpa daemon Docker (mis., Build seperti Kaniko atau build in userspace ).

werf akan mendukung build Kubernet tidak hanya dengan Dockerfile, tetapi juga dengan builder Stapel-nya dengan pembangunan kembali bertahap.

Versi 1.2: April-Mei 2020

8. Lainnya

Juga direncanakan:

Peningkatan versi yang dimungkinkan dan kemampuan untuk menggunakan berbagai versi Ansible;
mendukung peran yang memungkinkan;
dukungan untuk tahapan perakitan acak di Stapel (saat ini tidak mendukung serangkaian statis tahapan: beforeInstall install , install , beforeSetup , setup );
sintaks werf.yaml ditingkatkan, beralih ke configVersion: 2 (terkait, antara lain, dengan dua poin sebelumnya), dukungan untuk spesifikasi OpenAPI;
Dukungan Git LFS di Stapel untuk menyimpan file besar di Git;
peningkatan mekanisme pembersihan gambar (cacat non-kritis dalam versi saat ini dikaitkan dengan gambar yang tidak dideklarasikan dalam konfigurasi werf.yaml di cabang utama utama - gambar ini akan dihapus dengan pembersihan berkala);
pekerjaan yang lebih benar dengan ruang nama Kubernet bersama, ketika beberapa aplikasi dikerahkan dalam satu ruang nama;
rollback otomatis aplikasi ke versi kerja terbaru jika penyebaran tidak berhasil.

Total

Saya akan singkat dalam meringkas. Kami adalah:

berjalan jauh ke munculnya versi 1.0;
memperhitungkan banyak pengalaman nyata;
Kami hadir untuk menggunakan utilitas yang terbukti dengan fungsi yang stabil, diverifikasi oleh puluhan ribu peluncuran.

Rilis versi 1.0 menandai dimulainya fase pengembangan baru werf, di mana fitur fundamental baru akan ditambahkan. Ikuti beritanya! Dan juga bergabung dengan saluran terg wer__ru , di mana kehidupan baik pengembang langsung werf, dan insinyur kami, dan pengguna utilitas di luar perusahaan Flant berpartisipasi.

Memperkenalkan werf 1.0 stable: apa yang harus dilakukan GitOps dengan status, dan rencana