--add-host=hostname[;hostname[;...]]:ip

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

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

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

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

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

--annotation=annotation=value

یک یادداشت ایمیج (annotation) (مانند annotation=value) را به فراداده ایمیج اضافه می‌کند. می‌تواند چندین بار استفاده شود. اگر annotation نام‌گذاری شود اما نه = و نه یک value ارائه نشود، آنگاه annotation روی یک مقدار خالی تنظیم می‌شود.

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

--authfile=path

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

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

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

--build-arg=arg=value

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

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

--build-arg-file=path

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

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

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

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

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

--build-context=name=value

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

مقادیر معتبر می‌توانند موارد زیر باشند: * دایرکتوری محلی – برای مثال --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:// را نیز می‌پذیرد)

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

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

مقدار [name] با اولویت زیر مطابقت داده می‌شود:

--cache-from=image

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

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

مثال

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

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

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

--cache-to=image

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

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

مثال

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

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

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

--cache-ttl

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

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

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

--cap-add=CAP_xxx

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

--cap-drop=CAP_xxx

هنگام اجرای دستورالعمل‌های 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) برای اتصال به رجیستری و بازیابی محتوا از مکان‌های HTTPS برای دستورالعمل‌های ADD استفاده می‌کند. دایرکتوری پیش‌فرض گواهی‌ها /etc/containers/certs.d است.

--cgroup-parent=path

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

--cgroupns=how

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

--cleanup

پس از اتمام فرآیند ساخت، ایمیج‌های ساخته‌شده از روی نودهای فارم حذف شوند.

--compat-volumes

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

--compression-format=gzip | zstd | zstd:chunked

قالب فشرده‌سازی مورد استفاده را مشخص می‌کند. مقادیر پشتیبانی‌شده عبارتند از: gzip، zstd و zstd:chunked. مقدار zstd:chunked با رمزگذاری تصاویر ناسازگار است و در این حالت همراه با یک هشدار به صورت zstd رفتار خواهد شد. اگر مشخص نشود، قالب از تنظیمات compression_format در containers.conf خوانده می‌شود.

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

--compression-level=level

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

--cpp-flag=flags

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

--cpu-period=limit

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

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

--cpu-quota=limit

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

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

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

--cpu-shares, -c=shares

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

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

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

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

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

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

