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

podman-systemd.unit - واحدهای systemd با استفاده از Podman Quadlet

name.artifact, name.build, name.container, name.image, name.kube, name.network, name.pod, name.volume

  • .build — ساخت تصویر کانتینر از روی Containerfile. صفحه راهنمای podman-build.unit(5) را ببینید.
  • .container — تعریف و مدیریت یک کانتینر منفرد. صفحه راهنمای podman-container.unit(5) را ببینید.
  • .image — دریافت (Pull) و ذخیره موقت تصویر کانتینر. صفحه راهنمای podman-image.unit(5) را ببینید.
  • .kube — استقرار کانتینرها از روی YAML کوبرنتیز با استفاده از podman-kube.unit(5).
  • .network — ایجاد شبکه پودمن برای کانتینرها و پادها. صفحه راهنمای podman-network.unit(5) را ببینید.
  • .pod — ایجاد پاد پودمن که کانتینرها می‌توانند به آن بپیوندند. صفحه راهنمای podman-pod.unit(5) را ببینید.
  • .volume — اطمینان از وجود یک جلد (Volume) نام‌دار پودمن. صفحه راهنمای podman-volume.unit(5) را ببینید.

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

کادلت‌های موقت، معمولاً برای آزمایش استفاده می‌شوند:

•
/run/containers/systemd/

کادلت‌های تعریف‌شده توسط مدیر سیستم:

•
/etc/containers/systemd/

کادلت‌های تعریف‌شده توسط توزیع:

•
/usr/share/containers/systemd/

فایل‌های Quadlet برای کاربران غیرریشه می‌توانند در دایرکتوری‌های زیر قرار گیرند:

  • $XDG_RUNTIME_DIR/containers/systemd/
  • $XDG_CONFIG_HOME/containers/systemd/ یا ~/.config/containers/systemd/
  • /etc/containers/systemd/users/${UID}
  • /etc/containers/systemd/users/
  • /usr/share/containers/systemd/users/${UID}
  • /usr/share/containers/systemd/users/

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

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

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

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

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

برای کانتینرهای بدون ریشه، زمانی که مدیران سیستم فایل‌های 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 به صورت بازگشتی جستجو کرده و فایل‌های واحد موجود در این زیردایرکتوری‌ها را اجرا می‌کند.

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

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

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

[Service]
TimeoutStartSec=900

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

به طور پیش‌فرض، فیلد Type در بخش Service فایل Quadlet نیازی به تنظیم ندارد. ابزار Quadlet آن را برای فایل‌های .container و .kube روی notify، برای فایل‌های .pod روی forking، و برای فایل‌های .volume، .network، .build، .image و .artifact روی oneshot تنظیم می‌کند.

با این حال، زمانی که انتظار نمی‌رود پس از خروج podman هیچ کانتینری اجرا شود، می‌توان Type را صریحاً برای فایل‌های .container و .kube روی oneshot تنظیم کرد.

هنگام تنظیم Type=oneshot، توصیه می‌شود که RemainAfterExit=yes نیز تنظیم شود تا از تبدیل وضعیت سرویس به inactive (dead) جلوگیری شود. با این حال، هنگام فعال‌سازی یک سرویس از طریق یک واحد زمان‌سنج (Timer)، تنظیم RemainAfterExit=yes وظیفه را در وضعیت "started" باقی می‌گذارد که از فعال‌سازی‌های بعدی توسط زمان‌سنج جلوگیری می‌کند. برای اطلاعات بیشتر، صفحه راهنمای systemd.service(5) را ببینید.

مثال‌هایی برای چنین مواردی: - فایل .container با تصویری که پس از پایان نقطه ورود (entrypoint) خود خارج می‌شود

•
فایل .kube که به یک فایل YAML کوبرنتیز اشاره می‌کند که هیچ کانتینری در آن تعریف نشده است؛ مانند مواردی که فقط PVC دارند

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

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

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

[Install]
WantedBy=default.target

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

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

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

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

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

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

یک فایل الگوی نمونه مانند sleep@.container ممکن است به این شکل باشد:

