podman-container.unit(5) File Formats Manual podman-container.unit(5)

podman-container.unit - فایل‌های واحد systemd برای مدیریت کانتینرها با استفاده از Podman Quadlet

name.container

واحد‌های کانتینر با پسوند .container نام‌گذاری می‌شوند و شامل یک بخش [Container] هستند که کانتینر در حال اجرا به عنوان یک سرویس را توصیف می‌کند. فایل سرویس حاصل شامل خطی مانند ExecStart=podman run ... image-name است، و بیشتر کلیدهای این بخش گزینه‌های خط فرمانی ارسال‌شده به Podman را کنترل می‌کنند. با این حال، برخی گزینه‌ها بر جزئیات نحوه راه‌اندازی و تعامل systemd با کانتینر نیز تأثیر می‌گذارند.

به‌طور پیش‌فرض، کانتینر Podman همان نام واحد را دارد، اما با پیشوند systemd-؛ یعنی یک فایل $name.container یک واحد $name.service و یک کانتینر Podman به نام systemd-$name ایجاد می‌کند. گزینه ContainerName امکان بازنویسی این نام پیش‌فرض را با نام ارائه‌شده توسط کاربر فراهم می‌کند.

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

فایل .container در زمان بوت یا بارگذاری مجدد (reload) توسط podman-system-generator تجزیه می‌شود و یک .service در systemd تولید می‌کند که podman run را اجرا می‌نماید. آن سرویس می‌تواند مانند هر واحد دیگری مدیریت شود:

systemctl --user start myimage-container.service

گزینه‌های معتبر برای [Container] در زیر فهرست شده‌اند:

گزینه‌های [Container] معادل در podman run
AddCapability=CAP --cap-add CAP
AddDevice=/dev/foo --device /dev/foo
AddHost=example.com:192.168.10.11 --add-host example.com:192.168.10.11
Annotation="XYZ" --annotation "XYZ"
AutoUpdate=registry --label "io.containers.autoupdate=registry"
CgroupsMode=no-conmon --cgroups=no-conmon
ContainerName=name --name name
ContainersConfModule=/etc/nvd.conf --module=/etc/nvd.conf
DNS=192.168.55.1 --dns=192.168.55.1
DNSOption=ndots:1 --dns-option=ndots:1
DNSSearch=example.com --dns-search example.com
DropCapability=CAP --cap-drop=CAP
Entrypoint=/foo.sh --entrypoint=/foo.sh
Environment=foo=bar --env foo=bar
EnvironmentFile=/tmp/env --env-file /tmp/env
EnvironmentHost=true --env-host
Exec=/usr/bin/command دستور پس از تعیین ایمیج - /usr/bin/command
ExposeHostPort=50-59 --expose 50-59
GIDMap=0:10000:10 --gidmap=0:10000:10
GlobalArgs=--log-level=debug --log-level=debug
Group=1234 --user UID:1234
GroupAdd=keep-groups --group-add=keep-groups
HealthCmd=/usr/bin/command --health-cmd=/usr/bin/command
HealthInterval=2m --health-interval=2m
HealthLogDestination=/foo/log --health-log-destination=/foo/log
HealthMaxLogCount=5 --health-max-log-count=5
HealthMaxLogSize=500 --health-max-log-size=500
HealthOnFailure=kill --health-on-failure=kill
HealthRetries=5 --health-retries=5
HealthStartPeriod=1m --health-start-period=1m
HealthStartupCmd=command --health-startup-cmd=command
HealthStartupInterval=1m --health-startup-interval=1m
HealthStartupRetries=8 --health-startup-retries=8
HealthStartupSuccess=2 --health-startup-success=2
HealthStartupTimeout=1m33s --health-startup-timeout=1m33s
HealthTimeout=20s --health-timeout=20s
HostName=example.com --hostname example.com
HttpProxy=true --http-proxy=true
Image=ubi8 تعیین ایمیج - ubi8
ImageVolume=tmpfs --image-volume tmpfs
IP=192.5.0.1 --ip 192.5.0.1
IP6=2001:db8::1 --ip6 2001:db8::1
Label="XYZ" --label "XYZ"
LogDriver=journald --log-driver journald
LogOpt=path=/var/log/mykube.json --log-opt path=/var/log/mykube.json
Mask=/proc/sys/foo:/proc/sys/bar --security-opt mask=/proc/sys/foo:/proc/sys/bar
Memory=20g --memory 20g
Mount=type=... --mount type=...
Network=host --network host
NetworkAlias=name --network-alias name
NoNewPrivileges=true --security-opt no-new-privileges
Notify=true --sdnotify container
PidsLimit=10000 --pids-limit 10000
Pod=pod-name --pod=pod-name
PodmanArgs=--publish 8080:80 --publish 8080:80
PublishPort=8080:80 --publish 8080:80
Pull=never --pull never
ReadOnly=true --read-only
ReadOnlyTmpfs=true --read-only-tmpfs
ReloadCmd=/usr/bin/command افزودن ExecReload و اجرای exec با این مقدار
ReloadSignal=SIGHUP افزودن ExecReload و اجرای kill با این سیگنال
Retry=5 --retry=5
RetryDelay=5s --retry-delay=5s
Rootfs=/var/lib/rootfs --rootfs /var/lib/rootfs
RunInit=true --init
SeccompProfile=/tmp/s.json --security-opt seccomp=/tmp/s.json
Secret=secret --secret=secret[,opt=opt ...]
SecurityLabelDisable=true --security-opt label=disable
SecurityLabelFileType=usr_t --security-opt label=filetype:usr_t
SecurityLabelLevel=s0:c1,c2 --security-opt label=level:s0:c1,c2
SecurityLabelNested=true --security-opt label=nested
SecurityLabelType=spc_t --security-opt label=type:spc_t
ShmSize=100m --shm-size=100m
StartWithPod=true اگر Pod= تعریف شده باشد، کانتینر توسط پاد راه‌اندازی می‌شود
StopSignal=SIGINT --stop-signal=SIGINT
StopTimeout=20 --stop-timeout=20
SubGIDMap=gtest --subgidname=gtest
SubUIDMap=utest --subuidname=utest
Sysctl=name=value --sysctl=name=value
Timezone=local --tz local
Tmpfs=/work --tmpfs /work
UIDMap=0:10000:10 --uidmap=0:10000:10
Ulimit=nofile=1000:10000 --ulimit nofile=1000:10000
Unmask=ALL --security-opt unmask=ALL
User=bin --user bin
UserNS=keep-id:uid=200,gid=210 --userns keep-id:uid=200,gid=210
Volume=/source:/dest --volume /source:/dest
WorkingDir=$HOME --workdir $HOME

کلیدهای پشتیبانی‌شده در بخش [Container] عبارتند از:

افزودن قابلیت‌های لینوکس (Linux capabilities).

اعطای قابلیت‌های بیشتر، دسترسی‌ها و امتیازات فرآیندهای در حال اجرا درون کانتینر را افزایش می‌دهد و ممکن است به آن‌ها اجازه خروج از محدوده امنیتی (confinement) را بدهد. قابلیت‌هایی مانند CAP_SYS_ADMIN، CAP_SYS_PTRACE، CAP_MKNOD و CAP_SYS_MODULE به‌ویژه زمانی که درون یک فضای نام کاربری (user namespace) استفاده نشوند، بسیار خطرناک هستند. لطفاً برای توضیح دقیق‌تر درباره نحوه تعامل بین فضاهای نام کاربری و قابلیت‌ها، به user_namespaces(7) مراجعه کنید.

پیش از افزودن هر قابلیتی، پیامدهای امنیتی آن را بررسی کرده و اطمینان حاصل کنید که واقعاً برای عملکرد کانتینر ضروری است. برای اطلاعات بیشتر به capabilities(7) مراجعه کنید.

افزودن یک دستگاه میزبان به کانتینر. قالب این گزینه به‌صورت HOST-DEVICE[:CONTAINER-DEVICE][:PERMISSIONS] است، که در آن HOST-DEVICE مسیر گره دستگاه (device node) روی میزبان، CONTAINER-DEVICE مسیر گره دستگاه در کانتینر، و PERMISSIONS فهرستی از مجوزها شامل ترکیبی از «r» برای خواندن، «w» برای نوشتن، و «m» برای mknod(2) است.

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

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

پادمن ممکن است ماژول‌های هسته مورد نیاز برای استفاده از دستگاه مشخص‌شده را بارگذاری کند. دستگاه‌هایی که پادمن در صورت لزوم ماژول‌های آن‌ها را بارگذاری می‌کند عبارتند از: /dev/fuse.

در حالت بدون ریشه (rootless)، دستگاه جدید از میزبان به درون کانتینر bind mount می‌شود، به‌جای اینکه پادمن آن را در فضای کانتینر ایجاد کند. از آنجا که اتصال bind برچسب SELinux خود را در سیستم‌های دارای SELinux حفظ می‌کند، ممکن است کانتینر هنگام دسترسی به دستگاه متصل‌شده با خطای عدم دسترسی (permission denied) روبرو شود. برای اجازه دادن به کانتینرها جهت استفاده از تمام برچسب‌های دستگاه، تنظیمات SELinux را با دستور زیر تغییر دهید:

$ sudo setsebool -P container_use_devices=true

افزودن نگاشت سفارشی نام میزبان به IP در فایل /etc/hosts کانتینر.

این گزینه یک یا چند نام میزبان را که با نقطه-ویرگول از هم جدا شده‌اند می‌پذیرد تا به یک آدرس IPv4 یا IPv6 واحد نگاشت شوند (که با دونقطه از نام‌ها جدا می‌شود). این گزینه همچنین می‌تواند برای بازنویسی آدرس‌های IP نام‌های میزبانی که پادمن به‌طور پیش‌فرض به /etc/hosts اضافه می‌کند استفاده شود (همچنین به گزینه‌های --name و --hostname مراجعه کنید). این گزینه می‌تواند چندین بار مشخص شود تا نگاشت‌های بیشتری به /etc/hosts اضافه گردد. این گزینه با گزینه --no-hosts و با no_hosts=true در containers.conf تداخل دارد.

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

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

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

افزودن یک یادداشت (annotation) به کانتینر. این گزینه می‌تواند چندین بار تنظیم شود.

مشخص می‌کند که آیا کانتینر به‌طور خودکار به‌روزرسانی شود یا خیر (podman-auto-update(1)). مقادیر زیر پشتیبانی می‌شوند:

  • registry: نیاز دارد که یک مرجع ایمیج کاملاً واجد شرایط (مانند quay.io/podman/stable:latest) برای ایجاد کانتینر استفاده شود. این الزام برای دانستن این است که کدام ایمیج باید واقعاً بررسی و دریافت (pull) شود. اگر از شناسه ایمیج استفاده شده باشد، پادمن دیگر نمی‌داند کدام ایمیج را بررسی/دریافت کند.
  • local: به پادمن اعلام می‌کند ایمیجی را که کانتینر استفاده می‌کند با ایمیجی با نام خام آن در حافظه محلی مقایسه کند. اگر ایمیج به‌صورت محلی به‌روزرسانی شود، پادمن به‌سادگی واحد systemd اجراکننده کانتینر را بازراه‌اندازی (restart) می‌کند.

تعیین می‌کند که آیا کانتینر cgroup ایجاد کند یا خیر.

به‌طور پیش‌فرض، حالت cgroups کانتینر ایجادشده توسط Quadlet برابر با split است که با پیش‌فرض (enabled) استفاده‌شده در رابط خط فرمان Podman تفاوت دارد.

اگر کانتینر به یک پاد متصل شود (یعنی Pod= مشخص شده باشد)، ممکن است بخواهید این را به no-conmon یا enabled تغییر دهید تا محدودیت‌های منابع cgroup در سطح پاد اعمال شوند.

گزینه enabled یک cgroup جدید در زیر cgroup-parent ایجاد می‌کند. گزینه disabled کانتینر را مجبور می‌کند که cgroup ایجاد نکند و بنابراین با گزینه‌های cgroup یعنی (--cgroupns و --cgroup-parent) تداخل دارد. گزینه no-conmon ایجاد cgroup جدید را فقط برای فرآیند conmon غیرفعال می‌کند. گزینه split گروه cgroup فعلی را به دو زیرگروه cgroup تقسیم می‌کند: یکی برای conmon و دیگری برای بار مفید کانتینر (container payload). تنظیم --cgroup-parent همراه با split امکان‌پذیر نیست.

اختصاص یک نام به کانتینر.

اپراتور می‌تواند یک کانتینر را به سه روش شناسایی کند:

  • شناسه طولانی UUID (مانند «f78375b1c487e03c9438c729345e54db9d20cfa2ac1fc3494b6eb60872e74778»)؛
  • شناسه کوتاه UUID (مانند «f78375b1c487»)؛
  • نام (مانند «jonah»).

پادمن برای هر کانتینر یک UUID تولید می‌کند، و اگر با استفاده از ContainerName= نامی به کانتینر اختصاص داده نشود، پادمن یک نام رشته‌ای تصادفی مانند exciting_chebyshev (به‌صورت صفت_اسم، سازگار با داکر) تولید می‌کند. الزامی نیست که نام کانتینرها یک نام میزبان یا نام دامنه معتبر باشد. خط زیر (underscore) و سایر نویسه‌های مجاز طبق قوانین نام‌گذاری مجاز هستند. در شبکه‌های پادمن با DNS فعال، حل نام کانتینر به کانتینر همچنان از همان نام ارائه‌شده استفاده می‌کند، مثلاً exciting_chebyshev. این نام می‌تواند به‌عنوان روشی کاربرپسندتر برای شناسایی کانتینرها مفید باشد. این ویژگی هم برای کانتینرهای پس‌زمینه و هم پیش‌زمینه کار می‌کند. نام کانتینر همچنین با استفاده از آدرس IP اصلی کانتینر به فایل /etc/hosts اضافه می‌شود (همچنین به گزینه AddHost= مراجعه کنید).

