Apa keindahan memisahkan runtime container menjadi komponen alat yang terpisah? Secara khusus, fakta bahwa alat-alat ini dapat mulai digabungkan sehingga saling melindungi.
Banyak orang tertarik dengan ide membangun gambar wadah OCI di dalamnya atau sistem serupa. Katakanlah kita memiliki CI / CD yang terus-menerus membuat gambar, lalu semacamnya /Kubernetes akan sangat berguna dalam hal penyeimbangan muatan build. Sampai baru-baru ini, kebanyakan orang hanya memberi wadah akses ke soket Docker dan mengizinkan mereka menjalankan perintah docker build. bahwa ini sangat tidak aman, bahkan lebih buruk daripada memberikan root atau sudo tanpa kata sandi.
Jadi orang terus-menerus mencoba menjalankan Buildah dalam sebuah wadah. Singkatnya, kami telah membuat bagaimana, menurut kami, yang terbaik adalah menjalankan Buildah di dalam wadah, dan memposting gambar yang sesuai . Mari kita mulai...
pengaturan
Gambar-gambar ini dibuat dari Dockerfiles, yang dapat ditemukan di repositori Buildah di dalam folder .
Di sini kami akan mempertimbangkan .
# stable/Dockerfile
#
# Build a Buildah container image from the latest
# stable version of Buildah on the Fedoras Updates System.
# https://bodhi.fedoraproject.org/updates/?search=buildah
# This image can be used to create a secured container
# that runs safely with privileges within the container.
#
FROM fedora:latest
# Don't include container-selinux and remove
# directories used by dnf that are just taking
# up space.
RUN yum -y install buildah fuse-overlayfs --exclude container-selinux; rm -rf /var/cache /var/log/dnf* /var/log/yum.*
# Adjust storage.conf to enable Fuse storage.
RUN sed -i -e 's|^#mount_program|mount_program|g' -e '/additionalimage.*/a "/var/lib/shared",' /etc/containers/storage.conf
Alih-alih OverlayFS, diimplementasikan pada tingkat kernel Linux dari host, kami menggunakan program di dalam wadah , karena saat ini OverlayFS hanya dapat dipasang jika Anda memberinya izin SYS_ADMIN melalui kemampuan Linux. Dan kami ingin menjalankan wadah Buildah kami tanpa hak akses root apa pun. Fuse-overlay cukup cepat dan bekerja lebih baik daripada driver penyimpanan VFS. Perhatikan bahwa saat menjalankan wadah Buildah menggunakan Fuse, perangkat /dev/fuse harus disediakan.
podman run --device /dev/fuse quay.io/buildahctr ...
RUN mkdir -p /var/lib/shared/overlay-images /var/lib/shared/overlay-layers; touch /var/lib/shared/overlay-images/images.lock; touch /var/lib/shared/overlay-layers/layers.lock
Selanjutnya, kami membuat direktori untuk repositori tambahan. mendukung konsep menghubungkan repositori gambar read-only tambahan. Misalnya, Anda dapat menyiapkan area penyimpanan overlay di satu mesin, lalu menggunakan NFS untuk memasang penyimpanan ini di komputer lain dan menggunakan image darinya tanpa mengunduh melalui pull. Kami membutuhkan penyimpanan ini agar dapat menghubungkan beberapa penyimpanan gambar dari host sebagai volume dan menggunakannya di dalam wadah.
# Set up environment variables to note that this is
# not starting with user namespace and default to
# isolate the filesystem with chroot.
ENV _BUILDAH_STARTED_IN_USERNS="" BUILDAH_ISOLATION=chroot
Terakhir, kami menggunakan variabel lingkungan BUILDAH_ISOLATION untuk memberi tahu wadah Buildah untuk memulai dengan isolasi chroot secara default. Isolasi tambahan tidak diperlukan di sini, karena kita sudah bekerja dalam wadah. Agar Buildah dapat membuat wadahnya sendiri yang dipisahkan oleh namespace, diperlukan hak istimewa SYS_ADMIN, yang akan mengharuskan pelonggaran aturan SELinux dan SECCOMP wadah, yang akan bertentangan dengan pengaturan kami untuk membangun dari wadah yang aman.
Jalankan Buildah di dalam wadah
Skema gambar wadah Buildah yang dibahas di atas memungkinkan Anda untuk secara fleksibel memvariasikan bagaimana wadah tersebut diluncurkan.
Kecepatan versus keamanan
Keamanan komputer selalu merupakan kompromi antara kecepatan suatu proses dan seberapa banyak perlindungan yang melingkupinya. Pernyataan ini juga berlaku saat merakit wadah, jadi di bawah ini kami akan mempertimbangkan opsi untuk kompromi semacam itu.
Gambar kontainer yang dibahas di atas akan menyimpan penyimpanannya di /var/lib/containers. Oleh karena itu, kami perlu memasang konten ke folder ini, dan cara kami melakukannya akan sangat memengaruhi kecepatan pembuatan gambar kontainer.
Mari pertimbangkan tiga opsi.
Opsi 1. Jika keamanan maksimum diperlukan, maka untuk setiap penampung Anda dapat membuat folder sendiri untuk penampung / gambar dan menghubungkannya ke penampung melalui volume-mount. Dan selain itu, tempatkan direktori konteks di wadah itu sendiri, di folder /build:
# mkdir /var/lib/containers1
# podman run -v ./build:/build:z -v /var/lib/containers1:/var/lib/containers:Z quay.io/buildah/stable
buildah -t image1 bud /build
# podman run -v /var/lib/containers1:/var/lib/containers:Z quay.io/buildah/stable buildah push image1 registry.company.com/myuser
# rm -rf /var/lib/containers1
Keamanan Buildah yang berjalan dalam wadah seperti itu memiliki keamanan maksimum: tidak diberikan hak akses root apa pun berdasarkan kemampuannya, dan semua batasan SECOMP dan SELinux berlaku untuknya. Wadah semacam itu bahkan dapat dijalankan dengan isolasi User Namespace dengan menambahkan opsi seperti --uidmap 0:100000:10000.
Performa. Tetapi kinerja di sini minimal, karena setiap gambar dari pendaftar penampung disalin ke host setiap kali, dan caching tidak berfungsi dari kata "tidak mungkin". Saat selesai bekerja, wadah Buildah harus mengirim gambar ke registri dan menghancurkan konten di host. Lain kali image container dibuat, itu harus diunduh lagi dari registri, karena tidak ada yang tersisa di host saat itu.
Opsi 2. Jika Anda membutuhkan kinerja tingkat Docker, Anda dapat memasang wadah/penyimpanan host langsung ke dalam wadah.
# podman run -v ./build:/build:z -v /var/lib/containers:/var/lib/containers --security-opt label:disabled quay.io/buildah/stable buildah -t image2 bud /build
# podman run -v /var/lib/containers:/var/lib/containers --security-opt label:disabled quay.io/buildah/stable buildah push image2 registry.company.com/myuser
Keamanan Ini adalah cara yang paling tidak aman untuk membuat kontainer, karena ini memungkinkan kontainer untuk memodifikasi penyimpanan di host dan berpotensi menyelipkan gambar berbahaya ke dalam Podman atau CRI-O. Selain itu, Anda perlu menonaktifkan pemisahan SELinux agar proses dalam wadah Buildah dapat berinteraksi dengan repositori di host. Perhatikan bahwa opsi ini masih lebih baik daripada soket Docker, karena penampung diblokir oleh fitur keamanan yang tersisa dan tidak dapat dengan mudah mengambil dan menjalankan penampung apa pun di host.
Performa. Ini maksimal, karena caching sepenuhnya terlibat. Jika Podman atau CRI-O telah mengunduh image yang diinginkan ke host, maka proses Buildah di dalam container tidak perlu mendownloadnya lagi, dan build selanjutnya berdasarkan image ini juga akan dapat mengambil yang diperlukan dari cache .
Opsi 3. Inti dari metode ini adalah menggabungkan beberapa gambar menjadi satu proyek dengan folder umum untuk gambar kontainer.
# mkdir /var/lib/project3
# podman run --security-opt label_level=s0:C100, C200 -v ./build:/build:z
-v /var/lib/project3:/var/lib/containers:Z quay.io/buildah/stable buildah -t image3 bud /build
# podman run --security-opt label_level=s0:C100, C200
-v /var/lib/project3:/var/lib/containers quay.io/buildah/stable buildah push image3 registry.company.com/myuser
Dalam contoh ini, kami tidak menghapus folder proyek (/var/lib/project3) di antara proses, sehingga semua pembangunan berikutnya dalam proyek memanfaatkan caching.
Keamanan Sesuatu antara opsi 1 dan 2. Di satu sisi, wadah tidak memiliki akses ke konten di host dan, karenanya, tidak dapat menyelipkan sesuatu yang buruk ke dalam penyimpanan gambar Podman / CRI-O. Di sisi lain, dalam proyeknya sendiri, sebuah wadah dapat mengganggu perakitan wadah lain.
Performa. Ini lebih buruk daripada menggunakan cache bersama di tingkat host, karena Anda tidak dapat menggunakan gambar yang telah diunduh menggunakan Podman / CRI-O. Namun, setelah Buildah mengunduh image, image tersebut dapat digunakan di build berikutnya dalam project.
Penyimpanan tambahan
Π£ ada hal yang keren seperti penyimpanan tambahan (penyimpanan tambahan), berkat itu, saat memulai dan membuat kontainer, mesin kontainer dapat menggunakan penyimpanan gambar eksternal dalam mode overlay hanya-baca. Bahkan, Anda dapat menambahkan satu atau lebih penyimpanan read-only ke file storage.conf, sehingga saat penampung dimulai, mesin penampung akan mencari gambar yang diinginkan di dalamnya. Selain itu, itu akan mengunduh gambar dari registri hanya jika tidak ditemukan di salah satu penyimpanan ini. Mesin kontainer hanya akan dapat menulis ke penyimpanan yang dapat ditulisi...
Jika kita menggulir ke atas dan melihat Dockerfile yang kita gunakan untuk membuat image quay.io/buildah/stable, ada baris seperti ini:
# Adjust storage.conf to enable Fuse storage.
RUN sed -i -e 's|^#mount_program|mount_program|g' -e '/additionalimage.*/a "/var/lib/shared",' /etc/containers/storage.conf
RUN mkdir -p /var/lib/shared/overlay-images /var/lib/shared/overlay-layers; touch /var/lib/shared/overlay-images/images.lock; touch /var/lib/shared/overlay-layers/layers.lock
Pada baris pertama, kita memodifikasi /etc/containers/storage.conf di dalam image container, memberi tahu driver penyimpanan untuk menggunakan "additionalimagestores" di folder /var/lib/shared. Dan di baris berikutnya, kami membuat folder bersama dan menambahkan beberapa file kunci agar tidak ada penyalahgunaan dari wadah / penyimpanan. Pada dasarnya, kami hanya membuat penyimpanan gambar kontainer kosong.
Jika Anda memasang wadah/penyimpanan satu tingkat di atas folder ini, Buildah akan dapat menggunakan gambar.
Sekarang mari kita kembali ke Opsi 2 yang dibahas di atas, ketika wadah Buildah dapat membaca dan menulis ke wadah / menyimpan di host dan, karenanya, memiliki kinerja maksimal karena caching gambar di tingkat Podman / CRI-O, tetapi memberikan keamanan minimum, karena dapat menulis langsung di penyimpanan. Dan sekarang kami akan memasang penyimpanan tambahan di sini dan mendapatkan yang terbaik dari kedua dunia.
# mkdir /var/lib/containers4
# podman run -v ./build:/build:z -v /var/lib/containers/storage:/var/lib/shared:ro -v /var/lib/containers4:/var/lib/containers:Z quay.io/buildah/stable
buildah -t image4 bud /build
# podman run -v /var/lib/containers/storage:/var/lib/shared:ro
-v >/var/lib/containers4:/var/lib/containers:Z quay.io/buildah/stable buildah push image4 registry.company.com/myuser
# rm -rf /var/lib/continers4
Perhatikan bahwa /var/lib/containers/storage host dipasang ke /var/lib/shared di dalam container dalam mode read-only. Oleh karena itu, bekerja dalam wadah, Buildah dapat menggunakan gambar apa pun yang telah diunduh menggunakan Podman / CRI-O (halo, kecepatan), tetapi hanya dapat menulis ke penyimpanannya sendiri (halo, keamanan). Perhatikan juga bahwa ini dilakukan tanpa menonaktifkan pemisahan SELinux untuk wadah.
Nuansa penting
Dalam keadaan apa pun gambar apa pun tidak boleh dihapus dari repositori yang mendasarinya. Jika tidak, wadah Buildah mungkin macet.
Dan itu tidak semua manfaatnya.
Kemungkinan penyimpanan tambahan tidak terbatas pada skenario di atas. Misalnya, Anda dapat menempatkan semua gambar kontainer di penyimpanan jaringan bersama dan memberikan akses ke semua kontainer Buildah. Katakanlah kita memiliki ratusan gambar yang digunakan sistem CI/CD secara teratur untuk membuat gambar dalam container. Kami memusatkan semua gambar ini pada satu host penyimpanan dan kemudian, menggunakan alat penyimpanan jaringan pilihan (NFS, Gluster, Ceph, iSCSI, S3 ...), berbagi penyimpanan ini dengan semua node Buildah atau Kubernetes.
Sekarang cukup memasang penyimpanan jaringan ini ke wadah Buildah di /var/lib/shared dan hanya itu - wadah Buildah tidak lagi harus mengunduh gambar melalui pull sama sekali. Jadi, kami membuang fase pra-pendudukan dan segera siap meluncurkan wadah.
Dan tentu saja, ini dapat digunakan dalam sistem Kubernetes langsung atau infrastruktur wadah untuk meluncurkan dan menjalankan wadah di mana saja tanpa penarikan gambar apa pun. Selain itu, ketika registri kontainer menerima permintaan push untuk mengunggah gambar yang diperbarui ke dalamnya, ia dapat secara otomatis mengirimkan gambar ini ke penyimpanan jaringan bersama, yang langsung tersedia untuk semua node.
Gambar kontainer terkadang berukuran banyak gigabyte. Fungsionalitas penyimpanan tambahan menghilangkan kebutuhan untuk mengkloning gambar tersebut dengan node dan membuat peluncuran kontainer hampir seketika.
Selain itu, saat ini kami sedang mengerjakan fitur pemasangan volume overlay baru yang akan membuat wadah pembangunan lebih cepat.
Kesimpulan
Menjalankan Buildah di dalam wadah di lingkungan Kubernetes/CRI-O, Podman, atau bahkan Docker sangat mungkin dilakukan, dan ini sederhana dan jauh lebih aman daripada menggunakan docker.socket. Kami telah meningkatkan fleksibilitas bekerja dengan gambar, dan sekarang Anda dapat menjalankannya dalam berbagai cara untuk keseimbangan terbaik antara keamanan dan kinerja.
Fungsionalitas penyimpanan tambahan memungkinkan Anda untuk mempercepat atau bahkan sepenuhnya menghilangkan pengunduhan gambar ke node.
Sumber: www.habr.com