Konteyner çalışma zamanını ayrı takım bileşenlerine ayırmanın güzelliği nedir? Özellikle bu araçlar birbirlerini koruyacak şekilde birleştirilmeye başlanabilir.
Birçok kişi, kapsayıcıya alınmış OCI görüntüleri oluşturma fikrinden etkileniyor. veya benzer bir sistem. Diyelim ki sürekli olarak görüntüleri toplayan bir CI/CD'miz var, o zaman şöyle bir şey var: /Kubernetes, derlemeler sırasında yük dengeleme açısından oldukça faydalı olacaktır. Yakın zamana kadar çoğu kişi konteynerlerin Docker soketine erişmesine ve docker build komutunu çalıştırmalarına izin veriyordu. bunun çok güvensiz olduğunu, hatta şifresiz root veya sudo vermekten bile daha kötü olduğunu düşünüyorum.
Bu yüzden insanlar Buildah'ı sürekli olarak bir konteynerde çalıştırmaya çalışıyorlar. Kısaca yarattığımız Bize göre Buildah'ı bir konteyner içinde çalıştırmanın en iyi yolu nedir ve ilgili görselleri . Başlayalım...
Ayar
Bu görüntüler, klasördeki Buildah deposunda bulunabilen Docker dosyalarından oluşturulmuştur. .
Burada dikkate alacağız .
# 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
Ana Linux çekirdeği düzeyinde uygulanan OverlayFS yerine, konteynerin içindeki programı kullanıyoruz çünkü OverlayFS şu anda yalnızca Linux özelliklerini kullanarak SYS_ADMIN izinlerini verirseniz bağlanabilmektedir. Buildah konteynerlerimizi herhangi bir kök ayrıcalıkları olmadan çalıştırmak istiyoruz. Sigorta katmanı oldukça hızlı çalışır ve VFS depolama sürücüsünden daha iyi performansa sahiptir. Lütfen Fuse kullanan bir Buildah konteyneri çalıştırırken /dev/fuse cihazını sağlamanız gerektiğini unutmayın.
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
Daha sonra ek depolama için bir dizin oluşturuyoruz. ek salt okunur görüntü depolarını bağlama konseptini destekler. Örneğin, bir makinede bir yer paylaşımlı depolama alanı yapılandırabilir ve daha sonra bu depolamayı başka bir makineye monte etmek için NFS'yi kullanabilir ve çekme yoluyla indirmeden buradaki görüntüleri kullanabilirsiniz. Ana bilgisayardaki bazı görüntü depolarını birim olarak bağlayabilmek ve konteynerin içinde kullanabilmek için bu depolamaya ihtiyacımız var.
# 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
Son olarak BUILDAH_ISOLATION ortam değişkenini kullanarak Buildah konteynerinin varsayılan olarak chroot izolasyonu ile çalışmasını söylüyoruz. Zaten bir konteynırda çalıştığımız için burada ek izolasyona gerek yok. Buildah'ın kendi ad alanıyla ayrılmış konteynerlerini oluşturabilmesi için SYS_ADMIN ayrıcalığı gereklidir, bu da konteynerin SELinux ve SECCOMP kurallarının gevşetilmesini gerektirir ki bu da güvenli bir konteynerden derleme tercihimize aykırıdır.
Buildah'ı bir konteynerin içinde çalıştırmak
Yukarıda tartışılan Buildah konteyner görüntü şeması, bu tür konteynerleri başlatma yöntemlerini esnek bir şekilde değiştirmenize olanak tanır.
Hız ve güvenlik
Bilgisayar güvenliği her zaman işlemin hızı ile bunun etrafına ne kadar koruma sarıldığı arasında bir uzlaşmadır. Bu ifade aynı zamanda kapların montajı sırasında da geçerlidir, bu nedenle aşağıda böyle bir uzlaşmaya yönelik seçenekleri ele alacağız.
Yukarıda tartışılan kapsayıcı görüntüsü, depolama alanını /var/lib/containers konumunda tutacaktır. Bu nedenle içeriği bu klasöre yerleştirmemiz gerekiyor ve bunu nasıl yapacağımız, konteyner görüntüleri oluşturma hızını büyük ölçüde etkileyecektir.
Üç seçeneği ele alalım.
Seçenek 1. Maksimum güvenlik gerekiyorsa, her kapsayıcı için kapsayıcılar/görüntü için kendi klasörünüzü oluşturabilir ve bunu birim montajı yoluyla kapsayıcıya bağlayabilirsiniz. Ayrıca bağlam dizinini kabın kendisine, /build klasörüne yerleştirin:
# 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
Güvenlik. Böyle bir kapsayıcıda çalışan Buildah maksimum güvenliğe sahiptir: yetenekler kullanılarak herhangi bir kök ayrıcalığı verilmez ve tüm SECOMP ve SELinux kısıtlamaları ona uygulanır.Böyle bir kapsayıcı, —uidmap 0 gibi bir seçenek eklenerek Kullanıcı Ad Alanı yalıtımıyla bile çalıştırılabilir: 100000:10000.
Performans. Ancak konteyner kayıtlarındaki resimler her seferinde ana bilgisayara kopyalandığından ve önbelleğe alma hiç çalışmadığından buradaki performans minimum düzeydedir. Buildah konteyneri işini tamamlarken görüntüyü kayıt defterine göndermeli ve ana bilgisayardaki içeriği yok etmelidir. Bir sonraki sefer konteyner görüntüsü oluşturulduğunda, kayıt defterinden tekrar indirilmesi gerekecektir, çünkü o zamana kadar ana bilgisayarda hiçbir şey kalmayacaktır.
Seçenek 2. Docker düzeyinde performansa ihtiyacınız varsa ana bilgisayar konteynerini/depolamayı doğrudan konteynere monte edebilirsiniz.
# 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
Güvenlik. Bu, konteyner oluşturmanın en az güvenli yoludur çünkü konteynerin ana bilgisayar depolamasını değiştirmesine izin verir ve potansiyel olarak Podman veya CRI-O'ya kötü amaçlı bir görüntü besleyebilir. Ayrıca Buildah konteynerindeki işlemlerin ana bilgisayardaki depolama alanıyla etkileşime girebilmesi için SELinux ayırmayı devre dışı bırakmanız gerekecektir. Bu seçeneğin yine de Docker soketinden daha iyi olduğunu unutmayın çünkü konteyner kalan güvenlik özellikleri tarafından kilitlenmiştir ve bir konteyneri ana makinede kolayca çalıştıramaz.
Performans. Önbelleğe alma tamamen kullanıldığı için burada maksimumdur. Podman veya CRI-O gerekli görüntüyü ana bilgisayara zaten indirmişse, konteynerin içindeki Buildah işleminin onu tekrar indirmesi gerekmeyecek ve bu görüntüyü temel alan sonraki derlemeler de ihtiyaç duydukları şeyi önbellekten alabilecektir. .
Seçenek 3. Bu yöntemin özü, birkaç görüntüyü, kapsayıcı görüntüler için ortak bir klasörle tek bir projede birleştirmektir.
# 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
Bu örnekte, çalıştırmalar arasında proje klasörünü (/var/lib/project3) silmiyoruz, dolayısıyla proje içindeki sonraki tüm derlemeler önbelleğe alma işleminden yararlanır.
Güvenlik. Seçenek 1 ve 2 arasında bir şey. Bir yandan, konteynerlerin ana bilgisayardaki içeriğe erişimi yoktur ve dolayısıyla Podman/CRI-O görüntü deposuna kötü bir şey aktaramazlar. Öte yandan tasarımı gereği bir konteyner diğer konteynerlerin montajına müdahale edebilir.
Performans. Podman/CRI-O kullanılarak zaten indirilmiş olan görüntüleri kullanamayacağınız için, ana bilgisayar düzeyinde paylaşılan bir önbellek kullanmaktan daha kötüdür. Ancak Buildah görüntüyü indirdikten sonra görüntü, proje içindeki sonraki herhangi bir yapıda kullanılabilir.
Ek depolama
У Ek mağazalar (ek mağazalar) gibi harika bir şey var; bu sayede konteynerleri başlatırken ve oluştururken konteyner motorları harici görüntü depolarını salt okunur kaplama modunda kullanabilir. Temel olarak, Storage.conf dosyasına bir veya daha fazla salt okunur depolama ekleyebilirsiniz, böylece kapsayıcıyı başlattığınızda kapsayıcı motoru istenen görüntüyü bunlarda arar. Üstelik görüntüyü yalnızca bu depoların hiçbirinde bulamazsa kayıt defterinden indirecektir. Konteyner motoru yalnızca yazılabilir depolama alanına yazabilecek...
Yukarı kaydırıp quay.io/buildah/stable imajını oluşturmak için kullandığımız Docker dosyasına bakarsanız aşağıdaki gibi satırlar vardır:
# 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
İlk satırda, konteyner görüntüsünün içindeki /etc/containers/storage.conf dosyasını değiştirerek depolama sürücüsüne /var/lib/shared klasöründeki "additionalimagestores"u kullanmasını söyleriz. Ve bir sonraki satırda paylaşılan bir klasör oluşturup birkaç kilit dosyası ekliyoruz, böylece kapsayıcılardan/depolamadan herhangi bir kötüye kullanım yaşanmaz. Esasen, yalnızca boş bir kapsayıcı görüntü deposu oluşturuyoruz.
Konteynerleri/depolamayı bu klasörden daha yüksek bir seviyeye monte ederseniz Buildah görselleri kullanabilecektir.
Şimdi Buildah konteynerinin ana bilgisayarlardaki konteynerleri/depolamayı okuyabildiği ve yazabildiği ve buna bağlı olarak görüntüleri Podman/CRI-O düzeyinde önbelleğe alma nedeniyle maksimum performansa sahip olduğu ancak minimum güvenlik sağladığı yukarıda tartışılan Seçenek 2'ye dönelim. doğrudan depolamaya yazabilir. Şimdi buraya ek depolama alanı ekleyelim ve her iki dünyanın da en iyilerinden yararlanalım.
# 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
Ana bilgisayarın /var/lib/containers/storage dosyasının salt okunur modda konteynerin içinde /var/lib/shared dizinine bağlandığını unutmayın. Bu nedenle, bir konteynerde çalışan Buildah, daha önce Podman/CRI-O (merhaba, hız) kullanılarak indirilen tüm görüntüleri kullanabilir, ancak yalnızca kendi deposuna (merhaba, güvenlik) yazabilir. Ayrıca bunun, konteyner için SELinux ayırma devre dışı bırakılmadan yapıldığını unutmayın.
Önemli nüans
Hiçbir durumda temel depodaki hiçbir resmi silmemelisiniz. Aksi takdirde Buildah konteyneri çökebilir.
Ve bunların hepsi avantajlar değil
Ek depolama olanakları yukarıdaki senaryoyla sınırlı değildir. Örneğin, tüm konteyner görüntülerini paylaşılan bir ağ depolama alanına yerleştirebilir ve buna tüm Buildah konteynerlerine erişim verebilirsiniz. Diyelim ki CI/CD sistemimizin kapsayıcı görüntüler oluşturmak için düzenli olarak kullandığı yüzlerce görüntümüz var. Tüm bu görüntüleri tek bir depolama ana bilgisayarında yoğunlaştırıyoruz ve ardından tercih edilen ağ depolama araçlarını (NFS, Gluster, Ceph, ISCSI, S3...) kullanarak bu depolamaya tüm Buildah veya Kubernetes düğümlerine genel erişim açıyoruz.
Artık bu ağ depolama alanını /var/lib/shared adresindeki Buildah konteynerine bağlamak yeterli ve bu kadar - Buildah konteynerlerinin artık görüntüleri çekme yoluyla indirmesine gerek yok. Böylece ön-doldurma aşamasını bir kenara atıyoruz ve konteynırları hemen yaymaya hazır hale geliyoruz.
Ve tabii ki bu, canlı bir Kubernetes sistemi veya konteyner altyapısı içinde, konteynerleri herhangi bir yerde herhangi bir görüntü indirmeye gerek kalmadan başlatmak ve çalıştırmak için kullanılabilir. Ayrıca, güncellenmiş bir görüntüyü kendisine yüklemek için bir anlık istek alan konteyner kayıt defteri, bu görüntüyü otomatik olarak paylaşılan bir ağ deposuna gönderebilir ve burada anında tüm düğümler tarafından kullanılabilir hale gelir.
Kapsayıcı görüntülerin boyutu bazen birçok gigabayta ulaşabilir. Ek depolamanın işlevselliği, bu tür görüntülerin düğümler arasında kopyalanmasını önlemenize olanak tanır ve kapsayıcıların neredeyse anında başlatılmasını sağlar.
Buna ek olarak, konteynerlerin inşasını daha da hızlı hale getirecek olan kaplama birimi bağlantıları adı verilen yeni bir özellik üzerinde çalışıyoruz.
Sonuç
Buildah'ı Kubernetes/CRI-O, Podman ve hatta Docker'daki bir konteyner içinde çalıştırmak docker.socket kullanmaktan daha uygun, basit ve çok daha güvenlidir. Görüntülerle çalışmanın esnekliğini büyük ölçüde artırdık; böylece güvenlik ve performans arasındaki dengeyi optimize etmek için görüntüleri çeşitli şekillerde çalıştırabilirsiniz.
Ek depolamanın işlevselliği, görüntülerin düğümlere indirilmesini hızlandırmanıza ve hatta tamamen ortadan kaldırmanıza olanak tanır.
Kaynak: habr.com