نام (NAME)

containers.conf - فایل پیکربندی موتور کانتینر گزینه‌های پیکربندی پیش‌فرض و فلگ‌های خط فرمان را برای موتورهای کانتینر مشخص می‌کند.

توضیحات (DESCRIPTION)

موتورهای کانتینر مانند Podman و Buildah در صورت وجود فایل containers.conf آن را خوانده و مقادیر پیش‌فرض برای اجرای کانتینرها را روی میزبان تغییر می‌دهند. فایل containers.conf از قالب TOML استفاده می‌کند که ویرایش و نسخه‌بندی آن آسان است.

به‌طور پیش‌فرض، در صورت وجود، پیکربندی از $XDG_CONFIG_HOME/containers/containers.conf (یا در صورت تنظیم نبودن $XDG_CONFIG_HOME از $HOME/.config/containers/containers.conf) خوانده می‌شود؛ در غیر این صورت از /etc/containers/containers.conf؛ و در غیر این صورت از /usr/share/containers/containers.conf.

علاوه بر containers.conf، فایل‌های الحاقی (drop-in) با همان قالب از دایرکتوری‌های زیر نیز خوانده می‌شوند:
- $XDG_CONFIG_HOME/containers/containers.conf.d (یا در صورت عدم تنظیم $XDG_CONFIG_HOME از $HOME/.config/containers/containers.conf.d)
- /etc/containers/containers.rootful.conf.d (فقط هنگام اجرا با uid 0)
- /etc/containers/containers.rootless.conf.d/$UID (فقط هنگام اجرا با uid > 0)
- /etc/containers/containers.rootless.conf.d (فقط هنگام اجرا با uid > 0)
- /etc/containers/containers.conf.d
- /usr/share/containers/containers.rootful.conf.d (فقط هنگام اجرا با uid 0)
- /usr/share/containers/containers.rootless.conf.d/$UID (فقط هنگام اجرا با uid > 0)
- /usr/share/containers/containers.rootless.conf.d (فقط هنگام اجرا با uid > 0)
- /usr/share/containers/containers.conf.d

فایل‌ها باید دارای پسوند .conf باشند؛ دایرکتوری‌ها یا فایل‌هایی با پسوندهای دیگر نادیده گرفته می‌شوند. تمام فایل‌های این مسیرها ابتدا جمع‌آوری شده و سپس بر اساس ترتیب الفبایی-عددی مرتب می‌شوند. اگر نام فایلی دو بار تکرار شود، تنها اولین تطابق از فهرست دایرکتوری‌های بالا استفاده می‌شود. سپس فایل‌ها به ترتیب مرتب‌شده تجزیه و پردازش می‌شوند.

فیلدهای مشخص‌شده در containers.conf، گزینه‌های پیش‌فرض و همچنین گزینه‌های موجود در فایل‌های containers.conf قبلاً خوانده‌شده را بازنویسی (override) می‌کنند.

برای توضیحات دقیق‌تر در مورد نحوه بارگذاری فایل‌ها به containers-config(5) مراجعه کنید.

همه گزینه‌ها در تمام موتورهای کانتینر پشتیبانی نمی‌شوند.

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

storage.conf برای پیکربندی فضای ذخیره‌سازی کانتینر و ایمیج‌ها.
registries.conf برای تعریف رجیستری‌های کانتینر جهت جستجو هنگام دریافت (pull) ایمیج‌های کانتینر.
policy.conf برای کنترل اینکه چه ایمیج‌هایی می‌توانند روی سیستم دریافت شوند.

نکته: اگر Podman در یک ماشین مجازی با استفاده از podman machine اجرا می‌شود (شامل میزبان‌های Mac و Windows)، مطمئن شوید که فایل‌های پیکربندی در داخل ماشین مجازی با استفاده از podman machine ssh ویرایش شوند.

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

اگر متغیر محیطی CONTAINERS_CONF تنظیم شده باشد، تمام فایل‌های پیکربندی سیستمی و کاربری نادیده گرفته شده و تنها فایل پیکربندی مشخص‌شده بارگذاری خواهد شد.

اگر متغیر محیطی مسیر CONTAINERS_CONF_OVERRIDE تنظیم شده باشد، فایل پیکربندی در آخرین مرحله بارگذاری می‌شود، حتی اگر CONTAINERS_CONF تنظیم شده باشد.

مقادیر هر دو متغیر محیطی می‌توانند مسیرهای مطلق یا نسبی باشند؛ برای مثال: CONTAINERS_CONF=/tmp/my_containers.conf.

ماژول‌ها (MODULES)

یک ماژول، فایل containers.conf ای است که مستقیماً درون یکی از سه دایرکتوری زیر یا زیرشاخه‌های آنها قرار دارد:
- \$XDG_CONFIG_HOME/containers/containers.conf.modules یا \$HOME/.config/containers/containers.conf.modules در صورت عدم تنظیم $XDG_CONFIG_HOME
- /etc/containers/containers.conf.modules
- /usr/share/containers/containers.conf.modules

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

در حال حاضر ماژول‌ها توسط podman(1) پشتیبانی می‌شوند. فلگ podman --module امکان بارگذاری یک ماژول را فراهم کرده و می‌تواند چندین بار مشخص شود. اگر مقدار مشخص‌شده یک مسیر مطلق باشد، فایل پیکربندی مستقیماً بارگذاری می‌شود. مسیرهای نسبی با توجه به سه دایرکتوری ماژول ذکر شده در بالا و به ترتیب مشخص‌شده بررسی و حل می‌شوند، به طوری که ماژول‌های موجود در $XDG_CONFIG_HOME/$HOME امکان بازنویسی ماژول‌های موجود در /etc و /usr/share را خواهند داشت.

افزودن به آرایه‌های رشته‌ای (APPENDING TO STRING ARRAYS)

رفتار پیش‌فرض در طول دنباله بارگذاری چندین فایل containers.conf، بازنویسی داده‌های قبلی است. برای تغییر این رفتار از بازنویسی به پیوست کردن (افزودن)، می‌توانید صفت append را به این صورت تنظیم کنید: array=["item-1", "item=2", ..., {append=true}]. تنظیم ویژگی append مشخص می‌کند که در این مرحله و مراحل بعدی بارگذاری، مقادیر به این آرایه رشته‌ای اضافه شوند. برای بازگشت به حالت بازنویسی، {append=false} را تنظیم کنید.

مثال زیر را در نظر بگیرید:

modules1.conf: env=["1=true"]
modules2.conf: env=["2=true"]
modules3.conf: env=["3=true", {append=true}]
modules4.conf: env=["4=true"]

پس از بارگذاری فایل‌ها به ترتیب مشخص‌شده، محتوای نهایی env=["2=true", "3=true", "4=true"] خواهد بود. اگر modules4.conf مقدار {append=false} را تنظیم می‌کرد، محتوای نهایی env=["4=true"] می‌شد.

قالب (FORMAT)