این نام، نام میزبان (hostname) درون کانتینر نیست؛ به HostName= مراجعه کنید. برای اطلاعات بیشتر درباره DNS شبکه به podman-network(1) مراجعه کنید.

بارگذاری ماژول مشخص‌شده در containers.conf(5).

این گزینه می‌تواند چندین بار فهرست شود.

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

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

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

توجه داشته باشید که ipaddr ممکن است مستقیماً به /etc/resolv.conf کانتینر افزوده شود؛ با این حال این مورد تضمین‌شده نیست. به‌عنوان مثال، ارسال یک شبکه سفارشی که dns_enabled آن روی true تنظیم شده است به --network باعث می‌شود /etc/resolv.conf فقط به سرور aardvark-dns اشاره کند. سپس aardvark-dns تمام پرس‌وجوهای نام‌های غیرکانتینری را به ipaddr ارائه‌شده فوروارد می‌کند.

تنظیم گزینه‌های سفارشی DNS. در صورت استفاده از DNSOption= همراه با Network= که روی none یا container:id تنظیم شده باشد، نامعتبر است.

تنظیم دامنه‌های جستجوی سفارشی DNS. در صورت استفاده از DNSSearch= همراه با Network= که روی none یا container:id تنظیم شده باشد، نامعتبر است. از DNSSearch=. برای حذف دامنه جستجو استفاده کنید.

حذف این قابلیت‌ها از مجموعه قابلیت‌های پیش‌فرض پادمن، یا all برای حذف تمام قابلیت‌ها.

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

بازنویسی ENTRYPOINT پیش‌فرض از ایمیج.

نقطه ورود (ENTRYPOINT) یک ایمیج شبیه به COMMAND است چرا که مشخص می‌کند هنگام شروع کانتینر چه فایل اجرایی باید اجرا شود، اما (به‌عمد) بازنویسی آن دشوارتر است. ENTRYPOINT ماهیت یا رفتار پیش‌فرض کانتینر را تعیین می‌کند. هنگامی که ENTRYPOINT تنظیم می‌شود، کانتینر طوری اجرا می‌شود که گویی خود آن فایل دودویی (binary) است، همراه با گزینه‌های پیش‌فرض. گزینه‌های بیشتر می‌توانند از طریق COMMAND ارسال شوند. اما، اگر کاربری بخواهد چیز دیگری را در داخل کانتینر اجرا کند، گزینه Entrypoint= امکان مشخص کردن یک ENTRYPOINT جدید را فراهم می‌سازد.

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

تنظیم متغیرهای محیطی.

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

خواندن یک فایل خط‌به‌خط شامل متغیرهای محیطی.

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

آرگومان‌های اضافی برای کانتینر؛ این دقیقاً همان اثری را دارد که ارسال آرگومان‌های بیشتر پس از فراخوانی podman run <image> <arguments> دارد.

قالب آن همانند خطوط فرمان systemd است، با این حال برخلاف دستورالعمل هم‌نام systemd یعنی ExecStart= که روی سیستم‌فایل ریشه جاری عمل می‌کند، بسیار رایج است که ایمیج‌های کانتینر متادیتای ENTRYPOINT یا CMD مخصوص به خود را داشته باشند که این فیلد با آن‌ها تعامل دارد.

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

روش دیگر برای توصیف این مورد این است که عملکردی کاملاً مشابه با فیلد args در یک پاد Kubernetes دارد.

نمایان ساختن (expose) یک درگاه (پورت) یا محدوده‌ای از درگاه‌ها (مانند Expose=3300-3310). پروتکل می‌تواند tcp، udp یا sctp باشد و در صورت عدم ارائه، tcp فرض می‌شود. این گزینه با دستورالعمل EXPOSE برای ساخت ایمیج مطابقت دارد و هیچ تاثیری بر قوانین واقعی شبکه ندارد مگر اینکه از -P/--publish-all برای فوروارد کردن از درگاه‌های تصادفی میزبان به تمام درگاه‌های نمایان‌شده استفاده شود. برای فوروارد کردن درگاه‌های خاص از میزبان به درون کانتینر، به‌جای این از گزینه PublishPort= استفاده کنید.

اجرای کانتینر در یک فضای نام کاربری جدید با استفاده از نگاشت GID ارائه‌شده. این گزینه با گزینه‌های UserNS= و SubGIDMap= تداخل دارد. این گزینه روشی برای نگاشت GIDهای میزبان به GIDهای کانتینر به همان شیوه‌ای که --uidmap شناسه‌های UID میزبان را به UIDهای کانتینر نگاشت می‌کند، فراهم می‌سازد. برای جزئیات به --uidmap مراجعه کنید.

نکته: گزینه GIDMap= نمی‌تواند همراه با گزینه Pod= فراخوانی شود زیرا هنگام حضور در یک پاد، نمی‌توان gidmap را در سطح کانتینر تنظیم کرد.

این کلید شامل فهرستی از آرگومان‌ها است که مستقیماً پس از دستور podman در فایل تولیدشده قرار می‌گیرند. این گزینه می‌تواند برای دسترسی به ویژگی‌های پادمن که توسط مولد (generator) پشتیبانی نمی‌شوند استفاده شود. از آنجا که مولد از تعاملات غیرمنتظره‌ای که این آرگومان‌ها ممکن است ایجاد کنند بی‌اطلاع است، استفاده از این گزینه توصیه نمی‌شود.

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

این کلید می‌تواند چندین بار درج شود.

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

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

•
keep-groups یک فلگ ویژه است که به پادمن می‌گوید دسترسی گروه‌های تکمیلی (supplementary group access) را حفظ کند.

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

تنظیم یا تغییر دستور بررسی سلامت (healthcheck) برای کانتینر. این دستور، دستوری است که درون کانتینر اجرا شده و سلامت کانتینر را تعیین می‌کند. این دستور برای اعمال سایر گزینه‌های بررسی سلامت الزامی است. مقدار none بررسی‌های سلامت موجود را غیرفعال می‌کند.

گزینه‌های متعدد می‌توانند در قالب یک آرایه JSON ارسال شوند؛ در غیر این صورت، دستور به‌عنوان یک آرگومان برای /bin/sh -c تفسیر می‌شود.

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

تنظیم بازه زمانی برای بررسی‌های سلامت. بازه زمانی disable باعث می‌شود هیچ تایمر خودکاری راه‌اندازی نشود. مقدار پیش‌فرض 30s است.

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

تنظیم مقصد ثبت گزارش بررسی سلامت (HealthCheck log). مسیر دایرکتوری، local یا events_logger (حالت local از فایل وضعیت کانتینر استفاده می‌کند) (پیش‌فرض: local).

  • local: (پیش‌فرض) گزارش‌های HealthCheck در کانتینرهای overlay ذخیره می‌شوند (برای مثال: $runroot/healthcheck.log).
  • directory: یک فایل لاگ به نام <container-ID>-healthcheck.log شامل لاگ‌های HealthCheck در دایرکتوری مشخص‌شده ایجاد می‌کند.
  • events_logger: لاگ با مکانیزم ثبت لاگ تنظیم‌شده توسط events_logger نوشته خواهد شد. این گزینه همچنین برای بهبود عملکرد در سیستمی با تعداد لاگ‌های زیاد، گزارش را در یک دایرکتوری پیش‌فرض ذخیره می‌کند.

تنظیم حداکثر تعداد تلاش‌ها در فایل لاگ HealthCheck (مقدار «0» به معنای تعداد نامحدود تلاش‌ها در فایل لاگ است) (پیش‌فرض: ۵ تلاش).

تنظیم حداکثر طول گزارش ذخیره‌شده HealthCheck بر حسب نویسه (کاراکتر) (مقدار «0» به معنای طول لاگ نامحدود است) (پیش‌فرض: ۵۰۰ نویسه).

اقدامی که باید پس از انتقال کانتینر به وضعیت ناسالم (unhealthy) انجام شود. پیش‌فرض none است.

  • none: هیچ اقدامی انجام نمی‌دهد.
  • kill: کانتینر را از بین می‌برد (kill).
  • restart: کانتینر را بازراه‌اندازی می‌کند (restart). عمل restart را با فلگ --restart ترکیب نکنید. هنگام اجرا در داخل یک واحد systemd، برای استفاده از خط‌مشی بازراه‌اندازی systemd، استفاده از عملیات kill یا stop را در نظر بگیرید.
  • stop: کانتینر را متوقف می‌کند (stop).

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

نکته: این پارامتر می‌تواند پیکربندی بررسی سلامت در ایمیج را بازنویسی کند.

زمان مقداردهی اولیه مورد نیاز برای راه‌اندازی (bootstrap) کانتینر. مقدار می‌تواند در قالبی مانند 2m3s بیان شود. مقدار پیش‌فرض 0s است.

نکته: دستور بررسی سلامت به محض راه‌اندازی کانتینر اجرا می‌شود؛ اگر بررسی سلامت موفقیت‌آمیز باشد، وضعیت سلامت کانتینر به healthy به‌روزرسانی می‌شود. با این حال، اگر بررسی سلامت ناموفق باشد، وضعیت سلامت روی starting باقی می‌ماند تا زمانی که بررسی سلامت موفق شود یا زمان HealthStartPeriod= به پایان برسد. اگر دستور بررسی سلامت پس از پایان زمان HealthStartPeriod= شکست بخورد، وضعیت سلامت به unhealthy به‌روزرسانی خواهد شد. دستور بررسی سلامت بر اساس مقدار HealthInterval= به‌صورت دوره‌ای اجرا می‌شود.

نکته: این پارامتر پیکربندی مربوط به بررسی سلامت در ایمیج را بازنویسی خواهد کرد.

تنظیم یک دستور بررسی سلامت هنگام راه‌اندازی برای کانتینر. این دستور در داخل کانتینر اجرا می‌شود و برای دروازه‌بانی (کنترل آغاز) بررسی سلامت عادی به کار می‌رود. هنگامی که دستور راه‌اندازی موفق شود، بررسی سلامت عادی آغاز شده و بررسی سلامت راه‌اندازی متوقف می‌شود. در صورت تمایل، اگر دستور به تعداد دفعات مشخصی با شکست مواجه شود، کانتینر بازراه‌اندازی می‌شود. بررسی سلامت راه‌اندازی می‌تواند برای اطمینان از این مورد استفاده شود که کانتینرهایی با مدت زمان راه‌اندازی طولانی تا زمانی که کاملاً راه‌اندازی نشده‌اند به‌عنوان ناسالم علامت‌گذاری نشوند. بررسی‌های سلامت راه‌اندازی فقط زمانی قابل استفاده هستند که بررسی سلامت عادی (از ایمیج کانتینر یا گزینه HealthCmd=) نیز تنظیم شده باشد.

تنظیم بازه زمانی برای بررسی سلامت راه‌اندازی. بازه زمانی disable باعث می‌شود هیچ تایمر خودکاری راه‌اندازی نشود. مقدار پیش‌فرض 30s است.

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

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

حداکثر زمانی که دستور بررسی سلامت راه‌اندازی فرصت دارد تا قبل از اینکه به‌عنوان ناموفق علامت‌گذاری شود، به پایان برسد. مقدار می‌تواند در یک قالب زمانی مانند 2m3s بیان شود. مقدار پیش‌فرض 30s است.

حداکثر زمان مجاز برای تکمیل بررسی سلامت قبل از اینکه بازه زمانی ناموفق در نظر گرفته شود. همانند start-period، این مقدار می‌تواند در قالب زمانی مانند 1m22s بیان شود. مقدار پیش‌فرض 30s است.

نکته: پایان مهلت زمانی (timeout) بررسی سلامت را به‌عنوان ناموفق علامت‌گذاری می‌کند. اگر خود دستور بررسی سلامت طولانی‌تر از timeout مشخص‌شده اجرا شود، سیگنال SIGKILL برای آن ارسال خواهد شد.

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

تنظیم نام میزبان کانتینر در داخل کانتینر.

این گزینه فقط با فضای نام خصوصی UTS یعنی --uts=private (پیش‌فرض) قابل استفاده است. اگر Pod= داده شده باشد و پاد از همان فضای نام UTS مشترک استفاده کند (پیش‌فرض)، نام میزبان پاد استفاده می‌شود. نام میزبان ارائه‌شده همچنین با استفاده از آدرس IP اصلی کانتینر به فایل /etc/hosts اضافه می‌شود (همچنین به گزینه AddHost= مراجعه کنید).

هنگامی که HostName= تنظیم نشده باشد و کانتینر از فضای نام خصوصی UTS (پیش‌فرض) استفاده کند، پادمن نام میزبان را روی ۱۲ نویسه اول شناسه کانتینر تنظیم می‌کند. نام کانتینر اختصاص‌داده‌شده با ContainerName= استفاده نمی‌شود مگر اینکه container_name_as_hostname=true در containers.conf تنظیم شده باشد.

