একটি পাত্রের ভিতরে Buildah চালানোর জন্য নির্দেশিকা

কন্টেইনার রানটাইমকে আলাদা টুল উপাদানে আলাদা করার সৌন্দর্য কী? বিশেষ করে, এই সরঞ্জামগুলি একত্রিত হতে শুরু করতে পারে যাতে তারা একে অপরকে রক্ষা করে।

অনেক মানুষ কন্টেইনারাইজড ওসিআই ইমেজ তৈরির ধারণা দ্বারা আকৃষ্ট হয় Kubernetes বা অনুরূপ সিস্টেম। ধরা যাক আমাদের একটা সিআই/সিডি আছে যা প্রতিনিয়ত ছবি তৈরি করে, তারপর এরকম কিছু রেড হ্যাট ওপেনশিফ্ট/Kubernetes বিল্ড লোড ব্যালেন্সিং পরিপ্রেক্ষিতে খুব দরকারী হবে. সম্প্রতি অবধি, বেশিরভাগ লোকেরা কেবল একটি ডকার সকেটে কন্টেইনারগুলিকে অ্যাক্সেস দেয় এবং তাদের ডকার বিল্ড কমান্ড চালানোর অনুমতি দেয়। আমরা কয়েক বছর আগে দেখিয়েছিযে এটি খুবই অনিরাপদ, আসলে এটি পাসওয়ার্ডহীন রুট বা সুডো দেওয়ার চেয়েও খারাপ।

তাই মানুষ প্রতিনিয়ত বিল্ডাকে কনটেইনারে করে চালানোর চেষ্টা করছে। সংক্ষেপে, আমরা তৈরি করেছি উদাহরণ কিভাবে, আমাদের মতে, একটি পাত্রের ভিতরে Buildah চালানো সর্বোত্তম, এবং সংশ্লিষ্ট ছবি পোস্ট করা quay.io/buildah. চল শুরু করি...

সমন্বয়

এই ছবিগুলি ডকারফাইলস থেকে তৈরি করা হয়েছে, যা ফোল্ডারের Buildah সংগ্রহস্থলে পাওয়া যাবে বিল্ডহিমেজ.
এখানে আমরা বিবেচনা করব ডকারফাইলের স্থিতিশীল সংস্করণ.

# 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 এর পরিবর্তে, আমরা কন্টেইনারের ভিতরে প্রোগ্রামটি ব্যবহার করি ফিউজ ওভারলে, কারণ বর্তমানে OverlayFS শুধুমাত্র মাউন্ট করতে পারে যদি আপনি এটিকে Linux ক্ষমতার মাধ্যমে SYS_ADMIN অনুমতি দেন। এবং আমরা আমাদের Buildah কন্টেইনারগুলিকে কোনো রুট সুবিধা ছাড়াই চালাতে চাই। ফিউজ-ওভারলে বেশ দ্রুত এবং VFS স্টোরেজ ড্রাইভারের চেয়ে ভালো পারফর্ম করে। লক্ষ্য করুন যে Fuse ব্যবহার করে Buildah কন্টেইনার চালানোর সময়, /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 এবং SECOMP নিয়মগুলিকে শিথিল করতে হবে, যা একটি সুরক্ষিত কন্টেইনার থেকে তৈরি করার জন্য আমাদের সেটআপের সাথে বিরোধ করবে৷

একটি ধারক ভিতরে Buildah চালান

উপরে আলোচনা করা 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

নিরাপত্তা। এটি কন্টেইনার তৈরির সবচেয়ে কম নিরাপদ উপায়, কারণ এটি কন্টেইনারকে হোস্টে স্টোরেজ পরিবর্তন করতে দেয় এবং সম্ভাব্যভাবে পডম্যান বা CRI-O-তে একটি দূষিত ছবি স্লিপ করতে পারে। উপরন্তু, আপনাকে SELinux বিচ্ছেদ নিষ্ক্রিয় করতে হবে যাতে 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 এর মধ্যে কিছু। একদিকে, কন্টেইনারগুলির হোস্টের সামগ্রীতে অ্যাক্সেস নেই এবং সেই অনুযায়ী, পডম্যান / CRI-O ইমেজ স্টোরেজের মধ্যে খারাপ কিছু স্লিপ করতে পারে না। অন্যদিকে, তার নিজস্ব প্রকল্পের মধ্যে, একটি ধারক অন্যান্য পাত্রের সমাবেশে হস্তক্ষেপ করতে পারে।

কর্মক্ষমতা. এখানে হোস্ট লেভেলে শেয়ার করা ক্যাশে ব্যবহার করার চেয়ে খারাপ, যেহেতু আপনি পডম্যান/সিআরআই-ও ব্যবহার করে ইতিমধ্যে ডাউনলোড করা ছবি ব্যবহার করতে পারবেন না। যাইহোক, একবার Buildah ছবিটি ডাউনলোড করলে, সেই ছবিটি প্রকল্পের মধ্যে পরবর্তী যেকোনো বিল্ডে ব্যবহার করা যেতে পারে।

অতিরিক্ত স্টোরেজ