قالب TOML ⟨https://github.com/toml-lang/toml⟩ به عنوان قالب کدگذاری فایل پیکربندی استفاده می‌شود. هر گزینه درون جدول مربوط به خود قرار دارد و هیچ گزینه مستقلی خارج از جداول استفاده نمی‌شود. قالب TOML را می‌توان به شکل زیر خلاصه کرد:

[table1]
option = value
[table2]
option = value
[table3]
option = value
[table3.subtable1]
option = value

جدول CONTAINERS (CONTAINERS TABLE)

جدول containers شامل تنظیماتی برای پیکربندی و مدیریت زمان اجرای OCI (OCI runtime) است.

annotations = []

فهرست حاشیه‌نویسی‌ها (annotations). به عنوان جفت‌های "key=value" مشخص می‌شود تا به تمام کانتینرها اضافه شوند.

مثال: "run.oci.keep_original_groups=1"

apparmor_profile="container-default"

برای تغییر نام نمایه پیش‌فرض AppArmor موتورهای کانتینر استفاده می‌شود. نام نمایه پیش‌فرض "container-default" است.

base_hosts_file=""

فایل پایه برای ساخت فایل /etc/hosts درون کانتینر. این مقدار باید یک مسیر مطلق به فایلی در سیستم میزبان باشد، یا یکی از فلگ‌های ویژه زیر:
"" استفاده از فایل /etc/hosts میزبان (پیش‌فرض)
none عدم استفاده از فایل پایه (یعنی شروع با یک فایل خالی)
image استفاده از فایل /etc/hosts ایمیج کانتینر به عنوان فایل پایه

cgroup_conf=[]

فهرستی از ورودی‌های cgroup_conf که فهرستی از فایل‌های cgroup برای نوشتن و مقادیر آنها را مشخص می‌کند. برای مثال memory.high=1073741824 حد memory.high را روی 1GB تنظیم می‌کند.

cgroups="enabled"

تعیین می‌کند که آیا کانتینر CGroupها را ایجاد خواهد کرد یا خیر. گزینه‌ها عبارتند از:
enabled فعال‌سازی پشتیبانی از cgroup در داخل کانتینر
disabled غیرفعال کردن پشتیبانی از cgroup؛ cgroupها از والد به ارث برده می‌شوند
no-conmon عدم ایجاد یک cgroup اختصاصی برای conmon.

cgroupns="private"

روش پیش‌فرض برای ایجاد فضای نام cgroup برای کانتینر. گزینه‌ها عبارتند از: private ایجاد فضای نام Cgroup خصوصی برای کانتینر. host به اشتراک‌گذاری فضای نام Cgroup میزبان با کانتینر.

container_name_as_hostname=true|false

وقتی هیچ نام میزبانی (hostname) برای کانتینر تنظیم نشده باشد، از نام کانتینر (با حذف نویسه‌های نامعتبر برای hostname) به عنوان hostname به جای ۱۲ نویسه اول شناسه کانتینر استفاده می‌شود. کانتینرهایی که در فضای نام خصوصی UTS اجرا نمی‌شوند، بدون در نظر گرفتن این تنظیم، hostname آنها برابر با hostname میزبان قرار خواهد گرفت.

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

default_capabilities=[]

فهرست قابلیت‌های (capabilities) پیش‌فرض برای کانتینرها.

فهرست پیش‌فرض عبارت است از:

default_capabilities = [
      "CHOWN",
      "DAC_OVERRIDE",
      "FOWNER",
      "FSETID",
      "KILL",
      "NET_BIND_SERVICE",
      "SETFCAP",
      "SETGID",
      "SETPCAP",
      "SETUID",
      "SYS_CHROOT",
]

توجه داشته باشید که به‌طور پیش‌فرض موتورهای کانتینری که از containers.conf استفاده می‌کنند، با قابلیت‌های کمتری نسبت به Docker اجرا می‌شوند. داکر علاوه بر این موارد با "AUDIT_WRITE"، "MKNOD" و "NET_RAW" نیز اجرا می‌شود. در صورت نیاز به افزودن هر یک از این قابلیت‌ها برای کانتینری خاص، می‌توانید از گزینه --cap-add استفاده کنید یا فایل containers.conf سیستم خود را ویرایش نمایید.

default_sysctls=[]

فهرستی از sysctlهایی که باید به‌طور پیش‌فرض در کانتینرها تنظیم شوند، مشخص‌شده به صورت "name=value".

مثال: "net.ipv4.ping_group_range=0 1000".

default_ulimits=[]

فهرستی از ulimitهایی که باید به‌طور پیش‌فرض در کانتینرها تنظیم شوند، مشخص‌شده به صورت "name=soft-limit:hard-limit".

مثال: "nofile=1024:2048".

devices=[]

فهرست دستگاه‌ها. مشخص‌شده به صورت 'device-on-host:device-on-container:permissions'.

مثال: "/dev/sdc:/dev/xvdc:rwm".

dns_options=[]

فهرست گزینه‌های پیش‌فرض DNS برای افزودن به /etc/resolv.conf درون کانتینر.

dns_searches=[]

فهرست دامنه‌های جستجوی پیش‌فرض DNS برای افزودن به /etc/resolv.conf درون کانتینر.

dns_servers=[]

فهرستی از سرورهای dns برای بازنویسی پیکربندی DNS ارسال‌شده به کانتینر. مقدار ویژه «none» می‌تواند برای غیرفعال کردن ایجاد /etc/resolv.conf در کانتینر مشخص شود.

env=["PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"]

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

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

env_host=false

ارسال تمام متغیرهای محیطی میزبان به داخل کانتینر.

host_containers_internal_ip=""

تنظیم آدرس IP که کانتینر باید برای اتصال به میزبان انتظار داشته باشد. این آدرس IP توسط Podman برای افزودن خودکار نام‌های میزبان host.containers.internal و host.docker.internal به فایل /etc/hosts کانتینر استفاده می‌شود. همچنین برای فلگ host-gateway گزینه خط فرمان --add-host در Podman استفاده می‌شود. اگر هیچ آدرس IP پیکربندی نشده باشد (پیش‌فرض)، Podman تلاش می‌کند آن را به‌طور خودکار تعیین کند، اما بسته به پیکربندی شبکه کانتینر ممکن است ناموفق باشد. در این صورت، افزودن این نام‌های میزبان داخلی به /etc/hosts بدون هشدار نادیده گرفته می‌شود. این پیکربندی را روی none تنظیم کنید تا هرگز نام‌های میزبان داخلی به /etc/hosts اضافه نشوند.

نکته: اگر Podman در یک ماشین مجازی با استفاده از podman machine اجرا می‌شود (شامل میزبان‌های Mac و Windows)، هنگامی که این مقدار خالی باشد Podman نام میزبان host.containers.internal را از طریق حل‌کننده DNS ماشین پودمن (gvproxy) حل می‌کند. همچنین از آنجا که نام توسط نام DNS در gvproxy حل می‌شود، تنظیم این مقدار روی none تأثیری نخواهد داشت. این گزینه رفتار gvproxy را تغییر نمی‌دهد.

