نام (NAME)

buildah-from - یک کانتینر کاری جدید، چه از ابتدا (scratch) و چه با استفاده از یک تصویر مشخص به عنوان نقطه شروع ایجاد می‌کند.

خلاصه دستور (SYNOPSIS)

buildah from [options] image

توضیحات (DESCRIPTION)

یک کانتینر کاری بر پایه نام تصویر مشخص‌شده ایجاد می‌کند. اگر نام تصویر ارائه‌شده "scratch" باشد، یک کانتینر خالی جدید ایجاد می‌شود. نام‌های تصاویر از قالب "transport":"details" استفاده می‌کنند.

چندین روش انتقال (transports) پشتیبانی می‌شوند:

dir:path
یک مسیر دایرکتوری محلی موجود (path) شامل مانیفست، بایگانی‌های تار لایه‌ها و امضاها در فایل‌های جداگانه. این یک قالب غیراستاندارد است که عمدتاً برای اشکال‌زدایی یا بازرسی بدون تغییر تصویر کاربرد دارد.

docker://docker-reference (پیش‌فرض)
تصویری در یک رجیستری که "Docker Registry HTTP API V2" را پیاده‌سازی می‌کند. به‌طور پیش‌فرض، از وضعیت مجوزدهی در $XDG_RUNTIME_DIR/containers/auth.json استفاده می‌کند، که با استفاده از (buildah login) تنظیم می‌شود. برای اطلاعات بیشتر به containers-auth.json(5) مراجعه کنید. اگر وضعیت مجوزدهی در آنجا یافت نشود، $HOME/.docker/config.json بررسی می‌شود که با استفاده از (docker login) تنظیم شده است.
اگر docker-reference شامل نام رجیستری نباشد، ابتدا با localhost مشورت می‌شود و سپس با هر رجیستری نام‌برده‌شده در پیکربندی registries.

docker-archive:path
تصویر به صورت فایلی با قالب podman load بازیابی می‌شود.

docker-daemon:docker-reference
تصویری با docker-reference که در فضای ذخیره‌سازی داخلی دیمن داکر ذخیره شده است. docker-reference باید شامل یک برچسب (tag) یا دایجست (digest) باشد. همچنین هنگام خواندن تصاویر، قالب می‌تواند به صورت docker-daemon:algo:digest (شناسه تصویر) نیز باشد.

oci:path:tag**
یک برچسب تصویر در یک دایرکتوری سازگار با "Open Container Image Layout Specification" در path.

oci-archive:path:tag
یک برچسب تصویر (tag) در یک دایرکتوری سازگار با "Open Container Image Layout Specification" در path.

مقدار بازگشتی (RETURN VALUE)

شناسه کانتینر (container ID) مربوط به کانتینری که ایجاد شده است. در صورت بروز خطا 1 بازگردانده می‌شود.

گزینه‌ها (OPTIONS)

--add-host=[]

افزودن یک نگاشت سفارشی میزبان به IP (host:ip)

افزودن یک خط به /etc/hosts. قالب به صورت hostname:ip است. گزینه --add-host می‌تواند چندین بار تعیین شود.

--arch="ARCH"

تنظیم ARCH تصویر مورد نظر برای واکشی روی مقدار ارائه‌شده به جای استفاده از معماری میزبان. (نمونه‌ها: arm، arm64، 386، amd64، ppc64le، s390x)

--authfile path

مسیر فایل احراز هویت. پیش‌فرض ${XDG_RUNTIME_DIR}/containers/auth.json است. برای اطلاعات بیشتر به containers-auth.json(5) مراجعه کنید. این فایل با استفاده از buildah login ایجاد می‌شود.

اگر وضعیت مجوزدهی در آنجا یافت نشود، $HOME/.docker/config.json بررسی می‌شود که با استفاده از docker login تنظیم شده است.

نکته: همچنین می‌توانید مسیر پیش‌فرض فایل احراز هویت را با تنظیم متغیر محیطی REGISTRY_AUTH_FILE بازنویسی کنید. export REGISTRY_AUTH_FILE=path

--cap-add=CAP_xxx

افزودن قابلیت (capability) مشخص‌شده به مجموعه پیش‌فرض قابلیت‌هایی که برای فراخوانی‌های بعدی buildah run که از این کانتینر استفاده می‌کنند، ارائه خواهد شد. برخی قابلیت‌ها به‌طور پیش‌فرض اعطا می‌شوند؛ این گزینه می‌تواند برای افزودن موارد بیشتر استفاده شود.

--cap-drop=CAP_xxx

حذف قابلیت مشخص‌شده از مجموعه پیش‌فرض قابلیت‌هایی که برای فراخوانی‌های بعدی buildah run که از این کانتینر استفاده می‌کنند، ارائه خواهد شد. قابلیت‌های CAP_CHOWN، CAP_DAC_OVERRIDE، CAP_FOWNER، CAP_FSETID، CAP_KILL، CAP_NET_BIND_SERVICE، CAP_SETFCAP، CAP_SETGID، CAP_SETPCAP و CAP_SETUID به‌طور پیش‌فرض اعطا می‌شوند؛ این گزینه می‌تواند برای حذف آن‌ها استفاده شود. فهرست قابلیت‌های پیش‌فرض در containers.conf(5) مدیریت می‌شود.

اگر یک قابلیت هم برای گزینه --cap-add و هم برای گزینه --cap-drop مشخص شود، صرف‌نظر از ترتیبی که گزینه‌ها داده شده‌اند، حذف خواهد شد.

--cert-dir path

استفاده از گواهی‌ها در path (*.crt، *.cert، *.key) برای اتصال به رجیستری. دایرکتوری پیش‌فرض گواهی‌ها /etc/containers/certs.d است.

--cgroup-parent=""

