Apa keindahan membagi runtime kontainer menjadi komponen instrumental terpisah? Secara khusus, fakta bahwa alat-alat ini dapat mulai digabungkan untuk saling melindungi.
Banyak orang tertarik dengan gagasan membangun kontainer
OCI dalam
Kubernetes atau sistem serupa. Misalkan kita memiliki CI / CD yang terus-menerus mengumpulkan gambar, maka sesuatu seperti
Red Hat OpenShift / Kubernetes akan sangat berguna dalam hal keseimbangan beban selama perakitan. Sampai baru-baru ini, kebanyakan orang hanya memberikan kontainer akses ke soket buruh pelabuhan dan memungkinkan perintah membangun buruh pelabuhan dijalankan.
Kami menunjukkan beberapa tahun yang lalu bahwa ini sangat tidak aman, bahkan lebih buruk daripada memberikan root atau sudo tanpa kata sandi.
Oleh karena itu, orang terus berusaha menjalankan Buildah dalam sebuah wadah. Singkatnya, kami membuat
contoh bagaimana, menurut pendapat kami, yang terbaik adalah menjalankan Buildah di dalam wadah, dan meletakkan gambar yang sesuai di
quay.io/buildah . Mari kita mulai ...
Kustomisasi
Gambar-gambar ini dikompilasi dari Dockerfiles, yang dapat ditemukan di repositori Buildah di folder
buildahimage .
Di sini kita melihat
versi stabil Dockerfile .
# 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
fuse-overlay di dalam wadah, karena pada saat ini OverlayFS hanya dapat dipasang jika diberikan hak istimewa SYS_ADMIN oleh kemampuan Linux. Dan kami ingin menjalankan wadah Buildah kami tanpa hak root. Fuse-overlay cukup cepat dan kinerjanya lebih baik daripada driver penyimpanan VFS. Perhatikan bahwa ketika memulai wadah Buildah menggunakan Fuse, Anda harus menyediakan perangkat / 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
Selanjutnya, kami membuat direktori untuk penyimpanan tambahan.
Wadah / penyimpanan mendukung konsep menghubungkan penyimpanan gambar hanya baca tambahan. Misalnya, Anda dapat mengonfigurasi area penyimpanan overlay pada satu mesin, dan kemudian menggunakan NFS untuk memasang penyimpanan ini di komputer lain dan menggunakan gambar darinya tanpa mengunduh melalui tarikan. Kami membutuhkan penyimpanan ini untuk dapat menghubungkan beberapa jenis 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
Akhirnya, menggunakan variabel lingkungan BUILDAH_ISOLATION, kami mengatakan bahwa secara default, wadah Buildah harus dimulai dengan isolasi chroot. Isolasi tambahan tidak diperlukan di sini, karena kami sudah bekerja di wadah. Agar Buildah membuat wadah sendiri dengan pemisahan ruang nama, hak istimewa SYS_ADMIN diperlukan, dan untuk ini akan perlu untuk melemahkan aturan SELinux dan SECCOMP untuk wadah, yang bertentangan dengan instalasi kami untuk membangun dari wadah yang aman.
Jalankan Buildah di dalam wadah
Skema gambar wadah Buildah yang dibahas di atas memungkinkan Anda untuk memvariasikan cara Anda menjalankan wadah tersebut secara fleksibel.
Kecepatan vs. Keamanan
Keamanan komputer selalu merupakan kompromi antara kecepatan proses dan seberapa banyak perlindungan yang melingkupinya. Pernyataan ini juga berlaku ketika merakit kontainer, jadi di bawah ini kami akan mempertimbangkan opsi untuk kompromi semacam itu.
Gambar kontainer yang dibahas di atas akan menyimpan repositori di / var / lib / container. Oleh karena itu, kita perlu me-mount konten dalam folder ini, dan cara kita melakukan ini akan sangat mempengaruhi kecepatan perakitan gambar kontainer.
Mari kita pertimbangkan tiga opsi.
Opsi 1. Jika keamanan maksimum diperlukan, maka untuk setiap wadah Anda dapat membuat folder Anda sendiri untuk wadah / gambar dan menghubungkannya ke wadah melalui volume-mount. Dan di samping itu, tempatkan direktori konteks dalam 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: ia tidak diberi hak root apa pun dengan alat kemampuan, dan semua pembatasan SECOMP dan SELinux berlaku untuknya. Wadah semacam itu bahkan dapat dijalankan dengan isolasi User Namespace, menambahkan opsi seperti - fluidmap 0: 100000: 10000 .
Performa. Tetapi kinerjanya di sini minimal, karena setiap gambar dari register kontainer disalin ke host setiap waktu, dan caching tidak bekerja dari kata "no way." Ketika menyelesaikan pekerjaannya, wadah Buildah harus mengirim gambar ke registri dan menghancurkan konten di host. Ketika gambar kontainer dikumpulkan lain kali, itu harus diunduh dari registri lagi, karena pada saat itu tidak ada yang tersisa di host.
Opsi 2. Jika Anda membutuhkan kinerja tingkat Docker, Anda dapat memasang wadah / penyimpanan host secara 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 di sini kontainer diizinkan untuk memodifikasi penyimpanan pada host, dan berpotensi dapat memasukkan gambar jahat ke Podman atau CRI-O. Selain itu, Anda harus menonaktifkan pemisahan SELinux sehingga proses dalam wadah Buildah dapat berinteraksi dengan penyimpanan di host. Harap dicatat bahwa opsi ini masih lebih baik daripada soket Docker, karena wadah diblokir oleh fungsi keamanan yang tersisa dan tidak bisa mengambil dan menjalankan wadah apa pun di host.
Performa. Ini maksimum, karena caching sepenuhnya terlibat. Jika Podman atau CRI-O sudah berhasil mengunduh gambar yang diinginkan ke host, maka proses Buildah di dalam wadah tidak harus mengunduhnya lagi, dan rakitan berikutnya berdasarkan gambar ini juga akan dapat mengambil yang diperlukan dari cache.
Opsi 3. Inti dari metode ini adalah menggabungkan beberapa gambar dalam satu proyek dengan folder bersama untuk gambar wadah.
# 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 mulai, jadi semua bangunan berikutnya dalam proyek mengambil keuntungan dari caching.
Keamanan Sesuatu di antara opsi 1 dan 2. Di satu sisi, kontainer tidak memiliki akses ke konten pada host dan, karenanya, tidak dapat memasukkan sesuatu yang buruk ke penyimpanan gambar Podman / CRI-O. Di sisi lain, sebagai bagian dari proyeknya, sebuah wadah dapat mengganggu perakitan wadah lainnya.
Performa. Ini lebih buruk daripada ketika menggunakan cache bersama di tingkat host, karena Anda tidak dapat menggunakan gambar yang sudah diunduh sebelumnya menggunakan Podman / CRI-O. Namun, setelah Buildah mengunduh gambar, gambar ini dapat digunakan di setiap bangunan berikutnya dalam proyek.
Penyimpanan tambahan
Wadah / penyimpanan memiliki fitur yang sangat keren seperti toko tambahan, berkat mesin wadah yang dapat menggunakan penyimpanan gambar eksternal dalam mode over-read-only saat meluncurkan dan membuat wadah. Bahkan, Anda bisa menambahkan satu atau lebih penyimpanan read-only ke file storage.conf sehingga ketika wadah mulai, mesin wadah mencari gambar yang diinginkan di dalamnya. Selain itu, ia akan mengunduh gambar dari registri hanya jika ia tidak menemukannya di salah satu repositori ini. Mesin kontainer hanya akan dapat menulis ke penyimpanan yang dapat ditulisi ...
Jika Anda menggulir ke atas dan melihat Dockerfile, yang kami gunakan untuk membangun gambar quay.io/buildah/stable, maka ada beberapa baris:
# 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 gambar container, memberi tahu driver penyimpanan untuk menggunakan "agagambarimagorores "di folder / var / lib / shared. Dan di baris berikutnya, buat folder bersama dan tambahkan beberapa file kunci sehingga tidak ada penyalahgunaan dari wadah / penyimpanan. Pada dasarnya, kami hanya membuat penyimpanan gambar wadah kosong.
Jika Anda memasang wadah / penyimpanan di atas folder ini, Buildah akan dapat menggunakan gambar.
Sekarang kembali ke Opsi 2 yang dibahas di atas, ketika sebuah wadah Buildah dapat membaca dan menulis ke wadah / simpan pada host dan, karenanya, memiliki kinerja maksimum karena caching gambar di tingkat Podman / CRI-O, tetapi memberikan keamanan minimum, karena dapat menulis secara langsung dalam penyimpanan. Dan sekarang kita akan mempercepat penyimpanan tambahan di sini dan mendapatkan yang terbaik dari 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
Perhatikan bahwa host / var / lib / wadah / penyimpanan sudah terpasang di / var / lib / dibagi di dalam wadah dalam mode read-only. Oleh karena itu, bekerja dalam sebuah wadah, Buildah dapat menggunakan gambar apa pun yang sebelumnya diunduh menggunakan Podman / CRI-O (hai, kecepatan), tetapi hanya dapat menulis ke repositori sendiri (hai, keamanan). Perhatikan juga bahwa ini dilakukan tanpa menonaktifkan pemisahan SELinux untuk wadah.
Nuansa penting
Dalam hal apa pun Anda tidak boleh menghapus gambar dari penyimpanan yang mendasarinya. Jika tidak, wadah Buildah dapat terbang keluar.
Dan ini tidak semua manfaatnya.
Kemampuan 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. Misalkan kita memiliki ratusan gambar yang sistem CI / CD kita gunakan secara teratur untuk membangun gambar kontainer. Kami memusatkan semua gambar ini pada satu host penyimpanan tunggal dan kemudian, menggunakan alat penyimpanan jaringan pilihan (NFS, Gluster, Ceph, ISCSI, S3 ...), membuka penyimpanan bersama untuk semua node Buildah atau Kubernetes.
Sekarang cukup untuk memasang penyimpanan jaringan ini ke wadah Buildah di / var / lib / dibagikan dan itu saja - Kontainer Buildah tidak lagi harus mengunduh gambar melalui tarikan. Jadi kami membuang fase pra-populasi dan segera siap untuk meluncurkan wadah.
Dan tentu saja, ini dapat digunakan dalam sistem Kubernetes yang ada atau infrastruktur wadah untuk meluncurkan dan menjalankan kontainer di mana saja tanpa mengunduh gambar melalui tarikan. Selain itu, registri kontainer, menerima permintaan push untuk memuat gambar yang diperbarui ke dalamnya, secara otomatis dapat mengirim gambar ini ke penyimpanan jaringan bersama, di mana secara instan tersedia untuk semua node.
Ukuran gambar kontainer terkadang dapat mencapai banyak gigabita. Fungsionalitas penyimpanan tambahan memungkinkan Anda untuk melakukannya tanpa mengkloning gambar-gambar tersebut dengan simpul dan membuat peluncuran wadah hampir instan.
Selain itu, kami sedang mengerjakan fungsi pemasangan volume overlay baru yang akan membuat perakitan kontainer lebih cepat.
Kesimpulan
Menjalankan Buildah di dalam sebuah wadah di Kubernetes / CRI-O, Podman, atau bahkan Docker adalah nyata, dan itu lebih sederhana dan lebih aman daripada menggunakan docker.socket. Kami telah sangat meningkatkan fleksibilitas bekerja dengan gambar, dan sekarang Anda dapat meluncurkannya dengan berbagai cara untuk keseimbangan optimal antara keamanan dan kinerja.
Fungsionalitas penyimpanan tambahan memungkinkan Anda untuk mempercepat atau bahkan sepenuhnya menghilangkan pengunduhan gambar ke node.