🥇Anda kini boleh membina imej Docker dalam werf menggunakan fail Docker biasa

Lebih baik lewat daripada tidak pernah. Atau bagaimana kami hampir membuat kesilapan yang serius dengan tidak mempunyai sokongan untuk Dockerfiles biasa untuk membina imej aplikasi.

Kita akan bercakap tentang werf — Utiliti GitOps yang berintegrasi dengan mana-mana sistem CI/CD dan menyediakan pengurusan keseluruhan kitaran hayat aplikasi, membenarkan:

mengumpul dan menerbitkan imej,
menggunakan aplikasi dalam Kubernetes,
padamkan imej yang tidak digunakan menggunakan dasar khas.

Falsafah projek ini adalah untuk mengumpul alatan peringkat rendah ke dalam satu sistem bersatu yang memberikan jurutera DevOps kawalan ke atas aplikasi. Jika boleh, utiliti sedia ada (seperti Helm dan Docker) harus digunakan. Jika tiada penyelesaian kepada masalah, kami boleh mencipta dan menyokong semua yang diperlukan untuk ini.

Latar belakang: pengumpul imej anda sendiri

Inilah yang berlaku dengan pengumpul imej dalam werf: Dockerfile biasa tidak mencukupi untuk kami. Jika anda melihat dengan cepat sejarah projek, masalah ini telah pun muncul dalam versi pertama werf (kemudian masih dikenali sebagai dapp).

Semasa mencipta alat untuk membina aplikasi ke dalam imej Docker, kami dengan cepat menyedari bahawa Dockerfile tidak sesuai untuk kami untuk beberapa tugas yang sangat khusus:

Keperluan untuk membina aplikasi web kecil biasa mengikut skema standard berikut:
- pasang kebergantungan aplikasi seluruh sistem,
- pasang sekumpulan perpustakaan kebergantungan aplikasi,
- mengumpul aset,
- dan yang paling penting, kemas kini kod dalam imej dengan cepat dan cekap.
Apabila perubahan dibuat pada fail projek, pembina mesti membuat lapisan baharu dengan cepat dengan menggunakan tampalan pada fail yang diubah.
Jika fail tertentu telah berubah, maka adalah perlu untuk membina semula peringkat bergantung yang sepadan.

Hari ini pengumpul kami mempunyai banyak kemungkinan lain, tetapi ini adalah keinginan dan desakan awal.

Secara umum, tanpa berfikir dua kali, kami mempersenjatai diri dengan bahasa pengaturcaraan yang kami gunakan (lihat di bawah) dan mencapai jalan untuk melaksanakan DSL sendiri! Selaras dengan objektif, ia bertujuan untuk menerangkan proses pemasangan secara berperingkat dan menentukan kebergantungan peringkat ini pada fail. Dan melengkapinya pengumpul sendiri, yang menjadikan DSL sebagai matlamat akhir - imej yang dipasang. Pada mulanya DSL adalah dalam Ruby, tetapi sebagai peralihan ke Golang — konfigurasi pengumpul kami mula diterangkan dalam fail YAML.

Konfigurasi lama untuk dapp dalam Ruby

Konfigurasi semasa untuk werf pada YAML

Mekanisme pengumpul juga berubah dari semasa ke semasa. Pada mulanya, kami hanya menjana fail Docker sementara dengan cepat daripada konfigurasi kami, dan kemudian kami mula menjalankan arahan pemasangan dalam bekas sementara dan komit.

NB: Pada masa ini, pengumpul kami, yang berfungsi dengan konfigurasinya sendiri (dalam YAML) dan dipanggil pengumpul Stapel, telah berkembang menjadi alat yang cukup berkuasa. Penerangan terperincinya memerlukan artikel yang berasingan, dan butiran asas boleh didapati di dokumentasi.

Kesedaran tentang masalah