مسیر cgroups که cgroup کانتینر تحت آن ایجاد خواهد شد. اگر مسیر مطلق نباشد، مسیر نسبت به مسیر cgroups فرایند init در نظر گرفته می‌شود. اگر cgroups از قبل وجود نداشته باشند، ایجاد خواهند شد.

--cgroupns how

تنظیمات فضاهای نام IPC را زمانی که کانتینر متعاقباً برای buildah run استفاده می‌شود پیکربندی می‌کند. مقدار پیکربندی‌شده می‌تواند "" (رشته خالی) یا "private" برای نشان دادن اینکه یک فضای نام cgroup جدید باید ایجاد شود، یا "host" برای نشان دادن اینکه فضای نام cgroup که خود buildah در آن در حال اجرا است باید دوباره استفاده شود، باشد.

--cidfile ContainerIDFile

نوشتن شناسه کانتینر در فایل.

--cpu-period=0

محدود کردن دوره CFS (زمان‌بند کاملاً منصفانه) پردازنده

محدود کردن استفاده کانتینر از پردازنده. این پرچم به هسته می‌گوید استفاده کانتینر از پردازنده را به دوره‌ای که مشخص می‌کنید محدود کند.

--cpu-quota=0

محدود کردن سهمیه CFS (زمان‌بند کاملاً منصفانه) پردازنده

محدود کردن استفاده کانتینر از پردازنده. به‌طور پیش‌فرض، کانتینرها با منابع کامل پردازنده اجرا می‌شوند. این پرچم به هسته می‌گوید استفاده کانتینر از پردازنده را به سهمیه‌ای که مشخص می‌کنید محدود کند.

--cpu-shares, -c=0

سهم‌های پردازنده (وزن نسبی)

به‌طور پیش‌فرض، همه کانتینرها سهم یکسانی از چرخه‌های پردازنده دریافت می‌کنند. این نسبت می‌تواند با تغییر وزن سهم پردازنده کانتینر نسبت به وزن سایر کانتینرهای در حال اجرا اصلاح شود.

برای تغییر نسبت از مقدار پیش‌فرض 1024، از پرچم --cpu-shares برای تنظیم وزن به 2 یا بالاتر استفاده کنید.

این نسبت تنها زمانی اعمال خواهد شد که فرایندهای با بار پردازشی بالا در حال اجرا باشند. هنگامی که وظایف در یک کانتینر بیکار هستند، کانتینرهای دیگر می‌توانند از زمان پردازنده باقی‌مانده استفاده کنند. مقدار واقعی زمان پردازنده بسته به تعداد کانتینرهای در حال اجرا روی سیستم متغیر خواهد بود.

به عنوان مثال، سه کانتینر را در نظر بگیرید که یکی دارای cpu-share معادل 1024 و دو کانتینر دیگر دارای تنظیم cpu-share برابر با 512 هستند. هنگامی که فرایندها در هر سه کانتینر تلاش می‌کنند از %100 پردازنده استفاده کنند، کانتینر اول %50 از کل زمان پردازنده را دریافت خواهد کرد. اگر کانتینر چهارمی با cpu-share معادل 1024 اضافه کنید، کانتینر اول تنها %33 از پردازنده را دریافت می‌کند. کانتینرهای باقی‌مانده %16.5، %16.5 و %33 از پردازنده را دریافت خواهند کرد.

روی یک سیستم چند‌هسته‌ای، سهم‌های زمان پردازنده میان تمام هسته‌های پردازنده توزیع می‌شود. حتی اگر یک کانتینر به کمتر از %100 زمان پردازنده محدود شده باشد، می‌تواند از %100 هر هسته پردازنده به صورت جداگانه استفاده کند.

به عنوان مثال، سیستمی با بیش از سه هسته را در نظر بگیرید. اگر یک کانتینر {C0} را با -c=512 در حال اجرای یک فرایند، و کانتینر دیگری {C1} را با -c=1024 در حال اجرای دو فرایند راه‌اندازی کنید، این کار می‌تواند منجر به تقسیم سهم‌های پردازنده به شکل زیر شود:

PID    container	CPU	CPU share
100    {C0}		0	100% of CPU0
101    {C1}		1	100% of CPU1
102    {C1}		2	100% of CPU2

--cpuset-cpus=""

پردازنده‌هایی که اجازه اجرا در آن‌ها داده می‌شود (0-3, 0,1)

--cpuset-mems=""

گره‌های حافظه (MEMها) که اجازه اجرا در آن‌ها داده می‌شود (0-3, 0,1). تنها روی سیستم‌های NUMA موثر است.

اگر چهار گره حافظه روی سیستم خود دارید (0-3)، از --cpuset-mems=0,1 استفاده کنید؛ آنگاه فرایندها در کانتینر شما تنها از حافظه دو گره نخست حافظه استفاده خواهند کرد.

--creds creds

مقدار [username[:password]] برای استفاده در احراز هویت با رجیستری در صورت نیاز. اگر یک یا هر دو مقدار ارائه نشوند، یک اعلان در خط فرمان ظاهر می‌شود و مقدار می‌تواند وارد شود. گذرواژه بدون بازتاب وارد می‌شود.

--decryption-key key[:passphrase]

مقدار [key[:passphrase]] برای استفاده در رمزگشایی تصاویر. کلید می‌تواند به کلیدها و/یا گواهی‌ها اشاره کند. رمزگشایی با تمام کلیدها امتحان خواهد شد. اگر کلید با یک عبارت عبور (passphrase) محافظت شده باشد، ارسال آن در آرگومان الزامی است و در غیر این صورت حذف می‌شود.

--device=device

افزودن یک دستگاه میزبان، یا دستگاه‌های زیر یک دایرکتوری، به محیط فراخوانی‌های بعدی buildah run برای کانتینر کاری جدید. پارامتر اختیاری permissions می‌تواند برای مشخص کردن مجوزهای دستگاه با استفاده از یک یا چند مورد از r برای خواندن، w برای نوشتن و m برای mknod(2) استفاده شود.