У পাত্র/সঞ্চয়স্থান অতিরিক্ত স্টোর (অতিরিক্ত স্টোর) এর মতো একটি দুর্দান্ত জিনিস রয়েছে, যার জন্য ধন্যবাদ, কন্টেইনারগুলি শুরু করার এবং তৈরি করার সময়, কন্টেইনার ইঞ্জিনগুলি কেবল-পঠনযোগ্য ওভারলে মোডে বাহ্যিক চিত্র স্টোরগুলি ব্যবহার করতে পারে। প্রকৃতপক্ষে, আপনি storage.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 পডম্যান / CRI-O (হ্যালো, গতি) ব্যবহার করে ইতিমধ্যে ডাউনলোড করা যেকোন ছবি ব্যবহার করতে পারে, কিন্তু শুধুমাত্র নিজের স্টোরেজে লিখতে পারে (হ্যালো, নিরাপত্তা)। এছাড়াও মনে রাখবেন যে ধারকটির জন্য SELinux বিচ্ছেদ নিষ্ক্রিয় না করে এটি করা হয়।

গুরুত্বপূর্ণ nuance

কোনো অবস্থাতেই অন্তর্নিহিত সংগ্রহস্থল থেকে কোনো ছবি মুছে ফেলা উচিত নয়। অন্যথায়, Buildah কন্টেইনার বিপর্যস্ত হতে পারে.

এবং যে সব সুবিধা না.

অতিরিক্ত স্টোরেজের সম্ভাবনাগুলি উপরের দৃশ্যে সীমাবদ্ধ নয়। উদাহরণস্বরূপ, আপনি একটি শেয়ার্ড নেটওয়ার্ক স্টোরেজে সমস্ত কন্টেইনার ইমেজ রাখতে পারেন এবং সমস্ত Buildah কন্টেইনারে এটি অ্যাক্সেস করতে পারেন। ধরা যাক আমাদের শত শত ছবি আছে যা আমাদের সিআই/সিডি সিস্টেম নিয়মিত কনটেইনারাইজড ইমেজ তৈরি করতে ব্যবহার করে। আমরা এই সমস্ত চিত্রগুলিকে একটি একক স্টোরেজ হোস্টে কেন্দ্রীভূত করি এবং তারপরে, পছন্দের নেটওয়ার্ক স্টোরেজ সরঞ্জামগুলি (NFS, Gluster, Ceph, iSCSI, S3 ...) ব্যবহার করে, সমস্ত Buildah বা Kubernetes নোডের সাথে এই স্টোরেজটি ভাগ করি।

এখন এই নেটওয়ার্ক স্টোরেজটিকে /var/lib/shared-এ Buildah কন্টেইনারে মাউন্ট করা যথেষ্ট এবং এটিই - Buildah কন্টেইনারগুলিকে আর পুলের মাধ্যমে ছবি ডাউনলোড করতে হবে না। এইভাবে, আমরা প্রাক-জনসংখ্যার পর্যায়টি নিক্ষেপ করি এবং অবিলম্বে পাত্রগুলি রোল করার জন্য প্রস্তুত।

এবং অবশ্যই, এটি একটি লাইভ Kubernetes সিস্টেম বা কন্টেইনার অবকাঠামোর মধ্যে ব্যবহার করা যেতে পারে কোন ইমেজ টান ছাড়াই যে কোনও জায়গায় কন্টেইনারগুলি চালু এবং চালানোর জন্য। অধিকন্তু, যখন একটি কন্টেইনার রেজিস্ট্রি এটিতে একটি আপডেট করা ছবি আপলোড করার জন্য একটি পুশ অনুরোধ পায়, তখন এটি স্বয়ংক্রিয়ভাবে এই ছবিটি একটি শেয়ার্ড নেটওয়ার্ক স্টোরেজে পাঠাতে পারে, যেখানে এটি তাত্ক্ষণিকভাবে সমস্ত নোডের জন্য উপলব্ধ।

কন্টেইনার ছবি কখনও কখনও আকারে অনেক গিগাবাইট হতে পারে। অতিরিক্ত স্টোরেজের কার্যকারিতা নোড দ্বারা এই ধরনের ছবি ক্লোন করার প্রয়োজনীয়তা দূর করে এবং কন্টেইনারগুলিকে প্রায় তাত্ক্ষণিকভাবে চালু করে।

এছাড়াও, আমরা বর্তমানে একটি নতুন ওভারলে ভলিউম মাউন্ট বৈশিষ্ট্য নিয়ে কাজ করছি যা কন্টেইনারগুলিকে আরও দ্রুততর করে তুলবে৷

উপসংহার

Kubernetes/CRI-O, Podman, এমনকি Docker পরিবেশে একটি পাত্রের ভিতরে Buildah চালানো বেশ সম্ভব, এবং এটি docker.socket ব্যবহার করার চেয়ে সহজ এবং অনেক বেশি নিরাপদ। আমরা চিত্রগুলির সাথে কাজ করার নমনীয়তা ব্যাপকভাবে বৃদ্ধি করেছি এবং এখন আপনি নিরাপত্তা এবং কর্মক্ষমতার মধ্যে সেরা ভারসাম্যের জন্য বিভিন্ন উপায়ে সেগুলি চালাতে পারেন৷

অতিরিক্ত স্টোরেজগুলির কার্যকারিতা আপনাকে নোডগুলিতে চিত্রগুলির ডাউনলোডের গতি বাড়ানো বা এমনকি সম্পূর্ণরূপে নির্মূল করতে দেয়।

উত্স: www.habr.com