Lebih baik terlambat daripada tidak sama sekali. Atau bagaimana kami hampir membuat kesalahan serius dengan tidak memiliki dukungan untuk Dockerfile biasa untuk membuat image aplikasi.
Kita akan membicarakannya — Utilitas GitOps yang terintegrasi dengan sistem CI/CD apa pun dan menyediakan pengelolaan seluruh siklus hidup aplikasi, memungkinkan:
- mengumpulkan dan mempublikasikan gambar,
- menyebarkan aplikasi di Kubernetes,
- hapus gambar yang tidak digunakan menggunakan kebijakan khusus.
Filosofi proyek ini adalah mengumpulkan alat tingkat rendah ke dalam satu sistem terpadu yang memberi para insinyur DevOps kendali atas aplikasi. Jika memungkinkan, utilitas yang ada (seperti Helm dan Docker) harus digunakan. Jika tidak ada solusi untuk suatu masalah, kami dapat menciptakan dan mendukung segala sesuatu yang diperlukan untuk itu.
Latar Belakang: kolektor gambar Anda sendiri
Inilah yang terjadi dengan pengumpul gambar di werf: Dockerfile biasa tidak cukup bagi kami. Jika Anda melihat sekilas sejarah proyek, masalah ini sudah muncul di versi pertama werf (saat itu masih ).
Saat membuat alat untuk membangun aplikasi ke dalam image Docker, kami segera menyadari bahwa Dockerfile tidak cocok bagi kami untuk beberapa tugas yang sangat spesifik:
- Kebutuhan untuk membangun aplikasi web kecil yang khas sesuai dengan skema standar berikut:
- menginstal dependensi aplikasi di seluruh sistem,
- menginstal bundel perpustakaan ketergantungan aplikasi,
- mengumpulkan aset,
- dan yang terpenting, perbarui kode pada gambar dengan cepat dan efisien.
- Ketika perubahan dilakukan pada file proyek, pembuat harus segera membuat lapisan baru dengan menerapkan tambalan pada file yang diubah.
- Jika file tertentu telah berubah, maka perlu untuk membangun kembali tahap dependen yang sesuai.
Saat ini kolektor kami memiliki banyak kemungkinan lain, tetapi ini adalah keinginan dan dorongan awal.
Secara umum, tanpa berpikir dua kali, kami mempersenjatai diri dengan bahasa pemrograman yang kami gunakan (Lihat di bawah) dan mulai menerapkannya DSL sendiri! Sesuai dengan tujuannya, dimaksudkan untuk menggambarkan proses perakitan secara bertahap dan menentukan ketergantungan tahapan tersebut pada file. Dan melengkapinya kolektor sendiri, yang mengubah DSL menjadi tujuan akhir - gambar yang dirangkai. Pada awalnya DSL ada di Ruby, tetapi sebagai — konfigurasi kolektor kami mulai dijelaskan dalam file YAML.
Konfigurasi lama untuk dapp di Ruby
Konfigurasi saat ini untuk werf di YAML
Mekanisme kolektor juga berubah seiring berjalannya waktu. Pada awalnya, kami hanya membuat Dockerfile sementara dengan cepat dari konfigurasi kami, lalu kami mulai menjalankan instruksi perakitan di container sementara dan melakukan commit.
NB: Saat ini, kolektor kami, yang bekerja dengan konfigurasinya sendiri (di YAML) dan disebut kolektor Stapel, telah berkembang menjadi alat yang cukup kuat. Penjelasan rincinya memerlukan artikel terpisah, dan rincian dasar dapat ditemukan di .
Kesadaran akan masalahnya
Namun kami menyadari, dan tidak segera, bahwa kami telah melakukan satu kesalahan: kami tidak menambah kemampuan membangun gambar melalui Dockerfile standar dan mengintegrasikannya ke dalam infrastruktur manajemen aplikasi end-to-end yang sama (yaitu mengumpulkan gambar, menerapkan, dan membersihkannya). Bagaimana mungkin membuat alat untuk diterapkan di Kubernetes dan tidak mengimplementasikan dukungan Dockerfile, mis. cara standar untuk mendeskripsikan gambar untuk sebagian besar proyek?..
Daripada menjawab pertanyaan ini, kami menawarkan solusi. Bagaimana jika Anda sudah memiliki Dockerfile (atau sekumpulan Dockerfiles) dan ingin menggunakan werf?
NB: Ngomong-ngomong, kenapa kamu malah ingin menggunakan werf? Fitur utamanya adalah sebagai berikut:
- siklus manajemen aplikasi penuh termasuk pembersihan gambar;
- kemampuan untuk mengelola perakitan beberapa gambar sekaligus dari satu konfigurasi;
- Peningkatan proses penerapan untuk bagan yang kompatibel dengan Helm.
Daftar lebih lengkapnya dapat dilihat di .
Jadi, jika sebelumnya kami menawarkan untuk menulis ulang Dockerfile di konfigurasi kami, sekarang kami akan dengan senang hati mengatakan: “Biarkan kami membangun Dockerfiles Anda!”
Bagaimana cara menggunakannya?
Implementasi penuh dari fitur ini muncul di rilis . Prinsip umumnya sederhana: pengguna menentukan jalur ke Dockerfile yang ada di konfigurasi werf, dan kemudian menjalankan perintah werf build... dan itu saja - werf akan merakit gambarnya. Mari kita lihat contoh abstrak.
Mari kita umumkan yang berikutnya Dockerfile di root proyek:
FROM ubuntu:18.04
RUN echo Building ...
Dan kami akan mengumumkannya werf.yamlyang menggunakan ini Dockerfile:
configVersion: 1
project: dockerfile-example
---
image: ~
dockerfile: ./Dockerfile
Semua! Kiri Lari werf build:
Selain itu, Anda dapat mendeklarasikan hal berikut werf.yaml untuk membuat beberapa image dari Dockerfile yang berbeda sekaligus:
configVersion: 1
project: dockerfile-example
---
image: backend
dockerfile: ./dockerfiles/Dockerfile-backend
---
image: frontend
dockerfile: ./dockerfiles/Dockerfile-frontend
Terakhir, ini juga mendukung penerusan parameter build tambahan, seperti --build-arg и --add-host - melalui konfigurasi werf. Penjelasan lengkap tentang konfigurasi image Dockerfile tersedia di .
Bagaimana cara kerjanya?
Selama proses pembangunan, cache standar lapisan lokal di Docker berfungsi. Namun, yang penting adalah werf itu juga mengintegrasikan konfigurasi Dockerfile ke dalam infrastrukturnya. Apa artinya ini?
- Setiap image yang dibangun dari Dockerfile terdiri dari satu tahap yang disebut
dockerfile(Anda dapat membaca lebih lanjut tentang tahapan apa saja yang ada di werf ). - Untuk panggung
dockerfilewerf menghitung tanda tangan yang bergantung pada konten konfigurasi Dockerfile. Ketika konfigurasi Dockerfile berubah, tanda tangan panggung berubahdockerfiledan werf memulai pembangunan kembali tahap ini dengan konfigurasi Dockerfile baru. Jika tanda tangan tidak berubah, maka werf mengambil gambar dari cache (detail lebih lanjut tentang penggunaan tanda tangan di werf dijelaskan di ). - Selanjutnya, gambar yang dikumpulkan dapat dipublikasikan dengan perintah
werf publish(Atauwerf build-and-publish) dan menggunakannya untuk penerapan ke Kubernetes. Gambar yang dipublikasikan ke Docker Registry akan dibersihkan menggunakan alat pembersihan werf standar, yaitu. Gambar lama (lebih lama dari N hari), gambar yang terkait dengan cabang Git yang tidak ada, dan kebijakan lainnya akan dibersihkan secara otomatis.
Detail lebih lanjut tentang poin-poin yang dijelaskan di sini dapat ditemukan di dokumentasi:
- ;
- ;
- .
Catatan dan tindakan pencegahan
1. URL eksternal tidak didukung di ADD
Saat ini tidak didukung untuk menggunakan URL eksternal dalam arahan ADD. Werf tidak akan memulai pembangunan kembali ketika sumber daya di URL yang ditentukan berubah. Kami berencana untuk segera menambahkan fitur ini.
2. Anda tidak dapat menambahkan .git ke gambar
Secara umum, menambahkan direktori .git pada gambar - praktik buruk yang keji dan inilah alasannya:
- Jika
.gittetap pada gambar akhir, ini melanggar prinsip : Karena gambar akhir harus ditautkan ke satu komit, hal itu tidak dapat dilakukangit checkoutkomitmen sewenang-wenang. -
.gitmeningkatkan ukuran gambar (repositori bisa berukuran besar karena fakta bahwa file besar pernah ditambahkan ke dalamnya dan kemudian dihapus). Ukuran pohon kerja yang dikaitkan hanya dengan penerapan tertentu tidak akan bergantung pada riwayat operasi di Git. Dalam hal ini, penambahan dan penghapusan selanjutnya.gitdari gambar akhir tidak akan berfungsi: gambar masih akan memperoleh lapisan tambahan - beginilah cara kerja Docker. - Docker dapat memulai pembangunan kembali yang tidak perlu, meskipun komit yang sama sedang dibuat, tetapi dari pohon kerja yang berbeda. Misalnya, GitLab membuat direktori kloning terpisah di
/home/gitlab-runner/builds/HASH/[0-N]/yourprojectketika perakitan paralel diaktifkan. Perakitan ulang tambahan akan disebabkan oleh fakta bahwa direktori tersebut.gitberbeda dalam versi kloning berbeda dari repositori yang sama, meskipun komit yang sama dibuat.
Poin terakhir juga memiliki konsekuensi ketika menggunakan werf. Werf memerlukan cache yang dibangun untuk ada saat menjalankan beberapa perintah (mis. werf deploy). Saat perintah ini dijalankan, werf menghitung tanda tangan panggung untuk gambar yang ditentukan werf.yaml, dan mereka harus berada di cache perakitan - jika tidak, perintah tidak akan dapat terus bekerja. Kalau tanda tangan panggung tergantung isinya .git, maka kita mendapatkan cache yang tidak stabil terhadap perubahan file yang tidak relevan, dan werf tidak akan bisa memaafkan kelalaian seperti itu (untuk lebih jelasnya, lihat ).
Secara umum, hanya menambahkan file tertentu yang diperlukan melalui instruksi ADD dalam hal apapun meningkatkan efisiensi dan keandalan tulisan Dockerfile, dan juga meningkatkan stabilitas cache yang dikumpulkan untuk ini Dockerfile, untuk perubahan yang tidak relevan di Git.
Total
Jalur awal kami dalam menulis pembuat kami sendiri untuk kebutuhan spesifik sangatlah sulit, jujur, dan lugas: alih-alih menggunakan kruk di atas Dockerfile standar, kami menulis solusi kami dengan sintaksis khusus. Dan ini memiliki kelebihan: kolektor Stapel melakukan tugasnya dengan sempurna.
Namun, dalam proses penulisan pembuat kami sendiri, kami kehilangan dukungan untuk Dockerfiles yang ada. Cacat ini sekarang telah diperbaiki, dan di masa depan kami berencana untuk mengembangkan dukungan Dockerfile bersama dengan pembuat Stapel khusus kami untuk perakitan terdistribusi dan untuk perakitan menggunakan Kubernetes (yaitu perakitan pada runner di dalam Kubernetes, seperti yang dilakukan di kaniko).
Jadi, jika Anda tiba-tiba memiliki beberapa Dockerfile tergeletak di sekitar... coba !
PS Daftar dokumentasi tentang topik tersebut
- ;
- ;
- ;
- ;
- ;
- ;
- .
Baca juga di blog kami: “'.
Sumber: www.habr.com