دی‌ان‌اس شبکه پادمن نام کانتینر، شناسه کوتاه کانتینر (۱۲ نویسه اول)، و هر --hostname تنظیم‌شده به‌صورت صریح را به‌عنوان نام‌های DNS ثبت می‌کند. نام میزبان پیش‌فرض با نام مستعار شناسه کوتاه مطابقت دارد. به podman-network(1) مراجعه کنید.

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

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

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

قالب نام همانند زمانی است که به podman pull ارسال می‌شود. بنابراین، برای تضمین نسخه خاصی از ایمیج، از :tag یا خلاصه‌های دیجیتال (digests) پشتیبانی می‌کند.

حالت‌های خاص:

  • اگر name ایمیج به .image ختم شود، Quadlet از ایمیج دریافت‌شده توسط فایل .image مربوطه استفاده می‌کند و سرویس systemd تولیدشده شامل یک وابستگی به $name-image.service (یا نام سرویس تنظیم‌شده در فایل .image) خواهد بود. توجه داشته باشید که فایل .image مربوطه باید وجود داشته باشد.
  • اگر name ایمیج به .build ختم شود، Quadlet از ایمیج ساخته‌شده توسط فایل .build مربوطه استفاده می‌کند و سرویس systemd تولیدشده شامل یک وابستگی به $name-build.service خواهد بود. نکته: فایل .build مربوطه باید وجود داشته باشد.

به پادمن می‌گوید که چگونه با حجم‌های داخلی (builtin) ایمیج رفتار کند. پیش‌فرض bind است.

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

مشخص کردن یک آدرس استاتیک IPv4 برای کانتینر، برای مثال 10.88.64.128. این گزینه فقط زمانی می‌تواند استفاده شود که کانتینر تنها به یک شبکه متصل باشد - یعنی Network=network-name حداکثر یک بار استفاده شده باشد - و در صورتی که کانتینر از طریق Network=container:id به فضای نام شبکه کانتینر دیگری متصل نشده باشد. آدرس باید در محدوده آدرس‌های IP شبکه باشد (پیش‌فرض 10.88.0.0/16).

برای تعیین چندین آدرس استاتیک IP برای هر کانتینر، چندین شبکه را با استفاده از گزینه Network= تنظیم کنید که برای هر کدام یک آدرس IP استاتیک با استفاده از حالت ip آن گزینه مشخص شده باشد.

مشخص کردن یک آدرس استاتیک IPv6 برای کانتینر، برای مثال fd46:db93:aa76:ac37::10. این گزینه فقط زمانی می‌تواند استفاده شود که کانتینر تنها به یک شبکه متصل باشد - یعنی Network=network-name حداکثر یک بار استفاده شده باشد - و در صورتی که کانتینر از طریق Network=container:id به فضای نام شبکه کانتینر دیگری متصل نشده باشد. آدرس باید در محدوده آدرس‌های IPv6 شبکه باشد.

برای تعیین چندین آدرس استاتیک IPv6 برای هر کانتینر، چندین شبکه را با استفاده از گزینه Network= تنظیم کنید که برای هر کدام یک آدرس IPv6 استاتیک با استفاده از حالت ip6 آن گزینه مشخص شده باشد.

افزودن متادیتا به کانتینر.

درایور ثبت لاگ (logging driver) برای کانتینر. گزینه‌های در دسترس فعلی عبارتند از k8s-file، journald، none، passthrough و passthrough-tty، که json-file برای سازگاری با اسکریپت‌ها نام مستعار k8s-file است (پیش‌فرض journald).

دستور podman info زیر درایور پیش‌فرض ثبت لاگ سیستم را نمایش می‌دهد.

$ podman info --format '{{ .Host.LogDriver }}'
journald

درایور passthrough جریان‌های استاندارد (stdin، stdout، stderr) را به کانتینر منتقل می‌کند. این درایور با کلاینت راه دور Podman، شامل ماشین‌های مک و ویندوز (به‌جز WSL2)، و روی یک tty مجاز نیست، زیرا در برابر حملات از طریق TIOCSTI آسیب‌پذیر است.

درایور passthrough-tty مشابه passthrough است، به جز اینکه در صورت تمایل واقعی کاربر، امکان استفاده از آن روی یک TTY نیز وجود دارد.

گزینه‌های مخصوص درایور ثبت لاگ.

تنظیم پیکربندی سفارشی ثبت لاگ. مقادیر *name* زیر پشتیبانی می‌شوند:

path: مشخص کردن مسیر فایل لاگ (برای مثال LogOpt=path=/var/log/container/mycontainer.json)؛

max-size: مشخص کردن حداکثر اندازه فایل لاگ (برای مثال LogOpt=max-size=10mb)؛

tag: مشخص کردن یک برچسب لاگ سفارشی برای کانتینر (برای مثال LogOpt=tag="{{.ImageName}}". این گزینه از همان کلیدهای podman inspect --format پشتیبانی می‌کند. این گزینه در حال حاضر فقط توسط درایور لاگ journald پشتیبانی می‌شود).

label: مشخص کردن یک برچسب متنی (label) لاگ سفارشی برای کانتینر (برای مثال --log-opt label="CONTAINER_IMAGE={{.ImageName}}". این گزینه از همان کلیدهای podman inspect --format پشتیبانی می‌کند. این گزینه می‌تواند چندین بار تکرار شود. این گزینه در حال حاضر فقط توسط درایور لاگ journald پشتیبانی می‌شود).

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

محدودیت حافظه. واحد unit می‌تواند b (بایت)، k (کیبی‌بایت)، m (مبی‌بایت) یا g (گیبی‌بایت) باشد.

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

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

اتصال یک نقطه سوار کردن فایل‌سیستم (filesystem mount) به کانتینر.

حالت‌های خاص:

  • برای type=volume، اگر source به .volume ختم شود، حجم نام‌گذاری‌شده پادمن تولیدشده توسط فایل .volume مربوطه استفاده می‌شود.
  • برای type=image، اگر source به .image ختم شود، ایمیج تولیدشده توسط فایل .image مربوطه استفاده می‌شود.

در هر دو حالت، سرویس systemd تولیدشده شامل یک وابستگی به سرویس تولیدشده برای واحد مربوطه خواهد بود. نکته: فایل .volume یا .image مربوطه باید وجود داشته باشد.

انواع TYPEهای سوار کردن که در حال حاضر پشتیبانی می‌شوند عبارتند از: artifact، bind، devpts، glob، image، ramfs، tmpfs و volume.

گزینه‌های مشترک برای تمام انواع mount:

  • src، source: مشخصات مبدا سوار کردن برای bind، glob و volume. اجباری برای artifact، bind، glob و image. اختیاری برای volume؛ در صورت حذف، یک حجم ناشناس ایجاد می‌شود.
  • dst، dest، destination، target: مشخصات مقصد سوار کردن.

هنگامی که الگوهای مبدا (source globs) بدون دایرکتوری مقصد مشخص می‌شوند، فایل‌ها و پوشه‌ها با مسیر کامل خود در داخل کانتینر سوار می‌شوند. هنگامی که مقصد مشخص می‌شود، فایل‌ها و پوشه‌های منطبق با الگوی نام فایل پایه روی پوشه مقصد سوار می‌شوند. گزینه type=glob,src=/foo*,destination=/tmp/bar به موتورهای کانتینر می‌گوید که فایل‌های میزبان منطبق با /foo* را در دایرکتوری /tmp/bar/ در کانتینر سوار کنند.

گزینه‌های مخصوص type=artifact:

  • digest: اگر منبع آرتیفکت شامل چندین حباب (blob) باشد، می‌توان یک چکیده (digest) تعیین کرد تا فقط همان حباب خاص با آن دایجست سوار شود.
  • title: اگر منبع آرتیفکت شامل چندین بلاب باشد، می‌توان یک عنوان تعیین کرد که با یادداشت org.opencontainers.image.title مقایسه می‌شود.
  • name: این می‌تواند برای بازنویسی نام فایلی که در داخل کانتینر برای سوار کردن استفاده می‌کنیم به کار رود. در یک آرتیفکت با یک بلاب، اگر dst یک دایرکتوری باشد نام همان‌طور که هست استفاده می‌شود و در غیر این صورت نادیده گرفته می‌شود. با یک آرتیفکت چندبلابی، نام همراه با پسوند شاخص <name>-x استفاده خواهد شد که در آن x شاخص لایه در آرتیفکت است که از 0 شروع می‌شود.

آرگومان src شامل نام آرتیفکت است که باید از قبل به‌صورت محلی وجود داشته باشد. آرگومان dst شامل مسیر هدف است؛ اگر مسیر در کانتینر یک پوشه باشد، عنوان بلاب (یادداشت org.opencontainers.image.title) به‌عنوان نام فایل استفاده شده و به مسیر ملحق می‌شود. اگر یادداشت وجود نداشته باشد، دایجست به‌جای آن به‌عنوان نام فایل استفاده می‌شود. این منجر می‌شود همه بلاب‌های آرتیفکت در مسیر داده‌شده درون کانتینر سوار شوند.

با این حال، اگر مسیر dst یک فایل موجود در کانتینر باشد، بلاب مستقیماً روی آن سوار می‌شود. این حالت فقط زمانی کار می‌کند که آرتیفکت شامل یک تک‌بلاب باشد یا یکی از مقادیر digest یا title مشخص شده باشد.

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

گزینه‌های مخصوص type=volume:

  • ro, readonly: true یا false (پیش‌فرض در صورت عدم تعیین: false).
  • U, chown: true یا false (پیش‌فرض در صورت عدم تعیین: false). مالک و گروه حجم مبدأ را به صورت بازگشتی بر اساس UID و GID کانتینر تغییر می‌دهد.
  • subpath: فقط یک زیرمسیر مشخص درون حجم را به جای کل حجم سوار (mount) می‌کند.
  • relabel: shared, private. نقطه اتصال را به صورت بازگشتی پیمایش کرده و برچسب سیستم امنیتی (مانند SELinux) را روی هر فایل تنظیم می‌کند تا مجوزهای دسترسی از زمینه کانتینر اعطا شود. shared برچسبی اعمال می‌کند که به تمام کانتینرها مجوز می‌دهد، در حالی که private برچسبی اعمال می‌کند که تنها به این کانتینر خاص مجوز می‌دهد.
  • z, Z: به ترتیب نام اختصاری برای relabel=shared و relabel=private هستند.
  • idmap: در صورت تعیین، یک سوار شدن idmapped به فضای نام کاربری هدف در کانتینر ایجاد می‌کند. گزینه idmap تنها توسط پودمن در حالت با دسترسی ریشه (rootful) پشتیبانی می‌شود. هسته لینوکس اجازه استفاده از سیستم‌های فایل idmapped را به کاربران غیرممتاز نمی‌دهد. گزینه idmap از یک نگاشت سفارشی پشتیبانی می‌کند که می‌تواند با فضای نام کاربری مورد استفاده کانتینر متفاوت باشد. این نگاشت را می‌توان بعد از گزینه idmap به این صورت مشخص کرد: idmap=uids=0-1-10#10-11-10;gids=0-100-10. برای هر سه‌تایی، مقدار اول شروع شناسه‌های سیستم فایل پشتیبان است که به مقدار دوم روی میزبان نگاشت می‌شوند. طول این نگاشت در مقدار سوم مشخص می‌شود. محدوده‌های متعدد با # از هم جدا می‌شوند. اگر قبل از نگاشت مشخص‌شده یک '@' قرار گیرد، نگاشت نسبت به فضای نام کاربری کانتینر نسبی در نظر گرفته می‌شود. شناسه میزبان برای نگاشت به منظور لحاظ کردن موقعیت نسبی کاربر کانتینر در فضای نام کاربری کانتینر تغییر داده می‌شود.

گزینه‌های مخصوص type=image:

  • rw, readwrite: true یا false (پیش‌فرض در صورت عدم تعیین: false).
  • subpath: فقط یک مسیر مشخص درون ایمیج را به جای کل ایمیج سوار (mount) می‌کند.