نکته: این پیکربندی بر تنظیمات واقعی شبکه تأثیری ندارد، بلکه فقط آدرس IP مورد انتظار را به Podman اطلاع می‌دهد. پیکربندی یک آدرس IP در اینجا تضمین نمی‌کند که کانتینر واقعاً بتواند با استفاده از این IP به میزبان دسترسی پیدا کند.

http_proxy=true

متغیرهای محیطی پیش‌فرض پروکسی به کانتینر ارسال خواهند شد. متغیرهای محیطی ارسالی عبارتند از: http_proxy, https_proxy, ftp_proxy, no_proxy و نسخه‌های با حروف بزرگ آنها. گزینه no_proxy زمانی نیاز است که سیستم میزبان از پروکسی استفاده می‌کند اما کانتینر نباید از آن استفاده کند. متغیرهای محیطی پروکسی مشخص‌شده برای کانتینر از هر طریق دیگر، مقادیر ارسالی از میزبان را بازنویسی خواهند کرد.

init=false

اجرای یک فرآیند init درون کانتینر که سیگنال‌ها را هدایت کرده و فرآیندهای مرده (zombie/reaped) را جمع‌آوری می‌کند.

init_path="/usr/libexec/podman/catatonit"

اگر این گزینه تنظیم نشود، catatonit در دایرکتوری‌های فهرست‌شده تحت گزینه helper_binaries_dir جستجو می‌شود. توصیه می‌شود به جای پیکربندی این گزینه در اینجا، catatonit را در همان مسیرها نصب کنید.

مسیر باینری container-init که سیگنال‌ها را فوروارد کرده و فرآیندها را درون کانتینرها جمع‌آوری می‌کند. توجه داشته باشید که باینری container-init تنها زمانی استفاده خواهد شد که گزینه --init برای podman-create و podman-run تنظیم شده باشد.

interface_name=""

روش پیش‌فرض برای تعیین نام‌های رابط شبکه درون کانتینرها. در صورت عدم تعریف، به‌طور پیش‌فرض از الگوی سنتی ethX (که در آن X یک عدد صحیح است) استفاده می‌شود. گزینه‌ها عبارتند از:
device از نام network_interface موجود در پیکربندی شبکه به عنوان نام رابط استفاده می‌کند. اگر network_interface تنظیم نشده باشد، به الگوی ethX بازمی‌گردد.

ipcns="shareable"

روش پیش‌فرض برای ایجاد فضای نام IPC برای کانتینر. گزینه‌ها عبارتند از:
host به اشتراک‌گذاری فضای نام IPC میزبان با کانتینر.
none ایجاد فضای نام IPC قابل اشتراک‌گذاری برای کانتینر بدون /dev/shm خصوصی.
private ایجاد فضای نام IPC خصوصی برای کانتینر؛ کانتینرهای دیگر مجاز به اشتراک‌گذاری آن نیستند.
shareable ایجاد فضای نام IPC قابل اشتراک‌گذاری برای کانتینر.

keyring=true

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

label=true

مشخص می‌کند که آیا موتور کانتینر از جداسازی کانتینر MAC(SELinux) از طریق برچسب‌گذاری استفاده می‌کند یا خیر. این گزینه در سیستم‌های غیرفعال نادیده گرفته می‌شود.

label_users=false

گزینه label_users مشخص می‌کند که آیا کاربران محدودشده در کانتینرها روی سیستم‌های SELinux اعمال شوند یا خیر. این گزینه باعث می‌شود کانتینرها فیلد کاربر و نقش فعلی فرآیند فراخواننده را حفظ کنند. به‌طور پیش‌فرض کانتینرهای SELinux با کاربر system_u و نقش system_r اجرا می‌شوند.

log_driver=""

درایور ثبت لاگ برای کانتینر. گزینه‌های موجود در حال حاضر عبارتند از k8s-file, journald, none و passthrough، که json-file به عنوان نام مستعار k8s-file برای سازگاری با اسکریپت‌ها عمل می‌کند. اگر journal سیستم‌دی قابل خواندن و نوشتن باشد، درایور journald به‌طور پیش‌فرض استفاده می‌شود؛ در غیر این صورت، از درایور k8s-file استفاده می‌شود.

log_path=""

مسیر پیش‌فرض برای ذخیره لاگ‌های کانتینر. در صورت خالی بودن، لاگ‌ها در فضای ذخیره‌سازی پیش‌فرض کانتینر ذخیره شده و با حذف کانتینر حذف می‌شوند. یک زیردایرکتوری با نام شناسه کانتینر تحت مسیر مشخص‌شده ایجاد خواهد شد و فایل لاگ دارای نام پیش‌فرض ctr.log درون آن دایرکتوری خواهد بود. این گزینه را می‌توان با فلگ --log-opt بازنویسی کرد.

log_size_max=-1

حداکثر حجم مجاز برای فایل لاگ کانتینر. اعداد منفی نشان می‌دهند که هیچ محدودیت حجمی اعمال نمی‌شود. اگر مقدار مثبت باشد، باید >= 8192 باشد تا با بافر خواندن conmon مطابقت داشته باشد یا از آن فراتر رود. فایل کوتاه (truncate) شده و مجدداً باز می‌شود تا از حد مجاز فراتر نرود.

log_tag=""

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

mounts=[]

فهرست mountها. مشخص‌شده به صورت "type=TYPE,source=,destination=,"

مثال: [ "type=bind,source=/var/lib/foobar,destination=/var/lib/foobar,ro", ]

netns=""

روش پیش‌فرض برای ایجاد فضای نام NET برای کانتینر. این گزینه به آرگومان --network دستورات podman نگاشت می‌شود و مقادیر یکسانی با آن می‌پذیرد. برای مثال می‌تواند روی bridge, host, none, pasta و موارد دیگر تنظیم شود؛ راهنمای podman-create(1) ⟨https://docs.podman.io/en/latest/markdown/podman-create.1.html#network-mode-net⟩ را برای تمام گزینه‌های موجود ببینید.

no_hosts=false

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

oom_score_adj=0

تنظیم اولویت‌های OOM میزبان برای کانتینرها (مقادیر از -1000 تا 1000 را می‌پذیرد).

pidns="private"

روش پیش‌فرض ایجاد فضای نام PID برای کانتینر. گزینه‌ها عبارتند از:
private ایجاد فضای نام PID خصوصی برای کانتینر.
host به اشتراک‌گذاری فضای نام PID میزبان با کانتینر.

pids_limit=1024

حداکثر تعداد فرآیندهای مجاز در یک کانتینر. مقدار 0 نشان‌دهنده عدم اعمال محدودیت است.

prepare_volume_on_create=false

