'\" t
.nh
.TH podman-systemd.unit 5
.SH "نام (NAME)"
podman-systemd.unit \- واحدهای systemd با استفاده از Podman Quadlet

.SH "خلاصه دستور (SYNOPSIS)"
\fIname\fP\&.artifact, \fIname\fP\&.build, \fIname\fP\&.container, \fIname\fP\&.image, \fIname\fP\&.kube, \fIname\fP\&.network, \fIname\fP\&.pod, \fIname\fP\&.volume
.IP \(bu 2
\fB\fB\&.build\fR\fP — ساخت تصویر کانتینر از روی Containerfile. صفحه راهنمای podman-build.unit(5) را ببینید.
.IP \(bu 2
\fB\fB\&.container\fR\fP — تعریف و مدیریت یک کانتینر منفرد. صفحه راهنمای podman-container.unit(5) را ببینید.
.IP \(bu 2
\fB\fB\&.image\fR\fP — دریافت (Pull) و ذخیره موقت تصویر کانتینر. صفحه راهنمای podman-image.unit(5) را ببینید.
.IP \(bu 2
\fB\fB\&.kube\fR\fP — استقرار کانتینرها از روی YAML کوبرنتیز با استفاده از podman-kube.unit(5).
.IP \(bu 2
\fB\fB\&.network\fR\fP — ایجاد شبکه پودمن برای کانتینرها و پادها. صفحه راهنمای podman-network.unit(5) را ببینید.
.IP \(bu 2
\fB\fB\&.pod\fR\fP — ایجاد پاد پودمن که کانتینرها می‌توانند به آن بپیوندند. صفحه راهنمای podman-pod.unit(5) را ببینید.
.IP \(bu 2
\fB\fB\&.volume\fR\fP — اطمینان از وجود یک جلد (Volume) نام‌دار پودمن. صفحه راهنمای podman-volume.unit(5) را ببینید.

.SS مسیر جستجوی واحدهای دارای دسترسی ریشه (Rootful) در پودمن
فایل‌های Quadlet برای کاربر ریشه را می‌توان در دایرکتوری‌های زیر به ترتیب اولویت قرار داد. به این معنی که کادلت‌های هم‌نام پیدا شده در /run نسبت به موارد موجود در /etc و همچنین موارد موجود در /usr اولویت دارند:

.PP
کادلت‌های موقت، معمولاً برای آزمایش استفاده می‌شوند:
.IP \(bu 2
/run/containers/systemd/

.PP
کادلت‌های تعریف‌شده توسط مدیر سیستم:
.IP \(bu 2
/etc/containers/systemd/

.PP
کادلت‌های تعریف‌شده توسط توزیع:
.IP \(bu 2
/usr/share/containers/systemd/

.SS مسیر جستجوی واحدهای بدون دسترسی ریشه (Rootless) در پودمن
فایل‌های Quadlet برای کاربران غیرریشه می‌توانند در دایرکتوری‌های زیر قرار گیرند:
.IP \(bu 2
$XDG_RUNTIME_DIR/containers/systemd/
.IP \(bu 2
$XDG_CONFIG_HOME/containers/systemd/ یا ~/.config/containers/systemd/
.IP \(bu 2
/etc/containers/systemd/users/${UID}
.IP \(bu 2
/etc/containers/systemd/users/
.IP \(bu 2
/usr/share/containers/systemd/users/${UID}
.IP \(bu 2
/usr/share/containers/systemd/users/

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

.SH "توضیحات (DESCRIPTION)"
پودمن از ساخت و راه‌اندازی کانتینرها (و ایجاد حجم‌ها) از طریق systemd با استفاده از یک
تولیدکننده (generator) در systemd پشتیبانی می‌کند.
این فایل‌ها هنگام بوت (و زمانی که \fBsystemctl daemon-reload\fR اجرا می‌شود) خوانده شده و
فایل‌های متناظر واحد سرویس معمولی systemd را تولید می‌کنند. هر دو نوع واحدهای سیستمی و کاربری systemd پشتیبانی می‌شوند.
تمام گزینه‌ها و جدول‌های موجود در فایل‌های واحد استاندارد systemd پشتیبانی می‌شوند. برای مثال، گزینه‌های تعریف‌شده در
جدول [Service] و جدول‌های [Install] مستقیماً به systemd منتقل شده و توسط آن مدیریت می‌شوند.
برای اطلاعات بیشتر، صفحه راهنمای systemd.unit(5) را ببینید.

.PP
تولیدکننده پودمن مسیرهای جستجوی بالا را بررسی کرده و فایل‌های دارای پسوندهای \fB\&.container\fR،
\fB\&.volume\fR، \fB\&.network\fR، \fB\&.build\fR، \fB\&.pod\fR، \fB\&.kube\fR و \fB\&.artifact\fR را می‌خواند و برای هر فایل، یک فایل \fB\&.service\fR با نام مشابه تولید می‌کند. توجه داشته باشید که
سرویس‌های توزیع‌کننده موجود (یعنی در \fB/usr/\fR) در صورت داشتن نام مشابه جایگزین می‌شوند. فایل‌های واحد تولیدشده را می‌توان
با \fBsystemctl\fR همانند هر سرویس دیگر systemd راه‌اندازی و مدیریت کرد. دستور \fBsystemctl {--user} list-unit-files\fR
فایل‌های واحد موجود روی سیستم را فهرست می‌کند. برای فهرست کردن فایل‌های واحد کاربری که پوسته ورود آن \fB/sbin/nologin\fR است،
دستور \fBsudo systemctl --machine username@ --user list-unit-files\fR را اجرا کنید.

.PP
فایل‌های پودمن از همان قالب فایل‌های واحد معمولی systemd استفاده می‌کنند.
هر نوع فایل دارای یک بخش سفارشی است (برای مثال \fB[Container]\fR) که توسط پودمن مدیریت می‌شود و تمام
بخش‌های دیگر بدون تغییر منتقل می‌شوند، که امکان استفاده از هر گزینه پیکربندی عادی systemd
مانند وابستگی‌ها یا محدودیت‌های cgroup را فراهم می‌کند.

.PP
فایل‌های منبع همچنین از فایل‌های تکمیلی (Drop-ins) به همان شیوه systemd پشتیبانی می‌کنند.
برای یک فایل منبع مشخص (\fBfoo.container\fR)، دایرکتوری \fB\&.d\fR متناظر (\fBfoo.container.d\fR) برای
یافتن فایل‌های با پسوند \fB\&.conf\fR پویش می‌شود که سپس به ترتیب حروف الفبا با فایل پایه
ادغام می‌گردند. فایل‌های تکمیلی سطح بالای نوع فایل (\fBcontainer.d\fR) نیز گنجانده می‌شوند. اگر نام واحد شامل خط تیره ("-")
باشد (\fBfoo-bar-baz.container\fR)، دایرکتوری‌های تکمیلی تولیدشده با بریدن نام پس از
خط تیره نیز جستجو می‌شوند (\fBfoo-.container.d\fR و \fBfoo-bar-.container.d\fR). فایل‌های تکمیلی با نام یکسان
در سطوح پایین‌تر سلسله‌مراتب، بر موارد بالاتر اولویت داشته و آن‌ها را بازنویسی می‌کنند (\fBfoo-bar-baz.container.d/10-override.conf\fR بر
\fBfoo-bar-.container.d/10-override.conf\fR اولویت دارد که آن نیز بر \fBfoo-.service.d/10-override.conf\fR و آن هم بر
\fBcontainer.d/10-override.conf\fR اولویت دارد). قالب این فایل‌های تکمیلی همانند فایل پایه است. این ویژگی برای
تغییر یا افزودن تنظیمات پیکربندی یک واحد، بدون نیاز به ویرایش فایل‌های واحد مفید است.

.PP
برای کانتینرهای بدون ریشه، زمانی که مدیران سیستم فایل‌های Quadlet را در دایرکتوری‌های
/etc/containers/systemd/users یا /usr/share/containers/users قرار می‌دهند،
نشست‌های تمام کاربران هنگام شروع نشست ورود، Quadlet را اجرا می‌کنند.
اگر مدیر سیستم یک فایل Quadlet را در دایرکتوری
/etc/containers/systemd/users/${UID}/ یا /usr/share/containers/users/${UID}
قرار دهد، آن‌گاه تنها کاربری با UID منطبق، هنگام شروع نشست ورود Quadlet را
اجرا می‌کند. برای فایل‌های واحد قرار داده شده در زیردایرکتوری‌های درون
/etc/containers/systemd/users/${UID}/، /usr/share/containers/users/${UID} و
سایر مسیرهای جستجوی واحد کاربری، Quadlet به صورت بازگشتی جستجو کرده و
فایل‌های واحد موجود در این زیردایرکتوری‌ها را اجرا می‌کند.

.PP
توجه داشته باشید که واحدهای Quadlet از اجرا به عنوان کاربر غیرریشه با تعریف گزینه‌های
User، Group،
یا DynamicUser
در systemd پشتیبانی نمی‌کنند. اگر می‌خواهید یک Quadlet بدون ریشه را اجرا کنید، باید کاربر را ایجاد کرده
و فایل واحد را به یکی از مسیرهای جستجوی واحد بدون ریشه در بالا اضافه کنید.

.PP
هنگامی که یک واحد Quadlet شروع می‌شود، ممکن است پودمن نیاز به دریافت یا ساخت تصاویر کانتینر داشته باشد که می‌تواند به میزان قابل توجهی طولانی‌تر
از محدودیت پیش‌فرض ۹۰ ثانیه‌ای راه‌اندازی سرویس در systemd زمان ببرد. اگر این موضوع باعث شکست واحد شد، می‌توانید تصاویر
مورد نیاز را از قبل دریافت کرده یا با استفاده از گزینه \fITimeoutStartSec\fP مهلت زمانی راه‌اندازی سرویس را افزایش دهید. با این حال به یاد داشته باشید
که برای واحدهایی که \fBType=oneshot\fR را مشخص می‌کنند، مهلت زمانی راه‌اندازی به طور پیش‌فرض غیرفعال است (روی بی‌نهایت تنظیم شده)، بنابراین
اگر مهلت زمانی مد نظر باشد، \fITimeoutStartSec\fP باید صریحاً پیکربندی شود. برای جزئیات بیشتر در مورد \fITimeoutStartSec\fP، به \fBsystemd.service(5)\fR مراجعه کنید.

.PP
افزودن قطعه زیر به فایل Quadlet، مهلت زمانی راه‌اندازی را به ۱۵ دقیقه افزایش می‌دهد.

.EX
[Service]
TimeoutStartSec=900
.EE

.PP
ابزار Quadlet نیاز به استفاده از cgroup v2 دارد، برای بررسی روی سیستم از دستور \fBpodman info --format {{.Host.CgroupsVersion}}\fR استفاده کنید.

.SS نوع سرویس (Service Type)
به طور پیش‌فرض، فیلد \fBType\fR در بخش \fBService\fR فایل Quadlet نیازی به تنظیم ندارد.
ابزار Quadlet آن را برای فایل‌های \fB\&.container\fR و \fB\&.kube\fR روی \fBnotify\fR،
برای فایل‌های \fB\&.pod\fR روی \fBforking\fR، و برای فایل‌های \fB\&.volume\fR، \fB\&.network\fR، \fB\&.build\fR، \fB\&.image\fR و \fB\&.artifact\fR روی \fBoneshot\fR تنظیم می‌کند.

.PP
با این حال، زمانی که انتظار نمی‌رود پس از خروج \fBpodman\fR هیچ کانتینری اجرا
شود، می‌توان \fBType\fR را صریحاً برای فایل‌های \fB\&.container\fR و \fB\&.kube\fR روی \fBoneshot\fR تنظیم کرد.

.PP
هنگام تنظیم \fBType=oneshot\fR، توصیه می‌شود که \fBRemainAfterExit=yes\fR نیز تنظیم شود تا از تبدیل وضعیت سرویس
به \fBinactive (dead)\fR جلوگیری شود. با این حال، هنگام فعال‌سازی یک سرویس از طریق یک واحد زمان‌سنج (Timer)، تنظیم \fBRemainAfterExit=yes\fR
وظیفه را در وضعیت "started" باقی می‌گذارد که از فعال‌سازی‌های بعدی توسط زمان‌سنج جلوگیری می‌کند. برای اطلاعات بیشتر،
صفحه راهنمای \fBsystemd.service(5)\fR را ببینید.

.PP
مثال‌هایی برای چنین مواردی:
- فایل \fB\&.container\fR با تصویری که پس از پایان نقطه ورود (entrypoint) خود خارج می‌شود
.IP \(bu 2
فایل \fB\&.kube\fR که به یک فایل YAML کوبرنتیز اشاره می‌کند که هیچ کانتینری در آن تعریف نشده است؛ مانند مواردی که فقط PVC دارند

.SS فعال‌سازی فایل‌های واحد
سرویس‌های ایجادشده توسط پودمن از نظر systemd گذرا (transient) در نظر گرفته می‌شوند، به این معنی که از همان
قوانین ماندگاری واحدهای معمولی پیروی نمی‌کنند. به ویژه، اجرای \fBsystemctl enable\fR روی آن‌ها
برای فعال‌سازی خودکار در بوت بعدی ممکن نیست.

.PP
برای جبران این موضوع، تولیدکننده در زمان تولید به صورت دستی بخش \fB[Install]\fR فایل‌های واحد تعریف کانتینر
را اعمال می‌کند، همان‌گونه که دستور \fBsystemctl enable\fR هنگام اجرا در زمان بعد عمل می‌کند.

.PP
برای مثال، جهت راه‌اندازی یک کانتینر هنگام بوت، چیزی شبیه به این را به فایل اضافه کنید:

.EX
[Install]
WantedBy=default.target
.EE

.PP
در حال حاضر، تنها کلیدهای \fBAlias\fR، \fBWantedBy\fR، \fBRequiredBy\fR و \fBUpheldBy\fR پشتیبانی می‌شوند.

.PP
بخش Install می‌تواند بخشی از فایل اصلی باشد، یا می‌تواند همان‌طور که در بالا توضیح داده شد
در یک فایل تکمیلی (Drop-in) جداگانه قرار گیرد. حالت دوم به شما امکان می‌دهد
یک واحد غیرفعال را نصب کرده و بعداً با نصب فایل تکمیلی
آن را فعال نمایید.

.SS فایل‌های الگو (Template files)
سیستم‌دی از مفهوم فایل‌های الگو پشتیبانی می‌کند.
آن‌ها واحدهایی با نام‌هایی به فرم "basename@instancename.service"
هنگام اجرا هستند، اما می‌توانند چندین بار از یک فایل منفرد "basename@.service"
نمونه‌سازی شوند. نمونه‌های جداگانه همچنین می‌توانند با استفاده از فایل‌های تکمیلی
دارای نام کامل نمونه، متفاوت باشند.

.PP
ابزار Quadlet به دو روش از این فایل‌ها پشتیبانی می‌کند. اول از همه، یک واحد Quadlet با
فرم الگو، یک سرویس systemd با فرم الگو تولید می‌کند و
سرویس الگوی systemd می‌تواند به عنوان یک الگوی معمولی استفاده شود.
برای مثال، "foo@.container" فایل "foo@.service" را تولید می‌کند و سپس
می‌توانید "systemctl start foo@bar.service" را اجرا کنید.

.PP
ثانیاً، اگر یک پیوند نمادین مانند "foo@instance.container" ایجاد کنید، آن پیوند
یک فایل الگوی نمونه‌سازی‌شده تولید خواهد کرد. هنگام تولید این فایل،
Quadlet فایل‌های تکمیلی را هم از دایرکتوری نمونه‌سازی‌شده
(foo@instance.container.d) و هم از دایرکتوری الگو
(foo@.container.d) می‌خواند. این امکان سفارشی‌سازی نمونه‌های جداگانه را فراهم می‌کند.

.PP
فایل‌های الگوی نمونه‌سازی‌شده (مانند \fBfoo@bar.container\fR) را می‌توان دقیقاً مانند
موارد بدون الگو فعال کرد. با این حال، موارد الگو
(\fBfoo@.container\fR) متفاوت هستند، زیرا نیاز به نمونه‌سازی دارند.
اگر بخش \fB[Install]\fR شامل کلید \fBDefaultInstance=\fR باشد،
آن نمونه فعال خواهد شد، اما اگر نباشد، هیچ اتفاقی رخ نمی‌دهد
و گزینه‌ها تنها به عنوان پیش‌فرض برای واحدهایی که با استفاده از پیوندهای نمادین نمونه‌سازی شده‌اند
استفاده خواهند شد.

.PP
یک فایل الگوی نمونه مانند \fBsleep@.container\fR ممکن است به این شکل باشد:

.EX
[Unit]
Description=A templated sleepy container

[Container]
Image=quay.io/fedora/fedora
Exec=sleep %i

[Service]
# Restart service when sleep finishes
Restart=always

[Install]
WantedBy=multi-user.target
DefaultInstance=100
.EE

.PP
اگر این فایل نصب شود، در هنگام بوت یک \fBsleep@100.service\fR
در حال اجرا خواهد بود که به مدت ۱۰۰ ثانیه می‌خوابد (متوقف می‌شود). سپس می‌توانید کاری مانند
\fBsystemctl start sleep@50.service\fR را برای راه‌اندازی نمونه دیگری که
۵۰ ثانیه می‌خوابد انجام دهید، یا متناوباً سرویس دیگری می‌تواند آن را از طریق یک
وابستگی مانند \fBWants=sleep@50.service\fR راه‌اندازی کند.

.PP
علاوه بر این، اگر دستور \fBln -s sleep@.container sleep@10.container\fR را اجرا کنید،
یک خواب ۱۰ ثانیه‌ای در حال اجرا در زمان بوت نیز خواهید داشت. و اگر بخواهید
آن نمونه خاص با تصویر دیگری اجرا شود، می‌توانید یک فایل تکمیلی مانند
\fBsleep@10.container.d/10-image.conf\fR ایجاد کنید:

.EX
[Container]
Image=quay.io/centos/centos
.EE

.SS ارجاع به سایر Quadletهای الگو
اغلب پیش می‌آید که بخواهید از یک Quadlet به یک Quadlet الگوی دیگر
ارجاع دهید. برای مثال، ممکن است بخواهید هر نمونه از \fBfoo@.container\fR
یک جلد مجزا را سوار (mount) کند. در این حالت می‌توانید یک Quadlet الگو به نام
\fBfoo-data@.volume\fR (نام اختیاری است) ایجاد کرده و در \fBfoo@.container\fR به آن ارجاع دهید:

.PP
\fBfoo-data@.volume\fR:

.EX
[Volume]
# Optional: without an explicit VolumeName, Quadlet auto-generates one with a
# "systemd-" prefix (e.g. systemd-foo-data-%i for foo-data@.volume).
# This does not affect how you reference this Quadlet from other Quadlets.
VolumeName=my-name-%i
.EE

.PP
\fBfoo@.container\fR:

.EX
[Container]
Volume=foo-data@.volume:/mnt/path
.EE

.PP
توجه داشته باشید که ما به جای نام نمونه \fBfoo-data@%i.volume\fR به نام الگو
یعنی \fBfoo-data@.volume\fR ارجاع می‌دهیم. ابزار Quadlet فایل الگو را خوانده
و نام صحیح جلد را (همراه با مشخص‌کننده systemd) برای
دستور \fBpodman run\fR در فایل \fB\&.service\fR تولیدشده تعیین می‌کند. در این مثال،
مقدار \fBExecStart\fR تولیدشده توسط Quadlet شبیه به این خواهد بود:

.EX
ExecStart=/usr/bin/podman run ... -v my-name-%i:/mnt/path ...
.EE

.SS مسیرهای نسبی (Relative paths)
به منظور پشتیبانی از مشخص‌کننده‌های Systemd، ابزار Quadlet مسیرهای نسبی را که با \fB%\fR شروع می‌شوند حل نمی‌کند.
برای حل چنین مسیری، \fB\&./\fR را به ابتدای آن اضافه کنید.

.PP
برای مثال، به جای \fBEnvironmentFile=%n/env\fR از \fBEnvironmentFile=./%n/env\fR استفاده کنید.

.SS اشکال‌زدایی فایل‌های واحد
پس از قرار دادن فایل واحد در یکی از مسیرهای جستجوی واحد (ذکر شده
در بالا)، می‌توانید آن را با \fBsystemctl start {--user}\fR راه‌اندازی کنید. اگر با خطای
"Failed to start example.service: Unit example.service not found." با شکست
مواجه شد، ممکن است از نحو نادرست استفاده کرده باشید یا گزینه‌ای از نسخه جدیدتر
Podman Quadlet به کار برده باشید و تولیدکننده در ایجاد فایل سرویس ناموفق بوده باشد.

.PP
مشاهده فایل‌های تولیدشده و/یا پیام‌های خطا با:

.EX
/usr/lib/systemd/system-generators/podman-system-generator {--user} --dryrun
.EE

.PP
همچنین، نمایش تنها خطاها با:

.EX
systemd-analyze {--user} --generators=true verify example.service
.EE

.PP
این دستور بررسی‌های بیشتری را نیز روی واحد سرویس تولیدشده انجام می‌دهد.
برای جزئیات، صفحه راهنمای systemd-analyze(1) را ببینید.

.SS اشکال‌زدایی مجموعه محدودی از فایل‌های واحد
اگر می‌خواهید مجموعه محدودی از فایل‌های واحد را اشکال‌زدایی کنید، می‌توانید آن‌ها را در یک دایرکتوری جداگانه کپی کرده و هنگام اجرای دستور زیر،
متغیر محیطی \fBQUADLET_UNIT_DIRS\fR را روی این دایرکتوری تنظیم کنید:

.EX
QUADLET_UNIT_DIRS=<Directory> /usr/lib/systemd/system-generators/podman-system-generator {--user} --dryrun
.EE

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

.SS وابستگی‌های ضمنی شبکه
ابزار Quadlet با افزودن ویژگی‌های \fBAfter=\fR و \fBWants=\fR به واحد، وابستگی‌هایی به \fBnetwork-online.target\fR (به عنوان ریشه) یا \fBpodman-user-wait-network-online.service\fR
(به عنوان کاربر) اضافه می‌کند. این کار برای اطمینان از قابل دسترس بودن شبکه
در صورت نیاز به دریافت تصویر و در زمان راه‌اندازی کانتینر است.

.PP
واحد ویژه \fBpodman-user-wait-network-online.service\fR برای کاربر مورد نیاز است، زیرا واحدهای کاربری قادر به انتظار
برای واحدهای سیستمی (ریشه) نیستند، بنابراین \fBnetwork-online.target\fR در آنجا کاری انجام نمی‌دهد و نادیده گرفته می‌شود. از آنجا که این مسئله
مشکلات زیادی ایجاد کرده بود، تصمیم گرفتیم با واحد ویژه خودمان این مشکل را دور بزنیم که به سادگی بررسی می‌کند
آیا واحد \fBnetwork-online.target\fR با دستور \fBsystemctl is-active network-online.target\fR فعال است یا خیر.

.PP
این رفتار را می‌توان با افزودن \fBDefaultDependencies=false\fR در بخش \fBQuadlet\fR غیرفعال کرد.
توجه داشته باشید که بخش \fB[Unit]\fR در \fIsystemd\fP گزینه‌ای با همین نام اما مفهومی متفاوت دارد.

.SS وابستگی میان واحدهای Quadlet
ابزار Quadlet به طور خودکار وابستگی‌های مشخص‌شده در کلیدهای
\fBWants\fR، \fBRequires\fR، \fBRequisite\fR، \fBBindsTo\fR، \fBPartOf\fR، \fBUpholds\fR، \fBConflicts\fR، \fBBefore\fR و \fBAfter\fR
از بخش \fB[Unit]\fR را میان واحدهای مختلف Quadlet ترجمه می‌کند.

.PP
به عنوان مثال، واحد \fBfedora.container\fR در زیر، یک وابستگی به واحد \fBbasic.container\fR را مشخص می‌کند.

.EX
[Unit]
After=basic.container
Requires=basic.container

[Container]
Image=registry.fedoraproject.org/fedora:41
.EE

.SS تنظیم نام منابع
واحدهای Quadlet اجازه تنظیم نام منابع ایجادشده را می‌دهند
(مانند \fBVolumeName\fR برای واحدهای \fB\&.volume\fR یا \fBPodName\fR برای واحدهای \fB\&.pod\fR).

.PP
توجه داشته باشید که استفاده از مشخص‌کننده‌های systemd که به واحد سرویس تولیدشده ارجاع می‌دهند (مانند \fB$N\fR)،
توانایی Quadlet برای پیوند دادن منابع را مختل می‌کند زیرا در هر سرویس به گونه متفاوتی ترجمه می‌شوند.

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

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

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

.PP
گزینه‌های مجاز برای \fB[Container]\fR در زیر فهرست شده‌اند:

.TS
allbox;
l l 
l l .
\fB\fBگزینه‌های [Container]\fP\fP	\fB\fBمعادل podman run\fP\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"
AppArmor="alternate-profile"	T{
--security-opt apparmor=alternate-profile
T}
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}
ServiceName=name	نام‌گذاری واحد systemd به صورت \fBname.service\fR
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=\fR
افزودن این قابلیت‌ها (capabilities)، علاوه بر مجموعه قابلیت‌های پیش‌فرض پودمن، به کانتینر.

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

.PP
برای مثال:

.EX
AddCapability=CAP_DAC_OVERRIDE CAP_IPC_OWNER
.EE

.SS \fBAddDevice=\fR
یک گره دستگاه را از میزبان به درون کانتینر اضافه می‌کند. قالب آن به صورت
\fBHOST-DEVICE[:CONTAINER-DEVICE][:PERMISSIONS]\fR است که در آن \fBHOST-DEVICE\fR مسیر
گره دستگاه روی میزبان، \fBCONTAINER-DEVICE\fR مسیر گره دستگاه در
کانتینر، و \fBPERMISSIONS\fR فهرستی از مجوزها شامل ترکیبی از 'r' برای خواندن،
\&'w' برای نوشتن، و 'm' برای mknod(2) است. پیشوند \fB-\fR به Quadlet می‌گوید که دستگاه
را تنها در صورتی که روی میزبان وجود داشته باشد اضافه کند.

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

.SS \fBAddHost=\fR
افزودن نگاشت میزبان به IP به /etc/hosts.
قالب آن به صورت \fBhostname:ip\fR است.

.PP
معادل گزینه \fB--add-host\fR در پودمن.
این کلید می‌تواند چندین بار درج شود.

.SS \fBAnnotation=\fR
تنظیم یک یا چند حاشیه‌نویسی OCI (OCI annotations) روی کانتینر. قالب آن فهرستی از موارد \fBkey=value\fR است،
مشابه با \fBEnvironment\fR\&.

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

.SS \fBAppArmor=\fR
پروفایل محدودسازی apparmor را برای کانتینر تنظیم می‌کند. مقدار \fBunconfined\fR محدودسازی apparmor را غیرفعال می‌کند.

.SS \fBAutoUpdate=\fR
مشخص می‌کند که آیا کانتینر به طور خودکار به‌روزرسانی شود یا خیر (podman-auto-update(1)). مقادیر زیر پشتیبانی می‌شوند:
.IP \(bu 2
\fBregistry\fR: مستلزم استفاده از یک مرجع تصویر کاملاً مشخص (مانند quay.io/podman/stable:latest) برای ساخت کانتینر است. این الزام برای دانستن این که دقیقاً کدام تصویر باید بررسی و دریافت شود، ضروری است. اگر از شناسه تصویر استفاده شده باشد، پودمن دیگر نمی‌داند کدام تصویر را باید بررسی یا دریافت کند.
.IP \(bu 2
\fBlocal\fR: به پودمن اعلام می‌کند که تصویر مورد استفاده کانتینر را با تصویری با نام خام در فضای ذخیره‌سازی محلی مقایسه کند. اگر یک تصویر به صورت محلی به‌روزرسانی شود، پودمن به سادگی واحد systemd مجری کانتینر را مجدداً راه‌اندازی می‌کند.

.SS \fBCgroupsMode=\fR
حالت cgroups در کانتینر پودمن. معادل گزینه \fB--cgroups\fR در پودمن.

.PP
به طور پیش‌فرض، حالت cgroups کانتینر ایجادشده توسط Quadlet برابر با \fBsplit\fR است
که با مقدار پیش‌فرض (\fBenabled\fR) مورد استفاده در CLI پودمن تفاوت دارد.

.PP
اگر کانتینر به یک پاد بپیوندد (یعنی \fBPod=\fR مشخص شده باشد)، ممکن است بخواهید این مقدار را به
\fBno-conmon\fR یا \fBenabled\fR تغییر دهید تا محدودیت‌های منابع cgroup در سطح پاد بتوانند اعمال شوند.

.SS \fBContainerName=\fR
نام (اختیاری) کانتینر پودمن. اگر این گزینه مشخص نشود، مقدار پیش‌فرض
\fBsystemd-%N\fR استفاده می‌شود که همان نام سرویس است اما با یک پیشوند \fBsystemd-\fR
تا از تداخل با کانتینرهای مدیریت‌شده توسط کاربر جلوگیری شود.

.SS \fBContainersConfModule=\fR
بارگذاری ماژول مشخص‌شده containers.conf(5). معادل گزینه \fB--module\fR در پودمن.

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

.SS \fBDNS=\fR
تنظیم تحلیل‌گر نام/کارساز نام DNS در حوزه شبکه برای کانتینرهای موجود در این شبکه.

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

.SS \fBDNSOption=\fR
تنظیم گزینه‌های سفارشی DNS.

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

.SS \fBDNSSearch=\fR
تنظیم دامنه‌های جستجوی سفارشی DNS. برای حذف دامنه جستجو از \fBDNSSearch=.\fP استفاده کنید.

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

.SS \fBDropCapability=\fR
حذف این قابلیت‌ها از مجموعه قابلیت‌های پیش‌فرض پودمن، یا مقدار \fBall\fR برای حذف تمام قابلیت‌ها.

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

.PP
برای مثال:

.EX
DropCapability=CAP_DAC_OVERRIDE CAP_IPC_OWNER
.EE

.SS \fBEntrypoint=\fR
بازنویسی ENTRYPOINT پیش‌فرض از تصویر.
معادل گزینه \fB--entrypoint\fR در پودمن.
دستورات چندگزینه‌ای را در قالب یک رشته JSON مشخص کنید.

.SS \fBEnvironment=\fR
تنظیم یک متغیر محیطی در کانتینر. این گزینه از همان قالب
سرویس‌ها در systemd استفاده می‌کند
و می‌تواند چندین بار درج شود.

.SS \fBEnvironmentFile=\fR
استفاده از یک فایل خط‌به‌خط برای تنظیم متغیرهای محیطی در کانتینر.
مسیر ممکن است مطلق یا نسبت به محل فایل واحد باشد.
این کلید می‌تواند چندین بار استفاده شود و ترتیب آن هنگام ارسال به \fBpodman run\fR حفظ می‌شود.

.SS \fBEnvironmentHost=\fR
استفاده از محیط میزبان در داخل کانتینر.

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

.PP
قالب آن همانند خط فرمان‌های systemd است؛
با این حال، برخلاف سناریوی استفاده از عبارت با نام مشابه \fBExecStart=\fR در systemd
که روی فایل‌سیستم ریشه محیط عمل می‌کند، در تصاویر کانتینر
بسیار معمول است که متادیتای \fBENTRYPOINT\fR یا \fBCMD\fR اختصاصی خود را داشته باشند که این گزینه با آن تعامل می‌کند.

.PP
انتظار پیش‌فرض برای بسیاری از تصاویر این است که تصویر شامل یک \fBENTRYPOINT\fR
با یک باینری پیش‌فرض باشد و این فیلد آرگومان‌هایی را به آن نقطه ورود اضافه کند.

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

.SS \fBExposeHostPort=\fR
در معرض قرار دادن یک درگاه، یا بازه‌ای از درگاه‌ها (مانند \fB50-59\fR)، از میزبان به کانتینر. معادل
گزینه \fB--expose\fR در پودمن.

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

.SS \fBGIDMap=\fR
اجرای کانتینر در یک فضای‌نام کاربری جدید با استفاده از نگاشت GID ارائه‌شده.
معادل گزینه \fB--gidmap\fR در پودمن.

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

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

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

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

.SS \fBGroup=\fR
شناسه گروه یا GID (عددی) برای اجرا به عنوان آن در داخل کانتینر. این شناسه نیازی به تطابق با GID روی میزبان ندارد،
که می‌تواند با \fBUserNS\fR تغییر یابد، اما اگر مشخص نشود، این GID روی میزبان نیز استفاده می‌شود.

.PP
نکته: هنگامی که هر دو گزینه \fBUser=\fR و \fBGroup=\fR مشخص شوند، در یک آرگومان منفرد
\fB--user USER:GROUP\fR ترکیب شده و به پودمن ارسال می‌شوند. استفاده از \fBGroup=\fR بدون \fBUser=\fR منجر به خطا خواهد شد.

.SS \fBGroupAdd=\fR
اختصاص گروه‌های اضافی به کاربر اصلی در حال اجرا درون فرآیند کانتینر. همچنین از پرچم ویژه \fBkeep-groups\fR پشتیبانی می‌کند.
معادل گزینه \fB--group-add\fR در پودمن.

.SS \fBHealthCmd=\fR
تنظیم یا تغییر دستور بررسی سلامت برای یک کانتینر. مقدار none بررسی‌های سلامت موجود را غیرفعال می‌کند.
معادل گزینه \fB--health-cmd\fR در پودمن.
.SS \fBHealthInterval=\fR
یک بازه زمانی برای بررسی‌های سلامت تنظیم می‌کند. مقدار بازه disable منجر به عدم راه‌اندازی تایمر خودکار می‌شود.
معادل گزینه \fB--health-interval\fR در Podman است.

.SS \fBHealthLogDestination=\fR
مقصد لاگ بررسی سلامت (HealthCheck) را تعیین می‌کند. مسیر یک دایرکتوری، local یا events_logger (حالت local از فایل وضعیت کانتینر استفاده می‌کند).
(پیش‌فرض: local)
معادل گزینه \fB--health-log-destination\fR در Podman است.
.IP \(bu 2
\fBlocal\fR: (پیش‌فرض) لاگ‌های بررسی سلامت در کانتینرهای overlay ذخیره می‌شوند (برای مثال: \fB$runroot/healthcheck.log\fR).
.IP \(bu 2
\fBdirectory\fR: یک فایل لاگ با نام \fB<container-ID>-healthcheck.log\fR حاوی لاگ‌های بررسی سلامت در دایرکتوری مشخص‌شده ایجاد می‌کند.
.IP \(bu 2
\fBevents_logger\fR: لاگ با سازوکار ثبت لاگ تنظیم‌شده توسط events_logger نوشته خواهد شد. این گزینه همچنین لاگ را برای کارایی بهتر در سیستمی با تعداد زیاد لاگ در یک دایرکتوری پیش‌فرض ذخیره می‌کند.

.SS \fBHealthMaxLogCount=\fR
حداکثر تعداد تلاش‌ها در فایل لاگ بررسی سلامت را تعیین می‌کند (مقدار '0' به معنای تعداد نامحدود تلاش‌ها در فایل لاگ است).
(پیش‌فرض: ۵ تلاش)
معادل گزینه \fB--Health-max-log-count\fR در Podman است.

.SS \fBHealthMaxLogSize=\fR
حداکثر طول کاراکترهای لاگ بررسی سلامت ذخیره‌شده را تنظیم می‌کند (مقدار "0" به معنای طول لاگ نامحدود است).
(پیش‌فرض: ۵۰۰ کاراکتر)
معادل گزینه \fB--Health-max-log-size\fR در Podman است.

.SS \fBHealthOnFailure=\fR
عملی که در صورت انتقال کانتینر به وضعیت ناسالم (unhealthy) باید انجام شود.
عمل "kill" در ترکیب با systemd بهترین یکپارچگی را دارد. به محض اینکه
کانتینر ناسالم شود، متوقف (kill) شده و systemd سرویس را مجدداً
راه‌اندازی می‌کند.
معادل گزینه \fB--health-on-failure\fR در Podman است.

.SS \fBHealthRetries=\fR
تعداد دفعات تلاش مجاز قبل از اینکه یک بررسی سلامت، ناسالم در نظر گرفته شود.
معادل گزینه \fB--health-retries\fR در Podman است.

.SS \fBHealthStartPeriod=\fR
زمان راه‌اندازی اولیه مورد نیاز برای بوت‌استرپ شدن کانتینر.
معادل گزینه \fB--health-start-period\fR در Podman است.

.SS \fBHealthStartupCmd=\fR
یک دستور بررسی سلامت راه‌اندازی برای کانتینر تنظیم می‌کند.
معادل گزینه \fB--health-startup-cmd\fR در Podman است.

.SS \fBHealthStartupInterval=\fR
یک بازه زمانی برای بررسی سلامت راه‌اندازی تنظیم می‌کند. مقدار بازه disable منجر به عدم راه‌اندازی تایمر خودکار می‌شود.
معادل گزینه \fB--health-startup-interval\fR در Podman است.

.SS \fBHealthStartupRetries=\fR
تعداد تلاش‌های مجاز قبل از اینکه بررسی سلامت راه‌اندازی، کانتینر را مجدداً راه‌اندازی کند.
معادل گزینه \fB--health-startup-retries\fR در Podman است.

.SS \fBHealthStartupSuccess=\fR
تعداد اجراهای موفق مورد نیاز پیش از موفقیت‌آمیز بودن بررسی سلامت راه‌اندازی و شروع بررسی سلامت عادی.
معادل گزینه \fB--health-startup-success\fR در Podman است.

.SS \fBHealthStartupTimeout=\fR
حداکثر زمانی که یک دستور بررسی سلامت راه‌اندازی برای تکمیل فرصت دارد قبل از اینکه ناموفق علامت‌گذاری شود.
معادل گزینه \fB--health-startup-timeout\fR در Podman است.

.SS \fBHealthTimeout=\fR
حداکثر زمان مجاز برای تکمیل بررسی سلامت قبل از ناموفق تلقی شدن یک بازه زمانی.
معادل گزینه \fB--health-timeout\fR در Podman است.

.SS \fBHostName=\fR
نام میزبان در دسترس در داخل کانتینر را تنظیم می‌کند.
معادل گزینه \fB--hostname\fR در Podman است.

.SS \fBHttpProxy=\fR
کنترل می‌کند که آیا متغیرهای محیطی پروکسی (http_proxy، https_proxy، ftp_proxy، no_proxy) هنگام دریافت ایمیج (pull) و ساخت آن (build) از فرایند Podman به درون کانتینر منتقل شوند یا خیر.

.PP
برای فعال‌سازی وراثت پروکسی (رفتار پیش‌فرض Podman) آن را برابر \fBtrue\fR یا برای غیرفعال‌سازی آن برابر \fBfalse\fR تنظیم کنید.
این گزینه به‌ویژه در سیستم‌هایی کاربرد دارد که برای دسترسی به اینترنت به پیکربندی پروکسی نیاز دارند اما مایل نیستند تنظیمات پروکسی به زمان اجرای کانتینر ارسال شود.

.PP
معادل گزینه \fB--http-proxy\fR در Podman است.

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

.PP
قالب نام همانند زمانی است که به \fBpodman pull\fR\& داده می‌شود. بنابراین برای تضمین نسخه خاصی از ایمیج از \fB:tag\fR یا شناسه یکتا (digest) پشتیبانی می‌کند.

.PP
حالت‌های خاص:
.IP \(bu 2
اگر \fBنام\fR ایمیج به \fB\&.image\fR ختم شود، Quadlet از ایمیج دریافت‌شده توسط فایل متناظر \fB\&.image\fR استفاده می‌کند، و سرویس systemd تولیدشده شامل وابستگی به \fB$name-image.service\fR (یا نام سرویس تنظیم‌شده در فایل .image) خواهد بود. توجه داشته باشید که فایل متناظر \fB\&.image\fR باید وجود داشته باشد.
.IP \(bu 2
اگر \fBنام\fR ایمیج به \fB\&.build\fR ختم شود، Quadlet از ایمیج ساخته‌شده توسط فایل متناظر \fB\&.build\fR استفاده می‌کند، و سرویس systemd تولیدشده شامل وابستگی به \fB$name-build.service\fR\& خواهد بود. نکته: فایل متناظر \fB\&.build\fR باید وجود داشته باشد.

.SS \fBImageVolume=\fR
به Podman می‌گوید چگونه حجم‌های داخلی ایمیج را مدیریت کند. پیش‌فرض \fBbind\fP\& است.
معادل گزینه \fB--image-volume\fR در Podman است.

.SS \fBIP=\fR
یک نشانی استاتیک IPv4 برای کانتینر تعیین می‌کند، برای مثال \fB10.88.64.128\fP\&.
معادل گزینه \fB--ip\fR در Podman است.

.SS \fBIP6=\fR
یک نشانی استاتیک IPv6 برای کانتینر تعیین می‌کند، برای مثال \fBfd46:db93:aa76:ac37::10\fP\&.
معادل گزینه \fB--ip6\fR در Podman است.

.SS \fBLabel=\fR
یک یا چند برچسب OCI را روی کانتینر تنظیم می‌کند. قالب آن به صورت فهرستی از موارد \fBkey=value\fR است،
مشابه \fBEnvironment\fR\&.

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

.SS \fBLogDriver=\fR
درایور لاگ‌گیری (log-driver) مورد استفاده توسط Podman هنگام اجرای کانتینر را تنظیم می‌کند.
معادل گزینه \fB--log-driver\fR در Podman است.

.SS \fBLogOpt=\fR
گزینه‌های ثبت لاگ (log-opt) مورد استفاده توسط Podman هنگام اجرای کانتینر را تنظیم می‌کند.
معادل گزینه \fB--log-opt\fR در Podman است.
این کلید می‌تواند چندین بار درج شود.

.SS \fBMask=\fR
مسیرهایی که باید ماسک شوند را جداشده با دونقطه مشخص می‌کند: \fBMask=/path/1:/path/2\fR\&. یک مسیر ماسک‌شده در داخل کانتینر قابل دسترسی نیست.

.SS \fBMemory=\fR
میزان حافظه برای کانتینر را مشخص می‌کند.

.SS \fBMount=\fR
یک نقطه اتصال سیستم‌فایل را به کانتینر متصل (mount) می‌کند.
این معادل گزینه \fB--mount\fR در Podman است، و
عموماً قالبی به شکل \fBtype=TYPE,TYPE-SPECIFIC-OPTION[,...]\fR\& دارد.

.PP
حالت‌های خاص:
.IP \(bu 2
برای \fBtype=volume\fR، اگر \fBsource\fR به \fB\&.volume\fR ختم شود، از حجم نام‌گذاری‌شده Podman که توسط فایل متناظر \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
این کلید می‌تواند چندین بار درج شود.

.SS \fBNetwork=\fR
یک شبکه سفارشی برای کانتینر مشخص می‌کند. این گزینه همان قالبی را دارد که گزینه \fB--network\fR
در \fBpodman run\fR\& دارد. برای مثال، از \fBhost\fR برای استفاده از شبکه میزبان در کانتینر، یا از \fBnone\fR برای
عدم راه‌اندازی شبکه در کانتینر استفاده کنید.

.PP
حالت‌های خاص:
.IP \(bu 2
اگر \fBنام\fR شبکه به \fB\&.network\fR ختم شود، یک شبکه Podman به نام
\fBsystemd-$name\fR استفاده می‌شود، و سرویس systemd تولیدشده شامل
یک وابستگی به \fB$name-network.service\fR\& خواهد بود. چنین شبکه‌ای می‌تواند به طور خودکار
با استفاده از فایل Quadlet با نام \fB$name.network\fR ایجاد شود. نکته: فایل متناظر \fB\&.network\fR باید وجود داشته باشد.
.IP \(bu 2
اگر \fBنام\fR به \fB\&.container\fR ختم شود،
کانتینر از پشته شبکه کانتینر دیگری که توسط \fB$name.container\fR\& ایجاد شده است مجدداً استفاده خواهد کرد.
سرویس systemd تولیدشده شامل یک وابستگی به \fB$name.service\fR\& خواهد بود. نکته: فایل متناظر \fB\&.container\fR باید وجود داشته باشد.

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

.SS \fBNetworkAlias=\fR
یک نام مستعار در محدوده شبکه برای کانتینر اضافه می‌کند. این گزینه دارای همان قالبی است که گزینه \fB--network-alias\fR
در دستور \fBpodman run\fR\& دارد. از نام‌های مستعار می‌توان برای گروه‌بندی کانتینرها با یکدیگر در تفکیک DNS استفاده کرد: برای
مثال، تنظیم \fBNetworkAlias=web\fR روی چند کانتینر باعث می‌شود که یک پرس‌وجوی DNS برای نام \fBweb\fR به
تمام کانتینرهای دارای آن نام مستعار هدایت شود.

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

.SS \fBNoNewPrivileges=\fR (پیش‌فرض \fBfalse\fR)
در صورت فعال بودن، فرایندهای کانتینر را از دستیابی به مجوزهای بیشتر از طریق مواردی مانند
setuid و قابلیت‌های فایل (file capabilities) منع می‌کند.

.SS \fBNotify=\fR (پیش‌فرض \fBfalse\fR)
به‌طور پیش‌فرض، Podman به گونه‌ای اجرا می‌شود که دستور اطلاع‌رسانی راه‌اندازی systemd توسط
زمان اجرای کانتینر مدیریت می‌شود. به عبارت دیگر، سرویس زمانی شروع‌شده تلقی می‌شود که زمان اجرای کانتینر
فرایند فرزند را در کانتینر آغاز کند. با این حال، اگر برنامه کانتینر از
sd_notify پشتیبانی کند، تنظیم
\fBNotify\fR به true جزئیات اعلان را به کانتینر ارسال می‌کند و به آن اجازه می‌دهد تا
راه‌اندازی را خودش اعلام کند.

.PP
علاوه بر این، تنظیم \fBNotify\fR به \fBhealthy\fR اعلان‌های راه‌اندازی را تا زمانی که
کانتینر طبق بررسی‌های سلامت Podman سالم علامت‌گذاری شود به تعویق می‌اندازد. توجه داشته باشید که این امر مستلزم
راه‌اندازی بررسی سلامت کانتینر است، برای اطلاعات بیشتر گزینه \fBHealthCmd\fR را ببینید.

.SS \fBPidsLimit=\fR
محدودیت شناسه‌های فرایند (pids limit) کانتینر را تنظیم می‌کند.
این معادل گزینه \fB--pids-limit\fR در Podman است.

.SS \fBPod=\fR
یک واحد Quadlet از نوع \fB\&.pod\fR را برای پیوند دادن کانتینر به آن مشخص می‌کند.
مقدار باید به صورت \fB<name>.pod\fR باشد و واحد \fB\&.pod\fR باید وجود داشته باشد.

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

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

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

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

.SS \fBPublishPort=\fR
یک پورت یا محدوده‌ای از پورت‌ها (مانند \fB50-59\fR) را از کانتینر به میزبان متصل و نمایان می‌سازد. معادل
گزینه \fB--publish\fR در Podman است. قالب آن مشابه گزینه‌های Podman بوده و
به صورت \fBip:hostPort:containerPort\fR، \fBip::containerPort\fR، \fBhostPort:containerPort\fR یا
\fBcontainerPort\fR است که در آن تعداد پورت‌های میزبان و کانتینر باید برابر باشند (در حالت
یک محدوده). پروتکل را می‌توان در انتها قید کرد، مانند \fBhostPort:containerPort/tcp\fR\&.
پروتکل‌های معتبر \fBtcp\fR و \fBudp\fR هستند؛ پروتکل \fBsctp\fR فقط برای کانتینرهای با ریشه (rootful) پشتیبانی می‌شود.

.PP
اگر IP برابر با 0.0.0.0 تنظیم شود یا اصلاً مشخص نشود، پورت به تمام نشانی‌های IPv4 روی
میزبان پیوند می‌خورد؛ برای IPv6 از [::] استفاده کنید.

.PP
توجه داشته باشید که مشخص نکردن پورت میزبان به این معناست که Podman به صورت خودکار یک پورت را انتخاب می‌کند، و این پورت
ممکن است در هر بار فراخوانی سرویس متفاوت باشد. این مسئله باعث می‌شود گزینه کمتر مفیدی باشد. پورت
اختصاص‌یافته را می‌توان با دستور \fBpodman port\fR پیدا کرد.

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

.SS \fBPull=\fR
سیاست دریافت ایمیج (pull policy) را تعیین می‌کند.
این معادل گزینه \fB--pull\fR در Podman است.

.SS \fBReadOnly=\fR (پیش‌فرض \fBfalse\fR)
در صورت فعال بودن، ایمیج را فقط‌خواندنی می‌کند.

.SS \fBReadOnlyTmpfs=\fR (پیش‌فرض \fBtrue\fR)
اگر ReadOnly روی \fBtrue\fR تنظیم شده باشد، یک tmpfs خواندنی-نوشتنی روی مسیرهای /dev، /dev/shm، /run، /tmp و /var/tmp متصل (mount) می‌کند.

.SS \fBReloadCmd=\fR
خط \fBExecReload\fR را به \fBService\fR اضافه می‌کند که \fBpodman exec\fR را همراه با این دستور در این کانتینر اجرا می‌نماید.

.PP
به منظور اجرای بارگذاری مجدد، دستور \fBsystemctl reload <Service>\fR را اجرا کنید.

.PP
با \fBReloadSignal\fR ناسازگار و مانعه‌الجمع است.

.SS \fBReloadSignal=\fR
خط \fBExecReload\fR را به \fBService\fR اضافه می‌کند که \fBpodman kill\fR را همراه با این سیگنال اجرا کرده و سیگنال را به فرایند اصلی کانتینر ارسال می‌نماید.

.PP
به منظور اجرای بارگذاری مجدد، دستور \fBsystemctl reload <Service>\fR را اجرا کنید.

.PP
با \fBReloadCmd\fR ناسازگار و مانعه‌الجمع است.

.SS \fBRetry=\fR
تعداد دفعات تلاش مجدد برای دریافت ایمیج هنگام بروز خطای HTTP. معادل گزینه \fB--retry\fR در Podman است.

.SS \fBRetryDelay=\fR
تاخیر زمانی میان تلاش‌های مجدد. معادل گزینه \fB--retry-delay\fR در Podman است.

.SS \fBRootfs=\fR
سیستم‌فایل ریشه (rootfs) مورد استفاده برای کانتینر. گزینه Rootfs به یک دایرکتوری در سیستم اشاره دارد که شامل محتوایی است که باید درون کانتینر اجرا شود. این گزینه با گزینه \fBImage\fR در تضاد است.

.PP
قالب rootfs همانند زمانی است که به \fBpodman run --rootfs\fR پاس داده می‌شود، بنابراین از مانت‌های overlay نیز پشتیبانی می‌کند.

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

.SS \fBRunInit=\fR (پیش‌فرض \fBfalse\fR)
در صورت فعال بودن، کانتینر دارای یک فرایند init مینیمال درون
کانتینر خواهد بود که سیگنال‌ها را فوروارد کرده و فرایندهای بدون سرپرست را جمع‌آوری (reap) می‌کند.

.SS \fBSeccompProfile=\fR
پروفایل seccomp مورد استفاده در کانتینر را تعیین می‌کند. در صورت عدم تنظیم، از پروفایل پیش‌فرض Podman استفاده می‌شود.
مقدار را برابر مسیر یک فایل JSON، یا \fBunconfined\fR برای غیرفعال کردن فیلترهای seccomp تنظیم کنید.

.SS \fBSecret=\fR
استفاده از یک سکرت Podman در کانتینر به صورت یک فایل یا یک متغیر محیطی.
این معادل گزینه \fB--secret\fR در Podman است و عموماً قالبی به شکل \fBsecret[,opt=opt ...]\fR دارد.

.SS \fBSecurityLabelDisable=\fR
جداسازی برچسب‌های امنیتی را برای کانتینر غیرفعال می‌کند.

.SS \fBSecurityLabelFileType=\fR
نوع فایل برچسب امنیتی را برای فایل‌های کانتینر تنظیم می‌کند.

.SS \fBSecurityLabelLevel=\fR
سطح فرایند برچسب امنیتی را برای فرایندهای کانتینر تنظیم می‌کند.

.SS \fBSecurityLabelNested=\fR
به برچسب‌های امنیتی (SecurityLabels) اجازه عملکرد درون کانتینر را می‌دهد. این قابلیت امکان جداسازی کانتینرهای ایجادشده درون این کانتینر را فراهم می‌سازد.

.SS \fBSecurityLabelType=\fR
نوع فرایند برچسب امنیتی را برای فرایندهای کانتینر تنظیم می‌کند.

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

.PP
نکته: نام نباید شامل پسوند فایل \fB\&.service\fR باشد.

.SS \fBShmSize=\fR
اندازه دایرکتوری /dev/shm.

.PP
این معادل گزینه \fB--shm-size\fR در Podman است و عموماً قالبی به شکل \fBnumber[unit]\fR دارد.

.SS \fBStartWithPod=\fR
کانتینر را پس از ایجاد شدن پاد مرتبط راه‌اندازی می‌کند. پیش‌فرض \fBtrue\fP\& است.

.PP
اگر برابر \fBtrue\fR باشد، کانتینر در کنار پاد راه‌اندازی/متوقف/بازراه‌اندازی خواهد شد.

.PP
اگر برابر \fBfalse\fR باشد، کانتینر با شروع به کار پاد راه‌اندازی نمی‌شود. کانتینر همراه با پاد متوقف خواهد شد. بازراه‌اندازی پاد همچنین تا زمانی که کانتینر پیش از آن در حال اجرا بوده باشد، کانتینر را نیز مجدداً راه‌اندازی می‌کند.

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

.SS \fBStopSignal=\fR
سیگنال برای متوقف کردن کانتینر. پیش‌فرض \fBSIGTERM\fP\& است.

.PP
این معادل گزینه \fB--stop-signal\fR در Podman است.

.SS \fBStopTimeout=\fR
تعداد ثانیه‌های انتظار پیش از متوقف کردن اجباری کانتینر.

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

.PP
این معادل گزینه \fB--stop-timeout\fR در Podman است.

.SS \fBSubGIDMap=\fR
اجرای کانتینر در یک فضای نام کاربری جدید با استفاده از نگاشت دارای این نام در فایل /etc/subgid.
معادل گزینه \fB--subgidname\fR در Podman است.

.SS \fBSubUIDMap=\fR
اجرای کانتینر در یک فضای نام کاربری جدید با استفاده از نگاشت دارای این نام در فایل /etc/subuid.
معادل گزینه \fB--subuidname\fR در Podman است.

.SS \fBSysctl=\fR
پارامترهای هسته دارای فضای نام را برای کانتینر پیکربندی می‌کند. قالب آن به صورت \fBSysctl=name=value\fR\& است.

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

.PP
برای مثال:

.EX
Sysctl=net.ipv6.conf.all.disable_ipv6=1 net.ipv6.conf.all.use_tempaddr=1
.EE

.SS \fBTimezone=\fR (در صورت عدم تنظیم از پیش‌فرض پیکربندی‌شده سیستم استفاده می‌کند)
منطقه زمانی که کانتینر باید در آن اجرا شود.

.SS \fBTmpfs=\fR
یک tmpfs را در کانتینر متصل (mount) می‌کند. این معادل گزینه \fB--tmpfs\fR در Podman است، و
عموماً قالبی به شکل \fBCONTAINER-DIR[:OPTIONS]\fR\& دارد.

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

.SS \fBUIDMap=\fR
اجرای کانتینر در یک فضای نام کاربری جدید با استفاده از نگاشت UID ارائه‌شده.
معادل گزینه \fB--uidmap\fR در Podman است.

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

.SS \fBUlimit=\fR
گزینه‌های Ulimit. مقادیر ulimit را درون کانتینر تنظیم می‌کند.

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

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

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

.PP
مسیرهای پیش‌فرضی که ماسک شده‌اند عبارتند از: /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
مسیرهای پیش‌فرضی که فقط‌خواندنی هستند عبارتند از: /proc/asound، /proc/bus، /proc/fs، /proc/irq، /proc/sys، /proc/sysrq-trigger و /sys/fs/cgroup.

.SS \fBUser=\fR
شناسه کاربری عددی (UID) برای اجرا در داخل کانتینر. این مقدار نیازی به مطابقت با UID روی میزبان ندارد،
که می‌توان آن را با \fBUserNS\fR تغییر داد، اما اگر مشخص نشود، همین UID روی میزبان نیز استفاده می‌شود.

.PP
نکته: هنگامی که هر دو گزینه \fBUser=\fR و \fBGroup=\fR مشخص شده باشند، در یک آرگومان واحد به صورت \fB--user USER:GROUP\fR
ترکیب شده و به Podman ارسال می‌شوند.

.SS \fBUserNS=\fR
حالت فضای نام کاربری را برای کانتینر تنظیم می‌کند. این معادل گزینه \fB--userns\fR در Podman است و
عموماً قالبی به شکل \fBMODE[:OPTIONS,...]\fR\& دارد.

.SS \fBVolume=\fR
یک حجم را در کانتینر متصل (mount) می‌کند. این معادل گزینه \fB--volume\fR در Podman است، و
عموماً قالبی به شکل \fB[[SOURCE-VOLUME|HOST-DIR:]CONTAINER-DIR[:OPTIONS]]\fR\& دارد.

.PP
اگر \fBSOURCE-VOLUME\fR با \fB\&.\fR آغاز شود، Quadlet مسیر را به صورت نسبی نسبت به مکان فایل واحد تحلیل می‌کند.

.PP
حالت خاص:
.IP \(bu 2
اگر \fBSOURCE-VOLUME\fR به \fB\&.volume\fR ختم شود، یک حجم نام‌گذاری‌شده Podman به نام \fBsystemd-$name\fR به عنوان منبع استفاده می‌شود، و سرویس systemd تولیدشده شامل یک وابستگی به \fB$name-volume.service\fR\& خواهد بود. توجه داشته باشید که فایل متناظر \fB\&.volume\fR باید وجود داشته باشد.

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

.SS \fBWorkingDir=\fR
دایرکتوری کاری درون کانتینر.

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

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

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

.PP
سرویس تولیدشده به‌طور پیش‌فرض روی \fBRestart=on-failure\fR\& تنظیم می‌شود. توجه داشته باشید که با \fBExitPolicy=stop\fR (مقدار
پیش‌فرض برای پادهای Quadlet)، پاد هنگام توقف تمام کانتینرهایش به‌طور تمیز (کد خروج ۰) خارج می‌شود، بنابراین
\fBon-failure\fR در این حالت راه‌اندازی مجددی را آغاز \fBنخواهد کرد\fP. برای اینکه پاد هنگام خروج کانتینرها به‌طور خودکار
مجدداً راه‌اندازی شود، در بخش \fB[Service]\fR فایل \fB\&.pod\fR گزینه \fBRestart=always\fR را تنظیم کنید.

.PP
گزینه‌های معتبر برای \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
StopTimeout=20	--time=20
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=\fR
یک نگاشت نام میزبان به IP را به /etc/hosts اضافه می‌کند.
قالب آن به صورت \fBhostname:ip\fR\& است.

.PP
معادل گزینه \fB--add-host\fR در Podman است.
این کلید می‌تواند چندین بار درج شود.

.SS \fBContainersConfModule=\fR
ماژول مشخص‌شده در containers.conf(5) را بارگذاری می‌کند. معادل گزینه \fB--module\fR در Podman است.

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

.SS \fBDNS=\fR
تحلیل‌گر DNS/نام‌سرور در محدوده شبکه را برای کانتینرهای موجود در این پاد تنظیم می‌کند.

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

.SS \fBDNSOption=\fR
گزینه‌های سفارشی DNS را تنظیم می‌کند.

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

.SS \fBDNSSearch=\fR
دامنه‌های جستجوی سفارشی DNS را تنظیم می‌کند. از \fBDNSSearch=.\fP برای حذف دامنه جستجو استفاده کنید.

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

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

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

.SS \fBGIDMap=\fR
ایجاد پاد در یک فضای نام کاربری جدید با استفاده از نگاشت GID ارائه‌شده.
معادل گزینه \fB--gidmap\fR در Podman است.

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

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

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

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

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

.PP
نام میزبان ارائه‌شده همچنین با استفاده از نشانی IP اصلی کانتینر به فایل /etc/hosts اضافه می‌شود (همچنین گزینه \fB--add-host\fR را ببینید).

.PP
معادل گزینه \fB--hostname\fR در Podman است.

.SS \fBIP=\fR
یک نشانی استاتیک IPv4 برای پاد تعیین می‌کند، برای مثال \fB10.88.64.128\fP\&.
معادل گزینه \fB--ip\fR در Podman است.

.SS \fBIP6=\fR
یک نشانی استاتیک IPv6 برای پاد تعیین می‌کند، برای مثال \fBfd46:db93:aa76:ac37::10\fP\&.
معادل گزینه \fB--ip6\fR در Podman است.

.SS \fBLabel=\fR
یک یا چند برچسب OCI را روی پاد تنظیم می‌کند. قالب آن به صورت فهرستی از
موارد \fBkey=value\fR است، مشابه \fBEnvironment\fR\&.

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

.SS \fBNetwork=\fR
یک شبکه سفارشی برای پاد مشخص می‌کند.
این گزینه دارای همان قالبی است که گزینه \fB--network\fR در دستور \fBpodman pod create\fR\& دارد.
برای مثال، از \fBhost\fR برای استفاده از شبکه میزبان در پاد، یا از \fBnone\fR برای عدم راه‌اندازی شبکه در پاد استفاده کنید.

.PP
حالت خاص:
.IP \(bu 2
اگر \fBنام\fR شبکه به \fB\&.network\fR ختم شود، Quadlet به دنبال واحد متناظر Quadlet با پسوند \fB\&.network\fR خواهد گشت. در صورت یافتن، Quadlet از نام Network تنظیم‌شده در واحد استفاده می‌کند؛ در غیر این صورت، \fBsystemd-$name\fR استفاده می‌شود.

.PP
سرویس تولیدشده systemd شامل یک وابستگی به واحد سرویس تولیدشده برای آن واحد \fB\&.network\fR خواهد بود. نکته: فایل متناظر \fB\&.network\fR باید وجود داشته باشد.

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

.SS \fBNetworkAlias=\fR
یک نام مستعار در محدوده شبکه برای پاد اضافه می‌کند. این گزینه دارای همان قالبی است که گزینه \fB--network-alias\fR در
دستور \fBpodman pod create\fR\& دارد. از نام‌های مستعار می‌توان برای گروه‌بندی کانتینرها با یکدیگر در تفکیک DNS استفاده کرد: برای
مثال، تنظیم \fBNetworkAlias=web\fR روی چند کانتینر باعث می‌شود که یک پرس‌وجوی DNS برای نام \fBweb\fR به
تمام کانتینرهای دارای آن نام مستعار هدایت شود.

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

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

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

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

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

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

.SS \fBPublishPort=\fR
یک پورت یا محدوده‌ای از پورت‌ها (مانند \fB50-59\fR) را از پاد به میزبان متصل و نمایان می‌سازد. معادل
گزینه \fB--publish\fR در Podman است. قالب آن مشابه گزینه‌های Podman بوده و
به صورت \fBip:hostPort:containerPort\fR، \fBip::containerPort\fR، \fBhostPort:containerPort\fR یا
\fBcontainerPort\fR است که در آن تعداد پورت‌های میزبان و کانتینر باید برابر باشند (در حالت
یک محدوده). پروتکل را می‌توان در انتها قید کرد، مانند \fBhostPort:containerPort/tcp\fR\&.
پروتکل‌های معتبر \fBtcp\fR و \fBudp\fR هستند؛ پروتکل \fBsctp\fR فقط برای کانتینرهای با ریشه (rootful) پشتیبانی می‌شود.

.PP
اگر IP برابر با 0.0.0.0 تنظیم شود یا اصلاً مشخص نشود، پورت به تمام نشانی‌های IPv4 روی
میزبان پیوند می‌خورد؛ برای IPv6 از [::] استفاده کنید.

.PP
توجه داشته باشید که مشخص نکردن پورت میزبان به این معناست که Podman به صورت خودکار یک پورت را انتخاب می‌کند، و این پورت
ممکن است در هر بار فراخوانی سرویس متفاوت باشد. این مسئله باعث می‌شود گزینه کمتر مفیدی باشد. پورت
اختصاص‌یافته را می‌توان با دستور \fBpodman port\fR پیدا کرد.

.PP
هنگام استفاده از شبکه \fBhost\fR از طریق \fBNetwork=host\fR، گزینه \fBPublishPort=\fR قابل استفاده نخواهد بود.

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

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

.PP
نکته: نام نباید شامل پسوند فایل \fB\&.service\fR باشد.

.SS \fBShmSize=\fR
اندازه دایرکتوری /dev/shm.

.PP
این معادل گزینه \fB--shm-size\fR در Podman است و عموماً قالبی به شکل \fBnumber[unit]\fR دارد.

.SS \fBStopTimeout=\fR
مدت زمان به ثانیه برای انتظار جهت توقف تدریجی و تمیز پاد را تعیین می‌کند.
این مقدار معادل آرگومان \fB--time\fR در دستور podman \fBpod stop\fR در هنگام توقف سرویس است.
پس از انقضای این مدت، هرگونه کانتینر در حال اجرا در پاد به صورت اجباری متوقف (kill) می‌شود.

.SS \fBSubGIDMap=\fR
ایجاد پاد در یک فضای نام کاربری جدید با استفاده از نگاشت دارای این نام در فایل /etc/subgid.
معادل گزینه \fB--subgidname\fR در Podman است.

.SS \fBSubUIDMap=\fR
ایجاد پاد در یک فضای نام کاربری جدید با استفاده از نگاشت دارای این نام در فایل /etc/subuid.
معادل گزینه \fB--subuidname\fR در Podman است.

.SS \fBUIDMap=\fR
ایجاد پاد در یک فضای نام کاربری جدید با استفاده از نگاشت UID ارائه‌شده.
معادل گزینه \fB--uidmap\fR در Podman است.

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

.SS \fBUserNS=\fR
حالت فضای نام کاربری را برای پاد تنظیم می‌کند. این معادل گزینه \fB--userns\fR در Podman است و
عموماً قالبی به شکل \fBMODE[:OPTIONS,...]\fR\& دارد.

.SS \fBVolume=\fR
یک حجم را در پاد متصل (mount) می‌کند. این معادل گزینه \fB--volume\fR در Podman است، و
عموماً قالبی به شکل \fB[[SOURCE-VOLUME|HOST-DIR:]CONTAINER-DIR[:OPTIONS]]\fR\& دارد.

.PP
اگر \fBSOURCE-VOLUME\fR با \fB\&.\fR آغاز شود، Quadlet مسیر را به صورت نسبی نسبت به مکان فایل واحد تحلیل می‌کند.

.PP
حالت خاص:
.IP \(bu 2
اگر \fBSOURCE-VOLUME\fR به \fB\&.volume\fR ختم شود، Quadlet به دنبال واحد متناظر Quadlet با پسوند \fB\&.volume\fR خواهد گشت. در صورت یافتن، Quadlet از نام Volume تنظیم‌شده در واحد استفاده می‌کند؛ در غیر این صورت، \fBsystemd-$name\fR استفاده می‌شود. توجه: فایل متناظر \fB\&.volume\fR باید وجود داشته باشد.

.PP
سرویس تولیدشده systemd حاوی وابستگی به واحد سرویس تولیدشده برای آن واحد \fB\&.volume\fR است، یا به \fB$name-volume.service\fR در صورتی که واحد \fB\&.volume\fR یافت نشود.

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

.SH "واحدهای Kube [Kube]"
واحدهای Kube با پسوند \fB\&.kube\fR نام‌گذاری می‌شوند و شامل بخش \fB[Kube]\fR هستند که نحوه اجرای \fBpodman kube play\fR به عنوان یک سرویس را توصیف می‌کند. فایل سرویس حاصل شامل خطی مانند \fBExecStart=podman kube play … file.yml\fR است، و بیشتر کلیدهای این بخش گزینه‌های خط فرمانی ارسال‌شده به Podman را کنترل می‌کنند. با این حال، برخی گزینه‌ها نیز بر جزئیات نحوه راه‌اندازی و تعامل systemd با کانتینر تأثیر می‌گذارند.

.PP
تنها یک کلید الزامی وجود دارد، \fBYaml\fR، که مسیر فایل YAML کوبرنتیز را تعیین می‌کند.

.PP
گزینه‌های معتبر برای \fB[Kube]\fR در زیر فهرست شده‌اند:

.TS
allbox;
l l 
l l .
\fBگزینه‌های [Kube]\fP	\fBمعادل در podman kube play\fP
AutoUpdate=registry	T{
--annotation "io.containers.autoupdate=registry"
T}
ConfigMap=/tmp/config.map	--config-map /tmp/config.map
ContainersConfModule=/etc/nvd\&.conf	--module=/etc/nvd\&.conf
ExitCodePropagation=how	T{
نحوه انتشار وضعیت خطای کانتینر
T}
GlobalArgs=--log-level=debug	--log-level=debug
KubeDownForce=true	--force (برای \fBpodman kube down\fR)
LogDriver=journald	--log-driver journald
Network=host	--network host
PodmanArgs=--annotation=key=value	--annotation=key=value
PublishPort=8080:80	--publish 8080:80
ServiceName=name	نام‌گذاری واحد systemd به \fBname.service\fR
SetWorkingDirectory=yaml	تنظیم \fBWorkingDirectory\fR فایل واحد به مکان فایل YAML
UserNS=keep-id:uid=200,gid=210	T{
--userns keep-id:uid=200,gid=210
T}
Yaml=/tmp/kube.yaml	T{
podman kube play /tmp/kube.yaml
T}
.TE

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

.SS \fBAutoUpdate=\fR
مشخص می‌کند که آیا کانتینرها به‌روزرسانی خودکار خواهند شد یا خیر (podman-auto-update(1)). گزینه AutoUpdate می‌تواند چندین بار مشخص شود. مقادیر زیر پشتیبانی می‌شوند:
.IP \(bu 2
\fBregistry\fR: مستلزم آن است که یک مرجع ایمیج کاملاً واجد شرایط (مانند quay.io/podman/stable:latest) برای ایجاد کانتینر استفاده شود. این الزام برای دانستن اینکه کدام ایمیج‌ها باید واقعاً بررسی و واکشی (pull) شوند ضروری است. اگر از شناسه ایمیج استفاده شده باشد، Podman دیگر نمی‌داند کدام ایمیج را بررسی/واکشی کند.
.IP \(bu 2
\fBlocal\fR: به Podman دستور می‌دهد ایمیجی را که یک کانتینر استفاده می‌کند با ایمیج با نام خام آن در حافظه محلی مقایسه کند. اگر یک ایمیج به صورت محلی به‌روزرسانی شود، Podman به سادگی واحد systemd اجراکننده Quadlet کوبرنتیز را بازراه‌اندازی می‌کند.
.IP \(bu 2
\fBname/(local|registry)\fR: به Podman دستور می‌دهد به‌روزرسانی خودکار \fBlocal\fR یا \fBregistry\fR را روی نام کانتینر مشخص‌شده انجام دهد.

.SS \fBConfigMap=\fR
مسیر YAML کانفیگ‌مپ (ConfigMap) کوبرنتیز را از طریق آرگومان \fB--configmap\fR به \fBpodman kube play\fR ارسال می‌کند. بر خلاف آرگومان \fBconfigmap\fR، مقدار فقط می‌تواند شامل یک مسیر باشد، اما می‌تواند مطلق یا نسبت به مکان فایل واحد باشد.

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

.SS \fBContainersConfModule=\fR
ماژول مشخص‌شده در containers.conf(5) را بارگذاری می‌کند. معادل گزینه \fB--module\fR در Podman است.

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

.SS \fBExitCodePropagation=\fR
کنترل می‌کند که PID اصلی سرویس systemd چگونه باید خارج شود. مقادیر زیر پشتیبانی می‌شوند:
- \fBall\fR: در صورتی که همه کانتینرها شکست خورده باشند (یعنی با کد غیرصفر خارج شده باشند) با کد غیرصفر خارج شود
- \fBany\fR: در صورتی که هر یک از کانتینرها شکست خورده باشند با کد غیرصفر خارج شود
- \fBnone\fR: با کد صفر خارج شود و کانتینرهای ناموفق را نادیده بگیرد

.PP
مقدار پیش‌فرض فعلی \fBnone\fR است.

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

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

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

.SS \fBKubeDownForce=\fR
هنگام فراخوانی \fBpodman kube down\fR تمام منابع، از جمله حجم‌ها را حذف می‌کند. معادل گزینه \fB--force\fR در Podman است.

.SS \fBLogDriver=\fR
درایور لاگ‌گیری (log-driver) را که Podman هنگام اجرای کانتینر استفاده می‌کند تنظیم می‌نماید. معادل گزینه \fB--log-driver\fR در Podman است.

.SS \fBNetwork=\fR
یک شبکه سفارشی برای کانتینر مشخص می‌کند. این گزینه دارای همان قالبی است که گزینه \fB--network\fR در \fBpodman kube play\fR دارد. به عنوان مثال، از \fBhost\fR برای استفاده از شبکه میزبان در کانتینر، یا از \fBnone\fR برای عدم راه‌اندازی شبکه در کانتینر استفاده کنید.

.PP
حالت خاص:
.IP \(bu 2
اگر \fBname\fR شبکه به \fB\&.network\fR ختم شود، یک شبکه Podman به نام \fBsystemd-$name\fR استفاده می‌شود و سرویس تولیدشده systemd حاوی وابستگی به \fB$name-network.service\fR خواهد بود. چنین شبکه‌ای می‌تواند به طور خودکار با استفاده از یک فایل Quadlet با نام \fB$name.network\fR ایجاد شود. توجه: فایل متناظر \fB\&.network\fR باید وجود داشته باشد.

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

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

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

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

.SS \fBPublishPort=\fR
یک درگاه (پورت) یا محدوده‌ای از درگاه‌ها (مانند \fB50-59\fR) را از کانتینر به میزبان در دسترس قرار می‌دهد. معادل گزینه \fB--publish\fR در \fBpodman kube play\fR است. قالب آن شبیه به گزینه‌های Podman است، که به شکل \fBip:hostPort:containerPort\fR، \fBip::containerPort\fR، \fBhostPort:containerPort\fR یا \fBcontainerPort\fR است، که در آن تعداد پورت‌های میزبان و کانتینر باید یکسان باشد (در حالت یک محدوده). پروتکل را می‌توان در انتها ارائه کرد، مانند \fBhostPort:containerPort/tcp\fR\&. پروتکل‌های معتبر \fBtcp\fR و \fBudp\fR هستند؛ پروتکل \fBsctp\fR فقط برای کانتینرهای با دسترسی ریشه (rootful) پشتیبانی می‌شود.

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

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

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

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

.PP
توجه داشته باشید که نام نباید شامل پسوند فایل \fB\&.service\fR باشد.

.SS \fBSetWorkingDirectory=\fR
فیلد \fBWorkingDirectory\fR از گروه \fBService\fR فایل واحد سرویس Systemd را تنظیم می‌کند. برای این استفاده می‌شود که به \fBpodman kube play\fR اجازه دهد مسیرهای نسبی را به درستی حل (resolve) کند. مقادیر پشتیبانی‌شده \fByaml\fR و \fBunit\fR هستند تا دایرکتوری کاری را به ترتیب به دایرکتوری فایل YAML یا فایل واحد Quadlet تنظیم کنند.

.PP
همچنین، کاربران می‌توانند به صراحت فیلد \fBWorkingDirectory\fR از گروه \fBService\fR را در فایل \fB\&.kube\fR تنظیم کنند. لطفاً توجه داشته باشید که اگر فیلد \fBWorkingDirectory\fR از گروه \fBService\fR تنظیم شده باشد، حتی اگر \fBSetWorkingDirectory\fR نیز تنظیم شده باشد، Quadlet آن را تنظیم نخواهد کرد.

.PP
حالت خاص:
* اگر چندین مسیر \fBYaml\fR ارائه شده باشد، فقط \fBunit\fR پشتیبانی می‌شود.

.SS \fBUserNS=\fR
حالت فضای نام کاربر (user namespace) را برای کانتینر تنظیم می‌کند. این معادل گزینه \fB--userns\fR در Podman است و عموماً به شکل \fBMODE[:OPTIONS,...]\fR است.

.SS \fBYaml=\fR
مسیر، مطلق یا نسبی نسبت به مکان فایل واحد، به فایل YAML کوبرنتیز که باید استفاده شود.

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

.SH "واحدهای شبکه [Network]"
فایل‌های شبکه با پسوند \fB\&.network\fR نام‌گذاری می‌شوند و شامل بخش \fB[Network]\fR هستند که شبکه نام‌گذاری‌شده Podman را توصیف می‌کند. سرویس تولیدشده یک دستور یک‌باره است که اطمینان حاصل می‌کند شبکه روی میزبان وجود دارد و در صورت نیاز آن را ایجاد می‌کند.

.PP
به‌طور پیش‌فرض، شبکه Podman همان نام واحد را دارد، اما با پیشوند \fBsystemd-\fR؛ یعنی برای یک فایل شبکه به نام \fB$NAME.network\fR، شبکه Podman تولیدشده \fBsystemd-$NAME\fR نامیده می‌شود و فایل سرویس تولیدشده \fB$NAME-network.service\fR است. گزینه \fBNetworkName\fR امکان بازنویسی این نام پیش‌فرض را با یک نام ارائه‌شده توسط کاربر فراهم می‌سازد.

.PP
به منظور به‌روزرسانی پارامترهای شبکه، ابتدا باید شبکه podman را به صورت دستی حذف کرده و سپس سرویس را بازراه‌اندازی کنید. گزینه \fBNetworkDeleteOnStop=true\fR را تنظیم کنید تا این رفتار را بازنویسی کرده و هنگام متوقف شدن دستگاه، شبکه حذف شود.

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

.PP
گزینه‌های معتبر برای \fB[Network]\fR در زیر فهرست شده‌اند:

.TS
allbox;
l l 
l l .
\fBگزینه‌های [Network]\fP	\fBمعادل در podman network create\fP
ContainersConfModule=/etc/nvd\&.conf	--module=/etc/nvd\&.conf
DisableDNS=true	--disable-dns
DNS=192.168.55.1	--dns=192.168.55.1
Driver=bridge	--driver bridge
Gateway=192.168.55.3	--gateway 192.168.55.3
GlobalArgs=--log-level=debug	--log-level=debug
InterfaceName=enp1	--interface-name enp1
Internal=true	--internal
IPAMDriver=dhcp	--ipam-driver dhcp
IPRange=192.168.55.128/25	--ip-range 192.168.55.128/25
IPv6=true	--ipv6
Label="XYZ"	--label "XYZ"
NetworkDeleteOnStop=true	T{
افزودن ExecStopPost برای حذف شبکه هنگام توقف واحد
T}
NetworkName=foo	podman network create foo
Options=isolate=true	--opt isolate=true
PodmanArgs=--dns=192.168.55.1	--dns=192.168.55.1
ServiceName=name	نام‌گذاری واحد systemd به \fBname.service\fR
Subnet=192.5.0.0/16	--subnet 192.5.0.0/16
.TE

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

.SS \fBContainersConfModule=\fR
ماژول مشخص‌شده در containers.conf(5) را بارگذاری می‌کند. معادل گزینه \fB--module\fR در Podman است.

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

.SS \fBDisableDNS=\fR (پیش‌فرض: \fBfalse\fR)
در صورت فعال بودن، افزونه DNS را برای این شبکه غیرفعال می‌کند.

.PP
این معادل گزینه \fB--disable-dns\fR در Podman است.

.SS \fBDNS=\fR
تحلیل‌کننده DNS/نیم‌سرور در سطح شبکه را برای کانتینرهای این شبکه تنظیم می‌کند.

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

.SS \fBDriver=\fR (پیش‌فرض: \fBbridge\fR)
درایور برای مدیریت شبکه. در حال حاضر \fBbridge\fR، \fBmacvlan\fR و \fBipvlan\fR پشتیبانی می‌شوند.

.PP
این معادل گزینه \fB--driver\fR در Podman است.

.SS \fBGateway=\fR
یک گیت‌وی (دروازه) برای زیرشبکه (subnet) تعریف می‌کند. اگر می‌خواهید آدرس درگاه را ارائه دهید، باید گزینه subnet را نیز ارائه کنید.

.PP
این معادل گزینه \fB--gateway\fR در Podman است.

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

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

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

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

.SS \fBInterfaceName=\fR
این گزینه با گزینه \fInetwork_interface\fP در پیکربندی شبکه تطابق دارد، \fBpodman network inspect\fP را ببینید. بسته به درایور، این می‌تواند اثرات متفاوتی داشته باشد؛ برای \fBbridge\fR، از نام رابط پل (bridge) استفاده می‌کند. برای \fBmacvlan\fR و \fBipvlan\fR، دستگاه والد روی میزبان است. این معادل \fB--opt parent=...\fR است.

.PP
این معادل گزینه \fB--interface-name\fR در Podman است.

.SS \fBInternal=\fR (پیش‌فرض: \fBfalse\fR)
دسترسی خارجی این شبکه را محدود می‌کند.

.PP
این معادل گزینه \fB--internal\fR در Podman است.

.SS \fBIPAMDriver=\fR
درایور IPAM (درایور مدیریت آدرس IP) را برای شبکه تنظیم می‌کند. در حال حاضر \fBhost-local\fR، \fBdhcp\fR و \fBnone\fR پشتیبانی می‌شوند.

.PP
این معادل گزینه \fB--ipam-driver\fR در Podman است.

.SS \fBIPRange=\fR
نشانی IP کانتینر را از یک محدوده تخصیص می‌دهد. این محدوده یا باید یک زیرشبکه کامل در قالب CIDR باشد یا در نحو \fB<startIP>-<endIP>\fR باشد که در مقایسه با زیرشبکه CIDR دامنه انعطاف‌پذیرتری را فراهم می‌کند. گزینه ip-range باید همراه با یک گزینه subnet استفاده شود.

.PP
این معادل گزینه \fB--ip-range\fR در Podman است.

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

.SS \fBIPv6=\fR
شبکه‌سازی IPv6 (پشته دوگانه یا Dual Stack) را فعال می‌کند.

.PP
این معادل گزینه \fB--ipv6\fR در Podman است.

.SS \fBLabel=\fR
یک یا چند برچسب OCI را روی شبکه تنظیم می‌کند. قالب آن فهرستی از موارد \fBkey=value\fR، مشابه با \fBEnvironment\fR است.

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

.SS \fBNetworkDeleteOnStop=\fR (پیش‌فرض: \fBfalse\fR)
هنگامی که روی \fBtrue\fR تنظیم شود، با متوقف شدن سرویس، شبکه حذف می‌شود.

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

.SS \fBOptions=\fR
گزینه‌های مخصوص درایور را تنظیم می‌کند.

.PP
این معادل گزینه \fB--opt\fR در Podman است.

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

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

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

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

.PP
توجه داشته باشید که نام نباید شامل پسوند فایل \fB\&.service\fR باشد.

.SS \fBSubnet=\fR
زیرشبکه در نمادگذاری CIDR.

.PP
این معادل گزینه \fB--subnet\fR در Podman است.

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

.SH "واحدهای حجم [Volume]"
فایل‌های حجم (Volume) با پسوند \fB\&.volume\fR نام‌گذاری می‌شوند و شامل بخش \fB[Volume]\fR هستند که حجم نام‌گذاری‌شده Podman را توصیف می‌کند. سرویس تولیدشده یک دستور یک‌باره است که اطمینان حاصل می‌کند حجم روی میزبان وجود دارد و در صورت نیاز آن را ایجاد می‌کند.

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

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

.PP
گزینه‌های معتبر برای \fB[Volume]\fR در زیر فهرست شده‌اند:

.TS
allbox;
l l 
l l .
\fBگزینه‌های [Volume]\fP	\fBمعادل در podman volume create\fP
ContainersConfModule=/etc/nvd\&.conf	--module=/etc/nvd\&.conf
Copy=true	--opt copy
Device=tmpfs	--opt device=tmpfs
Driver=image	--driver=image
GID=5678	--gid 5678
GlobalArgs=--log-level=debug	--log-level=debug
Group=192	--opt "o=group=192"
Image=quay.io/centos/centos:latest	T{
--opt image=quay.io/centos/centos:latest
T}
Label="foo=bar"	--label "foo=bar"
Options=XYZ	--opt "o=XYZ"
PodmanArgs=--driver=image	--driver=image
ServiceName=name	نام‌گذاری واحد systemd به \fBname.service\fR
Type=type	نوع سیستم‌فایل Device
UID=1234	--uid 1234
User=123	--opt "o=uid=123"
VolumeName=foo	podman volume create foo
.TE

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

.SS \fBContainersConfModule=\fR
ماژول مشخص‌شده در containers.conf(5) را بارگذاری می‌کند. معادل گزینه \fB--module\fR در Podman است.

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

.SS \fBCopy=\fR (پیش‌فرض: \fBtrue\fR)
در صورت فعال بودن، محتوای ایمیج واقع در نقطه اتصال (mountpoint) حجم در اولین اجرا در داخل حجم کپی می‌شود.

.SS \fBDevice=\fR
مسیر دستگاهی که برای حجم متصل (mount) می‌شود.

.SS \fBDriver=\fR
نام درایور حجم را مشخص می‌کند. هنگامی که روی \fBimage\fR تنظیم شود، کلید \fBImage\fR نیز باید تنظیم شده باشد.

.PP
این معادل گزینه \fB--driver\fR در Podman است.

.SS \fBGID=\fR
شناسه گروهی (GID) که حجم با آن ایجاد می‌شود. بر خلاف \fBGroup=\fR، مقدار مشخص‌شده به عملیات mount ارسال نمی‌شود. مقدار GID مشخص‌شده، مالک دایرکتوری نقطه اتصال حجم خواهد بود و بر عملیات chown حجم تأثیر می‌گذارد.

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

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

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

.SS \fBGroup=\fR
شناسه گروهی (عددی) میزبان، یا نام گروهی که باید به عنوان گروه برای حجم استفاده شود. بر خلاف \fBGID\fR، مقدار مشخص‌شده به عملیات mount ارسال می‌شود.

.SS \fBImage=\fR
ایمیجی را که حجم بر اساس آن ساخته می‌شود، زمانی که \fBDriver\fR روی \fBimage\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 باید وجود داشته باشد.

.SS \fBLabel=\fR
یک یا چند برچسب OCI را روی حجم تنظیم می‌کند. قالب آن فهرستی از موارد \fBkey=value\fR، مشابه با \fBEnvironment\fR است.

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

.SS \fBOptions=\fR
گزینه‌های اتصالی (mount options) که برای یک سیستم‌فایل استفاده می‌شوند، همانند آنچه در گزینه \fB-o\fR دستور \fBmount(8)\fP استفاده می‌شود.

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

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

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

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

.PP
توجه داشته باشید که نام نباید شامل پسوند فایل \fB\&.service\fR باشد.

.SS \fBType=\fR
نوع سیستم‌فایل \fBDevice\fR، همان‌گونه که در گزینه \fB-t\fR دستورات \fBmount(8)\fP استفاده می‌شود.

.SS \fBUID=\fR
شناسه کاربری (UID) که حجم با آن ایجاد می‌شود. بر خلاف \fBUser\fR، مقدار مشخص‌شده به عملیات mount ارسال نمی‌شود. مقدار UID مشخص‌شده، مالک دایرکتوری نقطه اتصال حجم خواهد بود و بر عملیات chown حجم تأثیر می‌گذارد.

.SS \fBUser=\fR
شناسه کاربری (عددی) میزبان، یا نام کاربری که باید به عنوان مالک حجم استفاده شود. بر خلاف \fBUID\fR، مقدار مشخص‌شده به عملیات mount ارسال می‌شود.

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

.SH "واحدهای ساخت [Build]"
فایل‌های ساخت با پسوند \fB\&.build\fR نام‌گذاری می‌شوند و شامل بخش \fB[Build]\fR هستند که دستور ساخت ایمیج را توصیف می‌کند. سرویس تولیدشده یک دستور یک‌باره است که اطمینان حاصل می‌کند ایمیج بر روی میزبان از یک Containerfile و دایرکتوری زمینه (context) ارائه‌شده ساخته می‌شود. شروع‌های (یا راه‌اندازی‌های مجدد) بعدی سرویس ساخته‌شده تولیدی معمولاً به سرعت به پایان می‌رسند، زیرا حافظه پنهان لایه‌های ایمیج مراحل بدون تغییر ساخت را نادیده می‌گیرد.

.PP
یک واحد \fB\&.build\fR کمینه حداقل به کلید \fBImageTag=\fR، و یکی از کلیدهای \fBFile=\fR یا \fBSetWorkingDirectory=\fR نیاز دارد.

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

.PP
گزینه‌های معتبر برای \fB[Build]\fR در زیر فهرست شده‌اند:

.TS
allbox;
l l 
l l .
\fBگزینه‌های [Build]\fP	\fBمعادل در podman build\fP
Annotation=annotation=value	--annotation=annotation=value
Arch=aarch64	--arch=aarch64
AuthFile=/etc/registry/auth\&.json	--authfile=/etc/registry/auth\&.json
BuildArg=foo=bar	--build-arg foo=bar
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
Environment=foo=bar	--env foo=bar
File=/path/to/Containerfile	--file=/path/to/Containerfile
ForceRM=false	--force-rm=false
GlobalArgs=--log-level=debug	--log-level=debug
GroupAdd=keep-groups	--group-add=keep-groups
IgnoreFile=/path/to/\&.customignore	--ignorefile=/path/to/\&.customignore
ImageTag=localhost/imagename	--tag=localhost/imagename
Label=label	--label=label
Network=host	--network=host
PodmanArgs=--pull never	--pull never
Pull=never	--pull never
Retry=5	--retry=5
RetryDelay=10s	--retry-delay=10s
Secret=secret	--secret=id=mysecret,src=path
ServiceName=name	نام‌گذاری واحد systemd به \fBname.service\fR
SetWorkingDirectory=unit	تنظیم \fBWorkingDirectory\fR فایل واحد systemd
Target=my-app	--target=my-app
TLSVerify=false	--tls-verify=false
Variant=arm/v7	--variant=arm/v7
Volume=/source:/dest	--volume /source:/dest
.TE

.SS \fBAnnotation=\fR
یک پی‌نوشت یا حاشیه‌نویسی (\fIannotation\fP) ایمیج (مانند annotation=\fIvalue\fP) را به متادیتای ایمیج اضافه می‌کند. می‌تواند چندین بار استفاده شود.

.PP
این معادل گزینه \fB--annotation\fR در \fBpodman build\fR است.

.SS \fBArch=\fR
معماری ایمیجی را که باید ساخته شود بازنویسی می‌کند (پیش‌فرض معماری میزبان است).

.PP
این معادل گزینه \fB--arch\fR در \fBpodman build\fR است.

.SS \fBAuthFile=\fR
مسیر فایل احراز هویت.

.PP
این معادل گزینه \fB--authfile\fR در \fBpodman build\fR است.

.SS \fBBuildArg=\fR
یک آرگومان ساخت و مقدار آن را به همان روش متغیرهای محیطی مشخص می‌کند (مانند env=\fIvalue\fP)، اما به فهرست متغیرهای محیطی در پیکربندی ایمیج حاصل اضافه نمی‌شود. می‌تواند چندین بار درج شود.

.PP
این معادل گزینه \fB--build-arg\fR در \fBpodman build\fR است.

.SS \fBContainersConfModule=\fR
ماژول مشخص‌شده در containers.conf(5) را بارگذاری می‌کند. معادل گزینه \fB--module\fR در Podman است.

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

.SS \fBDNS=\fR
تحلیل‌کننده DNS/نیم‌سرور در سطح شبکه را برای کانتینر ساخت تنظیم می‌کند.

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

.PP
این معادل گزینه \fB--dns\fR در \fBpodman build\fR است.

.SS \fBDNSOption=\fR
گزینه‌های سفارشی DNS را تنظیم می‌کند.

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

.PP
این معادل گزینه \fB--dns-option\fR در \fBpodman build\fR است.

.SS \fBDNSSearch=\fR
دامنه‌های سفارشی جستجوی DNS را تنظیم می‌کند. برای حذف دامنه جستجو از \fBDNSSearch=.\fP استفاده کنید.

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

.PP
این معادل گزینه \fB--dns-search\fR در \fBpodman build\fR است.

.SS \fBEnvironment=\fR
یک مقدار (مانند env=\fIvalue\fP) را به ایمیج ساخته‌شده اضافه می‌کند. این گزینه از همان قالب سرویس‌ها در systemd
\[la]https://www.freedesktop.org/software/systemd/man/systemd.exec.html#Environment=\[ra]
استفاده می‌کند و می‌تواند چندین بار درج شود.

.SS \fBFile=\fR
یک Containerfile را مشخص می‌کند که شامل دستورالعمل‌های ساخت ایمیج است. نشانی اینترنتی (URL) که با \fBhttp(s)://\fR آغاز شود به شما امکان می‌دهد یک Containerfile راه دور را برای دانلود مشخص کنید. توجه داشته باشید که برای یک مسیر نسبی معین به Containerfile، یا هنگام استفاده از URL با \fBhttp(s)://\fR، باید \fBSetWorkingDirectory=\fR را نیز تنظیم کنید تا \fBpodman build\fR بتواند یک دایرکتوری زمینه (context) معتبر برای منابع مشخص‌شده در Containerfile پیدا کند.

.PP
توجه داشته باشید که تنظیم فیلد \fBFile=\fR برای فایل \fB\&.build\fR الزامی است، مگر اینکه \fBSetWorkingDirectory\fR (یا \fBWorkingDirectory\fR در گروه \fBService\fR) نیز تنظیم شده باشد.

.PP
این معادل گزینه \fB--file\fR در \fBpodman build\fR است.

.SS \fBForceRM=\fR
همیشه پس از اتمام ساخت، حتی در صورت شکست ساخت، کانتینرهای میانی را حذف می‌کند (پیش‌فرض true است).

.PP
این معادل گزینه \fB--force-rm\fR در \fBpodman build\fR است.

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

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

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

.SS \fBGroupAdd=\fR
گروه‌های اضافی را به کاربر اصلی در حال اجرا درون فرآیند کانتینر اختصاص می‌دهد. همچنین از پرچم ویژه \fBkeep-groups\fR پشتیبانی می‌کند.

.PP
این معادل گزینه \fB--group-add\fR در \fBpodman build\fR است.

.SS \fBIgnoreFile=\fR
مسیر به یک فایل جایگزین .containerignore برای استفاده هنگام ساخت ایمیج. توجه داشته باشید که هنگام استفاده از یک مسیر نسبی، باید \fBSetWorkingDirectory=\fR را نیز تنظیم کنید.

.PP
این معادل گزینه \fB--ignorefile\fR در \fBpodman build\fR است.

.SS \fBImageTag=\fR
نامی را مشخص می‌کند که در صورت تکمیل موفقیت‌آمیز فرآیند ساخت به ایمیج حاصل اختصاص می‌یابد.

.PP
این معادل گزینه \fB--tag\fR در \fBpodman build\fR است.

.PP
این کلید می‌تواند چندین بار درج شود. اولین مورد به عنوان نام آرتیفکت ایجادشده در زمانی که فایل \fB\&.build\fR توسط یک واحد Quadlet دیگر ارجاع داده می‌شود، استفاده خواهد شد.
.SS \fBLabel=\fR
افزودن یک برچسب ایمیج (\fIlabel\fP، مانند label=\fIvalue\fP) به متادیتای ایمیج. این کلید می‌تواند چندین بار استفاده شود.

.PP
این معادل گزینه \fB--label\fR در \fBpodman build\fR است.

.SS \fBNetwork=\fR
پیکربندی فضاهای نام شبکه (network namespaces) را هنگام پردازش دستورالعمل‌های RUN تنظیم می‌کند. این کلید همان قالب گزینه \fB--network\fR در \fBpodman build\fR را دارد. برای مثال، برای استفاده از شبکه میزبان از \fBhost\fR، یا برای عدم راه‌اندازی شبکه از \fBnone\fR استفاده کنید.

.PP
حالت ویژه:
.IP \(bu 2
اگر \fBنام\fR شبکه به \fB\&.network\fR ختم شود، Quadlet به دنبال واحد Quadlet مربوطه با پسوند \fB\&.network\fR خواهد گشت. در صورت یافتن، Quadlet از نام شبکه تنظیم‌شده در Unit استفاده می‌کند، در غیر این صورت از \fBsystemd-$name\fR استفاده می‌شود. سرویس systemd تولیدشده شامل یک وابستگی به واحد سرویس تولیدشده برای آن واحد \fB\&.network\fR، یا در صورت پیدا نشدن واحد \fB\&.network\fR به \fB$name-network.service\fR خواهد بود. نکته: فایل \fB\&.network\fR متناظر باید وجود داشته باشد.

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

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

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

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

.SS \fBPull=\fR
سیاست دریافت (pull) ایمیج را تنظیم می‌کند.

.PP
این معادل گزینه \fB--pull\fR در \fBpodman build\fR است.

.SS \fBRetry=\fR
تعداد دفعات تلاش مجدد برای دریافت ایمیج هنگام بروز خطای HTTP. معادل گزینه \fB--retry\fR در پادمن است.

.SS \fBRetryDelay=\fR
مدت زمان تاخیر بین تلاش‌های مجدد. معادل گزینه \fB--retry-delay\fR در پادمن است.

.SS \fBSecret=\fR
ارسال اطلاعات حساس و محرمانه (secret) مورد استفاده در مراحل ساخت Containerfile به شیوه‌ای امن.

.PP
این معادل گزینه \fB--secret\fR در \fBpodman build\fR است و به‌طور کلی قالبی به صورت \fBsecret[,opt=opt ...]\fR دارد.

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

.PP
توجه داشته باشید که نام نباید شامل پسوند فایل \fB\&.service\fR باشد.

.SS \fBSetWorkingDirectory=\fR
فراهم کردن کانتکست (یک دایرکتوری کاری) برای \fBpodman build\fR\&. مقادیر پشتیبانی‌شده عبارتند از یک مسیر، یک URL، یا کلیدهای ویژه \fBfile\fR یا \fBunit\fR برای تنظیم دایرکتوری کانتکست به ترتیب روی دایرکتوری والد فایل مشخص‌شده در کلید \fBFile=\fR یا دایرکتوری فایل واحد \fB\&.build\fR کوادلت. این قابلیت به Quadlet امکان می‌دهد مسیرهای نسبی را حل‌وفصل کند.

.PP
هنگام استفاده از یکی از کلیدهای ویژه (\fBfile\fR یا \fBunit\fR)، فیلد \fBWorkingDirectory\fR از گروه \fBService\fR واحد سرویس systemd نیز متناسب با آن تنظیم خواهد شد. همچنین، کاربران می‌توانند فیلد \fBWorkingDirectory\fR از گروه \fBService\fR را صراحتاً در فایل \fB\&.build\fR تنظیم کنند. لطفاً توجه داشته باشید که اگر فیلد \fBWorkingDirectory\fR گروه \fBService\fR توسط کاربر تنظیم شده باشد، Quadlet آن را حتی در صورت تنظیم \fBSetWorkingDirectory\fR روی \fBfile\fR یا \fBunit\fR بازنویسی نخواهد کرد.

.PP
با ارائه یک نشانی اینترنتی (URL) به \fBSetWorkingDirectory=\fR می‌توانید به \fBpodman build\fR دستور دهید یک مخزن گیت را کلون کند یا فایل فشرده‌ای (آرشیو) را دانلود کرده و به عنوان کانتکست ساخت در یک مکان موقت استخراج کند. توجه داشته باشید که در این حالت، فیلد \fBWorkingDirectory\fR واحد سرویس systemd توسط Quadlet دست‌نخورده باقی می‌ماند.

.PP
توجه داشته باشید که فراهم کردن دایرکتوری کانتکست برای فایل \fB\&.build\fR الزامی است، مگر اینکه کلید \fBFile=\fR نیز ارائه شده باشد.

.SS \fBTarget=\fR
مرحله ساخت هدف (target build stage) را برای ساخت مشخص می‌کند. دستورات موجود در Containerfile پس از مرحله هدف نادیده گرفته می‌شوند.

.PP
این معادل گزینه \fB--target\fR در \fBpodman build\fR است.

.SS \fBTLSVerify=\fR
الزام استفاده از HTTPS و اعتبارسنجی گواهی‌ها هنگام تماس با رجیستری‌ها.

.PP
این معادل گزینه \fB--tls-verify\fR در \fBpodman build\fR است.

.SS \fBVariant=\fR
گونه‌ی معماری پیش‌فرض ایمیج کانتینر در حال ساخت را بازنویسی می‌کند.

.PP
این معادل گزینه \fB--variant\fR در \fBpodman build\fR است.

.SS \fBVolume=\fR
سوار کردن (mount) یک حجم روی کانتینرها هنگام اجرای دستورالعمل‌های RUN در حین ساخت. این معادل گزینه \fB--volume\fR در \fBpodman build\fR است و عموماً قالبی به صورت \fB[[SOURCE-VOLUME|HOST-DIR:]CONTAINER-DIR[:OPTIONS]]\fR دارد.

.PP
اگر \fBSOURCE-VOLUME\fR با \fB\&.\fR شروع شود، Quadlet مسیر را به صورت نسبی نسبت به محل فایل واحد حل‌وفصل می‌کند.

.PP
حالت ویژه:
.IP \(bu 2
اگر \fBSOURCE-VOLUME\fR به \fB\&.volume\fR ختم شود، Quadlet به دنبال واحد Quadlet متناظر با پسوند \fB\&.volume\fR خواهد گشت. در صورت یافتن، Quadlet از نام Volume تنظیم‌شده در Unit استفاده می‌کند، در غیر این صورت از \fBsystemd-$name\fR استفاده می‌شود. سرویس systemd تولیدشده شامل یک وابستگی به واحد سرویس ایجادشده برای آن واحد \fB\&.volume\fR، یا در صورت پیدا نشدن واحد \fB\&.volume\fR به \fB$name-volume.service\fR خواهد بود. نکته: فایل \fB\&.volume\fR متناظر باید وجود داشته باشد.

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

.SH Image units [Image]
فایل‌های ایمیج با پسوند \fB\&.image\fR نام‌گذاری می‌شوند و شامل بخش \fB[Image]\fR هستند که دستور دریافت (pull) ایمیج کانتینر را توصیف می‌کند. سرویس ایجادشده یک دستور یک‌باره است که از وجود ایمیج روی میزبان اطمینان حاصل کرده و در صورت نیاز آن را دریافت می‌کند.

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

.PP
گزینه‌های معتبر برای \fB[Image]\fR در زیر فهرست شده‌اند:

.TS
allbox;
l l 
l l .
\fBگزینه‌های [Image]\fP	\fBمعادل در podman image pull\fP
AllTags=true	--all-tags
Arch=aarch64	--arch=aarch64
AuthFile=/etc/registry/auth\&.json	--authfile=/etc/registry/auth\&.json
CertDir=/etc/registry/certs	--cert-dir=/etc/registry/certs
ContainersConfModule=/etc/nvd\&.conf	--module=/etc/nvd\&.conf
Creds=myname:mypassword	--creds=myname:mypassword
DecryptionKey=/etc/registry\&.key	--decryption-key=/etc/registry\&.key
GlobalArgs=--log-level=debug	--log-level=debug
Image=quay\&.io/centos/centos:latest	T{
podman image pull quay.io/centos/centos:latest
T}
ImageTag=quay\&.io/centos/centos:latest	از این نام هنگام حل ارجاعات \fB\&.image\fR استفاده می‌شود
OS=windows	--os=windows
PodmanArgs=--os=linux	--os=linux
Policy=always	--policy=always
Retry=5	--retry=5
RetryDelay=10s	--retry-delay=10s
ServiceName=name	نام‌گذاری واحد systemd به صورت \fBname.service\fR
TLSVerify=false	--tls-verify=false
Variant=arm/v7	--variant=arm/v7
.TE

.SS \fBAllTags=\fR
تمام ایمیج‌های دارای تگ در مخزن دریافت می‌شوند.

.PP
این معادل گزینه \fB--all-tags\fR در پادمن است.

.SS \fBArch=\fR
معماری ایمیج دریافتی را بازنویسی می‌کند (پیش‌فرض معماری میزبان است).

.PP
این معادل گزینه \fB--arch\fR در پادمن است.

.SS \fBAuthFile=\fR
مسیر فایل احراز هویت.

.PP
این معادل گزینه \fB--authfile\fR در پادمن است.

.SS \fBCertDir=\fR
استفاده از گواهی‌های موجود در مسیر (*.crt، *.cert، *.key) برای اتصال به رجیستری.

.PP
این معادل گزینه \fB--cert-dir\fR در پادمن است.

.SS \fBContainersConfModule=\fR
ماژول مشخص‌شده containers.conf(5) را بارگذاری می‌کند. معادل گزینه \fB--module\fR در پادمن است.

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

.SS \fBCreds=\fR
اطلاعات احراز هویت \fB[username[:password]]\fR برای استفاده جهت احراز هویت با رجیستری در صورت نیاز.

.PP
این معادل گزینه \fB--creds\fR در پادمن است.

.SS \fBDecryptionKey=\fR
کلید یا عبارت عبور \fB[key[:passphrase]]\fR مورد استفاده برای رمزگشایی ایمیج‌ها.

.PP
این معادل گزینه \fB--decryption-key\fR در پادمن است.

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

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

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

.SS \fBImage=\fR
ایمیجی که باید دریافت شود.
توصیه می‌شود به دلایل کارایی و پایداری، به جای نام کوتاه از نام کامل و واجد شرایط ایمیج (fully qualified image name) استفاده شود.

.PP
قالب نام همانند زمانی است که به دستور \fBpodman pull\fR داده می‌شود؛ بنابراین از استفاده از \fB:tag\fR یا چکیده‌ها (digests) برای تضمین نسخه مشخصی از ایمیج پشتیبانی می‌کند.

.SS \fBImageTag=\fR
نام کامل و معتبر واقعی ایمیج (FQIN) ارجاع داده شده در \fBImage\fR\&.
تنها زمانی معنادار است که منبع یک فایل یا آرشیو دایرکتوری باشد.

.PP
برای مثال، ایمیجی که با دستور پادمن زیر در یک \fBdocker-archive\fR ذخیره شده است:

.PP
\fBpodman image save --format docker-archive --output /tmp/archive-file.tar quay.io/podman/stable:latest\fR

.PP
نیازمند تنظیم موارد زیر است:
- \fBImage=docker-archive:/tmp/archive-file.tar\fR
- \fBImageTag=quay.io/podman/stable:latest\fR

.SS \fBOS=\fR
سیستم‌عامل ایمیج دریافتی را بازنویسی می‌کند (پیش‌فرض سیستم‌عامل میزبان است).

.PP
این معادل گزینه \fB--os\fR در پادمن است.

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

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

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

.SS \fBPolicy=\fR
سیاست دریافتی که باید هنگام pull کردن ایمیج استفاده شود.

.PP
این معادل گزینه \fB--policy\fR در پادمن است.

.SS \fBRetry=\fR
تعداد دفعات تلاش مجدد برای دریافت ایمیج هنگام بروز خطای HTTP. معادل گزینه \fB--retry\fR در پادمن است.

.SS \fBRetryDelay=\fR
مدت زمان تاخیر بین تلاش‌های مجدد. معادل گزینه \fB--retry-delay\fR در پادمن است.

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

.PP
توجه داشته باشید که نام نباید شامل پسوند فایل \fB\&.service\fR باشد.

.SS \fBTLSVerify=\fR
الزام استفاده از HTTPS و اعتبارسنجی گواهی‌ها هنگام تماس با رجیستری‌ها.

.PP
این معادل گزینه \fB--tls-verify\fR در پادمن است.

.SS \fBVariant=\fR
گونه‌ی معماری پیش‌فرض ایمیج کانتینر را بازنویسی می‌کند.

.PP
این معادل گزینه \fB--variant\fR در پادمن است.

.SH Artifact units [Artifact]
.SS هشدار: واحد آزمایشی (Experimental Unit)
این واحد آزمایشی در نظر گرفته شده و همچنان در حال توسعه است. ورودی‌ها، گزینه‌ها و خروجی‌ها همگی ممکن است تغییر کنند.

.PP
واحدهای آرتیفکت با پسوند \fB\&.artifact\fR نام‌گذاری می‌شوند و شامل بخش \fB[Artifact]\fR هستند که دستور دریافت آرتیفکت کانتینر را توصیف می‌کند. سرویس ایجادشده یک دستور یک‌باره است که از وجود آرتیفکت روی میزبان اطمینان حاصل کرده و در صورت نیاز آن را دریافت می‌کند.

.PP
استفاده از واحدهای آرتیفکت به کانتینرها اجازه می‌دهد به آرتیفکت‌هایی که به‌طور خودکار دریافت شده‌اند وابسته باشند. این قابلیت به‌ویژه برای مدیریت آرتیفکت‌هایی که کانتینرها باید آن‌ها را سوار (mount) کرده یا به آن‌ها دسترسی داشته باشند مفید است؛ کلید \fBArtifact\fP درون واحد [Artifact] اجباری است.

.PP
گزینه‌های معتبر برای \fB[Artifact]\fR در زیر فهرست شده‌اند:

.TS
allbox;
l l 
l l .
\fBگزینه‌های [Artifact]\fP	\fBمعادل در podman artifact pull\fP
Artifact=quay\&.io/foobar/artifact:special	podman artifact pull quay\&.io/foobar/artifact:special
AuthFile=/etc/registry/auth\&.json	--authfile=/etc/registry/auth\&.json
CertDir=/etc/registry/certs	--cert-dir=/etc/registry/certs
ContainersConfModule=/etc/nvd\&.conf	--module=/etc/nvd\&.conf
Creds=username:password	--creds=username:password
DecryptionKey=/etc/registry\&.key	--decryption-key=/etc/registry\&.key
GlobalArgs=--log-level=debug	--log-level=debug
PodmanArgs=--pull never	--pull never
Quiet=true	--quiet
Retry=5	--retry=5
RetryDelay=10s	--retry-delay=10s
ServiceName=my-artifact	T{
تنظیم نام سرویس systemd به my-artifact.service
T}
TLSVerify=false	--tls-verify=false
.TE

.SS \fBArtifact=\fR
آرتیفکتی که باید از یک رجیستری بر روی دستگاه محلی دریافت شود. این تنها کلید الزامی برای واحدهای آرتیفکت است.

.PP
به دلایل کارایی و استحکام، استفاده از نام کامل و واجد شرایط آرتیفکت به‌جای نام کوتاه الزامی است.

.SS \fBAuthFile=\fR
مسیر فایل احراز هویت.

.PP
این معادل گزینه \fB--authfile\fR در پادمن است.

.SS \fBCertDir=\fR
استفاده از گواهی‌های موجود در مسیر (*.crt، *.cert، *.key) برای اتصال به رجیستری.

.PP
این معادل گزینه \fB--cert-dir\fR در پادمن است.

.SS \fBContainersConfModule=\fR
بارگذاری ماژول مشخص‌شده containers.conf(5). معادل گزینه \fB--module\fR در پادمن است.

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

.SS \fBCreds=\fR
اطلاعات احراز هویت برای استفاده هنگام تماس با رجیستری در قالب \fB[username[:password]]\fR\&.

.PP
این معادل گزینه \fB--creds\fR در پادمن است.

.SS \fBDecryptionKey=\fR
کلید یا عبارت عبور \fB[key[:passphrase]]\fR مورد استفاده برای رمزگشایی آرتیفکت‌ها.

.PP
این معادل گزینه \fB--decryption-key\fR در پادمن است.

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

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

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

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

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

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

.SS \fBQuiet=\fR
نادیده گرفتن و سرکوب اطلاعات خروجی هنگام دریافت آرتیفکت‌ها.

.PP
این معادل گزینه \fB--quiet\fR در پادمن است.

.SS \fBRetry=\fR
تعداد دفعات تلاش مجدد برای دریافت آرتیفکت هنگام بروز خطای HTTP. معادل گزینه \fB--retry\fR در پادمن است.

.SS \fBRetryDelay=\fR
مدت زمان تاخیر بین تلاش‌های مجدد. معادل گزینه \fB--retry-delay\fR در پادمن است.

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

.SS \fBTLSVerify=\fR
الزام استفاده از HTTPS و اعتبارسنجی گواهی‌ها هنگام تماس با رجیستری‌ها.

.PP
این معادل گزینه \fB--tls-verify\fR در پادمن است.

.SH Quadlet section [Quadlet]
برخی از پیکربندی‌های خاص Quadlet بین انواع مختلف واحدها مشترک هستند. این تنظیمات را می‌توان در بخش \fB[Quadlet]\fR پیکربندی کرد.

.PP
گزینه‌های معتبر برای \fB[Quadlet]\fR در زیر فهرست شده‌اند:

.TS
allbox;
l l 
l l .
\fBگزینه‌های [Quadlet]\fP	\fBتوضیحات\fP
DefaultDependencies=false	T{
غیرفعال کردن وابستگی‌های ضمنی شبکه به واحد
T}
.TE

.SS \fBDefaultDependencies=\fR
افزودن وابستگی‌های شبکه‌ای پیش‌فرض Quadlet به واحد (پیش‌فرض \fBtrue\fR است).

.PP
هنگامی که روی false تنظیم شود، Quadlet وابستگی (After=, Wants=) به \fBnetwork-online.target\fR/\fBpodman-user-wait-network-online.service\fR را به واحد تولیدشده اضافه \fBنخواهد\fP کرد.

.PP
توجه داشته باشید که این گزینه در بخش \fB[Quadlet]\fR تنظیم می‌شود. بخش \fB[Unit]\fR در \fIsystemd\fP نیز گزینه‌ای با همین نام اما با معنایی متفاوت دارد.

.SH "مثال‌ها (EXAMPLES)"
مثال \fBtest.container\fR:

.EX
[Unit]
Description=A minimal container

[Container]
# Use the centos image
Image=quay.io/centos/centos:latest

# Use volume and network defined below
Volume=test.volume:/data
Network=test.network

# In the container we just run sleep
Exec=sleep 60

[Service]
# Restart service when sleep finishes
Restart=always
# Extend Timeout to allow time to pull the image
TimeoutStartSec=900
# ExecStartPre flag and other systemd commands can go here, see systemd.unit(5) man page.
ExecStartPre=/usr/share/mincontainer/setup.sh

[Install]
# Start by default on boot
WantedBy=multi-user.target default.target
.EE

.PP
مثال \fBtest.kube\fR:

.EX
[Unit]
Description=A kubernetes yaml based service
Before=local-fs.target

[Kube]
Yaml=/opt/k8s/deployment.yml

[Install]
# Start by default on boot
WantedBy=multi-user.target default.target
.EE

.PP
مثال برای ایمیج ساخته‌شده به صورت محلی جهت استفاده در یک کانتینر با آرگومان‌های ویژه ساخت:

.PP
\fBtest.build\fR

.EX
[Build]
# Tag the image to be built
ImageTag=localhost/imagename

# Set the working directory to the path of the unit file,
# expecting to find a Containerfile/Dockerfile
# + other files needed to build the image
SetWorkingDirectory=unit
# Set build arguments VERSION and DEBUG
BuildArg=VERSION=1.0   
          DEBUG=false
.EE

.PP
\fBtest.container\fR

.EX
[Container]
Image=test.build
.EE

.PP
مثال \fBtest.volume\fR:

.EX
[Volume]
User=root
Group=root
Label=org.test.Key=value
.EE

.PP
مثال \fBtest.network\fR:

.EX
[Network]
Subnet=172.16.0.0/24
Gateway=172.16.0.1
IPRange=172.16.0.0/28
Label=org.test.Key=value
.EE

.PP
مثال \fBtest.artifact\fR فقط برای دریافت آرتیفکت با استفاده از یک فایل احراز هویت:

.EX
[Artifact]
Artifact=quay.io/example/my-artifact:latest
AuthFile=/etc/registry/auth.json
TLSVerify=false
.EE

.PP
مثال کاربردی که در آن یک کانتینر به یک آرتیفکت وابسته است:

.PP
\fBmy-artifact.artifact\fR:

.EX
[Artifact]
Artifact=quay.io/example/my-config:latest
.EE

.PP
\fBmy-app.container\fR:

.EX
[Container]
Image=quay.io/example/my-app:latest
Mount=type=artifact,source=my-artifact.artifact,destination=/etc/config
.EE

.PP
مثال برای یک کانتینر در یک پاد (Pod):

.PP
\fBtest.pod\fR

.EX
[Pod]
PodName=test
.EE

.PP
\fBcentos.container\fR

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

.PP
مثال برای یک پاد با یک وظیفه راه‌اندازی تک‌باره (one-shot startup task):

.PP
\fBtest.pod\fR

.EX
[Pod]
PodName=test
ExitPolicy=continue
.EE

.PP
\fBstartup-task.container\fR

.EX
[Service]
Type=oneshot
RemainAfterExit=yes

[Container]
Pod=test.pod
Image=quay.io/centos/centos:latest
Exec=sh -c "echo 'setup starting'; sleep 2; echo 'setup complete'"
.EE

.PP
\fBapp.container\fR

.EX
[Unit]
Requires=startup-task.container
After=startup-task.container

[Container]
Pod=test.pod
Image=quay.io/centos/centos:latest
Exec=sh -c "echo 'app running.'; sleep 30"
.EE

.PP
مثال \fBs3fs.volume\fR:

.PP
برای جزئیات بیشتر، لطفاً به پروژه s3fs-fuse مراجعه کنید.
به یاد داشته باشید که پرسش‌های متداول (FAQ) را مطالعه نمایید.

.PP
.RS

.PP
نکته: فعال‌سازی کش (حافظه موقت) سرعت دسترسی و زمان نوشتن روی فایل‌ها/اشیاء استاتیک را به شدت افزایش می‌دهد.

.PP
با این حال، گزینه \fBuse_cache\fR بدون محدودیت (UNBOUNDED) است!

.PP
مراقب باشید؛ این کش با هر فایلی که روی باکت s3 از طریق سیستم فایل به آن دسترسی پیدا شود، پر خواهد شد.

.RE

.PP
لطفاً به یاد داشته باشید که \fBS3_BUCKET\fR، \fBPATH\fR و \fBAWS_REGION\fR را تنظیم کنید. متغیر \fBCACHE_DIRECTORY\fR باید توسط systemd راه‌اندازی شود.

.EX
[Service]
CacheDirectory=s3fs
ExecStartPre=/usr/local/bin/aws s3api put-object --bucket ${S3_BUCKET} --key ${PATH}/

[Volume]
Device=${S3_BUCKET}:/${PATH}
Type=fuse.s3fs
VolumeName=s3fs-volume
Options=iam_role,endpoint=${AWS_REGION},use_xattr,listobjectsv2,del_cache,use_cache=${CACHE_DIRECTORY}
# `iam_role` assumes inside EC2, if not, Use `profile=` instead
.EE

.PP
برای مثال‌های بیشتر، لطفاً صفحه راهنمای podman-quadlet-basic-usage(7) را مشاهده کنید.

.SH "همچنین ببینید (SEE ALSO)"
.IP \(bu 2
\fBpodman-auto-update(1)\fP
.IP \(bu 2
\fBpodman-build.unit(5),\fP
.IP \(bu 2
\fBpodman-container.unit(5),\fP
.IP \(bu 2
\fBpodman-image.unit(5),\fP
.IP \(bu 2
\fBpodman-kube.unit(5),\fP
.IP \(bu 2
\fBpodman-network-create(1)\fP,
.IP \(bu 2
\fBpodman-network.unit(5),\fP
.IP \(bu 2
\fBpodman-pod.unit(5),\fP
.IP \(bu 2
\fBpodman-quadlet-basic-usage.7,\fP
.IP \(bu 2
\fBpodman-run(1)\fP,
.IP \(bu 2
\fBpodman-volume.unit(5),\fP
.IP \(bu 2
\fBsystemd-analyze(1)\fP,
.IP \(bu 2
\fBsystemd.service(5)\fP,
.IP \(bu 2
\fBsystemd.unit(5)\fP