گزینه‌های مخصوص bind و glob:

  • ro, readonly: true یا false (پیش‌فرض در صورت عدم تعیین: false).
  • bind-propagation: shared، slave، private، unbindable، rshared، rslave، runbindable یا rprivate (پیش‌فرض).[1] ⟨#Footnote1⟩ همچنین صفحه راهنمای mount(2) را ببینید.
  • bind-nonrecursive: سوار کردن اتصالی (bind mount) را به صورت بازگشتی تنظیم نمی‌کند. به طور پیش‌فرض بازگشتی است.
  • relabel: shared, private. نقطه اتصال را به صورت بازگشتی پیمایش کرده و برچسب سیستم امنیتی (مانند SELinux) را روی هر فایل تنظیم می‌کند تا مجوزهای دسترسی از زمینه کانتینر اعطا شود. shared برچسبی اعمال می‌کند که به تمام کانتینرها مجوز می‌دهد، در حالی که private برچسبی اعمال می‌کند که تنها به این کانتینر خاص مجوز می‌دهد.
  • z, Z: به ترتیب نام اختصاری برای relabel=shared و relabel=private هستند.
  • idmap: در صورت تعیین، یک سوار شدن idmapped به فضای نام کاربری هدف در کانتینر ایجاد می‌کند. گزینه idmap تنها توسط پودمن در حالت با دسترسی ریشه (rootful) پشتیبانی می‌شود. هسته لینوکس اجازه استفاده از سیستم‌های فایل idmapped را به کاربران غیرممتاز نمی‌دهد. گزینه idmap از یک نگاشت سفارشی پشتیبانی می‌کند که می‌تواند با فضای نام کاربری مورد استفاده کانتینر متفاوت باشد. این نگاشت را می‌توان بعد از گزینه idmap به این صورت مشخص کرد: idmap=uids=0-1-10#10-11-10;gids=0-100-10. برای هر سه‌تایی، مقدار اول شروع شناسه‌های سیستم فایل پشتیبان است که به مقدار دوم روی میزبان نگاشت می‌شوند. طول این نگاشت در مقدار سوم مشخص می‌شود. محدوده‌های متعدد با # از هم جدا می‌شوند. اگر قبل از نگاشت مشخص‌شده یک '@' قرار گیرد، نگاشت نسبت به فضای نام کاربری کانتینر نسبی در نظر گرفته می‌شود. شناسه میزبان برای نگاشت به منظور لحاظ کردن موقعیت نسبی کاربر کانتینر در فضای نام کاربری کانتینر تغییر داده می‌شود.
  • U, chown: true یا false (پیش‌فرض در صورت عدم تعیین: false). مالک و گروه حجم مبدأ را به صورت بازگشتی بر اساس UID و GID کانتینر تغییر می‌دهد.
  • no-dereference: پیوندهای نمادین (symlinks) را دنبال نمی‌کند، بلکه مبدأ پیوند را در مقصد اتصال کپی می‌کند.

گزینه‌های مخصوص type=tmpfs و ramfs:

  • ro, readonly: true یا false (پیش‌فرض در صورت عدم تعیین: false).
  • tmpfs-size: اندازه نقطه اتصال tmpfs/ramfs بر حسب بایت. در لینوکس به طور پیش‌فرض نامحدود است.
  • tmpfs-mode: حالت هشت‌هشتی فایل (octal file mode) مربوط به tmpfs/ramfs (برای مثال 700 یا 0700).
  • tmpcopyup: فعال‌سازی کپی به بالا (copyup) از دایرکتوری ایمیج در همان مکان به tmpfs/ramfs. به طور پیش‌فرض استفاده می‌شود.

هنگامی که مقصد tmpfs درون یک حجم یا اتصال اتصالی (bind mount) قرار دارد، فایل‌های اتصال والد نیز در tmpfs کپی می‌شوند تا محتوای والد قابل مشاهده باقی بماند. از notmpcopyup برای سوار کردن یک tmpfs خالی استفاده کنید که زیردرخت اتصال والد را بپوشاند (shadow کند).

  • noatime: به‌روزرسانی زمان‌های دسترسی فایل را هنگام خوانده شدن فایل غیرفعال می‌کند.
  • notmpcopyup: کپی کردن فایل‌ها از ایمیج به tmpfs/ramfs را غیرفعال می‌کند.

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

•
U, chown: true یا false (پیش‌فرض در صورت عدم تعیین: false). گزینه‌های uid و gid را برای سیستم فایل tmpfs بر اساس UID و GID کانتینر تنظیم می‌کند. این عمل بازگشتی نیست.

گزینه‌های مخصوص type=devpts:

  • uid: شناسه عددی UID مالک فایل (پیش‌فرض: 0).
  • gid: شناسه عددی GID مالک فایل (پیش‌فرض: 0).
  • mode: ماسک دسترسی هشت‌هشتی برای فایل (پیش‌فرض: 600).
  • max: حداکثر تعداد PTYها (پیش‌فرض: 1048576).

Examples:

  • type=bind,source=/path/on/host,destination=/path/in/container
  • type=bind,src=/path/on/host,dst=/path/in/container,relabel=shared
  • type=bind,src=/path/on/host,dst=/path/in/container,relabel=shared,U=true
  • type=bind,src=/path/on/host,dst=/path/in/container,idmap
  • type=bind,src=/path/on/host,dst=/path/in/container,idmap=uids=0-1-10;gids=0-100-10
  • type=devpts,destination=/dev/pts
  • type=glob,src=/usr/lib/libfoo*,destination=/usr/lib,ro=true
  • type=image,source=fedora,destination=/fedora-image,rw=true
  • type=ramfs,tmpfs-size=512M,destination=/path/in/container
  • type=tmpfs,tmpfs-size=512M,destination=/path/in/container
  • type=tmpfs,destination=/path/in/container,noswap
  • type=artifact,src=quay.io/libpod/testartifact:20250206-single,dst=/data
  • type=artifact,src=quay.io/libpod/testartifact:20250206-multi,dst=/data,title=test1
  • type=volume,destination=/path/in/container
  • type=volume,src=test_vol,dst=/data,subpath=/code/docs

تنظیم حالت شبکه برای کانتینر.

موارد خاص:

  • اگر name شبکه با .network خاتمه یابد، یک شبکه پودمن با نام systemd-$name استفاده می‌شود، و سرویس systemd تولیدشده شامل وابستگی به $name-network.service خواهد بود. چنین شبکه‌ای می‌تواند به طور خودکار با استفاده از یک فایل کوادلت $name.network ایجاد شود. توجه: فایل .network متناظر باید وجود داشته باشد.
  • اگر name با .container خاتمه یابد، کانتینر از پشته شبکه کانتینر دیگری که توسط $name.container ایجاد شده مجدداً استفاده خواهد کرد. سرویس systemd تولیدشده شامل وابستگی به $name.service خواهد بود. توجه: فایل .container متناظر باید وجود داشته باشد.

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

•
bridge[:OPTIONS,...]: یک پشته شبکه روی پل (bridge) پیش‌فرض ایجاد می‌کند. این مقدار پیش‌فرض برای کانتینرهای با دسترسی ریشه (rootful) است. امکان تعیین این گزینه‌های اضافی وجود دارد:
  • alias=name: افزودن نام مستعار در سطح شبکه برای کانتینر.
  • ip=IPv4: تعیین یک آدرس IPv4 ایستا برای این کانتینر.
  • ip6=IPv6: تعیین یک آدرس IPv6 ایستا برای این کانتینر.
  • mac=MAC: تعیین یک آدرس MAC ایستا برای این کانتینر.
  • interface_name=name: تعیین نام برای رابط شبکه ایجادشده در داخل کانتینر.
  • host_interface_name=name: تعیین نام برای رابط شبکه ایجادشده در خارج از کانتینر.
هر گزینه دیگری بدون اعتبارسنجی مستقیماً به netavark ارسال می‌شود. این امر می‌تواند برای ارسال آرگومان‌ها به پلاگین‌های netavark مفید باشد.

برای شبکه‌های bridge بدون ریشه (rootless)، هدایت پورت (port forwarding) به طور پیش‌فرض از rootlessport استفاده می‌کند. تنظیم rootless_port_forwarder="pasta" در بخش [network] از containers.conf(5) روش هدایت را به هدایت در سطح هسته pasta (از طریق pesto) تغییر می‌دهد، که آدرس IP مبدأ اصلی کلاینت را درون کانتینر حفظ می‌کند. این گزینه آزمایشی است و رفتار آن ممکن است تغییر کند.

برای مثال، جهت تعیین یک آدرس IPv4 ایستا و یک آدرس mac ایستا، از --network bridge:ip=10.88.0.10,mac=44:33:22:11:00:99 استفاده کنید.

  • <network name or ID>[:OPTIONS,...]: اتصال به یک شبکه تعریف‌شده توسط کاربر؛ این مقدار، نام شبکه یا شناسه حاصل از یک شبکه ایجادشده با podman network create است. امکان مشخص کردن همان گزینه‌های شرح داده شده در حالت bridge در بالا وجود دارد. برای مشخص کردن شبکه‌های بیشتر، چندین بار از گزینه --network استفاده کنید.
    برای سازگاری با نسخه‌های پیشین، همچنین می‌توان شبکه‌ها را با کاما در اولین آرگومان --network مشخص کرد، با این حال این کار مانع از استفاده شما از گزینه‌های شرح‌داده‌شده در بخش bridge در بالا می‌شود.
  • none: یک فضای نام شبکه برای کانتینر ایجاد می‌کند اما رابط‌های شبکه‌ای برای آن پیکربندی نمی‌کند، در نتیجه کانتینر هیچ‌گونه اتصال شبکه‌ای نخواهد داشت.
  • container:id: استفاده مجدد از پشته شبکه یک کانتینر دیگر.
  • host: استفاده از فضای نام شبکه میزبان برای کانتینر به جای ایجاد یک فضای نام ایزوله. هشدار: این کار به کانتینر دسترسی کامل به سوکت‌های انتزاعی دامین یونیکس (abstract Unix domain sockets) و سوکت‌های TCP/UDP مقید به localhost می‌دهد. از آنجا که این سازوکارها اغلب برای جلوگیری از دسترسی به سرویس‌های حساس سیستم و ایزوله‌سازی آنها از دسترسی نهادهای خارجی استفاده می‌شوند، به‌کارگیری این گزینه می‌تواند یک آسیب‌پذیری امنیتی تلقی شود.
  • ns:path: مسیر فضای نام شبکه‌ای که باید به آن متصل شد.
  • private: یک فضای نام جدید برای کانتینر ایجاد می‌کند. این گزینه برای کانتینرهای با دسترسی ریشه (rootful) از حالت bridge و برای کانتینرهای بدون ریشه (rootless) از pasta استفاده می‌کند.
  • pasta[:OPTIONS,...]: استفاده از pasta(1) برای ایجاد یک پشته شبکه در حالت کاربری (user-mode).
    این گزینه حالت پیش‌فرض برای کانتینرهای بدون ریشه (rootless) است و تنها در حالت بدون ریشه پشتیبانی می‌شود.
    به طور پیش‌فرض، آدرس‌ها و مسیرهای IPv4 و IPv6، و همچنین نام رابط پاد از میزبان کپی می‌شوند. هدایت پورت آدرس IP مبدأ اصلی را حفظ می‌کند. گزینه‌های شرح داده شده در pasta(1) را می‌توان به صورت آرگومان‌های جداشده با کاما مشخص کرد.
    از نظر گزینه‌های pasta(1)، گزینه --config-net به طور پیش‌فرض برای پیکربندی شبکه در هنگام راه‌اندازی کانتینر ارائه می‌شود، و --no-map-gw نیز به طور پیش‌فرض فرض می‌شود تا از دسترسی مستقیم کانتینر به میزبان با استفاده از آدرس درگاه (gateway) جلوگیری شود. مورد دوم را می‌توان با ارسال --map-gw در گزینه‌های مخصوص pasta بازنویسی کرد (با وجود اینکه یک گزینه واقعی در pasta(1) نیست).
    برای ادغام بهتر با مدیریت DNS، مقدار --dns-forward 169.254.1.1 به طور پیش‌فرض ارسال می‌شود، و این آدرس به عنوان اولین حل‌کننده به resolv.conf(5) اضافه می‌شود. در صورتی که نیاز به استفاده از آدرس IP متفاوتی باشد، می‌توان --dns-forward را به صورت صریح ارسال کرد.
    برای فعال شدن ورودی host.containers.internal در /etc/hosts و اجازه برقراری ارتباط با میزبان، --map-guest-addr 169.254.1.2 به طور پیش‌فرض ارسال می‌شود. مجدداً می‌توان آن را به طور صریح برای انتخاب آدرس IP دیگری تنظیم کرد.
    همچنین، در صورتی که هیچ هدایت پورت TCP یا UDP از میزبان به کانتینر پیکربندی نشده باشد (از طریق --publish پودمن یا با ارسال مستقیم گزینه‌های -t/-u در pasta)، به ترتیب مقادیر -t none و -u none ارسال می‌شوند تا هدایت خودکار پورت بر اساس پورت‌های متصل غیرفعال شود. به طور مشابه، -T none و -U none برای غیرفعال کردن همین عملکرد از کانتینر به میزبان داده می‌شوند.
    تمامی گزینه‌ها را می‌توان در containers.conf(5) نیز تنظیم کرد؛ کلید pasta_options را در زیر بخش network در آن فایل ببینید.
    چند مثال:
  • pasta:--map-gw: اجازه دسترسی مستقیم کانتینر به میزبان با استفاده از آدرس درگاه (gateway).
  • pasta:--mtu,1500: تعیین MTU معادل 1500 بایت برای رابط tap در کانتینر.
  • pasta:--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: غیرفعال کردن IPv6، تخصیص 10.0.2.0/24 به رابط tap0 در کانتینر، همراه با درگاه 10.0.2.3، فعال‌سازی ارسال‌کننده DNS قابل دسترس در 10.0.2.3، تنظیم MTU روی 1500 بایت، غیرفعال کردن پشتیبانی از NDP، DHCPv6 و DHCP.
  • pasta:-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: همانند بالا، اما باقی گذاشتن MTU روی 65520 بایت.
  • pasta:-t,auto,-u,auto,-T,auto,-U,auto: فعال‌سازی هدایت خودکار پورت بر اساس پورت‌های متصل مشاهده‌شده از هر دو طرف میزبان و کانتینر.
  • pasta:-T,5201: فعال‌سازی هدایت پورت TCP شماره 5201 از کانتینر به میزبان، با استفاده از رابط loopback به جای رابط tap جهت بهبود کارایی.