Tetapi kami menyedari, dan tidak serta-merta, bahawa kami telah melakukan satu kesilapan: kami tidak menambah keupayaan bina imej melalui fail Docker standard dan menyepadukannya ke dalam infrastruktur pengurusan aplikasi hujung ke hujung yang sama (iaitu mengumpul imej, menggunakan dan membersihkannya). Bagaimanakah mungkin untuk membuat alat untuk penggunaan dalam Kubernetes dan tidak melaksanakan sokongan Dockerfile, i.e. cara standard untuk menerangkan imej untuk kebanyakan projek?..

Daripada menjawab soalan ini, kami menawarkan penyelesaian. Bagaimana jika anda sudah mempunyai Dockerfile (atau satu set Dockerfiles) dan mahu menggunakan werf?

NB: By the way, kenapa awak nak guna werf? Ciri-ciri utama adalah seperti berikut:

kitaran pengurusan aplikasi penuh termasuk pembersihan imej;
keupayaan untuk menguruskan pemasangan beberapa imej sekaligus dari satu konfigurasi;
Proses penggunaan yang lebih baik untuk carta yang serasi dengan Helm.

Senarai yang lebih lengkap daripada mereka boleh didapati di halaman projek.

Jadi, jika sebelum ini kami akan menawarkan untuk menulis semula Dockerfile dalam konfigurasi kami, kini kami dengan senang hati akan berkata: "Biar werf membina Dockerfiles anda!"

Bagaimana untuk digunakan?

Pelaksanaan penuh ciri ini muncul dalam keluaran werf v1.0.3-beta.1. Prinsip umum adalah mudah: pengguna menentukan laluan ke Dockerfile sedia ada dalam konfigurasi werf, dan kemudian menjalankan arahan werf build... dan itu sahaja - werf akan memasang imej. Mari kita lihat contoh abstrak.

Mari kita umumkan yang seterusnya Dockerfile dalam akar projek:

FROM ubuntu:18.04
RUN echo Building ...

Dan kami akan umumkan werf.yamlyang menggunakan ini Dockerfile:

configVersion: 1
project: dockerfile-example
---
image: ~
dockerfile: ./Dockerfile

Semua! Dibiarkan lari werf build:

Di samping itu, anda boleh mengisytiharkan perkara berikut werf.yaml untuk membina beberapa imej daripada fail Docker yang berbeza sekaligus:

configVersion: 1
project: dockerfile-example
---
image: backend
dockerfile: ./dockerfiles/Dockerfile-backend
---
image: frontend
dockerfile: ./dockerfiles/Dockerfile-frontend

Akhirnya, ia juga menyokong lulus parameter binaan tambahan, seperti --build-arg и --add-host - melalui konfigurasi werf. Penerangan lengkap konfigurasi imej Dockerfile tersedia di halaman dokumentasi.

Bagaimana ia berfungsi?

Semasa proses binaan, cache standard lapisan tempatan dalam Docker berfungsi. Walau bagaimanapun, apa yang penting ialah werf itu juga menyepadukan konfigurasi Dockerfile ke dalam infrastrukturnya. Apakah maksud ini?

Setiap imej yang dibina daripada Dockerfile terdiri daripada satu peringkat dipanggil dockerfile (anda boleh membaca lebih lanjut mengenai peringkat mana dalam werf di sini).
Untuk pentas dockerfile werf mengira tandatangan yang bergantung pada kandungan konfigurasi Dockerfile. Apabila konfigurasi Dockerfile berubah, tandatangan peringkat berubah dockerfile dan werf memulakan pembinaan semula peringkat ini dengan konfigurasi Dockerfile baharu. Jika tandatangan tidak berubah, maka werf mengambil imej dari cache (butiran lanjut tentang penggunaan tandatangan dalam werf telah diterangkan dalam laporan ini).
Seterusnya, imej yang dikumpul boleh diterbitkan dengan arahan werf publish (Atau werf build-and-publish) dan gunakannya untuk penempatan ke Kubernetes. Imej yang diterbitkan ke Docker Registry akan dibersihkan menggunakan alat pembersihan werf standard, i.e. Imej lama (lebih lama daripada N hari), imej yang dikaitkan dengan cawangan Git yang tidak wujud dan dasar lain akan dibersihkan secara automatik.