کپی کردن محتوا از ایمیج پایه درون حجم (volume) تازه‌ایجادشده هنگام ساخت کانتینر به جای زمان شروع آن. اگر false باشد، موتور کانتینر تا زمان شروع کانتینر محتوا را کپی نخواهد کرد. تنظیم آن روی true ممکن است اثرات منفی بر کارایی داشته باشد.

privileged=false

اعطای امتیازات گسترده به همه کانتینرها. یک کانتینر با امتیاز ویژه (privileged) ویژگی‌های امنیتی که کانتینر را از میزبان جدا می‌کند، غیرفعال می‌سازد. قابلیت‌های حذف‌شده، دستگاه‌های محدود شده، نقاط اتصال فقط‌خواندنی، جداسازی Apparmor/SELinux و فیلترهای Seccomp همگی غیرفعال می‌شوند. با توجه به ویژگی‌های امنیتی غیرفعال‌شده، فیلد privileged تقریباً هرگز نباید تنظیم شود زیرا کانتینرها می‌توانند به راحتی از محیط ایزوله خارج شوند.

کانتینرهایی که در یک فضای نام کاربری اجرا می‌شوند (مانند کانتینرهای بدون ریشه / rootless) نمی‌توانند امتیازاتی بیشتر از کاربری که آنها را اجرا کرده است داشته باشند.

read_only=true|false

اجرای تمام کانتینرها با سیستم‌فایل ریشه متصل‌شده به صورت فقط‌خواندنی. به‌طور پیش‌فرض روی false تنظیم شده است.

seccomp_profile="/usr/share/containers/seccomp.json"

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

shm_size="65536k"

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

tz=""

تنظیم منطقه زمانی درون کانتینر. مناطق زمانی IANA و همچنین local را می‌پذیرد، که منطقه زمانی درون کانتینر را با ماشین میزبان مطابقت می‌دهد. در صورت عدم تنظیم، کانتینرها با منطقه زمانی مشخص‌شده در ایمیج اجرا می‌شوند.

مثال‌ها:
tz="local"
tz="America/New_York"

umask="0022"

تنظیم umask درون کانتینر.

userns="host"

روش پیش‌فرض برای ایجاد فضای نام USER برای کانتینر. گزینه‌ها عبارتند از:
private ایجاد فضای نام USER خصوصی برای کانتینر بدون افزودن هیچ‌گونه نگاشت UID.
host به اشتراک‌گذاری فضای نام USER میزبان با کانتینر. ریشه در کانتینر به UID کاربر میزبان نگاشت می‌شود.
auto ایجاد خودکار یک فضای نام USER با نگاشت یکتا.
keep-id مانند private، اما UIDهای کانتینر به UIDهای فرعی (subordinate) کاربر میزبان فهرست‌شده در /etc/subuid نگاشت می‌شوند، و UID:GID کاربر فعلی به همان مقادیر درون کانتینر نگاشت می‌گردد.
no-map مانند keep-id، اما UID:GID کاربر فعلی به هیچ UID:GID درون کانتینر نگاشت نمی‌شود.

utsns="private"

روش پیش‌فرض برای ایجاد فضای نام UTS برای کانتینر. گزینه‌ها عبارتند از:
private ایجاد فضای نام UTS خصوصی برای کانتینر.
host به اشتراک‌گذاری فضای نام UTS میزبان با کانتینر.

volumes=[]

فهرست حجم‌ها (volumes). مشخص‌شده به صورت "directory-on-host:directory-in-container:options".

مثال: "/db:/var/lib/db:ro".

جدول NETWORK (NETWORK TABLE)

جدول network شامل تنظیمات مربوط به مدیریت شبکه‌های کانتینر است.

network_backend=""

بک‌اند شبکه تعیین می‌کند کدام درایور شبکه برای راه‌اندازی و برچیدن شبکه‌های کانتینر استفاده خواهد شد. تنها مقدار پشتیبانی‌شده "netavark" است. رشته خالی به‌طور پیش‌فرض "netavark" در نظر گرفته می‌شود.

netavark_plugin_dirs=[]

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

فهرست پیش‌فرض عبارت است از:

netavark_plugin_dirs = [
  "/usr/local/libexec/netavark",
  "/usr/libexec/netavark",
  "/usr/local/lib/netavark",
  "/usr/lib/netavark",
]

default_network="podman"

نام شبکه پیش‌فرض همان‌طور که در خروجی podman network ls دیده می‌شود. این گزینه تنها بر تخصیص شبکه در زمانی که حالت شبکه bridge انتخاب شده باشد (یعنی --network bridge) تأثیر می‌گذارد. این حالت برای کانتینرهای با دسترسی ریشه (rootful) پیش‌فرض است اما برای کانتینرهای بدون ریشه (rootless) خیر. برای تغییر حالت پیش‌فرض شبکه، از گزینه netns در جدول [containers] استفاده کنید.

نکته: تا زمانی که کانتینرهایی در حال استفاده از این شبکه هستند، نباید این گزینه تغییر داده شود.

default_subnet="10.88.0.0/16"

زیرشبکه مورد استفاده برای شبکه پیش‌فرض (نام‌گذاری شده در بالا در default_network).

نکته: اگر هر کانتینری در حال حاضر روی شبکه پیش‌فرض در حال اجرا باشد، این مقدار نباید تغییر کند.

default_subnet_pools=[]

گزینه DefaultSubnetPools فهرستی از زیرشبکه‌ها و اندازه‌های آنهاست که برای تخصیص خودکار زیرشبکه‌ها در podman network create استفاده می‌شود. این فهرست پیمایش شده و اولین زیرشبکه خالی با اندازه مشخص‌شده انتخاب خواهد شد. این گزینه تنها برای زیرشبکه‌های ipv4 استفاده می‌شود؛ زیرشبکه‌های ipv6 همیشه به‌صورت تصادفی تخصیص داده می‌شوند.

فهرست پیش‌فرض (10.89.0.0-10.255.255.0/24) عبارت است از:

default_subnet_pools = [
  {"base" = "10.89.0.0/16", "size" = 24},
  {"base" = "10.90.0.0/15", "size" = 24},
  {"base" = "10.92.0.0/14", "size" = 24},
  {"base" = "10.96.0.0/11", "size" = 24},
  {"base" = "10.128.0.0/9", "size" = 24},
]

default_rootless_network_cmd="pasta"

تعیین برنامه شبکه بدون ریشه که به‌طور پیش‌فرض استفاده شود. تنها گزینه معتبر pasta است (پیش‌فرض).

rootless_port_forwarder="rootlessport"

انتخاب سازوکار فوروارد پورت برای شبکه‌های bridge بدون ریشه. گزینه‌های معتبر عبارتند از rootlessport (پیش‌فرض) و pasta. گزینه rootlessport از یک پروکسی TCP/UDP در فضای کاربر استفاده می‌کند. گزینه pasta از سوکت کنترلی pasta برای افزودن قوانین فوروارد پورت از طریق kernel splice استفاده می‌کند که آدرس IP مبدا اصلی را در داخل کانتینر حفظ می‌نماید. گزینه pasta آزمایشی (experimental) بوده و ممکن است دستخوش تغییر شود.

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

