Apakah keindahan mengasingkan masa jalan kontena ke dalam komponen perkakas yang berasingan? Khususnya, alat ini boleh mula digabungkan supaya mereka melindungi satu sama lain.
Ramai orang tertarik dengan idea membina imej OCI dalam kontena atau sistem yang serupa. Katakan kita mempunyai CI/CD yang sentiasa mengumpul imej, kemudian sesuatu seperti /Kubernetes akan sangat berguna dari segi pengimbangan beban semasa binaan. Sehingga baru-baru ini, kebanyakan orang hanya memberikan bekas akses kepada soket Docker dan membenarkan mereka menjalankan arahan binaan docker. bahawa ini adalah sangat tidak selamat, malah, ia lebih teruk daripada memberikan root tanpa kata laluan atau sudo.
Itulah sebabnya orang sentiasa cuba menjalankan Buildah dalam bekas. Pendek kata, kami mencipta bagaimana, pada pendapat kami, adalah yang terbaik untuk menjalankan Buildah di dalam bekas, dan menyiarkan imej yang sepadan pada . Mari kita mulakan...
pelarasan
Imej ini dibina daripada Dockerfiles, yang boleh didapati dalam repositori Buildah dalam folder .
Di sini kita 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
Daripada OverlayFS, dilaksanakan pada peringkat kernel Linux hos, kami menggunakan program di dalam bekas , kerana pada masa ini OverlayFS hanya boleh dipasang jika anda memberikannya kebenaran SYS_ADMIN menggunakan keupayaan Linux. Dan kami mahu menjalankan bekas Buildah kami tanpa sebarang keistimewaan akar. Tindanan fius berfungsi dengan cepat dan mempunyai prestasi yang lebih baik daripada pemacu storan VFS. Sila ambil perhatian bahawa apabila menjalankan bekas Buildah yang menggunakan Fius, anda mesti menyediakan peranti /dev/fuse.
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
Seterusnya kami membuat direktori untuk storan tambahan. menyokong konsep menyambungkan stor imej baca sahaja tambahan. Sebagai contoh, anda boleh mengkonfigurasi kawasan storan tindanan pada satu mesin, dan kemudian menggunakan NFS untuk melekapkan storan ini pada mesin lain dan menggunakan imej daripadanya tanpa memuat turun melalui tarik. Kami memerlukan storan ini untuk dapat menyambungkan beberapa storan imej daripada hos sebagai volum dan menggunakannya di dalam bekas.
# 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
Akhir sekali, dengan menggunakan pembolehubah persekitaran BUILDAH_ISOLATION, kami memberitahu bekas Buildah untuk dijalankan dengan pengasingan chroot secara lalai. Penebat tambahan tidak diperlukan di sini, kerana kami sudah bekerja dalam bekas. Untuk membolehkan Buildah mencipta bekas yang dipisahkan dengan ruang nama sendiri, keistimewaan SYS_ADMIN diperlukan, yang memerlukan melonggarkan peraturan SELinux dan SECCOMP kontena, yang bertentangan dengan keutamaan kami untuk membina daripada bekas selamat.
Menjalankan Buildah di dalam bekas
Gambar rajah imej kontena Buildah yang dibincangkan di atas membolehkan anda mengubah kaedah pelancaran kontena tersebut secara fleksibel.
Kelajuan berbanding keselamatan
Keselamatan komputer sentiasa berkompromi antara kelajuan proses dan berapa banyak perlindungan yang dililitkan di sekelilingnya. Kenyataan ini juga benar semasa memasang bekas, jadi di bawah kami akan mempertimbangkan pilihan untuk kompromi sedemikian.
Imej bekas yang dibincangkan di atas akan menyimpan storannya dalam /var/lib/containers. Oleh itu, kami perlu melekapkan kandungan ke dalam folder ini, dan cara kami melakukan ini akan sangat mempengaruhi kelajuan membina imej kontena.
Mari kita pertimbangkan tiga pilihan.
Pilihan 1. Jika keselamatan maksimum diperlukan, maka untuk setiap bekas anda boleh mencipta folder anda sendiri untuk bekas/imej dan menyambungkannya ke bekas melalui pemasangan volum. Selain itu, letakkan direktori konteks dalam bekas itu sendiri, dalam 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
Keselamatan. Binaan yang dijalankan dalam bekas sedemikian mempunyai keselamatan maksimum: ia tidak diberikan sebarang keistimewaan root menggunakan keupayaan, dan semua sekatan SECOMP dan SELinux dikenakan padanya. Bekas sedemikian boleh dijalankan dengan pengasingan Ruang Nama Pengguna dengan menambahkan pilihan seperti βuidmap 0: 100000:10000.
Prestasi. Tetapi prestasi di sini adalah minimum, kerana mana-mana imej daripada pendaftaran kontena disalin ke hos setiap kali, dan caching tidak berfungsi sama sekali. Apabila menyelesaikan kerjanya, bekas Buildah mesti menghantar imej ke pendaftaran dan memusnahkan kandungan pada hos. Pada kali seterusnya imej kontena dibina, ia perlu dimuat turun dari pendaftaran sekali lagi, kerana pada masa itu tidak akan ada apa-apa lagi pada hos.
Pilihan 2. Jika anda memerlukan prestasi peringkat Docker, anda boleh melekapkan bekas/storan hos terus ke dalam bekas.
# 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
Keselamatan. Ini ialah cara yang paling tidak selamat untuk membina bekas kerana ia membenarkan bekas mengubah suai storan pada hos dan berpotensi memberi Podman atau CRI-O imej berniat jahat. Selain itu, anda perlu melumpuhkan pemisahan SELinux supaya proses dalam bekas Buildah boleh berinteraksi dengan storan pada hos. Ambil perhatian bahawa pilihan ini masih lebih baik daripada soket Docker kerana bekas itu dikunci oleh ciri keselamatan yang tinggal dan tidak boleh menjalankan bekas pada hos sahaja.
Prestasi. Di sini ia adalah maksimum, kerana caching digunakan sepenuhnya. Jika Podman atau CRI-O telah memuat turun imej yang diperlukan ke hos, maka proses Buildah di dalam bekas tidak perlu memuat turunnya semula dan binaan seterusnya berdasarkan imej ini juga akan dapat mengambil apa yang mereka perlukan daripada cache .
Pilihan 3. Intipati kaedah ini adalah untuk menggabungkan beberapa imej ke dalam satu projek dengan folder biasa untuk imej kontena.
# 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 memadamkan folder projek (/var/lib/project3) antara larian, jadi semua binaan seterusnya dalam projek mendapat manfaat daripada caching.
Keselamatan. Sesuatu di antara pilihan 1 dan 2. Di satu pihak, bekas tidak mempunyai akses kepada kandungan pada hos dan, oleh itu, tidak boleh menyelitkan sesuatu yang buruk ke dalam storan imej Podman/CRI-O. Sebaliknya, sebagai sebahagian daripada reka bentuknya, bekas boleh mengganggu pemasangan bekas lain.
Prestasi. Di sini ia lebih teruk daripada menggunakan cache kongsi di peringkat hos, kerana anda tidak boleh menggunakan imej yang telah dimuat turun menggunakan Podman/CRI-O. Walau bagaimanapun, sebaik sahaja Buildah memuat turun imej, imej itu boleh digunakan dalam mana-mana binaan seterusnya dalam projek.
Storan tambahan
Π£ Terdapat perkara yang menarik seperti kedai tambahan (kedai tambahan), terima kasih kepada yang apabila melancarkan dan membina bekas, enjin kontena boleh menggunakan kedai imej luaran dalam mod tindanan baca sahaja. Pada asasnya, anda boleh menambah satu atau lebih storan baca sahaja pada fail storage.conf supaya apabila anda memulakan bekas, enjin kontena mencari imej yang dikehendaki di dalamnya. Selain itu, ia akan memuat turun imej dari pendaftaran hanya jika ia tidak menemuinya dalam mana-mana storan ini. Enjin kontena hanya akan dapat menulis ke storan boleh tulis...
Jika anda menatal ke atas dan melihat Dockerfile yang kami gunakan untuk membina imej quay.io/buildah/stable, terdapat 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
Dalam baris pertama, kami mengubah suai /etc/containers/storage.conf di dalam imej bekas, memberitahu pemacu storan untuk menggunakan "additionalimagestores" dalam folder /var/lib/shared. Dan dalam baris seterusnya kami mencipta folder kongsi dan menambah beberapa fail kunci supaya tiada penyalahgunaan daripada bekas/storan. Pada asasnya, kami hanya mencipta stor imej bekas kosong.
Jika anda melekapkan bekas/storan pada tahap yang lebih tinggi daripada folder ini, Buildah akan dapat menggunakan imej.
Sekarang mari kita kembali ke Pilihan 2 yang dibincangkan di atas, apabila bekas Buildah boleh membaca dan menulis ke bekas/simpan pada hos dan, dengan itu, mempunyai prestasi maksimum disebabkan oleh caching imej pada tahap Podman/CRI-O, tetapi menyediakan keselamatan minimum sejak ia boleh menulis terus ke storan. Sekarang mari tambah storan tambahan di sini dan dapatkan yang terbaik dari kedua-dua 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
Ambil perhatian bahawa hos /var/lib/containers/storage dipasang pada /var/lib/shared di dalam bekas dalam mod baca sahaja. Oleh itu, bekerja dalam bekas, Buildah boleh menggunakan mana-mana imej yang telah dimuat turun sebelum ini menggunakan Podman/CRI-O (hello, kelajuan), tetapi hanya boleh menulis ke storan sendiri (hello, keselamatan). Juga ambil perhatian bahawa ini dilakukan tanpa melumpuhkan pemisahan SELinux untuk bekas.
Nuansa penting
Dalam apa jua keadaan, anda tidak boleh memadamkan sebarang imej daripada repositori asas. Jika tidak, bekas Buildah mungkin ranap.
Dan ini bukan semua kelebihannya
Kemungkinan storan tambahan tidak terhad kepada senario di atas. Sebagai contoh, anda boleh meletakkan semua imej bekas pada storan rangkaian kongsi dan memberikan akses kepadanya kepada semua bekas Buildah. Katakan kami mempunyai beratus-ratus imej yang selalu digunakan oleh sistem CI/CD kami untuk membina imej bekas. Kami menumpukan semua imej ini pada satu hos storan dan kemudian, menggunakan alat storan rangkaian pilihan (NFS, Gluster, Ceph, ISCSI, S3...), kami membuka akses umum kepada storan ini kepada semua nod Buildah atau Kubernetes.
Kini sudah cukup untuk melekapkan storan rangkaian ini ke dalam bekas Buildah pada /var/lib/shared dan itu sahaja - Bekas Buildah tidak perlu lagi memuat turun imej melalui tarik. Oleh itu, kami membuang fasa prapenduduk dan segera bersedia untuk melancarkan bekas.
Dan sudah tentu, ini boleh digunakan dalam sistem Kubernetes langsung atau infrastruktur kontena untuk melancarkan dan menjalankan kontena di mana-mana sahaja tanpa sebarang muat turun gambar. Selain itu, pendaftaran kontena, yang menerima permintaan tolak untuk memuat naik imej yang dikemas kini kepadanya, secara automatik boleh menghantar imej ini ke storan rangkaian kongsi, di mana ia serta-merta menjadi tersedia kepada semua nod.
Imej bekas kadangkala boleh mencapai banyak gigabait dalam saiz. Kefungsian storan tambahan membolehkan anda mengelakkan pengklonan imej sedemikian merentasi nod dan menjadikan bekas pelancaran hampir serta-merta.
Selain itu, kami sedang mengusahakan ciri baharu yang dipanggil pelekap volum tindanan, yang akan menjadikan bekas pembinaan lebih pantas.
Kesimpulan
Menjalankan Buildah di dalam bekas dalam Kubernetes/CRI-O, Podman, atau bahkan Docker adalah boleh dilaksanakan, mudah dan lebih selamat daripada menggunakan docker.socket. Kami telah meningkatkan fleksibiliti bekerja dengan imej, jadi anda boleh menjalankannya dalam pelbagai cara untuk mengoptimumkan keseimbangan antara keselamatan dan prestasi.
Fungsi storan tambahan membolehkan anda mempercepatkan atau bahkan menghapuskan sepenuhnya muat turun imej ke nod.
Sumber: www.habr.com