افزودن نام مستعار در سطح شبکه برای کانتینر، و تنظیم این نام مستعار برای تمامی شبکه‌هایی که کانتینر به آنها می‌پیوندد. برای تنظیم یک نام فقط برای یک شبکه خاص، از گزینه alias به همان صورت شرح داده شده در زیر گزینه --network استفاده کنید. اگر شبکه دارای DNS فعال باشد (podman network inspect -f {{.DNSEnabled}} <name>)، این نام‌های مستعار را می‌توان برای تحلیل نام در شبکه مذکور استفاده کرد. این گزینه را می‌توان چندین بار مشخص کرد.

در صورت فعال بودن، فرآیندهای کانتینر را از کسب امتیازات و دسترسی‌های اضافی از طریق مواردی مانند setuid و قابلیت‌های فایل (file capabilities) منع می‌کند.

به طور پیش‌فرض، پودمن به گونه‌ای اجرا می‌شود که دستور اعلان راه‌اندازی systemd توسط زمان اجرای کانتینر مدیریت می‌شود. به عبارت دیگر، سرویس زمانی شروع‌شده تلقی می‌شود که زمان اجرای کانتینر، فرآیند فرزند را در کانتینر راه‌اندازی کند. با این حال، اگر برنامه کاربردی کانتینر از sd_notify پشتیبانی کند، تنظیم Notify روی true جزئیات اعلان را به کانتینر ارسال می‌کند و به آن اجازه می‌دهد راه‌اندازی خود را شخصاً اعلان کند.

علاوه بر این، تنظیم Notify روی healthy اعلان‌های راه‌اندازی را تا زمانی که کانتینر طبق بررسی‌های سلامت پودمن به عنوان سالم (healthy) نشانه‌گذاری شود به تعویق می‌اندازد. توجه داشته باشید که این امر نیازمند تنظیم بررسی سلامت کانتینر است؛ برای اطلاعات بیشتر گزینه HealthCmd را ببینید.

تنظیم حد مجاز PIDهای کانتینر. برای نامحدود بودن تعداد PIDهای کانتینر مقدار را برابر -1 قرار دهید. پیش‌فرض در سیستم‌هایی که از کنترل‌کننده cgroup موسوم به "pids" پشتیبانی می‌کنند برابر 2048 است.

یک واحد کوادلت .pod را مشخص می‌کند تا کانتینر به آن متصل شود. مقدار باید به قالب <name>.pod باشد و واحد .pod باید وجود داشته باشد.

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

این کلید شامل فهرستی از آرگومان‌هاست که مستقیماً به انتهای دستور podman در فایل تولیدشده ارسال می‌شوند. از این گزینه می‌توان برای دسترسی به قابلیت‌های پودمن که در غیر این صورت توسط تولیدکننده (generator) پشتیبانی نمی‌شوند استفاده کرد. از آنجا که مولد از تداخلات غیرمنتظره‌ای که ممکن است توسط این آرگومان‌ها ایجاد شود آگاه نیست، استفاده از این گزینه توصیه نمی‌شود.

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

این کلید می‌تواند چندین بار درج شود.

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

هر دو مقدار hostPort و containerPort می‌توانند به عنوان محدوده‌ای از پورت‌ها تعیین شوند. هنگام مشخص کردن محدوده برای هر دو، تعداد پورت‌های کانتینر در محدوده باید با تعداد پورت‌های میزبان در محدوده مطابقت داشته باشد.

اگر hostIP برابر 0.0.0.0 باشد، تنها آدرس‌های IPv4 مقید می‌شوند؛ اگر روی [::] تنظیم شود، تنها آدرس‌های IPv6 مقید می‌شوند. در سایر موارد، دقیقاً همان آدرس IP داده‌شده مقید خواهد شد. اگر hostIP اصلاً تنظیم نشده باشد، پورت روی تمام آدرس‌های IP میزبان، هم v4 و هم v6 (در صورت امکان)، مقید می‌شود.

مقدار پیش‌فرض hostIP را می‌توان در containers.conf(5) با استفاده از گزینه default_host_ips در زیر بخش [network] پیکربندی کرد. این گزینه یک آرایه را می‌پذیرد تا بتوان چندین آدرس IP قیدشده را مشخص نمود. برای مثال، تنظیم default_host_ips = ["127.0.0.1", "::1"] باعث می‌شود پورت به ترتیب روی آدرس localhost نسخه ipv4 و ipv6 منتشر شود. یک hostIP صریح که در دستور مشخص شود، همیشه بر گزینه پیکربندی ارجحیت دارد.

به طور پیش‌فرض، پودمن پورت‌های TCP را منتشر می‌کند. برای انتشار پورت UDP به جای آن، udp را به عنوان پروتکل مشخص کنید. برای انتشار هر دو نوع پورت TCP و UDP، گزینه --publish را دو بار با پروتکل‌های tcp و udp تنظیم کنید. کانتینرهای با دسترسی ریشه (rootful) می‌توانند پورت‌ها را با استفاده از پروتکل sctp نیز منتشر کنند.

نیازی به تعیین حتمی پورت میزبان نیست (مانند podman run -p 127.0.0.1::80). اگر تعیین نشود، یک پورت روی میزبان به صورت تصادفی به پورت کانتینر اختصاص داده می‌شود.

برای مشاهده نگاشت واقعی از podman port استفاده کنید: podman port $CONTAINER $CONTAINERPORT.

انتشار پورت تنها برای کانتینرهایی پشتیبانی می‌شود که از فضای نام شبکه اختصاصی خود از طریق شبکه‌های bridge یا حالت شبکه pasta استفاده می‌کنند.

برای شبکه‌های bridge بدون ریشه (rootless)، هدایت پورت به طور پیش‌فرض از rootlessport استفاده می‌کند، که یک پراکسی فضای کاربری است و IP مبدأ کلاینت را حفظ نمی‌کند. تنظیم rootless_port_forwarder="pasta" در بخش [network] از containers.conf(5) روش هدایت را به هدایت در سطح هسته pasta از طریق pesto تغییر می‌دهد، که آدرس IP اصلی کلاینت را درون کانتینر حفظ می‌کند. این گزینه آزمایشی است و رفتار آن ممکن است تغییر کند.

سیاست دریافت (pull) ایمیج. مقدار پیش‌فرض missing است.

  • always: همیشه ایمیج را دریافت می‌کند و در صورت عدم موفقیت در دریافت، خطا صادر می‌کند.
  • missing: فقط زمانی که ایمیج در فضای ذخیره‌سازی محلی کانتینرها موجود نباشد آن را دریافت می‌کند. اگر هیچ ایمیجی یافت نشود و دریافت ناموفق باشد، خطا صادر می‌کند.
  • never: هرگز ایمیج را دریافت نمی‌کند، بلکه از ایمیج موجود در فضای ذخیره‌سازی محلی کانتینرها استفاده می‌کند. اگر هیچ ایمیجی یافت نشود، خطا صادر می‌کند.
  • newer: اگر ایمیج موجود در مخزن (registry) جدیدتر از نسخه موجود در فضای ذخیره‌سازی محلی کانتینرها باشد، آن را دریافت می‌کند. اگر چکیده‌ها (digests) متفاوت باشند، ایمیج جدیدتر تلقی می‌شود. مقایسه مهر زمانی مستعد خطاست. اگر یک ایمیج محلی یافت شود، خطاهای دریافت نادیده گرفته می‌شوند.

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

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

هنگام اجرای کانتینرهای --read-only، یک tmpfs خواندنی-نوشتنی را روی /dev، /dev/shm، /run، /tmp و /var/tmp سوار می‌کند. مقدار پیش‌فرض true است.

--read-only --read-only-tmpfs / /run, /tmp, /var/tmp
true true r/o r/w
true false r/o r/o
false false r/w r/w
false true r/w r/w

هنگامی که ReadOnly=true و ReadOnlyTmpfs=true باشد، tmpfsهای اضافی روی دایرکتوری‌های /tmp، /run و /var/tmp سوار می‌شوند.

هنگامی که ReadOnly=true و ReadOnlyTmpfs=false باشد، مسیرهای /dev و /dev/shm به صورت فقط‌خواندنی نشانه‌گذاری می‌شوند و هیچ tmpfsای روی /tmp، /run و /var/tmp سوار نمی‌شود. این دایرکتوری‌ها از ایمیج زیرین نمایان می‌شوند، به این معنی که به طور پیش‌فرض فقط‌خواندنی هستند. این امر کانتینر را کاملاً فقط‌خواندنی می‌کند. هیچ دایرکتوری قابل نوشتنی در داخل کانتینر وجود نخواهد داشت. در این حالت دایرکتوری‌های قابل نوشتن باید از طریق حجم‌ها یا اتصالات خارجی اضافه شوند.

به طور پیش‌فرض، هنگامی که ReadOnly=false باشد، دایرکتوری‌های /dev و /dev/shm خواندنی-نوشتنی هستند و /tmp، /run و /var/tmp نیز دایرکتوری‌های خواندنی-نوشتنی برگرفته از ایمیج کانتینر هستند.

افزودن یک خط ExecReload= به بخش Service که دستور podman exec را با این دستور در این کانتینر اجرا می‌کند.

برای بارگذاری مجدد سرویس، دستور systemctl reload <Service> را اجرا کنید.

این گزینه مانعه‌الجمع با ReloadSignal است.

افزودن یک خط ExecReload= به بخش Service که دستور podman kill را با این سیگنال اجرا می‌کند، که سیگنال را به فرآیند اصلی کانتینر ارسال می‌نماید.

برای بارگذاری مجدد سرویس، دستور systemctl reload <Service> را اجرا کنید.

این گزینه مانعه‌الجمع با ReloadCmd است.

تعداد دفعات تلاش مجدد برای دریافت (pull) یا ارسال (push) ایمیج‌ها بین مخزن (registry) و فضای ذخیره‌سازی محلی در صورت بروز خطا. مقدار پیش‌فرض 3 است.

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

در صورت تعیین، اولین آرگومان به یک کانتینر استخراج‌شده (exploded container) روی سیستم فایل اشاره دارد.

این گزینه با گزینه Image در تعارض است.

این گزینه برای اجرای کانتینر بدون نیاز به مدیریت ایمیج مفید است؛ فرض می‌شود rootfs کانتینر به صورت خارجی مدیریت می‌شود.

Overlay Rootfs Mounts

فلگ :O به پودمن می‌گوید که دایرکتوری حاصل از مسیر rootfs را به عنوان فضای ذخیره‌سازی با استفاده از overlay file system سوار کند. فرآیندهای کانتینر می‌توانند محتوای درون نقطه اتصال را تغییر دهند که در فضای ذخیره‌سازی کانتینر در یک دایرکتوری جداگانه ذخیره می‌شود. در اصطلاحات overlay، دایرکتوری مبدأ لایه زیرین (lower) است، و دایرکتوری ذخیره‌سازی کانتینر لایه زبرین (upper) است. تغییرات اعمال‌شده در نقطه اتصال با اتمام اجرای کانتینر نابود می‌شوند، مشابه زمانی که یک نقطه اتصال tmpfs پیاده (unmount) می‌شود.

نکته: در سیستم‌های مجهز به SELinux، مسیر rootfs نیازمند برچسب صحیح است، که به طور پیش‌فرض unconfined_u:object_r:container_file_t:s0 می‌باشد.

idmap

در صورت تعیین idmap، یک سوار شدن idmapped به فضای نام کاربری هدف در کانتینر ایجاد می‌شود. گزینه idmap از یک نگاشت سفارشی پشتیبانی می‌کند که می‌تواند با فضای نام کاربری مورد استفاده کانتینر متفاوت باشد. این نگاشت را می‌توان بعد از گزینه idmap به این صورت مشخص کرد: idmap=uids=0-1-10#10-11-10;gids=0-100-10. برای هر سه‌تایی، مقدار اول شروع شناسه‌های سیستم فایل پشتیبان است که به مقدار دوم روی میزبان نگاشت می‌شوند. طول این نگاشت در مقدار سوم داده می‌شود. محدوده‌های متعدد با # از هم جدا می‌شوند.

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

تنظیم نمایه seccomp مورد استفاده در کانتینر. در صورت عدم تنظیم، نمایه پیش‌فرض پودمن استفاده می‌شود. مقدار را برابر مسیر یک فایل JSON یا unconfined قرار دهید تا فیلترهای seccomp غیرفعال شوند.

اعطای دسترسی به یک سکرت (راز/داده محرمانه) به کانتینر. می‌تواند چندین بار مشخص شود.

یک سکرت، بلوکی از داده‌های حساس است که کانتینر در زمان اجرا به آن نیاز دارد اما در ایمیج یا در سیستم کنترل نسخه ذخیره نمی‌شود، مانند نام‌های کاربری و گذرواژه‌ها، گواهی‌ها و کلیدهای TLS، کلیدهای SSH یا سایر رشته‌های مهم عمومی یا محتوای باینری (تا سقف اندازه 512 کیلوبایت).

هنگامی که سکرت‌ها از نوع mount مشخص شوند، سکرت‌ها هنگام ایجاد کانتینر کپی شده و درون کانتینر سوار می‌شوند. هنگامی که سکرت‌ها از نوع env مشخص شوند، سکرت به عنوان یک متغیر محیطی درون کانتینر تنظیم می‌شود. سکرت‌ها در زمان ایجاد کانتینر درون کانتینر نوشته می‌شوند، و اصلاح سکرت با استفاده از دستورات podman secret پس از ایجاد کانتینر بر سکرت داخل کانتینر تأثیر می‌گذارد.

