'\" t .nh .TH podman-farm-build 1 .SH "نام (NAME)" podman-farm-build \- ساخت ایمیج‌ها روی نودهای فارم و تجمیع آن‌ها در یک لیست مانیفست .SH "خلاصه دستور (SYNOPSIS)" \fBpodman farm build\fP [\fIگزینه‌ها\fP] [\fIبافت\fP] .SH "توضیحات (DESCRIPTION)" دستور \fBpodman farm build\fP یک ایمیج را روی تمامی نودهای موجود در یک فارم ساخته و آن‌ها را در یک لیست مانیفست تجمیع می‌کند. این دستور \fBpodman build\fR را با Containerfile داده‌شده روی نودهای فارم اجرا می‌نماید. پس از ساخته شدن ایمیج‌ها روی تمام نودهای فارم، ایمیج‌ها به رجیستری مشخص‌شده توسط فلگ \fB--tag\fP ارسال (push) می‌شوند. پس از ارسال تمام ایمیج‌ها، یک لیست مانیفست به صورت محلی ایجاد شده و به رجیستری ارسال می‌گردد. .PP لیست مانیفست شامل یک ایمیج به ازای هر نوع معماری بومی حاضر در فارم خواهد بود. .PP کارکرد اصلی این دستور، ایجاد ساخت‌های چندمعماری با سرعتی بسیار بالاتر از شبیه‌سازی با \fBpodman build --arch --platform\fR است. .PP اگر هیچ فارمی مشخص نشود، عملیات ساخت به تمامی نودهایی که توسط \fBpodman system connection\fR شناخته شده‌اند ارسال خواهد شد. .SH "گزینه‌ها (OPTIONS)" .SS \fB--add-host\fP=\fIhostname[;hostname[;...]]\fP:\fIip\fP افزودن یک نگاشت سفارشی میزبان به IP (به صورت host:ip) .PP یک خط به /etc/hosts اضافه می‌کند. قالب آن به صورت hostname:ip است. گزینه \fB--add-host\fP می‌تواند چندین بار مشخص شود. این گزینه با گزینه --no-hosts تداخل دارد. .PP به جای آدرس IP، می‌توان فلگ ویژه host-gateway را مشخص کرد. این فلگ به یک آدرس IP تبدیل می‌شود که کانتینر می‌تواند از آن برای اتصال به میزبان استفاده کند. آدرس IP انتخاب‌شده به پیکربندی شبکه شما بستگی دارد، بنابراین هیچ تضمینی وجود ندارد که Podman بتواند آدرس host-gateway را به صورت خودکار تعیین کند، که در این صورت Podman با پیام خطا متوقف خواهد شد. شما می‌توانید این آدرس IP را با استفاده از گزینه host_containers_internal_ip در containers.conf بازنویسی کنید. .PP آدرس 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 حل می‌شوند. .PP برنامه Podman به طور پیش‌فرض از فایل /etc/hosts میزبان به عنوان پایه استفاده می‌کند، یعنی هر نام میزبانی که در این فایل وجود داشته باشد، در فایل /etc/hosts کانتینر نیز حضور خواهد داشت. یک فایل پایه متفاوت می‌تواند با استفاده از پیکربندی base_hosts_file در containers.conf تنظیم شود. .SS \fB--annotation\fP=\fIannotation=value\fP یک یادداشت ایمیج (\fIannotation\fP) (مانند annotation=\fIvalue\fP) را به فراداده ایمیج اضافه می‌کند. می‌تواند چندین بار استفاده شود. اگر \fIannotation\fP نام‌گذاری شود اما نه \fB=\fR و نه یک \fBvalue\fR ارائه نشود، آنگاه \fIannotation\fP روی یک مقدار خالی تنظیم می‌شود. .PP نکته: این اطلاعات در قالب‌های ایمیج Docker وجود ندارد، بنابراین هنگام نوشتن ایمیج‌ها در قالب‌های Docker نادیده گرفته می‌شود. .SS \fB--authfile\fP=\fIpath\fP مسیر فایل احراز هویت. پیش‌فرض ${XDG_RUNTIME_DIR}/containers/auth.json است. برای اطلاعات بیشتر containers-auth.json(5) را ببینید. این فایل با استفاده از \fBpodman login\fR\& ایجاد می‌شود. .PP اگر وضعیت احراز هویت در آنجا یافت نشود، $HOME/.docker/config.json بررسی می‌شود که با استفاده از \fBdocker login\fR\& تنظیم شده است. .PP نکته: شما همچنین می‌توانید مسیر پیش‌فرض فایل احراز هویت را با تنظیم متغیر محیطی REGISTRY_AUTH_FILE لغو و بازنویسی کنید. \fBexport REGISTRY_AUTH_FILE=path\fR .SS \fB--build-arg\fP=\fIarg=value\fP یک آرگومان ساخت و مقدار آن را مشخص می‌کند که در دستورالعمل‌های خوانده‌شده از Containerfiles درست مانند متغیرهای محیطی جای‌گذاری می‌شود، اما به فهرست متغیرهای محیطی در پیکربندی ایمیج حاصل اضافه نخواهد شد. .PP لطفاً برای مشاهده فهرست متغیرهایی که می‌توانند در زمان اجرا درون Containerfile بازنویسی شوند، به بخش متغیرهای زمان ساخت (BUILD TIME VARIABLES) \[la]#build\-time\-variables\[ra] مراجعه کنید. .SS \fB--build-arg-file\fP=\fIpath\fP فایلی حاوی خطوطی از آرگومان‌های ساخت به فرم 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\& را بازنویسی و باطل می‌کنند. .SS \fB--build-context\fP=\fIname=value\fP یک بافت ساخت اضافی را با استفاده از نام کوتاه و مکان آن مشخص می‌کند. به بافت‌های ساخت اضافی می‌توان به همان شیوه‌ای که به مراحل مختلف در دستورالعمل \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 .SS \fB--cache-from\fP=\fIimage\fP مخزنی که به عنوان فهرست احتمالی منابع کش استفاده می‌شود. هنگامی که مشخص شود، Podman تلاش خواهد کرد تا ایمیج‌های کش را در مخازن مشخص‌شده جستجو کند و به جای اجرای واقعی مراحل ساخت به صورت محلی، اقدام به دریافت (pull) ایمیج‌های کش خواهد کرد. Podman تنها زمانی برای دریافت ایمیج‌های کش‌شده قبلی تلاش می‌کند که آن‌ها به عنوان تطابق‌های معتبر کش (cache hits) در نظر گرفته شوند. .PP از گزینه \fB--cache-to\fR برای پر کردن یک یا چند مخزن راه دور با محتوای کش استفاده کنید. .PP مثال .EX # populate a cache and also consult it podman 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 در Podman متفاوت از گزینه \fB--cache-from\fR در Docker و BuildKit طراحی شده است. مکانیزم کش توزیع‌شده در Podman ایمیج‌های میانی را مستقیماً از خود رجیستری راه دور دریافت می‌کند، بر خلاف Docker و BuildKit که ایمیج میانی درون خود ایمیج ذخیره می‌شود. رویکرد Podman مشابه kaniko است که اندازه ایمیج اصلی را با ایمیج‌های میانی افزایش نمی‌دهد. همچنین با استفاده از مکانیزم کش Podman، ایمیج‌های میانی واقعاً می‌توانند به صورت توزیع‌شده در یک یا چند رجیستری راه دور نگهداری شوند. .SS \fB--cache-to\fP=\fIimage\fP این فلگ را برای مشخص کردن فهرستی از مخازن راه دور که برای ذخیره ایمیج‌های کش استفاده می‌شوند تنظیم کنید. Podman تلاش خواهد کرد تا ایمیج کش تازه‌ساخته‌شده را به مخازن راه دور ارسال (push) کند. .PP نکته: به منظور استفاده از محتوای کش در یک مخزن راه دور، از گزینه \fB--cache-from\fR استفاده کنید. .PP مثال .EX # populate a cache and also consult it podman 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 در Podman متفاوت از گزینه \fB--cache-to\fR در Docker و BuildKit طراحی شده است. مکانیزم کش توزیع‌شده در Podman ایمیج‌های میانی را مستقیماً به خود رجیستری راه دور ارسال می‌کند، بر خلاف Docker و BuildKit که ایمیج میانی درون خود ایمیج ذخیره می‌شود. رویکرد Podman مشابه kaniko است که اندازه ایمیج اصلی را با ایمیج‌های میانی افزایش نمی‌دهد. همچنین با استفاده از مکانیزم کش Podman، ایمیج‌های میانی واقعاً می‌توانند به صورت توزیع‌شده در یک یا چند رجیستری راه دور نگهداری شوند. .SS \fB--cache-ttl\fP استفاده از ایمیج‌های کش‌شده را تنها به ایمیج‌هایی محدود می‌کند که برچسب زمانی ایجاد آن‌ها کمتر از \fIduration\fP پیش باشد. برای مثال اگر \fB--cache-ttl=1h\fR مشخص شود، Podman تنها ایمیج‌های کش میانی را در نظر می‌گیرد که در بازه زمانی کمتر از یک ساعت ایجاد شده باشند، و ایمیج‌های کش میانی خارج از این بازه زمانی نادیده گرفته خواهند شد. .PP نکته: تنظیم دستی \fB--cache-ttl=0\fR در پیاده‌سازی معادل استفاده از \fB--no-cache\fR است، زیرا عملاً به این معنی است که کاربر به هیچ وجه مایل به استفاده از کش نیست. \fB--cap-add\fP=\fICAP_xxx\fP .PP هنگام اجرای دستورالعمل‌های RUN، دستور مشخص‌شده در دستورالعمل را با قابلیت (capability) مشخص‌شده که به مجموعه قابلیت‌های آن اضافه شده است، اجرا می‌کند. برخی از قابلیت‌ها به صورت پیش‌فرض اعطا می‌شوند؛ این گزینه می‌تواند برای افزودن قابلیت‌های بیشتر استفاده شود. .SS \fB--cap-add\fP=\fICAP_xxx\fP هنگام اجرای دستورالعمل‌های RUN، دستور مشخص‌شده در دستورالعمل با قابلیت مشخص‌شده اضافه شده به مجموعه قابلیت‌های آن اجرا می‌شود. برخی قابلیت‌ها به طور پیش‌فرض اعطا می‌شوند؛ این گزینه می‌تواند برای افزودن موارد بیشتر استفاده شود. .SS \fB--cap-drop\fP=\fICAP_xxx\fP هنگام اجرای دستورالعمل‌های 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 مشخص شود، صرف‌نظر از ترتیبی که گزینه‌ها مشخص شده‌اند، حذف خواهد شد. .SS \fB--cert-dir\fP=\fIpath\fP از گواهی‌های موجود در \fIpath\fP (*\&.crt، *\&.cert، *\&.key) برای اتصال به رجیستری و بازیابی محتوا از مکان‌های HTTPS برای دستورالعمل‌های ADD استفاده می‌کند. دایرکتوری پیش‌فرض گواهی‌ها \fI/etc/containers/certs.d\fP\& است. .SS \fB--cgroup-parent\fP=\fIpath\fP مسیر cgroups که cgroup مربوط به دستورالعمل‌های RUN در زیر آن ایجاد خواهد شد. اگر مسیر مطلق نباشد، مسیر نسبت به مسیر cgroups فرایند init در نظر گرفته می‌شود. اگر cgroupها از قبل وجود نداشته باشند، ایجاد خواهند شد. .SS \fB--cgroupns\fP=\fIhow\fP پیکربندی فضاهای نام cgroup (cgroup namespaces) را هنگام پردازش دستورالعمل‌های \fBRUN\fR تنظیم می‌کند. مقدار پیکربندی‌شده می‌تواند "" (رشته خالی) یا "private" باشد که نشان می‌دهد باید یک فضای نام cgroup جدید ایجاد شود، یا می‌تواند "host" باشد که نشان می‌دهد باید از فضای نام cgroup که خود \fBpodman\fR در آن اجرا می‌شود مجدداً استفاده شود. .SS \fB--cleanup\fP پس از اتمام فرآیند ساخت، ایمیج‌های ساخته‌شده از روی نودهای فارم حذف شوند. .SS \fB--compat-volumes\fP دایرکتوری‌هایی را که با استفاده از دستورالعمل VOLUME علامت‌گذاری شده‌اند (چه در این بیلد و چه مواردی که از تصاویر پایه به ارث رسیده‌اند) به گونه‌ای مدیریت می‌کند که محتوای آن‌ها فقط توسط دستورالعمل‌های ADD و COPY قابل تغییر باشد. هر تغییری که توسط دستورالعمل‌های RUN در آن مکان‌ها ایجاد شود بازگردانده (revert) خواهد شد. قبل از معرفی این گزینه، این رفتار به صورت پیش‌فرض فعال بود، اما اکنون به صورت پیش‌فرض غیرفعال است. .SS \fB--compression-format\fP=\fBgzip\fP | \fIzstd\fP | \fIzstd:chunked\fP قالب فشرده‌سازی مورد استفاده را مشخص می‌کند. مقادیر پشتیبانی‌شده عبارتند از: \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 یا یک رجیستری) تأثیر می‌گذارد. هنگامی که خروجی، ذخیره‌سازی کانتینر محلی باشد (حالت پیش‌فرض)، لایه‌ها همیشه هنگام ورود از حالت فشرده خارج می‌شوند، بنابراین فشرده‌سازی در زمان \fBpodman push\fR اعمال می‌شود. .SS \fB--compression-level\fP=\fIlevel\fP سطح فشرده‌سازی مورد استفاده را مشخص می‌کند. این مقدار بستگی به الگوریتم فشرده‌سازی مورد استفاده دارد؛ به عنوان مثال برای zstd مقادیر پذیرفته‌شده در محدوده ۱-۲۰ (شامل خود این اعداد) است، در حالی که برای gzip بین ۱-۹ (شامل خود این اعداد) می‌باشد. اگر مشخص نشود، سطح فشرده‌سازی از تنظیمات \fBcompression_level\fR در containers.conf خوانده می‌شود. .SS \fB--cpp-flag\fP=\fIflags\fP تنظیم فلگ‌های اضافی برای ارسال به پیش‌پردازنده سی cpp(1). پرونده‌های Containerfile که با پسوند ".in" پایان می‌یابند از طریق cpp(1) پیش‌پردازش می‌شوند. این گزینه می‌تواند برای ارسال فلگ‌های اضافی به cpp استفاده شود. نکته: شما همچنین می‌توانید با تنظیم متغیر محیطی BUILDAH_CPPFLAGS، مقادیر پیش‌فرض CPPFLAGS را تنظیم کنید (مانند \fBexport BUILDAH_CPPFLAGS="-DDEBUG"\fR). .SS \fB--cpu-period\fP=\fIlimit\fP دوره 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 .SS \fB--cpu-quota\fP=\fIlimit\fP محدود کردن سهمیه (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 .SS \fB--cpu-shares\fP, \fB-c\fP=\fIshares\fP سهم‌های پردازنده (وزن نسبی) .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 .SS \fB--cpuset-cpus\fP=\fInumber\fP پردازنده‌هایی که اجازه اجرا در آن‌ها داده می‌شود (0-3, 0,1) .SS \fB--cpuset-mems\fP=\fInodes\fP گره‌های حافظه (MEMs) که اجازه اجرا در آن‌ها داده می‌شود (0-3, 0,1). فقط در سیستم‌های NUMA مؤثر است. .PP اگر چهار گره حافظه در سیستم خود دارید (0-3)، با استفاده از \fB--cpuset-mems=0,1\fR فرایندهای موجود در کانتینر شما فقط از حافظه دو گره اول حافظه استفاده خواهند کرد. .SS \fB--created-annotation\fP یک یادداشت (\fIannotation\fP) تصویر (همچنین ببینید: \fB--annotation\fP) به فراداده (متادیتا) تصویر اضافه می‌کند که مقدار "org.opencontainers.image.created" را روی زمان فعلی، یا روی برچسب زمانی مشخص‌شده با فلگ \fB--source-date-epoch\fP یا \fB--timestamp\fP (در صورت استفاده از هرکدام) تنظیم می‌کند. اگر مقدار \fIfalse\fP باشد، چنین یادداشتی در تصویر نوشته‌شده وجود نخواهد داشت. .PP نکته: این اطلاعات در قالب‌های تصویر داکر وجود ندارد، بنابراین هنگام نوشتن تصاویر در قالب‌های داکر نادیده گرفته می‌شود. .SS \fB--creds\fP=\fI[username[:password]]\fP مقدار [username[:password]] برای استفاده جهت احراز هویت با رجیستری در صورت نیاز. اگر یک یا هر دو مقدار ارائه نشوند، یک اعلان خط فرمان ظاهر می‌شود و می‌توان مقدار را وارد کرد. گذرواژه بدون نمایش (echo) وارد می‌شود. .SS \fB--decryption-key\fP=\fIkey[:passphrase]\fP مقدار [key[:passphrase]] برای رمزگشایی تصاویر استفاده می‌شود. کلید می‌تواند به کلیدها و/یا گواهی‌ها اشاره کند. رمزگشایی با تمام کلیدها امتحان خواهد شد. اگر کلید با عبارت عبور محافظت شده باشد، لازم است در آرگومان ارسال شود و در غیر این صورت حذف شود. .SS \fB--device\fP=\fIhost-device[:container-device][:permissions]\fP یک دستگاه میزبان یا دستگاه‌های زیر یک دایرکتوری را به محیط هر دستورالعمل \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\& اجبار شود. .SS \fB--disable-compression\fP, \fB-D\fP هنگام ساخت ایمیج، لایه‌های سیستم‌فایل فشرده‌سازی نمی‌شوند مگر اینکه مکانی که ایمیج در آن نوشته می‌شود این را ایجاب کند. این تنظیم پیش‌فرض است، زیرا لایه‌های ایمیج هنگام ارسال به رجیستری‌ها به طور خودکار فشرده می‌شوند. .SS \fB--dns\fP=\fIipaddr\fP تنظیم سرورهای DNS سفارشی. استفاده از \fB--dns\fP همراه با \fB--network=none\fP\& نامعتبر است. .PP این گزینه می‌تواند برای بازنویسی پیکربندی DNS ارائه‌شده به کانتینر استفاده شود. معمولاً زمانی این کار لازم است که پیکربندی DNS میزبان برای کانتینر نامعتبر باشد (برای نمونه 127.0.0.1). در این حالت، فلگ \fB--dns\fR برای هر بار اجرا ضروری است. .PP مقدار ویژه \fBnone\fP می‌تواند برای غیرفعال کردن ایجاد /etc/resolv.conf در کانتینر توسط Podman تعیین شود. فایل /etc/resolv.conf موجود در تصویر بدون تغییر استفاده خواهد شد. .SS \fB--dns-option\fP=\fIoption\fP تنظیم گزینه‌های DNS سفارشی. استفاده از \fB--dns-option\fP همراه با \fB--network=none\fP\& نامعتبر است. .SS \fB--dns-search\fP=\fIdomain\fP تنظیم دامنه‌های جستجوی DNS سفارشی. استفاده از \fB--dns-search\fP همراه با \fB--network=none\fP\& نامعتبر است. .SS \fB--env\fP=\fIenv[=value]\fP افزودن یک مقدار (برای نمونه env=\fIvalue\fP) به تصویر ساخته‌شده. این گزینه می‌تواند چندین بار استفاده شود. اگر نه \fB=\fR و نه یک \fB*value*\fR تعیین نشده باشد، اما \fIenv\fP در محیط فعلی تنظیم شده باشد، مقدار از محیط فعلی به تصویر اضافه خواهد شد. مقدار \fIenv\fP می‌تواند توسط دستورالعمل‌های ENV در Containerfile بازنویسی شود. برای حذف یک متغیر محیطی از تصویر ساخته‌شده، از گزینه \fB--unsetenv\fR استفاده کنید. .SS \fB--farm\fP نام فارم (مزرعه نودها) برای ارسال عملیات ساخت به آن. .SS \fB--file\fP, \fB-f\fP=\fIContainerfile\fP یک Containerfile را مشخص می‌کند که حاوی دستورالعمل‌هایی برای ساخت تصویر است؛ چه یک فایل محلی باشد یا یک URL با پروتکل \fBhttp\fP یا \fBhttps\fP\&. اگر بیش از یک Containerfile تعیین شده باشد، دستورالعمل‌های \fIFROM\fP تنها از آخرین فایل مشخص‌شده پذیرفته خواهند شد. .PP اگر یک فایل محلی به عنوان Containerfile مشخص شده باشد و وجود نداشته باشد، دایرکتوری زمینه (context directory) به ابتدای مقدار فایل محلی اضافه خواهد شد. .PP اگر \fB-f -\fR را مشخص کنید، محتویات Containerfile از ورودی استاندارد (stdin) خوانده خواهد شد. .SS \fB--force-compression\fP در صورت تنظیم، از الگوریتم فشرده‌سازی مشخص‌شده استفاده می‌کند حتی اگر مقصد از قبل حاوی نسخه‌ای با فشرده‌سازی متفاوت باشد. اگر \fB--compression-format\fR به‌طور صریح در خط فرمان مشخص شده باشد یا \fBcompression_format\fR در containers.conf تنظیم شده باشد، مقدار پیش‌فرض \fBtrue\fR است، در غیر این صورت \fBfalse\fR می‌باشد. .SS \fB--force-rm\fP همیشه کانتینرهای میانی را پس از ساخت حذف می‌کند، حتی اگر ساخت با شکست مواجه شود (پیش‌فرض false است). .SS \fB--format\fP قالب مانیفست و داده‌های پیکربندی تصویر ساخته‌شده را کنترل می‌کند. قالب‌های شناخته‌شده شامل \fIoci\fP (مشخصات OCI image-spec v1.0، پیش‌فرض) و \fIdocker\fP (نسخه 2، با استفاده از قالب شِمای 2 برای مانیفست) هستند. .PP نکته: همچنین می‌توانید قالب پیش‌فرض را با تنظیم متغیر محیطی BUILDAH_FORMAT بازنویسی کنید. \fBexport BUILDAH_FORMAT=docker\fR .SS \fB--from\fP نخستین دستورالعمل \fBFROM\fR را درون Containerfile بازنویسی می‌کند. اگر چندین دستورالعمل FROM در یک Containerfile وجود داشته باشد، تنها دستورالعمل اول تغییر می‌کند. .SS \fB--group-add\fP=\fIgroup\fP | \fIkeep-groups\fP اختصاص گروه‌های اضافی به کاربر اصلی در حال اجرا درون فرایند کانتینر. .RS .IP \(bu 2 مقدار \fBkeep-groups\fR یک فلگ ویژه است که به Podman می‌گوید دسترسی گروه‌های تکمیلی (supplementary group access) را حفظ کند. .RE .PP به کانتینر اجازه می‌دهد از دسترسی گروه‌های تکمیلی کاربر استفاده کند. اگر سیستم‌های فایل یا دستگاه‌ها تنها توسط گروه کاربر بدون ریشه (rootless) قابل دسترس باشند، این فلگ به زمان اجرای OCI می‌گوید دسترسی گروهی را به داخل کانتینر منتقل کند. در حال حاضر فقط با زمان اجرای OCI موسوم به \fBcrun\fR در دسترس است. نکته: \fBkeep-groups\fR انحصاری است و گروه‌های دیگر را نمی‌توان همراه با این فلگ مشخص کرد. .SS \fB--help\fP, \fB-h\fP چاپ راهنمای نحوه استفاده (usage statement) .SS \fB--hooks-dir\fP=\fIpath\fP هر فایل \fB*.json\fR در مسیر، یک قلاب (hook) را برای کانتینرهای ساخت podman پیکربندی می‌کند. برای جزئیات بیشتر در مورد ساختار فایل‌های JSON و معناشناسی تزریق قلاب، به oci-hooks(5) مراجعه کنید. ابزار Podman در حال حاضر از هر دو شِمای قلاب 1.0.0 و 0.1.0 پشتیبانی می‌کند، هرچند شِمای 0.1.0 منسوخ شده است. .PP این گزینه ممکن است چندین بار تنظیم شود؛ مسیرهای مربوط به گزینه‌های بعدی دارای اولویت بالاتری هستند (صفحه راهنمای oci-hooks(5) اولویت دایرکتوری را مورد بحث قرار می‌دهد). .PP برای شرایط حاشیه‌نویسی (annotation conditions)،‏ podman از هرگونه حاشیه‌نویسی تنظیم‌شده در پیکربندی OCI ایجادشده استفاده می‌کند. .PP برای شرایط متصل‌کردن پیوندی (bind-mount conditions)، تنها اتصال‌هایی که به‌طور صریح توسط فراخواننده از طریق --volume درخواست شده‌اند در نظر گرفته می‌شوند. اتصال‌های پیوندی که podman به‌طور پیش‌فرض درج می‌کند (مانند /dev/shm) در نظر گرفته نمی‌شوند. .PP اگر --hooks-dir برای فراخوانندگان ریشه (root) تنظیم نشده باشد، Podman در حال حاضر به ترتیب افزایش اولویت به /usr/share/containers/oci/hooks.d و /etc/containers/oci/hooks.d پیش‌فرض خواهد بود. استفاده از این مقادیر پیش‌فرض منسوخ شده است و فراخوانندگان باید به تنظیم صریح --hooks-dir مهاجرت کنند. .SS \fB--http-proxy\fP به‌طور پیش‌فرض، اگر متغیرهای محیطی پروکسی برای فرایند podman تنظیم شده باشند، به داخل کانتینر منتقل می‌شوند. این رفتار را می‌توان با تنظیم گزینه \fB--http-proxy\fR روی \fBfalse\fR\& غیرفعال کرد. متغیرهای محیطی منتقل‌شده شامل \fBhttp_proxy\fR،‏ \fBhttps_proxy\fR،‏ \fBftp_proxy\fR،‏ \fBno_proxy\fR و همچنین نسخه‌های با حروف بزرگ آن‌ها هستند. .SS \fB--identity-label\fP یک برچسب \fBio.podman.version\fR اضافه می‌کند که مقدار آن برابر با نسخه podman که تصویر را ساخته است تنظیم می‌شود (پیش‌فرض true است مگر اینکه از \fB--timestamp\fR یا \fB--source-date-epoch\fR استفاده شود). .SS \fB--ignorefile\fP مسیر به یک فایل .containerignore (.dockerignore) جایگزین. .SS \fB--iidfile\fP=\fIImageIDfile\fP شناسه تصویر ساخته‌شده را در فایل می‌نویسد. هنگامی که \fB--platform\fR بیش از یک بار مشخص شده باشد، تلاش برای استفاده از این گزینه خطایی را ایجاد خواهد کرد. .SS \fB--iidfile-raw\fP=\fIImageIDfile\fP شناسه تصویر ساخته‌شده را بدون پیشوند الگوریتم (برای نمونه \fBsha256:\fR) در فایل می‌نویسد. هنگامی که \fB--platform\fR بیش از یک بار مشخص شده باشد، تلاش برای استفاده از این گزینه خطایی را ایجاد خواهد کرد. .PP نام مستعار \fB--raw-iidfile\fR نیز در دسترس است. .SS \fB--inherit-annotations\fP=\fIbool-value\fP حاشیه‌نویسی‌ها (annotations) را از تصویر پایه یا مراحل پایه به ارث می‌برد (پیش‌فرض true است). موارد استفاده‌ای که این فلگ را روی \fIfalse\fP تنظیم می‌کنند ممکن است نیاز داشته باشند همین کار را برای فلگ \fB--created-annotation\fP نیز انجام دهند. .SS \fB--inherit-labels\fP برچسب‌ها (labels) را از تصویر پایه یا مراحل پایه به ارث می‌برد (پیش‌فرض true است). .SS \fB--ipc\fP=\fIhow\fP پیکربندی فضاهای نام IPC را هنگام رسیدگی به دستورالعمل‌های \fBRUN\fR تنظیم می‌کند. مقدار پیکربندی‌شده می‌تواند "" (رشته خالی) یا "container" برای نشان دادن اینکه یک فضای نام IPC جدید باید ایجاد شود، یا "host" برای نشان دادن اینکه فضای نام IPC که خود \fBpodman\fR در آن در حال اجرا است باید مجدداً استفاده شود، یا مسیر یک فضای نام IPC که از قبل توسط فرایند دیگری در حال استفاده است، باشد. .SS \fB--isolation\fP=\fItype\fP نوع ایزوله‌سازی مورد استفاده برای اجرای فرایندها به عنوان بخشی از دستورالعمل‌های \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 .SS \fB--jobs\fP=\fInumber\fP حداکثر N مرحله همزمان را به صورت موازی اجرا می‌کند. اگر تعداد کارها بیشتر از 1 باشد، stdin از /dev/null خوانده خواهد شد. اگر 0 مشخص شود، هیچ محدودیتی برای تعداد کارهایی که به صورت موازی اجرا می‌شوند وجود نخواهد داشت. .SS \fB--label\fP=\fIlabel\fP افزودن یک برچسب تصویر \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 اگر قابلیت‌های مشخص‌شده در مجموعه پیش‌فرض نباشند، موتورهای کانتینر باید یک پیام خطا چاپ کنند و کانتینر را با قابلیت‌های پیش‌فرض اجرا خواهند کرد. .SS \fB--layer-label\fP=\fIlabel[=value]\fP افزودن یک برچسب تصویر میانی \fIlabel\fP (برای نمونه label=\fIvalue\fP) به متاداده در تصاویر میانی، یعنی هر تصویری که برای مراحل غیرنهایی و برای دستورالعمل‌های غیرنهایی در مراحلی که \fB--layers\fP برابر با \fBtrue\fP\& است ساخته شده باشد. این گزینه می‌تواند چندین بار استفاده شود. اگر نام \fIlabel\fP ذکر شود، اما نه \fB=\fR و نه یک \fBvalue\fR ارائه نشود، آنگاه \fIlabel\fP روی یک مقدار خالی تنظیم می‌شود. .SS \fB--layers\fP کش‌کردن تصاویر میانی در طول فرایند ساخت (پیش‌فرض \fBfalse\fR است). .PP نکته: همچنین می‌توانید مقدار پیش‌فرض لایه‌ها را با تنظیم متغیر محیطی BUILDAH_LAYERS بازنویسی کنید. \fBexport BUILDAH_LAYERS=true\fR .SS \fB--local\fP, \fB-l\fP علاوه بر نودهای فارم، عملیات ساخت روی سیستم محلی نیز انجام شود. .SS \fB--logfile\fP=\fIfilename\fP خروجی لاگ را که به خروجی استاندارد و خطای استاندارد ارسال می‌شد، به جای خروجی استاندارد و خطای استاندارد در فایل مشخص‌شده می‌نویسد. .SS \fB--memory\fP, \fB-m\fP=\fInumber[unit]\fP محدودیت حافظه (قالب: []، که در آن واحد = b، k، m یا g است) .PP به شما اجازه می‌دهد حافظه در دسترس کانتینر را محدود کنید. اگر میزبان از حافظه swap پشتیبانی کند، تنظیم حافظه \fB-m\fP می‌تواند بزرگ‌تر از RAM فیزیکی باشد. اگر محدودیت 0 مشخص شود (عدم استفاده از \fB-m\fP)، حافظه کانتینر محدود نخواهد شد. حد واقعی ممکن است به مضربی از اندازه صفحه (page size) سیستم‌عامل به بالا گرد شود (این مقدار بسیار بزرگ خواهد بود، یعنی میلیون‌ها تریلیون). .SS \fB--memory-swap\fP=\fInumber[unit]\fP یک مقدار محدودیت برابر با حافظه به علاوه swap. باید همراه با فلگ \fB-m\fP (\fB--memory\fP) استفاده شود. مقدار \fBLIMIT\fR مربوط به swap همیشه باید از مقدار \fB-m\fP (\fB--memory\fP) بزرگ‌تر باشد. به طور پیش‌فرض، \fBLIMIT\fR سواپ دو برابر مقدار --memory تنظیم خواهد شد. .PP قالب \fBLIMIT\fR به صورت \fB[]\fR است. واحد می‌تواند \fBb\fR (بایت)، \fBk\fR (کیلوبایت)، \fBm\fR (مگابایت)، یا \fBg\fR (گیگابایت) باشد. اگر واحدی مشخص نکنید، \fBb\fR استفاده می‌شود. برای فعال‌سازی swap نامحدود، مقدار LIMIT را روی \fB-1\fR تنظیم کنید. .SS \fB--mount\fP=\fImount-specification\fP این مونت را پیش از اجرا به هر دستور \fBRUN\fR در Containerfile اضافه می‌کند. برای مثال: .PP \fBpodman 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 .SS \fB--network\fP=\fImode\fP, \fB--net\fP پیکربندی فضاهای نام شبکه را هنگام پردازش دستورالعمل‌های \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\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 .SS \fB--no-cache\fP از ایمیج‌های موجود در کش برای ساخت کانتینر استفاده نمی‌کند. ساخت از ابتدا با مجموعه‌ای جدید از لایه‌های کش‌شده انجام می‌شود. .SS \fB--no-hostname\fP فایل \fI/etc/hostname\fP را در کانتینر برای دستورالعمل‌های RUN ایجاد نمی‌کند. .PP به طور پیش‌فرض، Podman فایل \fI/etc/hostname\fP را مدیریت کرده و نام میزبان کانتینر را اضافه می‌کند. هنگامی که گزینه \fB--no-hostname\fP تنظیم شود، فایل \fI/etc/hostname\fP ایمیج (در صورت وجود) بدون تغییر حفظ خواهد شد. .SS \fB--no-hosts\fP فایل \fI/etc/hosts\fP را در کانتینر برای دستورالعمل‌های RUN ایجاد نمی‌کند. .PP به طور پیش‌فرض، Podman فایل \fI/etc/hosts\fP را مدیریت کرده و آدرس IP خود کانتینر را اضافه می‌کند. گزینه \fB--no-hosts\fP این مورد را غیرفعال می‌کند و فایل \fI/etc/hosts\fP ایمیج بدون تغییر حفظ خواهد شد. با گزینه \fB--add-host\fP تداخل دارد. .SS \fB--omit-history\fP حذف اطلاعات تاریخچه ساخت در ایمیج ساخته‌شده (پیش‌فرض false). .PP این گزینه برای مواردی مفید است که کاربران نهایی صراحتاً می‌خواهند \fB--omit-history\fR را برای حذف بخش اختیاری \fBHistory\fR از ایمیج‌های ساخته‌شده تنظیم کنند، یا هنگام کار با ایمیج‌هایی که توسط ابزارهای ساختی ساخته شده‌اند که اطلاعات \fBHistory\fR را در ایمیج‌های خود قرار نمی‌دهند. .SS \fB--os-feature\fP=\fIfeature\fP تنظیم نام یک ویژگی سیستم‌عامل (\fIfeature\fP) مورد نیاز برای ایمیجی که قرار است ساخته شود. به طور پیش‌فرض، اگر ایمیج بر پایه \fIscratch\fP نباشد، فهرست ویژگی‌های الزامی سیستم‌عامل ایمیج پایه (در صورتی که ایمیج پایه هر کدام را مشخص کرده باشد) حفظ می‌شود. این گزینه معمولاً فقط زمانی معنادار است که سیستم‌عامل ایمیج ویندوز باشد. .PP اگر \fIfeature\fP دارای یک علامت \fB-\fR در انتها باشد، آن \fIfeature\fP از مجموعه ویژگی‌های مورد نیازی که در ایمیج فهرست می‌شوند حذف می‌گردد. .SS \fB--os-version\fP=\fIversion\fP تنظیم نسخه سیستم‌عامل (\fIversion\fP) دقیقاً مورد نیاز برای ایمیجی که ساخته خواهد شد. به طور پیش‌فرض، اگر ایمیج بر پایه \fIscratch\fP نباشد، نسخه سیستم‌عامل الزامی ایمیج پایه (در صورت مشخص شدن در ایمیج پایه) حفظ می‌شود. این گزینه معمولاً تنها زمانی معنا دارد که سیستم‌عامل ایمیج ویندوز باشد و به طور معمول در ایمیج‌های پایه ویندوز تنظیم شده است، بنابراین استفاده از این گزینه معمولاً غیرضروری است. .SS \fB--pid\fP=\fIpid\fP پیکربندی فضاهای نام PID را هنگام پردازش دستورالعمل‌های \fBRUN\fR تعیین می‌کند. مقدار پیکربندی‌شده می‌تواند "" (رشته خالی) یا "private" باشد تا نشان دهد یک فضای نام PID جدید باید ایجاد شود، یا می‌تواند "host" باشد تا نشان دهد فضای نام PID که خود \fBpodman\fR در آن در حال اجراست باید مجدداً استفاده شود، یا می‌تواند مسیر یک فضای نام PID باشد که قبلاً توسط فرآیند دیگری استفاده شده است. .SS \fB--platforms\fP=\fIp1,p2,p3...\fP فهرست پلتفرم‌ها و معماری‌های هدف برای ساخت ایمیج چندمعماری. .SS \fB--pull\fP=\fIpolicy\fP سیاست دریافت (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 .SS \fB--quiet\fP, \fB-q\fP پیام‌های خروجی را که نشان‌دهنده دستورالعمل در حال پردازش، پیشرفت دریافت ایمیج‌ها از رجیستری و نوشتن ایمیج خروجی هستند، بی‌صدا (سرکوب) کن. .SS \fB--retry\fP=\fIattempts\fP تعداد دفعات تلاش مجدد در صورت بروز خطا هنگام ارسال یا دریافت (push/pull) ایمیج‌ها به/از رجیستری. .PP پیش‌فرض \fB3\fR است\&. .SS \fB--retry-delay\fP=\fIduration\fP مدت زمان تاخیر بین تلاش‌های مجدد در صورت بروز خطا هنگام ارسال یا دریافت (push/pull) ایمیج‌ها به/از رجیستری. .PP پیش‌فرض \fB2s\fR است\&. .SS \fB--rewrite-timestamp\fP هنگام تولید لایه‌های جدید برای ایمیج، با جایگزین کردن هرگونه مهرزمانی (timestamp) پس از مقدار استفاده‌شده توسط فلگ \fB--source-date-epoch\fP (در صورت ارائه) با همان مقدار، اطمینان حاصل کن که هیچ محتوای تازه اضافه‌شده‌ای مهرزمانی بعد از آن مقدار را نداشته باشد. .SS \fB--rm\fP حذف کانتینرهای میانی پس از ساخت موفقیت‌آمیز (پیش‌فرض true). .SS \fB--runtime\fP=\fIpath\fP مسیر (\fIpath\fP) به یک زمان‌اجرای (runtime) جایگزین سازگار با OCI، که برای اجرای دستورات مشخص‌شده توسط دستورالعمل \fBRUN\fP استفاده خواهد شد. مقدار پیش‌فرض \fBrunc\fR است، یا \fBcrun\fR هنگامی که سیستم برای استفاده از cgroups V2 پیکربندی شده باشد. .PP نکته: شما همچنین می‌توانید با تنظیم متغیر محیطی BUILDAH_RUNTIME، زمان‌اجرای پیش‌فرض را بازنویسی کنید. \fBexport BUILDAH_RUNTIME=/usr/bin/crun\fR .SS \fB--runtime-flag\fP=\fIflag\fP فلگ‌های سراسری را برای زمان‌اجرای کانتینر اضافه می‌کند. برای مشاهده فهرست فلگ‌های پشتیبانی‌شده، لطفاً به صفحات راهنما (man pages) زمان‌اجرای کانتینر انتخابی مراجعه کنید. .PP نکته: \fB--\fR ابتدایی را به فلگ ارسال نکنید. برای ارسال فلگ runc یعنی \fB--log-format json\fR به podman build، گزینه ارائه‌شده باید به‌صورت \fB--runtime-flag log-format=json\fR باشد\&. .SS \fB--save-stages\fP هنگامی که با \fB--stage-labels\fR ترکیب شود، تمامی ایمیج‌های مراحل (از جمله ایمیج نهایی) برچسب‌های متادیتا را برای شناسایی و مدیریت آسان‌تر شامل خواهند شد. .SS \fB--sbom\fP=\fIpreset\fP تولید لیست مواد نرم‌افزاری / 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 .SS \fB--sbom-image-output\fP=\fIpath\fP هنگام تولید SBOM، لیست مواد نرم‌افزاری (SBOM) تولیدشده را در مسیر مشخص‌شده در ایمیج خروجی ذخیره کن. هیچ مقدار پیش‌فرضی وجود ندارد. .SS \fB--sbom-image-purl-output\fP=\fIpath\fP هنگام تولید SBOM، آن‌ها را برای اطلاعات PURL (نشانی اینترنتی بسته / package URL \[la]https://github.com/package\-url/purl\-spec/blob/master/PURL\-SPECIFICATION.rst\[ra]) اسکن کن، و فهرستی از PURLهای یافت‌شده را در مسیر مشخص‌شده در ایمیج خروجی ذخیره نما. هیچ مقدار پیش‌فرضی وجود ندارد. .SS \fB--sbom-merge-strategy\fP=\fImethod\fP اگر بیش از یک مقدار \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 .SS \fB--sbom-output\fP=\fIfile\fP هنگام تولید SBOM، لیست مواد نرم‌افزاری (SBOM) تولیدشده را در پرونده نام‌برده در سیستم‌فایل محلی ذخیره کن. هیچ مقدار پیش‌فرضی وجود ندارد. .SS \fB--sbom-purl-output\fP=\fIfile\fP هنگام تولید SBOM، آن‌ها را برای اطلاعات PURL (نشانی اینترنتی بسته / package URL \[la]https://github.com/package\-url/purl\-spec/blob/master/PURL\-SPECIFICATION.rst\[ra]) اسکن کن، و فهرستی از PURLهای یافت‌شده را در پرونده نام‌برده در سیستم‌فایل محلی ذخیره نما. هیچ مقدار پیش‌فرضی وجود ندارد. .SS \fB--sbom-scanner-command\fP=\fIimage\fP تولید SBOM با اجرای دستور مشخص‌شده از ایمیج اسکنر. اگر چندین دستور مشخص شده باشد، آن‌ها به ترتیبی که تعیین شده‌اند اجرا می‌شوند. این جایگزینی‌های متنی انجام می‌شوند: - {ROOTFS} ریشه فایل‌سیستم ایمیج ساخته‌شده، متصل‌شده به‌صورت bind mount. - {CONTEXT} زمینه ساخت (build context) و زمینه‌های ساخت اضافی، متصل‌شده به‌صورت bind mount. - {OUTPUT} نام یک پرونده خروجی موقت، برای خواندن و ادغام با سایرین یا کپی شدن در جای دیگر. .SS \fB--sbom-scanner-image\fP=\fIimage\fP تولید SBOM با استفاده از ایمیج اسکنر مشخص‌شده. .SS \fB--secret\fP=\fBid=id[,src=\fIenvOrFile\fP][,env=\fIENV\fP][,type=\fIfile\fP | \fIenv\fP]\fP ارسال اطلاعات محرمانه (سکرت / secret) برای استفاده در Containerfile جهت ساخت ایمیج‌ها به روشی امن که در نهایت در ایمیج نهایی ذخیره نشود یا در مراحل دیگر دیده نشود. مقدار سکرت از یک متغیر محیطی یا پرونده با نام ارائه‌شده توسط گزینه "id"، یا با نام تعیین‌شده توسط گزینه "src" (در صورت مشخص شدن)، یا از یک متغیر محیطی مشخص‌شده با گزینه "env" خوانده می‌شود. اطلاعات محرمانه (سکرت) به‌طور پیش‌فرض در مسیر \fB/run/secrets/\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 نکته: تغییر محتوای پرونده‌های سکرت، موجب بازسازی مجدد لایه‌هایی که از سکرت‌های مذکور استفاده می‌کنند نخواهد شد. .SS \fB--security-opt\fP=\fIoption\fP گزینه‌های امنیتی .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\&. .SS \fB--shm-size\fP=\fInumber[unit]\fP اندازه \fB/dev/shm\fR\&. قالب آن به‌صورت \fB\fR است\&. \fBnumber\fR باید بزرگتر از \fB0\fR باشد\&. واحد اختیاری است و می‌تواند \fBb\fR (بایت)، \fBk\fR (کیلوبایت)، \fBm\fR (مگابایت)، یا \fBg\fR (گیگابایت) باشد. اگر واحد را حذف کنید، سیستم از بایت استفاده می‌کند. اگر اندازه را به‌طور کامل حذف کنید، سیستم از \fB64m\fR استفاده می‌کند\&. .SS \fB--skip-unused-stages\fP صرف‌نظر کردن از مراحلی در ساخت‌های چندمرحله‌ای که تأثیری روی مرحله هدف ندارند (پیش‌فرض \fBtrue\fR است). .SS \fB--source-date-epoch\fP=\fIseconds\fP برچسب زمانی «ایجاد شده» (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 که زمان مشخص‌شده‌اش را بر روی محتویات لایه‌های جدید نیز اعمال می‌کند، تداخل دارد. .SS \fB--source-policy-file\fP=\fIpathname\fP مسیر یک فایل 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 .SS \fB--squash\fP تمامی لایه‌ها، از جمله لایه‌های متعلق به تصویر (تصاویر) پایه را در یک لایه واحد ادغام (squash) می‌کند. (پیش‌فرض false است). .PP به‌صورت پیش‌فرض، Podman لایه‌های موجود تصویر پایه را حفظ کرده و در هنگام ساخت تنها یک لایه جدید اضافه می‌کند. گزینه --layers می‌تواند برای حفظ لایه‌های میانی ساخت استفاده شود. .SS \fB--squash-all\fP ادغام تمام لایه‌های ایمیج جدید (شامل لایه‌های به ارث رسیده از ایمیج پایه) در یک لایه جدید منفرد. .SS \fB--ssh\fP=\fIdefault\fP | \fIid[=socket>\fP سوکت عامل 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 .SS \fB--stage-labels\fP افزودن برچسب‌های متادیتا به تمامی تصاویر مراحل میانی در ساخت چندمرحله‌ای، از جمله تصویر نهایی (پیش‌فرض \fBfalse\fR است). این گزینه نیازمند فعال بودن \fB--save-stages\fR است. .PP در صورت فعال بودن، تمام تصاویر مراحل میانی و تصویر نهایی با موارد زیر برچسب‌گذاری می‌شوند: - \fBio.podman.stage.name\fR: نام مستعار مرحله (از \fBFROM ... AS alias\fR)، یا موقعیت مرحله در صورت عدم تعیین نام مستعار - \fBio.podman.stage.base\fR: تصویر پایه استفاده‌شده توسط این مرحله (pullspec یا شناسه تصویر در صورتی که مرحله از مرحله دیگری به عنوان پایه استفاده کند) .PP این برچسب‌ها شناسایی، جستجو و مدیریت تصاویر حاصل از ساخت‌های چندمرحله‌ای را آسان‌تر می‌کنند. .SS \fB--tag\fP, \fB-t\fP=\fIimageName\fP نامی را مشخص می‌کند که در صورت تکمیل موفقیت‌آمیز فرایند ساخت، به تصویر حاصل اختصاص داده خواهد شد. اگر \fIimageName\fP شامل بخش نام رجیستری نباشد، نام رجیستری \fIlocalhost\fP به ابتدای نام تصویر افزوده خواهد شد. .PP گزینه \fB--tag\fP از تمامی پروتکل‌های انتقال موجود در \fBcontainers-transports(5)\fR پشتیبانی می‌کند\&. در صورت عدم تعیین پروتکل انتقال، پروتکل \fBcontainers-storage\fR (یعنی فضای ذخیره‌سازی محلی) استفاده می‌شود. .PP \fBpodman build --tag=oci-archive:./foo.ociarchive .\fP .PP \fBpodman build -t quay.io/username/foo .\fP .SS \fB--target\fP=\fIstageName\fP مرحله ساخت هدف (تارگت) را برای ساخت مشخص می‌کند. هنگام ساخت یک Containerfile با چندین مرحله ساخت، می‌توان از --target برای مشخص کردن یک مرحله ساخت میانی با نام آن به عنوان مرحله نهایی برای تصویر حاصل استفاده کرد. دستورات پس از مرحله هدف نادیده گرفته خواهند شد. .SS \fB--timestamp\fP=\fIseconds\fP برچسب زمانی «ایجاد شده» (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 که به‌صورت پیش‌فرض بر برچسب‌های زمانی محتویات لایه‌ها تأثیری ندارد، تداخل دارد. .SS \fB--tls-verify\fP الزام استفاده از HTTPS و اعتبارسنجی گواهی‌ها هنگام ارتباط با رجیستری‌های کانتینر (پیش‌فرض true است) و بازیابی محتوا از مکان‌های HTTPS برای دستورالعمل‌های ADD. اعتبارسنجی TLS هنگام ارتباط با یک رجیستری ناامن قابل استفاده نیست. .SS \fB--ulimit\fP=\fItype=soft-limit[:hard-limit]\fP محدودیت‌های منابع را برای اعمال بر روی فرایندهای راه‌اندازی‌شده هنگام پردازش دستورالعمل‌های \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) .SS \fB--unsetannotation\fP=\fIannotation\fP حذف حاشیه‌نویسی (annotation) تصویر، که مانع از به ارث رسیدن حاشیه‌نویسی از تصویر پایه می‌شود. .SS \fB--unsetenv\fP=\fIenv\fP حذف متغیرهای محیطی از تصویر نهایی. .SS \fB--unsetlabel\fP=\fIlabel\fP حذف برچسب (label) تصویر، که مانع از به ارث رسیدن برچسب از تصویر پایه می‌شود. .SS \fB--userns\fP=\fIhow\fP پیکربندی فضاهای نام کاربری (user namespaces) را هنگام پردازش دستورالعمل‌های \fBRUN\fR تنظیم می‌کند. مقدار پیکربندی‌شده می‌تواند "" (رشته خالی)، "private" یا "auto" باشد تا نشان دهد که باید یک فضای نام کاربری جدید ایجاد شود، می‌تواند "host" باشد تا نشان دهد فضای نام کاربری که در آن خود \fBpodman\fR در حال اجراست باید مجدداً استفاده شود، یا می‌تواند مسیر یک فضای نام کاربری باشد که هم‌اکنون توسط فرایند دیگری در حال استفاده است. .PP auto: ایجاد خودکار یک فضای نام کاربری یکتا. .PP فلگ --userns=auto مستلزم این است که نام کاربری containers و محدوده‌ای از شناسه‌های کاربری فرعی (subordinate user IDs) که کانتینر ساخت مجاز به استفاده از آن‌ها است در فایل‌های /etc/subuid و /etc/subgid مشخص شده باشند. .PP مثال: \fBcontainers:2147483647:2147483648\fR\&. .PP برنامه Podman محدوده‌های یکتایی از 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 .SS \fB--userns-gid-map\fP=\fImapping\fP به‌طور مستقیم یک نگاشت 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 ارائه شده باشد، تنظیمات گزینه سراسری استفاده خواهد شد. .SS \fB--userns-gid-map-group\fP=\fIgroup\fP مشخص می‌کند نگاشت GID که باید برای تعیین مالکیت در سطح سیستم فایل بر روی محتویات کانتینر در حال کار استفاده شود، می‌تواند در مدخل‌های مربوط به گروه مشخص‌شده در فایل \fB/etc/subgid\fR یافت شود. دستوراتی که هنگام پردازش دستورالعمل‌های \fBRUN\fR اجرا می‌شوند، به‌طور پیش‌فرض در فضاهای نام کاربری اختصاصی خود که با استفاده از نگاشت‌های UID و GID پیکربندی شده‌اند اجرا خواهند شد. اگر --userns-uid-map-user مشخص شده باشد، اما --userns-gid-map-group مشخص نشده باشد، \fBpodman\fR فرض خواهد کرد که نام کاربر مشخص‌شده یک نام گروه مناسب برای استفاده به‌عنوان تنظیم پیش‌فرض این گزینه نیز هست. .PP کاربران می‌توانند نگاشت‌ها را مستقیماً با استفاده از \fB--userns-gid-map\fR که در صفحه راهنمای podman(1) توضیح داده شده است مشخص کنند. .PP \fBنکته:\fP هنگامی که این گزینه توسط یک کاربر بدون ریشه (rootless) مشخص شود، نگاشت‌های تعیین‌شده نسبت به فضای نام کاربری بدون ریشه در کانتینر سنجیده می‌شوند، نه نسبت به میزبان آن‌گونه که در اجرای با ریشه (rootful) رخ می‌دهد. .SS \fB--userns-uid-map\fP=\fImapping\fP به‌طور مستقیم یک نگاشت UID را مشخص می‌کند که باید برای تعیین مالکیت در سطح سیستم فایل، بر روی محتویات کانتینر در حال کار استفاده شود. دستوراتی که هنگام پردازش دستورالعمل‌های \fBRUN\fR اجرا می‌شوند، به‌طور پیش‌فرض در فضاهای نام کاربری اختصاصی خود که با استفاده از نگاشت‌های UID و GID پیکربندی شده‌اند اجرا خواهند شد. .PP مدخل‌ها در این نگاشت به‌صورت یک یا چند سه‌تایی جداشده با دونقطه هستند که شامل UID آغازین درون کانتینر، UID آغازین متناظر در سطح میزبان، و تعداد شناسه‌های متوالی است که این مدخل نگاشت نشان می‌دهد. .PP این گزینه تنظیم \fIremap-uids\fP را در بخش \fIoptions\fP از /etc/containers/storage.conf بازنویسی می‌کند. .PP اگر این گزینه مشخص نشده باشد، اما یک تنظیم سراسری --userns-uid-map ارائه شده باشد، تنظیمات گزینه سراسری استفاده خواهد شد. .SS \fB--userns-uid-map-user\fP=\fIuser\fP مشخص می‌کند نگاشت UID که باید برای تعیین مالکیت در سطح سیستم فایل بر روی محتویات کانتینر در حال کار استفاده شود، می‌تواند در مدخل‌های مربوط به کاربر مشخص‌شده در فایل \fB/etc/subuid\fR یافت شود. دستوراتی که هنگام پردازش دستورالعمل‌های \fBRUN\fR اجرا می‌شوند، به‌طور پیش‌فرض در فضاهای نام کاربری اختصاصی خود که با استفاده از نگاشت‌های UID و GID پیکربندی شده‌اند اجرا خواهند شد. اگر --userns-gid-map-group مشخص شده باشد، اما --userns-uid-map-user مشخص نشده باشد، \fBpodman\fR فرض خواهد کرد که نام گروه مشخص‌شده یک نام کاربری مناسب برای استفاده به‌عنوان تنظیم پیش‌فرض این گزینه نیز هست. .PP \fBنکته:\fP هنگامی که این گزینه توسط یک کاربر بدون ریشه (rootless) مشخص شود، نگاشت‌های تعیین‌شده نسبت به فضای نام کاربری بدون ریشه در کانتینر سنجیده می‌شوند، نه نسبت به میزبان آن‌گونه که در اجرای با ریشه (rootful) رخ می‌دهد. .SS \fB--uts\fP=\fIhow\fP پیکربندی فضاهای نام UTS را هنگام پردازش دستورالعمل‌های \fBRUN\fR تنظیم می‌کند. مقدار پیکربندی‌شده می‌تواند "" (رشته خالی) یا "container" باشد تا نشان دهد یک فضای نام UTS جدید باید ایجاد شود، یا می‌تواند "host" باشد تا نشان دهد فضای نام UTS که خود \fBpodman\fR در آن در حال اجراست باید بازاستفاده شود، یا می‌تواند مسیری به یک فضای نام UTS باشد که پیش‌تر توسط فرایند دیگری در حال استفاده است. .SS \fB--volume\fP, \fB-v\fP=\fI[HOST-DIR:CONTAINER-DIR[:OPTIONS]]\fP یک دایرکتوری میزبان را هنگام اجرای دستورالعمل‌های \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 نیز باید یک مسیر مطلق باشد. Podman مسیر \fBHOST-DIR\fR را به مسیری که مشخص می‌کنید bind-mount می‌کند. برای نمونه، اگر \fB/foo\fR را به‌عنوان مسیر میزبان بدهید، Podman محتویات \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 به‌طور پیش‌فرض، Podman مالک و گروه دایرکتوری‌های حجم مبدأ متصل‌شده به کانتینرها را تغییر نمی‌دهد. اگر کانتینری در یک فضای نام کاربری (user namespace) جدید ایجاد شود، UID و GID درون کانتینر ممکن است با UID و GID متفاوتی روی میزبان متناظر باشند. .PP پسوند \fB:U\fR به Podman می‌گوید تا بر اساس UID و GID درون کانتینر، از UID و GID درست میزبان برای تغییر دادن مالک و گروه حجم مبدأ استفاده کند. .PP \fBبرچسب‌گذاری اتصال‌های حجم (Labeling Volume Mounts)\fR .PP سیستم‌های برچسب‌گذاری مانند SELinux نیازمند قرارگیری برچسب‌های مناسب روی محتوای حجم متصل‌شده به کانتینر هستند. بدون برچسب، سیستم امنیتی ممکن است از استفاده فرایندهای در حال اجرا درون کانتینر از محتوا جلوگیری کند. به‌طور پیش‌فرض، Podman برچسب‌های تنظیم‌شده توسط سیستم‌عامل را تغییر نمی‌دهد. .PP برای تغییر یک برچسب در بافت کانتینر، می‌توانید یکی از دو پسوند \fB:z\fR یا \fB:Z\fR را به اتصال حجم اضافه کنید. این پسوندها به Podman می‌گویند که اشیاء فایل روی حجم‌های اشتراکی را دوباره برچسب‌گذاری کند. گزینه \fBz\fR به Podman می‌گوید که دو کانتینر محتوای حجم را به اشتراک می‌گذارند. در نتیجه، Podman محتوا را با یک برچسب محتوای مشترک برچسب‌گذاری می‌کند. برچسب‌های حجم مشترک به همه کانتینرها اجازه خواندن/نوشتن محتوا را می‌دهند. گزینه \fBZ\fR به Podman می‌گوید که محتوا را با یک برچسب اختصاصی غیرمشترک برچسب‌گذاری کند. تنها کانتینر فعلی می‌تواند از یک حجم اختصاصی استفاده کند. .PP \fBاتصال‌های حجم اورلی (Overlay Volume Mounts)\fR .PP فلگ \fB:O\fR به Podman می‌گوید که دایرکتوری را از میزبان با استفاده از سیستم فایل 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 \fR برای تعیین نقطه اتصال مبدأ و سپس از \fBfindmnt -o TARGET,PROPAGATION \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)" دستورالعمل 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)" .SH "همچنین ببینید (SEE ALSO)" \fBpodman(1)\fP, \fBpodman-farm(1)\fP, \fBpodman-build(1)\fP .SH "تاریخچه (HISTORY)" ژوئیه ۲۰۲۳، توسط Brent Baude ایجاد شد.