کنٹینر کے اندر بلڈہ چلانے کے لیے رہنما خطوط

کنٹینر رن ٹائم کو الگ الگ ٹولنگ اجزاء میں ڈیکپل کرنے کی خوبصورتی کیا ہے؟ خاص طور پر، ان آلات کو جوڑنا شروع ہوسکتا ہے تاکہ وہ ایک دوسرے کی حفاظت کریں۔

بہت سے لوگ اندر کنٹینرائزڈ OCI امیجز بنانے کے خیال کی طرف راغب ہوتے ہیں۔ Kubernetes یا اسی طرح کا نظام۔ ہم کہتے ہیں کہ ہمارے پاس ایک CI/CD ہے جو مسلسل تصاویر جمع کرتا ہے، پھر کچھ اس طرح ریڈ ہاٹ اوپن شفٹ/Kubernetes تعمیرات کے دوران بوجھ کے توازن کے لحاظ سے کافی مفید ثابت ہوں گے۔ کچھ عرصہ پہلے تک، زیادہ تر لوگوں نے کنٹینرز کو ڈوکر ساکٹ تک رسائی دی اور انہیں ڈوکر بلڈ کمانڈ چلانے کی اجازت دی۔ کئی سال پہلے ہم نے دکھایاکہ یہ بہت غیر محفوظ ہے، درحقیقت یہ پاس ورڈ لیس روٹ یا سوڈو دینے سے بھی بدتر ہے۔

اسی لیے لوگ مسلسل بلڈہ کو کنٹینر میں چلانے کی کوشش کرتے ہیں۔ مختصر میں، ہم نے پیدا کیا مثال کے طور پر ہماری رائے میں، بلڈہ کو کنٹینر کے اندر چلانا کس طرح بہتر ہے، اور اس سے متعلقہ تصاویر پوسٹ کی جائیں۔ quay.io/buildah. آو شروع کریں...

ایڈجسٹمنٹ

یہ تصاویر Dockerfiles سے بنائی گئی ہیں، جو فولڈر میں Buildah ذخیرہ میں دیکھی جا سکتی ہیں۔ تعمیر کی تصویر.
یہاں ہم دیکھیں گے۔ 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 صرف اس صورت میں ماؤنٹ ہو سکتا ہے جب آپ اسے لینکس کی صلاحیتوں کا استعمال کرتے ہوئے SYS_ADMIN کی اجازت دیں۔ اور ہم اپنے بلڈہ کنٹینرز کو بغیر کسی روٹ مراعات کے چلانا چاہتے ہیں۔ فیوز اوورلے کافی تیزی سے کام کرتا ہے اور اس کی کارکردگی 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 کنٹینر کو کہہ رہے ہیں کہ وہ بطور ڈیفالٹ کروٹ آئسولیشن کے ساتھ چلائیں۔ یہاں اضافی موصلیت کی ضرورت نہیں ہے، کیونکہ ہم پہلے سے ہی ایک کنٹینر میں کام کر رہے ہیں۔ Buildah کے لیے اپنے نام کی جگہ سے علیحدہ کنٹینرز بنانے کے لیے، SYS_ADMIN استحقاق درکار ہے، جس کے لیے کنٹینر کے SELinux اور SECOMP کے قوانین میں نرمی کی ضرورت ہوگی، جو کہ محفوظ کنٹینر سے تعمیر کرنے کی ہماری ترجیح کے خلاف ہے۔

کنٹینر کے اندر بلڈہ چل رہا ہے۔

اوپر زیر بحث Buildah کنٹینر امیج ڈایاگرام آپ کو اس طرح کے کنٹینرز کو لانچ کرنے کے طریقوں کو لچکدار طریقے سے تبدیل کرنے کی اجازت دیتا ہے۔

رفتار بمقابلہ حفاظت

کمپیوٹر سیکیورٹی ہمیشہ عمل کی رفتار اور اس کے گرد کتنا تحفظ لپیٹے ہوئے ہے کے درمیان ایک سمجھوتہ ہوتا ہے۔ یہ بیان کنٹینرز کو جمع کرتے وقت بھی درست ہے، لہذا ذیل میں ہم اس طرح کے سمجھوتے کے اختیارات پر غور کریں گے۔

