'\" t
.nh
.TH podman-pod.unit 5

.SH "نام (NAME)"
podman-pod.unit \- فایل‌های واحد systemd برای مدیریت پادهای پادمن با استفاده از Quadlet


.SH "خلاصه دستور (SYNOPSIS)"
\fIname\fP\&.pod


.SH "توضیحات (DESCRIPTION)"
واحدهای پاد (Pod) با پسوند \fB\&.pod\fR نام‌گذاری می‌شوند و شامل بخش \fB[Pod]\fR هستند که پاد ایجادشده و در حال اجرا به‌عنوان یک سرویس را توصیف می‌کند. فایل سرویس حاصل شامل خطی مانند \fBExecStartPre=podman pod create …\fR است و اکثر کلیدهای این بخش، گزینه‌های خط فرمانی را که به پادمن ارسال می‌شوند کنترل می‌کنند.

.PP
به‌طور پیش‌فرض، پاد پادمن هم‌نام با واحد خواهد بود اما با پیشوند \fBsystemd-\fR؛ یعنی یک فایل \fB$name.pod\fR یک واحد \fB$name-pod.service\fR و یک پاد پادمن به نام \fBsystemd-$name\fR ایجاد می‌کند. گزینه \fBPodName\fR اجازه می‌دهد این نام پیش‌فرض با یک نام ارائه‌شده توسط کاربر بازنویسی شود.


.SH "گزینه‌ها (OPTIONS)"
گزینه‌های معتبر برای \fB[Pod]\fR در زیر فهرست شده‌اند:

.TS
allbox;
l l 
l l .
\fBگزینه‌های [Pod]\fP	\fBمعادل در podman pod create\fP
AddHost=example\&.com:192.168.10.11	T{
--add-host example.com:192.168.10.11
T}
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
ExitPolicy=stop	--exit-policy stop
GIDMap=0:10000:10	--gidmap=0:10000:10
GlobalArgs=--log-level=debug	--log-level=debug
HostName=name	--hostname=name
IP=192.5.0.1	--ip 192.5.0.1
IP6=2001:db8::1	--ip6 2001:db8::1
Label="XYZ"	--label "XYZ"
Network=host	--network host
NetworkAlias=name	--network-alias name
PodmanArgs=--cpus=2	--cpus=2
PodName=name	--name=name
PublishPort=8080:80	--publish 8080:80
ServiceName=name	نام‌گذاری واحد systemd به \fBname.service\fR
ShmSize=100m	--shm-size=100m
SubGIDMap=gtest	--subgidname=gtest
SubUIDMap=utest	--subuidname=utest
UIDMap=0:10000:10	--uidmap=0:10000:10
UserNS=keep-id:uid=200,gid=210	T{
--userns keep-id:uid=200,gid=210
T}
Volume=/source:/dest	--volume /source:/dest
.TE

.PP
کلیدهای پشتیبانی‌شده در بخش \fB[Pod]\fR عبارتند از:

.SS \fBAddHost=hostname[;hostname[;...]]:ip\fR
یک نگاشت سفارشی میزبان به IP به فایل \fB/etc/hosts\fR کانتینر اضافه می‌کند.

.PP
این گزینه یک یا چند نام میزبان جداشده با نقطه ویرگول (semicolon) را دریافت می‌کند که با یک دونقطه به یک آدرس 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 \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=\fP همراه با \fBNetwork=\fP که روی \fBnone\fP یا \fBcontainer:\fP\fIid\fP تنظیم شده باشد، نامعتبر است.

.SS \fBDNSSearch=domain\fR
تنظیم دامنه‌های جستجوی سفارشی DNS. در صورت استفاده از \fBDNSSearch=\fP همراه با \fBNetwork=\fP که روی \fBnone\fP یا \fBcontainer:\fP\fIid\fP تنظیم شده باشد، نامعتبر است.
برای حذف دامنه جستجو از \fBDNSSearch=.\fP استفاده کنید.

