إرشادات لتشغيل Buildah داخل الحاوية

ما هو جمال فصل وقت تشغيل الحاوية إلى مكونات أداة منفصلة؟ على وجه الخصوص ، حقيقة أن هذه الأدوات يمكن البدء في دمجها بحيث تحمي بعضها البعض.

ينجذب الكثير من الناس إلى فكرة بناء صور حاوية OCI في الداخل Kubernetes أو نظام مشابه. لنفترض أن لدينا CI / CD الذي يبني الصور باستمرار ، ثم شيء مثل ريد هات OpenShift/ سيكون Kubernetes مفيدًا جدًا فيما يتعلق بموازنة تحميل البناء. حتى وقت قريب ، منح معظم الأشخاص ببساطة وصول الحاويات إلى مقبس Docker وسمحوا لهم بتشغيل أمر إنشاء عامل ميناء. أظهرنا قبل بضع سنواتأن هذا غير آمن للغاية ، في الواقع ، إنه أسوأ من إعطاء الجذر بدون كلمة مرور أو sudo.

لذلك يحاول الناس باستمرار تشغيل 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 الخاصة بنا دون أي امتيازات الجذر. Fuse-overlay سريع جدًا ويعمل بشكل أفضل من محرك تخزين 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 / الحاويات. لذلك ، نحتاج إلى تحميل المحتوى على هذا المجلد ، وكيف نفعل ذلك سيؤثر بشكل كبير على سرعة إنشاء صور حاوية.

لنفكر في ثلاثة خيارات.

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 تنطبق عليه. يمكن تشغيل مثل هذه الحاوية مع عزل User Namespace عن طريق إضافة خيار مثل --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 socket ، حيث يتم حظر الحاوية بواسطة ميزات الأمان المتبقية ولا يمكن ببساطة التقاط وتشغيل أي حاوية على المضيف.

الأداء. هنا هو الحد الأقصى ، لأن التخزين المؤقت متضمن بالكامل. إذا قام 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 داخل صورة الحاوية ، لإخبار سائق التخزين باستخدام "extraimagestores" في / 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 / Shared داخل الحاوية في وضع القراءة فقط. لذلك ، عند العمل في حاوية ، يمكن لـ 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. لقد قمنا بزيادة مرونة العمل مع الصور بشكل كبير ، والآن يمكنك تشغيلها بعدة طرق لتحقيق أفضل توازن بين الأمان والأداء.

تتيح لك وظيفة التخزين الإضافي تسريع تنزيل الصور إلى العقد أو حتى إزالته تمامًا.

المصدر: www.habr.com