.nh
.TH buildah-build "1" "April 2017" "buildah"
.SH "نام (NAME)"
.PP
buildah-build \- ساخت ایمیج‌های کانتینر با استفاده از دستورالعمل‌های Containerfile یا Dockerfile

.SH "خلاصه دستور (SYNOPSIS)"
.PP
\fBbuildah build\fP [\fIگزینه‌ها\fP] [\fIبافت\fP]

.PP
\fBbuildah bud\fP [\fIگزینه‌ها\fP] [\fIبافت\fP]

.SH "توضیحات (DESCRIPTION)"
.PP
یک ایمیج را با استفاده از دستورالعمل‌های موجود در یک یا چند Containerfile یا Dockerfile و یک دایرکتوری بافت ساخت (build context) مشخص می‌سازد. یک Containerfile از نظر داخلی از نحوی مشابه Dockerfile استفاده می‌کند. در این مستند، فایلی که با عنوان Containerfile نامیده می‌شود می‌تواند فایلی با نام 'Containerfile' یا 'Dockerfile' باشد.

.PP
دایرکتوری بافت ساخت می‌تواند به عنوان یک آدرس URL از نوع http(s) مربوط به یک بایگانی (آرشیو)، یک مخزن git یا یک Containerfile مشخص شود.

.PP
اگر هیچ دایرکتوری بافتی مشخص نشود، Buildah دایرکتوری کاری فعلی را به عنوان بافت ساخت در نظر می‌گیرد که باید حاوی یک Containerfile باشد.

.PP
فایل‌های Containerfile که پسوند ".in" دارند، از طریق cpp(1) پیش‌پردازش خواهند شد. این قابلیت می‌تواند برای تجزیه Containerfileها به چندین بخش قابل استفاده مجدد که از طریق دستورالعمل \fB#include\fP در CPP قابل استفاده هستند، مفید باشد. توجه داشته باشید که فایل Containerfile.in همچنان می‌تواند توسط سایر ابزارها هنگام پیش‌پردازش دستی از طریق \fBcpp -E\fR\& استفاده شود. هرگونه کامنت (خطوطی که با \fB#\fR شروع می‌شوند) در فایل(های) Containerfile اضافه شده که جزو دستورات پیش‌پردازنده نباشند، در حین ساخت به عنوان هشدار چاپ خواهند شد.

.PP
هنگامی که آدرس URL یک بایگانی باشد، محتویات URL در یک مکان موقت دانلود شده و قبل از اجرا استخراج می‌شود.

.PP
هنگامی که آدرس URL یک Containerfile باشد، فایل در یک مکان موقت دانلود می‌شود.

.PP
هنگامی که یک مخزن Git به عنوان آدرس URL تنظیم می‌شود، مخزن به صورت محلی کلون شده و سپس به عنوان بافت ساخت استفاده می‌شود. می‌توان از یک شاخه غیرپیش‌فرض (یا شناسه کامیت) و زیردایرکتوری از مخزن git کلون‌شده با درج نام آن‌ها در انتهای URL به شکل \fBmyrepo.git#mybranch:subdir\fR، \fBmyrepo.git#mycommit:subdir\fR، یا در صورتی که زیردایرکتوری باید از شاخه پیش‌فرض استفاده شود به شکل \fBmyrepo.git#:subdir\fR استفاده کرد.

.SH "گزینه‌ها (OPTIONS)"
.PP
\fB--add-host\fP=[]

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

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

.PP
به جای آدرس IP، می‌توان فلگ ویژه host-gateway را مشخص کرد. این فلگ به یک آدرس IP تبدیل می‌شود که کانتینر می‌تواند از آن برای اتصال به میزبان استفاده کند. آدرس IP انتخاب‌شده به پیکربندی شبکه شما بستگی دارد، بنابراین هیچ تضمینی وجود ندارد که Buildah بتواند آدرس host-gateway را به صورت خودکار تعیین کند، که در این صورت Buildah با پیام خطا متوقف خواهد شد. شما می‌توانید این آدرس IP را با استفاده از گزینه host_containers_internal_ip در containers.conf بازنویسی کنید.

.PP
آدرس host-gateway همچنین توسط Buildah برای افزودن خودکار نام‌های میزبان host.containers.internal و host.docker.internal به /etc/hosts استفاده می‌شود. شما می‌توانید با تعیین گزینه --no-hosts یا با تنظیم host_containers_internal_ip="none" در containers.conf از این کار جلوگیری کنید. اگر هیچ آدرس host-gateway به صورت دستی پیکربندی نشده باشد و Buildah نتواند آدرس IP را به طور خودکار تعیین کند، Buildah بدون اعلام خطا از افزودن این نام‌های میزبان داخلی به /etc/hosts صرف‌نظر می‌کند. اگر Buildah درون یک ماشین مجازی با استفاده از podman machine در حال اجرا باشد (این شامل میزبان‌های مک و ویندوز می‌شود)، Buildah از افزودن نام‌های میزبان داخلی به /etc/hosts صرف‌نظر می‌کند، مگر اینکه یک آدرس IP به صورت دستی پیکربندی شده باشد؛ در عوض نام‌های میزبان داخلی توسط حل‌کننده DNS موسوم به gvproxy حل می‌شوند.

.PP
برنامه Buildah به طور پیش‌فرض از فایل /etc/hosts میزبان به عنوان پایه استفاده می‌کند، یعنی هر نام میزبانی که در این فایل وجود داشته باشد، در فایل /etc/hosts کانتینر نیز حضور خواهد داشت. یک فایل پایه متفاوت می‌تواند با استفاده از پیکربندی base_hosts_file در containers.conf تنظیم شود.

.PP
\fB--all-platforms\fP

.PP
به جای ساخت برای مجموعه‌ای از پلتفرم‌های مشخص‌شده با گزینه \fB--platform\fP، ایمیج‌های پایه ساخت را بازرسی می‌کند و برای تمام پلتفرم‌هایی که همگی در آن‌ها در دسترس هستند، فرآیند ساخت را انجام می‌دهد. مراحلی که از \fIscratch\fP به عنوان نقطه شروع استفاده می‌کنند قابل بازرسی نیستند، بنابراین حداقل یک مرحله غیر \fIscratch\fP باید وجود داشته باشد تا تشخیص به درستی کار کند.

.PP
\fB--annotation\fP \fIannotation[=value]\fP

.PP
یک یادداشت ایمیج (\fIannotation\fP) (مانند annotation=\fIvalue\fP) را به فراداده ایمیج اضافه می‌کند. می‌تواند چندین بار استفاده شود.
اگر \fIannotation\fP نام‌گذاری شود اما نه \fB=\fR و نه یک \fBvalue\fR ارائه نشود، آنگاه \fIannotation\fP روی یک مقدار خالی تنظیم می‌شود.

.PP
نکته: این اطلاعات در قالب‌های ایمیج Docker وجود ندارد، بنابراین هنگام نوشتن ایمیج‌ها در قالب‌های Docker نادیده گرفته می‌شود.

.PP
\fB--arch\fP="ARCH"

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

.PP
\fB--authfile\fP \fIpath\fP

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

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

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

.PP
\fB--build-arg\fP \fIarg=value\fP

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

.PP
لطفاً برای مشاهده فهرست متغیرهایی که می‌توانند در زمان اجرا درون Containerfile بازنویسی شوند، به بخش متغیرهای زمان ساخت (BUILD TIME VARIABLES)
\[la]#build\-time\-variables\[ra] مراجعه کنید.

.PP
\fB--build-arg-file\fP \fIpath\fP

.PP
فایلی حاوی خطوطی از آرگومان‌های ساخت به فرم arg=value را مشخص می‌کند. نام فایل پیشنهادی argfile.conf است.

.PP
خطوط توضیحات (کامنت) که با \fB#\fR شروع می‌شوند، به همراه خطوط خالی نادیده گرفته می‌شوند. سایر خطوط باید در قالب \fBarg=value\fR باشند که به \fB--build-arg\fR\& داده می‌شود.

.PP
اگر چندین آرگومان از طریق گزینه‌های \fB--build-arg-file\fR و \fB--build-arg\fR ارائه شوند، آرگومان‌های ساخت بین تمامی فایل‌های ارائه‌شده و آرگومان‌های خط فرمان ادغام خواهند شد.

.PP
هر فایلی که در گزینه \fB--build-arg-file\fR مشخص شود، قبل از آرگومان‌های ارائه‌شده از طریق گزینه \fB--build-arg\fR خوانده خواهد شد.

.PP
هنگامی که یک نام آرگومان مشخص چندین بار تعیین شود، آخرین نمونه همان مقداری است که به فرآیند ساخت نهایی ارسال می‌شود. این بدان معناست که مقادیر \fB--build-arg\fR همیشه مقادیر موجود در \fB--build-arg-file\fR\& را بازنویسی و باطل می‌کنند.

.PP
\fB--build-context\fP \fIname=value\fP

.PP
یک بافت ساخت اضافی را با استفاده از نام کوتاه و مکان آن مشخص می‌کند. به بافت‌های ساخت اضافی می‌توان به همان شیوه‌ای که به مراحل مختلف در دستورالعمل \fBCOPY\fR دسترسی داریم، ارجاع داد.

.PP
مقادیر معتبر می‌توانند موارد زیر باشند:
* دایرکتوری محلی – برای مثال --build-context project2=../path/to/project2/src
* آدرس اینترنتی HTTP به یک tarball – برای مثال --build-context src=https://example.org/releases/src.tar
* ایمیج کانتینر – مشخص‌شده با پیشوند container-image://، برای مثال --build-context alpine=container-image://alpine:3.15 (همچنین docker:// و docker-image:// را نیز می‌پذیرد)

.PP
در سمت Containerfile، می‌توانید در تمامی دستوراتی که پارامتر «from» را می‌پذیرند به این بافت ساخت ارجاع دهید.
نمونه نحوه استفاده به این صورت است:

.EX
FROM [name]
COPY --from=[name] ...
RUN --mount=from=[name] …
.EE

.PP
مقدار \fB[name]\fR با اولویت زیر مطابقت داده می‌شود:

