Kuby-core: Menggunakan buildx

Dibuat pada 13 Des 2021  ·  6Komentar  ·  Sumber: getkuby/kuby-core

Saya mencoba menambahkan dukungan untuk memanggil docker build sebagai docker buildx build tetapi saya khawatir ini mungkin sedikit lebih rumit dari itu

Niat saya adalah menambahkan jenis params ini:

https://github.com/fluxcd/image-reflector-controller/blob/62c06ea58cd14072fde2c9ada7c6970dedf580e5/.github/workflows/build.yaml#L57 -L59

Kemudian kita dapat men-cache lapisan build Docker dengan cara yang lebih efisien. Bagaimanapun opsi --cache-to dan --cache-from hanya tersedia di Docker Buildx, seperti banyak opsi lain yang mungkin ingin saya gunakan

Di masa lalu saya telah berhasil mengaktifkan volume cache untuk bundler di dalam Dockerfile, sehingga perubahan pada Gemfile dan Gemfile.lock tidak akan menghasilkan penghitungan ulang lengkap dari dependensi waktu pembuatan gambar, tetapi sebaliknya akan membangun dari cache sehingga hanya dependensi baru yang dihitung ulang.

Meskipun ini jelas merupakan pengoptimalan niche, ada kasus penggunaan lain yang lebih umum yang hanya dapat ditangani dengan baik dengan buildx. Toolset buildkit menjadi cukup standar sekarang IMHO. Saya akan senang jika mungkin untuk memanggil build Kuby dengan cara yang menggunakan buildx!

Saya mungkin mencoba menerapkan ini lagi nanti, mungkin lebih mudah sekarang karena 0.15.0 dirilis dengan solid. Sementara itu, ada contoh yang berfungsi dari Tindakan GitHub yaitu WIP tetapi saat ini terlihat cukup bagus di: https://github.com/kingdonb/kuby_test

Dengan caching yang dikonfigurasi dengan benar di tempat terakhir ini, dan beberapa perubahan lainnya, saya pikir ini hampir siap untuk menandai dan membuat contoh darinya untuk kontribusi kembali ke kuby-core, atau untuk tinggal di suatu tempat di proyek getkuby 👍

Komentar yang paling membantu

Baiklah, jika docker build hanyalah sebuah alias untuk docker buildx , maka saya tidak melihat perlunya Kuby melakukan sesuatu yang istimewa. Pengguna harus mengatur pembuat yang mereka inginkan.

Semua 6 komentar

Hai!

Dimungkinkan untuk menggunakan buildx sekarang, jika Anda menetapkannya sebagai builder default .

Berikut adalah contoh Github Action yang menggunakan buildx dan kemampuan cachingnya: https://github.com/anycable/anycable_rails_demo/pull/25/files#diff -28802fbf11c83a2eee09623fb192785e7ca92a3f40602a517c011b947a1822d

Lihat juga https://evilmartians.com/chronicles/kubing-rails-stressless-kubernetes-deployments-with-kuby#deploying -continuously-with-kuby-and-github-actions

Saya hanya mencari sesuatu seperti flag --only , karena saya mengalami masalah dalam menyiapkan caching! Saya mendapat ide bahwa saya perlu memisahkan cakupan untuk setiap jenis build, seperti yang saya lihat telah Anda lakukan di sini.

Terima kasih banyak atas referensi praktisnya 👍 Saya mengikuti sekarang untuk melihat apakah mereka membuat saya melewati batas!

Saya pasti juga melewatkan fitur pembuat default setup-buildx-action ( install: true )

Tampaknya berhasil sekarang! Saya baru saja melihat pembuatan gambar aplikasi selesai dalam waktu kurang dari 10 detik. Ada masalah lain yang saya alami sekarang, mungkin regresi yang saya temukan di mana RAILS_MASTER_KEY tidak diekspor dengan benar, tetapi saya akan pergi dan membaca sumbernya untuk mencari tahu sekarang.

Jika saya menggunakan install: true seperti dalam komit ini, maka metode build dari lib/kuby/docker/cli.rb memanggil buildx , dan saya dapat meneruskan konstruksi buildx seperti --cache-to setelah -- untuk memasukkannya ke dalam array *docker-args 👍 jadi ini bisa ditutup, kecuali mungkin bagus untuk kuby-core untuk mendokumentasikan bagaimana itu bisa digunakan dengan buildx, itu bukan masalah kuby

Dengan contoh di:

https://github.com/kingdonb/kuby_test/commit/d74bf51e04253359b0d54aae7ddd6723ea6fd41d#diff -e2ad06bfd6b3aefc2d5f4fe8f60e0015b16947abc16764adef02e4339ac07a42R17-R20a42R17

Saya bisa menggunakan buildx, jadi masalah ini bisa ditutup.

Ini sangat keren, terima kasih telah menemukan hal-hal buildx! Saya mendapat kesan bahwa Anda dapat menyetel variabel lingkungan dan itu akan Berhasil™, apakah itu yang dilakukan tindakan docker/setup-buildx-action@v1 ? Tampaknya buildx hadir dengan Docker Desktop dan versi yang lebih baru diinstal melalui paket deb/rpm, jadi saya ingin tahu apakah Kuby dapat menggunakannya secara default. Jika dapat dikonfigurasi melalui env var, mungkin memanggil docker buildx build tidak diperlukan? Mungkin Kuby dapat mendeteksinya dan kembali normal docker build ?

Ya, itu mungkin (dan itulah yang dilakukan install: true di GitHub Action): https://docs.docker.com/buildx/working-with-buildx/#set -buildx-as-the-default- pembangun

Baiklah, jika docker build hanyalah sebuah alias untuk docker buildx , maka saya tidak melihat perlunya Kuby melakukan sesuatu yang istimewa. Pengguna harus mengatur pembuat yang mereka inginkan.

Apakah halaman ini membantu?
0 / 5 - 0 peringkat