[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

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

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

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

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

foo-data@.volume:

[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

foo@.container:

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

توجه داشته باشید که ما به جای نام نمونه foo-data@%i.volume به نام الگو یعنی foo-data@.volume ارجاع می‌دهیم. ابزار Quadlet فایل الگو را خوانده و نام صحیح جلد را (همراه با مشخص‌کننده systemd) برای دستور podman run در فایل .service تولیدشده تعیین می‌کند. در این مثال، مقدار ExecStart تولیدشده توسط Quadlet شبیه به این خواهد بود:

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

به منظور پشتیبانی از مشخص‌کننده‌های Systemd، ابزار Quadlet مسیرهای نسبی را که با % شروع می‌شوند حل نمی‌کند. برای حل چنین مسیری، ./ را به ابتدای آن اضافه کنید.

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

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

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

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

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

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

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

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

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

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

ابزار Quadlet با افزودن ویژگی‌های After= و Wants= به واحد، وابستگی‌هایی به network-online.target (به عنوان ریشه) یا podman-user-wait-network-online.service (به عنوان کاربر) اضافه می‌کند. این کار برای اطمینان از قابل دسترس بودن شبکه در صورت نیاز به دریافت تصویر و در زمان راه‌اندازی کانتینر است.

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

این رفتار را می‌توان با افزودن DefaultDependencies=false در بخش Quadlet غیرفعال کرد. توجه داشته باشید که بخش [Unit] در systemd گزینه‌ای با همین نام اما مفهومی متفاوت دارد.

ابزار Quadlet به طور خودکار وابستگی‌های مشخص‌شده در کلیدهای Wants، Requires، Requisite، BindsTo، PartOf، Upholds، Conflicts، Before و After از بخش [Unit] را میان واحدهای مختلف Quadlet ترجمه می‌کند.

به عنوان مثال، واحد fedora.container در زیر، یک وابستگی به واحد basic.container را مشخص می‌کند.

[Unit]
After=basic.container
Requires=basic.container
[Container]
Image=registry.fedoraproject.org/fedora:41

واحدهای Quadlet اجازه تنظیم نام منابع ایجادشده را می‌دهند (مانند VolumeName برای واحدهای .volume یا PodName برای واحدهای .pod).

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

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

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

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

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

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

توضیحات بخش [Container] عبارتند از:

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

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

برای مثال:

AddCapability=CAP_DAC_OVERRIDE CAP_IPC_OWNER

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

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

افزودن نگاشت میزبان به IP به /etc/hosts. قالب آن به صورت hostname:ip است.

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

تنظیم یک یا چند حاشیه‌نویسی OCI (OCI annotations) روی کانتینر. قالب آن فهرستی از موارد key=value است، مشابه با Environment.

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

پروفایل محدودسازی apparmor را برای کانتینر تنظیم می‌کند. مقدار unconfined محدودسازی apparmor را غیرفعال می‌کند.

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

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

حالت cgroups در کانتینر پودمن. معادل گزینه --cgroups در پودمن.

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

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

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

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

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

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

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

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

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

تنظیم دامنه‌های جستجوی سفارشی DNS. برای حذف دامنه جستجو از DNSSearch=. استفاده کنید.

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

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

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

برای مثال:

DropCapability=CAP_DAC_OVERRIDE CAP_IPC_OWNER

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

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

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

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

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

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

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

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

در معرض قرار دادن یک درگاه، یا بازه‌ای از درگاه‌ها (مانند 50-59)، از میزبان به کانتینر. معادل گزینه --expose در پودمن.

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

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

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

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

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

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

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

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

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

تنظیم یا تغییر دستور بررسی سلامت برای یک کانتینر. مقدار none بررسی‌های سلامت موجود را غیرفعال می‌کند. معادل گزینه --health-cmd در پودمن.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

نام میزبان در دسترس در داخل کانتینر را تنظیم می‌کند. معادل گزینه --hostname در Podman است.

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

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

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

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

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

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

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

به Podman می‌گوید چگونه حجم‌های داخلی ایمیج را مدیریت کند. پیش‌فرض bind است. معادل گزینه --image-volume در Podman است.

یک نشانی استاتیک IPv4 برای کانتینر تعیین می‌کند، برای مثال 10.88.64.128. معادل گزینه --ip در Podman است.

یک نشانی استاتیک IPv6 برای کانتینر تعیین می‌کند، برای مثال fd46:db93:aa76:ac37::10. معادل گزینه --ip6 در Podman است.

یک یا چند برچسب OCI را روی کانتینر تنظیم می‌کند. قالب آن به صورت فهرستی از موارد key=value است، مشابه Environment.

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

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

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

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

میزان حافظه برای کانتینر را مشخص می‌کند.

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

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

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

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

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

یک شبکه سفارشی برای کانتینر مشخص می‌کند. این گزینه همان قالبی را دارد که گزینه --network در podman run دارد. برای مثال، از host برای استفاده از شبکه میزبان در کانتینر، یا از none برای عدم راه‌اندازی شبکه در کانتینر استفاده کنید.

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

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

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

یک نام مستعار در محدوده شبکه برای کانتینر اضافه می‌کند. این گزینه دارای همان قالبی است که گزینه --network-alias در دستور podman run دارد. از نام‌های مستعار می‌توان برای گروه‌بندی کانتینرها با یکدیگر در تفکیک DNS استفاده کرد: برای مثال، تنظیم NetworkAlias=web روی چند کانتینر باعث می‌شود که یک پرس‌وجوی DNS برای نام web به تمام کانتینرهای دارای آن نام مستعار هدایت شود.

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

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

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

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

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

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

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

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

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

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

یک پورت یا محدوده‌ای از پورت‌ها (مانند 50-59) را از کانتینر به میزبان متصل و نمایان می‌سازد. معادل گزینه --publish در Podman است. قالب آن مشابه گزینه‌های Podman بوده و به صورت ip:hostPort:containerPort، ip::containerPort، hostPort:containerPort یا containerPort است که در آن تعداد پورت‌های میزبان و کانتینر باید برابر باشند (در حالت یک محدوده). پروتکل را می‌توان در انتها قید کرد، مانند hostPort:containerPort/tcp. پروتکل‌های معتبر tcp و udp هستند؛ پروتکل sctp فقط برای کانتینرهای با ریشه (rootful) پشتیبانی می‌شود.

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

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

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

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

در صورت فعال بودن، ایمیج را فقط‌خواندنی می‌کند.

اگر ReadOnly روی true تنظیم شده باشد، یک tmpfs خواندنی-نوشتنی روی مسیرهای /dev، /dev/shm، /run، /tmp و /var/tmp متصل (mount) می‌کند.

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

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

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

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

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

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

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

تاخیر زمانی میان تلاش‌های مجدد. معادل گزینه --retry-delay در Podman است.

سیستم‌فایل ریشه (rootfs) مورد استفاده برای کانتینر. گزینه Rootfs به یک دایرکتوری در سیستم اشاره دارد که شامل محتوایی است که باید درون کانتینر اجرا شود. این گزینه با گزینه Image در تضاد است.

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

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

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

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

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

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

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

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

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

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

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

نکته: نام نباید شامل پسوند فایل .service باشد.

اندازه دایرکتوری /dev/shm.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

برای مثال:

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

منطقه زمانی که کانتینر باید در آن اجرا شود.

یک tmpfs را در کانتینر متصل (mount) می‌کند. این معادل گزینه --tmpfs در Podman است، و عموماً قالبی به شکل CONTAINER-DIR[:OPTIONS] دارد.

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

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

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

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

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

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

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

مسیرهای پیش‌فرضی که ماسک شده‌اند عبارتند از: /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.

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

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

نکته: هنگامی که هر دو گزینه User= و Group= مشخص شده باشند، در یک آرگومان واحد به صورت --user USER:GROUP ترکیب شده و به Podman ارسال می‌شوند.

حالت فضای نام کاربری را برای کانتینر تنظیم می‌کند. این معادل گزینه --userns در Podman است و عموماً قالبی به شکل MODE[:OPTIONS,...] دارد.

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

اگر SOURCE-VOLUME با . آغاز شود، Quadlet مسیر را به صورت نسبی نسبت به مکان فایل واحد تحلیل می‌کند.

حالت خاص:

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

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

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

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

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

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

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

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

گزینه‌های [Pod] معادل در podman pod create
AddHost=example.com:192.168.10.11 --add-host example.com:192.168.10.11
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 به name.service
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 --userns keep-id:uid=200,gid=210
Volume=/source:/dest --volume /source:/dest

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

یک نگاشت نام میزبان به IP را به /etc/hosts اضافه می‌کند. قالب آن به صورت hostname:ip است.

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

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

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

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

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

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

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

دامنه‌های جستجوی سفارشی DNS را تنظیم می‌کند. از DNSSearch=. برای حذف دامنه جستجو استفاده کنید.

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

سیاست خروج پاد را هنگام خروج آخرین کانتینر تنظیم می‌کند. مقدار پیش‌فرض برای quadletها stop است.

برای فعال نگه‌داشتن پاد، ExitPolicy=continue را تنظیم کنید.

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

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

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

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

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

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

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

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

یک نشانی استاتیک IPv4 برای پاد تعیین می‌کند، برای مثال 10.88.64.128. معادل گزینه --ip در Podman است.

یک نشانی استاتیک IPv6 برای پاد تعیین می‌کند، برای مثال fd46:db93:aa76:ac37::10. معادل گزینه --ip6 در Podman است.

یک یا چند برچسب OCI را روی پاد تنظیم می‌کند. قالب آن به صورت فهرستی از موارد key=value است، مشابه Environment.

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

یک شبکه سفارشی برای پاد مشخص می‌کند. این گزینه دارای همان قالبی است که گزینه --network در دستور podman pod create دارد. برای مثال، از host برای استفاده از شبکه میزبان در پاد، یا از none برای عدم راه‌اندازی شبکه در پاد استفاده کنید.

حالت خاص:

•
اگر نام شبکه به .network ختم شود، Quadlet به دنبال واحد متناظر Quadlet با پسوند .network خواهد گشت. در صورت یافتن، Quadlet از نام Network تنظیم‌شده در واحد استفاده می‌کند؛ در غیر این صورت، systemd-$name استفاده می‌شود.

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

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

یک نام مستعار در محدوده شبکه برای پاد اضافه می‌کند. این گزینه دارای همان قالبی است که گزینه --network-alias در دستور podman pod create دارد. از نام‌های مستعار می‌توان برای گروه‌بندی کانتینرها با یکدیگر در تفکیک DNS استفاده کرد: برای مثال، تنظیم NetworkAlias=web روی چند کانتینر باعث می‌شود که یک پرس‌وجوی DNS برای نام web به تمام کانتینرهای دارای آن نام مستعار هدایت شود.

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

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

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

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

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

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

یک پورت یا محدوده‌ای از پورت‌ها (مانند 50-59) را از پاد به میزبان متصل و نمایان می‌سازد. معادل گزینه --publish در Podman است. قالب آن مشابه گزینه‌های Podman بوده و به صورت ip:hostPort:containerPort، ip::containerPort، hostPort:containerPort یا containerPort است که در آن تعداد پورت‌های میزبان و کانتینر باید برابر باشند (در حالت یک محدوده). پروتکل را می‌توان در انتها قید کرد، مانند hostPort:containerPort/tcp. پروتکل‌های معتبر tcp و udp هستند؛ پروتکل sctp فقط برای کانتینرهای با ریشه (rootful) پشتیبانی می‌شود.

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

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

هنگام استفاده از شبکه host از طریق Network=host، گزینه PublishPort= قابل استفاده نخواهد بود.

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

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

نکته: نام نباید شامل پسوند فایل .service باشد.

اندازه دایرکتوری /dev/shm.

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

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

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

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

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

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

حالت فضای نام کاربری را برای پاد تنظیم می‌کند. این معادل گزینه --userns در Podman است و عموماً قالبی به شکل MODE[:OPTIONS,...] دارد.

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

اگر SOURCE-VOLUME با . آغاز شود، Quadlet مسیر را به صورت نسبی نسبت به مکان فایل واحد تحلیل می‌کند.

حالت خاص:

•
اگر SOURCE-VOLUME به .volume ختم شود، Quadlet به دنبال واحد متناظر Quadlet با پسوند .volume خواهد گشت. در صورت یافتن، Quadlet از نام Volume تنظیم‌شده در واحد استفاده می‌کند؛ در غیر این صورت، systemd-$name استفاده می‌شود. توجه: فایل متناظر .volume باید وجود داشته باشد.

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

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

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

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

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

گزینه‌های [Kube] معادل در podman kube play
AutoUpdate=registry --annotation "io.containers.autoupdate=registry"
ConfigMap=/tmp/config.map --config-map /tmp/config.map
ContainersConfModule=/etc/nvd.conf --module=/etc/nvd.conf
ExitCodePropagation=how نحوه انتشار وضعیت خطای کانتینر
GlobalArgs=--log-level=debug --log-level=debug
KubeDownForce=true --force (برای podman kube down)
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 به name.service
SetWorkingDirectory=yaml تنظیم WorkingDirectory فایل واحد به مکان فایل YAML
UserNS=keep-id:uid=200,gid=210 --userns keep-id:uid=200,gid=210
Yaml=/tmp/kube.yaml podman kube play /tmp/kube.yaml

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

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

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

مسیر YAML کانفیگ‌مپ (ConfigMap) کوبرنتیز را از طریق آرگومان --configmap به podman kube play ارسال می‌کند. بر خلاف آرگومان configmap، مقدار فقط می‌تواند شامل یک مسیر باشد، اما می‌تواند مطلق یا نسبت به مکان فایل واحد باشد.

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

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

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

کنترل می‌کند که PID اصلی سرویس systemd چگونه باید خارج شود. مقادیر زیر پشتیبانی می‌شوند: - all: در صورتی که همه کانتینرها شکست خورده باشند (یعنی با کد غیرصفر خارج شده باشند) با کد غیرصفر خارج شود - any: در صورتی که هر یک از کانتینرها شکست خورده باشند با کد غیرصفر خارج شود - none: با کد صفر خارج شود و کانتینرهای ناموفق را نادیده بگیرد

مقدار پیش‌فرض فعلی none است.

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

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

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

هنگام فراخوانی podman kube down تمام منابع، از جمله حجم‌ها را حذف می‌کند. معادل گزینه --force در Podman است.

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

یک شبکه سفارشی برای کانتینر مشخص می‌کند. این گزینه دارای همان قالبی است که گزینه --network در podman kube play دارد. به عنوان مثال، از host برای استفاده از شبکه میزبان در کانتینر، یا از none برای عدم راه‌اندازی شبکه در کانتینر استفاده کنید.

حالت خاص:

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

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

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

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

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

یک درگاه (پورت) یا محدوده‌ای از درگاه‌ها (مانند 50-59) را از کانتینر به میزبان در دسترس قرار می‌دهد. معادل گزینه --publish در podman kube play است. قالب آن شبیه به گزینه‌های Podman است، که به شکل ip:hostPort:containerPort، ip::containerPort، hostPort:containerPort یا containerPort است، که در آن تعداد پورت‌های میزبان و کانتینر باید یکسان باشد (در حالت یک محدوده). پروتکل را می‌توان در انتها ارائه کرد، مانند hostPort:containerPort/tcp. پروتکل‌های معتبر tcp و udp هستند؛ پروتکل sctp فقط برای کانتینرهای با دسترسی ریشه (rootful) پشتیبانی می‌شود.

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

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

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

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

توجه داشته باشید که نام نباید شامل پسوند فایل .service باشد.

فیلد WorkingDirectory از گروه Service فایل واحد سرویس Systemd را تنظیم می‌کند. برای این استفاده می‌شود که به podman kube play اجازه دهد مسیرهای نسبی را به درستی حل (resolve) کند. مقادیر پشتیبانی‌شده yaml و unit هستند تا دایرکتوری کاری را به ترتیب به دایرکتوری فایل YAML یا فایل واحد Quadlet تنظیم کنند.

همچنین، کاربران می‌توانند به صراحت فیلد WorkingDirectory از گروه Service را در فایل .kube تنظیم کنند. لطفاً توجه داشته باشید که اگر فیلد WorkingDirectory از گروه Service تنظیم شده باشد، حتی اگر SetWorkingDirectory نیز تنظیم شده باشد، Quadlet آن را تنظیم نخواهد کرد.

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

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

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

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

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

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

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

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

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

گزینه‌های [Network] معادل در podman network create
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 افزودن ExecStopPost برای حذف شبکه هنگام توقف واحد
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 به name.service
Subnet=192.5.0.0/16 --subnet 192.5.0.0/16

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

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

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

در صورت فعال بودن، افزونه DNS را برای این شبکه غیرفعال می‌کند.

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

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

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

درایور برای مدیریت شبکه. در حال حاضر bridge، macvlan و ipvlan پشتیبانی می‌شوند.

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

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

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

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

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

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

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

این گزینه با گزینه network_interface در پیکربندی شبکه تطابق دارد، podman network inspect را ببینید. بسته به درایور، این می‌تواند اثرات متفاوتی داشته باشد؛ برای bridge، از نام رابط پل (bridge) استفاده می‌کند. برای macvlan و ipvlan، دستگاه والد روی میزبان است. این معادل --opt parent=... است.

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

دسترسی خارجی این شبکه را محدود می‌کند.

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

درایور IPAM (درایور مدیریت آدرس IP) را برای شبکه تنظیم می‌کند. در حال حاضر host-local، dhcp و none پشتیبانی می‌شوند.

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

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

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

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

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

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

یک یا چند برچسب OCI را روی شبکه تنظیم می‌کند. قالب آن فهرستی از موارد key=value، مشابه با Environment است.

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

هنگامی که روی true تنظیم شود، با متوقف شدن سرویس، شبکه حذف می‌شود.

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

گزینه‌های مخصوص درایور را تنظیم می‌کند.

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

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

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

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

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

توجه داشته باشید که نام نباید شامل پسوند فایل .service باشد.

زیرشبکه در نمادگذاری CIDR.

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

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

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

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

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

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

گزینه‌های [Volume] معادل در podman volume create
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 --opt image=quay.io/centos/centos:latest
Label="foo=bar" --label "foo=bar"
Options=XYZ --opt "o=XYZ"
PodmanArgs=--driver=image --driver=image
ServiceName=name نام‌گذاری واحد systemd به name.service
Type=type نوع سیستم‌فایل Device
UID=1234 --uid 1234
User=123 --opt "o=uid=123"
VolumeName=foo podman volume create foo

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

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

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

در صورت فعال بودن، محتوای ایمیج واقع در نقطه اتصال (mountpoint) حجم در اولین اجرا در داخل حجم کپی می‌شود.

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

نام درایور حجم را مشخص می‌کند. هنگامی که روی image تنظیم شود، کلید Image نیز باید تنظیم شده باشد.

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

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

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

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

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

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

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

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

حالت خاص:

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

یک یا چند برچسب OCI را روی حجم تنظیم می‌کند. قالب آن فهرستی از موارد key=value، مشابه با Environment است.

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

گزینه‌های اتصالی (mount options) که برای یک سیستم‌فایل استفاده می‌شوند، همانند آنچه در گزینه -o دستور mount(8) استفاده می‌شود.

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

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

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

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

توجه داشته باشید که نام نباید شامل پسوند فایل .service باشد.

نوع سیستم‌فایل Device، همان‌گونه که در گزینه -t دستورات mount(8) استفاده می‌شود.

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

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

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

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

یک واحد .build کمینه حداقل به کلید ImageTag=، و یکی از کلیدهای File= یا SetWorkingDirectory= نیاز دارد.

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

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

گزینه‌های [Build] معادل در podman build
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 به name.service
SetWorkingDirectory=unit تنظیم WorkingDirectory فایل واحد systemd
Target=my-app --target=my-app
TLSVerify=false --tls-verify=false
Variant=arm/v7 --variant=arm/v7
Volume=/source:/dest --volume /source:/dest

یک پی‌نوشت یا حاشیه‌نویسی (annotation) ایمیج (مانند annotation=value) را به متادیتای ایمیج اضافه می‌کند. می‌تواند چندین بار استفاده شود.

این معادل گزینه --annotation در podman build است.

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

این معادل گزینه --arch در podman build است.

مسیر فایل احراز هویت.

این معادل گزینه --authfile در podman build است.

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

این معادل گزینه --build-arg در podman build است.

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

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

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

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

این معادل گزینه --dns در podman build است.

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

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

این معادل گزینه --dns-option در podman build است.

دامنه‌های سفارشی جستجوی DNS را تنظیم می‌کند. برای حذف دامنه جستجو از DNSSearch=. استفاده کنید.

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

این معادل گزینه --dns-search در podman build است.

یک مقدار (مانند env=value) را به ایمیج ساخته‌شده اضافه می‌کند. این گزینه از همان قالب سرویس‌ها در systemd ⟨https://www.freedesktop.org/software/systemd/man/systemd.exec.html#Environment=⟩ استفاده می‌کند و می‌تواند چندین بار درج شود.

یک Containerfile را مشخص می‌کند که شامل دستورالعمل‌های ساخت ایمیج است. نشانی اینترنتی (URL) که با http(s):// آغاز شود به شما امکان می‌دهد یک Containerfile راه دور را برای دانلود مشخص کنید. توجه داشته باشید که برای یک مسیر نسبی معین به Containerfile، یا هنگام استفاده از URL با http(s)://، باید SetWorkingDirectory= را نیز تنظیم کنید تا podman build بتواند یک دایرکتوری زمینه (context) معتبر برای منابع مشخص‌شده در Containerfile پیدا کند.

توجه داشته باشید که تنظیم فیلد File= برای فایل .build الزامی است، مگر اینکه SetWorkingDirectory (یا WorkingDirectory در گروه Service) نیز تنظیم شده باشد.

این معادل گزینه --file در podman build است.

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

این معادل گزینه --force-rm در podman build است.

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

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

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

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

این معادل گزینه --group-add در podman build است.

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

این معادل گزینه --ignorefile در podman build است.

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

این معادل گزینه --tag در podman build است.

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

افزودن یک برچسب ایمیج (label، مانند label=value) به متادیتای ایمیج. این کلید می‌تواند چندین بار استفاده شود.

این معادل گزینه --label در podman build است.

پیکربندی فضاهای نام شبکه (network namespaces) را هنگام پردازش دستورالعمل‌های RUN تنظیم می‌کند. این کلید همان قالب گزینه --network در podman build را دارد. برای مثال، برای استفاده از شبکه میزبان از host، یا برای عدم راه‌اندازی شبکه از none استفاده کنید.

حالت ویژه:

•
اگر نام شبکه به .network ختم شود، Quadlet به دنبال واحد Quadlet مربوطه با پسوند .network خواهد گشت. در صورت یافتن، Quadlet از نام شبکه تنظیم‌شده در Unit استفاده می‌کند، در غیر این صورت از systemd-$name استفاده می‌شود. سرویس systemd تولیدشده شامل یک وابستگی به واحد سرویس تولیدشده برای آن واحد .network، یا در صورت پیدا نشدن واحد .network به $name-network.service خواهد بود. نکته: فایل .network متناظر باید وجود داشته باشد.

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

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

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

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

سیاست دریافت (pull) ایمیج را تنظیم می‌کند.

این معادل گزینه --pull در podman build است.

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

مدت زمان تاخیر بین تلاش‌های مجدد. معادل گزینه --retry-delay در پادمن است.

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

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

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

توجه داشته باشید که نام نباید شامل پسوند فایل .service باشد.

فراهم کردن کانتکست (یک دایرکتوری کاری) برای podman build. مقادیر پشتیبانی‌شده عبارتند از یک مسیر، یک URL، یا کلیدهای ویژه file یا unit برای تنظیم دایرکتوری کانتکست به ترتیب روی دایرکتوری والد فایل مشخص‌شده در کلید File= یا دایرکتوری فایل واحد .build کوادلت. این قابلیت به Quadlet امکان می‌دهد مسیرهای نسبی را حل‌وفصل کند.

هنگام استفاده از یکی از کلیدهای ویژه (file یا unit)، فیلد WorkingDirectory از گروه Service واحد سرویس systemd نیز متناسب با آن تنظیم خواهد شد. همچنین، کاربران می‌توانند فیلد WorkingDirectory از گروه Service را صراحتاً در فایل .build تنظیم کنند. لطفاً توجه داشته باشید که اگر فیلد WorkingDirectory گروه Service توسط کاربر تنظیم شده باشد، Quadlet آن را حتی در صورت تنظیم SetWorkingDirectory روی file یا unit بازنویسی نخواهد کرد.

با ارائه یک نشانی اینترنتی (URL) به SetWorkingDirectory= می‌توانید به podman build دستور دهید یک مخزن گیت را کلون کند یا فایل فشرده‌ای (آرشیو) را دانلود کرده و به عنوان کانتکست ساخت در یک مکان موقت استخراج کند. توجه داشته باشید که در این حالت، فیلد WorkingDirectory واحد سرویس systemd توسط Quadlet دست‌نخورده باقی می‌ماند.

توجه داشته باشید که فراهم کردن دایرکتوری کانتکست برای فایل .build الزامی است، مگر اینکه کلید File= نیز ارائه شده باشد.

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

این معادل گزینه --target در podman build است.

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

این معادل گزینه --tls-verify در podman build است.

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

این معادل گزینه --variant در podman build است.

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

اگر SOURCE-VOLUME با . شروع شود، Quadlet مسیر را به صورت نسبی نسبت به محل فایل واحد حل‌وفصل می‌کند.

حالت ویژه:

•
اگر SOURCE-VOLUME به .volume ختم شود، Quadlet به دنبال واحد Quadlet متناظر با پسوند .volume خواهد گشت. در صورت یافتن، Quadlet از نام Volume تنظیم‌شده در Unit استفاده می‌کند، در غیر این صورت از systemd-$name استفاده می‌شود. سرویس systemd تولیدشده شامل یک وابستگی به واحد سرویس ایجادشده برای آن واحد .volume، یا در صورت پیدا نشدن واحد .volume به $name-volume.service خواهد بود. نکته: فایل .volume متناظر باید وجود داشته باشد.

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

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

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

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

گزینه‌های [Image] معادل در podman image pull
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 podman image pull quay.io/centos/centos:latest
ImageTag=quay.io/centos/centos:latest از این نام هنگام حل ارجاعات .image استفاده می‌شود
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 به صورت name.service
TLSVerify=false --tls-verify=false
Variant=arm/v7 --variant=arm/v7

تمام ایمیج‌های دارای تگ در مخزن دریافت می‌شوند.

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

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

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

مسیر فایل احراز هویت.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

نام کامل و معتبر واقعی ایمیج (FQIN) ارجاع داده شده در Image. تنها زمانی معنادار است که منبع یک فایل یا آرشیو دایرکتوری باشد.

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

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

نیازمند تنظیم موارد زیر است: - Image=docker-archive:/tmp/archive-file.tar - ImageTag=quay.io/podman/stable:latest

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

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

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

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

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

سیاست دریافتی که باید هنگام pull کردن ایمیج استفاده شود.

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

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

مدت زمان تاخیر بین تلاش‌های مجدد. معادل گزینه --retry-delay در پادمن است.

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

توجه داشته باشید که نام نباید شامل پسوند فایل .service باشد.

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

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

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

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

این واحد آزمایشی در نظر گرفته شده و همچنان در حال توسعه است. ورودی‌ها، گزینه‌ها و خروجی‌ها همگی ممکن است تغییر کنند.

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

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

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

گزینه‌های [Artifact] معادل در podman artifact pull
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 تنظیم نام سرویس systemd به my-artifact.service
TLSVerify=false --tls-verify=false

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

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

مسیر فایل احراز هویت.

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

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

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

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

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

اطلاعات احراز هویت برای استفاده هنگام تماس با رجیستری در قالب [username[:password]].

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

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

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

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

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

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

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

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

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

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

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

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

مدت زمان تاخیر بین تلاش‌های مجدد. معادل گزینه --retry-delay در پادمن است.

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

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

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

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

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

گزینه‌های [Quadlet] توضیحات
DefaultDependencies=false غیرفعال کردن وابستگی‌های ضمنی شبکه به واحد

افزودن وابستگی‌های شبکه‌ای پیش‌فرض Quadlet به واحد (پیش‌فرض true است).

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

توجه داشته باشید که این گزینه در بخش [Quadlet] تنظیم می‌شود. بخش [Unit] در systemd نیز گزینه‌ای با همین نام اما با معنایی متفاوت دارد.

مثال test.container:

[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

مثال test.kube:

[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

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

test.build

[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

test.container

[Container]
Image=test.build

مثال test.volume:

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

مثال test.network:

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

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

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

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

my-artifact.artifact:

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

my-app.container:

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

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

test.pod

[Pod]
PodName=test

centos.container

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

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

test.pod

[Pod]
PodName=test
ExitPolicy=continue

startup-task.container

[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'"

app.container

[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"

مثال s3fs.volume:

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

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

با این حال، گزینه use_cache بدون محدودیت (UNBOUNDED) است!

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

لطفاً به یاد داشته باشید که S3_BUCKET، PATH و AWS_REGION را تنظیم کنید. متغیر CACHE_DIRECTORY باید توسط systemd راه‌اندازی شود.

[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

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