network_config_dir="/etc/containers/networks"

مسیر دایرکتوری محل قرارگیری فایل‌های پیکربندی شبکه. مقدار پیش‌فرض برای کاربر ریشه "/etc/containers/networks" و برای حالت بدون ریشه "$graphroot/networks" است.

firewall_driver=""

درایور فایروال مورد استفاده توسط netavark. پیش‌فرض خالی است که به این معنی است netavark یکی را بر اساس شرایط انتخاب خواهد کرد. درایورهای پشتیبانی‌شده فعلی عبارتند از "nftables"، "none" (هیچ قانون فایروالی ایجاد نخواهد شد) و "firewalld" (درایور firewalld در حال حاضر آزمایشی بوده و خارج از محیط تست توصیه نمی‌شود).

dns_bind_port=53

پورت مورد استفاده برای دیمن فورواردینگ dns با netavark در حالت bridge با دسترسی ریشه و فعال بودن dns. استفاده از یک پورت جایگزین ممکن است در صورتی که سایر سرویس‌های dns روی ماشین اجرا شوند مفید باشد.

pasta_options = []

فهرستی از گزینه‌های پیش‌فرض pasta که هنگام اجرای pasta باید استفاده شوند. این گزینه پارامترهای خط فرمان pasta را می‌پذیرد؛ برای فهرست کامل گزینه‌ها به pasta(1) مراجعه کنید.

default_host_ips=[]

IPهای پیش‌فرض میزبان برای متصل کردن (bind) پورت‌های منتشرشده کانتینر در صورتی که هیچ IP میزبانی صراحتاً در فلگ -p مشخص نشده باشد (مانند -p 8000:8000). اگر خالی باشد، رفتار پیش‌فرض اتصال به تمام رابط‌های شبکه است (0.0.0.0 برای IPv4 و :: برای IPv6). اگر چندین IP مشخص شده باشد، نگاشت پورت جداگانه‌ای برای هر یک از IPهای مشخص‌شده ایجاد می‌شود. برای مثال، تنظیم این مقدار روی ["127.0.0.1", "::1"] و پورت مشخص‌شده به صورت -p 8080:80 منجر به دو نگاشت پورت در podman خواهد شد: 127.0.0.1:8080:80 و [::1]:8080:80. توجه داشته باشید که تعیین صریح IP میزبان در فلگ -p (مانند -p 192.168.1.10:8000:8000) همیشه این پیش‌فرض را بازنویسی خواهد کرد.

جدول ENGINE (ENGINE TABLE)

جدول engine شامل گزینه‌های پیکربندی مورد استفاده برای راه‌اندازی موتورهای کانتینر مانند Podman و Buildah است.

active_service=""

نام مقصد برای دسترسی به سرویس Podman. جدول SERVICE DESTINATION TABLE را در زیر ببینید.

add_compression=[]

فهرست الگوریتم‌های فشرده‌سازی. در صورت تنظیم، تضمین می‌کند که نسخه فشرده‌سازی درخواستی برای هر پلتفرم به لیست مانیفست اضافه شود و نمونه اصلی دست‌نخورده در همان لیست مانیفست در هر بار اجرای manifest push باقی بماند. مقادیر پشتیبانی‌شده عبارتند از (gzip, zstd و zstd:chunked). گزینه zstd:chunked با رمزگذاری ایمیج‌ها ناسازگار است و در این حالت همراه با یک هشدار به عنوان zstd تلقی خواهد شد.

نکته: این مورد با compression_format متفاوت است که به کاربران اجازه می‌دهد یک قالب فشرده‌سازی پیش‌فرض برای push و manifest push انتخاب کنند، در حالی که add_compression محدود به manifest push است و به کاربران اجازه می‌دهد نمونه‌های جدیدی را با الگوریتم‌های فشرده‌سازی مشخص‌شده در add_compression برای هر پلتفرم به لیست مانیفست اضافه کنند.

cgroup_manager="systemd"

پیاده‌سازی مدیریت cgroup مورد استفاده برای زمان اجرا. از cgroupfs و systemd پشتیبانی می‌کند.

compat_api_enforce_docker_hub=true

اجبار به استفاده از docker.io برای تکمیل نام‌های کوتاه در REST API سازگاری Podman. توجه داشته باشید که این گزینه unqualified-search-registries و نام‌های مستعار short-name تعریف‌شده در containers-registries.conf(5) را نادیده می‌گیرد.

compose_providers=[]

تعیین یک یا چند ارائه‌دهنده خارجی برای دستور compose. اولین ارائه‌دهنده یافت‌شده برای اجرا استفاده می‌شود. می‌تواند یک مسیر مطلق و نسبی یا نام یک فایل باشد.

compose_warning_logs=true

ارسال لاگ در هر بار فراخوانی دستور compose مبنی بر اینکه یک ارائه‌دهنده compose خارجی در حال اجرا است.

conmon_env_vars=[]

متغیرهای محیطی برای ارسال به Conmon.

conmon_path=[]

مسیرهای جستجو برای باینری مدیر کانتینر conmon. اگر مسیرها خالی باشند یا مسیر معتبری یافت نشود، از متغیر محیطی $PATH به عنوان جایگزین استفاده خواهد شد.

فهرست پیش‌فرض عبارت است از:

conmon_path=[
    "/usr/libexec/podman/conmon",
    "/usr/local/libexec/podman/conmon",
    "/usr/local/lib/podman/conmon",
    "/usr/bin/conmon",
    "/usr/sbin/conmon",
    "/usr/local/bin/conmon",
    "/usr/local/sbin/conmon",
    "/run/current-system/sw/bin/conmon",
]

detach_keys="ctrl-p,ctrl-q"

توالی کلیدهای مورد استفاده برای جدا شدن (detach) از کانتینر. توالی کلیدها را مشخص کنید. قالب آن یک نویسه تکی [a-Z] یا یک دنباله جداشده با کاما از ctrl-<value> است، که در آن <value> یکی از موارد زیر است: a-z, @, ^, [, \, ], ^ یا _ مشخص کردن "" این قابلیت را غیرفعال می‌کند.

enable_port_reservation=true

تعیین می‌کند که آیا موتور هنگام فوروارد شدن پورت‌ها به کانتینرها، آنها را روی میزبان رزرو کند یا خیر. در صورت فعال بودن، هنگام فوروارد پورت‌ها به کانتینرها، تا زمانی که کانتینر در حال اجرا است پورت‌ها توسط conmon باز نگه داشته می‌شوند تا اطمینان حاصل شود که برنامه‌های دیگر روی میزبان نمی‌توانند از آنها استفاده کنند. با این حال، اگر کانتینری پورت‌های زیادی به آن فوروارد شده باشد، این امر می‌تواند باعث افزایش مصرف حافظه شود. غیرفعال کردن این گزینه می‌تواند حافظه را ذخیره کند اما توصیه نمی‌شود زیرا تداخل‌های پورت شناسایی نخواهند شد. توجه داشته باشید که این گزینه فقط برای کانتینرهای با دسترسی ریشه در زمانی که پورت‌ها از طریق قوانین فایروال فوروارد می‌شوند، استفاده می‌شود. کانتینرهای بدون ریشه با استفاده از pasta(1) همیشه باید به هر پورت bind شوند.