سکرت‌ها و محل ذخیره‌سازی آنها با استفاده از دستور podman secret مدیریت می‌شوند.

گزینه‌های Secret

  • type=mount|env : نحوه ارائه سکرت به کانتینر.
    mount سکرت را به عنوان یک فایل درون کانتینر سوار می‌کند.
    env سکرت را به عنوان یک متغیر محیطی در معرض کانتینر قرار می‌دهد.
    پیش‌فرض برابر mount است.
  • target=target : هدف سکرت.
    برای سکرت‌های سوارشده (mounted)، این مقدار مسیر سکرت درون کانتینر است.
    اگر یک مسیر کامل ارائه شود، سکرت در همان مکان سوار می‌شود.
    در غیر این صورت، سکرت به
    /run/secrets/target برای کانتینرهای لینوکس یا
    /var/run/secrets/target برای کانتینرهای FreeBSD سوار می‌شود.
    اگر هدف تنظیم نشده باشد، سکرت به طور پیش‌فرض در /run/secrets/secretname سوار می‌شود.
    برای سکرت‌های env، این مقدار کلید متغیر محیطی است. پیش‌فرض برابر secretname است.
  • uid=0 : شناسه UID سکرت. پیش‌فرض برابر 0 است. فقط برای سکرت‌های نوع mount.
  • gid=0 : شناسه GID سکرت. پیش‌فرض برابر 0 است. فقط برای سکرت‌های نوع mount.
  • mode=0 : حالت (mode) سکرت. پیش‌فرض برابر 0444 است. فقط برای سکرت‌های نوع mount.

مثال‌ها

سوار کردن در /my/location/mysecret با UID برابر 1:

--secret mysecret,target=/my/location/mysecret,uid=1

سوار کردن در /run/secrets/customtarget با mode برابر 0777:

--secret mysecret,target=customtarget,mode=0777

ایجاد یک متغیر محیطی سکرت با نام ENVSEC:

--secret mysecret,type=env,target=ENVSEC

غیرفعال کردن تفکیک برچسب (label separation) برای کانتینر.

تنظیم نوع برچسب فایل برای فایل‌های کانتینر.

تنظیم سطح برچسب فرآیند برای فرآیندهای کانتینر.

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

تنظیم نوع برچسب فرآیند برای فرآیندهای کانتینر.

اندازه /dev/shm. یک unit می‌تواند b (بایت)، k (کیبی‌بایت)، m (مبی‌بایت) یا g (گیبی‌بایت) باشد. اگر یکا (واحد) ذکر نشود، سیستم از بایت استفاده می‌کند. اگر اندازه ذکر نشود، مقدار پیش‌فرض 64m است. هنگامی که size برابر 0 باشد، هیچ محدودیتی روی میزان حافظه مورد استفاده کانتینر برای IPC وجود نخواهد داشت. این گزینه با --ipc=host در تعارض است.

راه‌اندازی کانتینر پس از ایجاد پاد مرتبط. پیش‌فرض برابر true است.

اگر true باشد، کانتینر در کنار پاد شروع/متوقف/بازراه‌اندازی خواهد شد.

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

توجه: کانتینر همچنان می‌تواند با پیکربندی بخش [Install] به صورت دستی یا از طریق یک هدف (target) راه‌اندازی شود. در هر حال، پاد در صورت نیاز راه‌اندازی خواهد شد.

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

مهلت زمانی برای توقف کانتینر. پیش‌فرض 10 است. اتصالات راه دور از containers.conf محلی برای مقادیر پیش‌فرض استفاده می‌کنند.

نکته: این مقدار باید کمتر از مهلت زمانی واقعی واحد systemd باشد تا اطمینان حاصل شود که دستور podman rm توسط systemd متوقف (kill) نمی‌شود.

اجرای کانتینر در یک فضای نام کاربری جدید با استفاده از نگاشت دارای name در فایل /etc/subgid. هنگام اجرا در حالت بدون ریشه (rootless)، کاربر برای استفاده از نگاشت به مجوزهای لازم نیاز دارد. به subgid(5) مراجعه کنید. این فلگ با گزینه‌های UserNS= و GIDMap= در تعارض است. همراه با GIDMap= به گونه‌ای عمل می‌کند که گویی GIDMap= با تمام نگاشت‌های گروه name در /etc/subgid ارسال شده است.

اجرای کانتینر در یک فضای نام کاربری جدید با استفاده از نگاشت دارای name در فایل /etc/subuid. هنگام اجرا در حالت بدون ریشه (rootless)، کاربر برای استفاده از نگاشت به مجوزهای لازم نیاز دارد. به subuid(5) مراجعه کنید. این فلگ با گزینه‌های UserNS= و UIDMap= در تعارض است. همراه با UIDMap= به گونه‌ای عمل می‌کند که گویی UIDMap= با تمام نگاشت‌های کاربر name در /etc/subuid ارسال شده است.

پیکربندی پارامترهای فضای نام هسته در زمان اجرا.

برای فضای نام IPC، مقادیر sysctl زیر مجاز هستند:

  • kernel.msgmax
  • kernel.msgmnb
  • kernel.msgmni
  • kernel.sem
  • kernel.shmall
  • kernel.shmmax
  • kernel.shmmni
  • kernel.shm_rmid_forced
  • مقادیر Sysctl که با fs.mqueue.* شروع می‌شوند

توجه: در صورت استفاده از گزینه --ipc=host، مقادیر sysctl بالا مجاز نیستند.

برای فضای نام شبکه، تنها مقادیر sysctl که با net.* شروع می‌شوند مجاز هستند.

توجه: در صورت استفاده از گزینه --network=host، مقادیر sysctl بالا مجاز نیستند.

تنظیم منطقه زمانی در کانتینر. این فلگ مناطق زمانی مبتنی بر منطقه جغرافیایی، زمان GMT، و همچنین local را می‌پذیرد که منطقه زمانی درون کانتینر را مطابق با دستگاه میزبان تنظیم می‌کند. برای مناطق زمانی معتبر به /usr/share/zoneinfo/ مراجعه کنید. اتصالات راه دور از containers.conf محلی برای مقادیر پیش‌فرض استفاده می‌کنند.

ایجاد یک نقطه اتصال tmpfs.

سوار کردن یک سیستم فایل موقت (tmpfs) در یک کانتینر، برای مثال:

$ podman podman-container.unit.5.md.in -d --tmpfs /tmp:rw,size=787448k,mode=1777 my_image

این دستور یک tmpfs را در مسیر /tmp درون کانتینر سوار می‌کند. گزینه‌های سوار کردن پشتیبانی‌شده همان فلگ‌های پیش‌فرض سوار کردن لینوکس هستند. اگر هیچ گزینه‌ای مشخص نشود، سیستم از گزینه‌های زیر استفاده می‌کند: rw,noexec,nosuid,nodev.

به طور پیش‌فرض، پودمن ویژگی tmpcopyup را روی اتصالات tmpfs فعال می‌کند، که محتویات دایرکتوری ایمیج زیرین را قبل از سوار کردن در tmpfs کپی می‌کند. این امر همچنین در مواردی که مقصد tmpfs درون یک حجم یا bind mount باشد صدق می‌کند: فایل‌های نقطه اتصال والد در tmpfs کپی می‌شوند، بنابراین محتوای والد قابل مشاهده باقی می‌ماند. برای سوار کردن یک tmpfs خالی که زیردرخت یک اتصال والد را بپوشاند (shadow کند)، از گزینه notmpcopyup استفاده کنید:

$ podman podman-container.unit.5.md.in --volume myvolume:/data --tmpfs /data/sub:notmpcopyup my_image

اجرای کانتینر در یک فضای نام کاربری جدید با استفاده از نگاشت UID ارائه‌شده. این گزینه با گزینه‌های UserNS= و SubUIDMap= در تعارض است. این گزینه راهکاری برای نگاشت شناسه‌های UID میزبان به UIDهای کانتینر ارائه می‌دهد. می‌توان آن را چندین بار برای نگاشت محدوده‌های مختلف ارسال کرد.

مقادیر ممکن برای flags اختیاری در ادامه این صفحه بررسی شده‌اند. مقدار amount اختیاری است و در صورت عدم تعیین، برابر 1 فرض می‌شود.

مقدار from_uid بر اساس کاربری است که دستور را اجرا می‌کند؛ چه کاربران با دسترسی ریشه (rootful) و چه کاربران بدون ریشه (rootless).

  • کاربر ریشه (rootful): [flags]container_uid:host_uid[:amount]
  • کاربر بدون ریشه (rootless): [flags]container_uid:intermediate_uid[:amount]

Rootful mappings

هنگامی که podman توسط یک کاربر دارای امتیاز فراخوانی می‌شود، گزینه UIDMap= به عنوان یک نگاشت مستقیم بین UIDهای میزبان و UIDهای کانتینر عمل می‌کند.

host UID -> container UID

مقدار amount تعداد UIDهای متوالی که نگاشت می‌شوند را مشخص می‌کند. اگر به عنوان نمونه مقدار amount برابر با 4 باشد، نگاشت به شکل زیر خواهد بود:

host UID container UID
from_uid container_uid
from_uid + 1 container_uid + 1
from_uid + 2 container_uid + 2
from_uid + 3 container_uid + 3

Rootless mappings

هنگامی که podman توسط یک کاربر فاقد امتیاز (یعنی در حال اجرای بدون ریشه) فراخوانی می‌شود، مقدار from_uid به عنوان یک «UID واسط» تفسیر می‌گردد. در حالت بدون ریشه، UIDهای میزبان به طور مستقیم به UIDهای کانتینر نگاشت نمی‌شوند. در عوض نگاشت طی دو مرحله انجام می‌شود:

host UID -> intermediate UID -> container UID

گزینه UIDMap= تنها بر مرحله دوم نگاشت اثر می‌گذارد.

مرحله نخست نگاشت توسط پادمن بر اساس محتوای فایل /etc/subuid و UID کاربری که پادمن را فراخوانی کرده تعیین می‌شود.

مرحله اول نگاشت:

host UID intermediate UID
UID for Podman user 0
1st subordinate UID 1
2nd subordinate UID 2
3rd subordinate UID 3
nth subordinate UID n

برای اینکه بتوان از UIDهای واسط بزرگ‌تر از صفر استفاده کرد، کاربر باید UIDهای فرعی پیکربندی‌شده در /etc/subuid داشته باشد. subuid(5) را ببینید.

مرحله دوم نگاشت با UIDMap= پیکربندی می‌شود.

اگر به عنوان مثال amount برابر با 5 باشد، مرحله دوم نگاشت به صورت زیر خواهد بود:

intermediate UID container UID
from_uid container_uid
from_uid + 1 container_uid + 1
from_uid + 2 container_uid + 2
from_uid + 3 container_uid + 3
from_uid + 4 container_uid + 4

هنگام اجرا در حالت بدون ریشه، پادمن از تمام محدوده‌های پیکربندی‌شده در فایل /etc/subuid استفاده می‌کند.

شناسه کاربر جاری به UID=0 در فضای نام کاربر بدون ریشه نگاشت می‌شود. هر محدوده اضافی به صورت متوالی پس از آن اضافه می‌گردد:

host rootless user namespace length
$UID 0 1
1 $FIRST_RANGE_ID $FIRST_RANGE_LENGTH
1+$FIRST_RANGE_LENGTH $SECOND_RANGE_ID $SECOND_RANGE_LENGTH

Referencing a host ID from the parent namespace

به عنوان یک کاربر بدون ریشه، شناسه میزبان داده‌شده در UIDMap= یا GIDMap= از فضای نام واسط تولیدشده توسط پادمن نگاشت می‌شود. گاهی اوقات ارجاع مستقیم به فضای نام میزبان مطلوب است. این کار به صورت دستی با اجرای دستور podman unshare cat /proc/self/gid_map، یافتن شناسه میزبان مورد نظر در ستون دوم خروجی، و دریافت شناسه واسط متناظر از ستون اول امکان‌پذیر است.

پادمن می‌تواند همه این کارها را با قرار دادن نماد @ قبل از شناسه میزبان در نگاشت انجام دهد. برای نمونه، با تعیین --gidmap 100000:@2000:1، پادمن شناسه واسط متناظر با شناسه میزبان 2000 را جستجو کرده و شناسه واسط یافت‌شده را به شناسه کانتینر 100000 نگاشت می‌کند. شناسه میزبان داده‌شده باید به عنوان فرعی تعریف شده باشد (در غیر این صورت از ابتدا در فضای واسط نگاشت نخواهد شد).

اگر طول بیشتر از یک باشد، مثلاً با --gidmap 100000:@2000:2، پادمن شناسه‌های میزبان 2000 و 2001 را به ترتیب به 100000 و 100001 نگاشت خواهد کرد، صرف‌نظر از اینکه نگاشت واسط چگونه تعریف شده باشد.

Extending previous mappings

برخی از تغییرات نگاشت ممکن است پیچیده باشند. برای مثال، کاربری با یک نگاشت مانند --gidmap="0:0:65000" شروع می‌کند، که نیاز به تغییر دارد به گونه‌ای که شناسه والد 1 به جای آن به شناسه کانتینر 100000 نگاشت شود، و شناسه کانتینر 1 تخصیص‌نیافته باقی بماند. گزینه --gidmap متناظر به صورت --gidmap="0:0:1" --gidmap="2:2:65534" --gidmap="100000:1:1" درمی‌آید.

