'\" t .nh .TH podman-container.unit 5 .SH "نام (NAME)" podman-container.unit \- فایل‌های واحد systemd برای مدیریت کانتینرها با استفاده از Podman Quadlet .SH "خلاصه دستور (SYNOPSIS)" \fIname\fP\&.container .SH "توضیحات (DESCRIPTION)" واحد‌های کانتینر با پسوند \fB\&.container\fR نام‌گذاری می‌شوند و شامل یک بخش \fB[Container]\fR هستند که کانتینر در حال اجرا به عنوان یک سرویس را توصیف می‌کند. فایل سرویس حاصل شامل خطی مانند \fBExecStart=podman run ... image-name\fR است، و بیشتر کلیدهای این بخش گزینه‌های خط فرمانی ارسال‌شده به Podman را کنترل می‌کنند. با این حال، برخی گزینه‌ها بر جزئیات نحوه راه‌اندازی و تعامل systemd با کانتینر نیز تأثیر می‌گذارند. .PP به‌طور پیش‌فرض، کانتینر Podman همان نام واحد را دارد، اما با پیشوند \fBsystemd-\fR؛ یعنی یک فایل \fB$name.container\fR یک واحد \fB$name.service\fR و یک کانتینر Podman به نام \fBsystemd-$name\fR ایجاد می‌کند. گزینه \fBContainerName\fR امکان بازنویسی این نام پیش‌فرض را با نام ارائه‌شده توسط کاربر فراهم می‌کند. .PP تنها یک کلید الزامی وجود دارد، \fBImage\fR، که ایمیج کانتینری که سرویس اجرا می‌کند را مشخص می‌کند. .SH "خلاصه کاربرد (USAGE SUMMARY)" فایل \fB\&.container\fR در زمان بوت یا بارگذاری مجدد (reload) توسط \fBpodman-system-generator\fR تجزیه می‌شود و یک \fB\&.service\fR در systemd تولید می‌کند که \fBpodman run\fR را اجرا می‌نماید. آن سرویس می‌تواند مانند هر واحد دیگری مدیریت شود: .EX systemctl --user start myimage-container.service .EE .SH "گزینه‌ها (OPTIONS)" گزینه‌های معتبر برای \fB[Container]\fR در زیر فهرست شده‌اند: .TS allbox; l l l l . \fBگزینه‌های [Container]\fP \fBمعادل در podman run\fP AddCapability=CAP --cap-add CAP AddDevice=/dev/foo --device /dev/foo AddHost=example\&.com:192.168.10.11 T{ --add-host example.com:192.168.10.11 T} Annotation="XYZ" --annotation "XYZ" AutoUpdate=registry T{ --label "io.containers.autoupdate=registry" T} 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 T{ دستور پس از تعیین ایمیج - /usr/bin/command T} 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 T{ --health-log-destination=/foo/log T} 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 T{ --security-opt mask=/proc/sys/foo:/proc/sys/bar T} Memory=20g --memory 20g Mount=type=... --mount type=... Network=host --network host NetworkAlias=name --network-alias name NoNewPrivileges=true T{ --security-opt no-new-privileges T} 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 T{ افزودن ExecReload و اجرای exec با این مقدار T} ReloadSignal=SIGHUP T{ افزودن ExecReload و اجرای kill با این سیگنال T} Retry=5 --retry=5 RetryDelay=5s --retry-delay=5s Rootfs=/var/lib/rootfs --rootfs /var/lib/rootfs RunInit=true --init SeccompProfile=/tmp/s.json T{ --security-opt seccomp=/tmp/s.json T} Secret=secret --secret=secret[,opt=opt ...] SecurityLabelDisable=true --security-opt label=disable SecurityLabelFileType=usr_t T{ --security-opt label=filetype:usr_t T} SecurityLabelLevel=s0:c1,c2 T{ --security-opt label=level:s0:c1,c2 T} SecurityLabelNested=true --security-opt label=nested SecurityLabelType=spc_t T{ --security-opt label=type:spc_t T} ShmSize=100m --shm-size=100m StartWithPod=true T{ اگر Pod= تعریف شده باشد، کانتینر توسط پاد راه‌اندازی می‌شود T} 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 T{ --userns keep-id:uid=200,gid=210 T} Volume=/source:/dest --volume /source:/dest WorkingDir=$HOME --workdir $HOME .TE .PP کلیدهای پشتیبانی‌شده در بخش \fB[Container]\fR عبارتند از: .SS \fBAddCapability=capability\fR افزودن قابلیت‌های لینوکس (Linux capabilities). .PP اعطای قابلیت‌های بیشتر، دسترسی‌ها و امتیازات فرآیندهای در حال اجرا درون کانتینر را افزایش می‌دهد و ممکن است به آن‌ها اجازه خروج از محدوده امنیتی (confinement) را بدهد. قابلیت‌هایی مانند \fBCAP_SYS_ADMIN\fR، \fBCAP_SYS_PTRACE\fR، \fBCAP_MKNOD\fR و \fBCAP_SYS_MODULE\fR به‌ویژه زمانی که درون یک فضای نام کاربری (user namespace) استفاده نشوند، بسیار خطرناک هستند. لطفاً برای توضیح دقیق‌تر درباره نحوه تعامل بین فضاهای نام کاربری و قابلیت‌ها، به \fBuser_namespaces(7)\fP مراجعه کنید. .PP پیش از افزودن هر قابلیتی، پیامدهای امنیتی آن را بررسی کرده و اطمینان حاصل کنید که واقعاً برای عملکرد کانتینر ضروری است. برای اطلاعات بیشتر به \fBcapabilities(7)\fP مراجعه کنید. .SS \fBAddDevice=host-device[:container-device][:permissions]\fR افزودن یک دستگاه میزبان به کانتینر. قالب این گزینه به‌صورت \fBHOST-DEVICE[:CONTAINER-DEVICE][:PERMISSIONS]\fR است، که در آن \fBHOST-DEVICE\fR مسیر گره دستگاه (device node) روی میزبان، \fBCONTAINER-DEVICE\fR مسیر گره دستگاه در کانتینر، و \fBPERMISSIONS\fR فهرستی از مجوزها شامل ترکیبی از «r» برای خواندن، «w» برای نوشتن، و «m» برای mknod(2) است. .PP مثال: \fB--device=/dev/sdc:/dev/xvdc:rwm\fP\&. .PP نکته: اگر \fIhost-device\fP یک پیوند نمادین (symbolic link) باشد، ابتدا حل (resolve) می‌شود. کانتینر فقط شماره‌های اصلی و فرعی (major و minor) دستگاه میزبان را ذخیره می‌کند. .PP پادمن ممکن است ماژول‌های هسته مورد نیاز برای استفاده از دستگاه مشخص‌شده را بارگذاری کند. دستگاه‌هایی که پادمن در صورت لزوم ماژول‌های آن‌ها را بارگذاری می‌کند عبارتند از: /dev/fuse. .PP در حالت بدون ریشه (rootless)، دستگاه جدید از میزبان به درون کانتینر bind mount می‌شود، به‌جای اینکه پادمن آن را در فضای کانتینر ایجاد کند. از آنجا که اتصال bind برچسب SELinux خود را در سیستم‌های دارای SELinux حفظ می‌کند، ممکن است کانتینر هنگام دسترسی به دستگاه متصل‌شده با خطای عدم دسترسی (permission denied) روبرو شود. برای اجازه دادن به کانتینرها جهت استفاده از تمام برچسب‌های دستگاه، تنظیمات SELinux را با دستور زیر تغییر دهید: .PP $ sudo setsebool -P container_use_devices=true .SS \fBAddHost=hostname[;hostname[;...]]:ip\fR افزودن نگاشت سفارشی نام میزبان به IP در فایل \fB/etc/hosts\fR کانتینر. .PP این گزینه یک یا چند نام میزبان را که با نقطه-ویرگول از هم جدا شده‌اند می‌پذیرد تا به یک آدرس IPv4 یا IPv6 واحد نگاشت شوند (که با دونقطه از نام‌ها جدا می‌شود). این گزینه همچنین می‌تواند برای بازنویسی آدرس‌های IP نام‌های میزبانی که پادمن به‌طور پیش‌فرض به \fB/etc/hosts\fR اضافه می‌کند استفاده شود (همچنین به گزینه‌های \fB--name\fP و \fB--hostname\fP مراجعه کنید). این گزینه می‌تواند چندین بار مشخص شود تا نگاشت‌های بیشتری به \fB/etc/hosts\fR اضافه گردد. این گزینه با گزینه \fB--no-hosts\fP و با \fIno_hosts=true\fP در \fBcontainers.conf\fR تداخل دارد. .PP به‌جای آدرس IP، فلگ ویژه \fIhost-gateway\fP می‌تواند داده شود. این به یک آدرس IP تبدیل می‌شود که کانتینر می‌تواند برای اتصال به میزبان از آن استفاده کند. آدرس IP انتخاب‌شده به پیکربندی شبکه شما بستگی دارد، بنابراین هیچ تضمینی وجود ندارد که پادمن بتواند آدرس \fIhost-gateway\fP را به‌طور خودکار تعیین کند، که در این صورت پادمن با پیام خطا متوقف می‌شود. می‌توانید این آدرس IP را با استفاده از گزینه \fIhost_containers_internal_ip\fP در \fIcontainers.conf\fP بازنویسی کنید. .PP آدرس \fIhost-gateway\fP همچنین توسط پادمن برای افزودن خودکار نام‌های میزبان \fBhost.containers.internal\fR و \fBhost.docker.internal\fR به \fB/etc/hosts\fR استفاده می‌شود. می‌توانید با ارائه گزینه \fB--no-hosts\fP، یا با تنظیم \fIhost_containers_internal_ip="none"\fP در \fIcontainers.conf\fP از این کار جلوگیری کنید. اگر هیچ آدرس \fIhost-gateway\fP به‌صورت دستی پیکربندی نشده باشد و پادمن در تعیین خودکار آدرس IP ناموفق باشد، پادمن بدون نمایش پیام از افزودن این نام‌های میزبان داخلی به \fB/etc/hosts\fR صرف‌نظر می‌کند. اگر پادمن در یک ماشین مجازی با استفاده از \fBpodman machine\fR در حال اجرا باشد (این شامل میزبان‌های مک و ویندوز نیز می‌شود)، پادمن بدون نمایش پیام از افزودن نام‌های میزبان داخلی به \fB/etc/hosts\fR صرف‌نظر می‌کند، مگر اینکه آدرس IP به‌صورت دستی پیکربندی شده باشد؛ در این حالت نام‌های میزبان داخلی توسط حل‌کننده DNS به نام gvproxy حل می‌شوند. .PP پادمن به‌طور پیش‌فرض از فایل \fB/etc/hosts\fR میزبان به‌عنوان مبنا استفاده می‌کند، یعنی هر نام میزبانی که در این فایل وجود دارد، در فایل \fB/etc/hosts\fR کانتینر نیز موجود خواهد بود. یک فایل مبنای متفاوت را می‌توان با استفاده از پیکربندی \fIbase_hosts_file\fP در \fBcontainers.conf\fR تنظیم کرد. .SS \fBAnnotation=key=value\fR افزودن یک یادداشت (annotation) به کانتینر. این گزینه می‌تواند چندین بار تنظیم شود. .SS \fBAutoUpdate=registry\fR مشخص می‌کند که آیا کانتینر به‌طور خودکار به‌روزرسانی شود یا خیر (podman-auto-update(1)). مقادیر زیر پشتیبانی می‌شوند: .IP \(bu 2 \fBregistry\fR: نیاز دارد که یک مرجع ایمیج کاملاً واجد شرایط (مانند quay.io/podman/stable:latest) برای ایجاد کانتینر استفاده شود. این الزام برای دانستن این است که کدام ایمیج باید واقعاً بررسی و دریافت (pull) شود. اگر از شناسه ایمیج استفاده شده باشد، پادمن دیگر نمی‌داند کدام ایمیج را بررسی/دریافت کند. .IP \(bu 2 \fBlocal\fR: به پادمن اعلام می‌کند ایمیجی را که کانتینر استفاده می‌کند با ایمیجی با نام خام آن در حافظه محلی مقایسه کند. اگر ایمیج به‌صورت محلی به‌روزرسانی شود، پادمن به‌سادگی واحد systemd اجراکننده کانتینر را بازراه‌اندازی (restart) می‌کند. .SS \fBCgroupsMode=how\fR تعیین می‌کند که آیا کانتینر cgroup ایجاد کند یا خیر. .PP به‌طور پیش‌فرض، حالت cgroups کانتینر ایجادشده توسط Quadlet برابر با \fBsplit\fR است که با پیش‌فرض (\fBenabled\fR) استفاده‌شده در رابط خط فرمان Podman تفاوت دارد. .PP اگر کانتینر به یک پاد متصل شود (یعنی \fBPod=\fR مشخص شده باشد)، ممکن است بخواهید این را به \fBno-conmon\fR یا \fBenabled\fR تغییر دهید تا محدودیت‌های منابع cgroup در سطح پاد اعمال شوند. .PP گزینه \fBenabled\fP یک cgroup جدید در زیر cgroup-parent ایجاد می‌کند. گزینه \fBdisabled\fP کانتینر را مجبور می‌کند که cgroup ایجاد نکند و بنابراین با گزینه‌های cgroup یعنی (\fB--cgroupns\fP و \fB--cgroup-parent\fP) تداخل دارد. گزینه \fBno-conmon\fP ایجاد cgroup جدید را فقط برای فرآیند \fBconmon\fP غیرفعال می‌کند. گزینه \fBsplit\fP گروه cgroup فعلی را به دو زیرگروه cgroup تقسیم می‌کند: یکی برای conmon و دیگری برای بار مفید کانتینر (container payload). تنظیم \fB--cgroup-parent\fP همراه با \fBsplit\fP امکان‌پذیر نیست. .SS \fBContainerName=name\fR اختصاص یک نام به کانتینر. .PP اپراتور می‌تواند یک کانتینر را به سه روش شناسایی کند: .IP \(bu 2 شناسه طولانی UUID (مانند «f78375b1c487e03c9438c729345e54db9d20cfa2ac1fc3494b6eb60872e74778»)؛ .IP \(bu 2 شناسه کوتاه UUID (مانند «f78375b1c487»)؛ .IP \(bu 2 نام (مانند «jonah»). .PP پادمن برای هر کانتینر یک UUID تولید می‌کند، و اگر با استفاده از \fBContainerName=\fR نامی به کانتینر اختصاص داده نشود، پادمن یک نام رشته‌ای تصادفی مانند \fBexciting_chebyshev\fR (به‌صورت \fBصفت_اسم\fR، سازگار با داکر) تولید می‌کند. الزامی نیست که نام کانتینرها یک نام میزبان یا نام دامنه معتبر باشد. خط زیر (underscore) و سایر نویسه‌های مجاز طبق قوانین نام‌گذاری مجاز هستند. در شبکه‌های پادمن با DNS فعال، حل نام کانتینر به کانتینر همچنان از همان نام ارائه‌شده استفاده می‌کند، مثلاً \fBexciting_chebyshev\fR\&. این نام می‌تواند به‌عنوان روشی کاربرپسندتر برای شناسایی کانتینرها مفید باشد. این ویژگی هم برای کانتینرهای پس‌زمینه و هم پیش‌زمینه کار می‌کند. نام کانتینر همچنین با استفاده از آدرس IP اصلی کانتینر به فایل \fB/etc/hosts\fR اضافه می‌شود (همچنین به گزینه \fBAddHost=\fR مراجعه کنید). .PP این نام، نام میزبان (hostname) درون کانتینر نیست؛ به \fBHostName=\fR مراجعه کنید. برای اطلاعات بیشتر درباره DNS شبکه به \fBpodman-network(1)\fP مراجعه کنید. .SS \fBContainersConfModule=module\fR بارگذاری ماژول مشخص‌شده در containers.conf(5). .PP این گزینه می‌تواند چندین بار فهرست شود. .SS \fBDNS=ipaddr\fR تنظیم کارگزارهای DNS سفارشی. .PP این گزینه می‌تواند برای بازنویسی پیکربندی DNS ارسال‌شده به کانتینر استفاده شود. معمولاً این کار زمانی لازم است که پیکربندی DNS میزبان برای کانتینر نامعتبر باشد (مانند \fB127.0.0.1\fP). در این حالت، فلگ \fBDNS=.\fP برای هر اجرا ضروری است. .PP مقدار ویژه \fBnone\fP می‌تواند مشخص شود تا ایجاد فایل \fI/etc/resolv.conf\fP در کانتینر توسط پادمن غیرفعال گردد. در این صورت، فایل \fI/etc/resolv.conf\fP موجود در ایمیج بدون تغییر استفاده می‌شود. .PP توجه داشته باشید که \fBipaddr\fP ممکن است مستقیماً به \fI/etc/resolv.conf\fP کانتینر افزوده شود؛ با این حال این مورد تضمین‌شده نیست. به‌عنوان مثال، ارسال یک شبکه سفارشی که \fIdns_enabled\fP آن روی \fItrue\fP تنظیم شده است به \fB--network\fP باعث می‌شود \fI/etc/resolv.conf\fP فقط به سرور aardvark-dns اشاره کند. سپس aardvark-dns تمام پرس‌وجوهای نام‌های غیرکانتینری را به \fBipaddr\fP ارائه‌شده فوروارد می‌کند. .SS \fBDNSOption=option\fR تنظیم گزینه‌های سفارشی DNS. در صورت استفاده از \fBDNSOption=\fR همراه با \fBNetwork=\fR که روی \fBnone\fP یا \fBcontainer:\fP\fIid\fP تنظیم شده باشد، نامعتبر است. .SS \fBDNSSearch=domain\fR تنظیم دامنه‌های جستجوی سفارشی DNS. در صورت استفاده از \fBDNSSearch=\fR همراه با \fBNetwork=\fR که روی \fBnone\fP یا \fBcontainer:\fP\fIid\fP تنظیم شده باشد، نامعتبر است. از \fBDNSSearch=.\fP برای حذف دامنه جستجو استفاده کنید. .SS \fBDropCapability=capability\fR حذف این قابلیت‌ها از مجموعه قابلیت‌های پیش‌فرض پادمن، یا \fBall\fR برای حذف تمام قابلیت‌ها. .PP این یک فهرست از قابلیت‌ها است که با فاصله از هم جدا شده‌اند. .SS \fBEntrypoint="command"\fR بازنویسی ENTRYPOINT پیش‌فرض از ایمیج. .PP نقطه ورود (ENTRYPOINT) یک ایمیج شبیه به COMMAND است چرا که مشخص می‌کند هنگام شروع کانتینر چه فایل اجرایی باید اجرا شود، اما (به‌عمد) بازنویسی آن دشوارتر است. ENTRYPOINT ماهیت یا رفتار پیش‌فرض کانتینر را تعیین می‌کند. هنگامی که ENTRYPOINT تنظیم می‌شود، کانتینر طوری اجرا می‌شود که گویی خود آن فایل دودویی (binary) است، همراه با گزینه‌های پیش‌فرض. گزینه‌های بیشتر می‌توانند از طریق COMMAND ارسال شوند. اما، اگر کاربری بخواهد چیز دیگری را در داخل کانتینر اجرا کند، گزینه \fBEntrypoint=\fR امکان مشخص کردن یک ENTRYPOINT جدید را فراهم می‌سازد. .PP دستورات چندگزینه‌ای را در قالب یک رشته JSON مشخص کنید. .SS \fBEnvironment=env=value [env=value ...]\fR تنظیم متغیرهای محیطی. .PP این گزینه امکان تنظیم متغیرهای محیطی دلخواهی را فراهم می‌کند که در دسترس فرآیند راه‌اندازی‌شده در داخل کانتینر قرار می‌گیرند. اگر یک متغیر محیطی بدون مقدار مشخص شود، پادمن محیط میزبان را برای یافتن مقدار بررسی می‌کند و تنها در صورتی متغیر را تنظیم می‌کند که روی میزبان مقداردهی شده باشد. به‌عنوان یک حالت خاص، اگر یک متغیر محیطی که به \fB*\fR ختم می‌شود بدون مقدار مشخص گردد، پادمن متغیرهای محیط میزبان را برای یافتن مواردی که با آن پیشوند شروع می‌شوند جستجو کرده و آن متغیرها را به کانتینر اضافه می‌کند. .SS \fBEnvironmentFile=file\fR خواندن یک فایل خط‌به‌خط شامل متغیرهای محیطی. .SS \fBEnvironmentHost=\fR استفاده از محیط میزبان در داخل کانتینر. برای اولویت‌ها به یادداشت \fBEnvironment\fP در زیر مراجعه کنید. (این گزینه با کلاینت راه دور Podman، شامل ماشین‌های مک و ویندوز (به‌جز WSL2) در دسترس نیست). .SS \fBExec=command\fR آرگومان‌های اضافی برای کانتینر؛ این دقیقاً همان اثری را دارد که ارسال آرگومان‌های بیشتر پس از فراخوانی \fBpodman run \fR دارد. .PP قالب آن همانند خطوط فرمان systemd است، با این حال برخلاف دستورالعمل هم‌نام systemd یعنی \fBExecStart=\fR که روی سیستم‌فایل ریشه جاری عمل می‌کند، بسیار رایج است که ایمیج‌های کانتینر متادیتای \fBENTRYPOINT\fR یا \fBCMD\fR مخصوص به خود را داشته باشند که این فیلد با آن‌ها تعامل دارد. .PP انتظار پیش‌فرض برای بسیاری از ایمیج‌ها این است که ایمیج شامل یک \fBENTRYPOINT\fR با یک فایل دودویی پیش‌فرض باشد، و این فیلد آرگومان‌هایی را به آن نقطه ورود اضافه کند. .PP روش دیگر برای توصیف این مورد این است که عملکردی کاملاً مشابه با فیلد args در یک پاد Kubernetes دارد. .SS \fBExposeHostPort=port[/protocol]\fR نمایان ساختن (expose) یک درگاه (پورت) یا محدوده‌ای از درگاه‌ها (مانند \fBExpose=3300-3310\fP). پروتکل می‌تواند \fBtcp\fR، \fBudp\fR یا \fBsctp\fR باشد و در صورت عدم ارائه، \fBtcp\fR فرض می‌شود. این گزینه با دستورالعمل EXPOSE برای ساخت ایمیج مطابقت دارد و هیچ تاثیری بر قوانین واقعی شبکه ندارد مگر اینکه از \fB-P/--publish-all\fP برای فوروارد کردن از درگاه‌های تصادفی میزبان به تمام درگاه‌های نمایان‌شده استفاده شود. برای فوروارد کردن درگاه‌های خاص از میزبان به درون کانتینر، به‌جای این از گزینه \fBPublishPort=\fR استفاده کنید. .SS \fBGIDMap=[flags]container_gid:from_gid[:amount]\fR اجرای کانتینر در یک فضای نام کاربری جدید با استفاده از نگاشت GID ارائه‌شده. این گزینه با گزینه‌های \fBUserNS=\fR و \fBSubGIDMap=\fR تداخل دارد. این گزینه روشی برای نگاشت GIDهای میزبان به GIDهای کانتینر به همان شیوه‌ای که \fB--uidmap\fP شناسه‌های UID میزبان را به UIDهای کانتینر نگاشت می‌کند، فراهم می‌سازد. برای جزئیات به \fB--uidmap\fP مراجعه کنید. .PP نکته: گزینه \fBGIDMap=\fR نمی‌تواند همراه با گزینه \fBPod=\fR فراخوانی شود زیرا هنگام حضور در یک پاد، نمی‌توان gidmap را در سطح کانتینر تنظیم کرد. .SS \fBGlobalArgs=\fR این کلید شامل فهرستی از آرگومان‌ها است که مستقیماً پس از دستور \fBpodman\fR در فایل تولیدشده قرار می‌گیرند. این گزینه می‌تواند برای دسترسی به ویژگی‌های پادمن که توسط مولد (generator) پشتیبانی نمی‌شوند استفاده شود. از آنجا که مولد از تعاملات غیرمنتظره‌ای که این آرگومان‌ها ممکن است ایجاد کنند بی‌اطلاع است، استفاده از این گزینه توصیه نمی‌شود. .PP قالب این گزینه یک فهرست از آرگومان‌ها است که با فاصله از هم جدا شده‌اند، و می‌توان آن‌ها را به‌صورت جداگانه اسکیپ کرد تا شامل فاصله‌های خالی و سایر نویسه‌های کنترلی شوند. .PP این کلید می‌تواند چندین بار درج شود. .SS \fBGroup=gid\fR شناسه GID (عددی) برای اجرا به عنوان آن در داخل کانتینر. نیازی نیست که این شناسه با GID روی میزبان یکسان باشد (که می‌تواند با \fBUserNS\fR تغییر کند)، اما اگر مشخص نشود، این GID روی میزبان نیز استفاده می‌شود. .SS \fBGroupAdd=group | keep-groups\fR اختصاص گروه‌های اضافی به کاربر اصلی در حال اجرا درون فرآیند کانتینر. .IP \(bu 2 \fBkeep-groups\fR یک فلگ ویژه است که به پادمن می‌گوید دسترسی گروه‌های تکمیلی (supplementary group access) را حفظ کند. .PP به کانتینر اجازه می‌دهد از دسترسی گروه‌های تکمیلی کاربر استفاده کند. اگر سیستم‌های فایل یا دستگاه‌ها فقط توسط گروه کاربر بدون ریشه قابل دسترسی باشند، این فلگ به زمان اجرای OCI اعلام می‌کند که دسترسی گروه را به داخل کانتینر منتقل کند. در حال حاضر فقط با زمان اجرای OCI یعنی \fBcrun\fR در دسترس است. نکته: \fBkeep-groups\fR انحصاری است و نمی‌توان گروه‌های دیگر را همراه با این فلگ مشخص کرد. (برای دستورات راه دور، شامل ماشین‌های مک و ویندوز (به‌جز WSL2) در دسترس نیست). .SS \fBHealthCmd="command"\fR تنظیم یا تغییر دستور بررسی سلامت (healthcheck) برای کانتینر. این دستور، دستوری است که درون کانتینر اجرا شده و سلامت کانتینر را تعیین می‌کند. این دستور برای اعمال سایر گزینه‌های بررسی سلامت الزامی است. مقدار \fBnone\fP بررسی‌های سلامت موجود را غیرفعال می‌کند. .PP گزینه‌های متعدد می‌توانند در قالب یک آرایه JSON ارسال شوند؛ در غیر این صورت، دستور به‌عنوان یک آرگومان برای \fB/bin/sh -c\fP تفسیر می‌شود. .PP نکته: مقادیر پیش‌فرض حتی در صورتی که بررسی سلامت در ایمیج پیکربندی شده باشد استفاده می‌شوند. .SS \fBHealthInterval=interval\fR تنظیم بازه زمانی برای بررسی‌های سلامت. بازه زمانی \fBdisable\fP باعث می‌شود هیچ تایمر خودکاری راه‌اندازی نشود. مقدار پیش‌فرض \fB30s\fP است. .PP نکته: این پارامتر پیکربندی مربوط به بررسی سلامت در ایمیج را بازنویسی می‌کند. .SS \fBHealthLogDestination=directory_path\fR تنظیم مقصد ثبت گزارش بررسی سلامت (HealthCheck log). مسیر دایرکتوری، local یا events_logger (حالت local از فایل وضعیت کانتینر استفاده می‌کند) (پیش‌فرض: local). .IP \(bu 2 \fBlocal\fR: (پیش‌فرض) گزارش‌های HealthCheck در کانتینرهای overlay ذخیره می‌شوند (برای مثال: \fB$runroot/healthcheck.log\fR). .IP \(bu 2 \fBdirectory\fR: یک فایل لاگ به نام \fB-healthcheck.log\fR شامل لاگ‌های HealthCheck در دایرکتوری مشخص‌شده ایجاد می‌کند. .IP \(bu 2 \fBevents_logger\fR: لاگ با مکانیزم ثبت لاگ تنظیم‌شده توسط events_logger نوشته خواهد شد. این گزینه همچنین برای بهبود عملکرد در سیستمی با تعداد لاگ‌های زیاد، گزارش را در یک دایرکتوری پیش‌فرض ذخیره می‌کند. .SS \fBHealthMaxLogCount=number\fR تنظیم حداکثر تعداد تلاش‌ها در فایل لاگ HealthCheck (مقدار «0» به معنای تعداد نامحدود تلاش‌ها در فایل لاگ است) (پیش‌فرض: ۵ تلاش). .SS \fBHealthMaxLogSize=size\fR تنظیم حداکثر طول گزارش ذخیره‌شده HealthCheck بر حسب نویسه (کاراکتر) (مقدار «0» به معنای طول لاگ نامحدود است) (پیش‌فرض: ۵۰۰ نویسه). .SS \fBHealthOnFailure=action\fR اقدامی که باید پس از انتقال کانتینر به وضعیت ناسالم (unhealthy) انجام شود. پیش‌فرض \fBnone\fP است. .IP \(bu 2 \fBnone\fP: هیچ اقدامی انجام نمی‌دهد. .IP \(bu 2 \fBkill\fP: کانتینر را از بین می‌برد (kill). .IP \(bu 2 \fBrestart\fP: کانتینر را بازراه‌اندازی می‌کند (restart). عمل \fBrestart\fR را با فلگ \fB--restart\fR ترکیب نکنید. هنگام اجرا در داخل یک واحد systemd، برای استفاده از خط‌مشی بازراه‌اندازی systemd، استفاده از عملیات \fBkill\fR یا \fBstop\fR را در نظر بگیرید. .IP \(bu 2 \fBstop\fP: کانتینر را متوقف می‌کند (stop). .SS \fBHealthRetries=retries\fR تعداد دفعات تلاش مجدد مجاز قبل از اینکه بررسی سلامت ناسالم در نظر گرفته شود. مقدار پیش‌فرض \fB3\fP است. .PP نکته: این پارامتر می‌تواند پیکربندی بررسی سلامت در ایمیج را بازنویسی کند. .SS \fBHealthStartPeriod=period\fR زمان مقداردهی اولیه مورد نیاز برای راه‌اندازی (bootstrap) کانتینر. مقدار می‌تواند در قالبی مانند \fB2m3s\fP بیان شود. مقدار پیش‌فرض \fB0s\fP است. .PP نکته: دستور بررسی سلامت به محض راه‌اندازی کانتینر اجرا می‌شود؛ اگر بررسی سلامت موفقیت‌آمیز باشد، وضعیت سلامت کانتینر به \fBhealthy\fR به‌روزرسانی می‌شود. با این حال، اگر بررسی سلامت ناموفق باشد، وضعیت سلامت روی \fBstarting\fR باقی می‌ماند تا زمانی که بررسی سلامت موفق شود یا زمان \fBHealthStartPeriod=\fR به پایان برسد. اگر دستور بررسی سلامت پس از پایان زمان \fBHealthStartPeriod=\fR شکست بخورد، وضعیت سلامت به \fBunhealthy\fR به‌روزرسانی خواهد شد. دستور بررسی سلامت بر اساس مقدار \fBHealthInterval=\fR به‌صورت دوره‌ای اجرا می‌شود. .PP نکته: این پارامتر پیکربندی مربوط به بررسی سلامت در ایمیج را بازنویسی خواهد کرد. .SS \fBHealthStartupCmd="command"\fR تنظیم یک دستور بررسی سلامت هنگام راه‌اندازی برای کانتینر. این دستور در داخل کانتینر اجرا می‌شود و برای دروازه‌بانی (کنترل آغاز) بررسی سلامت عادی به کار می‌رود. هنگامی که دستور راه‌اندازی موفق شود، بررسی سلامت عادی آغاز شده و بررسی سلامت راه‌اندازی متوقف می‌شود. در صورت تمایل، اگر دستور به تعداد دفعات مشخصی با شکست مواجه شود، کانتینر بازراه‌اندازی می‌شود. بررسی سلامت راه‌اندازی می‌تواند برای اطمینان از این مورد استفاده شود که کانتینرهایی با مدت زمان راه‌اندازی طولانی تا زمانی که کاملاً راه‌اندازی نشده‌اند به‌عنوان ناسالم علامت‌گذاری نشوند. بررسی‌های سلامت راه‌اندازی فقط زمانی قابل استفاده هستند که بررسی سلامت عادی (از ایمیج کانتینر یا گزینه \fBHealthCmd=\fR) نیز تنظیم شده باشد. .SS \fBHealthStartupInterval=interval\fR تنظیم بازه زمانی برای بررسی سلامت راه‌اندازی. بازه زمانی \fBdisable\fP باعث می‌شود هیچ تایمر خودکاری راه‌اندازی نشود. مقدار پیش‌فرض \fB30s\fP است. .SS \fBHealthStartupRetries=retries\fR تعداد تلاش‌های مجاز قبل از اینکه بررسی سلامت راه‌اندازی کانتینر را بازراه‌اندازی کند. اگر روی \fB0\fP تنظیم شود، کانتینر هرگز بازراه‌اندازی نمی‌شود. مقدار پیش‌فرض \fB0\fP است. .SS \fBHealthStartupSuccess=retries\fR تعداد اجراهای موفق مورد نیاز قبل از اینکه بررسی سلامت راه‌اندازی موفقیت‌آمیز در نظر گرفته شود و بررسی سلامت عادی آغاز گردد. مقدار \fB0\fP به این معنی است که هر بار موفقیت، بررسی سلامت عادی را آغاز می‌کند. مقدار پیش‌فرض \fB0\fP است. .SS \fBHealthStartupTimeout=timeout\fR حداکثر زمانی که دستور بررسی سلامت راه‌اندازی فرصت دارد تا قبل از اینکه به‌عنوان ناموفق علامت‌گذاری شود، به پایان برسد. مقدار می‌تواند در یک قالب زمانی مانند \fB2m3s\fP بیان شود. مقدار پیش‌فرض \fB30s\fP است. .SS \fBHealthTimeout=timeout\fR حداکثر زمان مجاز برای تکمیل بررسی سلامت قبل از اینکه بازه زمانی ناموفق در نظر گرفته شود. همانند start-period، این مقدار می‌تواند در قالب زمانی مانند \fB1m22s\fP بیان شود. مقدار پیش‌فرض \fB30s\fP است. .PP نکته: پایان مهلت زمانی (timeout) بررسی سلامت را به‌عنوان ناموفق علامت‌گذاری می‌کند. اگر خود دستور بررسی سلامت طولانی‌تر از \fItimeout\fP مشخص‌شده اجرا شود، سیگنال \fBSIGKILL\fR برای آن ارسال خواهد شد. .PP نکته: این پارامتر پیکربندی مربوط به بررسی سلامت در ایمیج را بازنویسی می‌کند. .SS \fBHostName=name\fR تنظیم نام میزبان کانتینر در داخل کانتینر. .PP این گزینه فقط با فضای نام خصوصی UTS یعنی \fB--uts=private\fR (پیش‌فرض) قابل استفاده است. اگر \fBPod=\fR داده شده باشد و پاد از همان فضای نام UTS مشترک استفاده کند (پیش‌فرض)، نام میزبان پاد استفاده می‌شود. نام میزبان ارائه‌شده همچنین با استفاده از آدرس IP اصلی کانتینر به فایل \fB/etc/hosts\fR اضافه می‌شود (همچنین به گزینه \fBAddHost=\fR مراجعه کنید). .PP هنگامی که \fBHostName=\fR تنظیم نشده باشد و کانتینر از فضای نام خصوصی UTS (پیش‌فرض) استفاده کند، پادمن نام میزبان را روی ۱۲ نویسه اول شناسه کانتینر تنظیم می‌کند. نام کانتینر اختصاص‌داده‌شده با \fBContainerName=\fR استفاده نمی‌شود مگر اینکه \fIcontainer_name_as_hostname=true\fP در \fBcontainers.conf\fR تنظیم شده باشد. .PP دی‌ان‌اس شبکه پادمن نام کانتینر، شناسه کوتاه کانتینر (۱۲ نویسه اول)، و هر \fB--hostname\fP تنظیم‌شده به‌صورت صریح را به‌عنوان نام‌های DNS ثبت می‌کند. نام میزبان پیش‌فرض با نام مستعار شناسه کوتاه مطابقت دارد. به \fBpodman-network(1)\fP مراجعه کنید. .SS \fBHttpProxy=\fR به‌طور پیش‌فرض در صورت تنظیم متغیرهای محیطی پروکسی برای فرآیند پادمن، این متغیرها به داخل کانتینر ارسال می‌شوند. این رفتار را می‌توان با تنظیم مقدار روی \fBfalse\fP غیرفعال کرد. متغیرهای محیطی ارسال‌شده شامل \fBhttp_proxy\fP، \fBhttps_proxy\fP، \fBftp_proxy\fP، \fBno_proxy\fP و همچنین نسخه‌های حروف بزرگ آن‌ها هستند. این گزینه فقط زمانی مورد نیاز است که سیستم میزبان باید از پروکسی استفاده کند اما کانتینر نباید از هیچ پروکسی استفاده نماید. متغیرهای محیطی پروکسی مشخص‌شده برای کانتینر به هر روش دیگری، مقادیر منتقل‌شده از میزبان را بازنویسی می‌کنند (سایر روش‌های تعیین پروکسی برای کانتینر شامل ارسال مقادیر با فلگ \fB--env\fP یا مقداردهی ثابت (hardcode) محیط پروکسی در زمان ساخت کانتینر است). هنگامی که با کلاینت راه دور استفاده می‌شود، از متغیرهای محیطی پروکسی که روی فرآیند سرور تنظیم شده‌اند استفاده می‌کند. .PP پیش‌فرض \fBtrue\fP است. .SS \fBImage=name\fR ایمیجی که باید در کانتینر اجرا شود. توصیه می‌شود هم به دلایل عملکردی و هم به دلایل پایداری، به‌جای نام کوتاه از یک نام ایمیج کاملاً واجد شرایط (fully qualified) استفاده شود. .PP قالب نام همانند زمانی است که به \fBpodman pull\fR ارسال می‌شود. بنابراین، برای تضمین نسخه خاصی از ایمیج، از \fB:tag\fR یا خلاصه‌های دیجیتال (digests) پشتیبانی می‌کند. .PP حالت‌های خاص: .IP \(bu 2 اگر \fBname\fR ایمیج به \fB\&.image\fR ختم شود، Quadlet از ایمیج دریافت‌شده توسط فایل \fB\&.image\fR مربوطه استفاده می‌کند و سرویس systemd تولیدشده شامل یک وابستگی به \fB$name-image.service\fR (یا نام سرویس تنظیم‌شده در فایل .image) خواهد بود. توجه داشته باشید که فایل \fB\&.image\fR مربوطه باید وجود داشته باشد. .IP \(bu 2 اگر \fBname\fR ایمیج به \fB\&.build\fR ختم شود، Quadlet از ایمیج ساخته‌شده توسط فایل \fB\&.build\fR مربوطه استفاده می‌کند و سرویس systemd تولیدشده شامل یک وابستگی به \fB$name-build.service\fR خواهد بود. نکته: فایل \fB\&.build\fR مربوطه باید وجود داشته باشد. .SS \fBImageVolume=mode\fR به پادمن می‌گوید که چگونه با حجم‌های داخلی (builtin) ایمیج رفتار کند. پیش‌فرض \fBbind\fP است. .IP \(bu 2 \fBbind\fP: یک حجم نام‌گذاری‌شده ناشناس ایجاد شده و به درون کانتینر سوار (mount) می‌شود. .IP \(bu 2 \fBtmpfs\fP: حجم به‌صورت یک tmpfs بر روی کانتینر سوار می‌شود که به کاربران امکان می‌دهد محتوایی ایجاد کنند که پس از توقف کانتینر ناپدید می‌شود. .IP \(bu 2 \fBignore\fP: تمام حجم‌ها نادیده گرفته می‌شوند و هیچ اقدامی صورت نمی‌گیرد. .SS \fBIP=IPv4\fR مشخص کردن یک آدرس استاتیک IPv4 برای کانتینر، برای مثال \fB10.88.64.128\fP\&. این گزینه فقط زمانی می‌تواند استفاده شود که کانتینر تنها به یک شبکه متصل باشد - یعنی \fBNetwork=network-name\fP حداکثر یک بار استفاده شده باشد - و در صورتی که کانتینر از طریق \fBNetwork=container:\fIid\fP\fP به فضای نام شبکه کانتینر دیگری متصل نشده باشد. آدرس باید در محدوده آدرس‌های IP شبکه باشد (پیش‌فرض \fB10.88.0.0/16\fP). .PP برای تعیین چندین آدرس استاتیک IP برای هر کانتینر، چندین شبکه را با استفاده از گزینه \fBNetwork=\fR تنظیم کنید که برای هر کدام یک آدرس IP استاتیک با استفاده از حالت \fBip\fR آن گزینه مشخص شده باشد. .SS \fBIP6=IPv6\fR مشخص کردن یک آدرس استاتیک IPv6 برای کانتینر، برای مثال \fBfd46:db93:aa76:ac37::10\fP\&. این گزینه فقط زمانی می‌تواند استفاده شود که کانتینر تنها به یک شبکه متصل باشد - یعنی \fBNetwork=network-name\fP حداکثر یک بار استفاده شده باشد - و در صورتی که کانتینر از طریق \fBNetwork=container:\fIid\fP\fP به فضای نام شبکه کانتینر دیگری متصل نشده باشد. آدرس باید در محدوده آدرس‌های IPv6 شبکه باشد. .PP برای تعیین چندین آدرس استاتیک IPv6 برای هر کانتینر، چندین شبکه را با استفاده از گزینه \fBNetwork=\fR تنظیم کنید که برای هر کدام یک آدرس IPv6 استاتیک با استفاده از حالت \fBip6\fR آن گزینه مشخص شده باشد. .SS \fBLabel=key=value [key=value ...]\fR افزودن متادیتا به کانتینر. .SS \fBLogDriver=driver\fR درایور ثبت لاگ (logging driver) برای کانتینر. گزینه‌های در دسترس فعلی عبارتند از \fBk8s-file\fP، \fBjournald\fP، \fBnone\fP، \fBpassthrough\fP و \fBpassthrough-tty\fP، که \fBjson-file\fP برای سازگاری با اسکریپت‌ها نام مستعار \fBk8s-file\fP است (پیش‌فرض \fBjournald\fP). .PP دستور podman info زیر درایور پیش‌فرض ثبت لاگ سیستم را نمایش می‌دهد. .EX $ podman info --format '{{ .Host.LogDriver }}' journald .EE .PP درایور \fBpassthrough\fP جریان‌های استاندارد (stdin، stdout، stderr) را به کانتینر منتقل می‌کند. این درایور با کلاینت راه دور Podman، شامل ماشین‌های مک و ویندوز (به‌جز WSL2)، و روی یک tty مجاز نیست، زیرا در برابر حملات از طریق TIOCSTI آسیب‌پذیر است. .PP درایور \fBpassthrough-tty\fP مشابه \fBpassthrough\fP است، به جز اینکه در صورت تمایل واقعی کاربر، امکان استفاده از آن روی یک TTY نیز وجود دارد. .SS \fBLogOpt=name=value\fR گزینه‌های مخصوص درایور ثبت لاگ. .PP تنظیم پیکربندی سفارشی ثبت لاگ. مقادیر *name* زیر پشتیبانی می‌شوند: .PP \fBpath\fP: مشخص کردن مسیر فایل لاگ (برای مثال \fBLogOpt=path=/var/log/container/mycontainer.json\fP)؛ .PP \fBmax-size\fP: مشخص کردن حداکثر اندازه فایل لاگ (برای مثال \fBLogOpt=max-size=10mb\fP)؛ .PP \fBtag\fP: مشخص کردن یک برچسب لاگ سفارشی برای کانتینر (برای مثال \fBLogOpt=tag="{{.ImageName}}"\fP\&. این گزینه از همان کلیدهای \fBpodman inspect --format\fP پشتیبانی می‌کند. این گزینه در حال حاضر فقط توسط درایور لاگ \fBjournald\fP پشتیبانی می‌شود). .PP \fBlabel\fP: مشخص کردن یک برچسب متنی (label) لاگ سفارشی برای کانتینر (برای مثال \fB--log-opt label="CONTAINER_IMAGE={{.ImageName}}"\fP\&. این گزینه از همان کلیدهای \fBpodman inspect --format\fP پشتیبانی می‌کند. این گزینه می‌تواند چندین بار تکرار شود. این گزینه در حال حاضر فقط توسط درایور لاگ \fBjournald\fP پشتیبانی می‌شود). .SS \fBMask=/path/1:/path/2\fR مشخص کردن مسیرهای ماسک‌شده که با دونقطه از هم جدا می‌شوند: \fBMask=/path/1:/path/2\fR\&. یک مسیر ماسک‌شده در داخل کانتینر قابل دسترسی نیست. .SS \fBMemory=number[unit]\fR محدودیت حافظه. واحد \fIunit\fP می‌تواند \fBb\fP (بایت)، \fBk\fP (کیبی‌بایت)، \fBm\fP (مبی‌بایت) یا \fBg\fP (گیبی‌بایت) باشد. .PP اجازه می‌دهد حافظه در دسترس کانتینر محدود شود. اگر میزبان از حافظه swap پشتیبانی کند، تنظیم حافظه \fBMemory=\fR می‌تواند بزرگتر از RAM فیزیکی باشد. اگر محدودیت 0 مشخص شود (عدم استفاده از \fBMemory=\fR)، حافظه کانتینر محدود نمی‌شود. ممکن است حد واقعی به مضربی از اندازه صفحه (page size) سیستم‌عامل به بالا گرد شود (این مقدار بسیار بزرگ است، یعنی میلیون‌ها تریلیون). .PP این گزینه در سیستم‌های بدون ریشه با cgroups V1 پشتیبانی نمی‌شود. .SS \fBMount=type=TYPE,TYPE-SPECIFIC-OPTION[,...]\fR اتصال یک نقطه سوار کردن فایل‌سیستم (filesystem mount) به کانتینر. .PP حالت‌های خاص: .IP \(bu 2 برای \fBtype=volume\fR، اگر \fBsource\fR به \fB\&.volume\fR ختم شود، حجم نام‌گذاری‌شده پادمن تولیدشده توسط فایل \fB\&.volume\fR مربوطه استفاده می‌شود. .IP \(bu 2 برای \fBtype=image\fR، اگر \fBsource\fR به \fB\&.image\fR ختم شود، ایمیج تولیدشده توسط فایل \fB\&.image\fR مربوطه استفاده می‌شود. .PP در هر دو حالت، سرویس systemd تولیدشده شامل یک وابستگی به سرویس تولیدشده برای واحد مربوطه خواهد بود. نکته: فایل \fB\&.volume\fR یا \fB\&.image\fR مربوطه باید وجود داشته باشد. .PP انواع TYPEهای سوار کردن که در حال حاضر پشتیبانی می‌شوند عبارتند از: \fBartifact\fP، \fBbind\fP، \fBdevpts\fP، \fBglob\fP، \fBimage\fP، \fBramfs\fP، \fBtmpfs\fP و \fBvolume\fP\&. .PP گزینه‌های مشترک برای تمام انواع mount: .IP \(bu 2 \fIsrc\fP، \fIsource\fP: مشخصات مبدا سوار کردن برای \fBbind\fP، \fBglob\fP و \fBvolume\fP\&. اجباری برای \fBartifact\fP، \fBbind\fP، \fBglob\fP و \fBimage\fP\&. اختیاری برای \fBvolume\fP؛ در صورت حذف، یک حجم ناشناس ایجاد می‌شود. .IP \(bu 2 \fIdst\fP، \fIdest\fP، \fIdestination\fP، \fItarget\fP: مشخصات مقصد سوار کردن. .PP هنگامی که الگوهای مبدا (source globs) بدون دایرکتوری مقصد مشخص می‌شوند، فایل‌ها و پوشه‌ها با مسیر کامل خود در داخل کانتینر سوار می‌شوند. هنگامی که مقصد مشخص می‌شود، فایل‌ها و پوشه‌های منطبق با الگوی نام فایل پایه روی پوشه مقصد سوار می‌شوند. گزینه \fBtype=glob,src=/foo*,destination=/tmp/bar\fR به موتورهای کانتینر می‌گوید که فایل‌های میزبان منطبق با /foo* را در دایرکتوری /tmp/bar/ در کانتینر سوار کنند. .PP گزینه‌های مخصوص type=\fBartifact\fP: .IP \(bu 2 \fIdigest\fP: اگر منبع آرتیفکت شامل چندین حباب (blob) باشد، می‌توان یک چکیده (digest) تعیین کرد تا فقط همان حباب خاص با آن دایجست سوار شود. .IP \(bu 2 \fItitle\fP: اگر منبع آرتیفکت شامل چندین بلاب باشد، می‌توان یک عنوان تعیین کرد که با یادداشت \fBorg.opencontainers.image.title\fR مقایسه می‌شود. .IP \(bu 2 \fIname\fP: این می‌تواند برای بازنویسی نام فایلی که در داخل کانتینر برای سوار کردن استفاده می‌کنیم به کار رود. در یک آرتیفکت با یک بلاب، اگر \fIdst\fP یک دایرکتوری باشد نام همان‌طور که هست استفاده می‌شود و در غیر این صورت نادیده گرفته می‌شود. با یک آرتیفکت چندبلابی، نام همراه با پسوند شاخص \fB-x\fR استفاده خواهد شد که در آن x شاخص لایه در آرتیفکت است که از 0 شروع می‌شود. .PP آرگومان \fIsrc\fP شامل نام آرتیفکت است که باید از قبل به‌صورت محلی وجود داشته باشد. آرگومان \fIdst\fP شامل مسیر هدف است؛ اگر مسیر در کانتینر یک پوشه باشد، عنوان بلاب (یادداشت \fBorg.opencontainers.image.title\fR) به‌عنوان نام فایل استفاده شده و به مسیر ملحق می‌شود. اگر یادداشت وجود نداشته باشد، دایجست به‌جای آن به‌عنوان نام فایل استفاده می‌شود. این منجر می‌شود همه بلاب‌های آرتیفکت در مسیر داده‌شده درون کانتینر سوار شوند. .PP با این حال، اگر مسیر \fIdst\fP یک فایل موجود در کانتینر باشد، بلاب مستقیماً روی آن سوار می‌شود. این حالت فقط زمانی کار می‌کند که آرتیفکت شامل یک تک‌بلاب باشد یا یکی از مقادیر \fIdigest\fP یا \fItitle\fP مشخص شده باشد. .PP اگر مسیر \fIdst\fP از قبل در کانتینر وجود نداشته باشد، در صورتی که آرتیفکت شامل یک بلاب باشد، مانند حالت فایل موجود رفتار می‌کند و مستقیماً روی آن مسیر سوار می‌شود. اگر آرتیفکت بیش از یک بلاب داشته باشد، مانند حالت پوشه موجود رفتار می‌کند و هر بلاب را به‌عنوان فایلی در مسیر \fIdst\fP سوار می‌کند. .PP گزینه‌های مخصوص type=\fBvolume\fP: .IP \(bu 2 \fIro\fP, \fIreadonly\fP: \fItrue\fP یا \fIfalse\fP (پیش‌فرض در صورت عدم تعیین: \fIfalse\fP). .IP \(bu 2 \fIU\fP, \fIchown\fP: \fItrue\fP یا \fIfalse\fP (پیش‌فرض در صورت عدم تعیین: \fIfalse\fP). مالک و گروه حجم مبدأ را به صورت بازگشتی بر اساس UID و GID کانتینر تغییر می‌دهد. .IP \(bu 2 \fIsubpath\fP: فقط یک زیرمسیر مشخص درون حجم را به جای کل حجم سوار (mount) می‌کند. .IP \(bu 2 \fIrelabel\fP: \fIshared\fP, \fIprivate\fP\&. نقطه اتصال را به صورت بازگشتی پیمایش کرده و برچسب سیستم امنیتی (مانند SELinux) را روی هر فایل تنظیم می‌کند تا مجوزهای دسترسی از زمینه کانتینر اعطا شود. \fIshared\fP برچسبی اعمال می‌کند که به تمام کانتینرها مجوز می‌دهد، در حالی که \fIprivate\fP برچسبی اعمال می‌کند که تنها به این کانتینر خاص مجوز می‌دهد. .IP \(bu 2 \fIz\fP, \fIZ\fP: به ترتیب نام اختصاری برای \fIrelabel=shared\fP و \fIrelabel=private\fP هستند. .IP \(bu 2 \fIidmap\fP: در صورت تعیین، یک سوار شدن idmapped به فضای نام کاربری هدف در کانتینر ایجاد می‌کند. گزینه idmap تنها توسط پودمن در حالت با دسترسی ریشه (rootful) پشتیبانی می‌شود. هسته لینوکس اجازه استفاده از سیستم‌های فایل idmapped را به کاربران غیرممتاز نمی‌دهد. گزینه idmap از یک نگاشت سفارشی پشتیبانی می‌کند که می‌تواند با فضای نام کاربری مورد استفاده کانتینر متفاوت باشد. این نگاشت را می‌توان بعد از گزینه idmap به این صورت مشخص کرد: \fBidmap=uids=0-1-10#10-11-10;gids=0-100-10\fR\&. برای هر سه‌تایی، مقدار اول شروع شناسه‌های سیستم فایل پشتیبان است که به مقدار دوم روی میزبان نگاشت می‌شوند. طول این نگاشت در مقدار سوم مشخص می‌شود. محدوده‌های متعدد با # از هم جدا می‌شوند. اگر قبل از نگاشت مشخص‌شده یک '@' قرار گیرد، نگاشت نسبت به فضای نام کاربری کانتینر نسبی در نظر گرفته می‌شود. شناسه میزبان برای نگاشت به منظور لحاظ کردن موقعیت نسبی کاربر کانتینر در فضای نام کاربری کانتینر تغییر داده می‌شود. .PP گزینه‌های مخصوص type=\fBimage\fP: .IP \(bu 2 \fIrw\fP, \fIreadwrite\fP: \fItrue\fP یا \fIfalse\fP (پیش‌فرض در صورت عدم تعیین: \fIfalse\fP). .IP \(bu 2 \fIsubpath\fP: فقط یک مسیر مشخص درون ایمیج را به جای کل ایمیج سوار (mount) می‌کند. .PP گزینه‌های مخصوص \fBbind\fP و \fBglob\fP: .IP \(bu 2 \fIro\fP, \fIreadonly\fP: \fItrue\fP یا \fIfalse\fP (پیش‌فرض در صورت عدم تعیین: \fIfalse\fP). .IP \(bu 2 \fIbind-propagation\fP: \fIshared\fP، \fIslave\fP، \fIprivate\fP، \fIunbindable\fP، \fIrshared\fP، \fIrslave\fP، \fIrunbindable\fP یا \fBrprivate\fP (پیش‌فرض).[1] \[la]#Footnote1\[ra] همچنین صفحه راهنمای mount(2) را ببینید. .IP \(bu 2 \fIbind-nonrecursive\fP: سوار کردن اتصالی (bind mount) را به صورت بازگشتی تنظیم نمی‌کند. به طور پیش‌فرض بازگشتی است. .IP \(bu 2 \fIrelabel\fP: \fIshared\fP, \fIprivate\fP\&. نقطه اتصال را به صورت بازگشتی پیمایش کرده و برچسب سیستم امنیتی (مانند SELinux) را روی هر فایل تنظیم می‌کند تا مجوزهای دسترسی از زمینه کانتینر اعطا شود. \fIshared\fP برچسبی اعمال می‌کند که به تمام کانتینرها مجوز می‌دهد، در حالی که \fIprivate\fP برچسبی اعمال می‌کند که تنها به این کانتینر خاص مجوز می‌دهد. .IP \(bu 2 \fIz\fP, \fIZ\fP: به ترتیب نام اختصاری برای \fIrelabel=shared\fP و \fIrelabel=private\fP هستند. .IP \(bu 2 \fIidmap\fP: در صورت تعیین، یک سوار شدن idmapped به فضای نام کاربری هدف در کانتینر ایجاد می‌کند. گزینه idmap تنها توسط پودمن در حالت با دسترسی ریشه (rootful) پشتیبانی می‌شود. هسته لینوکس اجازه استفاده از سیستم‌های فایل idmapped را به کاربران غیرممتاز نمی‌دهد. گزینه idmap از یک نگاشت سفارشی پشتیبانی می‌کند که می‌تواند با فضای نام کاربری مورد استفاده کانتینر متفاوت باشد. این نگاشت را می‌توان بعد از گزینه idmap به این صورت مشخص کرد: \fBidmap=uids=0-1-10#10-11-10;gids=0-100-10\fR\&. برای هر سه‌تایی، مقدار اول شروع شناسه‌های سیستم فایل پشتیبان است که به مقدار دوم روی میزبان نگاشت می‌شوند. طول این نگاشت در مقدار سوم مشخص می‌شود. محدوده‌های متعدد با # از هم جدا می‌شوند. اگر قبل از نگاشت مشخص‌شده یک '@' قرار گیرد، نگاشت نسبت به فضای نام کاربری کانتینر نسبی در نظر گرفته می‌شود. شناسه میزبان برای نگاشت به منظور لحاظ کردن موقعیت نسبی کاربر کانتینر در فضای نام کاربری کانتینر تغییر داده می‌شود. .IP \(bu 2 \fIU\fP, \fIchown\fP: \fItrue\fP یا \fIfalse\fP (پیش‌فرض در صورت عدم تعیین: \fIfalse\fP). مالک و گروه حجم مبدأ را به صورت بازگشتی بر اساس UID و GID کانتینر تغییر می‌دهد. .IP \(bu 2 \fIno-dereference\fP: پیوندهای نمادین (symlinks) را دنبال نمی‌کند، بلکه مبدأ پیوند را در مقصد اتصال کپی می‌کند. .PP گزینه‌های مخصوص type=\fBtmpfs\fP و \fBramfs\fP: .IP \(bu 2 \fIro\fP, \fIreadonly\fP: \fItrue\fP یا \fIfalse\fP (پیش‌فرض در صورت عدم تعیین: \fIfalse\fP). .IP \(bu 2 \fItmpfs-size\fP: اندازه نقطه اتصال tmpfs/ramfs بر حسب بایت. در لینوکس به طور پیش‌فرض نامحدود است. .IP \(bu 2 \fItmpfs-mode\fP: حالت هشت‌هشتی فایل (octal file mode) مربوط به tmpfs/ramfs (برای مثال 700 یا 0700). .IP \(bu 2 \fItmpcopyup\fP: فعال‌سازی کپی به بالا (copyup) از دایرکتوری ایمیج در همان مکان به tmpfs/ramfs. به طور پیش‌فرض استفاده می‌شود. .PP هنگامی که مقصد tmpfs درون یک حجم یا اتصال اتصالی (bind mount) قرار دارد، فایل‌های اتصال والد نیز در tmpfs کپی می‌شوند تا محتوای والد قابل مشاهده باقی بماند. از \fBnotmpcopyup\fP برای سوار کردن یک tmpfs خالی استفاده کنید که زیردرخت اتصال والد را بپوشاند (shadow کند). .IP \(bu 2 \fInoatime\fP: به‌روزرسانی زمان‌های دسترسی فایل را هنگام خوانده شدن فایل غیرفعال می‌کند. .IP \(bu 2 \fInotmpcopyup\fP: کپی کردن فایل‌ها از ایمیج به tmpfs/ramfs را غیرفعال می‌کند. .PP هنگام سوار کردن یک tmpfs درون یک حجم یا bind mount از این گزینه استفاده کنید تا اطمینان حاصل شود که tmpfs به درستی زیردرخت اتصال والد را سایه می‌اندازد (پنهان می‌کند). .IP \(bu 2 \fIU\fP, \fIchown\fP: \fItrue\fP یا \fIfalse\fP (پیش‌فرض در صورت عدم تعیین: \fIfalse\fP). گزینه‌های uid و gid را برای سیستم فایل tmpfs بر اساس UID و GID کانتینر تنظیم می‌کند. این عمل بازگشتی \fBنیست\fP. .PP گزینه‌های مخصوص type=\fBdevpts\fP: .IP \(bu 2 \fIuid\fP: شناسه عددی UID مالک فایل (پیش‌فرض: 0). .IP \(bu 2 \fIgid\fP: شناسه عددی GID مالک فایل (پیش‌فرض: 0). .IP \(bu 2 \fImode\fP: ماسک دسترسی هشت‌هشتی برای فایل (پیش‌فرض: 600). .IP \(bu 2 \fImax\fP: حداکثر تعداد PTYها (پیش‌فرض: 1048576). .PP Examples: .IP \(bu 2 \fBtype=bind,source=/path/on/host,destination=/path/in/container\fR .IP \(bu 2 \fBtype=bind,src=/path/on/host,dst=/path/in/container,relabel=shared\fR .IP \(bu 2 \fBtype=bind,src=/path/on/host,dst=/path/in/container,relabel=shared,U=true\fR .IP \(bu 2 \fBtype=bind,src=/path/on/host,dst=/path/in/container,idmap\fR .IP \(bu 2 \fBtype=bind,src=/path/on/host,dst=/path/in/container,idmap=uids=0-1-10;gids=0-100-10\fR .IP \(bu 2 \fBtype=devpts,destination=/dev/pts\fR .IP \(bu 2 \fBtype=glob,src=/usr/lib/libfoo*,destination=/usr/lib,ro=true\fR .IP \(bu 2 \fBtype=image,source=fedora,destination=/fedora-image,rw=true\fR .IP \(bu 2 \fBtype=ramfs,tmpfs-size=512M,destination=/path/in/container\fR .IP \(bu 2 \fBtype=tmpfs,tmpfs-size=512M,destination=/path/in/container\fR .IP \(bu 2 \fBtype=tmpfs,destination=/path/in/container,noswap\fR .IP \(bu 2 \fBtype=artifact,src=quay.io/libpod/testartifact:20250206-single,dst=/data\fR .IP \(bu 2 \fBtype=artifact,src=quay.io/libpod/testartifact:20250206-multi,dst=/data,title=test1\fR .IP \(bu 2 \fBtype=volume,destination=/path/in/container\fR .IP \(bu 2 \fBtype=volume,src=test_vol,dst=/data,subpath=/code/docs\fR .SS \fBNetwork=mode\fR تنظیم حالت شبکه برای کانتینر. .PP موارد خاص: .IP \(bu 2 اگر \fBname\fR شبکه با \fB\&.network\fR خاتمه یابد، یک شبکه پودمن با نام \fBsystemd-$name\fR استفاده می‌شود، و سرویس systemd تولیدشده شامل وابستگی به \fB$name-network.service\fR\& خواهد بود. چنین شبکه‌ای می‌تواند به طور خودکار با استفاده از یک فایل کوادلت \fB$name.network\fR ایجاد شود. توجه: فایل \fB\&.network\fR متناظر باید وجود داشته باشد. .IP \(bu 2 اگر \fBname\fR با \fB\&.container\fR خاتمه یابد، کانتینر از پشته شبکه کانتینر دیگری که توسط \fB$name.container\fR\& ایجاد شده مجدداً استفاده خواهد کرد. سرویس systemd تولیدشده شامل وابستگی به \fB$name.service\fR\& خواهد بود. توجه: فایل \fB\&.container\fR متناظر باید وجود داشته باشد. .PP مقادیر مجاز \fImode\fP عبارتند از: .IP \(bu 2 \fBbridge[:OPTIONS,...]\fP: یک پشته شبکه روی پل (bridge) پیش‌فرض ایجاد می‌کند. این مقدار پیش‌فرض برای کانتینرهای با دسترسی ریشه (rootful) است. امکان تعیین این گزینه‌های اضافی وجود دارد: .RS .IP \(bu 2 \fBalias=\fP\fIname\fP: افزودن نام مستعار در سطح شبکه برای کانتینر. .IP \(bu 2 \fBip=\fP\fIIPv4\fP: تعیین یک آدرس IPv4 ایستا برای این کانتینر. .IP \(bu 2 \fBip6=\fP\fIIPv6\fP: تعیین یک آدرس IPv6 ایستا برای این کانتینر. .IP \(bu 2 \fBmac=\fP\fIMAC\fP: تعیین یک آدرس MAC ایستا برای این کانتینر. .IP \(bu 2 \fBinterface_name=\fP\fIname\fP: تعیین نام برای رابط شبکه ایجادشده در داخل کانتینر. .IP \(bu 2 \fBhost_interface_name=\fP\fIname\fP: تعیین نام برای رابط شبکه ایجادشده در خارج از کانتینر. .RE .IP هر گزینه دیگری بدون اعتبارسنجی مستقیماً به netavark ارسال می‌شود. این امر می‌تواند برای ارسال آرگومان‌ها به پلاگین‌های netavark مفید باشد. برای شبکه‌های bridge بدون ریشه (rootless)، هدایت پورت (port forwarding) به طور پیش‌فرض از \fBrootlessport\fR استفاده می‌کند. تنظیم \fBrootless_port_forwarder="pasta"\fR در بخش \fB[network]\fR از \fBcontainers.conf(5)\fP روش هدایت را به هدایت در سطح هسته pasta (از طریق \fBpesto\fR) تغییر می‌دهد، که آدرس IP مبدأ اصلی کلاینت را درون کانتینر حفظ می‌کند. این گزینه آزمایشی است و رفتار آن ممکن است تغییر کند. برای مثال، جهت تعیین یک آدرس IPv4 ایستا و یک آدرس mac ایستا، از \fB--network bridge:ip=10.88.0.10,mac=44:33:22:11:00:99\fR\& استفاده کنید. .IP \(bu 2 \fI\fP\fB[:OPTIONS,...]\fP: اتصال به یک شبکه تعریف‌شده توسط کاربر؛ این مقدار، نام شبکه یا شناسه حاصل از یک شبکه ایجادشده با \fBpodman network create\fP\& است. امکان مشخص کردن همان گزینه‌های شرح داده شده در حالت bridge در بالا وجود دارد. برای مشخص کردن شبکه‌های بیشتر، چندین بار از گزینه \fB--network\fP استفاده کنید. .br برای سازگاری با نسخه‌های پیشین، همچنین می‌توان شبکه‌ها را با کاما در اولین آرگومان \fB--network\fP مشخص کرد، با این حال این کار مانع از استفاده شما از گزینه‌های شرح‌داده‌شده در بخش bridge در بالا می‌شود. .IP \(bu 2 \fBnone\fP: یک فضای نام شبکه برای کانتینر ایجاد می‌کند اما رابط‌های شبکه‌ای برای آن پیکربندی نمی‌کند، در نتیجه کانتینر هیچ‌گونه اتصال شبکه‌ای نخواهد داشت. .IP \(bu 2 \fBcontainer:\fP\fIid\fP: استفاده مجدد از پشته شبکه یک کانتینر دیگر. .IP \(bu 2 \fBhost\fP: استفاده از فضای نام شبکه میزبان برای کانتینر به جای ایجاد یک فضای نام ایزوله. هشدار: این کار به کانتینر دسترسی کامل به سوکت‌های انتزاعی دامین یونیکس (abstract Unix domain sockets) و سوکت‌های TCP/UDP مقید به localhost می‌دهد. از آنجا که این سازوکارها اغلب برای جلوگیری از دسترسی به سرویس‌های حساس سیستم و ایزوله‌سازی آنها از دسترسی نهادهای خارجی استفاده می‌شوند، به‌کارگیری این گزینه می‌تواند یک آسیب‌پذیری امنیتی تلقی شود. .IP \(bu 2 \fBns:\fP\fIpath\fP: مسیر فضای نام شبکه‌ای که باید به آن متصل شد. .IP \(bu 2 \fBprivate\fP: یک فضای نام جدید برای کانتینر ایجاد می‌کند. این گزینه برای کانتینرهای با دسترسی ریشه (rootful) از حالت \fBbridge\fP و برای کانتینرهای بدون ریشه (rootless) از \fBpasta\fP استفاده می‌کند. .IP \(bu 2 \fBpasta[:OPTIONS,...]\fP: استفاده از \fBpasta\fP(1) برای ایجاد یک پشته شبکه در حالت کاربری (user-mode). .br این گزینه حالت پیش‌فرض برای کانتینرهای بدون ریشه (rootless) است و تنها در حالت بدون ریشه پشتیبانی می‌شود. .br به طور پیش‌فرض، آدرس‌ها و مسیرهای IPv4 و IPv6، و همچنین نام رابط پاد از میزبان کپی می‌شوند. هدایت پورت آدرس IP مبدأ اصلی را حفظ می‌کند. گزینه‌های شرح داده شده در pasta(1) را می‌توان به صورت آرگومان‌های جداشده با کاما مشخص کرد. .br از نظر گزینه‌های pasta(1)، گزینه \fB--config-net\fP به طور پیش‌فرض برای پیکربندی شبکه در هنگام راه‌اندازی کانتینر ارائه می‌شود، و \fB--no-map-gw\fP نیز به طور پیش‌فرض فرض می‌شود تا از دسترسی مستقیم کانتینر به میزبان با استفاده از آدرس درگاه (gateway) جلوگیری شود. مورد دوم را می‌توان با ارسال \fB--map-gw\fP در گزینه‌های مخصوص pasta بازنویسی کرد (با وجود اینکه یک گزینه واقعی در pasta(1) نیست). .br برای ادغام بهتر با مدیریت DNS، مقدار \fB--dns-forward 169.254.1.1\fP به طور پیش‌فرض ارسال می‌شود، و این آدرس به عنوان اولین حل‌کننده به resolv.conf(5) اضافه می‌شود. در صورتی که نیاز به استفاده از آدرس IP متفاوتی باشد، می‌توان \fB--dns-forward\fP را به صورت صریح ارسال کرد. .br برای فعال شدن ورودی \fBhost.containers.internal\fR در /etc/hosts و اجازه برقراری ارتباط با میزبان، \fB--map-guest-addr 169.254.1.2\fP به طور پیش‌فرض ارسال می‌شود. مجدداً می‌توان آن را به طور صریح برای انتخاب آدرس IP دیگری تنظیم کرد. .br همچنین، در صورتی که هیچ هدایت پورت TCP یا UDP از میزبان به کانتینر پیکربندی نشده باشد (از طریق \fB--publish\fP پودمن یا با ارسال مستقیم گزینه‌های \fB-t\fP/\fB-u\fP در pasta)، به ترتیب مقادیر \fB-t none\fP و \fB-u none\fP ارسال می‌شوند تا هدایت خودکار پورت بر اساس پورت‌های متصل غیرفعال شود. به طور مشابه، \fB-T none\fP و \fB-U none\fP برای غیرفعال کردن همین عملکرد از کانتینر به میزبان داده می‌شوند. .br تمامی گزینه‌ها را می‌توان در \fBcontainers.conf(5)\fP نیز تنظیم کرد؛ کلید \fBpasta_options\fR را در زیر بخش network در آن فایل ببینید. .br چند مثال: .RS .IP \(bu 2 \fBpasta:--map-gw\fP: اجازه دسترسی مستقیم کانتینر به میزبان با استفاده از آدرس درگاه (gateway). .IP \(bu 2 \fBpasta:--mtu,1500\fP: تعیین MTU معادل 1500 بایت برای رابط \fItap\fP در کانتینر. .IP \(bu 2 \fBpasta:--ipv4-only,-a,10.0.2.0,-n,24,-g,10.0.2.2,--dns-forward,10.0.2.3,-m,1500,--no-ndp,--no-dhcpv6,--no-dhcp\fP: غیرفعال کردن IPv6، تخصیص \fB10.0.2.0/24\fR به رابط \fBtap0\fR در کانتینر، همراه با درگاه \fB10.0.2.3\fR، فعال‌سازی ارسال‌کننده DNS قابل دسترس در \fB10.0.2.3\fR، تنظیم MTU روی 1500 بایت، غیرفعال کردن پشتیبانی از NDP، DHCPv6 و DHCP. .IP \(bu 2 \fBpasta:-I,tap0,--ipv4-only,-a,10.0.2.0,-n,24,-g,10.0.2.2,--dns-forward,10.0.2.3,--no-ndp,--no-dhcpv6,--no-dhcp\fP: همانند بالا، اما باقی گذاشتن MTU روی 65520 بایت. .IP \(bu 2 \fBpasta:-t,auto,-u,auto,-T,auto,-U,auto\fP: فعال‌سازی هدایت خودکار پورت بر اساس پورت‌های متصل مشاهده‌شده از هر دو طرف میزبان و کانتینر. .IP \(bu 2 \fBpasta:-T,5201\fP: فعال‌سازی هدایت پورت TCP شماره 5201 از کانتینر به میزبان، با استفاده از رابط loopback به جای رابط tap جهت بهبود کارایی. .RE .SS \fBNetworkAlias=alias\fR افزودن نام مستعار در سطح شبکه برای کانتینر، و تنظیم این نام مستعار برای تمامی شبکه‌هایی که کانتینر به آنها می‌پیوندد. برای تنظیم یک نام فقط برای یک شبکه خاص، از گزینه alias به همان صورت شرح داده شده در زیر گزینه \fB--network\fP استفاده کنید. اگر شبکه دارای DNS فعال باشد (\fBpodman network inspect -f {{.DNSEnabled}} \fR)، این نام‌های مستعار را می‌توان برای تحلیل نام در شبکه مذکور استفاده کرد. این گزینه را می‌توان چندین بار مشخص کرد. .SS \fBNoNewPrivileges=bool\fR (پیش‌فرض: \fBfalse\fR) در صورت فعال بودن، فرآیندهای کانتینر را از کسب امتیازات و دسترسی‌های اضافی از طریق مواردی مانند setuid و قابلیت‌های فایل (file capabilities) منع می‌کند. .SS \fBNotify=bool\fR (پیش‌فرض: \fBfalse\fR) به طور پیش‌فرض، پودمن به گونه‌ای اجرا می‌شود که دستور اعلان راه‌اندازی systemd توسط زمان اجرای کانتینر مدیریت می‌شود. به عبارت دیگر، سرویس زمانی شروع‌شده تلقی می‌شود که زمان اجرای کانتینر، فرآیند فرزند را در کانتینر راه‌اندازی کند. با این حال، اگر برنامه کاربردی کانتینر از sd_notify پشتیبانی کند، تنظیم \fBNotify\fR روی true جزئیات اعلان را به کانتینر ارسال می‌کند و به آن اجازه می‌دهد راه‌اندازی خود را شخصاً اعلان کند. .PP علاوه بر این، تنظیم \fBNotify\fR روی \fBhealthy\fR اعلان‌های راه‌اندازی را تا زمانی که کانتینر طبق بررسی‌های سلامت پودمن به عنوان سالم (healthy) نشانه‌گذاری شود به تعویق می‌اندازد. توجه داشته باشید که این امر نیازمند تنظیم بررسی سلامت کانتینر است؛ برای اطلاعات بیشتر گزینه \fBHealthCmd\fR را ببینید. .SS \fBPidsLimit=limit\fR تنظیم حد مجاز PIDهای کانتینر. برای نامحدود بودن تعداد PIDهای کانتینر مقدار را برابر \fB-1\fP قرار دهید. پیش‌فرض در سیستم‌هایی که از کنترل‌کننده cgroup موسوم به "pids" پشتیبانی می‌کنند برابر \fB2048\fP است. .SS \fBPod=name\fR یک واحد کوادلت \fB\&.pod\fR را مشخص می‌کند تا کانتینر به آن متصل شود. مقدار باید به قالب \fB.pod\fR باشد و واحد \fB\&.pod\fR باید وجود داشته باشد. .PP کوادلت تمامی پارامترهای لازم را برای ایجاد پیوند بین کانتینر و پاد و بین سرویس‌های متناظر آنها اضافه خواهد کرد. .SS \fBPodmanArgs=\fR این کلید شامل فهرستی از آرگومان‌هاست که مستقیماً به انتهای دستور \fBpodman\fR در فایل تولیدشده ارسال می‌شوند. از این گزینه می‌توان برای دسترسی به قابلیت‌های پودمن که در غیر این صورت توسط تولیدکننده (generator) پشتیبانی نمی‌شوند استفاده کرد. از آنجا که مولد از تداخلات غیرمنتظره‌ای که ممکن است توسط این آرگومان‌ها ایجاد شود آگاه نیست، استفاده از این گزینه توصیه نمی‌شود. .PP قالب این گزینه به صورت فهرستی از آرگومان‌های جداشده با فاصله است که می‌توان به صورت اختیاری کاراکترهای اسکیپ را در آنها به کار برد تا امکان گنجاندن فاصله‌ها و سایر کاراکترهای کنترلی فراهم شود. .PP این کلید می‌تواند چندین بار درج شود. .SS \fBPublishPort=[[hostIP:][hostPort]:]containerPort[/protocol]\fR انتشار یک پورت یا محدوده‌ای از پورت‌های کانتینر روی میزبان. .PP هر دو مقدار \fIhostPort\fP و \fIcontainerPort\fP می‌توانند به عنوان محدوده‌ای از پورت‌ها تعیین شوند. هنگام مشخص کردن محدوده برای هر دو، تعداد پورت‌های کانتینر در محدوده باید با تعداد پورت‌های میزبان در محدوده مطابقت داشته باشد. .PP اگر \fIhostIP\fP برابر \fB0.0.0.0\fR باشد، تنها آدرس‌های IPv4 مقید می‌شوند؛ اگر روی \fB[::]\fR تنظیم شود، تنها آدرس‌های IPv6 مقید می‌شوند. در سایر موارد، دقیقاً همان آدرس IP داده‌شده مقید خواهد شد. اگر \fIhostIP\fP اصلاً تنظیم نشده باشد، پورت روی تمام آدرس‌های IP میزبان، هم v4 و هم v6 (در صورت امکان)، مقید می‌شود. .PP مقدار پیش‌فرض \fIhostIP\fP را می‌توان در \fBcontainers.conf(5)\fP با استفاده از گزینه \fBdefault_host_ips\fR در زیر بخش \fB[network]\fR پیکربندی کرد. این گزینه یک آرایه را می‌پذیرد تا بتوان چندین آدرس IP قیدشده را مشخص نمود. برای مثال، تنظیم \fBdefault_host_ips = ["127.0.0.1", "::1"]\fR باعث می‌شود پورت به ترتیب روی آدرس localhost نسخه ipv4 و ipv6 منتشر شود. یک \fIhostIP\fP صریح که در دستور مشخص شود، همیشه بر گزینه پیکربندی ارجحیت دارد. .PP به طور پیش‌فرض، پودمن پورت‌های TCP را منتشر می‌کند. برای انتشار پورت UDP به جای آن، \fBudp\fR را به عنوان پروتکل مشخص کنید. برای انتشار هر دو نوع پورت TCP و UDP، گزینه \fB--publish\fR را دو بار با پروتکل‌های \fBtcp\fR و \fBudp\fR تنظیم کنید. کانتینرهای با دسترسی ریشه (rootful) می‌توانند پورت‌ها را با استفاده از پروتکل \fBsctp\fR نیز منتشر کنند. .PP نیازی به تعیین حتمی پورت میزبان نیست (مانند \fBpodman run -p 127.0.0.1::80\fR). اگر تعیین نشود، یک پورت روی میزبان به صورت تصادفی به پورت کانتینر اختصاص داده می‌شود. .PP برای مشاهده نگاشت واقعی از \fBpodman port\fP استفاده کنید: \fBpodman port $CONTAINER $CONTAINERPORT\fR\&. .PP انتشار پورت تنها برای کانتینرهایی پشتیبانی می‌شود که از فضای نام شبکه اختصاصی خود از طریق شبکه‌های \fBbridge\fR یا حالت شبکه \fBpasta\fR استفاده می‌کنند. .PP برای شبکه‌های bridge بدون ریشه (rootless)، هدایت پورت به طور پیش‌فرض از \fBrootlessport\fR استفاده می‌کند، که یک پراکسی فضای کاربری است و IP مبدأ کلاینت را حفظ نمی‌کند. تنظیم \fBrootless_port_forwarder="pasta"\fR در بخش \fB[network]\fR از \fBcontainers.conf(5)\fP روش هدایت را به هدایت در سطح هسته pasta از طریق \fBpesto\fR تغییر می‌دهد، که آدرس IP اصلی کلاینت را درون کانتینر حفظ می‌کند. این گزینه آزمایشی است و رفتار آن ممکن است تغییر کند. .SS \fBPull=policy\fR سیاست دریافت (pull) ایمیج. مقدار پیش‌فرض \fBmissing\fP\& است. .IP \(bu 2 \fBalways\fP: همیشه ایمیج را دریافت می‌کند و در صورت عدم موفقیت در دریافت، خطا صادر می‌کند. .IP \(bu 2 \fBmissing\fP: فقط زمانی که ایمیج در فضای ذخیره‌سازی محلی کانتینرها موجود نباشد آن را دریافت می‌کند. اگر هیچ ایمیجی یافت نشود و دریافت ناموفق باشد، خطا صادر می‌کند. .IP \(bu 2 \fBnever\fP: هرگز ایمیج را دریافت نمی‌کند، بلکه از ایمیج موجود در فضای ذخیره‌سازی محلی کانتینرها استفاده می‌کند. اگر هیچ ایمیجی یافت نشود، خطا صادر می‌کند. .IP \(bu 2 \fBnewer\fP: اگر ایمیج موجود در مخزن (registry) جدیدتر از نسخه موجود در فضای ذخیره‌سازی محلی کانتینرها باشد، آن را دریافت می‌کند. اگر چکیده‌ها (digests) متفاوت باشند، ایمیج جدیدتر تلقی می‌شود. مقایسه مهر زمانی مستعد خطاست. اگر یک ایمیج محلی یافت شود، خطاهای دریافت نادیده گرفته می‌شوند. .SS \fBReadOnly=\fR سوار کردن سیستم فایل ریشه کانتینر به صورت فقط‌خواندنی. .PP به طور پیش‌فرض، سیستم‌های فایل ریشه کانتینر قابل نوشتن هستند و به فرآیندها اجازه می‌دهند در هر مکانی فایل بنویسند. با تعیین فلگ \fBReadOnly=\fP، سیستم فایل ریشه کانتینر به صورت فقط‌خواندنی سوار شده و از هرگونه نوشتن جلوگیری می‌شود. .SS \fBReadOnlyTmpfs=true|false\fR هنگام اجرای کانتینرهای --read-only، یک tmpfs خواندنی-نوشتنی را روی \fI/dev\fP، \fI/dev/shm\fP، \fI/run\fP، \fI/tmp\fP و \fI/var/tmp\fP\& سوار می‌کند. مقدار پیش‌فرض \fBtrue\fP\& است. .TS allbox; l l l l l l l l . \fB--read-only\fP \fB--read-only-tmpfs\fP \fB/\fP \fB/run, /tmp, /var/tmp\fP true true r/o r/w true false r/o r/o false false r/w r/w false true r/w r/w .TE .PP هنگامی که \fBReadOnly=true\fP و \fBReadOnlyTmpfs=true\fP باشد، tmpfsهای اضافی روی دایرکتوری‌های /tmp، /run و /var/tmp سوار می‌شوند. .PP هنگامی که \fBReadOnly=true\fP و \fBReadOnlyTmpfs=false\fP باشد، مسیرهای /dev و /dev/shm به صورت فقط‌خواندنی نشانه‌گذاری می‌شوند و هیچ tmpfsای روی /tmp، /run و /var/tmp سوار نمی‌شود. این دایرکتوری‌ها از ایمیج زیرین نمایان می‌شوند، به این معنی که به طور پیش‌فرض فقط‌خواندنی هستند. این امر کانتینر را کاملاً فقط‌خواندنی می‌کند. هیچ دایرکتوری قابل نوشتنی در داخل کانتینر وجود نخواهد داشت. در این حالت دایرکتوری‌های قابل نوشتن باید از طریق حجم‌ها یا اتصالات خارجی اضافه شوند. .PP به طور پیش‌فرض، هنگامی که \fBReadOnly=false\fP باشد، دایرکتوری‌های /dev و /dev/shm خواندنی-نوشتنی هستند و /tmp، /run و /var/tmp نیز دایرکتوری‌های خواندنی-نوشتنی برگرفته از ایمیج کانتینر هستند. .SS \fBReloadCmd=/usr/bin/command\fR افزودن یک خط \fBExecReload=\fR به بخش \fBService\fR که دستور \fBpodman exec\fR را با این دستور در این کانتینر اجرا می‌کند. .PP برای بارگذاری مجدد سرویس، دستور \fBsystemctl reload \fR\& را اجرا کنید. .PP این گزینه مانعه‌الجمع با \fBReloadSignal\fR\& است. .SS \fBReloadSignal=signal\fR افزودن یک خط \fBExecReload=\fR به بخش \fBService\fR که دستور \fBpodman kill\fR را با این سیگنال اجرا می‌کند، که سیگنال را به فرآیند اصلی کانتینر ارسال می‌نماید. .PP برای بارگذاری مجدد سرویس، دستور \fBsystemctl reload \fR\& را اجرا کنید. .PP این گزینه مانعه‌الجمع با \fBReloadCmd\fR\& است. .SS \fBRetry=attempts\fR تعداد دفعات تلاش مجدد برای دریافت (pull) یا ارسال (push) ایمیج‌ها بین مخزن (registry) و فضای ذخیره‌سازی محلی در صورت بروز خطا. مقدار پیش‌فرض \fB3\fP\& است. .SS \fBRetryDelay=duration\fR مدت زمان تاخیر بین تلاش‌های مجدد هنگام دریافت یا ارسال ایمیج‌ها بین مخزن و فضای ذخیره‌سازی محلی در صورت بروز خطا. حالت پیش‌فرض شروع با دو ثانیه و سپس عقب‌نشینی نمایی است. در صورت تنظیم این مقدار، همین تاخیر استفاده شده و عقب‌نشینی نمایی رخ نمی‌دهد. .SS \fBRootfs=\fR در صورت تعیین، اولین آرگومان به یک کانتینر استخراج‌شده (exploded container) روی سیستم فایل اشاره دارد. .PP این گزینه با گزینه \fBImage\fR در تعارض است. .PP این گزینه برای اجرای کانتینر بدون نیاز به مدیریت ایمیج مفید است؛ فرض می‌شود rootfs کانتینر به صورت خارجی مدیریت می‌شود. .PP \fBOverlay Rootfs Mounts\fR .PP فلگ \fB:O\fR به پودمن می‌گوید که دایرکتوری حاصل از مسیر rootfs را به عنوان فضای ذخیره‌سازی با استفاده از \fBoverlay file system\fR\& سوار کند. فرآیندهای کانتینر می‌توانند محتوای درون نقطه اتصال را تغییر دهند که در فضای ذخیره‌سازی کانتینر در یک دایرکتوری جداگانه ذخیره می‌شود. در اصطلاحات overlay، دایرکتوری مبدأ لایه زیرین (lower) است، و دایرکتوری ذخیره‌سازی کانتینر لایه زبرین (upper) است. تغییرات اعمال‌شده در نقطه اتصال با اتمام اجرای کانتینر نابود می‌شوند، مشابه زمانی که یک نقطه اتصال tmpfs پیاده (unmount) می‌شود. .PP نکته: در سیستم‌های مجهز به \fBSELinux\fP، مسیر rootfs نیازمند برچسب صحیح است، که به طور پیش‌فرض \fBunconfined_u:object_r:container_file_t:s0\fP\& می‌باشد. .PP \fBidmap\fR .PP در صورت تعیین \fBidmap\fR، یک سوار شدن idmapped به فضای نام کاربری هدف در کانتینر ایجاد می‌شود. گزینه idmap از یک نگاشت سفارشی پشتیبانی می‌کند که می‌تواند با فضای نام کاربری مورد استفاده کانتینر متفاوت باشد. این نگاشت را می‌توان بعد از گزینه idmap به این صورت مشخص کرد: \fBidmap=uids=0-1-10#10-11-10;gids=0-100-10\fR\&. برای هر سه‌تایی، مقدار اول شروع شناسه‌های سیستم فایل پشتیبان است که به مقدار دوم روی میزبان نگاشت می‌شوند. طول این نگاشت در مقدار سوم داده می‌شود. محدوده‌های متعدد با # از هم جدا می‌شوند. .SS \fBRunInit=\fR اجرای یک سیستم init در داخل کانتینر که سیگنال‌ها را هدایت کرده و فرآیندهای زامبی را جمع‌آوری می‌کند. باینری container-init در مسیر \fB/run/podman-init\fR\& سوار می‌شود. سوار کردن روی مسیر \fB/run\fR اجرای کانتینر را دچار اختلال می‌کند. .SS \fBSeccompProfile=path\fR تنظیم نمایه seccomp مورد استفاده در کانتینر. در صورت عدم تنظیم، نمایه پیش‌فرض پودمن استفاده می‌شود. مقدار را برابر مسیر یک فایل JSON یا \fBunconfined\fR قرار دهید تا فیلترهای seccomp غیرفعال شوند. .SS \fBSecret=secret[,opt=opt ...]\fR اعطای دسترسی به یک سکرت (راز/داده محرمانه) به کانتینر. می‌تواند چندین بار مشخص شود. .PP یک سکرت، بلوکی از داده‌های حساس است که کانتینر در زمان اجرا به آن نیاز دارد اما در ایمیج یا در سیستم کنترل نسخه ذخیره نمی‌شود، مانند نام‌های کاربری و گذرواژه‌ها، گواهی‌ها و کلیدهای TLS، کلیدهای SSH یا سایر رشته‌های مهم عمومی یا محتوای باینری (تا سقف اندازه 512 کیلوبایت). .PP هنگامی که سکرت‌ها از نوع \fBmount\fR مشخص شوند، سکرت‌ها هنگام ایجاد کانتینر کپی شده و درون کانتینر سوار می‌شوند. هنگامی که سکرت‌ها از نوع \fBenv\fR مشخص شوند، سکرت به عنوان یک متغیر محیطی درون کانتینر تنظیم می‌شود. سکرت‌ها در زمان ایجاد کانتینر درون کانتینر نوشته می‌شوند، و اصلاح سکرت با استفاده از دستورات \fBpodman secret\fR پس از ایجاد کانتینر بر سکرت داخل کانتینر تأثیر می‌گذارد. .PP سکرت‌ها و محل ذخیره‌سازی آنها با استفاده از دستور \fBpodman secret\fR مدیریت می‌شوند. .PP گزینه‌های Secret .IP \(bu 2 \fBtype=mount|env\fR : نحوه ارائه سکرت به کانتینر. \fBmount\fR سکرت را به عنوان یک فایل درون کانتینر سوار می‌کند. \fBenv\fR سکرت را به عنوان یک متغیر محیطی در معرض کانتینر قرار می‌دهد. پیش‌فرض برابر \fBmount\fR\& است. .IP \(bu 2 \fBtarget=target\fR : هدف سکرت. برای سکرت‌های سوارشده (mounted)، این مقدار مسیر سکرت درون کانتینر است. اگر یک مسیر کامل ارائه شود، سکرت در همان مکان سوار می‌شود. در غیر این صورت، سکرت به \fB/run/secrets/target\fR برای کانتینرهای لینوکس یا \fB/var/run/secrets/target\fR برای کانتینرهای FreeBSD سوار می‌شود. اگر هدف تنظیم نشده باشد، سکرت به طور پیش‌فرض در \fB/run/secrets/secretname\fR سوار می‌شود. برای سکرت‌های env، این مقدار کلید متغیر محیطی است. پیش‌فرض برابر \fBsecretname\fR\& است. .IP \(bu 2 \fBuid=0\fR : شناسه UID سکرت. پیش‌فرض برابر 0 است. فقط برای سکرت‌های نوع mount. .IP \(bu 2 \fBgid=0\fR : شناسه GID سکرت. پیش‌فرض برابر 0 است. فقط برای سکرت‌های نوع mount. .IP \(bu 2 \fBmode=0\fR : حالت (mode) سکرت. پیش‌فرض برابر 0444 است. فقط برای سکرت‌های نوع mount. .PP مثال‌ها .PP سوار کردن در \fB/my/location/mysecret\fR با UID برابر 1: .EX --secret mysecret,target=/my/location/mysecret,uid=1 .EE .PP سوار کردن در \fB/run/secrets/customtarget\fR با mode برابر 0777: .EX --secret mysecret,target=customtarget,mode=0777 .EE .PP ایجاد یک متغیر محیطی سکرت با نام \fBENVSEC\fR: .EX --secret mysecret,type=env,target=ENVSEC .EE .SS \fBSecurityLabelDisable=bool\fR غیرفعال کردن تفکیک برچسب (label separation) برای کانتینر. .SS \fBSecurityLabelFileType=label\fR تنظیم نوع برچسب فایل برای فایل‌های کانتینر. .SS \fBSecurityLabelLevel=s0:c1,c2\fR تنظیم سطح برچسب فرآیند برای فرآیندهای کانتینر. .SS \fBSecurityLabelNested=bool\fR اجازه به SecurityLabelها برای عملکرد در داخل کانتینر. این امر امکان تفکیک کانتینرهای ایجادشده درون کانتینر را فراهم می‌کند. .SS \fBSecurityLabelType=type\fR تنظیم نوع برچسب فرآیند برای فرآیندهای کانتینر. .SS \fBShmSize=number[unit]\fR اندازه \fI/dev/shm\fP\&. یک \fIunit\fP می‌تواند \fBb\fP (بایت)، \fBk\fP (کیبی‌بایت)، \fBm\fP (مبی‌بایت) یا \fBg\fP (گیبی‌بایت) باشد. اگر یکا (واحد) ذکر نشود، سیستم از بایت استفاده می‌کند. اگر اندازه ذکر نشود، مقدار پیش‌فرض \fB64m\fP\& است. هنگامی که \fIsize\fP برابر \fB0\fP باشد، هیچ محدودیتی روی میزان حافظه مورد استفاده کانتینر برای IPC وجود نخواهد داشت. این گزینه با \fB--ipc=host\fP\& در تعارض است. .SS \fBStartWithPod=bool\fR راه‌اندازی کانتینر پس از ایجاد پاد مرتبط. پیش‌فرض برابر \fBtrue\fP\& است. .PP اگر \fBtrue\fR باشد، کانتینر در کنار پاد شروع/متوقف/بازراه‌اندازی خواهد شد. .PP اگر \fBfalse\fR باشد، کانتینر هنگام شروع به کار پاد راه‌اندازی نمی‌شود. کانتینر همراه با پاد متوقف خواهد شد. بازراه‌اندازی پاد همچنین کانتینر را بازراه‌اندازی خواهد کرد، به شرطی که کانتینر نیز قبلاً در حال اجرا بوده باشد. .PP توجه: کانتینر همچنان می‌تواند با پیکربندی بخش \fB[Install]\fR به صورت دستی یا از طریق یک هدف (target) راه‌اندازی شود. در هر حال، پاد در صورت نیاز راه‌اندازی خواهد شد. .SS \fBStopSignal=signal\fR سیگنال مورد استفاده برای توقف کانتینر. پیش‌فرض \fBSIGTERM\fP\& است. .SS \fBStopTimeout=seconds\fR مهلت زمانی برای توقف کانتینر. پیش‌فرض \fB10\fP\& است. اتصالات راه دور از containers.conf محلی برای مقادیر پیش‌فرض استفاده می‌کنند. .PP \fBنکته:\fP این مقدار باید کمتر از مهلت زمانی واقعی واحد systemd باشد تا اطمینان حاصل شود که دستور \fBpodman rm\fR توسط systemd متوقف (kill) نمی‌شود. .SS \fBSubGIDMap=name\fR اجرای کانتینر در یک فضای نام کاربری جدید با استفاده از نگاشت دارای \fIname\fP در فایل \fI/etc/subgid\fP. هنگام اجرا در حالت بدون ریشه (rootless)، کاربر برای استفاده از نگاشت به مجوزهای لازم نیاز دارد. به \fBsubgid\fP(5) مراجعه کنید. این فلگ با گزینه‌های \fBUserNS=\fP و \fBGIDMap=\fP\& در تعارض است. همراه با \fBGIDMap=\fP به گونه‌ای عمل می‌کند که گویی \fBGIDMap=\fP با تمام نگاشت‌های گروه \fIname\fP در \fI/etc/subgid\fP\& ارسال شده است. .SS \fBSubUIDMap=name\fR اجرای کانتینر در یک فضای نام کاربری جدید با استفاده از نگاشت دارای \fIname\fP در فایل \fI/etc/subuid\fP. هنگام اجرا در حالت بدون ریشه (rootless)، کاربر برای استفاده از نگاشت به مجوزهای لازم نیاز دارد. به \fBsubuid\fP(5) مراجعه کنید. این فلگ با گزینه‌های \fBUserNS=\fP و \fBUIDMap=\fP\& در تعارض است. همراه با \fBUIDMap=\fP به گونه‌ای عمل می‌کند که گویی \fBUIDMap=\fP با تمام نگاشت‌های کاربر \fIname\fP در \fI/etc/subuid\fP\& ارسال شده است. .SS \fBSysctl=name=value\fR پیکربندی پارامترهای فضای نام هسته در زمان اجرا. .PP برای فضای نام IPC، مقادیر sysctl زیر مجاز هستند: .IP \(bu 2 kernel.msgmax .IP \(bu 2 kernel.msgmnb .IP \(bu 2 kernel.msgmni .IP \(bu 2 kernel.sem .IP \(bu 2 kernel.shmall .IP \(bu 2 kernel.shmmax .IP \(bu 2 kernel.shmmni .IP \(bu 2 kernel.shm_rmid_forced .IP \(bu 2 مقادیر Sysctl که با fs.mqueue.* شروع می‌شوند .PP توجه: در صورت استفاده از گزینه \fB--ipc=host\fP، مقادیر sysctl بالا مجاز نیستند. .PP برای فضای نام شبکه، تنها مقادیر sysctl که با net.* شروع می‌شوند مجاز هستند. .PP توجه: در صورت استفاده از گزینه \fB--network=host\fP، مقادیر sysctl بالا مجاز نیستند. .SS \fBTimezone=timezone\fR تنظیم منطقه زمانی در کانتینر. این فلگ مناطق زمانی مبتنی بر منطقه جغرافیایی، زمان GMT، و همچنین \fBlocal\fR را می‌پذیرد که منطقه زمانی درون کانتینر را مطابق با دستگاه میزبان تنظیم می‌کند. برای مناطق زمانی معتبر به \fB/usr/share/zoneinfo/\fR مراجعه کنید. اتصالات راه دور از containers.conf محلی برای مقادیر پیش‌فرض استفاده می‌کنند. .SS \fBTmpfs=\fR ایجاد یک نقطه اتصال tmpfs. .PP سوار کردن یک سیستم فایل موقت (\fBtmpfs\fP) در یک کانتینر، برای مثال: .EX $ podman podman-container.unit.5.md.in -d --tmpfs /tmp:rw,size=787448k,mode=1777 my_image .EE .PP این دستور یک \fBtmpfs\fP را در مسیر \fI/tmp\fP درون کانتینر سوار می‌کند. گزینه‌های سوار کردن پشتیبانی‌شده همان فلگ‌های پیش‌فرض سوار کردن لینوکس هستند. اگر هیچ گزینه‌ای مشخص نشود، سیستم از گزینه‌های زیر استفاده می‌کند: \fBrw,noexec,nosuid,nodev\fP\&. .PP به طور پیش‌فرض، پودمن ویژگی \fBtmpcopyup\fP را روی اتصالات tmpfs فعال می‌کند، که محتویات دایرکتوری ایمیج زیرین را قبل از سوار کردن در tmpfs کپی می‌کند. این امر همچنین در مواردی که مقصد tmpfs درون یک حجم یا bind mount باشد صدق می‌کند: فایل‌های نقطه اتصال والد در tmpfs کپی می‌شوند، بنابراین محتوای والد قابل مشاهده باقی می‌ماند. برای سوار کردن یک tmpfs خالی که زیردرخت یک اتصال والد را بپوشاند (shadow کند)، از گزینه \fBnotmpcopyup\fP استفاده کنید: .EX $ podman podman-container.unit.5.md.in --volume myvolume:/data --tmpfs /data/sub:notmpcopyup my_image .EE .SS \fBUIDMap=[flags]container_uid:from_uid[:amount]\fR اجرای کانتینر در یک فضای نام کاربری جدید با استفاده از نگاشت UID ارائه‌شده. این گزینه با گزینه‌های \fBUserNS=\fP و \fBSubUIDMap=\fP در تعارض است. این گزینه راهکاری برای نگاشت شناسه‌های UID میزبان به UIDهای کانتینر ارائه می‌دهد. می‌توان آن را چندین بار برای نگاشت محدوده‌های مختلف ارسال کرد. .PP مقادیر ممکن برای \fIflags\fP اختیاری در ادامه این صفحه بررسی شده‌اند. مقدار \fIamount\fP اختیاری است و در صورت عدم تعیین، برابر \fB1\fP فرض می‌شود. .PP مقدار \fIfrom_uid\fP بر اساس کاربری است که دستور را اجرا می‌کند؛ چه کاربران با دسترسی ریشه (rootful) و چه کاربران بدون ریشه (rootless). .IP \(bu 2 کاربر ریشه (rootful): [\fIflags\fP]\fIcontainer_uid\fP:\fIhost_uid\fP[:\fIamount\fP] .IP \(bu 2 کاربر بدون ریشه (rootless): [\fIflags\fP]\fIcontainer_uid\fP:\fIintermediate_uid\fP[:\fIamount\fP] .PP \fBRootful mappings\fR .PP هنگامی که \fBpodman\fP توسط یک کاربر دارای امتیاز فراخوانی می‌شود، گزینه \fBUIDMap=\fP به عنوان یک نگاشت مستقیم بین UIDهای میزبان و UIDهای کانتینر عمل می‌کند. .PP host UID -> container UID .PP مقدار \fIamount\fP تعداد UIDهای متوالی که نگاشت می‌شوند را مشخص می‌کند. اگر به عنوان نمونه مقدار \fIamount\fP برابر با \fB4\fP باشد، نگاشت به شکل زیر خواهد بود: .TS allbox; l l l l . \fBhost UID\fP \fBcontainer UID\fP \fIfrom_uid\fP \fIcontainer_uid\fP \fIfrom_uid\fP + 1 \fIcontainer_uid\fP + 1 \fIfrom_uid\fP + 2 \fIcontainer_uid\fP + 2 \fIfrom_uid\fP + 3 \fIcontainer_uid\fP + 3 .TE .PP \fBRootless mappings\fR .PP هنگامی که \fBpodman\fP توسط یک کاربر فاقد امتیاز (یعنی در حال اجرای بدون ریشه) فراخوانی می‌شود، مقدار \fIfrom_uid\fP به عنوان یک «UID واسط» تفسیر می‌گردد. در حالت بدون ریشه، UIDهای میزبان به طور مستقیم به UIDهای کانتینر نگاشت نمی‌شوند. در عوض نگاشت طی دو مرحله انجام می‌شود: .PP host UID -> intermediate UID -> container UID .PP گزینه \fBUIDMap=\fP تنها بر مرحله دوم نگاشت اثر می‌گذارد. .PP مرحله نخست نگاشت توسط پادمن بر اساس محتوای فایل \fI/etc/subuid\fP و UID کاربری که پادمن را فراخوانی کرده تعیین می‌شود. .PP مرحله اول نگاشت: .TS allbox; l l l l . \fBhost UID\fP \fBintermediate UID\fP UID for Podman user 0 1st subordinate UID 1 2nd subordinate UID 2 3rd subordinate UID 3 nth subordinate UID n .TE .PP برای اینکه بتوان از UIDهای واسط بزرگ‌تر از صفر استفاده کرد، کاربر باید UIDهای فرعی پیکربندی‌شده در \fI/etc/subuid\fP داشته باشد. \fBsubuid\fP(5) را ببینید. .PP مرحله دوم نگاشت با \fBUIDMap=\fP پیکربندی می‌شود. .PP اگر به عنوان مثال \fIamount\fP برابر با \fB5\fP باشد، مرحله دوم نگاشت به صورت زیر خواهد بود: .TS allbox; l l l l . \fBintermediate UID\fP \fBcontainer UID\fP \fIfrom_uid\fP \fIcontainer_uid\fP \fIfrom_uid\fP + 1 \fIcontainer_uid\fP + 1 \fIfrom_uid\fP + 2 \fIcontainer_uid\fP + 2 \fIfrom_uid\fP + 3 \fIcontainer_uid\fP + 3 \fIfrom_uid\fP + 4 \fIcontainer_uid\fP + 4 .TE .PP هنگام اجرا در حالت بدون ریشه، پادمن از تمام محدوده‌های پیکربندی‌شده در فایل \fI/etc/subuid\fP استفاده می‌کند. .PP شناسه کاربر جاری به UID=0 در فضای نام کاربر بدون ریشه نگاشت می‌شود. هر محدوده اضافی به صورت متوالی پس از آن اضافه می‌گردد: .TS allbox; l l l l l l . \fBhost\fP \fBrootless user namespace\fP \fBlength\fP $UID 0 1 1 $FIRST_RANGE_ID $FIRST_RANGE_LENGTH 1+$FIRST_RANGE_LENGTH $SECOND_RANGE_ID $SECOND_RANGE_LENGTH .TE .PP \fBReferencing a host ID from the parent namespace\fR .PP به عنوان یک کاربر بدون ریشه، شناسه میزبان داده‌شده در \fBUIDMap=\fP یا \fBGIDMap=\fP از \fIفضای نام واسط\fP تولیدشده توسط پادمن نگاشت می‌شود. گاهی اوقات ارجاع مستقیم به \fIفضای نام میزبان\fP مطلوب است. این کار به صورت دستی با اجرای دستور \fBpodman unshare cat /proc/self/gid_map\fR، یافتن شناسه میزبان مورد نظر در ستون دوم خروجی، و دریافت شناسه واسط متناظر از ستون اول امکان‌پذیر است. .PP پادمن می‌تواند همه این کارها را با قرار دادن نماد \fB@\fR قبل از شناسه میزبان در نگاشت انجام دهد. برای نمونه، با تعیین \fB--gidmap 100000:@2000:1\fR، پادمن شناسه واسط متناظر با شناسه میزبان \fB2000\fR را جستجو کرده و شناسه واسط یافت‌شده را به شناسه کانتینر \fB100000\fR نگاشت می‌کند. شناسه میزبان داده‌شده باید به عنوان فرعی تعریف شده باشد (در غیر این صورت از ابتدا در فضای واسط نگاشت نخواهد شد). .PP اگر طول بیشتر از یک باشد، مثلاً با \fB--gidmap 100000:@2000:2\fR، پادمن شناسه‌های میزبان \fB2000\fR و \fB2001\fR را به ترتیب به \fB100000\fR و \fB100001\fR نگاشت خواهد کرد، صرف‌نظر از اینکه نگاشت واسط چگونه تعریف شده باشد. .PP \fBExtending previous mappings\fR .PP برخی از تغییرات نگاشت ممکن است پیچیده باشند. برای مثال، کاربری با یک نگاشت مانند \fB--gidmap="0:0:65000"\fR شروع می‌کند، که نیاز به تغییر دارد به گونه‌ای که شناسه والد \fB1\fR به جای آن به شناسه کانتینر \fB100000\fR نگاشت شود، و شناسه کانتینر \fB1\fR تخصیص‌نیافته باقی بماند. گزینه \fB--gidmap\fR متناظر به صورت \fB--gidmap="0:0:1" --gidmap="2:2:65534" --gidmap="100000:1:1"\fR درمی‌آید. .PP این شیوه‌نگارش را می‌توان با استفاده از فلگ \fB+\fR ساده کرد، که وظیفه شکستن نگاشت‌های قبلی و حذف هرگونه تخصیص متداخل با نگاشت داده‌شده را بر عهده دارد. این فلگ قبل از شناسه کانتینر به صورت زیر ارائه می‌شود: \fB--gidmap="0:0:65000" --gidmap="+100000:1:1"\fR .TS allbox; l l l l l l . \fBFlag\fP \fBExample\fP \fBDescription\fP \fB+\fR \fB+100000:1:1\fR گسترش نگاشت قبلی .TE .PP این شیوه باعث ایجاد شکاف‌هایی در تخصیص می‌شود، بنابراین ممکن است پر کردن این شکاف‌ها پس از آن مناسب باشد: \fB--gidmap="0:0:65000" --gidmap="+100000:1:1" --gidmap="1:65001:1"\fR .PP یک مورد استفاده خاص برای این فلگ در زمینه کاربران بدون ریشه است. یک کاربر بدون ریشه می‌تواند نگاشت‌ها را با فلگ \fB+\fR مانند \fB--gidmap="+100000:1:1"\fR مشخص کند. پادمن سپس با تمام شناسه‌های واسط باقی‌مانده، با شروع از صفر «شکاف‌ها را پر می‌کند». این زمانی مناسب است که کاربر بخواهد یک شناسه واسط خاص را به یک شناسه کانتینر نگاشت کند، و اجازه دهد بقیه شناسه‌های فرعی توسط پادمن به دلخواه نگاشت شوند. .PP \fBPassing only one of --uidmap or --gidmap\fR .PP معمولاً شناسه‌های فرعی کاربر و گروه به طور هم‌زمان تخصیص می‌یابند و برای هر کاربر، شناسه‌های فرعی کاربر با شناسه‌های فرعی گروه مطابقت دارند. برای راحتی، اگر فقط یکی از \fBUIDMap=\fP یا \fBGIDMap=\fP داده شود، پادمن فرض می‌کند که نگاشت به هر دو UID و GID اشاره دارد و نگاشت داده‌شده را روی هر دو اعمال می‌کند. اگر تنها یکی از این دو مقدار نیاز به تغییر داشته باشد، نگاشت‌ها باید شامل فلگ‌های \fBu\fR یا \fBg\fR باشند تا مشخص کنند که فقط روی UIDها یا GIDها اعمال می‌شوند و نباید روی دیگری کپی شوند. .TS allbox; l l l l l l . \fBflag\fP \fBExample\fP \fBDescription\fP \fBu\fR \fBu20000:2000:1\fR T{ نگاشت تنها بر UIDها اعمال می‌شود T} \fBg\fR \fBg10000:1000:1\fR T{ نگاشت تنها بر GIDها اعمال می‌شود T} .TE .PP برای نمونه با فرض دستور: .EX podman podman-container.unit.5.md.in --gidmap "0:0:1000" --gidmap "g2000:2000:1" .EE .PP از آنجا که هیچ \fBUIDMap=\fP مشخص نشده است، مقدار \fBGIDMap=\fP در \fBUIDMap=\fP کپی می‌شود، و دستوری معادل زیر حاصل می‌گردد: .EX podman podman-container.unit.5.md.in --gidmap "0:0:1000" --gidmap "2000:2000:1" --uidmap "0:0:1000" .EE .PP گزینه \fB--gidmap "g2000:2000:1"\fR از فلگ \fBg\fR استفاده کرده و بنابراین در \fBUIDMap=\fP کپی نشده است. .PP \fBRootless mapping of additional host GIDs\fR .PP یک کاربر بدون ریشه ممکن است بخواهد یک گروه میزبان خاص را که قبلاً در \fI/etc/subgid\fP به صورت فرعی تعریف شده است، بدون مشخص کردن بقیه نگاشت، نگاشت کند. .PP این کار را می‌توان با \fBGIDMap="+g\fIcontainer_gid\fP:@\fIhost_gid\fP"\fP انجام داد. .PP به طوری که: .IP \(bu 2 شناسه GID میزبان از طریق نماد \fB@\fR داده می‌شود. .IP \(bu 2 نگاشت این GID به لطف فلگ \fBg\fR به \fB--usermap\fP کپی نمی‌شود. .IP \(bu 2 بقیه شناسه‌های کانتینر به لطف فلگ \fB+\fR، با شروع از 0 تا n، با تمام GIDهای فرعی باقی‌مانده نگاشت می‌شوند. .PP برای مثال، اگر کاربری متعلق به گروه \fB2000\fR باشد و آن گروه به آن کاربر اختصاص یافته باشد (با \fBusermod --add-subgids 2000-2000 $USER\fR)، کاربر می‌تواند آن گروه را با دستور زیر به کانتینر نگاشت کند: \fBGIDMap=+g100000:@2000\fP\&. .PP اگر این نگاشت با گزینه \fBGroupAdd=keep-groups\fR ترکیب شود، فرآیند درون کانتینر به گروه \fB100000\fR تعلق خواهد داشت، و فایل‌های متعلق به گروه \fB2000\fR در میزبان به گونه‌ای دیده می‌شوند که گویی متعلق به گروه \fB100000\fR در داخل کانتینر هستند. .EX podman run --group-add=keep-groups --gidmap="+g100000:@2000" ... .EE .PP \fBNo subordinate UIDs\fR .PP حتی اگر کاربری هیچ UID فرعی در \fI/etc/subuid\fP نداشته باشد، با اجرای دستور \fBpodman podman-container.unit.5.md.in --uidmap $container_uid:0:1 --user $container_uid ...\fR همچنان می‌توان از \fBUIDMap=\fP برای نگاشت UID عادی کاربر به یک UID کانتینر استفاده کرد. .PP \fBPods\fR .PP گزینه \fBUIDMap=\fP را نمی‌توان همراه با گزینه \fBPod=\fP فراخوانی کرد، زیرا در زمان حضور در پاد نمی‌توان نگاشت uidmap را در سطح کانتینر تنظیم کرد. .SS \fBUlimit=option\fR گزینه‌های Ulimit. مقادیر ulimit را در داخل کانتینر تنظیم می‌کند. .PP --ulimit با یک حد نرم (soft) و سخت (hard) در قالب =[:] تنظیم می‌شود. برای نمونه: .PP $ podman run --ulimit nofile=1024:1024 --rm ubi9 ulimit -n 1024 .PP برای حد نرم یا سخت مقدار 1- را تعیین کنید تا حد به حداکثر مقدار مجاز فرآیند جاری تنظیم شود. در حالت با ریشه (rootful) این مقدار اغلب نامحدود (unlimited) است. .PP اگر nofile و nproc تنظیم نشده باشند، یک مقدار پیش‌فرض برابر با ۱۰۴۸۵۷۶ استفاده خواهد شد، مگر اینکه در containers.conf(5) لغو و بازنویسی شده باشد. با این حال، اگر مقدار پیش‌فرض از حد سخت برای کاربر بدون ریشه جاری فراتر رود، حد سخت جاری به جای آن اعمال خواهد شد. .PP از \fBhost\fP برای کپی کردن پیکربندی جاری از میزبان استفاده کنید. .PP از nproc با فلگ ulimit استفاده نکنید زیرا لینوکس از nproc برای تعیین حداکثر تعداد فرآیندهای در دسترس یک کاربر استفاده می‌کند، نه یک کانتینر. .PP از گزینه --pids-limit برای اصلاح کنترل cgroup به منظور محدود کردن تعداد فرآیندهای درون یک کانتینر استفاده کنید. .SS \fBUnmask=\fR مسیرهایی که باید از حالت پوشش (unmask) خارج شوند را مشخص کنید که با دو نقطه از هم جدا می‌شوند. unmask=ALL یا /path/1:/path/2، یا مسیرهای گسترش‌یافته توسط شل (/proc/*): .PP اگر روی \fBALL\fR تنظیم شود، پادمن تمام مسیرهایی را که به طور پیش‌فرض پوشش‌دار شده یا فقط‌خواندنی شده‌اند از حالت پوشش خارج می‌کند. .PP مسیرهای پیش‌فرض پوشش‌دار (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. .PP مسیرهای پیش‌فرض فقط‌خواندنی (read-only) عبارتند از: /proc/asound، /proc/bus، /proc/fs، /proc/irq، /proc/sys، /proc/sysrq-trigger، /sys/fs/cgroup. .SS \fBUser=user[:group]\fR نام کاربری یا UID مورد استفاده و در صورت تمایل، نام گروه یا GID را برای دستور مشخص‌شده تعیین می‌کند. هر دو مقدار \fIuser\fP و \fIgroup\fP می‌توانند نمادین یا عددی باشند. .PP بدون این آرگومان، دستور به عنوان کاربری که در ایمیج کانتینر مشخص شده اجرا می‌شود. مگر اینکه توسط یک دستور \fBUSER\fR در Containerfile یا توسط مقداری که به این گزینه داده شده بازنویسی شود، این کاربر به طور پیش‌فرض root است. .PP هنگامی که از فضای نام کاربر استفاده نمی‌شود، UID و GID مورد استفاده در داخل کانتینر با UID و GID میزبان مطابقت دارند. با این حال، هنگامی که فضاهای نام کاربر استفاده می‌شوند، UID و GID در کانتینر ممکن است با یک UID و GID دیگر روی میزبان متناظر باشند. برای نمونه، در کانتینرهای بدون ریشه همواره از فضای نام کاربر استفاده می‌شود، و کاربر root در کانتینر به طور پیش‌فرض متناظر با UID و GID کاربری است که پادمن را فراخوانی می‌کند. .SS \fBUserNS=mode\fR حالت فضای نام کاربر (user namespace mode) را برای کانتینر تنظیم می‌کند. .PP اگر \fB--userns\fR تنظیم نشده باشد، مقدار پیش‌فرض به شرح زیر تعیین می‌شود: - اگر \fB--pod\fR تنظیم شده باشد، \fB--userns\fR نادیده گرفته شده و از فضای نام کاربر پاد استفاده می‌شود. - اگر متغیر محیطی \fBPODMAN_USERNS\fP تنظیم شده باشد، مقدار آن استفاده می‌شود. - اگر \fBuserns\fR در \fBcontainers.conf\fR مشخص شده باشد، این مقدار استفاده می‌شود. - در غیر این صورت، \fB--userns=host\fR فرض می‌شود. .PP گزینه \fB--userns=""\fR (یعنی یک رشته خالی) یک نام مستعار برای \fB--userns=host\fR است. .PP این گزینه با گزینه‌های \fBGIDMap=\fP، \fBUIDMap=\fP، \fBSubUIDMap=\fP و \fBSubGIDMap=\fP ناسازگار است. .PP نگاشت‌های کلیدهای --userns برای کاربر بدون ریشه: .TS allbox; l l l l l l . \fBKey\fP \fBHost User\fP \fBContainer User\fP auto $UID T{ nil (شناسه UID کاربر میزبان به داخل کانتینر نگاشت نمی‌شود.) T} host $UID T{ 0 (حساب پیش‌فرض کاربر به کاربر root در کانتینر نگاشت می‌شود.) T} keep-id $UID T{ $UID (نگاشت حساب کاربر به همان UID در داخل کانتینر.) T} keep-id:uid=200,gid=210 $UID T{ 200:210 (نگاشت حساب کاربر به مقدار مشخص‌شده UID و GID در داخل کانتینر.) T} nomap $UID T{ nil (شناسه UID کاربر میزبان به داخل کانتینر نگاشت نمی‌شود.) T} .TE .PP مقادیر مجاز \fImode\fP عبارتند از: .PP \fBauto\fP[:\fIOPTIONS,...\fP]: ایجاد خودکار یک فضای نام کاربر یکتا. .IP \(bu 2 \fBحالت با ریشه (rootful)\fR: فلگ \fB--userns=auto\fR مستلزم آن است که نام کاربری \fBcontainers\fP در فایل‌های /etc/subuid و /etc/subgid مشخص شده باشد، همراه با یک محدوده استفاده‌نشده از شناسه‌های کاربری فرعی که کانتینرهای پادمن مجاز به تخصیص آن‌ها هستند. برای نمونه: \fBcontainers:2147483647:2147483648\fR\&. .IP \(bu 2 \fBحالت بدون ریشه (rootless)\fR: از محدوده کاربر در فایل‌های /etc/subuid و /etc/subgid استفاده خواهد شد. توجه داشته باشید که اجرای یک کانتینر واحد بدون استفاده از --userns=auto از تمام محدوده UIDها استفاده می‌کند و اجازه تقسیم‌بندی بیشتر را نمی‌دهد. subuid(5) را ببینید. .PP پادمن محدوده‌های یکتایی از UIDها و GIDها را از شناسه‌های کاربری فرعی \fBcontainers\fR تخصیص می‌دهد. اندازه این محدوده‌ها بر اساس تعداد UIDهای مورد نیاز در ایمیج است. تعداد UIDها و GIDها را می‌توان با گزینه \fBsize\fR لغو و بازنویسی کرد. .PP گزینه \fB--userns=keep-id\fR از تمامی subuidها و subgidهای کاربر استفاده می‌کند. گزینه \fB--userns=nomap\fR از تمامی subuidها و subgidهای کاربر به جز شناسه خود کاربر استفاده می‌کند. استفاده از \fB--userns=auto\fR هنگام راه‌اندازی کانتینرهای جدید تا زمانی که کانتینرهایی وجود داشته باشند که با \fB--userns=nomap\fR یا \fB--userns=keep-id\fR بدون محدود کردن اندازه فضای نام کاربر راه‌اندازی شده‌اند، کار نخواهد کرد. .PP گزینه‌های مجاز \fBauto\fR: .IP \(bu 2 \fIgidmapping\fP=\fICONTAINER_GID:HOST_GID:SIZE\fP: برای اجبار به حضور یک نگاشت GID در فضای نام کاربر. .IP \(bu 2 \fIsize\fP=\fISIZE\fP: برای مشخص کردن یک اندازه صریح برای فضای نام خودکار کاربر. به عنوان نمونه: \fB--userns=auto:size=8192\fR\&. اگر \fBsize\fR مشخص نشود، \fBauto\fR اندازه‌ای را برای فضای نام کاربر تخمین می‌زند. .IP \(bu 2 \fIuidmapping\fP=\fICONTAINER_UID:HOST_UID:SIZE\fP: برای اجبار به حضور یک نگاشت UID در فضای نام کاربر. .PP شناسه‌های UID و GID میزبان در \fIgidmapping\fP و \fIuidmapping\fP می‌توانند به صورت اختیاری با نماد \fB@\fR پیشوند شوند. در این حالت، پادمن شناسه واسط متناظر با شناسه میزبان را جستجو کرده و شناسه واسط یافت‌شده را به شناسه کانتینر نگاشت می‌کند. برای جزئیات بیشتر به \fBUIDMap=\fP مراجعه کنید. .PP \fBcontainer:\fP\fIid\fP: پیوستن به فضای نام کاربر کانتینر مشخص‌شده. .PP \fBhost\fP یا \fB""\fP (رشته خالی): اجرا در فضای نام کاربر فراخواننده. فرآیندهای در حال اجرا در کانتینر، همان امتیازاتی را روی میزبان دارند که هر فرآیند دیگری که توسط کاربر فراخواننده اجرا شود دارد. .PP \fBkeep-id\fP: ایجاد یک فضای نام کاربر که در آن UID:GID کاربر جاری به همان مقادیر درون کانتینر نگاشت می‌شوند. برای کانتینرهای ایجادشده توسط root، نگاشت جاری در یک فضای نام کاربر جدید ایجاد می‌شود. .PP علاوه بر این، فرآیند init در داخل کانتینر با UID کاربر جاری اجرا خواهد شد. این رفتار دستورالعمل \fBUSER\fR ایمیج را لغو می‌کند مگر اینکه صراحتاً \fB--user\fR را تنظیم کرده باشید. .PP گزینه‌های مجاز \fBkeep-id\fR: .IP \(bu 2 \fIuid\fP=UID: شناسه UID داخل کانتینر را که کاربر جاری به آن نگاشت می‌شود لغو و بازنویسی می‌کند. .IP \(bu 2 \fIgid\fP=GID: شناسه GID داخل کانتینر را که کاربر جاری به آن نگاشت می‌شود لغو و بازنویسی می‌کند. .IP \(bu 2 \fIsize\fP=SIZE: اندازه فضای نام کاربر پیکربندی‌شده را بازنویسی می‌کند. این گزینه برای پر نکردن تمام شناسه‌های در دسترس مفید است. هنگام اجرا به عنوان root پشتیبانی نمی‌شود. .PP \fBnomap\fP: یک فضای نام کاربر ایجاد می‌کند که در آن UID:GID کاربر بدون ریشه جاری به کانتینر نگاشت نمی‌شوند. این گزینه برای کانتینرهای ایجادشده توسط کاربر ریشه (root) مجاز نیست. .PP \fBns:\fP\fInamespace\fP: کانتینر را در فضای نام کاربر موجود مشخص‌شده اجرا می‌کند. .SS \fBVolume=[[SOURCE-VOLUME|HOST-DIR:]CONTAINER-DIR[:OPTIONS]]\fR ایجاد یک اتصال اتصالی (bind mount). اگر \fB-v /HOST-DIR:/CONTAINER-DIR\fR مشخص شود، پادمن پوشه \fB/HOST-DIR\fR را از میزبان به درون \fB/CONTAINER-DIR\fR در کانتینر پادمن سوار می‌کند. به طور مشابه، \fB-v SOURCE-VOLUME:/CONTAINER-DIR\fR جلد نام‌گذاری‌شده را از میزبان به درون کانتینر سوار می‌کند. اگر چنین جلد نام‌گذاری‌شده‌ای وجود نداشته باشد، پادمن آن را ایجاد می‌کند. گزینه \fBnocreate\fP می‌تواند برای غیرفعال کردن این رفتار و الزام به وجود قبلی جلد استفاده شود. اگر منبعی داده نشود، جلد به عنوان یک جلد نام‌گذاری‌شده ناشناس با یک نام تصادفی تولیدشده ایجاد می‌شود، و هنگام حذف کانتینر از طریق فلگ \fB--rm\fR یا دستور \fBpodman rm --volumes\fR حذف می‌گردد. .PP حالت خاص: .IP \(bu 2 اگر \fBSOURCE-VOLUME\fR به پسوند \fB\&.volume\fR ختم شود، یک جلد نام‌گذاری‌شده پادمن به نام \fBsystemd-$name\fR به عنوان منبع استفاده می‌شود و سرویس systemd تولیدشده شامل یک وابستگی به \fB$name-volume.service\fR خواهد بود. توجه داشته باشید که فایل \fB\&.volume\fR متناظر باید وجود داشته باشد. .PP (توجه داشته باشید که هنگام استفاده از کلاینت راه دور، از جمله ماشین‌های Mac و ویندوز (به استثنای WSL2)، جلدهای حافظه از سرور راه دور سوار می‌شوند، نه لزوماً ماشین کلاینت.) .PP شناسه \fIOPTIONS\fP یک لیست جداشده با کاما است و می‌تواند یک یا چند مورد از موارد زیر باشد: .IP \(bu 2 \fBrw\fP|\fBro\fP .IP \(bu 2 \fBz\fP|\fBZ\fP .IP \(bu 2 [\fBO\fP] .IP \(bu 2 [\fBU\fP] .IP \(bu 2 [\fBno\fP]\fBcopy\fP .IP \(bu 2 [\fBno\fP]\fBdev\fP .IP \(bu 2 [\fBno\fP]\fBexec\fP .IP \(bu 2 [\fBno\fP]\fBsuid\fP .IP \(bu 2 [\fBr\fP]\fBbind\fP .IP \(bu 2 [\fBr\fP]\fBshared\fP|[\fBr\fP]\fBslave\fP|[\fBr\fP]\fBprivate\fP[\fBr\fP]\fBunbindable\fP [1] \[la]#Footnote1\[ra] .IP \(bu 2 \fBidmap\fP[=\fBoptions\fP] .IP \(bu 2 \fBnocreate\fP .PP مسیر \fBCONTAINER-DIR\fR باید یک مسیر مطلق مانند \fB/src/docs\fR باشد. جلد در این دایرکتوری درون کانتینر سوار می‌شود. .PP اگر منبع جلد مشخص شده باشد، باید یک مسیر روی میزبان یا نام یک جلد نام‌گذاری‌شده باشد. مسیرهای میزبان می‌توانند مطلق یا نسبی باشند؛ مسیرهای نسبی نسبت به دایرکتوری که پادمن در آن اجرا می‌شود حل‌وفصل می‌شوند. اگر منبع وجود نداشته باشد، پادمن یک خطا بازمی‌گرداند. کاربران باید فایل‌ها یا دایرکتوری‌های منبع را از قبل ایجاد کنند. .PP هر منبعی که با یک \fB\&.\fR یا \fB/\fR شروع نشود به عنوان نام یک جلد نام‌گذاری‌شده در نظر گرفته می‌شود. اگر جلدی با آن نام وجود نداشته باشد، ایجاد خواهد شد. جلدهایی که با نام ایجاد می‌شوند ناشناس نیستند و با گزینه \fB--rm\fR و دستور \fBpodman rm --volumes\fR حذف نمی‌شوند. .PP گزینه \fBnocreate\fP می‌تواند برای جلدهای نام‌گذاری‌شده مشخص شود تا از ایجاد خودکار جلد جلوگیری کند. اگر \fBnocreate\fP تنظیم شده باشد و جلد وجود نداشته باشد، پادمن به جای ایجاد جلد، یک خطا برمی‌گرداند. این گزینه زمانی مفید است که می‌خواهید اطمینان حاصل کنید جلد قبل از استفاده به طور صریح ایجاد شده است. .EX $ podman podman-container.unit.5.md.in -v myvolume:/data:nocreate alpine .EE .PP برای سوار کردن یک یا چند جلد در یک کانتینر، چندین گزینه \fB-v\fP را مشخص کنید. .PP \fBWrite Protected Volume Mounts\fR .PP گزینه \fB:ro\fP یا \fB:rw\fP را برای سوار کردن یک جلد به ترتیب در حالت فقط‌خواندنی یا خواندن-نوشتن اضافه کنید. به طور پیش‌فرض، جلدها به صورت خواندن-نوشتن سوار می‌شوند. مثال‌ها را ببینید. .PP \fBChowning Volume Mounts\fR .PP هنگامی که یک جلد نام‌گذاری‌شده برای نخستین بار به یک کانتینر متصل می‌شود، پادمن به طور خودکار مالکیت نقطه اتصال جلد را در طول مقداردهی اولیه کانتینر تنظیم می‌کند. این عملیات chown تحت شرایط زیر رخ می‌دهد: .IP \(bu 2 جلد هنوز استفاده نشده باشد (مقدار \fBNeedsChown\fR روی true تنظیم شده باشد) .IP \(bu 2 جلد خالی باشد یا هنوز به سمت بالا کپی (copy up) نشده باشد .IP \(bu 2 جلد توسط یک درایور جلد خارجی مدیریت نشود .IP \(bu 2 درایور جلد "image" نباشد .PP برای جلدهایی با سوار کردن مبتنی بر idmapped (با استفاده از گزینه \fBidmap\fR)، تغییر مالکیت، نگاشت‌های فضای نام کاربر کانتینر را لحاظ می‌کند، اما جلد idmapped نگاشت صحیح UID/GID را حفظ می‌نماید. برای جلدهای بدون idmapping، نقطه اتصال تغییر مالکیت می‌یابد تا با کاربر و گروه فرآیند کانتینر مطابقت کند که در صورت فعال بودن بازنگاشت فضای نام کاربر، به فضای نام کاربر میزبان نگاشت می‌شود. .PP اگر کانتینری در یک فضای نام کاربر جدید ایجاد شود، UID و GID در کانتینر ممکن است با UID و GID دیگری روی میزبان متناظر باشند. .PP پسوند \fB:U\fR به پادمن می‌گوید بر اساس UID و GID درون کانتینر، از UID و GID صحیح میزبان برای تغییر بازگشتی مالک و گروه جلد منبع استفاده کند. این تغییر مالکیت، سیستم فایل زیرمجموعه جلد را پیمایش کرده و UID/GID هر فایل را تغییر می‌دهد. اگر جلد دارای هزاران inode باشد، این فرآیند زمان زیادی برده و شروع به کار کانتینر را به تاخیر می‌اندازد. .PP \fBWarning\fP با احتیاط استفاده شود زیرا این عمل سیستم‌فایل میزبان را دستکاری می‌کند. .PP \fBLabeling Volume Mounts\fR .PP سیستم‌های برچسب‌گذاری مانند SELinux نیازمند آن هستند که برچسب‌های مناسب روی محتوای جلدهای سوارشده درون کانتینر قرار گیرند. بدون برچسب، سیستم امنیتی ممکن است از استفاده محتوا توسط فرآیندهای در حال اجرا درون کانتینر جلوگیری کند. به طور پیش‌فرض، پادمن برچسب‌های تعیین‌شده توسط سیستم‌عامل را تغییر نمی‌دهد. .PP برای تغییر برچسب در زمینه کانتینر، یکی از دو پسوند \fB:z\fP یا \fB:Z\fP را به سوار کردن جلد اضافه کنید. این پسوندها به پادمن می‌گویند اشیای فایلی موجود روی جلدهای اشتراکی را دوباره برچسب‌گذاری کند. گزینه \fBz\fP به پادمن می‌گوید که دو یا چند کانتینر محتوای جلد را به اشتراک می‌گذارند. در نتیجه، پادمن محتوا را با یک برچسب محتوای مشترک برچسب‌گذاری می‌کند. برچسب‌های جلدهای مشترک به همه کانتینرها اجازه خواندن/نوشتن محتوا را می‌دهند. گزینه \fBZ\fP به پادمن می‌گوید که محتوا را با یک برچسب اختصاصی غیرمشترک برچسب‌گذاری کند. فقط کانتینر جاری می‌تواند از یک جلد اختصاصی استفاده کند. .PP نکته: تمام کانتینرهای درون یک \fBpod\fR دارای برچسب SELinux یکسان هستند. این بدان معناست که همه کانتینرهای موجود در پاد یادشده می‌توانند جلدهای به اشتراک گذاشته شده در کانتینری را که با \fB:Z\fR در هر یک از کانتینرها ایجاد شده است، بخوانند/بنویسند. برچسب‌گذاری مجدد، سیستم‌فایل زیر جلد را پیمایش کرده و برچسب هر فایل را تغییر می‌دهد؛ اگر جلد دارای هزاران inode باشد، این فرآیند زمان زیادی برده و شروع به کار کانتینر را به تاخیر می‌اندازد. اگر جلد قبلاً با گزینه \fBz\fP برچسب‌گذاری مجدد شده باشد، پادمن بهینه‌سازی شده است تا برای بار دوم آن را برچسب‌گذاری مجدد نکند. اگر فایل‌ها به درون جلد منتقل شوند، برچسب‌ها را می‌توان به صورت دستی با دستور \fBchcon -Rt container_file_t PATH\fR تغییر داد. .PP نکته: فایل‌ها و دایرکتوری‌های سیستمی را برچسب‌گذاری مجدد نکنید. برچسب‌گذاری مجدد محتوای سیستمی ممکن است باعث خرابی سایر سرویس‌های محدودشده روی ماشین شود. برای این دسته از کانتینرها، غیرفعال کردن جداسازی SELinux را پیشنهاد می‌کنیم. گزینه \fB--security-opt label=disable\fP جداسازی SELinux را برای کانتینر غیرفعال می‌کند. برای نمونه، اگر کاربری بخواهد کل دایرکتوری خانگی (home) خود را به عنوان جلد در یک کانتینر سوار کند، باید جداسازی SELinux را غیرفعال نماید. .EX $ podman podman-container.unit.5.md.in --security-opt label=disable -v $HOME:/home/user fedora touch /home/user/file .EE .PP \fBOverlay Volume Mounts\fR .PP فلگ \fB:O\fR به پادمن می‌گوید که دایرکتوری را از میزبان به عنوان فضای ذخیره‌سازی موقت با استفاده از \fBoverlay file system\fR سوار کند. فرآیندهای کانتینر می‌توانند محتوای درون نقطه اتصال را تغییر دهند که در فضای ذخیره‌سازی کانتینر در یک دایرکتوری جداگانه ذخیره می‌شود. در اصطلاحات overlay، دایرکتوری منبع lower (پایینی) است و دایرکتوری ذخیره‌سازی کانتینر upper (بالایی) است. تغییرات اعمال‌شده در نقطه اتصال با پایان یافتن اجرای کانتینر نابود می‌شوند، مشابه نقطه اتصالی از نوع tmpfs که پس از پایان unmount می‌شود. .PP برای کاربران پیشرفته، گزینه \fBoverlay\fP همچنین از \fBupperdir\fP و \fBworkdir\fP غیرفرار سفارشی برای سوار کردن overlay پشتیبانی می‌کند. دایرکتوری‌های سفارشی \fBupperdir\fP و \fBworkdir\fP می‌توانند کاملاً توسط خود کاربران مدیریت شوند و پادمن در پایان چرخه حیات آن‌ها را حذف نمی‌کند. نمونه: \fB:O,upperdir=/some/upper,workdir=/some/work\fP .PP اجراهای بعدی کانتینر محتوای اصلی دایرکتوری منبع را می‌بینند و هرگونه تغییرات ناشی از اجراهای قبلی کانتینر دیگر وجود نخواهد داشت. .PP یکی از موارد استفاده از سوار کردن overlay، به اشتراک‌گذاری حافظه موقت (کش) بسته‌ها از میزبان به درون کانتینر جهت افزایش سرعت ساخت‌ها است. .PP نکته: فلگ \fBO\fR با سایر گزینه‌های ذکرشده در بالا تداخل دارد. .PP محتوای سوارشده در کانتینر با برچسب اختصاصی برچسب‌گذاری می‌شود. در سیستم‌های SELinux، برچسب‌های موجود در دایرکتوری منبع باید توسط برچسب کانتینر قابل خواندن باشند. معمولاً کانتینرها می‌توانند \fBcontainer_share_t\fR را بخوانند/اجرا کنند و می‌توانند \fBcontainer_file_t\fR را بخوانند/بنویسند. در صورت ناتوانی در تغییر برچسب‌های یک جلد منبع، جداسازی کانتینر SELinux باید غیرفعال شود تا کانتینر کار کند. .PP دایرکتوری منبع سوارشده در کانتینر را با یک سوار کردن overlay تغییر ندهید، چرا که می‌تواند باعث خرابی‌های غیرمنتظره شود. دایرکتوری را تنها پس از پایان یافتن اجرای کانتینر تغییر دهید. .PP \fBMounts propagation\fR .PP به طور پیش‌فرض، جلدهای متصل‌شده با bind mount به صورت \fBprivate\fR هستند. این بدان معناست که هر سوار کردنی که درون کانتینر انجام شود روی میزبان قابل مشاهده نیست و بالعکس. می‌توان این رفتار را با تعیین یک ویژگی انتشار سوار کردن جلد تغییر داد. هنگامی که یک جلد به صورت \fBshared\fR باشد، سوار کردن‌های انجام‌شده زیر آن جلد درون کانتینر، روی میزبان قابل مشاهده بوده و بالعکس. تنظیم یک جلد به عنوان \fBslave\fP[1] \[la]#Footnote1\[ra] تنها انتشار سوار کردن یک‌طرفه را فعال می‌کند: سوار کردن‌های انجام‌شده روی میزبان در زیر آن جلد درون کانتینر قابل مشاهده هستند، اما برعکس آن برقرار نیست. .PP برای کنترل ویژگی انتشار سوار کردن یک جلد، می‌توان از فلگ‌های انتشار [\fBr\fP]\fBshared\fP، [\fBr\fP]\fBslave\fP، [\fBr\fP]\fBprivate\fP یا [\fBr\fP]\fBunbindable\fP استفاده کرد. ویژگی انتشار را تنها می‌توان برای جلدهای دارای اتصال bind مشخص کرد و نه برای جلدهای داخلی یا جلدهای نام‌گذاری‌شده. برای کارکرد انتشار، نقطه اتصال منبع (نقطه اتصالی که دایرکتوری منبع روی آن سوار شده است) باید ویژگی‌های انتشار درستی داشته باشد. برای جلدهای اشتراکی (shared)، نقطه اتصال منبع باید shared باشد. و برای جلدهای slave، نقطه اتصال منبع باید یا shared باشد یا slave. [1] \[la]#Footnote1\[ra] .PP برای سوار کردن بازگشتی یک جلد و تمام اتصالات زیرمجموعه آن به درون یک کانتینر، از گزینه \fBrbind\fP استفاده کنید. به طور پیش‌فرض گزینه bind استفاده می‌شود و سوار کردن‌های زیرمجموعه دایرکتوری منبع به درون کانتینر سوار نمی‌شوند. .PP سوار کردن جلد با گزینه \fBcopy\fP به پادمن می‌گوید که محتوا را از دایرکتوری مقصد زیرین به جلدهای داخلی تازه ایجادشده کپی کند. عمل \fBcopy\fP تنها در زمان ایجاد اولیه جلد اتفاق می‌افتد. محتوا زمانی که جلد متعاقباً در کانتینرهای مختلف استفاده شود کپی نمی‌شود. گزینه \fBcopy\fP روی اتصالات bind نادیده گرفته شده و تاثیری ندارد. .PP سوار کردن جلدها با گزینه‌های \fBnosuid\fP به این معناست که فایل‌های اجرایی SUID روی جلد نمی‌توانند توسط برنامه‌ها برای تغییر دسترسی‌شان استفاده شوند. به طور پیش‌فرض جلدها با \fBnosuid\fP سوار می‌شوند. .PP سوار کردن جلد با گزینه \fBnoexec\fP به این معناست که هیچ فایل اجرایی روی جلد نمی‌تواند در داخل کانتینر اجرا شود. .PP سوار کردن جلد با گزینه \fBnodev\fP به این معناست که هیچ دستگاهی روی جلد نمی‌تواند توسط فرآیندهای درون کانتینر استفاده شود. به طور پیش‌فرض جلدها با \fBnodev\fP سوار می‌شوند. .PP اگر \fIHOST-DIR\fP یک نقطه اتصال باشد، گزینه‌های \fBdev\fP، \fBsuid\fP و \fBexec\fP توسط هسته لینوکس نادیده گرفته می‌شوند. .PP از دستور \fBdf HOST-DIR\fP برای یافتن نقطه اتصال منبع استفاده کنید، سپس از \fBfindmnt -o TARGET,PROPAGATION \fIsource-mount-dir\fP\fP برای بررسی ویژگی‌های انتشار نقطه اتصال منبع استفاده نمایید. اگر ابزار \fBfindmnt\fP(1) در دسترس نیست، می‌توانید مدخل سوار کردن را برای نقطه اتصال منبع در \fI/proc/self/mountinfo\fP بررسی کنید. به "optional fields" نگاه کنید و ببینید آیا هیچ ویژگی انتشاری مشخص شده است یا خیر. در آنجا، \fBshared:N\fP به این معنی است که نقطه اتصال مشترک (shared) است، \fBmaster:N\fP به این معنی است که نقطه اتصال تابع (slave) است، و اگر چیزی وجود نداشته باشد، نقطه اتصال خصوصی (private) است. [1] \[la]#Footnote1\[ra] .PP برای تغییر ویژگی‌های انتشار یک نقطه اتصال، از دستور \fBmount\fP(8) استفاده کنید. برای نمونه، اگر کسی بخواهد دایرکتوری منبع \fI/foo\fP را به صورت bind سوار کند، می‌تواند دستورهای \fBmount --bind /foo /foo\fP و \fBmount --make-private --make-shared /foo\fP را اجرا نماید. این کار /foo را به یک نقطه اتصال مشترک (shared) تبدیل می‌کند. روش دیگر این است که ویژگی‌های انتشار نقطه اتصال منبع را مستقیماً تغییر دهید. فرض کنید \fI/\fP نقطه اتصال منبع برای \fI/foo\fP باشد، در این صورت از \fBmount --make-shared /\fP برای تبدیل \fI/\fP به یک سوار کردن مشترک استفاده کنید. .PP نکته: اگر کاربر تنها از طریق یک گروه حقوق دسترسی داشته باشد، دسترسی به جلد از داخل یک کانتینر بدون ریشه با شکست مواجه می‌شود. .PP \fBIdmapped mount\fR .PP اگر \fBidmap\fR مشخص شده باشد، یک اتصال با نگاشت شناسه (idmapped mount) به فضای نام کاربر مقصد در کانتینر ایجاد کنید. گزینه idmap از یک نگاشت سفارشی پشتیبانی می‌کند که می‌تواند متفاوت از فضای نام کاربر مورد استفاده توسط کانتینر باشد. نگاشت را می‌توان بعد از گزینه idmap به صورت زیر مشخص کرد: \fBidmap=uids=0-1-10#10-11-10;gids=0-100-10\fR\&. برای هر سه‌تایی، مقدار اول شروع شناسه‌های سیستم فایل پشتیبان است که به مقدار دوم روی میزبان نگاشت می‌شوند. طول این نگاشت در مقدار سوم ارائه می‌شود. محدوده‌های چندگانه با نماد # از یکدیگر جدا می‌شوند. .SS \fBWorkingDir=dir\fR دایرکتوری کاری درون کانتینر. .PP دایرکتوری کاری پیش‌فرض برای اجرای فایل‌های باینری درون یک کانتینر، دایرکتوری ریشه (\fB/\fP) است. توسعه‌دهنده ایمیج می‌تواند با دستورالعمل WORKDIR پیش‌فرض متفاوتی را تنظیم کند. مجری سیستم می‌تواند دایرکتوری کاری را با استفاده از گزینه \fBWorkingDir=\fP لغو و بازنویسی کند. .SH "نوع سرویس (SERVICE TYPE)" به طور پیش‌فرض، مولد مقدار \fBType=notify\fR را برای واحدهای \fB\&.container\fR تنظیم می‌کند. .PP این مقدار را می‌توان با تنظیم صریح \fBType=\fR در بخش \fB[Service]\fR لغو و بازنویسی کرد. .PP برای کانتینرهای یک‌باره یا یک‌باره‌مصرف (مانند وظایف اولیه init)، از مورد زیر استفاده کنید: .EX [Service] Type=oneshot RemainAfterExit=yes .EE .PP برای جزئیات کامل پیرامون انواع سرویس‌ها و رفتارهای مرتبط به \fBsystemd.service(5)\fR مراجعه فرمایید. .SH "بخش نصب (INSTALL SECTION)" برای اطمینان از آغاز به کار کانتینر هنگام بوت، یک بخش \fB[Install]\fR اضافه کنید: .EX [Install] WantedBy=multi-user.target .EE .PP تنها کلیدهای \fBAlias=\fR، \fBWantedBy=\fR، \fBRequiredBy=\fR و \fBUpheldBy=\fR پشتیبانی می‌شوند. .SH "مهلت‌های زمانی (TIMEOUTS)" راه‌اندازی کانتینر ممکن است از مهلت زمانی پیش‌فرض ۹۰ ثانیه‌ای systemd فراتر رود (برای مثال، هنگام دریافت ایمیج‌ها). استفاده کنید از: .EX [Service] TimeoutStartSec=900 .EE .PP نکته: گزینه \fBTimeoutStartSec\fR برای \fBType=oneshot\fR نادیده گرفته می‌شود. .SH "وابستگی‌های شبکه (NETWORK DEPENDENCIES)" کوادلت موارد زیر را می‌افزاید: .IP \(bu 2 \fBAfter=network-online.target\fR (برای واحدهای ریشه) .IP \(bu 2 \fBAfter=podman-user-wait-network-online.service\fR (برای واحدهای کاربری) .PP جهت غیرفعال‌سازی این مورد، اضافه کنید: .EX [Quadlet] DefaultDependencies=false .EE .SH "نام‌گذاری منابع (RESOURCE NAMING)" به طور پیش‌فرض، کانتینر \fBsystemd-\fR نام‌گذاری می‌شود. از \fBContainerName=\fR برای لغو و بازنویسی آن استفاده کنید. .PP از به کار بردن مشخص‌کننده‌های systemd مانند \fB%N\fR در نام منابع خودداری ورزید—این کار پیوندهای بین‌منابعی را مخدوش می‌کند. .SH "واحدهای الگو (TEMPLATE UNITS)" کوادلت از واحدهای کانتینری الگودار پشتیبانی می‌کند، به عنوان نمونه، \fBfoo@.container\fR واحد \fBfoo@.service\fR را ایجاد می‌کند. .PP می‌توانید نمونه را با این دستور فراخوانی و اجرا کنید: .EX systemctl start foo@bar.service .EE .PP همچنین می‌توانید به نمونه‌ها پیوند نمادین ایجاد کنید: .EX ln -s foo@.container foo@bar.container .EE .PP برای سفارشی‌سازی مختص هر نمونه از فایل‌های دراپ-این استفاده کنید: .EX foo@bar.container.d/10-override.conf .EE .SH "فایل‌های دراپ-این (DROP-IN FILES)" کوادلت از پیکربندی دراپ-این در دایرکتوری‌های \fB\&.container.d/\fR پشتیبانی می‌کند. .PP برای نمونه، یک فایل دراپ-این: .EX test.container.d/10-extra.conf .EE .PP می‌تواند فایل واحد اصلی را لغو و بازنویسی کرده یا گسترش دهد. .PP فایل‌های دراپ-این از همان رفتار لغو و ادغام واحدهای systemd پیروی می‌کنند. .SH "مثال (EXAMPLE)" یک واحد کانتینری کمینه: .EX [Unit] Description=A minimal container [Container] Image=quay.io/centos/centos:latest Exec=sleep 60 [Install] WantedBy=multi-user.target .EE .SH "همچنین ببینید (SEE ALSO)" podman-run(1), podman-systemd.unit(5), systemd.service(5), systemd.unit(5)