env=[]

متغیرهای محیطی که هنگام اجرای موتور کانتینر (مانند Podman، Buildah) استفاده می‌شوند؛ به عنوان مثال "MYVAR=value". این متغیرهای محیطی درون کانتینر استفاده نخواهند شد. اگر می‌خواهید متغیرهای محیطی را برای کانتینر تنظیم کنید، بخش env را در جدول [containers] تنظیم نمایید.

توجه داشته باشید که در صورت استفاده از این گزینه برای تنظیم متغیرهای پروکسی http، بسته به اینکه http_proxy (در جدول [containers]) روی true (پیش‌فرض) یا false تنظیم شده باشد، ممکن است این متغیرها به درون کانتینر درز پیدا کنند.

events_logfile_path=""

تعیین محل ذخیره لاگ‌های رویدادها، در صورتی که events_logger روی "file" تنظیم شده باشد.

events_logfile_max_size="1m"

حداکثر اندازه را برای events_logfile_path تعیین می‌کند. واحد می‌تواند b (بایت)، k (کیلوبایت)، m (مگابایت) یا g (گیگابایت) باشد. قالب اندازه به صورت <number><unit> است؛ مانند 1b یا 3g. اگر هیچ واحدی مشخص نشود، اندازه بر حسب بایت خواهد بود. هنگامی که اندازه از حد مجاز فراتر رود، فایل لاگ چرخش پیدا می‌کند (rotate) و فایل قدیمی حذف می‌شود. اگر حداکثر اندازه روی 0 تنظیم شود، هیچ محدودیتی اعمال نخواهد شد و فایل لاگ چرخش داده نمی‌شود.

events_logger="journald"

روش پیش‌فرض مورد استفاده برای لاگ‌گیری رویدادها.

روش پیش‌فرض بسته به پلتفرمی که Podman روی آن اجرا می‌شود متفاوت است. برای تعیین مقدار فعلی، از این دستور استفاده کنید:

podman info --format {{.Host.EventLogger}}

مقادیر معتبر عبارتند از: file, journald, و none.

events_container_create_inspect_data=true|false

ایجاد یک رویداد container-create با جزئیات بیشتر که شامل یک بار داده JSON با اطلاعات تفصیلی درباره کانتینر است. به‌طور پیش‌فرض روی false تنظیم شده است.

force_port_listen=false

برای کانتینرهای با دسترسی ریشه هنگام رزرو پورت‌ها، Podman به‌طور پیش‌فرض از listen() روی پورت‌های TCP استفاده نخواهد کرد زیرا اتصالات از طریق قوانین فایروال فوروارد می‌شوند. این کار برای اطمینان از این است که اگر قانون فایروال دور زده شود (مانند اتصال به "::1")، اتصال به درستی رد شود و برای همیشه معلق نماند زیرا ما هرگز آنها را accept() نمی‌کنیم. برای برنامه‌هایی که فقط وضعیت گوش دادن (listening) یک سوکت را نظارت می‌کنند، این بدان معناست که آنها پورت متصل‌شده را نخواهند دید. در این حالت این گزینه می‌تواند روی true تنظیم شود تا Podman مجبور شود listen() را نیز روی پورت‌ها فراخوانی کند. همچنین گزینه enable_port_reservation را ببینید.

healthcheck_events=true|false

تعیین اینکه آیا Podman باید رویدادهای بررسی سلامت (healthcheck) را ثبت کند یا خیر. با وجود بررسی‌های سلامت مکرر در فواصل زمانی کوتاه، پودمن لاگ رویدادها را بسیار شلوغ می‌کند زیرا برای هر بار اجرای healthcheck یک رویداد ایجاد می‌نماید. از آنجا که این رویداد اختیاری است و فقط برای مصرف‌کنندگان خارجی که می‌خواهند از زمان اجرا یا شکست healthcheck مطلع شوند مفید است، به کاربران امکان داده شده تا با تنظیم آن روی false این قابلیت را خاموش کنند.

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

helper_binaries_dir=["/usr/libexec/podman", ...]

فهرستی از دایرکتوری‌ها که برای جستجوی باینری‌های کمکی استفاده می‌شوند. باینری‌های زیر در این دایرکتوری‌ها جستجو می‌شوند:
- aardvark-dns
- catatonit
- netavark
- pasta

ماشین Podman از آن برای این باینری‌ها استفاده می‌کند:
- gvproxy
- qemu
- vfkit

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

/usr/local/libexec/podman
/usr/local/lib/podman
/usr/libexec/podman
/usr/lib/podman

مسیرهای پیش‌فرض در macOS عبارتند از:

/usr/local/opt/podman/libexec
/opt/homebrew/bin
/opt/homebrew/opt/podman/libexec
/usr/local/bin
/usr/local/libexec/podman
/usr/local/lib/podman
/usr/libexec/podman
/usr/lib/podman

مسیر پیش‌فرض در Windows عبارت است از:

•: C:\Program Files\RedHat\Podman

hooks_dir=["/etc/containers/oci/hooks.d", ...]

مسیر دایرکتوری‌های قلاب‌های OCI برای قلاب‌هایی که به‌طور خودکار اجرا می‌شوند.

cdi_spec_dirs=["/etc/cdi", "/var/run/cdi", ...]

دایرکتوری‌ها برای اسکن فایل‌های CDI Spec.

image_default_format="oci"|"v2s2"|"v2s1"

نوع مانیفست (oci, v2s2, یا v2s1) برای دریافت، ارسال و ساخت ایمیج‌های کانتینر. به‌طور پیش‌فرض ایمیج‌های دریافت شده و ارسال شده با قالب ایمیج مبدا مطابقت دارند. ساخت/ثبت (commit) به‌طور پیش‌فرض روی OCI است. نکته: گزینه image_build_format منسوخ شده است.

image_default_transport="docker://"

روش انتقال پیش‌فرض برای دریافت و ارسال ایمیج‌ها.

image_parallel_copies=0

حداکثر تعداد لایه‌های ایمیج که به‌طور همزمان کپی (دریافت/ارسال) می‌شوند. عدم تنظیم این فیلد به مقادیر پیش‌فرض containers/image برمی‌گردد (6).

image_volume_mode="bind"

به موتورهای کانتینر می‌گوید که چگونه حجم‌های داخلی ایمیج را مدیریت کنند.