Butiran lanjut tentang perkara yang diterangkan di sini boleh didapati dalam dokumentasi:

Nota dan langkah berjaga-jaga

1. URL luaran tidak disokong dalam ADD

Pada masa ini ia tidak disokong untuk menggunakan URL luaran dalam arahan ADD. Werf tidak akan memulakan pembinaan semula apabila sumber pada URL yang ditentukan berubah. Kami merancang untuk menambah ciri ini tidak lama lagi.

2. Anda tidak boleh menambah .git pada imej

Secara umumnya, menambah direktori .git dalam imej - amalan buruk yang kejam dan inilah sebabnya:

Jika .git kekal dalam imej akhir, ini melanggar prinsip Aplikasi 12 faktor: Memandangkan imej akhir mesti dipautkan kepada satu komit, ia tidak boleh dilakukan git checkout melakukan sewenang-wenangnya.
.git meningkatkan saiz imej (repositori boleh menjadi besar kerana fakta bahawa fail besar pernah ditambahkan padanya dan kemudian dipadamkan). Saiz pokok kerja yang dikaitkan hanya dengan komit tertentu tidak akan bergantung pada sejarah operasi dalam Git. Dalam kes ini, penambahan dan penyingkiran seterusnya .git daripada imej akhir tidak akan berfungsi: imej masih akan memperoleh lapisan tambahan - ini adalah cara Docker berfungsi.
Docker boleh memulakan pembinaan semula yang tidak perlu, walaupun komit yang sama sedang dibina, tetapi daripada pokok kerja yang berbeza. Sebagai contoh, GitLab mencipta direktori klon berasingan dalam /home/gitlab-runner/builds/HASH/[0-N]/yourproject apabila pemasangan selari didayakan. Pengumpulan semula tambahan akan disebabkan oleh fakta bahawa direktori .git adalah berbeza dalam versi klon berbeza bagi repositori yang sama, walaupun jika komit yang sama dibina.

Titik terakhir juga mempunyai akibat apabila menggunakan werf. Werf memerlukan cache terbina untuk hadir semasa menjalankan beberapa arahan (cth. werf deploy). Apabila arahan ini dijalankan, werf mengira tandatangan peringkat untuk imej yang dinyatakan dalam werf.yaml, dan mereka mesti berada dalam cache pemasangan - jika tidak, arahan tidak akan dapat terus berfungsi. Jika tandatangan pentas bergantung pada kandungan .git, maka kami mendapat cache yang tidak stabil kepada perubahan dalam fail yang tidak berkaitan, dan werf tidak akan dapat memaafkan kesilapan sedemikian (untuk butiran lanjut, lihat dokumentasi).

Secara umum, menambah hanya fail tertentu yang diperlukan melalui arahan ADD dalam apa jua keadaan meningkatkan kecekapan dan kebolehpercayaan tulisan Dockerfile, dan juga meningkatkan kestabilan cache yang dikumpul untuk ini Dockerfile, kepada perubahan yang tidak berkaitan dalam Git.

Jumlah

Laluan awal kami untuk menulis pembina kami sendiri untuk keperluan khusus adalah sukar, jujur dan mudah: daripada menggunakan tongkat di atas Fail Docker standard, kami menulis penyelesaian kami dengan sintaks tersuai. Dan ini mempunyai kelebihannya: pengumpul Stapel mengatasi tugasnya dengan sempurna.

Walau bagaimanapun, dalam proses menulis pembina kami sendiri, kami kehilangan sokongan untuk Dockerfiles sedia ada. Cacat ini kini telah diperbaiki dan pada masa hadapan kami merancang untuk membangunkan sokongan Dockerfile bersama-sama dengan pembina Stapel tersuai kami untuk pemasangan teragih dan untuk pemasangan menggunakan Kubernetes (iaitu pemasangan pada pelari di dalam Kubernetes, seperti yang dilakukan dalam kaniko).

Jadi, jika anda tiba-tiba mempunyai beberapa Dockerfiles tergeletak... cuba werf!

Anda kini boleh membina imej Docker dalam werf menggunakan fail Docker biasa