این شیوه‌نگارش را می‌توان با استفاده از فلگ + ساده کرد، که وظیفه شکستن نگاشت‌های قبلی و حذف هرگونه تخصیص متداخل با نگاشت داده‌شده را بر عهده دارد. این فلگ قبل از شناسه کانتینر به صورت زیر ارائه می‌شود: --gidmap="0:0:65000" --gidmap="+100000:1:1"

Flag Example Description
+ +100000:1:1 گسترش نگاشت قبلی

این شیوه باعث ایجاد شکاف‌هایی در تخصیص می‌شود، بنابراین ممکن است پر کردن این شکاف‌ها پس از آن مناسب باشد: --gidmap="0:0:65000" --gidmap="+100000:1:1" --gidmap="1:65001:1"

یک مورد استفاده خاص برای این فلگ در زمینه کاربران بدون ریشه است. یک کاربر بدون ریشه می‌تواند نگاشت‌ها را با فلگ + مانند --gidmap="+100000:1:1" مشخص کند. پادمن سپس با تمام شناسه‌های واسط باقی‌مانده، با شروع از صفر «شکاف‌ها را پر می‌کند». این زمانی مناسب است که کاربر بخواهد یک شناسه واسط خاص را به یک شناسه کانتینر نگاشت کند، و اجازه دهد بقیه شناسه‌های فرعی توسط پادمن به دلخواه نگاشت شوند.

Passing only one of --uidmap or --gidmap

معمولاً شناسه‌های فرعی کاربر و گروه به طور هم‌زمان تخصیص می‌یابند و برای هر کاربر، شناسه‌های فرعی کاربر با شناسه‌های فرعی گروه مطابقت دارند. برای راحتی، اگر فقط یکی از UIDMap= یا GIDMap= داده شود، پادمن فرض می‌کند که نگاشت به هر دو UID و GID اشاره دارد و نگاشت داده‌شده را روی هر دو اعمال می‌کند. اگر تنها یکی از این دو مقدار نیاز به تغییر داشته باشد، نگاشت‌ها باید شامل فلگ‌های u یا g باشند تا مشخص کنند که فقط روی UIDها یا GIDها اعمال می‌شوند و نباید روی دیگری کپی شوند.

flag Example Description
u u20000:2000:1 نگاشت تنها بر UIDها اعمال می‌شود
g g10000:1000:1 نگاشت تنها بر GIDها اعمال می‌شود

برای نمونه با فرض دستور:

podman podman-container.unit.5.md.in --gidmap "0:0:1000" --gidmap "g2000:2000:1"

از آنجا که هیچ UIDMap= مشخص نشده است، مقدار GIDMap= در UIDMap= کپی می‌شود، و دستوری معادل زیر حاصل می‌گردد:

podman podman-container.unit.5.md.in --gidmap "0:0:1000" --gidmap "2000:2000:1" --uidmap "0:0:1000"

گزینه --gidmap "g2000:2000:1" از فلگ g استفاده کرده و بنابراین در UIDMap= کپی نشده است.

Rootless mapping of additional host GIDs

یک کاربر بدون ریشه ممکن است بخواهد یک گروه میزبان خاص را که قبلاً در /etc/subgid به صورت فرعی تعریف شده است، بدون مشخص کردن بقیه نگاشت، نگاشت کند.

این کار را می‌توان با GIDMap="+gcontainer_gid:@host_gid" انجام داد.

به طوری که:

  • شناسه GID میزبان از طریق نماد @ داده می‌شود.
  • نگاشت این GID به لطف فلگ g به --usermap کپی نمی‌شود.
  • بقیه شناسه‌های کانتینر به لطف فلگ +، با شروع از 0 تا n، با تمام GIDهای فرعی باقی‌مانده نگاشت می‌شوند.

برای مثال، اگر کاربری متعلق به گروه 2000 باشد و آن گروه به آن کاربر اختصاص یافته باشد (با usermod --add-subgids 2000-2000 $USER)، کاربر می‌تواند آن گروه را با دستور زیر به کانتینر نگاشت کند: GIDMap=+g100000:@2000.

اگر این نگاشت با گزینه GroupAdd=keep-groups ترکیب شود، فرآیند درون کانتینر به گروه 100000 تعلق خواهد داشت، و فایل‌های متعلق به گروه 2000 در میزبان به گونه‌ای دیده می‌شوند که گویی متعلق به گروه 100000 در داخل کانتینر هستند.

podman run --group-add=keep-groups --gidmap="+g100000:@2000" ...

No subordinate UIDs

حتی اگر کاربری هیچ UID فرعی در /etc/subuid نداشته باشد، با اجرای دستور podman podman-container.unit.5.md.in --uidmap $container_uid:0:1 --user $container_uid ... همچنان می‌توان از UIDMap= برای نگاشت UID عادی کاربر به یک UID کانتینر استفاده کرد.

Pods

گزینه UIDMap= را نمی‌توان همراه با گزینه Pod= فراخوانی کرد، زیرا در زمان حضور در پاد نمی‌توان نگاشت uidmap را در سطح کانتینر تنظیم کرد.

گزینه‌های Ulimit. مقادیر ulimit را در داخل کانتینر تنظیم می‌کند.

--ulimit با یک حد نرم (soft) و سخت (hard) در قالب =[:] تنظیم می‌شود. برای نمونه:

$ podman run --ulimit nofile=1024:1024 --rm ubi9 ulimit -n 1024

برای حد نرم یا سخت مقدار 1- را تعیین کنید تا حد به حداکثر مقدار مجاز فرآیند جاری تنظیم شود. در حالت با ریشه (rootful) این مقدار اغلب نامحدود (unlimited) است.

اگر nofile و nproc تنظیم نشده باشند، یک مقدار پیش‌فرض برابر با ۱۰۴۸۵۷۶ استفاده خواهد شد، مگر اینکه در containers.conf(5) لغو و بازنویسی شده باشد. با این حال، اگر مقدار پیش‌فرض از حد سخت برای کاربر بدون ریشه جاری فراتر رود، حد سخت جاری به جای آن اعمال خواهد شد.

از host برای کپی کردن پیکربندی جاری از میزبان استفاده کنید.

از nproc با فلگ ulimit استفاده نکنید زیرا لینوکس از nproc برای تعیین حداکثر تعداد فرآیندهای در دسترس یک کاربر استفاده می‌کند، نه یک کانتینر.

از گزینه --pids-limit برای اصلاح کنترل cgroup به منظور محدود کردن تعداد فرآیندهای درون یک کانتینر استفاده کنید.