اوپر زیر بحث کنٹینر کی تصویر اپنے اسٹوریج کو /var/lib/containers میں رکھے گی۔ لہذا، ہمیں اس فولڈر میں مواد کو ماؤنٹ کرنے کی ضرورت ہے، اور ہم یہ کیسے کرتے ہیں کنٹینر کی تصاویر بنانے کی رفتار کو بہت متاثر کرے گا۔

آئیے تین آپشنز پر غور کریں۔

اختیار 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. اگر آپ کو ڈوکر سطح کی کارکردگی کی ضرورت ہے، تو آپ میزبان کنٹینر/اسٹوریج کو براہ راست کنٹینر میں ماؤنٹ کر سکتے ہیں۔

# 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 کنٹینر میں عمل میزبان پر موجود اسٹوریج کے ساتھ تعامل کرسکیں۔ نوٹ کریں کہ یہ آپشن اب بھی ڈاکر ساکٹ سے بہتر ہے کیونکہ کنٹینر کو باقی حفاظتی خصوصیات کے ذریعے بند کر دیا جاتا ہے اور یہ میزبان پر کنٹینر کو آسانی سے نہیں چلا سکتا۔

کارکردگی یہاں یہ زیادہ سے زیادہ ہے، چونکہ کیشنگ مکمل طور پر استعمال ہوتی ہے۔ اگر 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 امیج اسٹوریج میں کوئی خراب چیز نہیں پھسل سکتی۔ دوسری طرف، اس کے ڈیزائن کے حصے کے طور پر، ایک کنٹینر دوسرے کنٹینرز کی اسمبلی میں مداخلت کر سکتا ہے۔

کارکردگی یہاں یہ میزبان کی سطح پر مشترکہ کیش استعمال کرنے سے بھی بدتر ہے، کیونکہ آپ پوڈ مین/سی آر آئی-او کا استعمال کرتے ہوئے پہلے ہی ڈاؤن لوڈ کی گئی تصاویر استعمال نہیں کر سکتے۔ تاہم، ایک بار جب Buildah تصویر کو ڈاؤن لوڈ کر لیتا ہے، تو اس تصویر کو پروجیکٹ کے اندر آنے والی کسی بھی تعمیر میں استعمال کیا جا سکتا ہے۔

اضافی اسٹوریج

У کنٹینرز/اسٹوریج اضافی اسٹورز (اضافی اسٹورز) جیسی اچھی چیز ہے، جس کی بدولت کنٹینرز کو لانچ کرتے اور بناتے وقت، کنٹینر انجن بیرونی امیج اسٹورز کو صرف پڑھنے کے لیے اوورلے موڈ میں استعمال کرسکتے ہیں۔ بنیادی طور پر، آپ store.conf فائل میں صرف پڑھنے کے لیے ایک یا زیادہ سٹوریجز شامل کر سکتے ہیں تاکہ جب آپ کنٹینر شروع کریں، کنٹینر انجن ان میں مطلوبہ تصویر تلاش کرے۔ مزید یہ کہ، یہ رجسٹری سے تصویر کو صرف اسی صورت میں ڈاؤن لوڈ کرے گا جب اسے ان میں سے کسی بھی سٹوریج میں نہ ملے۔ کنٹینر انجن صرف قابل تحریر اسٹوریج پر لکھ سکے گا...

اگر آپ اوپر سکرول کرتے ہیں اور ڈاکر فائل کو دیکھتے ہیں جسے ہم تصویر 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/shared فولڈر میں "additionalimagestores" استعمال کرے۔ اور اگلی لائن میں ہم ایک مشترکہ فولڈر بناتے ہیں اور کچھ لاک فائلیں شامل کرتے ہیں تاکہ کنٹینرز/اسٹوریج سے کوئی زیادتی نہ ہو۔ بنیادی طور پر، ہم صرف ایک خالی کنٹینر امیج اسٹور بنا رہے ہیں۔

اگر آپ کنٹینرز/اسٹوریج کو اس فولڈر سے اونچی سطح پر لگاتے ہیں، تو 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/containers/storage صرف پڑھنے کے موڈ میں کنٹینر کے اندر /var/lib/shared پر نصب ہے۔ لہذا، ایک کنٹینر میں کام کرتے ہوئے، Buildah ایسی کوئی بھی تصویر استعمال کر سکتا ہے جو پہلے Podman/CRI-O (ہیلو، سپیڈ) کا استعمال کرتے ہوئے ڈاؤن لوڈ کی گئی تھیں، لیکن صرف اپنے اسٹوریج (ہیلو، سیکیورٹی) پر لکھ سکتی ہیں۔ یہ بھی نوٹ کریں کہ یہ کنٹینر کے لیے SELinux علیحدگی کو غیر فعال کیے بغیر کیا جاتا ہے۔