bind: یک حجم نام‌گذاری‌شده ناشناس ایجاد شده و به داخل کانتینر متصل (mount) می‌شود.
tmpfs: حجم به صورت tmpfs روی کانتینر سوار می‌شود که به کاربران امکان می‌دهد محتوایی ایجاد کنند که با توقف کانتینر ناپدید می‌شود.
ignore: تمام حجم‌ها نادیده گرفته می‌شوند و هیچ اقدامی انجام نمی‌شود.

infra_command="/pause"

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

infra_image=""

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

kube_generate_type="pod"

نوع/مشخصات پیش‌فرض Kubernetes در فرمت yaml تولیدشده با دستور podman kube generate. گزینه‌های ممکن عبارتند از pod و deployment.

lock_type="shm"

تعیین سازوکار قفل‌گذاری مورد استفاده؛ مقادیر معتبر "shm" و "file" هستند. پیش‌فرض را تنها در صورتی تغییر دهید که از کار خود مطمئن هستید. به‌طور کلی "file" تنها در پلتفرم‌هایی مفید است که cgo برای استفاده از نوع قفل سریع‌تر "shm" در دسترس نیست. ممکن است پس از تغییر نوع قفل، نیاز به اجرای "podman system renumber" داشته باشید.

multi_image_archive=false

امکان ایجاد آرشیوها (مانند tarball) با بیش از یک ایمیج را فراهم می‌کند. برخی موتورهای کانتینر، مانند Podman، آرگومان‌های اضافی را به عنوان تگ‌هایی برای یک ایمیج تفسیر می‌کنند و بنابراین بیش از یک ایمیج را ذخیره نمی‌کنند. رفتار پیش‌فرض را می‌توان با این گزینه تغییر داد.

namespace=""

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

no_pivot_root=false

تعیین اینکه آیا به جای pivot_root در زمان اجرا از chroot استفاده شود یا خیر.

num_locks=2048

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

pod_exit_policy="continue"

تنظیم سیاست خروج پاد هنگام خروج آخرین کانتینر. سیاست‌های پشتیبانی‌شده عبارتند از:

Exit Policy	Description
continue	پاد پس از خروج آخرین کانتینر به اجرای خود ادامه می‌دهد. به‌طور پیش‌فرض استفاده می‌شود.
stop	پاد با خروج آخرین کانتینر متوقف می‌شود. در play kube استفاده می‌شود.

pull_policy="always"|"missing"|"never"

سیاست دریافت ایمیج قبل از اجرا یا ایجاد کانتینر. پیش‌فرض missing است.

missing: در صورتی که ایمیج محلی وجود نداشته باشد، تلاش می‌کند آخرین ایمیج را از رجیستری‌های فهرست‌شده در registries.conf دریافت کند. اگر ایمیج در هیچ رجیستری فهرست‌شده نباشد و به صورت محلی موجود نباشد، خطا می‌دهد.
always: ایمیج را از اولین رجیستری که در آن یافت شود طبق لیست registries.conf دریافت می‌کند. در صورت عدم یافتن در رجیستری‌ها، حتی اگر ایمیج به صورت محلی موجود باشد، خطا می‌دهد.
never: ایمیج را از رجیستری دریافت نمی‌کند و فقط از نسخه محلی استفاده می‌کند. اگر ایمیج به صورت محلی موجود نباشد، خطا می‌دهد.

remote = false

نشان می‌دهد که آیا برنامه باید در حالت ریموت اجرا شود یا خیر. این فلگ گزینه --remote را در موتورهای کانتینر تغییر می‌دهد. تنظیم فلگ روی true باعث می‌شود مقدار پیش‌فرض podman --remote=true برای دسترسی به سرویس راه دور Podman فعال شود.

retry = 3

تعداد دفعات تلاش مجدد برای دریافت/ارسال ایمیج‌ها در صورت بروز خطا.

retry_delay = ""

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

runtime=""

زمان اجرای پیش‌فرض مبتنی بر OCI در runtimes که به صورت پیش‌فرض استفاده خواهد شد. باید به عضوی از جدول runtimes اشاره کند. زمان اجرای پیش‌فرض با اولویت‌های زیر در سیستم جستجو خواهد شد: "crun", "runc", "runj", "kata", "runsc", "ocijail"

runtime_supports_json=["crun", "crun-vm", "runc", "kata", "runsc", "youki", "krun"]

فهرست زمان‌های اجرای OCI که از --format=json پشتیبانی می‌کنند.

runtime_supports_kvm=["kata", "krun"]

فهرست زمان‌های اجرای OCI که از اجرای کانتینرها با جداسازی KVM پشتیبانی می‌کنند.

runtime_supports_nocgroups=["crun", "crun-vm", "krun"]

فهرست زمان‌های اجرای OCI که از اجرای کانتینرها بدون CGroups پشتیبانی می‌کنند.

image_copy_tmp_dir="/var/tmp"

مکان پیش‌فرض برای ذخیره موقت محتوای ایمیج کانتینر. می‌تواند با متغیر محیطی TMPDIR بازنویسی شود. اگر "storage" را مشخص کنید، از مکان دایرکتوری موقت container/storage استفاده خواهد شد. در صورت تنظیم، مسئولیت پاک‌سازی حافظه بر عهده کاربر است. برای پاک‌سازی فضای ذخیره‌سازی، tmpfiles.d(5) را پیکربندی کنید.

service_timeout=5

تعداد ثانیه‌های انتظار بدون اتصال قبل از اینکه podman system service منقضی شده و خارج شود.

static_dir="/var/lib/containers/storage/libpod"

دایرکتوری فایل‌های ماندگار libpod (پایگاه داده و غیره). به‌طور پیش‌فرض این مقدار نسبت به جایی که containers/storage کانتینرها را ذخیره می‌کند، پیکربندی می‌شود.

stop_timeout=10

تعداد ثانیه‌های انتظار برای خروج کانتینر قبل از ارسال سیگنال kill.

exit_command_delay=300

تعداد ثانیه‌های انتظار برای فرآیند API جهت فراخوانی exec پیش از ارسال دستور خروج (مشابه رفتار ۵ دقیقه‌ای Docker بر حسب ثانیه).

tmp_dir="/run/libpod"

مسیر دایرکتوری موقت برای ذخیره کانتینرها در هر بار راه‌اندازی (per-boot). باید یک tmpfs باشد (پس از راه‌اندازی مجدد پاک شود).

volume_path="/var/lib/containers/storage/volumes"

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

chown_copied_files=true

تعیین می‌کند که آیا مالکیت فایل کپی‌شده درون کانتینر به uid/gid اصلی کانتینر تغییر یابد یا خیر.

compression_format="gzip"

قالب فشرده‌سازی مورد استفاده هنگام ارسال ایمیج را مشخص می‌کند. مقادیر پشتیبانی‌شده عبارتند از: gzip, zstd و zstd:chunked. این فیلد هنگام ارسال ایمیج‌ها به قالب‌های docker-daemon و docker-archive نادیده گرفته می‌شود. همچنین هنگامی که قالب مانیفست روی v2s2 تنظیم شده باشد نادیده گرفته خواهد شد. گزینه zstd:chunked با رمزگذاری ایمیج‌ها ناسازگار است و در این حالت با یک هشدار به صورت zstd تلقی خواهد شد.