مثال: --device=/dev/sdc:/dev/xvdc:rwm.

نکته: اگر host-device یک پیوند نمادین (symbolic link) باشد، ابتدا حل‌وفصل خواهد شد. کانتینر تنها شماره‌های عمده (major) و جزئی (minor) دستگاه میزبان را ذخیره خواهد کرد.

دستگاه برای اشتراک‌گذاری همچنین می‌تواند با استفاده از مشخصات واسط دستگاه کانتینر (CDI - Container Device Interface) مشخص شود (https://github.com/cncf-tags/container-device-interface).

نکته: اگر کاربر تنها از طریق یک گروه دارای حقوق دسترسی باشد، دسترسی به دستگاه از داخل یک کانتینر بدون ریشه (rootless) ناموفق خواهد بود. زمان اجرای crun(1) با افزودن گزینه --annotation run.oci.keep_original_groups=1 راهکاری برای این مورد ارائه می‌دهد.

--dns=[]

تنظیم سرورهای DNS سفارشی

این گزینه می‌تواند برای بازنویسی پیکربندی DNS ارائه‌شده به کانتینر استفاده شود. معمولاً زمانی این کار لازم است که پیکربندی DNS میزبان برای کانتینر نامعتبر باشد (برای نمونه 127.0.0.1). در این حالت، پرچم --dns برای هر بار اجرا ضروری است.

مقدار ویژه none می‌تواند برای غیرفعال کردن ایجاد /etc/resolv.conf در کانتینر توسط Buildah تعیین شود. فایل /etc/resolv.conf موجود در تصویر بدون تغییر استفاده خواهد شد.

--dns-option=[]

تنظیم گزینه‌های DNS سفارشی

--dns-search=[]

تنظیم دامنه‌های جستجوی DNS سفارشی

--format, -f oci | docker

کنترل قالب برای مانیفست و داده‌های پیکربندی تصویر ساخته‌شده. قالب‌های شناخته‌شده شامل oci (مشخصات OCI image-spec v1.0، پیش‌فرض) و docker (نسخه 2، با استفاده از قالب شِمای 2 برای مانیفست) هستند.

نکته: همچنین می‌توانید قالب پیش‌فرض را با تنظیم متغیر محیطی BUILDAH_FORMAT بازنویسی کنید. export BUILDAH_FORMAT=docker

--group-add=group | keep-groups

اختصاص گروه‌های اضافی به کاربر اصلی در حال اجرا درون فرایند کانتینر.

به کانتینر اجازه می‌دهد از دسترسی گروه تکمیلی کاربر استفاده کند. اگر سامانه‌های پرونده یا دستگاه‌ها تنها از طریق گروه کاربر بدون ریشه (rootless) قابل دسترسی باشند، این پرچم به زمان اجرای OCI اعلام می‌کند که دسترسی گروه را به درون کانتینر منتقل کند. در حال حاضر تنها با زمان اجرای OCI موسوم به crun در دسترس است. توجه: keep-groups مانعة‌الجمع است و گروه‌های دیگر را نمی‌توان با این پرچم مشخص کرد.

--http-proxy

به‌طور پیش‌فرض، در صورتی که متغیرهای محیطی پیشکار (proxy) برای فرایند Buildah تنظیم شده باشند، به درون کانتینر منتقل می‌شوند. این رفتار را می‌توان با تنظیم گزینه --http-proxy روی false غیرفعال کرد. متغیرهای محیطی منتقل‌شده شامل http_proxy، https_proxy، ftp_proxy، no_proxy و همچنین نگارش‌های با حروف بزرگ آن‌ها هستند.

پیش‌فرض true است.

--ipc how

پیکربندی فضاهای نام IPC را برای زمانی که کانتینر متعاقباً در buildah run استفاده شود، تنظیم می‌کند. مقدار پیکربندی‌شده می‌تواند "" (رشته خالی) یا "container" باشد تا نشان دهد که باید یک فضای نام IPC جدید ساخته شود، یا می‌تواند "host" باشد تا نشان دهد فضای نام IPC که خود Buildah در آن اجرا می‌شود باید بازاستفاده شود، یا می‌تواند مسیر یک فضای نام IPC باشد که پیش‌تر توسط فرایند دیگری در حال استفاده است.

--isolation type

کنترل می‌کند چه نوع جداسازی (isolation) برای اجرای فرایندها تحت buildah run به کار رود. نوع‌های شناخته‌شده عبارتند از oci (زمان اجرای سازگار با OCI، پیش‌فرض)، rootless (زمان اجرای سازگار با OCI که با پیکربندی تغییریافته فراخوانی می‌شود، همراه با افزودن --no-new-keyring به فراخوانی create آن، با استفاده مجدد از فضاهای نام شبکه و UTS میزبان، و ایجاد فضاهای نام اختصاصی IPC، PID، سوار کردن (mount) و کاربر؛ پیش‌فرض برای کاربران بدون امتیاز)، و chroot (یک لفاف داخلی که بیشتر به chroot(1) تمایل دارد تا فناوری کانتینر، با بازاستفاده از فضاهای نام گروه کنترل، شبکه، IPC و PID میزبان، و ایجاد فضاهای نام اختصاصی سوار کردن و UTS، و ایجاد فضاهای نام کاربر تنها هنگامی که برای نگاشت شناسه مورد نیاز باشند).

توجه: همچنین می‌توانید با مقداردهی متغیر محیطی BUILDAH_ISOLATION، نوع جداسازی پیش‌فرض را بازنویسی کنید. export BUILDAH_ISOLATION=oci

--memory, -m=""

محدودیت حافظه (قالب: []، که در آن واحد می‌تواند b، k، m یا g باشد)

به شما امکان می‌دهد حافظه در دسترس کانتینر را محدود کنید. اگر میزبان از حافظه swap پشتیبانی کند، تنظیم حافظه -m می‌تواند بزرگ‌تر از رم (RAM) فیزیکی باشد. اگر محدودیت 0 مشخص شود (عدم استفاده از -m)، حافظه کانتینر محدود نمی‌شود. محدودیت واقعی ممکن است به ضریبی از اندازه صفحه سیستم‌عامل گرد شود (این مقدار بسیار بزرگ خواهد بود، یعنی میلیون‌ها تریلیون).

--memory-swap="LIMIT"

یک مقدار محدودیت برابر با مجموع حافظه به علاوه swap. باید همراه با پرچم -m (--memory) استفاده شود. مقدار LIMIT برای swap همواره باید بزرگ‌تر از مقدار -m (--memory) باشد. به‌طور پیش‌فرض، مقدار LIMIT برای swap روی دو برابر مقدار --memory تنظیم خواهد شد.

قالب LIMIT به‌صورت <number>[<unit>] است. واحد می‌تواند b (بایت)، k (کیلوبایت)، m (مگابایت) یا g (گیگابایت) باشد. اگر واحدی مشخص نکنید، b به کار می‌رود. برای فعال‌سازی swap نامحدود، مقدار LIMIT را روی -1 قرار دهید.

--name name

یک name (نام) برای کانتینر کاری

--network=mode, --net=mode

پیکربندی فضاهای نام شبکه را برای زمانی که کانتینر متعاقباً در buildah run استفاده شود، تنظیم می‌کند.

مقادیر معتبر mode عبارتند از:

--os="OS"

تنظیم سیستم‌عامل تصویری که باید واکشی شود روی مقدار ارائه‌شده، به جای استفاده از سیستم‌عامل کنونی میزبان.

--pid how

پیکربندی فضاهای نام PID را برای زمانی که کانتینر متعاقباً در buildah run استفاده شود، تنظیم می‌کند. مقدار پیکربندی‌شده می‌تواند "" (رشته خالی) یا "container" باشد تا نشان دهد که باید یک فضای نام PID جدید ایجاد شود، یا می‌تواند "host" باشد تا نشان دهد فضای نام PID که خود Buildah در آن اجرا می‌شود باید بازاستفاده شود، یا می‌تواند مسیر یک فضای نام PID باشد که پیش‌تر توسط فرایند دیگری در حال استفاده است.

--platform="OS/ARCH[/VARIANT]"

تنظیم OS/ARCH تصویر مورد نظر برای واکشی روی مقدار ارائه‌شده به جای استفاده از سیستم‌عامل و معماری کنونی میزبان (به عنوان نمونه linux/arm).

جفت‌های OS/ARCH مواردی هستند که توسط زبان برنامه‌نویسی Go استفاده می‌شوند. در چندین مورد، مقدار ARCH برای یک پلتفرم با مقدار تولیدشده توسط ابزارهای دیگر مانند دستور arch تفاوت دارد. ترکیب‌های معتبر نام سیستم‌عامل و معماری به عنوان مقادیر $GOOS و $GOARCH در نشانی https://golang.org/doc/install/source#environment فهرست شده‌اند و همچنین با اجرای دستور go tool dist list قابل یافتن هستند.

اگرچه buildah from با کمال میل تصویری را برای هر پلتفرم موجود واکشی می‌کند، اما buildah run بدون کمک شبیه‌سازی ارائه‌شده توسط بسته‌هایی مانند qemu-user-static قادر به اجرای باینری‌های ارائه‌شده توسط آن تصویر نخواهد بود.

یادداشت (NOTE): گزینه --platform نباید در ترکیب با گزینه‌های --arch، --os یا --variant استفاده شود.

--pull

سیاست واکشی تصویر (Pull image policy). در صورت عدم تعیین، مقدار پیش‌فرض missing است. اگر یک آرگومان صریح --pull بدون هیچ مقداری ارائه شود، رفتار always به کار می‌رود.

--quiet, -q

در صورتی که نیاز به دریافت تصویر از مخزن باشد، از نمایش روند پیشرفت جلوگیری می‌کند.

--retry attempts

تعداد دفعات تلاش مجدد در صورت بروز خطا هنگام دریافت تصاویر از مخزن.

مقدار پیش‌فرض 3 است.

--retry-delay duration

مدت‌زمان تاخیر بین تلاش‌های مجدد در صورت بروز خطا هنگام دریافت تصاویر از مخزن.

مقدار پیش‌فرض 2s است.

--security-opt=[]

گزینه‌های امنیتی (Security Options)

"label=user:USER" : تنظیم کاربر برچسب برای کانتینر
"label=role:ROLE" : تنظیم نقش برچسب برای کانتینر
"label=type:TYPE" : تنظیم نوع برچسب برای کانتینر
"label=level:LEVEL" : تنظیم سطح برچسب برای کانتینر
"label=disable" : غیرفعال‌سازی محدودسازی برچسب برای کانتینر
"no-new-privileges" : جلوگیری از دستیابی فرایندهای کانتینر به مجوزهای بیشتر

"seccomp=unconfined" : غیرفعال‌سازی محدودسازی seccomp برای کانتینر
"seccomp=profile.json : فایل JSON شامل فراخوان‌های سیستمی مجاز برای استفاده به عنوان فیلتر seccomp

"apparmor=unconfined" : غیرفعال‌سازی محدودسازی apparmor برای کانتینر
"apparmor=your-profile" : تنظیم نمایه محدودسازی apparmor برای کانتینر

--shm-size=""

اندازه /dev/shm. قالب آن به صورت <number><unit> است. مقدار number باید بزرگتر از 0 باشد. واحد اختیاری است و می‌تواند b (بایت)، k (کیلوبایت)، m (مگابایت) یا g (گیگابایت) باشد. اگر واحد حذف شود، سیستم از بایت استفاده می‌کند. اگر اندازه به طور کامل حذف شود، سیستم از 64m استفاده می‌کند.

--tls-verify bool-value

الزام استفاده از HTTPS و اعتبارسنجی گواهی‌ها هنگام برقراری ارتباط با مخازن کانتینر (پیش‌فرض true است). هنگام برقراری ارتباط با یک مخزن ناامن نمی‌توان از اعتبارسنجی TLS استفاده کرد.

--ulimit type=soft-limit[:hard-limit]

محدودیت‌های منابع را برای اعمال روی فرایندهای اجراشده هنگام buildah run تعیین می‌کند. این گزینه می‌تواند چندین بار مشخص شود. انواع منابع شناخته‌شده عبارتند از:
"core": حداکثر اندازه تخلیه حافظه هسته (ulimit -c)
"cpu": حداکثر زمان پردازنده (ulimit -t)
"data": حداکثر اندازه بخش داده‌های یک فرایند (ulimit -d)
"fsize": حداکثر اندازه فایل‌های جدید (ulimit -f)
"locks": حداکثر تعداد قفل‌های فایل (ulimit -x)
"memlock": حداکثر مقدار حافظه قفل‌شده (ulimit -l)
"msgqueue": حداکثر مقدار داده در صف‌های پیام (ulimit -q)
"nice": تنظیم مقدار اولویت فرایند (nice -n, ulimit -e)
"nofile": حداکثر تعداد فایل‌های باز (ulimit -n)
"nofile": حداکثر تعداد فایل‌های باز (1048576)؛ هنگام اجرا توسط ریشه (root)
"nproc": حداکثر تعداد فرایندها (ulimit -u)
"nproc": حداکثر تعداد فرایندها (1048576)؛ هنگام اجرا توسط ریشه (root)
"rss": حداکثر اندازه حافظه فیزیکی فرایند (ulimit -m)
"rtprio": حداکثر اولویت زمان‌بندی بی‌درنگ (ulimit -r)
"rttime": حداکثر زمان اجرای بی‌درنگ بین فراخوان‌های سیستمی مسدودکننده
"sigpending": حداکثر تعداد سیگنال‌های در انتظار (ulimit -i)
"stack": حداکثر اندازه پشته (ulimit -s)

--userns how

پیکربندی فضاهای نام کاربری (User Namespaces) را هنگامی که کانتینر پس از آن برای buildah run استفاده می‌شود تنظیم می‌کند. مقدار پیکربندی‌شده می‌تواند "" (رشته خالی) یا "container" باشد تا نشان دهد یک فضای نام کاربری جدید باید ساخته شود، می‌تواند "host" باشد تا نشان دهد فضای نام کاربری که خود Buildah در آن اجرا می‌شود باید بازاستفاده شود، یا می‌تواند مسیری به یک فضای نام کاربری باشد که پیش‌تر توسط فرایند دیگری در حال استفاده است.

--userns-gid-map mapping

به طور مستقیم نگاشت GID را مشخص می‌کند که باید برای تنظیم مالکیت در سطح سیستم فایل بر محتوای کانتینر کاری استفاده شود. دستوراتی که هنگام پردازش دستورالعمل‌های RUN اجرا می‌شوند، به طور پیش‌فرض در فضاهای نام کاربری اختصاصی خود اجرا خواهند شد که با استفاده از نگاشت‌های UID و GID پیکربندی شده‌اند.

مدخل‌های این نگاشت به شکل یک یا چند سه‌تایی جداشده با دونقطه از GID آغازین درون کانتینر، یک GID آغازین متناظر در سطح میزبان، و تعداد شناسه‌های متوالی که مدخل نگاشت نشان می‌دهد هستند.

این گزینه بر تنظیم remap-gids در بخش options از /etc/containers/storage.conf ارجحیت دارد.

اگر این گزینه مشخص نشده باشد، اما یک تنظیم سراسری --userns-gid-map ارائه شده باشد، تنظیمات گزینه سراسری استفاده خواهد شد.

--userns-gid-map-group mapping

به طور مستقیم نگاشت GID را مشخص می‌کند که باید برای تنظیم مالکیت در سطح سیستم فایل بر محتوای کانتینر استفاده شود. دستورات اجراشده با استفاده از buildah run به طور پیش‌فرض در فضاهای نام کاربری اختصاصی خود اجرا می‌شوند که با استفاده از نگاشت‌های UID و GID پیکربندی شده‌اند.

مدخل‌های این نگاشت به شکل یک یا چند سه‌تایی از GID آغازین درون کانتینر، یک GID آغازین متناظر در سطح میزبان، و تعداد شناسه‌های متوالی که مدخل نگاشت نشان می‌دهد هستند.

این گزینه بر تنظیم remap-gids در بخش options از /etc/containers/storage.conf ارجحیت دارد.

اگر این گزینه مشخص نشده باشد، اما یک تنظیم سراسری --userns-gid-map ارائه شده باشد، تنظیمات گزینه سراسری استفاده خواهد شد.

اگر هیچ‌کدام از گزینه‌های --userns-uid-map-user یا --userns-gid-map-group یا --userns-gid-map مشخص نشده باشند، اما --userns-uid-map مشخص شده باشد، نگاشت GID برای استفاده از مقادیر عددی یکسان با نگاشت UID تنظیم خواهد شد.

نکته (NOTE): هنگامی که این گزینه توسط یک کاربر بدون ریشه (rootless) مشخص شود، نگاشت‌های تعیین‌شده نسبت به فضای نام کاربری بدون ریشه در کانتینر سنجیده می‌شوند، نه نسبت به میزبان آن‌گونه که در اجرای با ریشه (rootful) رخ می‌دهد.

--userns-gid-map-group group

مشخص می‌کند نگاشت GID که باید برای تنظیم مالکیت در سطح سیستم فایل بر محتوای کانتینر استفاده شود، می‌تواند در مدخل‌های مربوط به گروه مشخص‌شده در فایل /etc/subgid یافت شود. دستورات اجراشده با استفاده از buildah run به طور پیش‌فرض در فضاهای نام کاربری اختصاصی خود اجرا می‌شوند که با استفاده از نگاشت‌های UID و GID پیکربندی شده‌اند. اگر --userns-uid-map-user مشخص شده باشد، اما --userns-gid-map-group مشخص نشده باشد، Buildah فرض می‌کند نام کاربر مشخص‌شده نیز نام گروهی مناسب برای استفاده به عنوان تنظیم پیش‌فرض این گزینه است.

--userns-uid-map mapping

به طور مستقیم نگاشت UID را مشخص می‌کند که باید برای تنظیم مالکیت در سطح سیستم فایل بر محتوای کانتینر کاری استفاده شود. دستوراتی که هنگام پردازش دستورالعمل‌های RUN اجرا می‌شوند، به طور پیش‌فرض در فضاهای نام کاربری اختصاصی خود اجرا خواهند شد که با استفاده از نگاشت‌های UID و GID پیکربندی شده‌اند.

مدخل‌های این نگاشت به شکل یک یا چند سه‌تایی جداشده با دونقطه از UID آغازین درون کانتینر، یک UID آغازین متناظر در سطح میزبان، و تعداد شناسه‌های متوالی که مدخل نگاشت نشان می‌دهد هستند.

این گزینه بر تنظیم remap-uids در بخش options از /etc/containers/storage.conf ارجحیت دارد.

اگر این گزینه مشخص نشده باشد، اما یک تنظیم سراسری --userns-uid-map ارائه شده باشد، تنظیمات گزینه سراسری استفاده خواهد شد.

--userns-uid-map-user mapping

به طور مستقیم نگاشت UID را مشخص می‌کند که باید برای تنظیم مالکیت در سطح سیستم فایل بر محتوای کانتینر استفاده شود. دستورات اجراشده با استفاده از buildah run به طور پیش‌فرض در فضاهای نام کاربری اختصاصی خود اجرا می‌شوند که با استفاده از نگاشت‌های UID و GID پیکربندی شده‌اند.

مدخل‌های این نگاشت به شکل یک یا چند سه‌تایی از UID آغازین درون کانتینر، یک UID آغازین متناظر در سطح میزبان، و تعداد شناسه‌های متوالی که مدخل نگاشت نشان می‌دهد هستند.

این گزینه بر تنظیم remap-uids در بخش options از /etc/containers/storage.conf ارجحیت دارد.

اگر این گزینه مشخص نشده باشد، اما یک تنظیم سراسری --userns-uid-map ارائه شده باشد، تنظیمات گزینه سراسری استفاده خواهد شد.

اگر هیچ‌کدام از گزینه‌های --userns-uid-map-user یا --userns-gid-map-group یا --userns-uid-map مشخص نشده باشند، اما --userns-gid-map مشخص شده باشد، نگاشت UID برای استفاده از مقادیر عددی یکسان با نگاشت GID تنظیم خواهد شد.

نکته (NOTE): هنگامی که این گزینه توسط یک کاربر بدون ریشه (rootless) مشخص شود، نگاشت‌های تعیین‌شده نسبت به فضای نام کاربری بدون ریشه در کانتینر سنجیده می‌شوند، نه نسبت به میزبان آن‌گونه که در اجرای با ریشه (rootful) رخ می‌دهد.

--userns-uid-map-user user

مشخص می‌کند نگاشت UID که باید برای تنظیم مالکیت در سطح سیستم فایل بر محتوای کانتینر استفاده شود، می‌تواند در مدخل‌های مربوط به کاربر مشخص‌شده در فایل /etc/subuid یافت شود. دستورات اجراشده با استفاده از buildah run به طور پیش‌فرض در فضاهای نام کاربری اختصاصی خود اجرا می‌شوند که با استفاده از نگاشت‌های UID و GID پیکربندی شده‌اند. اگر --userns-gid-map-group مشخص شده باشد، اما --userns-uid-map-user مشخص نشده باشد، Buildah فرض می‌کند نام گروه مشخص‌شده نیز نام کاربری مناسبی برای استفاده به عنوان تنظیم پیش‌فرض این گزینه است.

--uts how

پیکربندی فضاهای نام UTS را هنگامی که کانتینر پس از آن برای buildah run استفاده می‌شود تنظیم می‌کند. مقدار پیکربندی‌شده می‌تواند "" (رشته خالی) یا "container" باشد تا نشان دهد یک فضای نام UTS جدید باید ساخته شود، یا می‌تواند "host" باشد تا نشان دهد فضای نام UTS که خود Buildah در آن اجرا می‌شود باید بازاستفاده شود، یا می‌تواند مسیری به یک فضای نام UTS باشد که پیش‌تر توسط فرایند دیگری در حال استفاده است.

--variant=""

گونه (variant) معماری تصویری که باید دریافت شود را تنظیم می‌کند.

--volume, -v[=[HOST-DIR:CONTAINER-DIR[:OPTIONS]]]

ایجاد یک اتصال پیوندی (bind mount). اگر مشخص کنید -v /HOST-DIR:/CONTAINER-DIR، ابزار Buildah مسیر /HOST-DIR در میزبان را به /CONTAINER-DIR درون کانتینر Buildah پیوند می‌زند. مقادیر OPTIONS فهرستی جداشده با کاما هستند و می‌توانند شامل موارد زیر باشند:

مسیر CONTAINER-DIR باید یک مسیر مطلق مانند /src/docs باشد. مسیر HOST-DIR نیز باید یک مسیر مطلق باشد. Buildah مسیر HOST-DIR را به مسیری که مشخص می‌کنید bind-mount می‌کند. برای نمونه، اگر /foo را به‌عنوان مسیر میزبان بدهید، Buildah محتویات /foo را در سیستم‌فایل کانتینر روی میزبان کپی کرده و آن را به درون کانتینر bind-mount می‌کند.

می‌توانید چندین گزینه -v را برای سوار کردن یک یا چند اتصال به یک کانتینر مشخص کنید.

اتصال‌های جلد حفاظت‌شده در برابر نوشتن (Write Protected Volume Mounts)

می‌توانید پسوند :ro یا :rw را به یک جلد اضافه کنید تا به ترتیب در حالت فقط‌خواندنی یا خواندنی-نوشتنی متصل شود. به‌طور پیش‌فرض، جلدها به‌صورت خواندنی-نوشتنی سوار می‌شوند. مثال‌ها را ببینید.

تغییر مالکیت اتصال‌های جلد (Chowning Volume Mounts)

به‌طور پیش‌فرض، Buildah مالک و گروه دایرکتوری‌های جلد منبع متصل‌شده به کانتینرها را تغییر نمی‌دهد. اگر کانتینری در یک فضای‌نام کاربری (user namespace) جدید ایجاد شود، UID و GID درون کانتینر ممکن است با UID و GID متفاوتی روی میزبان متناظر باشند.

پسوند :U به Buildah اعلام می‌کند تا بر پایه UID و GID درون کانتینر، از UID و GID درست میزبان استفاده کرده و مالک و گروه جلد منبع را تغییر دهد.

برچسب‌گذاری اتصال‌های جلد (Labeling Volume Mounts)

سامانه‌های برچسب‌گذاری مانند SELinux نیازمند قرارگیری برچسب‌های مناسب روی محتوای جلد متصل‌شده به کانتینر هستند. بدون برچسب، سامانه امنیتی ممکن است از استفاده فرایندهای در حال اجرا درون کانتینر از محتوا جلوگیری کند. به‌طور پیش‌فرض، Buildah برچسب‌های تنظیم‌شده توسط سیستم‌عامل را تغییر نمی‌دهد.

برای تغییر یک برچسب در بستر کانتینر، می‌توانید یکی از دو پسوند :z یا :Z را به اتصال جلد اضافه کنید. این پسوندها به Buildah می‌گویند که اشیای فایل روی جلدهای اشتراکی را دوباره برچسب‌گذاری کند. گزینه z به Buildah می‌گوید که دو کانتینر محتوای جلد را به اشتراک می‌گذارند. در نتیجه، Buildah محتوا را با یک برچسب محتوای مشترک برچسب‌گذاری می‌کند. برچسب‌های جلد مشترک به همه کانتینرها اجازه خواندن/نوشتن محتوا را می‌دهند. گزینه Z به Buildah می‌گوید که محتوا را با یک برچسب خصوصی غیرمشترک برچسب‌گذاری کند. تنها کانتینر فعلی می‌تواند از یک جلد خصوصی استفاده کند.

اتصال‌های جلد اورلی (Overlay Volume Mounts)

پرچم :O به Buildah اعلام می‌کند دایرکتوری را از میزبان با استفاده از سیستم‌فایل Overlay به‌عنوان یک فضای ذخیره‌سازی موقت سوار کند. کانتینرهای دستور RUN مجاز هستند محتویات درون نقطه اتصال را تغییر دهند و این تغییرات در فضای ذخیره‌سازی کانتینر در یک دایرکتوری جداگانه ذخیره می‌شوند. در اصطلاحات سامانه فایل Overlay، دایرکتوری منبع lower و دایرکتوری ذخیره‌سازی کانتینر upper خواهد بود. اصلاحات انجام‌شده در نقطه اتصال هنگام پایان اجرای دستور RUN از بین می‌روند، شبیه به یک نقطه اتصال tmpfs.

هر اجرای بعدی دستورهای RUN محتوای دایرکتوری منبع اصلی را می‌بیند؛ و هر تغییری از دستورات RUN قبلی دیگر وجود نخواهد داشت.

یک مورد استفاده از اتصال overlay، به اشتراک گذاشتن حافظه نهان بسته‌ها (package cache) از میزبان به درون کانتینر برای افزایش سرعت ساخت است.

نکته:

به‌طور پیش‌فرض جلدهای bind-mount شده private هستند. بدین معنا که هرگونه اتصالی که درون کانتینر انجام شود روی میزبان قابل مشاهده نخواهد بود و برعکس. این رفتار را می‌توان با مشخص کردن ویژگی انتشار اتصال جلد تغییر داد.

هنگامی که خط‌مشی انتشار اتصال روی shared تنظیم شود، هرگونه اتصال انجام‌شده درون کانتینر روی آن جلد هم برای میزبان و هم کانتینر قابل مشاهده خواهد بود. هنگامی که خط‌مشی انتشار اتصال روی slave تنظیم شود، انتشار یک‌طرفه اتصال فعال شده و هرگونه اتصال انجام‌شده روی میزبان برای آن جلد تنها در داخل کانتینر قابل مشاهده خواهد بود. برای کنترل ویژگی انتشار اتصال جلد، از پرچم‌های انتشار :[r]shared، :[r]slave، [r]private یا [r]unbindable استفاده کنید. ویژگی انتشار را فقط می‌توان برای جلدهای bind-mount شده تعیین کرد و نه جلدهای داخلی یا جلدهای نام‌گذاری‌شده. برای کارکرد انتشار اتصال روی نقطه اتصال منبع (نقطه اتصالی که دایرکتوری منبع روی آن سوار شده است)، باید ویژگی‌های انتشار مناسب را داشته باشد. برای جلدهای shared، نقطه اتصال منبع باید shared باشد. و برای جلدهای slave، اتصال منبع باید shared یا slave باشد. [1] ⟨#Footnote1⟩

از دستور df <source-dir> برای تعیین اتصال منبع و سپس از دستور findmnt -o TARGET,PROPAGATION <source-mount-dir> برای تعیین ویژگی‌های انتشار اتصال منبع استفاده کنید؛ اگر ابزار findmnt در دسترس نیست، نقطه اتصال منبع را می‌توان با بررسی مدخل mount در فایل /proc/self/mountinfo مشخص کرد. optional fields را بررسی کنید و ببینید آیا ویژگی انتشاری مشخص شده است یا خیر. shared:X به معنای shared بودن اتصال است، master:X به معنای slave بودن اتصال است و اگر چیزی وجود نداشته باشد به این معناست که اتصال private است. [1] ⟨#Footnote1⟩

برای تغییر ویژگی‌های انتشار یک نقطه اتصال از دستور mount استفاده کنید. برای نمونه، برای bind-mount کردن دایرکتوری منبع /foo دستورهای mount --bind /foo /foo و mount --make-private --make-shared /foo را اجرا کنید. این کار /foo را به یک نقطه اتصال shared تبدیل می‌کند. ویژگی‌های انتشار نقطه اتصال منبع را می‌توان مستقیماً تغییر داد. برای نمونه اگر / نقطه اتصال منبع برای /foo باشد، دستور mount --make-shared / را برای تبدیل / به یک اتصال shared به کار ببرید.

مثال (EXAMPLE)

buildah from --pull imagename

buildah from --pull docker://myregistry.example.com/imagename

buildah from docker-daemon:imagename:imagetag

buildah from --name mycontainer docker-archive:filename

buildah from oci-archive:filename

buildah from --name mycontainer dir:directoryname

buildah from --pull-always --name "mycontainer" myregistry.example.com/imagename

buildah from --tls-verify=false myregistry/myrepository/imagename:imagetag

buildah from --creds=myusername:mypassword --cert-dir ~/auth myregistry/myrepository/imagename:imagetag

buildah from --authfile=/tmp/auths/myauths.json myregistry/myrepository/imagename:imagetag

buildah from --memory 40m --cpu-shares 2 --cpuset-cpus 0,2 --security-opt label=level:s0:c100,c200 myregistry/myrepository/imagename:imagetag

buildah from --ulimit nofile=1024:1028 --cgroup-parent /path/to/cgroup/parent myregistry/myrepository/imagename:imagetag

buildah from --volume /home/test:/myvol:ro,Z myregistry/myrepository/imagename:imagetag

buildah from -v /home/test:/myvol:z,U myregistry/myrepository/imagename:imagetag

buildah from -v /var/lib/yum:/var/lib/yum:O myregistry/myrepository/imagename:imagetag

buildah from --arch=arm --variant v7 myregistry/myrepository/imagename:imagetag

متغیرهای محیطی (ENVIRONMENT)

BUILD_REGISTRY_SOURCES

متغیر BUILD_REGISTRY_SOURCES در صورت مقداردهی، به عنوان یک شیء JSON در نظر گرفته می‌شود که شامل فهرست‌هایی از نام‌های رجیستری ذیل کلیدهای insecureRegistries، blockedRegistries و allowedRegistries است.

هنگام دریافت (pull) تصویر از یک رجیستری، اگر نام رجیستری با هر یک از موارد موجود در فهرست blockedRegistries مطابقت داشته باشد، تلاش برای دریافت تصویر رد می‌شود. اگر در فهرست allowedRegistries رجیستری‌هایی وجود داشته باشند و نام رجیستری در فهرست نباشد، تلاش برای دریافت رد می‌شود.

TMPDIR متغیر محیطی TMPDIR به کاربر امکان می‌دهد محل ذخیره پرونده‌های موقت را هنگام دریافت و ارسال (pull و push) تصاویر مشخص کند. مقدار پیش‌فرض '/var/tmp' است.

پرونده‌ها (FILES)

registries.conf (/etc/containers/registries.conf)

پرونده registries.conf پرونده پیکربندی است که مشخص می‌کند هنگام تکمیل نام‌های تصاویری که فاقد بخش رجیستری یا دامنه هستند، باید به کدام رجیستری‌های کانتینر مراجعه شود.

policy.json (/etc/containers/policy.json)

پرونده سیاست امضا. این پرونده سیاست اعتماد را برای تصاویر کانتینر تعریف می‌کند. تعیین می‌کند کدام رجیستری‌های کانتینر می‌توانند برای تصاویر استفاده شوند و این‌که آیا ابزار باید به تصاویر اعتماد کند یا خیر.

همچنین ببینید (SEE ALSO)

buildah(1), buildah-pull(1), buildah-login(1), docker-login(1), namespaces(7), pid_namespaces(7), containers-policy.json(5), containers-registries.conf(5), user_namespaces(7), containers.conf(5), containers-auth.json(5)

پانویس‌ها (FOOTNOTES)

۱: پروژه Buildah به فراگیری، از ارزش‌های بنیادین متن‌باز، متعهد است. اصطلاحات انتشار سوارکردن (mount propagation) شامل master و slave که در این‌جا استفاده شده، مشکل‌ساز و تفرقه‌افکن است و باید دگرگون شود. با این حال، این اصطلاحات هم‌اکنون درون هسته لینوکس استفاده می‌شوند و در این مقطع زمانی باید به همان صورت به کار روند. هنگامی که نگه‌دارندگان هسته این کاربرد را اصلاح کنند، Buildah بی‌درنگ از آن پیروی خواهد کرد.