ما هو جمال تقسيم وقت تشغيل الحاويات إلى مكونات مفيدة منفصلة؟ على وجه الخصوص ، حقيقة أن هذه الأدوات يمكن أن تبدأ في الجمع بين لحماية بعضها البعض.
تنجذب الكثير من الناس إلى فكرة بناء
OCIs الحاوية داخل
Kubernetes أو نظام مماثل. لنفترض أن لدينا CI / CD يجمع الصور باستمرار ، ثم سيكون هناك شيء مثل
Red Hat OpenShift / Kubernetes سيكون مفيدًا للغاية من حيث موازنة التحميل أثناء التجميع. حتى وقت قريب ، قام معظم الأشخاص ببساطة بمنح الحاويات الوصول إلى مأخذ التوصيل وتم السماح لهم بتنفيذ أمر بناء عامل الميناء.
لقد أظهرنا قبل عدة سنوات أن هذا غير آمن للغاية ، بل إنه في الحقيقة أسوأ من إعطاء جذر أو كلمة مرور بدون كلمة مرور.
لذلك ، يحاول الناس باستمرار تشغيل Buildah في حاوية. باختصار ، أنشأنا
مثالًا على أنه من الأفضل ، في رأينا ، تشغيل Buildah داخل الحاوية ووضع الصور المناسبة على
quay.io/buildah . لنبدأ ...
تعديل
يتم تجميع هذه الصور من Dockerfiles ، والتي يمكن العثور عليها في مستودع Buildah في مجلد
buildahimage .
هنا ننظر إلى
إصدار مستقر من 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
بدلاً من OverlayFS ، الذي يتم تنفيذه على مستوى Linux kernel للمضيف ، نستخدم برنامج
تراكب الصمامات داخل الحاوية ، لأنه في الوقت الحالي لا يمكن تثبيت OverlayFS إلا إذا تم منحه امتيازات SYS_ADMIN بواسطة إمكانيات Linux. ونريد تشغيل حاويات Buildah الخاصة بنا دون أي امتيازات الجذر. تراكب الصمامات سريع جدًا وأفضل في الأداء من برنامج تشغيل التخزين VFS. لاحظ أنه عند بدء تشغيل حاوية Buildah باستخدام Fuse ، يجب عليك توفير الجهاز / 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
بعد ذلك ، نقوم بإنشاء دليل لسعة تخزين إضافية. تدعم
الحاوية / التخزين مفهوم توصيل مخازن صور للقراءة فقط. على سبيل المثال ، يمكنك تكوين مساحة تخزين التراكب على جهاز واحد ، ثم استخدام NFS لتركيب هذا التخزين على جهاز آخر واستخدام الصور منه دون التنزيل عبر السحب. نحتاج إلى هذا التخزين حتى نتمكن من توصيل نوع من تخزين الصور من المضيف كوحدة تخزين واستخدامه داخل الحاوية.
# 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
أخيرًا ، باستخدام متغير البيئة BUILDAH_ISOLATION ، نقول أنه بشكل افتراضي ، يجب أن تبدأ حاوية Buildah بعزل chroot. العزلة الإضافية غير مطلوبة هنا ، لأننا نعمل بالفعل في الحاوية. لكي تنشئ Buildah حاوياتها الخاصة مع فصل مسافات الاسم ، يكون امتياز SYS_ADMIN مطلوبًا ، ولهذا سيكون من الضروري إضعاف قواعد SELinux و SECCOMP للحاوية ، والتي تتعارض مع تثبيتنا للبناء من حاوية آمنة.
تشغيل Buildah داخل الحاوية
يتيح لك مخطط صورة الحاوية Buildah الذي تمت مناقشته أعلاه تغيير طريقة تشغيل هذه الحاويات بمرونة.
السرعة مقابل الأمن
يعد أمان الكمبيوتر دائمًا حلاً وسطًا بين سرعة العملية ومقدار الحماية المحيطة بها. يكون هذا البيان صحيحًا أيضًا عند تجميع الحاويات ، لذا سنبحث أدناه خيارات لمثل هذا الحل الوسط.
ستحتفظ صورة الحاوية التي تمت مناقشتها أعلاه بمستودعها في / var / lib / Container. لذلك ، نحتاج إلى تحميل المحتوى في هذا المجلد ، وستؤثر الطريقة التي نفعل بها إلى حد كبير على سرعة تجميع صور الحاوية.
دعنا نفكر في ثلاثة خيارات.
الخيار 1. إذا كان الحد الأقصى للأمان مطلوبًا ، فيمكنك لكل مجلد إنشاء مجلد خاص للحاويات / الصورة وتوصيله بالحاوية عبر وحدة التخزين. وإلى جانب ذلك ، ضع دليل السياق في الحاوية نفسها ، في مجلد / 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
الأمن. بناء Buildah في هذه الحاوية لديه أقصى درجات الأمان: لا يتم منح أي امتيازات الجذر مع إمكانات ، وجميع القيود SECOMP و SELinux تنطبق عليها. يمكنك حتى تشغيل هذه الحاوية مع عزل مساحة اسم المستخدم من خلال إضافة خيار مثل --uidmap 0: 100000: 10000 .
الأداء. لكن الأداء هنا ضئيل للغاية ، حيث يتم نسخ أي صور من سجلات الحاوية إلى المضيف في كل مرة ، ولا يعمل التخزين المؤقت من كلمة "لا مفر". عند الانتهاء من عملها ، يجب على حاوية Buildah إرسال الصورة إلى السجل وتدمير المحتوى على المضيف. عند جمع صورة الحاوية في المرة القادمة ، سيتعين تنزيلها من السجل مرة أخرى ، لأنه بحلول ذلك الوقت لن يبقى شيء على المضيف.
الخيار 2. إذا كنت بحاجة إلى أداء على مستوى Docker ، يمكنك تركيب الحاوية / تخزين المضيف مباشرة في الحاوية.
# 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
الأمن. هذه هي الطريقة الأقل أمانًا لإنشاء الحاويات ، لأنه هنا يُسمح للحاوية بتعديل التخزين على المضيف ، وربما يمكن أن تنزلق إلى Podman أو CRI-O صورة ضارة. بالإضافة إلى ذلك ، ستحتاج إلى تعطيل فصل SELinux حتى تتمكن العمليات في حاوية Buildah من التفاعل مع التخزين على المضيف. يرجى ملاحظة أن هذا الخيار لا يزال أفضل من مقبس Docker ، نظرًا لأن الحاوية تم حظرها بواسطة وظائف الأمان المتبقية ولا يمكن فقط التقاط وتشغيل أي حاوية على المضيف.
الأداء. هنا الحد الأقصى ، لأن التخزين المؤقت متورط بشكل كامل. إذا كان Podman أو CRI-O قد تمكنا بالفعل من تنزيل الصورة المطلوبة إلى المضيف ، فلن تضطر عملية Buildah داخل الحاوية إلى تنزيلها مرة أخرى ، كما ستتمكن التجميعات اللاحقة بناءً على هذه الصورة من أخذ ما يلزم من ذاكرة التخزين المؤقت.
الخيار 3. يتمثل جوهر هذه الطريقة في دمج عدة صور في مشروع واحد مع مجلد مشترك للصور الحاوية.
# 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
في هذا المثال ، لا نحذف مجلد المشروع (/ var / lib / project3) بين البدايات ، لذلك تستفيد جميع البنيات اللاحقة داخل المشروع من التخزين المؤقت.
الأمن. شيء ما بين الخيارين 1 و 2. من ناحية ، لا تملك الحاويات الوصول إلى المحتوى على المضيف ، وبالتالي ، لا يمكن أن تنزلق شيئًا سيئًا في تخزين الصور Podman / CRI-O. من ناحية أخرى ، كجزء من مشروعها ، قد تتداخل الحاوية مع تجميع الحاويات الأخرى.
الأداء. يكون الوضع هنا أسوأ من استخدام ذاكرة تخزين مؤقت مشتركة على مستوى المضيف ، حيث لا يمكنك استخدام الصور التي تم تنزيلها بالفعل باستخدام Podman / CRI-O. ومع ذلك ، بعد قيام Buildah بتنزيل الصورة ، يمكن استخدام هذه الصورة في أي تصميمات لاحقة داخل المشروع.
تخزين إضافي
تحتوي الحاويات / التخزين على شيء رائع مثل المتاجر الإضافية ، حيث يمكن لمحركات الحاويات استخدام مخازن الصور الخارجية في وضع التراكب للقراءة فقط عند بدء تشغيل وبناء الحاويات. في الواقع ، يمكنك إضافة واحد أو أكثر من وحدات التخزين للقراءة فقط إلى ملف storage.conf بحيث عندما يبدأ تشغيل الحاوية ، يبحث محرك الحاوية عن الصورة المطلوبة فيها. علاوة على ذلك ، سوف يقوم بتنزيل الصورة من السجل فقط إذا لم يعثر عليها في أي من هذه المستودعات. لن يتمكن محرك الحاوية من الكتابة إلا على وحدات التخزين القابلة للكتابة ...
إذا قمت بالتمرير لأعلى ورؤية Dockerfile ، والذي نستخدمه لبناء الصورة quay.io/buildah/stable ، فهناك مثل هذه الخطوط:
# 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
في السطر الأول ، نقوم بتعديل /etc/containers/storage.conf داخل صورة الحاوية ، ونطلب من برنامج تشغيل التخزين استخدام "علامات إضافية" في المجلد / var / lib / المشترك. وفي السطر التالي ، أنشئ مجلدًا مشتركًا وأضف بضعة ملفات تأمين حتى لا يكون هناك أي سوء استخدام من الحاويات / التخزين. في الأساس ، نحن فقط إنشاء تخزين صورة حاوية فارغة.
إذا قمت بتركيب حاويات / تخزين أعلى هذا المجلد ، فسيكون بإمكان Buildah استخدام الصور.
عُد الآن إلى الخيار 2 الذي تمت مناقشته أعلاه ، عندما تتمكن حاوية Buildah من القراءة والكتابة على الحاويات / المتجر على المضيفين ، وبالتالي تتمتع بأقصى أداء بسبب التخزين المؤقت للصور على مستوى Podman / CRI-O ، ولكنها توفر الحد الأدنى من الأمان ، حيث يمكنها الكتابة مباشرة في التخزين. والآن سنقوم بتثبيت مساحة تخزينية إضافية هنا والحصول على أفضل ما في العالمين.
# 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
لاحظ أن مضيف / var / lib / Container / storage مثبت في / var / lib / مشترك داخل الحاوية في وضع القراءة فقط. لذلك ، من خلال العمل في حاوية ، يمكن لـ Buildah استخدام أي صور تم تنزيلها مسبقًا باستخدام Podman / CRI-O (مرحبًا ، السرعة) ، ولكن لا يمكنه الكتابة إلا إلى مستودع التخزين الخاص به (مرحبًا ، الأمان). لاحظ أيضًا أن هذا يتم دون تعطيل فصل SELinux للحاوية.
فارق بسيط مهم
لا ينبغي بأي حال إزالة أي صور من التخزين الأساسي. خلاف ذلك ، قد تطير حاوية Buildah.
وهذا ليس كل الفوائد.
لا تقتصر إمكانات التخزين الإضافية على السيناريو أعلاه. على سبيل المثال ، يمكنك وضع جميع صور الحاوية في وحدة تخزين مشتركة على الشبكة وإتاحة الوصول إلى جميع حاويات Buildah. افترض أن لدينا مئات الصور التي يستخدمها نظام CI / CD الخاص بنا بانتظام لإنشاء صور حاوية. نحن نركز كل هذه الصور على مضيف تخزين واحد ومن ثم ، باستخدام أدوات تخزين الشبكة المفضلة (NFS ، Gluster ، Ceph ، ISCSI ، S3 ...) ، نفتح تخزينًا مشتركًا لجميع العقد Buildah أو Kubernetes.
يكفي الآن تركيب وحدة تخزين الشبكة هذه في حاوية Buildah على / var / lib / shared وهذا كله - لم تعد حاويات Buildah بحاجة إلى تنزيل الصور عبر السحب. وبالتالي ، فإننا نطرد مرحلة ما قبل السكان ونكون مستعدين على الفور لطرح الحاويات.
وبالطبع ، يمكن استخدام هذا ضمن نظام Kubernetes الحالي أو البنية التحتية للحاويات لإطلاق الحاويات وتنفيذها في أي مكان دون تنزيل الصور عبر السحب. علاوة على ذلك ، يمكن لسجل الحاوية ، الذي يتلقى طلب دفع لتحميل صورة محدثة فيه ، أن يرسل هذه الصورة تلقائيًا إلى وحدة تخزين مشتركة على الشبكة ، حيث تتاح على الفور لجميع العقد.
يمكن أن يصل حجم صور الحاوية أحيانًا إلى العديد من الجيجابايت. تسمح لك وظيفة وحدات التخزين الإضافية بالقيام دون استنساخ مثل هذه الصور بالعقد وتجعل حاويات الإطلاق شبه فورية.
بالإضافة إلى ذلك ، نحن نعمل حاليًا على وظيفة جديدة لحجم وحدات تخزين التراكب التي تجعل تجميع الحاوية أسرع.
استنتاج
تشغيل Buildah داخل حاوية في Kubernetes / CRI-O أو Podman أو Docker حقيقي ، وهو أبسط وأكثر أمانًا من استخدام docker.socket. لقد حسننا إلى حد كبير مرونة العمل مع الصور ، والآن يمكنك تشغيلها بطرق مختلفة لتحقيق التوازن الأمثل بين الأمان والأداء.
تتيح لك وظيفة وحدات التخزين الإضافية تسريع عملية تنزيل الصور إلى العقد أو القضاء عليها تمامًا.