برای مثال، سیستمی با بیش از سه هسته را در نظر بگیرید. اگر یک کانتینر {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=number

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

--cpuset-mems=nodes

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

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

--created-annotation

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

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

--creds=[username[:password]]

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

--decryption-key=key[:passphrase]

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

--device=host-device[:container-device][:permissions]

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

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

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

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

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

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

--disable-compression, -D

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

--dns=ipaddr

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

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

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

--dns-option=option

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

--dns-search=domain

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

--env=env[=value]

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

--farm

نام فارم (مزرعه نودها) برای ارسال عملیات ساخت به آن.

--file, -f=Containerfile

یک Containerfile را مشخص می‌کند که حاوی دستورالعمل‌هایی برای ساخت تصویر است؛ چه یک فایل محلی باشد یا یک URL با پروتکل http یا https. اگر بیش از یک Containerfile تعیین شده باشد، دستورالعمل‌های FROM تنها از آخرین فایل مشخص‌شده پذیرفته خواهند شد.

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

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

--force-compression

در صورت تنظیم، از الگوریتم فشرده‌سازی مشخص‌شده استفاده می‌کند حتی اگر مقصد از قبل حاوی نسخه‌ای با فشرده‌سازی متفاوت باشد. اگر --compression-format به‌طور صریح در خط فرمان مشخص شده باشد یا compression_format در containers.conf تنظیم شده باشد، مقدار پیش‌فرض true است، در غیر این صورت false می‌باشد.

--force-rm

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

--format

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

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

--from

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

--group-add=group | keep-groups

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

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

--help, -h

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

--hooks-dir=path

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

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

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

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

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

--http-proxy

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

--identity-label

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

--ignorefile

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

--iidfile=ImageIDfile

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

--iidfile-raw=ImageIDfile

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

نام مستعار --raw-iidfile نیز در دسترس است.

--inherit-annotations=bool-value

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

--inherit-labels

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

--ipc=how

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

--isolation=type

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

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

--jobs=number

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

--label=label

افزودن یک برچسب تصویر label (برای نمونه label=value) به متاداده تصویر. این گزینه می‌تواند چندین بار استفاده شود. اگر نام label ذکر شود، اما نه = و نه یک value ارائه نشود، آنگاه label روی یک مقدار خالی تنظیم می‌شود.

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

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

--layer-label=label[=value]

افزودن یک برچسب تصویر میانی label (برای نمونه label=value) به متاداده در تصاویر میانی، یعنی هر تصویری که برای مراحل غیرنهایی و برای دستورالعمل‌های غیرنهایی در مراحلی که --layers برابر با true است ساخته شده باشد. این گزینه می‌تواند چندین بار استفاده شود. اگر نام label ذکر شود، اما نه = و نه یک value ارائه نشود، آنگاه label روی یک مقدار خالی تنظیم می‌شود.

--layers

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

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

--local, -l

علاوه بر نودهای فارم، عملیات ساخت روی سیستم محلی نیز انجام شود.

--logfile=filename

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

--memory, -m=number[unit]

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

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

--memory-swap=number[unit]

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

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

--mount=mount-specification

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

podman build --mount type=secret,id=mysecret ...

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

RUN cat /run/secrets/mysecret

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

RUN --mount=type=secret,id=mysecret cat /run/secrets/mysecret

--network=mode, --net

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

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

--no-cache

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

--no-hostname

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

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

--no-hosts

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

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

--omit-history

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

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

--os-feature=feature

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

اگر feature دارای یک علامت - در انتها باشد، آن feature از مجموعه ویژگی‌های مورد نیازی که در ایمیج فهرست می‌شوند حذف می‌گردد.

--os-version=version

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

--pid=pid

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

--platforms=p1,p2,p3...

فهرست پلتفرم‌ها و معماری‌های هدف برای ساخت ایمیج چندمعماری.

--pull=policy

سیاست دریافت (pull) ایمیج. در صورت مشخص نشدن، مقدار پیش‌فرض missing است. اگر آرگومان صریح --pull بدون هیچ مقداری ارائه شود، از رفتار always استفاده می‌شود.

--quiet, -q

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

--retry=attempts

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

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

--retry-delay=duration

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

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

--rewrite-timestamp

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

--rm

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

--runtime=path

مسیر (path) به یک زمان‌اجرای (runtime) جایگزین سازگار با OCI، که برای اجرای دستورات مشخص‌شده توسط دستورالعمل RUN استفاده خواهد شد. مقدار پیش‌فرض runc است، یا crun هنگامی که سیستم برای استفاده از cgroups V2 پیکربندی شده باشد.

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

--runtime-flag=flag

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

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

--save-stages

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

--sbom=preset

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

--sbom-image-output=path

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

--sbom-image-purl-output=path

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

--sbom-merge-strategy=method

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

--sbom-output=file

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

--sbom-purl-output=file

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

--sbom-scanner-command=image

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

--sbom-scanner-image=image

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

--secret=id=id[,src=envOrFile][,env=ENV][,type=file | env]

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

برای استفاده از سکرت در ادامه، از فلگ --mount در دستورالعمل RUN در داخل یک Containerfile استفاده کنید:

RUN --mount=type=secret,id=mysecret cat /run/secrets/mysecret

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

RUN --mount=type=secret,id=mysecret,target=/run/secrets/myothersecret cat /run/secrets/myothersecret

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

RUN --mount=type=secret,id=mysecret,env=FOO sh -c 'echo "Hello $FOO"'

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

--security-opt=option

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

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

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

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

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

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

"unmask=ALL یا /path/1:/path/2، یا مسیرهای گسترش‌یافته توسط پوسته (/proc/*): مسیرهایی که باید آن‌ماسک شوند که با دونقطه از هم جدا شده‌اند. در صورت تنظیم روی ALL، تمام مسیرهایی که به‌طور پیش‌فرض ماسک شده یا فقط‌خواندنی هستند را از حالت ماسک خارج می‌کند.
مسیرهای پیش‌فرض ماسک‌شده عبارتند از /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، و /sys/fs/selinux. مسیرهای پیش‌فرض فقط‌خواندنی عبارتند از /proc/asound، /proc/bus، /proc/fs، /proc/irq، /proc/sys، و /proc/sysrq-trigger.

--shm-size=number[unit]

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

--skip-unused-stages

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

--source-date-epoch=seconds

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

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

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

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

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

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

--source-policy-file=pathname

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

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

فایل سیاست یک سند JSON شامل آرایه‌ای از قوانین است. هر قانون شامل موارد زیر است: - action: عملیاتی که هنگام تطابق قانون انجام می‌شود. عملیات معتبر عبارتند از:
- ALLOW: مجاز دانستن صریح منبع (بدون هیچ تبدیلی).
- DENY: مسدود کردن منبع و شکست فرایند ساخت.
- CONVERT: تبدیل منبع به یک مرجع متفاوت مشخص‌شده در updates. - selector: مشخص می‌کند قانون برای کدام منابع اعمال شود.
- identifier: شناسه منبع جهت تطابق (برای مثال، docker-image://docker.io/library/alpine:latest).
- matchType: نحوه تطابق شناسه. انواع معتبر عبارتند از EXACT و WILDCARD (پشتیبانی از الگوهای glob شامل * و ?). در صورت عدم تعیین، پیش‌فرض روی WILDCARD قرار دارد. - updates: برای عملیات CONVERT، شناسه جایگزین را مشخص می‌کند.

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

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

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

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

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

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

--squash

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

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

--squash-all

ادغام تمام لایه‌های ایمیج جدید (شامل لایه‌های به ارث رسیده از ایمیج پایه) در یک لایه جدید منفرد.

--ssh=default | id[=socket>

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

برای استفاده بعدی از عامل ssh، از فلگ --mount در دستورالعمل RUN درون یک Containerfile استفاده کنید:

RUN --mount=type=secret,id=id mycmd

نکته: هنگام استفاده از کاربری غیر از کاربر پیش‌فرض root، باید یکی از گزینه‌های mode، uid یا gid همراه با گزینه‌های mount مشخص شود. برای مثال، در دسترس قرار دادن سوکت ssh برای کاربر app با uid=50000:

# 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

--stage-labels

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

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

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

--tag, -t=imageName

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

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

podman build --tag=oci-archive:./foo.ociarchive .

podman build -t quay.io/username/foo .

--target=stageName

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

--timestamp=seconds

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

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

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

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

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

--tls-verify

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

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

محدودیت‌های منابع را برای اعمال بر روی فرایندهای راه‌اندازی‌شده هنگام پردازش دستورالعمل‌های RUN مشخص می‌کند. این گزینه می‌تواند چندین بار مشخص شود. انواع منابع شناخته‌شده عبارتند از:
"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)

--unsetannotation=annotation

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

--unsetenv=env

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

--unsetlabel=label

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

--userns=how

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

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

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

مثال: containers:2147483647:2147483648.

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

گزینه‌های معتبر auto:

--userns-gid-map=mapping

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

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

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

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

--userns-gid-map-group=group

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

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

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

--userns-uid-map=mapping

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

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

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

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

--userns-uid-map-user=user

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

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

--uts=how

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

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

یک دایرکتوری میزبان را هنگام اجرای دستورالعمل‌های RUN در طول فرایند ساخت به درون کانتینرها متصل (mount) می‌کند. گزینه‌های OPTIONS فهرستی جداشده با کاما هستند و می‌توانند شامل موارد زیر باشند:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

نکته:

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

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

از دستور df <source-dir> برای تعیین نقطه اتصال مبدأ و سپس از findmnt -o TARGET,PROPAGATION <source-mount-dir> برای تعیین ویژگی‌های انتشار نقطه اتصال مبدأ استفاده کنید؛ اگر ابزار findmnt در دسترس نیست، نقطه اتصال مبدأ را می‌توان با نگاه کردن به مدخل اتصال در /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 تبدیل نماید.