.SS \fBExitPolicy=stop\fR
سیاست خروج پاد را هنگام خروج آخرین کانتینر تنظیم می‌کند. مقدار پیش‌فرض برای quadletها \fBstop\fP است.

.PP
برای فعال نگه داشتن پاد، \fBExitPolicy=continue\fR را تنظیم کنید.

.SS \fBGIDMap=[flags]container_gid:from_gid[:amount]\fR
اجرای کانتینر در یک فضای نام کاربری جدید با استفاده از نگاشت GID ارائه‌شده. این گزینه با گزینه‌های \fBUserNS=\fP و \fBSubGIDMap=\fP تداخل دارد. این گزینه روشی برای نگاشت GIDهای میزبان به GIDهای کانتینر مشابه روشی که \fB--uidmap\fP شناسه‌های UID میزبان را به UIDهای کانتینر نگاشت می‌کند ارائه می‌دهد. برای جزئیات به \fB--uidmap\fP مراجعه کنید.

.PP
نکته: گزینه \fBGIDMap=\fP نمی‌تواند همراه با گزینه \fBPod=\fP فراخوانی شود زیرا در سطح کانتینر درون یک پاد نمی‌توان یک gidmap تنظیم کرد.

.SS \fBGlobalArgs=\fR
این کلید شامل فهرستی از آرگومان‌ها است که در فایل تولیدشده مستقیماً پس از دستور \fBpodman\fR قرار می‌گیرند. می‌توان از آن برای دسترسی به ویژگی‌هایی از پادمن استفاده کرد که در حالت عادی توسط مولد پشتیبانی نمی‌شوند. از آنجا که مولد از تداخلات و رفتارهای غیرمنتظره احتمالی ناشی از این آرگومان‌ها آگاه نیست، استفاده از این گزینه توصیه نمی‌شود.

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

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

.SS \fBHostName=name\fR
نام میزبان کانتینر را درون کانتینر تنظیم می‌کند.

.PP
این گزینه فقط با فضای نام خصوصی UTS به صورت \fB--uts=private\fR (پیش‌فرض) قابل استفاده است. اگر \fBPod=\fR داده شده باشد و پاد فضای نام UTS مشترک داشته باشد (پیش‌فرض)، از نام میزبان پاد استفاده می‌شود. نام میزبان ارائه‌شده همچنین با استفاده از آدرس IP اصلی کانتینر به فایل \fB/etc/hosts\fR اضافه می‌شود (همچنین گزینه \fBAddHost=\fP را ببینید).

.PP
زمانی که \fBHostName=\fP تنظیم نشده باشد و کانتینر از فضای نام UTS خصوصی استفاده کند (پیش‌فرض)، پادمن نام میزبان را برابر با ۱۲ نویسه‌ی اول شناسه کانتینر (Container ID) قرار می‌دهد. نام کانتینر تعیین‌شده با \fBContainerName=\fP استفاده نمی‌شود مگر اینکه \fIcontainer_name_as_hostname=true\fP در \fBcontainers.conf\fR تنظیم شده باشد.

.PP
سیستم DNS شبکه پادمن نام کانتینر، شناسه کوتاه کانتینر (۱۲ نویسه اول) و هر نام میزبانی که صراحتاً با \fB--hostname\fP تنظیم شده باشد را به‌عنوان نام‌های DNS ثبت می‌کند. نام میزبان پیش‌فرض با نام مستعار شناسه کوتاه مطابقت دارد. به \fBpodman-network(1)\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=\fP تنظیم کرده و با استفاده از حالت \fBip\fR برای آن گزینه، برای هر شبکه یک آدرس IP ایستا تعیین کنید.