.RS
.IP \(bu 2
بافت ساخت نام‌گذاری‌شده که با --build-context [name]=.. تعریف شده است
.IP \(bu 2
مرحله تعریف‌شده با AS [name] درون Containerfile
.IP \(bu 2
ایمیج [name]، چه محلی و چه در یک رجیستری از راه دور

.RE

.PP
\fB--cache-from\fP

.PP
مخزنی که به عنوان فهرست احتمالی منابع کش استفاده می‌شود. هنگامی که مشخص شود، Buildah تلاش خواهد کرد تا ایمیج‌های کش را در مخازن مشخص‌شده جستجو کند و به جای اجرای واقعی مراحل ساخت به صورت محلی، اقدام به دریافت (pull) ایمیج‌های کش خواهد کرد. Buildah تنها زمانی برای دریافت ایمیج‌های کش‌شده قبلی تلاش می‌کند که آن‌ها به عنوان تطابق‌های معتبر کش (cache hits) در نظر گرفته شوند.

.PP
از گزینه \fB--cache-to\fR برای پر کردن یک یا چند مخزن راه دور با محتوای کش استفاده کنید.

.PP
مثال

.EX
# populate a cache and also consult it
buildah build -t test --layers --cache-to registry/myrepo/cache --cache-from registry/myrepo/cache .
.EE

.PP
نکته: گزینه \fB--cache-from\fR نادیده گرفته می‌شود مگر اینکه \fB--layers\fR مشخص شده باشد.

.PP
نکته: گزینه \fB--cache-from\fR در Buildah متفاوت از گزینه \fB--cache-from\fR در Docker و BuildKit طراحی شده است. مکانیزم کش توزیع‌شده در Buildah ایمیج‌های میانی را مستقیماً از خود رجیستری راه دور دریافت می‌کند، بر خلاف Docker و BuildKit که ایمیج میانی درون خود ایمیج ذخیره می‌شود. رویکرد Buildah مشابه kaniko است که اندازه ایمیج اصلی را با ایمیج‌های میانی افزایش نمی‌دهد. همچنین با استفاده از مکانیزم کش Buildah، ایمیج‌های میانی واقعاً می‌توانند به صورت توزیع‌شده در یک یا چند رجیستری راه دور نگهداری شوند.

.PP
\fB--cache-to\fP

.PP
این فلگ را برای مشخص کردن فهرستی از مخازن راه دور که برای ذخیره ایمیج‌های کش استفاده می‌شوند تنظیم کنید. Buildah تلاش خواهد کرد تا ایمیج کش تازه‌ساخته‌شده را به مخازن راه دور ارسال (push) کند.

.PP
نکته: به منظور استفاده از محتوای کش در یک مخزن راه دور، از گزینه \fB--cache-from\fR استفاده کنید.

.PP
مثال

.EX
# populate a cache and also consult it
buildah build -t test --layers --cache-to registry/myrepo/cache --cache-from registry/myrepo/cache .
.EE

.PP
نکته: گزینه \fB--cache-to\fR نادیده گرفته می‌شود مگر اینکه \fB--layers\fR مشخص شده باشد.

.PP
نکته: گزینه \fB--cache-to\fR در Buildah متفاوت از گزینه \fB--cache-to\fR در Docker و BuildKit طراحی شده است. مکانیزم کش توزیع‌شده در Buildah ایمیج‌های میانی را مستقیماً به خود رجیستری راه دور ارسال می‌کند، بر خلاف Docker و BuildKit که ایمیج میانی درون خود ایمیج ذخیره می‌شود. رویکرد Buildah مشابه kaniko است که اندازه ایمیج اصلی را با ایمیج‌های میانی افزایش نمی‌دهد. همچنین با استفاده از مکانیزم کش Buildah، ایمیج‌های میانی واقعاً می‌توانند به صورت توزیع‌شده در یک یا چند رجیستری راه دور نگهداری شوند.

.PP
\fB--cache-ttl\fP \fIduration\fP

.PP
استفاده از ایمیج‌های کش‌شده را تنها به ایمیج‌هایی محدود می‌کند که برچسب زمانی ایجاد آن‌ها کمتر از \fIduration\fP پیش باشد.
برای مثال اگر \fB--cache-ttl=1h\fR مشخص شود، Buildah تنها ایمیج‌های کش میانی را در نظر می‌گیرد که در بازه زمانی کمتر از یک ساعت ایجاد شده باشند، و ایمیج‌های کش میانی خارج از این بازه زمانی نادیده گرفته خواهند شد.

.PP
نکته: تنظیم دستی \fB--cache-ttl=0\fR در پیاده‌سازی معادل استفاده از \fB--no-cache\fR است، زیرا عملاً به این معنی است که کاربر به هیچ وجه مایل به استفاده از کش نیست.
\fB--cap-add\fP=\fICAP_xxx\fP

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

.PP
\fB--cap-drop\fP=\fICAP_xxx\fP

.PP
هنگام اجرای دستورالعمل‌های 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) مدیریت می‌شود.

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

.PP
\fB--cert-dir\fP \fIpath\fP

.PP
از گواهی‌های موجود در \fIpath\fP (*\&.crt، *\&.cert، *\&.key) برای اتصال به رجیستری و بازیابی محتوا از مکان‌های HTTPS برای دستورالعمل‌های ADD استفاده می‌کند.
دایرکتوری پیش‌فرض گواهی‌ها \fI/etc/containers/certs.d\fP\& است.

.PP
\fB--cgroup-parent\fP=""

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

.PP
\fB--cgroupns\fP \fIhow\fP

.PP
پیکربندی فضاهای نام cgroup (cgroup namespaces) را هنگام پردازش دستورالعمل‌های \fBRUN\fR تنظیم می‌کند.
مقدار پیکربندی‌شده می‌تواند "" (رشته خالی) یا "private" باشد که نشان می‌دهد باید یک فضای نام cgroup جدید ایجاد شود، یا می‌تواند "host" باشد که نشان می‌دهد باید از فضای نام cgroup که خود \fBbuildah\fR در آن اجرا می‌شود مجدداً استفاده شود.

.PP
\fB--compat-volumes\fP

.PP
دایرکتوری‌هایی را که با استفاده از دستورالعمل VOLUME علامت‌گذاری شده‌اند (چه در این بیلد و چه مواردی که از تصاویر پایه به ارث رسیده‌اند) به گونه‌ای مدیریت می‌کند که محتوای آن‌ها فقط توسط دستورالعمل‌های ADD و COPY قابل تغییر باشد. هر تغییری که توسط دستورالعمل‌های RUN در آن مکان‌ها ایجاد شود بازگردانده (revert) خواهد شد. قبل از معرفی این گزینه، این رفتار به صورت پیش‌فرض فعال بود، اما اکنون به صورت پیش‌فرض غیرفعال است.

.PP
\fB--compress\fP

.PP
این گزینه برای همگامی با سایر رابط‌های خط فرمان (CLI) کانتینرها اضافه شده است.
ابزار Buildah کپی‌ای از دایرکتوری زمینه (context directory) را به یک دیمن یا کارساز راه دور ارسال نمی‌کند.
بنابراین، فشرده‌سازی داده‌ها قبل از ارسال برای Buildah بی‌مورد و نامربوط است.

.PP
\fB--compression-format\fP \fIformat\fP

.PP
قالب فشرده‌سازی مورد استفاده را مشخص می‌کند. مقادیر پشتیبانی‌شده عبارتند از: \fBgzip\fR، \fBzstd\fR و \fBzstd:chunked\fR\&.
مقدار \fBzstd:chunked\fR با رمزگذاری تصاویر ناسازگار است و در این حالت همراه با یک هشدار به صورت \fBzstd\fR رفتار خواهد شد.
اگر مشخص نشود، قالب از تنظیمات \fBcompression_format\fR در containers.conf خوانده می‌شود.

.PP
این گزینه بر ارسال حافظه نهان با \fB--cache-to\fR و تصویر نهایی هنگام نوشتن در یک مقصد غیرمحلی (مانند \fBdir:\fR، \fBoci:\fR، \fBoci-archive:\fR یا یک رجیستری) تأثیر می‌گذارد.
هنگامی که خروجی، ذخیره‌سازی کانتینر محلی باشد (حالت پیش‌فرض)، لایه‌ها همیشه هنگام ورود از حالت فشرده خارج می‌شوند، بنابراین فشرده‌سازی در زمان \fBbuildah push\fR اعمال می‌شود.

.PP
\fB--compression-level\fP \fIlevel\fP

.PP
سطح فشرده‌سازی مورد استفاده را مشخص می‌کند. این مقدار بستگی به الگوریتم فشرده‌سازی مورد استفاده دارد؛ به عنوان مثال برای zstd مقادیر پذیرفته‌شده در محدوده ۱-۲۰ (شامل خود این اعداد) است، در حالی که برای gzip بین ۱-۹ (شامل خود این اعداد) می‌باشد.
اگر مشخص نشود، سطح فشرده‌سازی از تنظیمات \fBcompression_level\fR در containers.conf خوانده می‌شود.

.PP
\fB--cpp-flag\fP=""

.PP
تنظیم فلگ‌های اضافی برای ارسال به پیش‌پردازنده سی cpp(1).
پرونده‌های Containerfile که با پسوند ".in" پایان می‌یابند از طریق cpp(1) پیش‌پردازش می‌شوند. این گزینه می‌تواند برای ارسال فلگ‌های اضافی به cpp استفاده شود.
نکته: شما همچنین می‌توانید با تنظیم متغیر محیطی BUILDAH_CPPFLAGS، مقادیر پیش‌فرض CPPFLAGS را تنظیم کنید (مانند \fBexport BUILDAH_CPPFLAGS="-DDEBUG"\fR).

.PP
\fB--cpu-period\fP=\fI0\fP

.PP
دوره CPU را برای زمان‌بند کاملاً منصفانه (CFS) که مدت زمانی بر حسب میکروثانیه است تنظیم می‌کند. هنگامی که سهمیه (quota) پردازنده کانتینر مصرف شود، تا زمانی که دوره جاری به پایان نرسد، کانتینر برای اجرا زمان‌بندی نخواهد شد. مقدار پیش‌فرض ۱۰۰۰۰۰ میکروثانیه است.

.PP
در برخی سیستم‌ها، ممکن است تغییر محدودیت‌های پردازنده برای کاربران غیر ریشه (non-root) مجاز نباشد. برای اطلاعات بیشتر، ببینید:
https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-cpu-limits-fails-with-a-permissions-error

.PP
\fB--cpu-quota\fP=\fI0\fP

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

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

.PP
در برخی سیستم‌ها، ممکن است تغییر محدودیت‌های پردازنده برای کاربران غیر ریشه (non-root) مجاز نباشد. برای اطلاعات بیشتر، ببینید:
https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-cpu-limits-fails-with-a-permissions-error

.PP
\fB--cpu-shares\fP, \fB-c\fP=\fI0\fP

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

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

.PP
برای تغییر این نسبت از مقدار پیش‌فرض ۱۰۲۴، از فلگ \fB--cpu-shares\fP برای تنظیم وزن روی ۲ یا بالاتر استفاده کنید.

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

.PP
به عنوان مثال، سه کانتینر را در نظر بگیرید که یکی دارای cpu-share با مقدار ۱۰۲۴ و دو کانتینر دیگر دارای cpu-share با مقدار ۵۱۲ هستند. هنگامی که فرایندها در هر سه کانتینر تلاش کنند ۱۰۰٪ پردازنده را استفاده نمایند، کانتینر اول ۵۰٪ از کل زمان پردازنده را دریافت خواهد کرد. اگر کانتینر چهارمی با cpu-share برابر با ۱۰۲۴ اضافه کنید، کانتینر اول فقط ۳۳٪ از پردازنده را دریافت می‌کند. کانتینرهای باقی‌مانده به ترتیب ۱۶.۵٪، ۱۶.۵٪ و ۳۳٪ از پردازنده را دریافت خواهند کرد.

.PP
در یک سیستم چند‌هسته‌ای، سهم‌های زمان پردازنده در تمام هسته‌های پردازنده توزیع می‌شوند. حتی اگر یک کانتینر به کمتر از ۱۰۰٪ کل زمان پردازنده محدود شده باشد، می‌تواند از ۱۰۰٪ هر یک از هسته‌های اختصاصی پردازنده استفاده کند.

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

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

.PP
\fB--cpuset-cpus\fP=""

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

.PP
\fB--cpuset-mems\fP=""

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

.PP
اگر چهار گره حافظه در سیستم خود دارید (0-3)، با استفاده از \fB--cpuset-mems=0,1\fR فرایندهای موجود در کانتینر شما فقط از حافظه دو گره اول حافظه استفاده خواهند کرد.

.PP
\fB--created-annotation\fP

.PP
یک یادداشت (\fIannotation\fP) تصویر (همچنین ببینید: \fB--annotation\fP) به فراداده (متادیتا) تصویر اضافه می‌کند که مقدار "org.opencontainers.image.created" را روی زمان فعلی، یا روی برچسب زمانی مشخص‌شده با فلگ \fB--source-date-epoch\fP یا \fB--timestamp\fP (در صورت استفاده از هرکدام) تنظیم می‌کند. اگر مقدار \fIfalse\fP باشد، چنین یادداشتی در تصویر نوشته‌شده وجود نخواهد داشت.

.PP
نکته: این اطلاعات در قالب‌های تصویر داکر وجود ندارد، بنابراین هنگام نوشتن تصاویر در قالب‌های داکر نادیده گرفته می‌شود.

.PP
\fB--creds\fP \fIcreds\fP

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

.PP
\fB--cw\fP \fIoptions\fP

.PP
تولید تصویری مناسب برای استفاده به عنوان بار کاری محرمانه (confidential workload) در حال اجرا در یک محیط اجرای معتمد (TEE) با استفاده از krun (یعنی \fIcrun\fP ساخته‌شده با ویژگی فعال libkrun که به عنوان \fIkrun\fP فراخوانی می‌شود). به جای محتویات معمول، سامانه پرونده ریشه (rootfs) تصویر شامل یک تصویر دیسک رمزگذاری‌شده و اطلاعات پیکربندی برای krun خواهد بود.

.PP
مقدار \fIoptions\fP یک فهرست جداشده با کاما از جفت‌های key=value است که اطلاعات پیکربندی لازم برای تولید داده‌های اضافی را که در تصویر کانتینر گنجانده می‌شوند، فراهم می‌کند.

.PP
کلیدهای (\fIkeys\fP) شناخته‌شده عبارتند از:

.PP
\fIattestation_url\fP: محل کارساز تصدیق / کارگزار کلید (key broker / attestation server).
اگر مقداری مشخص شود، شناسه بار کاری تصویر جدید به همراه عبارت عبور استفاده‌شده برای رمزگذاری تصویر دیسک در کارساز ثبت خواهد شد و محل کارساز در تصویر کانتینر ذخیره می‌شود.
در زمان اجرا، انتظار می‌رود krun با کارساز تماس گرفته و با استفاده از شناسه بار کاری که در تصویر کانتینر نیز ذخیره شده است، عبارت عبور را بازیابی کند.
اگر مقداری مشخص نشود، مقدار \fIpassphrase\fP \fIباید\fP مشخص گردد.

.PP
\fIcpus\fP: تعداد پردازنده‌های مجازی (vCPU) که تصویر انتظار دارد در زمان اجرا با آن اجرا شود. اگر مشخص نشود، یک مقدار پیش‌فرض ارائه خواهد شد.

.PP
\fIfirmware_library\fP: محل کتابخانه مشترک libkrunfw-sev. اگر مشخص نشود، \fBbuildah\fR وجود آن را در چندین مکان ثابت بررسی می‌کند.

.PP
\fImemory\fP: مقدار حافظه‌ای که تصویر انتظار دارد در زمان اجرا با آن اجرا شود، بر حسب مگابایت. اگر مشخص نشود، یک مقدار پیش‌فرض ارائه خواهد شد.

.PP
\fIpassphrase\fP: عبارت عبور مورد استفاده برای رمزگذاری تصویر دیسک که درون تصویر کانتینر گنجانده خواهد شد.
اگر مقداری مشخص نشود، اما مقدار \fIattestation_url\fP مشخص شده باشد، یک عبارت عبور تصادفی تولید و استفاده خواهد شد.
نویسندگان توصیه می‌کنند مقدار \fIattestation_url\fP تنظیم شود اما \fIpassphrase\fP تنظیم نگردد\&.

.PP
\fIslop\fP: فضای اضافی برای تخصیص به تصویر دیسک در مقایسه با اندازه محتویات تصویر کانتینر، که یا به صورت درصد (..%) یا به صورت مقدار اندازه (بایت، یا واحدهای بزرگ‌تر در صورت وجود پسوندهایی مانند KB یا MB) یا مجموع دو یا چند مورد از این مشخصات بیان می‌شود. اگر مشخص نشود، \fBbuildah\fR حدس می‌زند که ۲۵٪ فضای بیشتر نسبت به محتویات کافی خواهد بود، اما این گزینه برای مواقعی که حدس آن نادرست باشد ارائه شده است.

.PP
\fItype\fP: نوع محیط اجرای معتمد (TEE) که تصویر باید برای استفاده با آن علامت‌گذاری شود. مقادیر پذیرفته‌شده عبارتند از "SEV" (مجازی‌سازی رمزگذاری‌شده امن AMD - وضعیت رمزگذاری‌شده) و "SNP" (مجازی‌سازی رمزگذاری‌شده امن AMD - صفحه‌بندی تودرتوی امن). در صورت عدم تعیین، پیش‌فرض "SNP" است.

.PP
\fIworkload_id\fP: یک شناسه بار کاری که در تصویر کانتینر ثبت خواهد شد تا در زمان اجرا برای بازیابی عبارت عبوری که برای رمزگذاری تصویر دیسک استفاده شده بود، به کار رود. اگر مشخص نشود، یک مقدار نیمه‌تصادفی از شناسه تصویرِ تصویر پایه به دست خواهد آمد.

.PP
\fB--decryption-key\fP \fIkey[:passphrase]\fP

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

.PP
\fB--device\fP=\fIdevice\fP

.PP
یک دستگاه میزبان یا دستگاه‌های زیر یک دایرکتوری را به محیط هر دستورالعمل \fBRUN\fP که در طول بیلد اجرا می‌شود اضافه می‌کند. پارامتر اختیاری \fIpermissions\fP می‌تواند برای تعیین مجوزهای دستگاه با استفاده از یک یا چند مورد از \fBr\fP برای خواندن، \fBw\fP برای نوشتن و \fBm\fP برای \fBmknod\fP(2) استفاده شود.

.PP
مثال: \fB--device=/dev/sdc:/dev/xvdc:rwm\fP\&.

.PP
نکته: اگر \fIhost-device\fP یک پیوند نمادین (symbolic link) باشد، ابتدا حل‌وفصل می‌شود. کانتینر فقط شماره‌های اصلی و فرعی (major and minor numbers) دستگاه میزبان را ذخیره خواهد کرد.

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

.PP
نکته: اگر کاربر فقط از طریق یک گروه دارای حقوق دسترسی باشد، دسترسی به دستگاه از داخل یک کانتینر بدون ریشه (rootless) با شکست مواجه خواهد شد. زمان اجرای \fBcrun\fP(1) با افزودن گزینه \fB--annotation run.oci.keep_original_groups=1\fP راهکاری را برای این مورد ارائه می‌دهد\&.
\fB--disable-compression\fP، \fB-D\fP

.PP
لایه‌های سیستم‌فایل هنگام ساخت تصویر فشرده‌سازی نمی‌شوند مگر اینکه مکانی که تصویر در آن نوشته می‌شود به آن نیاز داشته باشد. این تنظیم پیش‌فرض است، زیرا لایه‌های تصویر هنگام ارسال (push) به رجیستری‌ها به‌طور خودکار فشرده می‌شوند و تصاویری که در فضای ذخیره‌سازی محلی نوشته می‌شوند تنها برای ذخیره‌شدن باید دوباره از حالت فشرده خارج شوند. فشرده‌سازی می‌تواند در تمام موارد با تعیین \fB--disable-compression=false\fP\& اجبار شود.

.PP
\fB--disable-content-trust\fP

.PP
این یک گزینه مخصوص داکر برای غیرفعال کردن اعتبارسنجی تصویر در یک رجیستری کانتینر است و توسط Buildah پشتیبانی نمی‌شود. این فلگ یک دستور بی‌اثر (NOOP) است و صرفاً برای سازگاری اسکریپت‌ها ارائه شده است.

.PP
\fB--dns\fP=[]

.PP
تنظیم سرورهای DNS سفارشی. استفاده از \fB--dns\fP همراه با \fB--network=none\fP\& نامعتبر است.

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

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

.PP
\fB--dns-option\fP=[]

.PP
تنظیم گزینه‌های DNS سفارشی. استفاده از \fB--dns-option\fP همراه با \fB--network=none\fP\& نامعتبر است.

.PP
\fB--dns-search\fP=[]

.PP
تنظیم دامنه‌های جستجوی DNS سفارشی. استفاده از \fB--dns-search\fP همراه با \fB--network=none\fP\& نامعتبر است.

.PP
\fB--env\fP \fIenv[=value]\fP

.PP
افزودن یک مقدار (برای نمونه env=\fIvalue\fP) به تصویر ساخته‌شده. این گزینه می‌تواند چندین بار استفاده شود.
اگر نه \fB=\fR و نه یک \fB*value*\fR تعیین نشده باشد، اما \fIenv\fP در محیط فعلی تنظیم شده باشد، مقدار از محیط فعلی به تصویر اضافه خواهد شد.
مقدار \fIenv\fP می‌تواند توسط دستورالعمل‌های ENV در Containerfile بازنویسی شود.
برای حذف یک متغیر محیطی از تصویر ساخته‌شده، از گزینه \fB--unsetenv\fR استفاده کنید.

.PP
\fB--file\fP، \fB-f\fP \fIContainerfile\fP

.PP
یک Containerfile را مشخص می‌کند که حاوی دستورالعمل‌هایی برای ساخت تصویر است؛ چه یک فایل محلی باشد یا یک URL با پروتکل \fBhttp\fP یا \fBhttps\fP\&. اگر بیش از یک Containerfile تعیین شده باشد، دستورالعمل‌های \fIFROM\fP تنها از آخرین فایل مشخص‌شده پذیرفته خواهند شد.

.PP
اگر یک فایل محلی به عنوان Containerfile مشخص شده باشد و وجود نداشته باشد، دایرکتوری زمینه (context directory) به ابتدای مقدار فایل محلی اضافه خواهد شد.

.PP
اگر \fB-f -\fR را مشخص کنید، محتویات Containerfile از ورودی استاندارد (stdin) خوانده خواهد شد.

.PP
\fB--force-compression\fP

.PP
در صورت تنظیم، از الگوریتم فشرده‌سازی مشخص‌شده استفاده می‌کند حتی اگر مقصد از قبل حاوی نسخه‌ای با فشرده‌سازی متفاوت باشد.
اگر \fB--compression-format\fR به‌طور صریح در خط فرمان مشخص شده باشد یا \fBcompression_format\fR در containers.conf تنظیم شده باشد، مقدار پیش‌فرض \fBtrue\fR است، در غیر این صورت \fBfalse\fR می‌باشد.

.PP
\fB--force-rm\fP \fIbool-value\fP

.PP
همیشه کانتینرهای میانی را پس از ساخت حذف می‌کند، حتی اگر ساخت با شکست مواجه شود (پیش‌فرض false است).

.PP
\fB--format\fP

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

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

.PP
\fB--from\fP

.PP
نخستین دستورالعمل \fBFROM\fR را درون Containerfile بازنویسی می‌کند. اگر چندین دستورالعمل FROM در یک Containerfile وجود داشته باشد، تنها دستورالعمل اول تغییر می‌کند.

.PP
\fB--group-add\fP=\fIgroup\fP | \fIkeep-groups\fP

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

.RS
.IP \(bu 2
مقدار \fBkeep-groups\fR یک فلگ ویژه است که به Buildah می‌گوید دسترسی گروه‌های تکمیلی (supplementary group access) را حفظ کند.

.RE

.PP
به کانتینر اجازه می‌دهد از دسترسی گروه‌های تکمیلی کاربر استفاده کند. اگر سیستم‌های فایل یا دستگاه‌ها تنها توسط گروه کاربر بدون ریشه (rootless) قابل دسترس باشند، این فلگ به زمان اجرای OCI می‌گوید دسترسی گروهی را به داخل کانتینر منتقل کند. در حال حاضر فقط با زمان اجرای OCI موسوم به \fBcrun\fR در دسترس است. نکته: \fBkeep-groups\fR انحصاری است و گروه‌های دیگر را نمی‌توان همراه با این فلگ مشخص کرد.

.PP
\fB--help\fP، \fB-h\fP

.PP
چاپ راهنمای نحوه استفاده (usage statement)

.PP
\fB--hooks-dir\fP \fIpath\fP

.PP
هر فایل \fB*.json\fR در مسیر، یک قلاب (hook) را برای کانتینرهای ساخت buildah پیکربندی می‌کند. برای جزئیات بیشتر در مورد ساختار فایل‌های JSON و معناشناسی تزریق قلاب، به oci-hooks(5) مراجعه کنید. ابزار Buildah در حال حاضر از هر دو شِمای قلاب 1.0.0 و 0.1.0 پشتیبانی می‌کند، هرچند شِمای 0.1.0 منسوخ شده است.

.PP
این گزینه ممکن است چندین بار تنظیم شود؛ مسیرهای مربوط به گزینه‌های بعدی دارای اولویت بالاتری هستند (صفحه راهنمای oci-hooks(5) اولویت دایرکتوری را مورد بحث قرار می‌دهد).

.PP
برای شرایط حاشیه‌نویسی (annotation conditions)،‏ buildah از هرگونه حاشیه‌نویسی تنظیم‌شده در پیکربندی OCI ایجادشده استفاده می‌کند.

.PP
برای شرایط متصل‌کردن پیوندی (bind-mount conditions)، تنها اتصال‌هایی که به‌طور صریح توسط فراخواننده از طریق --volume درخواست شده‌اند در نظر گرفته می‌شوند. اتصال‌های پیوندی که buildah به‌طور پیش‌فرض درج می‌کند (مانند /dev/shm) در نظر گرفته نمی‌شوند.

.PP
اگر --hooks-dir برای فراخوانندگان ریشه (root) تنظیم نشده باشد، Buildah در حال حاضر به ترتیب افزایش اولویت به /usr/share/containers/oci/hooks.d و /etc/containers/oci/hooks.d پیش‌فرض خواهد بود. استفاده از این مقادیر پیش‌فرض منسوخ شده است و فراخوانندگان باید به تنظیم صریح --hooks-dir مهاجرت کنند.

.PP
\fB--http-proxy\fP=true

.PP
به‌طور پیش‌فرض، اگر متغیرهای محیطی پروکسی برای فرایند buildah تنظیم شده باشند، به داخل کانتینر منتقل می‌شوند. این رفتار را می‌توان با تنظیم گزینه \fB--http-proxy\fR روی \fBfalse\fR\& غیرفعال کرد. متغیرهای محیطی منتقل‌شده شامل \fBhttp_proxy\fR،‏ \fBhttps_proxy\fR،‏ \fBftp_proxy\fR،‏ \fBno_proxy\fR و همچنین نسخه‌های با حروف بزرگ آن‌ها هستند.

.PP
\fB--identity-label\fP \fIbool-value\fP

.PP
یک برچسب \fBio.buildah.version\fR اضافه می‌کند که مقدار آن برابر با نسخه buildah که تصویر را ساخته است تنظیم می‌شود (پیش‌فرض true است مگر اینکه از \fB--timestamp\fR یا \fB--source-date-epoch\fR استفاده شود).

.PP
\fB--ignorefile\fP \fIfile\fP

.PP
مسیر به یک فایل .containerignore (.dockerignore) جایگزین.

.PP
\fB--iidfile\fP \fIImageIDfile\fP

.PP
شناسه تصویر ساخته‌شده را در فایل می‌نویسد. هنگامی که \fB--platform\fR بیش از یک بار مشخص شده باشد، تلاش برای استفاده از این گزینه خطایی را ایجاد خواهد کرد.

.PP
\fB--iidfile-raw\fP \fIImageIDfile\fP

.PP
شناسه تصویر ساخته‌شده را بدون پیشوند الگوریتم (برای نمونه \fBsha256:\fR) در فایل می‌نویسد. هنگامی که \fB--platform\fR بیش از یک بار مشخص شده باشد، تلاش برای استفاده از این گزینه خطایی را ایجاد خواهد کرد.

.PP
نام مستعار \fB--raw-iidfile\fR نیز در دسترس است.

.PP
\fB--inherit-annotations\fP \fIbool-value\fP

.PP
حاشیه‌نویسی‌ها (annotations) را از تصویر پایه یا مراحل پایه به ارث می‌برد (پیش‌فرض true است).
موارد استفاده‌ای که این فلگ را روی \fIfalse\fP تنظیم می‌کنند ممکن است نیاز داشته باشند همین کار را برای فلگ \fB--created-annotation\fP نیز انجام دهند.

.PP
\fB--inherit-labels\fP \fIbool-value\fP

.PP
برچسب‌ها (labels) را از تصویر پایه یا مراحل پایه به ارث می‌برد (پیش‌فرض true است).

.PP
\fB--ipc\fP \fIhow\fP

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

.PP
\fB--isolation\fP \fItype\fP

.PP
نوع ایزوله‌سازی مورد استفاده برای اجرای فرایندها به عنوان بخشی از دستورالعمل‌های \fBRUN\fR را کنترل می‌کند. انواع شناخته‌شده شامل \fIoci\fP (زمان اجرای سازگار با OCI، پیش‌فرض)، \fIrootless\fP (زمان اجرای سازگار با OCI که با استفاده از پیکربندی اصلاح‌شده فراخوانی می‌شود، همراه با \fI--no-new-keyring\fP اضافه‌شده به فراخوانی \fIcreate\fP آن، با استفاده مجدد از فضاهای نام شبکه و UTS میزبان، و ایجاد فضاهای نام خصوصی IPC،‏ PID، متصل‌کردن (mount) و کاربر؛ پیش‌فرض برای کاربران بدون امتیاز)، و \fIchroot\fP (یک پوشش‌دهنده داخلی که بیشتر به chroot(1) تمایل دارد تا فناوری کانتینر، با استفاده مجدد از فضاهای نام گروه کنترلی (cgroup)، شبکه، IPC و PID میزبان، و ایجاد فضاهای نام خصوصی mount و UTS، و ایجاد فضاهای نام کاربر تنها زمانی که برای نگاشت شناسه مورد نیاز باشند) هستند.

.PP
نکته: همچنین می‌توانید نوع ایزوله‌سازی پیش‌فرض را با تنظیم متغیر محیطی BUILDAH_ISOLATION بازنویسی کنید. \fBexport BUILDAH_ISOLATION=oci\fR

.PP
\fB--jobs\fP \fIN\fP

.PP
حداکثر N مرحله همزمان را به صورت موازی اجرا می‌کند. اگر تعداد کارها بیشتر از 1 باشد، stdin از /dev/null خوانده خواهد شد. اگر 0 مشخص شود، هیچ محدودیتی برای تعداد کارهایی که به صورت موازی اجرا می‌شوند وجود نخواهد داشت.

.PP
\fB--label\fP \fIlabel[=value]\fP

.PP
افزودن یک برچسب تصویر \fIlabel\fP (برای نمونه label=\fIvalue\fP) به متاداده تصویر. این گزینه می‌تواند چندین بار استفاده شود.
اگر نام \fIlabel\fP ذکر شود، اما نه \fB=\fR و نه یک \fBvalue\fR ارائه نشود، آنگاه \fIlabel\fP روی یک مقدار خالی تنظیم می‌شود.

.PP
کاربران می‌توانند یک LABEL ویژه به صورت \fBio.containers.capabilities=CAP1,CAP2,CAP3\fP در یک Containerfile تنظیم کنند که فهرست قابلیت‌های (capabilities) لینوکس مورد نیاز برای اجرای درست کانتینر را مشخص می‌کند. این برچسب تعیین‌شده در تصویر کانتینر به موتورهای کانتینر، مانند Podman، که این برچسب را می‌شناسند می‌گوید تا کانتینر را فقط با همین قابلیت‌ها اجرا کنند. موتور کانتینر کانتینر را فقط با قابلیت‌های مشخص‌شده راه‌اندازی می‌کند، تا زمانی که این فهرست از قابلیت‌ها زیرمجموعه‌ای از فهرست پیش‌فرض باشد.

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

.PP
\fB--layer-label\fP \fIlabel[=value]\fP

.PP
افزودن یک برچسب تصویر میانی \fIlabel\fP (برای نمونه label=\fIvalue\fP) به متاداده در تصاویر میانی، یعنی هر تصویری که برای مراحل غیرنهایی و برای دستورالعمل‌های غیرنهایی در مراحلی که \fB--layers\fP برابر با \fBtrue\fP\& است ساخته شده باشد. این گزینه می‌تواند چندین بار استفاده شود.
اگر نام \fIlabel\fP ذکر شود، اما نه \fB=\fR و نه یک \fBvalue\fR ارائه نشود، آنگاه \fIlabel\fP روی یک مقدار خالی تنظیم می‌شود.

.PP
\fB--layers\fP \fIbool-value\fP

.PP
کش‌کردن تصاویر میانی در طول فرایند ساخت (پیش‌فرض \fBfalse\fR است).

.PP
نکته: همچنین می‌توانید مقدار پیش‌فرض لایه‌ها را با تنظیم متغیر محیطی BUILDAH_LAYERS بازنویسی کنید. \fBexport BUILDAH_LAYERS=true\fR

.PP
\fB--logfile\fP \fIfilename\fP

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

.PP
\fB--logsplit\fP \fIbool-value\fP

.PP
در صورت مشخص شدن \fB--logfile\fP و \fB--platform\fP، این فلگ به کاربران نهایی اجازه می‌دهد تا فایل لاگ را برای هر پلتفرم در فایل‌های جداگانه‌ای با الگوی نام‌گذاری \fB${logfile}_${platform-os}_${platform-arch}\fR تقسیم کنند.

.PP
\fB--manifest\fP \fIlistName\fP

.PP
نام لیست مانیفستی که ایمیج ساخته‌شده به آن اضافه خواهد شد. در صورت عدم وجود لیست مانیفست، آن را ایجاد می‌کند. این گزینه برای ساخت ایمیج‌های چندمعماری مفید است.
اگر \fIlistName\fP شامل بخش نام رجیستری نباشد، نام رجیستری \fIlocalhost\fP به ابتدای نام لیست اضافه می‌شود.

.PP
\fB--memory\fP, \fB-m\fP=""

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

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

.PP
\fB--memory-swap\fP="LIMIT"

.PP
یک مقدار محدودیت برابر با حافظه به علاوه swap. باید همراه با فلگ \fB-m\fP (\fB--memory\fP) استفاده شود. مقدار \fBLIMIT\fR مربوط به swap همیشه باید از مقدار \fB-m\fP (\fB--memory\fP) بزرگ‌تر باشد. به طور پیش‌فرض، \fBLIMIT\fR سواپ دو برابر مقدار --memory تنظیم خواهد شد.

.PP
قالب \fBLIMIT\fR به صورت \fB<number>[<unit>]\fR است. واحد می‌تواند \fBb\fR (بایت)، \fBk\fR (کیلوبایت)، \fBm\fR (مگابایت)، یا \fBg\fR (گیگابایت) باشد. اگر واحدی مشخص نکنید، \fBb\fR استفاده می‌شود. برای فعال‌سازی swap نامحدود، مقدار LIMIT را روی \fB-1\fR تنظیم کنید.

.PP
\fB--metadata-file\fP \fIMetadataFile\fP

.PP
نوشتن اطلاعات مربوط به ایمیج ساخته‌شده در فایل نام‌برده‌شده. هنگامی که \fB--platform\fR بیش از یک بار مشخص شده باشد، تلاش برای استفاده از این گزینه خطایی ایجاد خواهد کرد.

.PP
\fB--mount\fP \fImount-instruction\fP

.PP
این مونت را پیش از اجرا به هر دستور \fBRUN\fR در Containerfile اضافه می‌کند. برای مثال:

.PP
\fBbuildah build --mount type=secret,id=mysecret ...\fR

.PP
و یک ورودی Containerfile به صورت:

.PP
\fBRUN cat /run/secrets/mysecret\fR

.PP
اثری مشابه دستور زیر دارد:

.PP
\fBRUN --mount=type=secret,id=mysecret cat /run/secrets/mysecret\fR

.PP
\fB--network\fP, \fB--net\fP=\fImode\fP

.PP
پیکربندی فضاهای نام شبکه را هنگام پردازش دستورالعمل‌های \fBRUN\fR تنظیم می‌کند.

.PP
مقادیر معتبر \fImode\fP عبارتند از:

.RS
.IP \(bu 2
\fBnone\fP: بدون شبکه. در صورت استفاده از \fB--dns\fP، \fB--dns-option\fP یا \fB--dns-search\fP نامعتبر است؛
.IP \(bu 2
\fBhost\fP: استفاده از پشته شبکه میزبان. نکته: حالت host دسترسی کامل به سرویس‌های محلی سیستم مانند D-Bus را به کانتینر می‌دهد و بنابراین ناامن تلقی می‌شود؛
.IP \(bu 2
\fBns:\fP\fIpath\fP: مسیر فضای نام شبکه برای پیوستن به آن؛
.IP \(bu 2
\fBprivate\fP: ایجاد یک فضای نام جدید برای کانتینر (پیش‌فرض)
.IP \(bu 2
\fB<network name|ID>\fP: پیوستن به شبکه با نام یا شناسه داده‌شده، مثلاً استفاده از \fB--network mynet\fR برای پیوستن به شبکه‌ای با نام mynet. فقط برای کاربران با دسترسی ریشه (rootful) پشتیبانی می‌شود.
.IP \(bu 2
\fBpasta[:OPTIONS,...]\fP: استفاده از \fBpasta\fP(1) برای ایجاد یک پشته شبکه در حالت کاربر (user-mode).
.br
این گزینه فقط در حالت بدون ریشه (rootless) پشتیبانی می‌شود.
.br
به طور پیش‌فرض، آدرس‌ها و مسیرهای IPv4 و IPv6 و همچنین نام رابط پاد (pod interface) از میزبان کپی می‌شوند. اگر فوروارد پورت پیکربندی نشده باشد، پورت‌ها به صورت پویا با متصل شدن سرویس‌ها در هر دو طرف (فضای نام init یا فضای نام کانتینر) فوروارد می‌شوند. فوروارد پورت آدرس IP مبدأ اصلی را حفظ می‌کند. گزینه‌های شرح‌داده‌شده در pasta(1) را می‌توان به صورت شناسه‌های جداشده با کاما مشخص کرد.
.br
از نظر گزینه‌های pasta(1)، گزینه \fB--config-net\fP به طور پیش‌فرض ارائه می‌شود تا شبکه هنگام راه‌اندازی کانتینر پیکربندی شود، و \fB--no-map-gw\fP نیز به طور پیش‌فرض اعمال می‌شود تا از دسترسی مستقیم کانتینر به میزبان با استفاده از آدرس گیت‌وی (درگاه) جلوگیری شود. مورد اخیر را می‌توان با پاس دادن \fB--map-gw\fP در گزینه‌های اختصاصی pasta بازنویسی کرد (با وجود اینکه یک گزینه واقعی در pasta(1) نیست).
.br
همچنین، گزینه‌های \fB-t none\fP و \fB-u none\fP برای غیرفعال کردن فوروارد خودکار پورت بر اساس پورت‌های متصل‌شده ارسال می‌شوند. به طور مشابه، \fB-T none\fP و \fB-U none\fP برای غیرفعال کردن همین عملکرد از کانتینر به میزبان ارسال می‌شوند.
.br
چند مثال:
.RS
.IP \(bu 2
\fBpasta:--map-gw\fP: به کانتینر اجازه می‌دهد مستقیماً با استفاده از آدرس گیت‌وی به میزبان دسترسی داشته باشد.
.IP \(bu 2
\fBpasta:--mtu,1500\fP: یک MTU به میزان ۱۵۰۰ بایت برای رابط \fItap\fP در کانتینر مشخص می‌کند.
.IP \(bu 2
\fBpasta:--ipv4-only,-a,10.0.2.0,-n,24,-g,10.0.2.2,--dns-forward,10.0.2.3,-m,1500,--no-ndp,--no-dhcpv6,--no-dhcp\fP،
غیرفعال کردن IPv6، انتساب \fB10.0.2.0/24\fR به رابط \fBtap0\fR در کانتینر با گیت‌وی \fB10.0.2.2\fR، فعال‌سازی فورواردر DNS قابل دسترس در \fB10.0.2.3\fR، تنظیم MTU روی ۱۵۰۰ بایت، و غیرفعال کردن پشتیبانی از NDP، DHCPv6 و DHCP.
.IP \(bu 2
\fBpasta:-I,tap0,--ipv4-only,-a,10.0.2.0,-n,24,-g,10.0.2.2,--dns-forward,10.0.2.3,--no-ndp,--no-dhcpv6,--no-dhcp\fP،
مشابه بالا، اما MTU را روی ۶۵۵۲۰ بایت باقی می‌گذارد
.IP \(bu 2
\fBpasta:-t,auto,-u,auto,-T,auto,-U,auto\fP: فعال‌سازی فوروارد خودکار پورت بر اساس پورت‌های متصل‌شده مشاهده‌شده از هر دو سمت میزبان و کانتینر
.IP \(bu 2
\fBpasta:-T,5201\fP: فعال‌سازی فوروارد پورت TCP 5201 از کانتینر به میزبان با استفاده از رابط loopback به جای رابط tap برای بهبود کارایی

.RE


.RE

.PP
\fB--no-cache\fP

.PP
از ایمیج‌های موجود در کش برای ساخت کانتینر استفاده نمی‌کند. ساخت از ابتدا با مجموعه‌ای جدید از لایه‌های کش‌شده انجام می‌شود.

.PP
\fB--no-hostname\fP

.PP
فایل \fI/etc/hostname\fP را در کانتینر برای دستورالعمل‌های RUN ایجاد نمی‌کند.

.PP
به طور پیش‌فرض، Buildah فایل \fI/etc/hostname\fP را مدیریت کرده و نام میزبان کانتینر را اضافه می‌کند. هنگامی که گزینه \fB--no-hostname\fP تنظیم شود، فایل \fI/etc/hostname\fP ایمیج (در صورت وجود) بدون تغییر حفظ خواهد شد.

.PP
\fB--no-hosts\fP

.PP
فایل \fI/etc/hosts\fP را در کانتینر برای دستورالعمل‌های RUN ایجاد نمی‌کند.

.PP
به طور پیش‌فرض، Buildah فایل \fI/etc/hosts\fP را مدیریت کرده و آدرس IP خود کانتینر را اضافه می‌کند. گزینه \fB--no-hosts\fP این مورد را غیرفعال می‌کند و فایل \fI/etc/hosts\fP ایمیج بدون تغییر حفظ خواهد شد. با گزینه \fB--add-host\fP تداخل دارد.

.PP
\fB--omit-history\fP \fIbool-value\fP

.PP
حذف اطلاعات تاریخچه ساخت در ایمیج ساخته‌شده (پیش‌فرض false).

.PP
این گزینه برای مواردی مفید است که کاربران نهایی صراحتاً می‌خواهند \fB--omit-history\fR را برای حذف بخش اختیاری \fBHistory\fR از ایمیج‌های ساخته‌شده تنظیم کنند، یا هنگام کار با ایمیج‌هایی که توسط ابزارهای ساختی ساخته شده‌اند که اطلاعات \fBHistory\fR را در ایمیج‌های خود قرار نمی‌دهند.

.PP
\fB--os\fP="OS"

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

.PP
\fB--os-feature\fP \fIfeature\fP

.PP
تنظیم نام یک ویژگی سیستم‌عامل (\fIfeature\fP) مورد نیاز برای ایمیجی که قرار است ساخته شود. به طور پیش‌فرض، اگر ایمیج بر پایه \fIscratch\fP نباشد، فهرست ویژگی‌های الزامی سیستم‌عامل ایمیج پایه (در صورتی که ایمیج پایه هر کدام را مشخص کرده باشد) حفظ می‌شود. این گزینه معمولاً فقط زمانی معنادار است که سیستم‌عامل ایمیج ویندوز باشد.

.PP
اگر \fIfeature\fP دارای یک علامت \fB-\fR در انتها باشد، آن \fIfeature\fP از مجموعه ویژگی‌های مورد نیازی که در ایمیج فهرست می‌شوند حذف می‌گردد.

.PP
\fB--os-version\fP \fIversion\fP

.PP
تنظیم نسخه سیستم‌عامل (\fIversion\fP) دقیقاً مورد نیاز برای ایمیجی که ساخته خواهد شد. به طور پیش‌فرض، اگر ایمیج بر پایه \fIscratch\fP نباشد، نسخه سیستم‌عامل الزامی ایمیج پایه (در صورت مشخص شدن در ایمیج پایه) حفظ می‌شود. این گزینه معمولاً تنها زمانی معنا دارد که سیستم‌عامل ایمیج ویندوز باشد و به طور معمول در ایمیج‌های پایه ویندوز تنظیم شده است، بنابراین استفاده از این گزینه معمولاً غیرضروری است.

.PP
\fB--output\fP, \fB-o\fP=""

.PP
خروجی اضافی (قالب: type=local,dest=path)

.PP
گزینه \fB--output\fP (یا \fB-o\fP) رفتار پیش‌فرض ساخت ایمیج کانتینر را با دادن اجازه به کاربران جهت صادر کردن محتویات ایمیج به صورت فایل‌هایی در سیستم‌فایل محلی تکمیل می‌کند، که می‌تواند برای تولید باینری‌های محلی، تولید کد و غیره مفید باشد.

.PP
مقدار \fB--output\fP دنباله‌ای از جفت‌های کلید=مقدار (key=value) جداشده با کاما است که نوع خروجی و گزینه‌ها را تعیین می‌کند.

.PP
کلیدهای (\fIkeys\fP) پشتیبانی‌شده عبارتند از:
 \fBdest\fP: مقصد خروجی صادرشده. می‌تواند برای نشان دادن خروجی استاندارد روی \fB-\fR یا یک مسیر مطلق یا نسبی تنظیم شود.
 \fBtype\fP: نوع خروجی نوشته‌شده را تعیین می‌کند. باید یکی از مقادیر فهرست‌شده در زیر باشد.

.PP
مقادیر معتبر \fItype\fP عبارتند از:
 \fBlocal\fP: نوشتن فایل‌های حاصل از ساخت در یک دایرکتوری در سمت کلاینت.
 \fBtar\fP: نوشتن فایل‌های حاصل به عنوان یک فایل تار یکتا (.tar).

.PP
همچنین به عنوان جایگزین به جای دنباله‌ای جداشده با کاما، مقدار \fB--output\fP می‌تواند تنها خود مقصد باشد (در قالب \fB**dest**\fR) (مانند \fB--output some-path\fR، \fB--output -\fR)، و در صورتی که مقصد خروجی \fB-\fR باشد نوع (\fBtype\fP) برابر با \fBtar\fP در نظر گرفته می‌شود، و در غیر این صورت \fBlocal\fP خواهد بود.

.PP
برچسب‌های زمانی (Timestamps) روی محتویات خروجی دقیقاً منطبق با مقدار مشخص‌شده با استفاده از فلگ \fB--timestamp\fP، یا دقیقاً منطبق با مقدار مشخص‌شده برای فلگ \fB--source-date-epoch\fP (در صورت تعیین هر یک از آن‌ها) تنظیم خواهد شد.

.PP
توجه داشته باشید که از گزینه \fB--tag\fP نیز می‌توان برای نوشتن ایمیج در هر مکانی که توسط \fBcontainers-transports(5)\fR توصیف شده است استفاده کرد.

.PP
\fB--pid\fP \fIhow\fP

.PP
پیکربندی فضاهای نام PID را هنگام پردازش دستورالعمل‌های \fBRUN\fR تعیین می‌کند. مقدار پیکربندی‌شده می‌تواند "" (رشته خالی) یا "private" باشد تا نشان دهد یک فضای نام PID جدید باید ایجاد شود، یا می‌تواند "host" باشد تا نشان دهد فضای نام PID که خود \fBbuildah\fR در آن در حال اجراست باید مجدداً استفاده شود، یا می‌تواند مسیر یک فضای نام PID باشد که قبلاً توسط فرآیند دیگری استفاده شده است.

.PP
\fB--platform\fP="OS/ARCH[/VARIANT]"

.PP
تنظیم OS/ARCH ایمیج ساخته‌شده (و ایمیج پایه آن، در صورتی که ساخت از آن استفاده کند) روی مقدار ارائه‌شده به جای استفاده از سیستم‌عامل و معماری فعلی میزبان (برای مثال \fBlinux/arm\fR، \fBlinux/arm64\fR، \fBlinux/amd64\fR).

.PP
فلگ \fB--platform\fR می‌تواند بیش از یک بار مشخص شود، یا فهرستی از مقادیر جداشده با کاما به عنوان شناسه به آن داده شود. هنگامی که بیش از یک پلتفرم مشخص شده باشد، باید از گزینه \fB--manifest\fR به جای گزینه \fB--tag\fR استفاده شود.

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

.PP
دستور \fBbuildah build\fR امکان ساخت ایمیج‌ها را برای تمام معماری‌های لینوکس، حتی معماری‌های غیربومی (non-native) فراهم می‌کند. هنگام ساخت ایمیج‌ها برای یک معماری متفاوت، دستورالعمل‌های \fBRUN\fR به نرم‌افزار شبیه‌سازی نصب‌شده روی میزبان نیاز دارند که توسط بسته‌هایی مانند \fBqemu-user-static\fR ارائه می‌شود. نکته: در صورت امکان همیشه ترجیح داده می‌شود که ایمیج‌ها روی معماری بومی ساخته شوند.

.PP
\fBنکته:\fP گزینه \fB--platform\fR نباید در ترکیب با گزینه‌های \fB--arch\fR، \fB--os\fR یا \fB--variant\fR استفاده شود.

.PP
\fB--pull\fP

.PP
سیاست دریافت (pull) ایمیج. در صورت مشخص نشدن، مقدار پیش‌فرض \fBmissing\fP است\&. اگر آرگومان صریح \fB--pull\fP بدون هیچ مقداری ارائه شود، از رفتار \fBalways\fP استفاده می‌شود.

.RS
.IP \(bu 2
\fBalways\fP: ایمیج‌های پایه و اسکنر SBOM را از رجیستری‌های فهرست‌شده در registries.conf دریافت کن. در صورتی که ایمیج پایه یا اسکنر SBOM در رجیستری‌ها یافت نشود، حتی اگر ایمیجی با همان نام به‌صورت محلی موجود باشد، خطا صادر کن.
.IP \(bu 2
\fBmissing\fP: ایمیج‌های اسکنر SBOM را تنها در صورتی دریافت کن که در فضای ذخیره‌سازی کانتینرهای محلی یافت نشوند. در صورتی که هیچ ایمیجی یافت نشود و دریافت با شکست مواجه شود، خطا صادر کن.
.IP \(bu 2
\fBnever\fP: ایمیج‌های پایه و اسکنر SBOM را از رجیستری‌ها دریافت نکن؛ تنها از نسخه‌های محلی استفاده کن. اگر ایمیج به‌صورت محلی موجود نباشد، خطا صادر کن.
.IP \(bu 2
\fBnewer\fP: ایمیج‌های پایه و اسکنر SBOM را در صورت جدیدتر بودن، از رجیستری‌های فهرست‌شده در registries.conf دریافت کن. اگر ایمیجی با همان نام به‌صورت محلی موجود نباشد و ایمیج پایه یا اسکنر SBOM در رجیستری‌ها یافت نشود، خطا صادر کن.

.RE

.PP
\fB--quiet\fP, \fB-q\fP

.PP
پیام‌های خروجی را که نشان‌دهنده دستورالعمل در حال پردازش، پیشرفت دریافت ایمیج‌ها از رجیستری و نوشتن ایمیج خروجی هستند، بی‌صدا (سرکوب) کن.

.PP
\fB--retry\fP \fIattempts\fP

.PP
تعداد دفعات تلاش مجدد در صورت بروز خطا هنگام ارسال یا دریافت (push/pull) ایمیج‌ها به/از رجیستری.

.PP
پیش‌فرض \fB3\fR است\&.

.PP
\fB--retry-delay\fP \fIduration\fP

.PP
مدت زمان تاخیر بین تلاش‌های مجدد در صورت بروز خطا هنگام ارسال یا دریافت (push/pull) ایمیج‌ها به/از رجیستری.

.PP
پیش‌فرض \fB2s\fR است\&.

.PP
\fB--rewrite-timestamp\fP

.PP
هنگام تولید لایه‌های جدید برای ایمیج، با جایگزین کردن هرگونه مهرزمانی (timestamp) پس از مقدار استفاده‌شده توسط فلگ \fB--source-date-epoch\fP (در صورت ارائه) با همان مقدار، اطمینان حاصل کن که هیچ محتوای تازه اضافه‌شده‌ای مهرزمانی بعد از آن مقدار را نداشته باشد.

.PP
\fB--rm\fP \fIbool-value\fP

.PP
حذف کانتینرهای میانی پس از ساخت موفقیت‌آمیز (پیش‌فرض true).

.PP
\fB--runtime\fP \fIpath\fP

.PP
مسیر (\fIpath\fP) به یک زمان‌اجرای (runtime) جایگزین سازگار با OCI، که برای اجرای دستورات مشخص‌شده توسط دستورالعمل \fBRUN\fP استفاده خواهد شد. مقدار پیش‌فرض \fBrunc\fR است، یا \fBcrun\fR هنگامی که سیستم برای استفاده از cgroups V2 پیکربندی شده باشد.

.PP
نکته: شما همچنین می‌توانید با تنظیم متغیر محیطی BUILDAH_RUNTIME، زمان‌اجرای پیش‌فرض را بازنویسی کنید.  \fBexport BUILDAH_RUNTIME=/usr/bin/crun\fR

.PP
\fB--runtime-flag\fP \fIflag\fP

.PP
فلگ‌های سراسری را برای زمان‌اجرای کانتینر اضافه می‌کند. برای مشاهده فهرست فلگ‌های پشتیبانی‌شده، لطفاً به صفحات راهنما (man pages) زمان‌اجرای کانتینر انتخابی مراجعه کنید.

.PP
نکته: \fB--\fR ابتدایی را به فلگ ارسال نکنید. برای ارسال فلگ runc یعنی \fB--log-format json\fR به buildah build، گزینه ارائه‌شده باید به‌صورت \fB--runtime-flag log-format=json\fR باشد\&.

.PP
\fB--save-stages\fP \fIbool-value\fP

.PP
حفظ ایمیج‌های مراحل (stages) میانی به جای حذف آن‌ها پس از اتمام ساخت (پیش‌فرض \fBfalse\fR است). به‌طور پیش‌فرض، Buildah برای صرفه‌جویی در فضا ایمیج‌های مراحل میانی را حذف می‌کند. این گزینه آن ایمیج‌ها را نگه می‌دارد، که می‌تواند برای اشکال‌زدایی ساخت‌های چندمرحله‌ای یا استفاده مجدد از مراحل میانی در ساخت‌های بعدی مفید باشد.

.PP
\fB--save-stages\fR می‌تواند همراه با \fB--layers\fR استفاده شود و ساخت‌های بعدی با \fB--layers\fR می‌توانند از لایه‌های میانی حفظ‌شده به عنوان کش (حافظه موقت) استفاده کنند.

.PP
هنگامی که با \fB--stage-labels\fR ترکیب شود، تمامی ایمیج‌های مراحل (از جمله ایمیج نهایی) برچسب‌های متادیتا را برای شناسایی و مدیریت آسان‌تر شامل خواهند شد.

.PP
\fB--sbom\fP \fIpreset\fP

.PP
تولید لیست مواد نرم‌افزاری / SBOM (Software Bills Of Materials) برای ایمیج خروجی با اسکن کانتینر در حال کار و زمینه‌های ساخت (build contexts) با استفاده از ترکیب نام‌گذاری‌شده‌ای از ایمیج اسکنر، دستورات اسکنر، و استراتژی ادغام. باید با یک یا چند مورد از \fB--sbom-image-output\fP، \fB--sbom-image-purl-output\fP، \fB--sbom-output\fP، و \fB--sbom-purl-output\fP مشخص شود\&. الگوهای از پیش‌تنظیم‌شده (presets) شناخته‌شده و مجموعه‌گزینه‌های معادل آن‌ها:

.RS
.IP \(bu 2
"syft", "syft-cyclonedx":
 --sbom-scanner-image=ghcr.io/anchore/syft
 --sbom-scanner-command="/syft scan -q dir:{ROOTFS} --output cyclonedx-json={OUTPUT}"
 --sbom-scanner-command="/syft scan -q dir:{CONTEXT} --output cyclonedx-json={OUTPUT}"
 --sbom-merge-strategy=merge-cyclonedx-by-component-name-and-version
.IP \(bu 2
"syft-spdx":
 --sbom-scanner-image=ghcr.io/anchore/syft
 --sbom-scanner-command="/syft scan -q dir:{ROOTFS} --output spdx-json={OUTPUT}"
 --sbom-scanner-command="/syft scan -q dir:{CONTEXT} --output spdx-json={OUTPUT}"
 --sbom-merge-strategy=merge-spdx-by-package-name-and-versioninfo
.IP \(bu 2
"trivy", "trivy-cyclonedx":
 --sbom-scanner-image=ghcr.io/aquasecurity/trivy
 --sbom-scanner-command="trivy filesystem -q {ROOTFS} --format cyclonedx --output {OUTPUT}"
 --sbom-scanner-command="trivy filesystem -q {CONTEXT} --format cyclonedx --output {OUTPUT}"
 --sbom-merge-strategy=merge-cyclonedx-by-component-name-and-version
.IP \(bu 2
"trivy-spdx":
 --sbom-scanner-image=ghcr.io/aquasecurity/trivy
 --sbom-scanner-command="trivy filesystem -q {ROOTFS} --format spdx-json --output {OUTPUT}"
 --sbom-scanner-command="trivy filesystem -q {CONTEXT} --format spdx-json --output {OUTPUT}"
 --sbom-merge-strategy=merge-spdx-by-package-name-and-versioninfo

.RE

.PP
\fB--sbom-image-output\fP \fIpath\fP

.PP
هنگام تولید SBOM، لیست مواد نرم‌افزاری (SBOM) تولیدشده را در مسیر مشخص‌شده در ایمیج خروجی ذخیره کن. هیچ مقدار پیش‌فرضی وجود ندارد.

.PP
\fB--sbom-image-purl-output\fP \fIpath\fP

.PP
هنگام تولید SBOM، آن‌ها را برای اطلاعات PURL (نشانی اینترنتی بسته / package
URL
\[la]https://github.com/package\-url/purl\-spec/blob/master/PURL\-SPECIFICATION.rst\[ra])
اسکن کن، و فهرستی از PURLهای یافت‌شده را در مسیر مشخص‌شده در ایمیج خروجی ذخیره نما. هیچ مقدار پیش‌فرضی وجود ندارد.

.PP
\fB--sbom-merge-strategy\fP \fImethod\fP

.PP
اگر بیش از یک مقدار \fB--sbom-scanner-command\fP استفاده شده باشد، از روش مشخص‌شده برای ادغام خروجی دستورات بعدی با خروجی دستورات قبلی استفاده کن. مقادیر شناخته‌شده عبارتند از:

.RS
.IP \(bu 2
cat
 پرونده‌ها را به یکدیگر متصل (الحاق) کن.
.IP \(bu 2
merge-cyclonedx-by-component-name-and-version
 فیلدهای "component" اسناد JSON را ادغام کن، و در صورتی که ترکیب مقادیر "name" و "version" آن‌ها از قبل وجود داشته باشد، مقادیر آن اسناد را نادیده بگیر. اسناد به ترتیبی که تولید می‌شوند پردازش خواهند شد، که همان ترتیب تعیین دستوراتی است که آن‌ها را تولید کرده‌اند.
.IP \(bu 2
merge-spdx-by-package-name-and-versioninfo
 فیلدهای "package" اسناد JSON را ادغام کن، و در صورتی که ترکیب مقادیر "name" و "versionInfo" آن‌ها از قبل وجود داشته باشد، مقادیر آن اسناد را نادیده بگیر. اسناد به ترتیبی که تولید می‌شوند پردازش خواهند شد، که همان ترتیب تعیین دستوراتی است که آن‌ها را تولید کرده‌اند.

.RE

.PP
\fB--sbom-output\fP \fIfile\fP

.PP
هنگام تولید SBOM، لیست مواد نرم‌افزاری (SBOM) تولیدشده را در پرونده نام‌برده در سیستم‌فایل محلی ذخیره کن. هیچ مقدار پیش‌فرضی وجود ندارد.

.PP
\fB--sbom-purl-output\fP \fIfile\fP

.PP
هنگام تولید SBOM، آن‌ها را برای اطلاعات PURL (نشانی اینترنتی بسته / package
URL
\[la]https://github.com/package\-url/purl\-spec/blob/master/PURL\-SPECIFICATION.rst\[ra])
اسکن کن، و فهرستی از PURLهای یافت‌شده را در پرونده نام‌برده در سیستم‌فایل محلی ذخیره نما. هیچ مقدار پیش‌فرضی وجود ندارد.

.PP
\fB--sbom-scanner-command\fP \fIimage\fP

.PP
تولید SBOM با اجرای دستور مشخص‌شده از ایمیج اسکنر. اگر چندین دستور مشخص شده باشد، آن‌ها به ترتیبی که تعیین شده‌اند اجرا می‌شوند. این جایگزینی‌های متنی انجام می‌شوند:
  - {ROOTFS}
      ریشه فایل‌سیستم ایمیج ساخته‌شده، متصل‌شده به‌صورت bind mount.
  - {CONTEXT}
      زمینه ساخت (build context) و زمینه‌های ساخت اضافی، متصل‌شده به‌صورت bind mount.
  - {OUTPUT}
      نام یک پرونده خروجی موقت، برای خواندن و ادغام با سایرین یا کپی شدن در جای دیگر.

.PP
\fB--sbom-scanner-image\fP \fIimage\fP

.PP
تولید SBOM با استفاده از ایمیج اسکنر مشخص‌شده.

.PP
\fB--secret\fP=\fBid=id[,src=\fIenvOrFile\fP][,env=ENV][,type=file|env]\fP

.PP
ارسال اطلاعات محرمانه (سکرت / secret) برای استفاده در Containerfile جهت ساخت ایمیج‌ها به روشی امن که در نهایت در ایمیج نهایی ذخیره نشود یا در مراحل دیگر دیده نشود. مقدار سکرت از یک متغیر محیطی یا پرونده با نام ارائه‌شده توسط گزینه "id"، یا با نام تعیین‌شده توسط گزینه "src" (در صورت مشخص شدن)، یا از یک متغیر محیطی مشخص‌شده با گزینه "env" خوانده می‌شود. اطلاعات محرمانه (سکرت) به‌طور پیش‌فرض در مسیر \fB/run/secrets/<id>\fR در کانتینر متصل (mount) خواهد شد.

.PP
برای استفاده از سکرت در ادامه، از فلگ --mount در دستورالعمل \fBRUN\fR در داخل یک \fBContainerfile\fR استفاده کنید:

.PP
\fBRUN --mount=type=secret,id=mysecret cat /run/secrets/mysecret\fR

.PP
محل قرارگیری سکرت در کانتینر را می‌توان با استفاده از گزینه‌های "target"، "dst" یا "destination" از فلگ \fBRUN --mount\fR بازنویسی کرد.

.PP
\fBRUN --mount=type=secret,id=mysecret,target=/run/secrets/myothersecret cat /run/secrets/myothersecret\fR

.PP
همچنین سکرت را می‌توان به‌صورت متغیر محیطی در اختیار فرایند قرار داد:

.PP
\fBRUN --mount=type=secret,id=mysecret,env=FOO sh -c 'echo "Hello $FOO"'\fR

.PP
نکته: تغییر محتوای پرونده‌های سکرت، موجب بازسازی مجدد لایه‌هایی که از سکرت‌های مذکور استفاده می‌کنند نخواهد شد.

.PP
\fB--security-opt\fP=[]

.PP
گزینه‌های امنیتی

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

.PP
"label=user:USER"       : تنظیم کاربر برچسب برای کانتینر
  "label=role:ROLE"       : تنظیم نقش برچسب برای کانتینر
  "label=type:TYPE"       : تنظیم نوع برچسب برای کانتینر
  "label=level:LEVEL"     : تنظیم سطح برچسب برای کانتینر
  "label=disable"         : غیرفعال کردن محدودسازی برچسب برای کانتینر

.PP
"mask=\fI/path/1:/path/2\fP": مسیرهایی که باید ماسک شوند که با دونقطه از هم جدا شده‌اند. مسیر ماسک‌شده در داخل کانتینر قابل دسترسی نیست.

.PP
"no-new-privileges"     : جلوگیری از کسب امتیازات اضافی توسط فرایندهای کانتینر

.PP
"seccomp=unconfined"    : غیرفعال کردن محدودسازی seccomp برای کانتینر
  "seccomp=profile.json   : پیکربندی JSON برای فیلتر seccomp

.PP
"unmask=\fIALL\fP یا \fI/path/1:/path/2\fP، یا مسیرهای گسترش‌یافته توسط پوسته (/proc/*): مسیرهایی که باید آن‌ماسک شوند که با دونقطه از هم جدا شده‌اند. در صورت تنظیم روی \fBALL\fP، تمام مسیرهایی که به‌طور پیش‌فرض ماسک شده یا فقط‌خواندنی هستند را از حالت ماسک خارج می‌کند.
  مسیرهای پیش‌فرض ماسک‌شده عبارتند از \fB/proc/acpi, /proc/interrupts, /proc/kcore, /proc/keys, /proc/latency_stats, /proc/sched_debug, /proc/scsi, /proc/timer_list, /proc/timer_stats, /sys/devices/virtual/powercap, /sys/firmware\fP، و \fB/sys/fs/selinux\fP\&. مسیرهای پیش‌فرض فقط‌خواندنی عبارتند از \fB/proc/asound\fP، \fB/proc/bus\fP، \fB/proc/fs\fP، \fB/proc/irq\fP، \fB/proc/sys\fP، و \fB/proc/sysrq-trigger\fP\&.

.PP
\fB--shm-size\fP=""

.PP
اندازه \fB/dev/shm\fR\&. قالب آن به‌صورت \fB<number><unit>\fR است\&. \fBnumber\fR باید بزرگتر از \fB0\fR باشد\&.
واحد اختیاری است و می‌تواند \fBb\fR (بایت)، \fBk\fR (کیلوبایت)، \fBm\fR (مگابایت)، یا \fBg\fR (گیگابایت) باشد.
اگر واحد را حذف کنید، سیستم از بایت استفاده می‌کند. اگر اندازه را به‌طور کامل حذف کنید، سیستم از \fB64m\fR استفاده می‌کند\&.

.PP
\fB--sign-by\fP \fIfingerprint\fP

.PP
امضای ایمیج ساخته‌شده با استفاده از کلید GPG مطابق با اثرانگشت (fingerprint) مشخص‌شده.

.PP
\fB--skip-unused-stages\fP \fIbool-value\fP

.PP
صرف‌نظر کردن از مراحلی در ساخت‌های چندمرحله‌ای که تأثیری روی مرحله هدف ندارند (پیش‌فرض \fBtrue\fR است).

.PP
\fB--source-date-epoch\fP \fIseconds\fP

.PP
برچسب زمانی «ایجاد شده» (created) را برای تصویر ساخته‌شده بر اساس این تعداد ثانیه از مبدأ زمان (Unix epoch، یعنی ساعت 00:00:00 به وقت UTC در ۱ ژانویه ۱۹۷۰) تنظیم می‌کند (پیش‌فرض استفاده از مقدار تنظیم‌شده در متغیر محیطی \fBSOURCE_DATE_EPOCH\fR، یا زمان فعلی در صورت عدم تنظیم آن است).

.PP
برچسب زمانی «created» هنگام ثبت (commit) تصویر در پیکربندی و مانیفست تصویر نوشته می‌شود؛ بنابراین، اجرای همان فرایند ساخت در دو زمان مختلف معمولاً تصاویری با هش‌های sha256 متفاوت تولید می‌کند، حتی اگر هیچ تغییر دیگری در Containerfile و زمینه ساخت (build context) ایجاد نشده باشد.

.PP
هنگامی که این فلگ تنظیم شود، یک آرگومان ساخت (build arg) به نام \fBSOURCE_DATE_EPOCH\fR مقدار خود را برای مرحله‌ای که در آن اعلان شده است فراهم می‌کند.

.PP
هنگامی که این فلگ تنظیم شود، برچسب زمانی «created» در پیکربندی تصویر همیشه روی زمان مشخص‌شده تنظیم می‌شود، که امکان ساخت تصاویر کاملاً یکسان را در زمان‌های مختلف با استفاده از مجموعه‌ای یکسان از ورودی‌ها فراهم می‌کند.

.PP
هنگامی که این فلگ تنظیم شود، خروجی نوشته‌شده طبق مشخصات فلگ \fB--output\fP دقیقاً حامل برچسب زمانی مشخص‌شده خواهد بود.

.PP
با فلگ مشابه \fB--timestamp\fP که زمان مشخص‌شده‌اش را بر روی محتویات لایه‌های جدید نیز اعمال می‌کند، تداخل دارد.

.PP
\fB--source-policy-file\fP \fIpathname\fP

.PP
مسیر یک فایل JSON سیاست منبع (source policy) سازگار با BuildKit را مشخص می‌کند. هنگام تعیین این گزینه، مراجع منبع (مانند تصاویر پایه در دستورالعمل‌های FROM) پیش از استفاده، بر اساس قوانین این سیاست ارزیابی می‌شوند.

.PP
سیاست‌های منبع امکان کنترل تصاویری را که می‌توانند به عنوان تصویر پایه استفاده شوند، و همچنین امکان تبدیل اختیاری مراجع تصویر (به عنوان مثال، پین کردن تگ‌ها به دایجست‌های خاص) را بدون نیاز به تغییر دادن فایل‌های Containerfile فراهم می‌کنند. این قابلیت برای اعمال سیاست‌های سازمانی و تضمین بازتولیدپذیری ساخت (build reproducibility) مفید است.

.PP
فایل سیاست یک سند JSON شامل آرایه‌ای از قوانین است. هر قانون شامل موارد زیر است:
- \fBaction\fP: عملیاتی که هنگام تطابق قانون انجام می‌شود. عملیات معتبر عبارتند از:
  - \fBALLOW\fP: مجاز دانستن صریح منبع (بدون هیچ تبدیلی).
  - \fBDENY\fP: مسدود کردن منبع و شکست فرایند ساخت.
  - \fBCONVERT\fP: تبدیل منبع به یک مرجع متفاوت مشخص‌شده در \fBupdates\fR\&.
- \fBselector\fP: مشخص می‌کند قانون برای کدام منابع اعمال شود.
  - \fBidentifier\fP: شناسه منبع جهت تطابق (برای مثال، \fBdocker-image://docker.io/library/alpine:latest\fR).
  - \fBmatchType\fP: نحوه تطابق شناسه. انواع معتبر عبارتند از \fBEXACT\fR و \fBWILDCARD\fR (پشتیبانی از الگوهای glob شامل \fB*\fR و \fB?\fR). در صورت عدم تعیین، پیش‌فرض روی \fBWILDCARD\fR قرار دارد.
- \fBupdates\fP: برای عملیات \fBCONVERT\fR، شناسه جایگزین را مشخص می‌کند.

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

.PP
نکته: قوانین CONVERT در سیاست منبع پس از جایگزینی‌های \fB--build-context\fP اما پیش از هرگونه جایگزینی مشخص‌شده در \fBcontainers-registries.conf(5)\fP پردازش می‌شوند\&. این سازوکار روش‌های متعددی را برای بازنویسی تصویر پایه مورد استفاده در یک مرحله خاص به ترتیب اولویت زیر فراهم می‌کند: ابتدا \fB--build-context\fR، سپس سیاست منبع، و در نهایت registries.conf.

.PP
نمونه فایل سیاست که alpine:latest را به یک دایجست خاص پین می‌کند:

.EX
{
  "rules": [
    {
      "action": "CONVERT",
      "selector": {
        "identifier": "docker-image://docker.io/library/alpine:latest"
      },
      "updates": {
        "identifier": "docker-image://docker.io/library/alpine@sha256:..."
      }
    }
  ]
}
.EE

.PP
نمونه فایل سیاست که تمامی تصاویر ubuntu را مسدود می‌کند:

.EX
{
  "rules": [
    {
      "action": "DENY",
      "selector": {
        "identifier": "docker-image://docker.io/library/ubuntu:*",
        "matchType": "WILDCARD"
      }
    }
  ]
}
.EE

.PP
\fB--squash\fP

.PP
تمامی لایه‌ها، از جمله لایه‌های متعلق به تصویر (تصاویر) پایه را در یک لایه واحد ادغام (squash) می‌کند. (پیش‌فرض false است).

.PP
به‌صورت پیش‌فرض، Buildah لایه‌های موجود تصویر پایه را حفظ کرده و در هنگام ساخت تنها یک لایه جدید اضافه می‌کند. گزینه --layers می‌تواند برای حفظ لایه‌های میانی ساخت استفاده شود.

.PP
\fB--ssh\fP=\fBdefault\fP|\fIid[=socket>|[,]\fP

.PP
سوکت عامل SSH یا کلیدهایی که قرار است در دسترس فرایند ساخت قرار گیرند.
مسیر سوکت می‌تواند خالی رها شود تا از مقدار \fBdefault=$SSH_AUTH_SOCK\fR استفاده شود.

.PP
برای استفاده بعدی از عامل ssh، از فلگ --mount در دستورالعمل \fBRUN\fR درون یک \fBContainerfile\fR استفاده کنید:

.PP
\fBRUN --mount=type=secret,id=id mycmd\fR

.PP
\fBنکته:\fP هنگام استفاده از کاربری غیر از کاربر پیش‌فرض \fBroot\fR، باید یکی از گزینه‌های \fBmode\fR، \fBuid\fR یا \fBgid\fR همراه با گزینه‌های \fBmount\fR مشخص شود. برای مثال، در دسترس قرار دادن سوکت ssh برای کاربر \fBapp\fR با \fBuid=50000\fR:

.EX
# Switch to application user (Note that uid depends on container image)
USER app
# ...and check whether ssh identities are available
RUN --mount=type=ssh,uid=50000
    ssh-add -L
.EE

.PP
\fB--stage-labels\fP \fIbool-value\fP

.PP
افزودن برچسب‌های متادیتا به تمامی تصاویر مراحل میانی در ساخت چندمرحله‌ای، از جمله تصویر نهایی (پیش‌فرض \fBfalse\fR است).
این گزینه نیازمند فعال بودن \fB--save-stages\fR است.

.PP
در صورت فعال بودن، تمام تصاویر مراحل میانی و تصویر نهایی با موارد زیر برچسب‌گذاری می‌شوند:
  - \fBio.buildah.stage.name\fR: نام مستعار مرحله (از \fBFROM ... AS alias\fR)، یا موقعیت مرحله در صورت عدم تعیین نام مستعار
  - \fBio.buildah.stage.base\fR: تصویر پایه استفاده‌شده توسط این مرحله (pullspec یا شناسه تصویر در صورتی که مرحله از مرحله دیگری به عنوان پایه استفاده کند)

.PP
این برچسب‌ها شناسایی، جستجو و مدیریت تصاویر حاصل از ساخت‌های چندمرحله‌ای را آسان‌تر می‌کنند.

.PP
\fB--stdin\fP

.PP
انتقال ورودی استاندارد (stdin) به کانتینرهای دستور RUN. گاهی دستوراتی که با RUN در داخل یک Containerfile اجرا می‌شوند می‌خواهند از کاربر درخواست اطلاعات کنند؛ به عنوان مثال apt که برای نصب درخواست تأییدیه می‌کند. برای امکان تعامل از طریق ترمینال در طول فرایند ساخت، از --stdin استفاده کنید.

.PP
\fB--tag\fP, \fB-t\fP \fIimageName\fP

.PP
نامی را مشخص می‌کند که در صورت تکمیل موفقیت‌آمیز فرایند ساخت، به تصویر حاصل اختصاص داده خواهد شد.
اگر \fIimageName\fP شامل بخش نام رجیستری نباشد، نام رجیستری \fIlocalhost\fP به ابتدای نام تصویر افزوده خواهد شد.

.PP
گزینه \fB--tag\fP از تمامی پروتکل‌های انتقال موجود در \fBcontainers-transports(5)\fR پشتیبانی می‌کند\&.
در صورت عدم تعیین پروتکل انتقال، پروتکل \fBcontainers-storage\fR (یعنی فضای ذخیره‌سازی محلی) استفاده می‌شود.

.PP
\fBbuildah build --tag=oci-archive:./foo.ociarchive .\fP

.PP
\fBbuildah build -t quay.io/username/foo  .\fP

.PP
\fB--target\fP \fIstageName\fP

.PP
مرحله ساخت هدف (تارگت) را برای ساخت مشخص می‌کند. هنگام ساخت یک Containerfile با چندین مرحله ساخت، می‌توان از --target برای مشخص کردن یک مرحله ساخت میانی با نام آن به عنوان مرحله نهایی برای تصویر حاصل استفاده کرد. دستورات پس از مرحله هدف نادیده گرفته خواهند شد.

.PP
\fB--timestamp\fP \fIseconds\fP

.PP
برچسب زمانی «ایجاد شده» (created) را برای تصویر ساخته‌شده بر اساس این تعداد ثانیه از مبدأ زمان (Unix epoch، یعنی ساعت 00:00:00 به وقت UTC در ۱ ژانویه ۱۹۷۰) تنظیم می‌کند (پیش‌فرض زمان فعلی است).

.PP
برچسب زمانی «created» هنگام ثبت (commit) تصویر در پیکربندی و مانیفست تصویر نوشته می‌شود؛ بنابراین، اجرای همان فرایند ساخت در دو زمان مختلف معمولاً تصاویری با هش‌های sha256 متفاوت تولید می‌کند، حتی اگر هیچ تغییر دیگری در Containerfile و زمینه ساخت (build context) ایجاد نشده باشد.

.PP
هنگامی که --timestamp تنظیم شود، برچسب زمانی «created» همیشه روی زمان مشخص‌شده تنظیم می‌شود، که امکان ساخت تصاویر کاملاً یکسان را در زمان‌های مختلف با استفاده از مجموعه‌ای یکسان از ورودی‌ها فراهم می‌کند.

.PP
هنگامی که --timestamp تنظیم شود، تمام محتوای لایه‌های ایجادشده به عنوان بخشی از فرایند ساخت، و خروجی نوشته‌شده طبق مشخصات فلگ \fB--output\fP نیز حامل همین برچسب زمانی خواهند بود.

.PP
با فلگ مشابه \fB--source-date-epoch\fP که به‌صورت پیش‌فرض بر برچسب‌های زمانی محتویات لایه‌ها تأثیری ندارد، تداخل دارد.

.PP
\fB--tls-verify\fP \fIbool-value\fP

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

.PP
\fB--ulimit\fP \fItype\fP=\fIsoft-limit\fP[:\fIhard-limit\fP]

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

.PP
\fB--unsetannotation\fP \fIannotation\fP

.PP
حذف حاشیه‌نویسی (annotation) تصویر، که مانع از به ارث رسیدن حاشیه‌نویسی از تصویر پایه می‌شود.

.PP
\fB--unsetenv\fP \fIenv\fP

.PP
حذف متغیرهای محیطی از تصویر نهایی.

.PP
\fB--unsetlabel\fP \fIlabel\fP

.PP
حذف برچسب (label) تصویر، که مانع از به ارث رسیدن برچسب از تصویر پایه می‌شود.

.PP
\fB--userns\fP \fIhow\fP

.PP
پیکربندی فضاهای نام کاربری (user namespaces) را هنگام پردازش دستورالعمل‌های \fBRUN\fR تنظیم می‌کند.
مقدار پیکربندی‌شده می‌تواند "" (رشته خالی)، "private" یا "auto" باشد تا نشان دهد که باید یک فضای نام کاربری جدید ایجاد شود، می‌تواند "host" باشد تا نشان دهد فضای نام کاربری که در آن خود \fBbuildah\fR در حال اجراست باید مجدداً استفاده شود، یا می‌تواند مسیر یک فضای نام کاربری باشد که هم‌اکنون توسط فرایند دیگری در حال استفاده است.

.PP
auto: ایجاد خودکار یک فضای نام کاربری یکتا.

.PP
فلگ --userns=auto مستلزم این است که نام کاربری containers و محدوده‌ای از شناسه‌های کاربری فرعی (subordinate user IDs) که کانتینر ساخت مجاز به استفاده از آن‌ها است در فایل‌های /etc/subuid و /etc/subgid مشخص شده باشند.

.PP
مثال: \fBcontainers:2147483647:2147483648\fR\&.

.PP
برنامه Buildah محدوده‌های یکتایی از UIDها و GIDها را از شناسه‌های کاربری فرعی containers اختصاص می‌دهد. اندازه این محدوده‌ها بر اساس تعداد UIDهای مورد نیاز در تصویر است. تعداد UIDها و GIDها را می‌توان با گزینه size بازنویسی کرد.

.PP
گزینه‌های معتبر \fBauto\fR:

.RS
.IP \(bu 2
gidmapping=CONTAINER_GID:HOST_GID:SIZE: برای اجبار به وجود یک نگاشت GID در فضای نام کاربری.
.IP \(bu 2
size=SIZE: برای مشخص کردن اندازه صریح برای فضای نام کاربری خودکار؛ برای مثال --userns=auto:size=8192. در صورت عدم تعیین size، گزینه auto اندازه‌ای را برای فضای نام کاربری تخمین می‌زند.
.IP \(bu 2
uidmapping=CONTAINER_UID:HOST_UID:SIZE: برای اجبار به وجود یک نگاشت UID در فضای نام کاربری.

.RE

.PP
\fB--userns-gid-map\fP \fImapping\fP

.PP
به‌طور مستقیم یک نگاشت GID را مشخص می‌کند که باید برای تعیین مالکیت در سطح
سیستم فایل، بر روی محتویات کانتینر در حال کار استفاده شود.
دستوراتی که هنگام پردازش دستورالعمل‌های \fBRUN\fR اجرا می‌شوند، به‌طور پیش‌فرض در
فضاهای نام کاربری (user namespace) مخصوص به خود که با استفاده از نگاشت‌های UID و GID پیکربندی شده‌اند اجرا خواهند شد.

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

.PP
این گزینه تنظیم \fIremap-gids\fP را در بخش \fIoptions\fP از
/etc/containers/storage.conf بازنویسی می‌کند.

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

.PP
\fB--userns-gid-map-group\fP \fIgroup\fP

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

.PP
کاربران می‌توانند نگاشت‌ها را مستقیماً با استفاده از \fB--userns-gid-map\fR که در صفحه راهنمای buildah(1) توضیح داده شده است مشخص کنند.

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

.PP
\fB--userns-uid-map\fP \fImapping\fP

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

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

.PP
این گزینه تنظیم \fIremap-uids\fP را در بخش \fIoptions\fP از
/etc/containers/storage.conf بازنویسی می‌کند.

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

.PP
\fB--userns-uid-map-user\fP \fIuser\fP

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

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

.PP
\fB--uts\fP \fIhow\fP

.PP
پیکربندی فضاهای نام UTS را هنگام پردازش دستورالعمل‌های \fBRUN\fR تنظیم می‌کند.
مقدار پیکربندی‌شده می‌تواند "" (رشته خالی) یا "container" باشد تا نشان دهد
یک فضای نام UTS جدید باید ایجاد شود، یا می‌تواند "host" باشد تا نشان دهد
فضای نام UTS که خود \fBbuildah\fR در آن در حال اجراست باید بازاستفاده شود،
یا می‌تواند مسیری به یک فضای نام UTS باشد که پیش‌تر توسط فرایند دیگری در حال استفاده است.

.PP
\fB--variant\fP=""

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

.PP
\fB--volume\fP, \fB-v\fP[=\fI[HOST-DIR:CONTAINER-DIR[:OPTIONS]]\fP]

.PP
یک دایرکتوری میزبان را هنگام اجرای دستورالعمل‌های \fIRUN\fP در طول
فرایند ساخت به درون کانتینرها متصل (mount) می‌کند. گزینه‌های \fBOPTIONS\fR فهرستی جداشده با کاما هستند و می‌توانند شامل موارد زیر باشند:

.RS
.IP \(bu 2
[rw|ro]
.IP \(bu 2
[U]
.IP \(bu 2
[z|Z|O]
.IP \(bu 2
[\fB[r]shared\fR|\fB[r]slave\fR|\fB[r]private\fR] [1]
\[la]#Footnote1\[ra]

.RE

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

.PP
می‌توانید چندین گزینه \fB-v\fP را برای متصل کردن یک یا چند نقطه اتصال به یک
کانتینر مشخص کنید.

.PP
\fBاتصال‌های حجم محافظت‌شده در برابر نوشتن (Write Protected Volume Mounts)\fR

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

.PP
\fBتغییر مالکیت اتصال‌های حجم (Chowning Volume Mounts)\fR

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

.PP
پسوند \fB:U\fR به Buildah می‌گوید تا بر اساس UID و GID درون کانتینر، از UID و GID درست میزبان برای تغییر دادن مالک و گروه حجم مبدأ استفاده کند.

.PP
\fBبرچسب‌گذاری اتصال‌های حجم (Labeling Volume Mounts)\fR

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

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

.PP
\fBاتصال‌های حجم اورلی (Overlay Volume Mounts)\fR

.PP
فلگ \fB:O\fR به Buildah می‌گوید که دایرکتوری را از میزبان با استفاده از سیستم فایل Overlay به‌عنوان یک فضای ذخیره‌سازی موقت متصل کند. کانتینرهای دستور \fBRUN\fR مجاز هستند محتویات درون نقطه اتصال را تغییر دهند و این تغییرات در فضای ذخیره‌سازی کانتینر در یک دایرکتوری جداگانه ذخیره می‌شوند. در اصطلاحات سامانه فایل چندلایه (Overlay FS)، دایرکتوری مبدأ لایه زیرین (lower) و دایرکتوری ذخیره‌سازی کانتینر لایه بالایی (upper) خواهد بود. تغییرات اعمال‌شده بر نقطه اتصال هنگام پایان اجرای دستور \fBRUN\fR از بین می‌روند، شبیه به یک نقطه اتصال tmpfs.

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

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

.PP
نکته:

.RS
.IP \(bu 2
فلگ \fBO\fR مجاز نیست همراه با فلگ‌های \fBZ\fR یا \fBz\fR مشخص شود. محتوای متصل‌شده به درون کانتینر با برچسب اختصاصی برچسب‌گذاری می‌شود.
   در سیستم‌های SELinux، برچسب‌های موجود در دایرکتوری مبدأ باید توسط برچسب کانتینر قابل خواندن باشند. در غیر این صورت، جداسازی کانتینر SELinux باید غیرفعال شود تا کانتینر کار کند.
.IP \(bu 2
تغییر دادن دایرکتوری حجم متصل‌شده به درون کانتینر با یک اتصال overlay می‌تواند خطاهای غیرمنتظره ایجاد کند. توصیه می‌شود تا زمانی که اجرای کانتینر به پایان نرسیده است دایرکتوری را تغییر ندهید.

.RE

.PP
به‌طور پیش‌فرض حجم‌های bind mount شده به‌صورت \fBprivate\fR\& هستند. بدین معنا که هرگونه اتصال انجام‌شده
درون کانتینر روی میزبان قابل مشاهده نخواهد بود و برعکس. این رفتار را می‌توان
با مشخص کردن ویژگی انتشار اتصال حجم (propagation property) تغییر داد.

.PP
هنگامی که خط‌مشی انتشار اتصال روی \fBshared\fR تنظیم شود، هرگونه اتصال انجام‌شده درون
کانتینر روی آن حجم، هم برای میزبان و هم برای کانتینر قابل مشاهده خواهد بود. هنگامی که
خط‌مشی انتشار اتصال روی \fBslave\fR تنظیم شود، انتشار یک‌طرفه اتصال فعال شده
و هرگونه اتصال انجام‌شده روی میزبان برای آن حجم تنها درون کانتینر قابل مشاهده خواهد بود.
برای کنترل ویژگی انتشار اتصال حجم از فلگ انتشار \fB:[r]shared\fR،
\fB:[r]slave\fR یا \fB:[r]private\fR استفاده کنید. ویژگی انتشار را تنها
می‌توان برای حجم‌های bind mount شده مشخص کرد، نه حجم‌های داخلی یا
حجم‌های نام‌گذاری‌شده. برای اینکه انتشار اتصال روی نقطه اتصال مبدأ (نقطه اتصالی
که دایرکتوری مبدأ روی آن متصل شده است) کار کند، باید ویژگی‌های انتشار مناسب را داشته باشد. برای
حجم‌های shared، نقطه اتصال مبدأ باید shared باشد. و برای حجم‌های slave،
اتصال مبدأ باید shared یا slave باشد. [1]
\[la]#Footnote1\[ra]

.PP
از دستور \fBdf <source-dir>\fR برای تعیین نقطه اتصال مبدأ و سپس از
\fBfindmnt -o TARGET,PROPAGATION <source-mount-dir>\fR برای تعیین ویژگی‌های
انتشار نقطه اتصال مبدأ استفاده کنید؛ اگر ابزار \fBfindmnt\fR در دسترس نیست، نقطه اتصال مبدأ
را می‌توان با نگاه کردن به مدخل اتصال در \fB/proc/self/mountinfo\fR\& مشخص کرد. به
\fBoptional fields\fR نگاه کنید و ببینید آیا ویژگی انتشاری مشخص شده است یا خیر.
\fBshared:X\fR به این معنی است که نقطه اتصال \fBshared\fR است، \fBmaster:X\fR به این معنی است که نقطه اتصال \fBslave\fR است و اگر
چیزی وجود نداشته باشد به این معنی است که نقطه اتصال \fBprivate\fR\& است. [1]
\[la]#Footnote1\[ra]

.PP
برای تغییر ویژگی‌های انتشار یک نقطه اتصال، از دستور \fBmount\fR استفاده کنید. برای
نمونه، جهت bind mount کردن دایرکتوری مبدأ \fB/foo\fR، دستورهای
\fBmount --bind /foo /foo\fR و \fBmount --make-private --make-shared /foo\fR\& را اجرا کنید. این
کار /foo را به یک نقطه اتصال \fBshared\fR تبدیل می‌کند. ویژگی‌های انتشار نقطه اتصال
مبدأ را می‌توان مستقیماً تغییر داد. برای نمونه اگر \fB/\fR نقطه اتصال مبدأ برای
\fB/foo\fR باشد، از دستور \fBmount --make-shared /\fR استفاده کنید تا \fB/\fR را به یک نقطه اتصال \fBshared\fR تبدیل نماید.
.SH "متغیرهای زمان ساخت (BUILD TIME VARIABLES)"
.PP
دستورالعمل ENV در یک Containerfile می‌تواند برای تعریف مقادیر متغیرها استفاده شود. هنگامی که تصویر ساخته می‌شود، مقادیر در تصویر کانتینر ماندگار خواهند شد. گاهی اوقات تغییر دادن مقادیر در Containerfile از طریق یک گزینه خط فرمان بسیار راحت‌تر از تغییر مقادیر در خود Containerfile است.

.PP
متغیرهای زیر می‌توانند همراه با گزینه \fB--build-arg\fR استفاده شوند تا مقادیر متناظر تنظیم‌شده در Containerfile با استفاده از دستورالعمل \fBENV\fR را بازنویسی (override) کنند.

.RS
.IP \(bu 2
HTTP_PROXY
.IP \(bu 2
HTTPS_PROXY
.IP \(bu 2
FTP_PROXY
.IP \(bu 2
NO_PROXY

.RE

.PP
لطفاً به بخش استفاده از متغیرهای زمان ساخت
\[la]#using\-build\-time\-variables\[ra] از مثال‌ها مراجعه کنید.

.SH "مثال‌ها (EXAMPLES)"
.SS "ساخت یک تصویر با استفاده از Containerfileهای محلی (Build an image using local Containerfiles)"
.PP
buildah build .

.PP
buildah build -f Containerfile .

.PP
cat ~/Containerfile | buildah build -f - .

.PP
buildah build -f Containerfile.simple -f Containerfile.notsosimple .

.PP
buildah build --timestamp=$(date '+%s') -t imageName .

.PP
buildah build -t imageName .

.PP
buildah build --tls-verify=true -t imageName -f Containerfile.simple .

.PP
buildah build --tls-verify=false -t imageName .

.PP
buildah build --runtime-flag log-format=json .

.PP
buildah build -f Containerfile --runtime-flag debug .

.PP
buildah build --authfile /tmp/auths/myauths.json --cert-dir ~/auth --tls-verify=true --creds=username:password -t imageName -f Containerfile.simple .

.PP
buildah build --memory 40m --cpu-period 10000 --cpu-quota 50000 --ulimit nofile=1024:1028 -t imageName .

.PP
buildah build --security-opt label=level:s0:c100,c200 --cgroup-parent /path/to/cgroup/parent -t imageName .

.PP
buildah build --arch=arm --variant v7 -t imageName .

.PP
buildah build --volume /home/test:/myvol:ro,Z -t imageName .

.PP
buildah build -v /home/test:/myvol:z,U -t imageName .

.PP
buildah build -v /var/lib/dnf:/var/lib/dnf:O -t imageName .

.PP
buildah build --layers -t imageName .

.PP
buildah build --save-stages -t imageName .

.PP
buildah build --save-stages --layers -t imageName .

.PP
buildah build --save-stages --stage-labels -t imageName .

.PP
buildah build --save-stages --stage-labels --layers -t imageName .

.PP
buildah build --no-cache -t imageName .

.PP
buildah build -f Containerfile --layers --force-rm -t imageName .

.PP
buildah build --no-cache --rm=false -t imageName .

.PP
buildah build --dns-search=example.com --dns=223.5.5.5 --dns-option=use-vc .

.PP
buildah build -f Containerfile.in --cpp-flag="-DDEBUG" -t imageName .

.PP
buildah build --network mynet .

.PP
buildah build --env LANG=en_US.UTF-8 -t imageName .

.PP
buildah build --env EDITOR -t imageName .

.PP
buildah build --unsetenv LANG -t imageName .

.PP
buildah build --os-version 10.0.19042.1645 -t imageName .

.PP
buildah build --os-feature win32k -t imageName .

.PP
buildah build --os-feature win32k- -t imageName .

.PP
buildah build --secret=id=mysecret .

.PP
buildah build --secret=id=mysecret,env=MYSECRET .

.PP
buildah build --secret=id=mysecret,src=MYSECRET,type=env .

.PP
buildah build --secret=id=mysecret,src=.mysecret,type=file .

.PP
buildah build --secret=id=mysecret,src=.mysecret .

.SS "ساخت یک تصویر با یک سیاست منبع (Building an image with a source policy)"
.PP
buildah build --source-policy-file /etc/buildah/source-policy.json -t imageName .

.SS "استفاده از FROM --after برای وابستگی‌های صریح مرحله (Using FROM --after for explicit stage dependencies)"
.PP
هنگام استفاده از انتقال‌های محلی مانند \fBFROM oci-archive:file.ociarchive\fR که در آن فایل توسط یک مرحله قبلی تولید می‌شود، Buildah نمی‌تواند به طور خودکار وابستگی را تشخیص دهد. از گزینه \fB--after\fR در دستورالعمل FROM برای اعلان وابستگی‌های صریح مرحله استفاده کنید:

.EX
FROM quay.io/skopeo/stable AS builder
RUN --mount=type=bind,target=/src,rw skopeo copy docker://quay.io/fedora/fedora-minimal oci-archive:/src/fedora.ociarchive

FROM --after=builder oci-archive:fedora.ociarchive
# این مرحله پیش از ارزیابی FROM منتظر تکمیل builder می‌ماند
.EE

.SS "ساخت یک تصویر چندمعماری با استفاده از گزینه --manifest (نیازمند نرم‌افزار شبیه‌سازی)"
.PP
buildah build --arch arm --manifest myimage /tmp/mysrc

.PP
buildah build --arch amd64 --manifest myimage /tmp/mysrc

.PP
buildah build --arch s390x --manifest myimage /tmp/mysrc

.PP
buildah bud --platform linux/s390x,linux/ppc64le,linux/amd64 --manifest myimage /tmp/mysrc

.PP
buildah build --platform linux/arm64 --platform linux/amd64 --manifest myimage /tmp/mysrc

.PP
buildah bud --all-platforms --manifest myimage /tmp/mysrc

.SS "ساخت یک تصویر با استفاده از خروجی ساخت سفارشی (--output)"
.PP
buildah build -o out .

.PP
buildah build --output type=local,dest=out .

.PP
buildah build --output type=tar,dest=out.tar .

.PP
buildah build -o - . > out.tar

.SS "حفظ و پرس‌وجوی تصاویر مراحل میانی (Preserving and querying intermediate stage images)"
.PP
ساخت یک تصویر چندمرحله‌ای هم‌زمان با حفظ مراحل میانی با برچسب‌های فراداده:

.PP
buildah build --save-stages --stage-labels -t myapp .

.PP
یافتن یک تصویر میانی برای یک نام مرحله خاص:

.PP
buildah images --filter "label=io.buildah.stage.name=builder"

.PP
یافتن یک تصویر میانی برای یک تصویر پایه مرحله خاص:

.PP
buildah images --filter "label=io.buildah.stage.base=golang:1.21"

.SS "ساخت یک تصویر با استفاده از یک نشانی اینترنتی (Building an image using a URL)"
.PP
این کار مخزن مشخص‌شده گیت‌هاب را از URL شبیه‌سازی (clone) کرده و به عنوان زمینه (context) استفاده می‌کند. فایل Containerfile یا Dockerfile در ریشه مخزن به عنوان زمینه ساخت استفاده می‌شود. این قابلیت تنها در صورتی کار می‌کند که مخزن گیت‌هاب یک مخزن اختصاصی باشد.

.PP
buildah build https://github.com/containers/PodmanHello.git

.PP
نکته: گیت‌هاب به دلیل تغییرات اخیر در راهنماهای امنیتی خود (https://github.blog/2021-09-01-improving-git-protocol-security-github) از استفاده از \fBgit://\fR برای انجام عملیات \fBclone\fR پشتیبانی نمی‌کند. در صورتی که مخزن مبدأ روی گیت‌هاب میزبانی می‌شود، از یک URL با پروتکل \fBhttps://\fR استفاده کنید.

.SS "ساخت یک تصویر با استفاده از URL به یک زمینه فشرده‌شده با فرمت تاربال (tarball)"
.PP
برنامه Buildah آرشیو تاربال را دریافت کرده، آن را از حالت فشرده خارج می‌کند و از محتویات آن به عنوان زمینه ساخت استفاده می‌نماید. فایل Containerfile یا Dockerfile در ریشه آرشیو و مابقی محتویات آرشیو به عنوان زمینه ساخت استفاده خواهند شد. اگر گزینه -f PATH/Containerfile را نیز ارسال کنید، سیستم به دنبال آن فایل درون محتویات تاربال خواهد گشت.

.PP
buildah build -f dev/Containerfile https://10.10.10.1/buildah/context.tar.gz

.PP
نکته: قالب‌های فشرده‌سازی پشتیبانی‌شده عبارتند از 'xz'، 'bzip2'، 'gzip' و 'identity' (بدون فشرده‌سازی).

.SS "استفاده از متغیرهای زمان ساخت (Using Build Time Variables)"
.SS "جایگزینی مقدار تنظیم‌شده برای متغیر محیطی HTTP_PROXY درون Containerfile"
.PP
buildah build --build-arg=HTTP_PROXY="http://127.0.0.1:8321"

.SH "محیط (ENVIRONMENT)"
.PP
\fBBUILD_REGISTRY_SOURCES\fP

.PP
متغیر BUILD_REGISTRY_SOURCES در صورت تنظیم، به عنوان یک شیء JSON در نظر گرفته می‌شود که شامل فهرست‌هایی از نام‌های رجیستری تحت کلیدهای \fBinsecureRegistries\fR، \fBblockedRegistries\fR و \fBallowedRegistries\fR\& است.

.PP
هنگام دریافت (pull) یک تصویر از یک رجیستری، اگر نام رجیستری با هر یک از موارد موجود در فهرست \fBblockedRegistries\fR مطابقت داشته باشد، تلاش برای دریافت تصویر رد می‌شود. اگر رجیستری‌هایی در فهرست \fBallowedRegistries\fR وجود داشته باشند و نام رجیستری در آن فهرست نباشد، تلاش برای دریافت تصویر رد خواهد شد.

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

.SH "فایل‌ها (FILES)"
.SS \fB\&.containerignore\fR/\fB\&.dockerignore\fR
.PP
اگر فایل .containerignore/.dockerignore در دایرکتوری زمینه وجود داشته باشد، \fBbuildah build\fR محتویات آن را می‌خواند. اگر هر دو وجود داشته باشند، .containerignore استفاده می‌شود. از گزینه \fB--ignorefile\fR برای بازنویسی مسیر مکان فایل چشم‌پوشی استفاده کنید. Buildah هنگام اجرای دستورالعمل‌های COPY و ADD در Containerfile/Dockerfile از این محتوا برای مستثنی کردن فایل‌ها و دایرکتوری‌ها از دایرکتوری زمینه استفاده می‌کند. دستورات COPY و ADD همچنین از \fB--exclude\fP پشتیبانی می‌کنند؛ الگوها نسبت به منبع کپی سنجیده می‌شوند.

.PP
کاربران می‌توانند مجموعه‌ای از الگوهای عمومی پوسته یونیکس (Unix shell globs) را در یک فایل .containerignore/.dockerignore مشخص کنند تا فایل‌ها/دایرکتوری‌هایی را که باید مستثنی شوند، تعیین نمایند.

.PP
برنامه Buildah از یک رشته نویسه عمومی ویژه \fB**\fR پشتیبانی می‌کند که با هر تعداد دایرکتوری (شامل صفر) مطابقت دارد. برای مثال، \fB**/*.go\fR تمام فایل‌هایی را که به .go ختم می‌شوند و در همه دایرکتوری‌ها یافت می‌شوند، مستثنی خواهد کرد.

.PP
نمونه فایل .containerignore:

.EX
# مستثنی کردن این محتوا برای تصویر
*/*.c
**/output*
src
.EE

.PP
\fB*/*.c\fR
فایل‌ها و دایرکتوری‌هایی را که نامشان به .c در هر زیردایرکتوری سطح بالا ختم می‌شود، مستثنی می‌کند. برای مثال، فایل منبع include/rootless.c.

.PP
\fB**/output*\fR
فایل‌ها و دایرکتوری‌هایی را که با \fBoutput\fR شروع می‌شوند از هر دایرکتوری مستثنی می‌کند.

.PP
\fBsrc\fR
فایل‌های با نام src و دایرکتوری src و همچنین هر محتوایی درون آن را مستثنی می‌کند.

.PP
خطوطی که با ! (علامت تعجب) شروع می‌شوند می‌توانند برای ایجاد استثنا در موارد مستثنی‌شده استفاده شوند. مثال زیر یک نمونه فایل .containerignore/.dockerignore است که از این سازوکار استفاده می‌کند:

.EX
*.doc
!Help.doc
.EE

.PP
تمام فایل‌های doc. به جز Help.doc را از تصویر مستثنی می‌کند.

.PP
این سازوکار با نحوه مدیریت فایل‌های .containerignore شرح داده شده در اینجا سازگار است:

.PP
https://github.com/containers/common/blob/main/docs/containerignore.5.md

.PP
نکته: هنگامی که آرگومان دستور ADD یک مخزن گیت باشد، فایل .containerignore محلی اعمال نمی‌شود.

.PP
\fBregistries.conf\fP (\fB/etc/containers/registries.conf\fR)

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

.PP
\fBpolicy.json\fP (\fB/etc/containers/policy.json\fR)

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

.SH "همچنین ببینید (SEE ALSO)"
.PP
buildah(1), cpp(1), buildah-login(1), docker-login(1), namespaces(7), pid_namespaces(7), containers-policy.json(5), containers-registries.conf(5), user_namespaces(7), crun(1), runc(8), containers.conf(5), oci-hooks(5), containers-transports(5), containers-auth.json(5)

.SH "پاورقی‌ها (FOOTNOTES)"
.PP
1: پروژه Buildah به فراگیر بودن (شمولیت)، که ارزش اصلی نرم‌افزارهای متن‌باز است، متعهد است. اصطلاحات انتشار سوارکردن (mount propagation) \fBmaster\fR و \fBslave\fR استفاده شده در اینجا مشکل‌ساز و تفرقه‌انگیز هستند و باید تغییر کنند. با این حال، این اصطلاحات در حال حاضر در هسته لینوکس استفاده می‌شوند و در حال حاضر باید به همان شکل استفاده شوند. هنگامی که نگه‌دارندگان هسته این کاربرد را اصلاح کنند، Buildah فوراً از آن پیروی خواهد کرد.