مسیرهایی که باید از حالت پوشش (unmask) خارج شوند را مشخص کنید که با دو نقطه از هم جدا می‌شوند. unmask=ALL یا /path/1:/path/2، یا مسیرهای گسترش‌یافته توسط شل (/proc/*):

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

مسیرهای پیش‌فرض پوشش‌دار (masked) عبارتند از: /proc/acpi، /proc/kcore، /proc/keys، /proc/latency_stats، /proc/sched_debug، /proc/scsi، /proc/timer_list، /proc/timer_stats، /sys/firmware و /sys/fs/selinux.

مسیرهای پیش‌فرض فقط‌خواندنی (read-only) عبارتند از: /proc/asound، /proc/bus، /proc/fs، /proc/irq، /proc/sys، /proc/sysrq-trigger، /sys/fs/cgroup.

نام کاربری یا UID مورد استفاده و در صورت تمایل، نام گروه یا GID را برای دستور مشخص‌شده تعیین می‌کند. هر دو مقدار user و group می‌توانند نمادین یا عددی باشند.

بدون این آرگومان، دستور به عنوان کاربری که در ایمیج کانتینر مشخص شده اجرا می‌شود. مگر اینکه توسط یک دستور USER در Containerfile یا توسط مقداری که به این گزینه داده شده بازنویسی شود، این کاربر به طور پیش‌فرض root است.

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

حالت فضای نام کاربر (user namespace mode) را برای کانتینر تنظیم می‌کند.

اگر --userns تنظیم نشده باشد، مقدار پیش‌فرض به شرح زیر تعیین می‌شود: - اگر --pod تنظیم شده باشد، --userns نادیده گرفته شده و از فضای نام کاربر پاد استفاده می‌شود. - اگر متغیر محیطی PODMAN_USERNS تنظیم شده باشد، مقدار آن استفاده می‌شود. - اگر userns در containers.conf مشخص شده باشد، این مقدار استفاده می‌شود. - در غیر این صورت، --userns=host فرض می‌شود.

گزینه --userns="" (یعنی یک رشته خالی) یک نام مستعار برای --userns=host است.

این گزینه با گزینه‌های GIDMap=، UIDMap=، SubUIDMap= و SubGIDMap= ناسازگار است.

نگاشت‌های کلیدهای --userns برای کاربر بدون ریشه:

Key Host User Container User
auto $UID nil (شناسه UID کاربر میزبان به داخل کانتینر نگاشت نمی‌شود.)
host $UID 0 (حساب پیش‌فرض کاربر به کاربر root در کانتینر نگاشت می‌شود.)
keep-id $UID $UID (نگاشت حساب کاربر به همان UID در داخل کانتینر.)
keep-id:uid=200,gid=210 $UID 200:210 (نگاشت حساب کاربر به مقدار مشخص‌شده UID و GID در داخل کانتینر.)
nomap $UID nil (شناسه UID کاربر میزبان به داخل کانتینر نگاشت نمی‌شود.)

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

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

  • حالت با ریشه (rootful): فلگ --userns=auto مستلزم آن است که نام کاربری containers در فایل‌های /etc/subuid و /etc/subgid مشخص شده باشد، همراه با یک محدوده استفاده‌نشده از شناسه‌های کاربری فرعی که کانتینرهای پادمن مجاز به تخصیص آن‌ها هستند. برای نمونه: containers:2147483647:2147483648.
  • حالت بدون ریشه (rootless): از محدوده کاربر در فایل‌های /etc/subuid و /etc/subgid استفاده خواهد شد. توجه داشته باشید که اجرای یک کانتینر واحد بدون استفاده از --userns=auto از تمام محدوده UIDها استفاده می‌کند و اجازه تقسیم‌بندی بیشتر را نمی‌دهد. subuid(5) را ببینید.

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

گزینه --userns=keep-id از تمامی subuidها و subgidهای کاربر استفاده می‌کند. گزینه --userns=nomap از تمامی subuidها و subgidهای کاربر به جز شناسه خود کاربر استفاده می‌کند. استفاده از --userns=auto هنگام راه‌اندازی کانتینرهای جدید تا زمانی که کانتینرهایی وجود داشته باشند که با --userns=nomap یا --userns=keep-id بدون محدود کردن اندازه فضای نام کاربر راه‌اندازی شده‌اند، کار نخواهد کرد.

گزینه‌های مجاز auto:

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

شناسه‌های UID و GID میزبان در gidmapping و uidmapping می‌توانند به صورت اختیاری با نماد @ پیشوند شوند. در این حالت، پادمن شناسه واسط متناظر با شناسه میزبان را جستجو کرده و شناسه واسط یافت‌شده را به شناسه کانتینر نگاشت می‌کند. برای جزئیات بیشتر به UIDMap= مراجعه کنید.

container:id: پیوستن به فضای نام کاربر کانتینر مشخص‌شده.

host یا "" (رشته خالی): اجرا در فضای نام کاربر فراخواننده. فرآیندهای در حال اجرا در کانتینر، همان امتیازاتی را روی میزبان دارند که هر فرآیند دیگری که توسط کاربر فراخواننده اجرا شود دارد.

keep-id: ایجاد یک فضای نام کاربر که در آن UID:GID کاربر جاری به همان مقادیر درون کانتینر نگاشت می‌شوند. برای کانتینرهای ایجادشده توسط root، نگاشت جاری در یک فضای نام کاربر جدید ایجاد می‌شود.

علاوه بر این، فرآیند init در داخل کانتینر با UID کاربر جاری اجرا خواهد شد. این رفتار دستورالعمل USER ایمیج را لغو می‌کند مگر اینکه صراحتاً --user را تنظیم کرده باشید.

گزینه‌های مجاز keep-id:

  • uid=UID: شناسه UID داخل کانتینر را که کاربر جاری به آن نگاشت می‌شود لغو و بازنویسی می‌کند.
  • gid=GID: شناسه GID داخل کانتینر را که کاربر جاری به آن نگاشت می‌شود لغو و بازنویسی می‌کند.
  • size=SIZE: اندازه فضای نام کاربر پیکربندی‌شده را بازنویسی می‌کند. این گزینه برای پر نکردن تمام شناسه‌های در دسترس مفید است. هنگام اجرا به عنوان root پشتیبانی نمی‌شود.

nomap: یک فضای نام کاربر ایجاد می‌کند که در آن UID:GID کاربر بدون ریشه جاری به کانتینر نگاشت نمی‌شوند. این گزینه برای کانتینرهای ایجادشده توسط کاربر ریشه (root) مجاز نیست.

ns:namespace: کانتینر را در فضای نام کاربر موجود مشخص‌شده اجرا می‌کند.

ایجاد یک اتصال اتصالی (bind mount). اگر -v /HOST-DIR:/CONTAINER-DIR مشخص شود، پادمن پوشه /HOST-DIR را از میزبان به درون /CONTAINER-DIR در کانتینر پادمن سوار می‌کند. به طور مشابه، -v SOURCE-VOLUME:/CONTAINER-DIR جلد نام‌گذاری‌شده را از میزبان به درون کانتینر سوار می‌کند. اگر چنین جلد نام‌گذاری‌شده‌ای وجود نداشته باشد، پادمن آن را ایجاد می‌کند. گزینه nocreate می‌تواند برای غیرفعال کردن این رفتار و الزام به وجود قبلی جلد استفاده شود. اگر منبعی داده نشود، جلد به عنوان یک جلد نام‌گذاری‌شده ناشناس با یک نام تصادفی تولیدشده ایجاد می‌شود، و هنگام حذف کانتینر از طریق فلگ --rm یا دستور podman rm --volumes حذف می‌گردد.

حالت خاص:

•
اگر SOURCE-VOLUME به پسوند .volume ختم شود، یک جلد نام‌گذاری‌شده پادمن به نام systemd-$name به عنوان منبع استفاده می‌شود و سرویس systemd تولیدشده شامل یک وابستگی به $name-volume.service خواهد بود. توجه داشته باشید که فایل .volume متناظر باید وجود داشته باشد.

(توجه داشته باشید که هنگام استفاده از کلاینت راه دور، از جمله ماشین‌های Mac و ویندوز (به استثنای WSL2)، جلدهای حافظه از سرور راه دور سوار می‌شوند، نه لزوماً ماشین کلاینت.)

شناسه OPTIONS یک لیست جداشده با کاما است و می‌تواند یک یا چند مورد از موارد زیر باشد:

  • rw|ro
  • z|Z
  • [O]
  • [U]
  • [no]copy
  • [no]dev
  • [no]exec
  • [no]suid
  • [r]bind
  • [r]shared|[r]slave|[r]private[r]unbindable [1] ⟨#Footnote1⟩
  • idmap[=options]
  • nocreate

مسیر CONTAINER-DIR باید یک مسیر مطلق مانند /src/docs باشد. جلد در این دایرکتوری درون کانتینر سوار می‌شود.

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

هر منبعی که با یک . یا / شروع نشود به عنوان نام یک جلد نام‌گذاری‌شده در نظر گرفته می‌شود. اگر جلدی با آن نام وجود نداشته باشد، ایجاد خواهد شد. جلدهایی که با نام ایجاد می‌شوند ناشناس نیستند و با گزینه --rm و دستور podman rm --volumes حذف نمی‌شوند.

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

$ podman podman-container.unit.5.md.in -v myvolume:/data:nocreate alpine

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

Write Protected Volume Mounts

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

Chowning Volume Mounts

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

  • جلد هنوز استفاده نشده باشد (مقدار NeedsChown روی true تنظیم شده باشد)
  • جلد خالی باشد یا هنوز به سمت بالا کپی (copy up) نشده باشد
  • جلد توسط یک درایور جلد خارجی مدیریت نشود
  • درایور جلد "image" نباشد

برای جلدهایی با سوار کردن مبتنی بر idmapped (با استفاده از گزینه idmap)، تغییر مالکیت، نگاشت‌های فضای نام کاربر کانتینر را لحاظ می‌کند، اما جلد idmapped نگاشت صحیح UID/GID را حفظ می‌نماید. برای جلدهای بدون idmapping، نقطه اتصال تغییر مالکیت می‌یابد تا با کاربر و گروه فرآیند کانتینر مطابقت کند که در صورت فعال بودن بازنگاشت فضای نام کاربر، به فضای نام کاربر میزبان نگاشت می‌شود.

اگر کانتینری در یک فضای نام کاربر جدید ایجاد شود، UID و GID در کانتینر ممکن است با UID و GID دیگری روی میزبان متناظر باشند.

پسوند :U به پادمن می‌گوید بر اساس UID و GID درون کانتینر، از UID و GID صحیح میزبان برای تغییر بازگشتی مالک و گروه جلد منبع استفاده کند. این تغییر مالکیت، سیستم فایل زیرمجموعه جلد را پیمایش کرده و UID/GID هر فایل را تغییر می‌دهد. اگر جلد دارای هزاران inode باشد، این فرآیند زمان زیادی برده و شروع به کار کانتینر را به تاخیر می‌اندازد.

Warning با احتیاط استفاده شود زیرا این عمل سیستم‌فایل میزبان را دستکاری می‌کند.

Labeling Volume Mounts

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

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

نکته: تمام کانتینرهای درون یک pod دارای برچسب SELinux یکسان هستند. این بدان معناست که همه کانتینرهای موجود در پاد یادشده می‌توانند جلدهای به اشتراک گذاشته شده در کانتینری را که با :Z در هر یک از کانتینرها ایجاد شده است، بخوانند/بنویسند. برچسب‌گذاری مجدد، سیستم‌فایل زیر جلد را پیمایش کرده و برچسب هر فایل را تغییر می‌دهد؛ اگر جلد دارای هزاران inode باشد، این فرآیند زمان زیادی برده و شروع به کار کانتینر را به تاخیر می‌اندازد. اگر جلد قبلاً با گزینه z برچسب‌گذاری مجدد شده باشد، پادمن بهینه‌سازی شده است تا برای بار دوم آن را برچسب‌گذاری مجدد نکند. اگر فایل‌ها به درون جلد منتقل شوند، برچسب‌ها را می‌توان به صورت دستی با دستور chcon -Rt container_file_t PATH تغییر داد.

نکته: فایل‌ها و دایرکتوری‌های سیستمی را برچسب‌گذاری مجدد نکنید. برچسب‌گذاری مجدد محتوای سیستمی ممکن است باعث خرابی سایر سرویس‌های محدودشده روی ماشین شود. برای این دسته از کانتینرها، غیرفعال کردن جداسازی SELinux را پیشنهاد می‌کنیم. گزینه --security-opt label=disable جداسازی SELinux را برای کانتینر غیرفعال می‌کند. برای نمونه، اگر کاربری بخواهد کل دایرکتوری خانگی (home) خود را به عنوان جلد در یک کانتینر سوار کند، باید جداسازی SELinux را غیرفعال نماید.

$ podman podman-container.unit.5.md.in --security-opt label=disable -v $HOME:/home/user fedora touch /home/user/file

Overlay Volume Mounts

فلگ :O به پادمن می‌گوید که دایرکتوری را از میزبان به عنوان فضای ذخیره‌سازی موقت با استفاده از overlay file system سوار کند. فرآیندهای کانتینر می‌توانند محتوای درون نقطه اتصال را تغییر دهند که در فضای ذخیره‌سازی کانتینر در یک دایرکتوری جداگانه ذخیره می‌شود. در اصطلاحات overlay، دایرکتوری منبع lower (پایینی) است و دایرکتوری ذخیره‌سازی کانتینر upper (بالایی) است. تغییرات اعمال‌شده در نقطه اتصال با پایان یافتن اجرای کانتینر نابود می‌شوند، مشابه نقطه اتصالی از نوع tmpfs که پس از پایان unmount می‌شود.

برای کاربران پیشرفته، گزینه overlay همچنین از upperdir و workdir غیرفرار سفارشی برای سوار کردن overlay پشتیبانی می‌کند. دایرکتوری‌های سفارشی upperdir و workdir می‌توانند کاملاً توسط خود کاربران مدیریت شوند و پادمن در پایان چرخه حیات آن‌ها را حذف نمی‌کند. نمونه: :O,upperdir=/some/upper,workdir=/some/work

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

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

نکته: فلگ O با سایر گزینه‌های ذکرشده در بالا تداخل دارد.

محتوای سوارشده در کانتینر با برچسب اختصاصی برچسب‌گذاری می‌شود. در سیستم‌های SELinux، برچسب‌های موجود در دایرکتوری منبع باید توسط برچسب کانتینر قابل خواندن باشند. معمولاً کانتینرها می‌توانند container_share_t را بخوانند/اجرا کنند و می‌توانند container_file_t را بخوانند/بنویسند. در صورت ناتوانی در تغییر برچسب‌های یک جلد منبع، جداسازی کانتینر SELinux باید غیرفعال شود تا کانتینر کار کند.

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

Mounts propagation

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

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

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

سوار کردن جلد با گزینه copy به پادمن می‌گوید که محتوا را از دایرکتوری مقصد زیرین به جلدهای داخلی تازه ایجادشده کپی کند. عمل copy تنها در زمان ایجاد اولیه جلد اتفاق می‌افتد. محتوا زمانی که جلد متعاقباً در کانتینرهای مختلف استفاده شود کپی نمی‌شود. گزینه copy روی اتصالات bind نادیده گرفته شده و تاثیری ندارد.

سوار کردن جلدها با گزینه‌های nosuid به این معناست که فایل‌های اجرایی SUID روی جلد نمی‌توانند توسط برنامه‌ها برای تغییر دسترسی‌شان استفاده شوند. به طور پیش‌فرض جلدها با nosuid سوار می‌شوند.

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

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

اگر HOST-DIR یک نقطه اتصال باشد، گزینه‌های dev، suid و exec توسط هسته لینوکس نادیده گرفته می‌شوند.

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

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

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

Idmapped mount

اگر idmap مشخص شده باشد، یک اتصال با نگاشت شناسه (idmapped mount) به فضای نام کاربر مقصد در کانتینر ایجاد کنید. گزینه idmap از یک نگاشت سفارشی پشتیبانی می‌کند که می‌تواند متفاوت از فضای نام کاربر مورد استفاده توسط کانتینر باشد. نگاشت را می‌توان بعد از گزینه idmap به صورت زیر مشخص کرد: idmap=uids=0-1-10#10-11-10;gids=0-100-10. برای هر سه‌تایی، مقدار اول شروع شناسه‌های سیستم فایل پشتیبان است که به مقدار دوم روی میزبان نگاشت می‌شوند. طول این نگاشت در مقدار سوم ارائه می‌شود. محدوده‌های چندگانه با نماد # از یکدیگر جدا می‌شوند.

دایرکتوری کاری درون کانتینر.

دایرکتوری کاری پیش‌فرض برای اجرای فایل‌های باینری درون یک کانتینر، دایرکتوری ریشه (/) است. توسعه‌دهنده ایمیج می‌تواند با دستورالعمل WORKDIR پیش‌فرض متفاوتی را تنظیم کند. مجری سیستم می‌تواند دایرکتوری کاری را با استفاده از گزینه WorkingDir= لغو و بازنویسی کند.

به طور پیش‌فرض، مولد مقدار Type=notify را برای واحدهای .container تنظیم می‌کند.

این مقدار را می‌توان با تنظیم صریح Type= در بخش [Service] لغو و بازنویسی کرد.

برای کانتینرهای یک‌باره یا یک‌باره‌مصرف (مانند وظایف اولیه init)، از مورد زیر استفاده کنید:

[Service]
Type=oneshot
RemainAfterExit=yes

برای جزئیات کامل پیرامون انواع سرویس‌ها و رفتارهای مرتبط به systemd.service(5) مراجعه فرمایید.

برای اطمینان از آغاز به کار کانتینر هنگام بوت، یک بخش [Install] اضافه کنید:

[Install]
WantedBy=multi-user.target

تنها کلیدهای Alias=، WantedBy=، RequiredBy= و UpheldBy= پشتیبانی می‌شوند.

راه‌اندازی کانتینر ممکن است از مهلت زمانی پیش‌فرض ۹۰ ثانیه‌ای systemd فراتر رود (برای مثال، هنگام دریافت ایمیج‌ها). استفاده کنید از:

[Service]
TimeoutStartSec=900

نکته: گزینه TimeoutStartSec برای Type=oneshot نادیده گرفته می‌شود.

کوادلت موارد زیر را می‌افزاید:

  • After=network-online.target (برای واحدهای ریشه)
  • After=podman-user-wait-network-online.service (برای واحدهای کاربری)

جهت غیرفعال‌سازی این مورد، اضافه کنید:

[Quadlet]
DefaultDependencies=false

به طور پیش‌فرض، کانتینر systemd-<unitname> نام‌گذاری می‌شود. از ContainerName= برای لغو و بازنویسی آن استفاده کنید.

از به کار بردن مشخص‌کننده‌های systemd مانند %N در نام منابع خودداری ورزید—این کار پیوندهای بین‌منابعی را مخدوش می‌کند.

کوادلت از واحدهای کانتینری الگودار پشتیبانی می‌کند، به عنوان نمونه، foo@.container واحد foo@.service را ایجاد می‌کند.

می‌توانید نمونه را با این دستور فراخوانی و اجرا کنید:

systemctl start foo@bar.service

همچنین می‌توانید به نمونه‌ها پیوند نمادین ایجاد کنید:

ln -s foo@.container foo@bar.container

برای سفارشی‌سازی مختص هر نمونه از فایل‌های دراپ-این استفاده کنید:

foo@bar.container.d/10-override.conf

کوادلت از پیکربندی دراپ-این در دایرکتوری‌های .container.d/ پشتیبانی می‌کند.

برای نمونه، یک فایل دراپ-این:

test.container.d/10-extra.conf

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

فایل‌های دراپ-این از همان رفتار لغو و ادغام واحدهای systemd پیروی می‌کنند.

یک واحد کانتینری کمینه:

[Unit]
Description=A minimal container
[Container]
Image=quay.io/centos/centos:latest
Exec=sleep 60
[Install]
WantedBy=multi-user.target

podman-run(1), podman-systemd.unit(5), systemd.service(5), systemd.unit(5)