اہم نرس

کسی بھی حالت میں آپ کو بنیادی ذخیرہ سے کسی بھی تصویر کو حذف نہیں کرنا چاہئے۔ بصورت دیگر، بلڈہ کنٹینر کریش ہو سکتا ہے۔

اور یہ تمام فوائد نہیں ہیں۔

اضافی سٹوریج کے امکانات مندرجہ بالا منظر نامے تک محدود نہیں ہیں۔ مثال کے طور پر، آپ کنٹینر کی تمام تصاویر کو مشترکہ نیٹ ورک سٹوریج پر رکھ سکتے ہیں اور Buildah کے تمام کنٹینرز تک اس تک رسائی دے سکتے ہیں۔ ہم کہتے ہیں کہ ہمارے پاس سینکڑوں تصاویر ہیں جنہیں ہمارا CI/CD سسٹم باقاعدگی سے کنٹینر امیجز بنانے کے لیے استعمال کرتا ہے۔ ہم ان تمام تصاویر کو ایک سٹوریج ہوسٹ پر مرکوز کرتے ہیں اور پھر، ترجیحی نیٹ ورک سٹوریج ٹولز (NFS, Gluster, Ceph, ISCSI, S3...) کا استعمال کرتے ہوئے، ہم تمام Buildah یا Kubernetes نوڈس تک اس سٹوریج تک عمومی رسائی کھولتے ہیں۔

اب اس نیٹ ورک اسٹوریج کو بلڈہ کنٹینر میں /var/lib/shared پر لگانا کافی ہے اور بس - Buildah کنٹینرز کو اب پل کے ذریعے تصاویر ڈاؤن لوڈ کرنے کی ضرورت نہیں ہے۔ اس طرح، ہم آبادی سے پہلے کے مرحلے کو باہر پھینک دیتے ہیں اور فوری طور پر کنٹینرز کو رول آؤٹ کرنے کے لیے تیار ہیں۔

اور بلاشبہ، یہ لائیو Kubernetes سسٹم یا کنٹینر انفراسٹرکچر کے اندر استعمال کیا جا سکتا ہے تاکہ کنٹینرز کو کسی بھی جگہ تصاویر کو ڈاؤن لوڈ کیے بغیر لانچ کیا جا سکے۔ مزید برآں، کنٹینر رجسٹری، اس پر اپڈیٹ شدہ تصویر اپ لوڈ کرنے کے لیے پش ریکوئسٹ وصول کرتی ہے، خود بخود اس تصویر کو مشترکہ نیٹ ورک اسٹوریج میں بھیج سکتی ہے، جہاں یہ فوری طور پر تمام نوڈس کے لیے دستیاب ہو جاتی ہے۔

کنٹینر کی تصاویر کبھی کبھی سائز میں کئی گیگا بائٹس تک پہنچ سکتی ہیں۔ اضافی سٹوریج کی فعالیت آپ کو نوڈس میں اس طرح کی تصاویر کی کلوننگ سے بچنے کی اجازت دیتی ہے اور کنٹینرز کو لانچ کرنے کو تقریباً فوری بنا دیتی ہے۔

اس کے علاوہ، ہم فی الحال اوورلے والیوم ماؤنٹس نامی ایک نئی خصوصیت پر کام کر رہے ہیں، جو کنٹینرز کی تعمیر کو اور بھی تیز تر بنائے گا۔

حاصل يہ ہوا

Kubernetes/CRI-O، Podman، یا یہاں تک کہ Docker میں کنٹینر کے اندر Buildah کو چلانا docker.socket استعمال کرنے سے زیادہ قابل عمل، آسان اور زیادہ محفوظ ہے۔ ہم نے امیجز کے ساتھ کام کرنے کی لچک کو بہت بڑھا دیا ہے، لہذا آپ انہیں سیکیورٹی اور کارکردگی کے درمیان توازن کو بہتر بنانے کے لیے مختلف طریقوں سے چلا سکتے ہیں۔

اضافی اسٹوریج کی فعالیت آپ کو نوڈس پر تصاویر کی ڈاؤن لوڈنگ کو تیز کرنے یا مکمل طور پر ختم کرنے کی اجازت دیتی ہے۔

ماخذ: www.habr.com