compression_level="5"

سطح فشرده‌سازی مورد استفاده هنگام ارسال ایمیج. گزینه‌های معتبر بستگی به قالب فشرده‌سازی استفاده‌شده دارند. برای gzip، گزینه‌های معتبر 1-9 با مقدار پیش‌فرض 5 هستند. برای zstd، گزینه‌های معتبر 1-20 با مقدار پیش‌فرض 3 هستند.

جدول SERVICE DESTINATION (SERVICE DESTINATION TABLE)

جدول engine.service_destinations شامل گزینه‌های پیکربندی مورد استفاده برای راه‌اندازی اتصالات از راه دور به سرویس podman برای API پودمن است.

[engine.service_destinations.{name}] شناسه URI برای دسترسی به سرویس Podman uri="ssh://user@production.example.com/run/user/1001/podman/podman.sock"

نمونه‌های URI:

rootless local - unix:///run/user/1000/podman/podman.sock
rootless remote - ssh://user@engineering.lab.company.com/run/user/1000/podman/podman.sock
rootful local - unix:///run/podman/podman.sock
rootful remote - ssh://root@10.10.1.136:22/run/podman/podman.sock
tcp/tls remote - tcp://10.10.1.136:9443

identity="~/.ssh/id_rsa

مسیر فایل حاوی کلید هویت ssh

tls_cert="/path/to/certs/podman/tls.crt"

مسیر فایل PEM حاوی گواهی کلاینت TLS

tls_key="/path/to/certs/podman/tls.key"

مسیر فایل PEM حاوی کلید خصوصی گواهی کلاینت TLS

tls_ca="/path/to/certs/podman/ca.crt"

مسیر فایل PEM حاوی بسته مرجع گواهی (CA) TLS

[engine.runtimes_flags]

فهرست فلگ‌های پیش‌فرض زمان اجرا برای هر زمان اجرای OCI معتبر (crun, runc, kata, runsc, krun, غیره).

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

[engine.volume_plugins]

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

[engine.platform_to_oci_runtime]

به کاربران نهایی امکان می‌دهد زمان اجرای OCI را بر اساس رشته پلتفرم ایمیج کانتینر تغییر دهند. فیلد پیکربندی زیر شامل نگاشتی از platform/string = oci_runtime است.

جدول SECRET (SECRET TABLE)

جدول secret شامل تنظیماتی برای پیکربندی زیرسیستم secret است.

driver=file

نام درایور secret مورد استفاده. مقادیر معتبر در حال حاضر عبارتند از:
* file
* pass

[secrets.opts]

شیء گزینه‌های اختصاصی درایور.

جدول MACHINE (MACHINE TABLE)

جدول machine شامل پیکربندی‌های مربوط به ماشین‌های مجازی podman machine است.

cpus=1 تعداد پردازنده‌هایی که یک ماشین با آن ایجاد می‌شود.

disk_size=10

اندازه دیسک بر حسب گیگابایت که هنگام مقداردهی اولیه ماشین مجازی podman-machine ایجاد می‌شود.

image="docker://quay.io/podman/machine-os"

ایمیج مورد استفاده هنگام ایجاد یک ماشین مجازی جدید با استفاده از podman machine init. می‌تواند به عنوان یک رجیستری با یک آرتیفکت OCI قابل بوت، نشانی وب بارگیری، یا یک مسیر محلی مشخص شود. مقصد رجیستری باید به فرمت docker://registry/repo/image:version باشد. موتورهای کانتینر مقادیر $OS و $ARCH در URI را به OS و ARCH بومی ترجمه می‌کنند. آدرس "https://example.com/$OS/$ARCH/foobar.ami" روی یک ماشین لینوکس AMD به "https://example.com/linux/amd64/foobar.ami" تبدیل خواهد شد. در صورت عدم تعیین، از ایمیج پیش‌فرض ماشین Podman استفاده خواهد شد.

memory=2048

حافظه بر حسب مگابایت که ماشین با آن ایجاد می‌شود.

user=""

نام کاربری مورد استفاده و ایجادشده در سیستم‌عامل ماشین podman برای دسترسی کانتینر بدون ریشه. مقدار پیش‌فرض user است. در Linux/Mac مقدار پیش‌فرض core است.

volumes=["$HOME:$HOME"]

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

در مک، حجم‌های پیش‌فرض عبارتند از:

[ "/Users:/Users", "/private:/private", "/var/folders:/var/folders" ]

provider=""

ارائه‌دهنده مجازی‌سازی مورد استفاده برای اجرای ماشین مجازی podman-machine. مقدار خالی به عنوان ارائه‌دهنده پیش‌فرض برای سیستم‌عامل میزبان فعلی تفسیر می‌شود.

Platform	Default Virtualization provider	Optional
Linux	"" (qemu)	None
Windows	"" ("wsl": Windows Subsystem for Linux)	"hyperv" (Windows Server Virtualization)
Mac	"" ("libkrun": اجرای ماشین از طریق پلتفرم libkrun، بهینه‌سازی‌شده برای اشتراک‌گذاری GPU با ماشین)	"applehv" (Apple Hypervisor)

rosetta=false

قابلیت Rosetta از اجرای باینری‌های x86_64 لینوکس روی یک ماشین Podman در تراشه‌های Apple Silicon پشتیبانی می‌کند. مقدار پیش‌فرض false است. فقط در ماشین‌های AppleHV(arm64) پشتیبانی می‌شود.

import_native_ca=false

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

جدول FARMS (FARMS TABLE)

جدول farms شامل گزینه‌های پیکربندی مورد استفاده برای گروه‌بندی اتصالات راه دور در قالب فارم‌ها است که هنگام ارسال ساخت‌ها (builds) به ماشین‌های مختلف در یک فارم از طریق podman buildfarm استفاده خواهند شد.

default=""

فارم پیش‌فرض برای استفاده هنگام برون‌سپاری فرآیند ساخت.

[farms.list]

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

جدول PODMANSH (PODMANSH TABLE)

جدول podmansh شامل گزینه‌های پیکربندی مورد استفاده توسط podmansh است.

shell="/bin/sh"

پوسته‌ای که در کانتینر اجرا می‌شود. مقدار پیش‌فرض /bin/sh است.

container="podmansh"

نام کانتینری که podmansh به آن ملحق می‌شود. مقدار پیش‌فرض podmansh است.

timeout=0

تعداد ثانیه‌های انتظار برای ورود به podmansh. این مقدار در صورت تنظیم، بر فیلد منسوخ‌شده engine.podmansh_timeout اولویت دارد. مقدار پیش‌فرض 30 است.

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

containers-config(5), containers-storage.conf(5), containers-policy.json(5), containers-registries.conf(5), tmpfiles.d(5)