.SS \fBIP6=IPv6\fR
یک آدرس استاتیک IPv6 برای کانتینر مشخص می‌کند، برای مثال \fBfd46:db93:aa76:ac37::10\fP\&.
این گزینه تنها زمانی قابل استفاده است که کانتینر تنها به یک شبکه پیوسته باشد — یعنی \fBNetwork=network-name\fP حداکثر یک بار استفاده شده باشد — و کانتینر از طریق \fBNetwork=container:\fIid\fP\fP به فضای نام شبکه کانتینر دیگری نپیوسته باشد.
آدرس باید درون استخر آدرس‌های IPv6 شبکه باشد.

.PP
برای مشخص کردن چندین آدرس IPv6 ایستا برای هر کانتینر، چندین شبکه را با استفاده از گزینه \fBNetwork=\fP تنظیم کرده و با استفاده از حالت \fBip6\fR برای آن گزینه، برای هر شبکه یک آدرس IPv6 ایستا تعیین کنید.

.SS \fBLabel=key=value [key=value ...]\fR
افزودن متادیتا به کانتینر.

.SS \fBNetwork=mode\fR
حالت شبکه را برای کانتینر تنظیم می‌کند.

.PP
حالت‌های خاص:
.IP \(bu 2
اگر نام (\fBname\fR) شبکه با \fB\&.network\fR پایان یابد، یک شبکه پادمن با نام \fBsystemd-$name\fR استفاده می‌شود، و سرویس systemd تولیدشده شامل یک وابستگی به \fB$name-network.service\fR خواهد بود. چنین شبکه‌ای می‌تواند به‌طور خودکار با استفاده از یک فایل Quadlet با نام \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: ایجاد یک پشته شبکه روی بریج پیش‌فرض. این حالت پیش‌فرض برای کانتینرهای با دسترسی ریشه (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 مفید باشد.

برای شبکه‌های بریج بدون ریشه (rootless)، فوروارد پورت به‌طور پیش‌فرض از \fBrootlessport\fR استفاده می‌کند. تنظیم \fBrootless_port_forwarder="pasta"\fR در بخش \fB[network]\fR فایل \fBcontainers.conf(5)\fP، حالت فوروارد را به سطح هسته با pasta (از طریق \fBpesto\fR) تغییر می‌دهد که آدرس IP مبدا اصلی کلاینت را درون کانتینر حفظ می‌کند. این گزینه آزمایشی است و رفتار آن ممکن است تغییر کند.

برای مثال، برای تنظیم یک آدرس استاتیک IPv4 و یک آدرس مک استاتیک، از \fB--network bridge:ip=10.88.0.10,mac=44:33:22:11:00:99\fR استفاده کنید.
.IP \(bu 2
\fI<network name or ID>\fP\fB[:OPTIONS,...]\fP: اتصال به یک شبکه تعریف‌شده توسط کاربر؛ این نام یا شناسه شبکه‌ای است که توسط \fBpodman network create\fR ایجاد شده است. امکان تعیین گزینه‌های مشابه آنچه در بخش حالت 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: استفاده از فضای نام شبکه میزبان برای کانتینر به‌جای ایجاد یک فضای نام ایزوله. هشدار: این کار دسترسی کامل به سوکت‌های یونیکس دامنه انتزاعی و سوکت‌های TCP/UDP مقید به localhost را به کانتینر می‌دهد. از آنجا که این سازوکارها اغلب برای جلوگیری از دسترسی به سرویس‌های حساس سیستم و جداسازی آن‌ها از دسترسی نهادهای خارجی استفاده می‌شوند، استفاده از این گزینه می‌تواند یک آسیب‌پذیری امنیتی محسوب شود.
.IP \(bu 2
\fBns:\fP\fIpath\fP: مسیر پیوستن به یک فضای نام شبکه.
.IP \(bu 2
\fBprivate\fP: ایجاد یک فضای نام جدید برای کانتینر. این گزینه برای کانتینرهای با دسترسی ریشه از حالت \fBbridge\fP و برای کانتینرهای بدون ریشه از \fBpasta\fR استفاده می‌کند.
.IP \(bu 2
\fBpasta[:OPTIONS,...]\fP: استفاده از \fBpasta\fP(1) برای ایجاد پشته شبکه در حالت کاربر (user-mode).
.br
این حالت پیش‌فرض برای کانتینرهای بدون ریشه است و فقط در حالت بدون ریشه پشتیبانی می‌شود.
.br
به‌طور پیش‌فرض، آدرس‌ها و مسیرهای IPv4 و IPv6 و همچنین نام رابط پاد از میزبان کپی می‌شوند. فوروارد پورت، آدرس IP مبدا اصلی را حفظ می‌کند. گزینه‌های شرح داده شده در pasta(1) می‌توانند به‌صورت آرگومان‌های جداشده با کاما مشخص شوند.
.br
از نظر گزینه‌های pasta(1)، به‌طور پیش‌فرض \fB--config-net\fP برای پیکربندی شبکه هنگام شروع کانتینر اعمال می‌شود و \fB--no-map-gw\fP نیز به‌طور پیش‌فرض فرض می‌شود تا از دسترسی مستقیم کانتینر به میزبان با استفاده از آدرس گیت‌وی جلوگیری شود. مورد دوم می‌تواند با ارسال \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 را ذیل بخش شبکه در آن فایل ببینید.
.br
چند مثال:
.RS
.IP \(bu 2
\fBpasta:--map-gw\fP: اجازه دسترسی مستقیم کانتینر به میزبان با استفاده از آدرس گیت‌وی.
.IP \(bu 2
\fBpasta:--mtu,1500\fP: مشخص کردن یک MTU معادل ۱۵۰۰ بایت برای رابط \fItap\fP در کانتینر.
.IP \(bu 2
\fBpasta:--ipv4-only,-a,10.0.2.0,-n,24,-g,10.0.2.2,--dns-forward,10.0.2.3,-m,1500,--no-ndp,--no-dhcpv6,--no-dhcp\fP:
غیرفعال کردن IPv6، تخصیص \fB10.0.2.0/24\fR به رابط \fBtap0\fR در کانتینر با گیت‌وی \fB10.0.2.3\fR، فعال‌سازی ارسال‌کننده DNS قابل دسترسی در \fB10.0.2.3\fR، تنظیم MTU روی ۱۵۰۰ بایت، غیرفعال‌سازی پشتیبانی NDP، DHCPv6 و DHCP.
.IP \(bu 2
\fBpasta:-I,tap0,--ipv4-only,-a,10.0.2.0,-n,24,-g,10.0.2.2,--dns-forward,10.0.2.3,--no-ndp,--no-dhcpv6,--no-dhcp\fP:
مشابه بالا، اما رها کردن MTU روی ۶۵۵۲۰ بایت.
.IP \(bu 2
\fBpasta:-t,auto,-u,auto,-T,auto,-U,auto\fP: فعال‌سازی فوروارد خودکار پورت بر اساس پورت‌های متصل مشاهده‌شده از سمت میزبان و کانتینر.
.IP \(bu 2
\fBpasta:-T,5201\fP: فعال‌سازی فوروارد پورت TCP به شماره ۵۲۰۱ از کانتینر به میزبان، با استفاده از رابط loopback به‌جای رابط tap برای کارایی بهتر.
.RE

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

.SS \fBPodmanArgs=\fR
این کلید شامل فهرستی از آرگومان‌ها است که در فایل تولیدشده مستقیماً به انتهای دستور \fBpodman\fR اضافه می‌شوند. می‌توان از آن برای دسترسی به ویژگی‌هایی از پادمن استفاده کرد که در حالت عادی توسط مولد پشتیبانی نمی‌شوند. از آنجا که مولد از تداخلات و رفتارهای غیرمنتظره احتمالی ناشی از این آرگومان‌ها آگاه نیست، استفاده از این گزینه توصیه نمی‌شود.

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

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

.SS \fBPodName=name\fR
نام (اختیاری) پاد پادمن.
اگر این گزینه مشخص نشود، مقدار پیش‌فرض هم‌نام با واحد خواهد بود اما با پیشوند \fBsystemd-\fR؛ یعنی یک فایل \fB$name.pod\fR یک پاد پادمن با نام \fBsystemd-$name\fR ایجاد می‌کند تا از تداخل با پادهای مدیریت‌شده توسط کاربر جلوگیری شود.

.PP
لطفاً توجه داشته باشید که پادها و کانتینرها نمی‌توانند نام یکسانی داشته باشند.
بنابراین اگر PodName تنظیم شده باشد، نباید با هیچ کانتینری تداخل داشته باشد.

.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 تنظیم کنید. کانتینرهای با دسترسی ریشه همچنین می‌توانند پورت‌ها را با استفاده از پروتکل \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
برای شبکه‌های بریج بدون ریشه، فوروارد پورت به‌طور پیش‌فرض از \fBrootlessport\fR استفاده می‌کند که یک پراکسی در فضای کاربر است و IPهای مبدا کلاینت را حفظ نمی‌کند. تنظیم \fBrootless_port_forwarder="pasta"\fR در بخش \fB[network]\fR فایل \fBcontainers.conf(5)\fP، فوروارد را به سطح هسته با pasta از طریق \fBpesto\fR تغییر می‌دهد و آدرس IP کلاینت اصلی را درون کانتینر حفظ می‌کند. این گزینه آزمایشی است و رفتار آن ممکن است تغییر کند.

.SS \fBServiceName=name\fR
به‌طور پیش‌فرض، Quadlet با افزودن \fB-pod\fR به انتهای نام Quadlet، نام واحد سرویس systemd را تعیین می‌کند.
تنظیم این کلید با دستور به Quadlet برای استفاده از نام ارائه‌شده، این رفتار را بازنویسی می‌کند.

.PP
توجه داشته باشید که نام نباید شامل پسوند فایل \fB\&.service\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 \fBSubGIDMap=name\fR
اجرای کانتینر در یک فضای نام کاربری جدید با استفاده از نگاشت با نام \fIname\fP در فایل \fI/etc/subgid\fP\&.
هنگام اجرا در حالت بدون ریشه، کاربر برای استفاده از این نگاشت نیازمند مجوزهای لازم است. به \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\&.
هنگام اجرا در حالت بدون ریشه، کاربر برای استفاده از این نگاشت نیازمند مجوزهای لازم است. به \fBsubuid\fP(5) مراجعه کنید.
این پرچم با \fBUserNS=\fP و \fBUIDMap=\fP تداخل دارد.
همراه با \fBUIDMap=\fP طوری عمل می‌کند که گویی \fBUIDMap=\fP با تمام نگاشت‌های کاربر \fIname\fP در \fI/etc/subuid\fP ارسال شده باشد.

.SS \fBUIDMap=container_uid:from_uid[:amount]\fR
اجرای تمام کانتینرهای درون پاد در یک فضای نام کاربری جدید با استفاده از نگاشت ارائه‌شده. این گزینه با گزینه‌های \fBUserNS=\fP و \fBSubUIDMap=\fP تداخل دارد. این گزینه روشی برای نگاشت UIDهای میزبان به UIDهای کانتینر فراهم می‌کند. می‌تواند چندین بار برای نگاشت محدوده‌های مختلف ارسال شود.

.SS \fBUserNS=mode\fR
تنظیم حالت فضای نام کاربری برای تمام کانتینرهای یک پاد. مقدار پیش‌فرض آن به متغیر محیطی \fBPODMAN_USERNS\fR بستگی دارد. مقدار خالی ("") به معنای غیرفعال بودن فضاهای نام کاربری است.

.PP
نگاشت‌های کاربر بدون ریشه \fBUserNS=Key\fP:

.TS
allbox;
l l l 
l l l .
\fBکلید\fP	\fBکاربر میزبان\fP	\fBکاربر کانتینر\fP
""	$UID	T{
0 (حساب کاربر پیش‌فرض به کاربر root در کانتینر نگاشت می‌شود.)
T}
host	$UID	T{
0 (حساب کاربر پیش‌فرض به کاربر root در کانتینر نگاشت می‌شود.)
T}
keep-id	$UID	T{
$UID (نگاشت حساب کاربر به همان UID درون کانتینر.)
T}
auto	$UID	T{
nil (شناسه UID کاربر میزبان به درون کانتینر نگاشت نمی‌شود.)
T}
nomap	$UID	T{
nil (شناسه UID کاربر میزبان به درون کانتینر نگاشت نمی‌شود.)
T}
.TE

.PP
مقادیر معتبر \fImode\fP عبارتند از:
.IP \(bu 2
\fIauto[:\fP\fIOPTIONS,...\fP\fI]\fP: ایجاد خودکار یک فضای نام. امکان تعیین این گزینه‌ها برای \fBauto\fR وجود دارد:
.RS
.IP \(bu 2
\fIgidmapping=\fP\fICONTAINER_GID:HOST_GID:SIZE\fP: اجبار به حضور یک نگاشت GID در فضای نام کاربر.
.IP \(bu 2
\fIsize=\fP\fISIZE\fP: برای تعیین یک اندازه صریح برای فضای نام کاربر خودکار. مثلاً \fBUserNS=auto:size=8192\fR\&. اگر \fBsize\fR مشخص نشود، \fBauto\fR اندازه فضای نام کاربر را برآورد می‌کند.
.IP \(bu 2
\fIuidmapping=\fP\fICONTAINER_UID:HOST_UID:SIZE\fP: اجبار به حضور یک نگاشت UID در فضای نام کاربر.
.RE
.IP \(bu 2
\fIhost\fP: اجرا در فضای نام کاربر فراخواننده. فرآیندهای در حال اجرا درون کانتینر همان امتیازات را روی میزبان دارند که هر فرآیند دیگری توسط کاربر فراخواننده اجرا شود دارد (پیش‌فرض).
.IP \(bu 2
\fIkeep-id\fP: یک فضای نام کاربر ایجاد می‌کند که در آن UID:GID کاربر بدون ریشه جاری به همان مقادیر درون کانتینر نگاشت می‌شوند. این گزینه برای کانتینرهای ایجادشده توسط کاربر root مجاز نیست.
.IP \(bu 2
\fInomap\fP: یک فضای نام کاربر ایجاد می‌کند که در آن UID:GID کاربر بدون ریشه جاری به درون کانتینر نگاشت نمی‌شوند. این گزینه برای کانتینرهای ایجادشده توسط کاربر root مجاز نیست.

.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 در کانتینر پادمن متصل (bind mount) می‌کند. به همین ترتیب، \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
(توجه داشته باشید هنگام استفاده از کلاینت راه دور، شامل ماشین‌های مک و ویندوز (به‌جز 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-pod.unit.5.md.in -v myvolume:/data:nocreate alpine
.EE

.PP
برای اتصال یک یا چند حجم به یک کانتینر، چندین گزینه \fB-v\fP را مشخص کنید.

.PP
\fBاتصالات حجم محافظت‌شده در برابر نوشتن (Write Protected)\fR

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

.PP
\fBتغییر مالکیت اتصالات حجم (Chowning)\fR

.PP
هنگامی که یک حجم نام‌گذاری‌شده برای نخستین بار به یک کانتینر متصل می‌شود، پادمن به‌طور خودکار مالکیت نقطه اتصال حجم را در طول راه‌اندازی اولیه کانتینر تنظیم می‌کند. این عملیات chown تحت شرایط زیر انجام می‌شود:
.IP \(bu 2
حجم هنوز استفاده نشده باشد (\fBNeedsChown\fR روی true تنظیم باشد)
.IP \(bu 2
حجم خالی باشد یا هنوز کپی به بالا انجام نشده باشد
.IP \(bu 2
حجم توسط یک درایور حجم خارجی مدیریت نشود
.IP \(bu 2
درایور حجم "image" نباشد

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

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

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

.PP
\fBهشدار\fP: با احتیاط استفاده کنید زیرا این کار سیستم فایل میزبان را تغییر می‌دهد.

.PP
\fBبرچسب‌گذاری اتصالات حجم (Labeling)\fR

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

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

.PP
نکته: تمام کانتینرهای درون یک \fBپاد\fR در همان برچسب SELinux سهیم هستند. این بدان معناست که همه کانتینرهای درون پاد مذکور می‌توانند حجم‌های به‌اشتراک‌گذاشته‌شده در کانتینر ایجادشده با \fB:Z\fR را روی هر یک از کانتینرها بخوانند/بنویسند. تغییر برچسب، سیستم فایل زیر حجم را پیمایش کرده و برچسب را روی هر فایل تغییر می‌دهد؛ اگر حجم دارای هزاران inode باشد، این فرآیند زمان زیادی برده و شروع کانتینر را به تاخیر می‌اندازد. اگر حجم قبلاً با گزینه \fBz\fR تغییر برچسب یافته باشد، پادمن طوری بهینه‌سازی شده است که برای بار دوم تغییر برچسب ندهد. اگر فایل‌هایی به درون حجم انتقال یابند، آنگاه برچسب‌ها را می‌توان به‌صورت دستی با دستور \fBchcon -Rt container_file_t PATH\fR تغییر داد.

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

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

.PP
\fBاتصالات حجم اورلی (Overlay)\fR

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

.PP
برای کاربران پیشرفته، گزینه \fBoverlay\fP همچنین از دایرکتوری‌های سفارشی غیرفرار \fBupperdir\fP و \fBworkdir\fP برای اتصال اورلی پشتیبانی می‌کند. گزینه‌های سفارشی \fBupperdir\fP و \fBworkdir\fP می‌توانند به‌طور کامل توسط خود کاربران مدیریت شوند و پادمن در پایان چرخه حیات آن‌ها را حذف نمی‌کند.
مثال: \fB:O,upperdir=/some/upper,workdir=/some/work\fP

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

.PP
یک مورد استفاده از اتصال اورلی، به اشتراک گذاشتن کش بسته‌ها از میزبان به کانتینر برای سرعت بخشیدن به فرآیند ساخت است.

.PP
نکته: پرچم \fBO\fR با سایر گزینه‌های ذکرشده در بالا تداخل دارد.

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

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

.PP
\fBانتشار اتصالات (Mounts 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-mounted قابل تعیین است و برای حجم‌های داخلی یا حجم‌های نام‌گذاری‌شده صدق نمی‌کند. برای کارکرد انتشار اتصال، نقطه اتصال منبع (نقطه اتصالی که پوشه منبع روی آن متصل شده) باید ویژگی‌های انتشار مناسب را داشته باشد. برای حجم‌های 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 به معنای اشتراکی بودن اتصال، \fBmaster:N\fP به معنای slave بودن، و عدم وجود چیزی به معنای خصوصی (private) بودن اتصال است. [1]
\[la]#Footnote1\[ra]

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

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

.PP
\fBاتصال نگاشت شناسه (Idmapped mount)\fR

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


.SH "مثال‌ها (EXAMPLES)"
مثال: کانتینر درون یک پاد

.PP
test.pod:

.EX
[Pod]
PodName=test
.EE

.PP
centos.container:

.EX
[Container]
Image=quay.io/centos/centos:latest
Exec=sh -c "sleep inf"
Pod=test.pod
.EE


.SH "همچنین ببینید (SEE ALSO)"
podman-kube-play(1),
podman-systemd.unit(5),
systemd.unit(5)