--add-host=hostname[;hostname[;...]]:ip

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

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

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

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

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

--annotation=key=value

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

--arch=ARCH

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

--attach, -a=stdin | stdout | stderr

اتصال به STDIN، STDOUT یا STDERR.

در حالت پیش‌زمینه (پیش‌فرض زمانی که -d مشخص نشده باشد)، podman run می‌تواند فرایند را در کانتینر آغاز کرده و کنسول را به ورودی استاندارد، خروجی و خطای استاندارد فرایند متصل کند. حتی می‌تواند مانند یک TTY رفتار کند (چیزی که اکثر فایل‌های اجرایی خط فرمان انتظار دارند) و سیگنال‌ها را منتقل نماید. گزینه -a می‌تواند برای هر یک از stdin، stdout و stderr تنظیم شود.

--authfile=path

مسیر فایل احراز هویت. پیش‌فرض در لینوکس ${XDG_RUNTIME_DIR}/containers/auth.json و در ویندوز/مک‌او‌اس $HOME/.config/containers/auth.json است. این فایل توسط podman login ایجاد می‌شود. اگر وضعیت مجوز در آنجا یافت نشود، $HOME/.docker/config.json بررسی می‌شود که با docker login تنظیم شده است.

نکته: همچنین گزینه بازنویسی مسیر پیش‌فرض فایل احراز هویت با تنظیم متغیر محیطی REGISTRY_AUTH_FILE وجود دارد. این کار را می‌توان با export REGISTRY_AUTH_FILE=path انجام داد.

--blkio-weight=weight

وزن نسبی Block IO. مقدار weight عددی بین 10 و 1000 است.

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

--blkio-weight-device=device:weight

وزن نسبی دستگاه Block IO.

--cap-add=capability

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

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

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

--cap-drop=capability

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

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

--cert-dir=path

استفاده از گواهی‌ها در path (*.crt, *.cert, *.key) برای اتصال به رجیستری (پیش‌فرض: etc/containers/certs.d/). برای جزئیات به containers-certs.d(5) مراجعه کنید. (این گزینه در کلاینت ریموت پادمن، از جمله ماشین‌های مک و ویندوز (به استثنای WSL2) در دسترس نیست)

--cgroup-conf=KEY=VALUE

هنگام اجرا روی cgroup v2، فایل cgroup و مقدار مورد نظر برای نوشتن در آن را مشخص می‌کند. برای مثال --cgroup-conf=memory.high=1073741824 محدودیت memory.high را روی 1GB تنظیم می‌کند.

--cgroup-parent=path

مسیر cgroups که cgroup کانتینر تحت آن ایجاد می‌شود. اگر مسیر مطلق نباشد، مسیر نسبت به مسیر cgroups فرایند init در نظر گرفته می‌شود. Cgroups در صورتی که از قبل وجود نداشته باشند ایجاد می‌شوند.

--cgroupns=mode

تنظیم حالت فضای نام cgroup برای کانتینر.

• host: استفاده از فضای نام cgroup میزبان درون کانتینر.
• container:id: پیوستن به فضای نام کانتینر مشخص‌شده.
• private: ایجاد یک فضای نام cgroup جدید.
• ns:path: پیوستن به فضای نام در مسیر مشخص‌شده.

اگر میزبان از cgroups v1 استفاده کند، پیش‌فرض روی host تنظیم می‌شود. در cgroups v2، پیش‌فرض private است.

--cgroups=how

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

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

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

--chrootdirs=path

مسیر به دایرکتوری درون کانتینر که به عنوان یک دایرکتوری chroot تلقی می‌شود. هر فایل تحت مدیریت پادمن (مانند etc/resolv.conf/، /etc/hosts، /etc/hostname) که درون دایرکتوری root مانت شده باشد، در آن مکان نیز مانت می‌شود. چندین دایرکتوری با کاما از هم جدا می‌شوند.

--cidfile=file

نوشتن شناسه کانتینر در file. فایل همراه با کانتینر حذف می‌شود، مگر زمانی که با podman --remote run روی کانتینرهای جداشده (detached) استفاده شود.

--conmon-pidfile=file

نوشتن pid فرایند conmon در یک فایل. از آنجا که conmon در فرایندی جدا از پادمن اجرا می‌شود، هنگام استفاده از systemd برای راه‌اندازی مجدد کانتینرهای پادمن این گزینه ضروری است. (این گزینه در کلاینت ریموت پادمن، از جمله ماشین‌های مک و ویندوز (به استثنای WSL2) در دسترس نیست)

--cpu-period=limit

تنظیم دوره CPU برای زمان‌بند کاملاً منصفانه (CFS) که مدت زمانی بر حسب میکروثانیه است. پس از اتمام سهمیه CPU کانتینر، تا پایان دوره فعلی برای اجرا زمان‌بندی نخواهد شد. پیش‌فرض 100000 میکروثانیه است.

در برخی سیستم‌ها، تغییر محدودیت‌های منابع ممکن است برای کاربران غیر ریشه مجاز نباشد. برای جزئیات بیشتر به لینک زیر مراجعه کنید: https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

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

--cpu-quota=limit

محدود کردن سهمیه زمان‌بند کاملاً منصفانه (CFS) پردازنده.

محدود کردن میزان استفاده پردازنده توسط کانتینر. به طور پیش‌فرض، کانتینرها با تمام منابع CPU اجرا می‌شوند. محدودیت عددی بر حسب میکروثانیه است. در صورت ارائه یک عدد، کانتینر مجاز است تا پایان دوره CPU (قابل کنترل از طریق --cpu-period) از همان مقدار زمان پردازنده استفاده کند.

در برخی سیستم‌ها، تغییر محدودیت‌های منابع ممکن است برای کاربران غیر ریشه مجاز نباشد. برای جزئیات بیشتر به لینک زیر مراجعه کنید: https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

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

--cpu-rt-period=microseconds

محدود کردن دوره بی‌درنگ (Real-Time) پردازنده بر حسب میکروثانیه.

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

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

--cpu-rt-runtime=microseconds

محدود کردن زمان اجرای بی‌درنگ (Real-Time) پردازنده بر حسب میکروثانیه.

محدود کردن استفاده بی‌درنگ کانتینر از پردازنده. این گزینه به کرنل دستور می‌دهد مدت زمانی را که تسک‌های بی‌درنگ در یک دوره CPU مشخص می‌توانند مصرف کنند محدود کند. برای مثال: دوره 1,000,000us و زمان اجرای 950,000us به این معنی است که این کانتینر می‌تواند 95% از پردازنده موجود را مصرف کند و 5% باقی‌مانده را برای تسک‌های با اولویت عادی بگذارد.

مجموع کل زمان‌های اجرا در میان کانتینرها نمی‌تواند از مقدار اختصاص‌یافته به cgroup والد فراتر رود.

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

--cpu-shares, -c=shares

سهم‌های پردازنده (وزن نسبی).

به طور پیش‌فرض، همه کانتینرها سهم یکسانی از چرخه‌های CPU دریافت می‌کنند. این نسبت را می‌توان با تغییر وزن سهم پردازنده کانتینر نسبت به وزن ترکیبی همه کانتینرهای در حال اجرا تغییر داد. وزن پیش‌فرض 1024 است.

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

برای مثال، سه کانتینر را در نظر بگیرید، یکی دارای cpu-share برابر 1024 و دو کانتینر دیگر دارای تنظیم cpu-share برابر 512 هستند. هنگامی که فرایندها در هر سه کانتینر تلاش می‌کنند از 100% پردازنده استفاده کنند، کانتینر اول 50% از کل زمان CPU را دریافت می‌کند. اگر کانتینر چهارمی با cpu-share برابر 1024 اضافه شود، کانتینر اول تنها 33% از CPU را دریافت می‌کند. کانتینرهای باقی‌مانده به ترتیب 16.5%، 16.5% و 33% از CPU را دریافت می‌نمایند.

در یک سیستم چند هسته‌ای، سهم‌های زمان CPU بین تمام هسته‌های پردازنده توزیع می‌شود. حتی اگر یک کانتینر به کمتر از 100% زمان پردازنده محدود شده باشد، می‌تواند از 100% هر یک از هسته‌های پردازنده به صورت جداگانه استفاده کند.

برای مثال، سیستمی با بیش از سه هسته را در نظر بگیرید. اگر کانتینر C0 با --cpu-shares=512 با یک فرایند اجرا شود، و کانتینر دیگری با نام C1 با --cpu-shares=1024 با دو فرایند اجرا شود، این امر می‌تواند به تقسیم سهم‌های CPU به شرح زیر منجر شود:

در برخی سیستم‌ها، تغییر محدودیت‌های منابع ممکن است برای کاربران غیر ریشه مجاز نباشد. برای جزئیات بیشتر به لینک زیر مراجعه کنید: https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

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

--cpus=number

تعداد پردازنده‌ها. پیش‌فرض 0.0 به معنای عدم وجود محدودیت است. این گزینه حالت خلاصه‌شده --cpu-period و --cpu-quota است، بنابراین نمی‌توان آن را همراه با --cpu-period یا --cpu-quota مشخص کرد.

در برخی سیستم‌ها، تغییر محدودیت‌های CPU ممکن است برای کاربران غیر ریشه مجاز نباشد. برای جزئیات بیشتر به لینک زیر مراجعه کنید: https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

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

--cpuset-cpus=number

پردازنده‌هایی که اجرا در آن‌ها مجاز است. می‌توان به صورت یک لیست جداشده با کاما (مانند 0,1)، به عنوان یک بازه (مانند 0-3) یا هر ترکیبی از آن‌ها (مانند 0-3,7,11-15) مشخص کرد.

در برخی سیستم‌ها، تغییر محدودیت‌های منابع ممکن است برای کاربران غیر ریشه مجاز نباشد. برای جزئیات بیشتر به لینک زیر مراجعه کنید: https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

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

--cpuset-mems=nodes

گره‌های حافظه (MEMs) که اجرا در آن‌ها مجاز است (0-3، 0,1). تنها در سیستم‌های NUMA موثر است.

اگر چهار گره حافظه در سیستم وجود داشته باشد (0-3)، با استفاده از --cpuset-mems=0,1 فرایندهای درون کانتینر تنها از حافظه دو گره حافظه اول استفاده می‌کنند.

در برخی سیستم‌ها، تغییر محدودیت‌های منابع ممکن است برای کاربران غیر ریشه مجاز نباشد. برای جزئیات بیشتر به لینک زیر مراجعه کنید: https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

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

--creds=[username[:password]]

ترکیب [نام‌کاربری[:رمز‌عبور]] برای احراز هویت در رجیستری، در صورت لزوم. اگر یک یا هر دو مقدار ارائه نشوند، اعلان خط فرمان ظاهر شده و می‌توان مقدار را وارد کرد. رمز عبور بدون بازتاب (echo) وارد می‌شود.

توجه داشته باشید که اعتبارهای مشخص‌شده تنها برای احراز هویت در رجیستری‌های هدف استفاده می‌شوند. آن‌ها برای آینه‌ها (mirrors) یا زمانی که رجیستری بازنویسی می‌شود استفاده نمی‌شوند (به containers-registries.conf(5) مراجعه کنید)؛ برای احراز هویت در برابر آن‌ها استفاده از فایل containers-auth.json(5) را در نظر بگیرید.

--decryption-key=key[:passphrase]

ترکیب [key[:passphrase]] مورد استفاده برای رمزگشایی ایمیج‌ها. کلید می‌تواند به کلیدها و/یا گواهی‌ها اشاره کند. رمزگشایی با تمام کلیدها امتحان می‌شود. اگر کلید با یک عبارت عبور محافظت شده باشد، ارسال آن در آرگومان الزامی است و در غیر این صورت حذف می‌شود.

--detach, -d

حالت جداشده (Detached): اجرای کانتینر در پس‌زمینه و چاپ شناسه کانتینر جدید. مقدار پیش‌فرض false است.

در هر زمان می‌توانید podman ps را در شل دیگری اجرا کنید تا فهرستی از کانتینرهای در حال اجرا را ببینید. با دستور podman attach مجدداً به یک کانتینر جداشده متصل شوید.

هنگام اتصال از طریق حالت tty، با استفاده از توالی کلیدهای قابل تنظیم از کانتینر جدا شوید (و بگذارید در حال اجرا بماند). توالی پیش‌فرض ctrl-p,ctrl-q است. توالی کلیدها را با استفاده از گزینه --detach-keys مشخص کنید، یا آن را در فایل containers.conf پیکربندی نمایید؛ برای اطلاعات بیشتر به containers.conf(5) مراجعه کنید.

--detach-keys=sequence

توالی کلیدها را برای جدا شدن از کانتینر مشخص می‌کند. قالب آن یک نویسه تکی [a-Z] یا یک یا چند نویسه ctrl-<value> است که در آن <value> یکی از این موارد است: a-z، @، ^، [، , یا _. مشخص کردن "" این ویژگی را غیرفعال می‌کند. مقدار پیش‌فرض ctrl-p,ctrl-q است.

این گزینه همچنین می‌تواند در فایل containers.conf(5) تنظیم شود.

--device=host-device[:container-device][:permissions]

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

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

نکته: اگر host-device یک پیوند نمادین باشد ابتدا تحلیل می‌شود. کانتینر تنها شماره‌های اصلی و فرعی دستگاه میزبان را ذخیره می‌کند.

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

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

$ sudo setsebool -P container_use_devices=true

نکته: اگر کاربر تنها از طریق یک گروه دارای حقوق دسترسی باشد، دسترسی به دستگاه از داخل کانتینر بدون ریشه با شکست مواجه می‌شود. از پرچم --group-add keep-groups برای انتقال دسترسی گروه تکمیلی کاربر به داخل کانتینر استفاده کنید.

--device-cgroup-rule="type major:minor mode"

افزودن قاعده به لیست دستگاه‌های مجاز cgroup. انتظار می‌رود این قاعده در قالبی باشد که در مستندات کرنل لینوکس admin-guide/cgroup-v1/devices مشخص شده است: - type: به صورت a (همه)، c (کاراکتری)، یا b (بلوکی)؛ - major و minor: یا یک عدد، یا * برای همه؛ - mode: ترکیبی از r (خواندن)، w (نوشتن)، و m (mknod(2)).

--device-read-bps=path:rate

محدود کردن نرخ خواندن (بر حسب بایت بر ثانیه) از یک دستگاه (مانند --device-read-bps=/dev/sda:1mb).

در برخی سیستم‌ها، تغییر محدودیت‌های منابع ممکن است برای کاربران غیر ریشه مجاز نباشد. برای جزئیات بیشتر به لینک زیر مراجعه کنید: https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

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

--device-read-iops=path:rate

محدود کردن نرخ خواندن (بر حسب عملیات IO در ثانیه) از یک دستگاه (مانند --device-read-iops=/dev/sda:1000).

در برخی سیستم‌ها، تغییر محدودیت‌های منابع ممکن است برای کاربران غیر ریشه مجاز نباشد. برای جزئیات بیشتر به لینک زیر مراجعه کنید: https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

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

--device-write-bps=path:rate

محدود کردن نرخ نوشتن (بر حسب بایت بر ثانیه) روی یک دستگاه (مانند --device-write-bps=/dev/sda:1mb).

در برخی سیستم‌ها، تغییر محدودیت‌های منابع ممکن است برای کاربران غیر ریشه مجاز نباشد. برای جزئیات بیشتر به لینک زیر مراجعه کنید: https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

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

--device-write-iops=path:rate

محدود کردن نرخ نوشتن (بر حسب عملیات IO در ثانیه) روی یک دستگاه (مانند --device-write-iops=/dev/sda:1000).

در برخی سیستم‌ها، تغییر محدودیت‌های منابع ممکن است برای کاربران غیر ریشه مجاز نباشد. برای جزئیات بیشتر به لینک زیر مراجعه کنید: https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

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

--disable-content-trust

این یک گزینه مخصوص داکر برای غیرفعال کردن اعتبارسنجی ایمیج در رجیستری کانتینر است و توسط پادمن پشتیبانی نمی‌شود. این گزینه یک دستور بی‌اثر (NOOP) است و صرفاً برای سازگاری اسکریپت‌ها ارائه شده است.

--dns=ipaddr

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

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

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

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

این گزینه نمی‌تواند با --network که روی none یا container:id تنظیم شده ترکیب شود.

--dns-option=option

تنظیم گزینه‌های سفارشی DNS. در صورت استفاده از --dns-option همراه با --network تنظیم‌شده روی none یا container:id نامعتبر است.

--dns-search=domain

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

--entrypoint="command" | '["command", arg1 , ...]'

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

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

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

--env, -e=env

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

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

برای اولویت و مثال‌ها به بخش محیط مراجعه کنید.

--env-file=file

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

برای اولویت و مثال‌ها به بخش محیط مراجعه کنید.

--env-host

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

--env-merge=env

پیش‌پردازش متغیرهای محیطی پیش‌فرض برای کانتینرها. برای مثال اگر ایمیج شامل متغیر محیطی hello=world باشد، کاربر می‌تواند با استفاده از --env-merge hello=${hello}-some آن را پیش‌پردازش کند تا مقدار جدید hello=world-some باشد.

لطفاً توجه داشته باشید که اگر متغیر محیطی hello در ایمیج وجود نداشته باشد، با یک رشته خالی جایگزین می‌شود و استفاده از --env-merge hello=${hello}-some منجر به مقدار جدید hello=-some خواهد شد (به علامت - در ابتدا دقت کنید).

--expose=port[/protocol]

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

--gidmap=[flags]container_gid:from_gid[:amount]

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

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

--gpus=ENTRY

شروع کانتینر با پشتیبانی از GPU. که در آن ENTRY می‌تواند all برای درخواست همه GPUها یا یک شناسه ویژه سازنده باشد. در حال حاضر دستگاه‌های NVIDIA و AMD پشتیبانی می‌شوند. اگر هر دو دستگاه‌های NVIDIA و AMD وجود داشته باشند، دستگاه‌های NVIDIA اولویت خواهند داشت، و باید یک نام دستگاه CDI با استفاده از پرچم --device مشخص شود تا مجموعه‌ای از GPUها از یک سازنده خاص درخواست شود.

--group-add=group | keep-groups

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

•

keep-groups یک پرچم ویژه است که به پادمن دستور می‌دهد دسترسی گروه‌های تکمیلی را حفظ کند.

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

--group-entry=ENTRY

سفارشی‌سازی ورودی نوشته‌شده در فایل /etc/group درون کانتینر هنگام استفاده از --user.

متغیرهای $GROUPNAME، $GID و $USERLIST در زمان اجرا به طور خودکار با مقدار خود جایگزین می‌شوند.

--health-cmd="command" | '["command", arg1 , ...]'

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

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

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

--health-interval=interval

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

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

--health-log-destination=directory_path

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

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

--health-max-log-count=number of stored logs

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

--health-max-log-size=size of stored logs

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

--health-on-failure=action

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

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

--health-retries=retries

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

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

--health-start-period=period

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

نکته: دستور بررسی سلامت به محض راه‌اندازی کانتینر اجرا می‌شود؛ اگر بررسی موفقیت‌آمیز باشد وضعیت سلامت کانتینر به healthy به‌روزرسانی می‌شود. با این حال اگر ناموفق باشد، وضعیت سلامت تا زمان موفقیت بررسی یا پایان یافتن زمان --health-start-period در حالت starting باقی می‌ماند. اگر دستور بررسی سلامت پس از اتمام زمان --health-start-period ناموفق شود، وضعیت به unhealthy تغییر می‌یابد. دستور بررسی سلامت به صورت دوره‌ای بر اساس مقدار --health-interval اجرا می‌شود.

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

--health-startup-cmd="command" | '["command", arg1 , ...]'

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

--health-startup-interval=interval

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

--health-startup-retries=retries

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

--health-startup-success=retries

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

--health-startup-timeout=timeout

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

--health-timeout=timeout

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

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

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

--help

چاپ راهنمای استفاده از دستور.

--hostname, -h=name

تنظیم نام میزبان (hostname) درون کانتینر.

این گزینه تنها با فضای نام UTS خصوصی --uts=private (پیش‌فرض) قابل استفاده است. اگر --pod داده شود و پاد فضای نام UTS یکسانی را به اشتراک بگذارد (پیش‌فرض)، نام میزبان پاد استفاده می‌شود. نام میزبان داده‌شده همچنین با استفاده از نشانی IP اصلی کانتینر به فایل /etc/hosts اضافه می‌شود (گزینه --add-host را نیز ببینید).

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

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

--hosts-file=path | none | image

فایل پایه برای ایجاد فایل /etc/hosts درون کانتینر. این باید یا یک مسیر مطلق به یک فایل روی سیستم میزبان باشد، یا یکی از پرچم‌های ویژه زیر:
"" از پیکربندی base_hosts_file در containers.conf پیروی می‌کند (پیش‌فرض)
none از فایل پایه استفاده نمی‌کند (یعنی با یک فایل خالی شروع می‌کند)
image از فایل /etc/hosts ایمیج کانتینر به عنوان فایل پایه استفاده می‌کند

--hostuser=name

افزودن یک حساب کاربری به etc/passwd/ از میزبان به کانتینر. نام کاربری یا UID باید روی سیستم میزبان وجود داشته باشد.

--http-proxy

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

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

--image-volume=bind | tmpfs | ignore

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

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

--init

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

--init-path=path

مسیر به باینری container-init.

--interactive, -i

هنگامی که روی true تنظیم شود، stdin را برای فرایند درون کانتینر در دسترس قرار می‌دهد. اگر false باشد، stdin فرایند درون کانتینر خالی بوده و بلافاصله بسته می‌شود.

اگر کانتینر متصل باشد (attached)، ورودی استاندارد (stdin) به فرایند کانتینر پایپ می‌شود. اگر جدا باشد (detached)، خواندن stdin تا زمان اتصال بعدی مسدود (block) خواهد شد.

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

--ip=IPv4

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

برای تعیین چندین نشانی IP استاتیک به ازای هر کانتینر، از گزینه --network همراه با چندین مقدار ip جداشده با کاما استفاده کنید:

--network mynet:ip=10.88.0.10,ip=10.88.0.11,ip=10.88.0.12

این کار چندین نشانی IPv4 استاتیک را به همان رابط شبکه اختصاص می‌دهد.

شبکه‌های چند زیرشبکه‌ای: هنگامی که یک شبکه دارای چندین زیرشبکه است، می‌توانید IPهایی از زیرشبکه‌های مختلف را به همان کانتینر اختصاص دهید. IPها روی یک رابط شبکه اعمال می‌شوند که IP اول به عنوان آدرس اصلی و IPهای بعدی به عنوان آدرس‌های ثانویه خواهند بود.

ترتیب تخصیص IP: برای شبکه‌های چند زیرشبکه‌ای، IPها بر اساس زیرشبکه مربوطه‌شان گروه‌بندی و مرتب می‌شوند، با پیروی از ترتیبی که زیرشبکه‌ها در طول ساخت شبکه (از طریق پرچم‌های --subnet) تعریف شده‌اند. ترتیبی که IPها را در دستور مشخص می‌کنید تاثیری بر ترتیب تخصیص نهایی ندارد. برای مثال:

podman network create --subnet 10.89.0.0/24 --subnet 10.90.0.0/24 mynet
podman run --network mynet:ip=10.90.0.20,ip=10.89.0.10,ip=10.89.0.11 alpine

منجر به IPهای مرتب‌شده بر اساس زیرشبکه می‌شود: 10.89.0.10 (اصلی)، 10.89.0.11 (ثانویه)، 10.90.0.20 (ثانویه)، زیرا 10.89.0.0/24 ابتدا تعریف شده بود.

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

مثال با شبکه چند زیرشبکه‌ای:

podman network create --subnet 10.89.0.0/24 --subnet 10.90.0.0/24 mynet
podman run --network mynet:ip=10.89.0.10,ip=10.90.0.20 alpine

این دستور eth0 را با 10.89.0.10 (اصلی) و 10.90.0.20 (ثانویه) پیکربندی می‌کند.

--ip6=IPv6

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

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

--ipc=ipc

تنظیم حالت فضای نام IPC برای کانتینر. پیش‌فرض ایجاد یک فضای نام IPC خصوصی است.

• "": استفاده از پیش‌فرض پادمن، تعریف‌شده در containers.conf.
• container:id: استفاده مجدد از حافظه اشتراکی، سمافورها و صف‌های پیام یک کانتینر دیگر.
• host: استفاده از حافظه اشتراکی، سمافورها و صف‌های پیام میزبان درون کانتینر. نکته: حالت host به کانتینر دسترسی کامل به حافظه اشتراکی محلی می‌دهد و بنابراین ناامن تلقی می‌شود.
• none: فضای نام IPC خصوصی، بدون مانت شدن dev/shm/.
• ns:path: مسیر به فضای نام IPC برای پیوستن.
• private: فضای نام IPC خصوصی.
• shareable: فضای نام IPC خصوصی با امکان اشتراک‌گذاری آن با کانتینرهای دیگر.

--label, -l=key=value

افزودن فراداده (metadata) به یک کانتینر.

--label-file=file

خواندن یک فایل حاوی برچسب‌ها با جداکننده خط.

--link-local-ip=ip

پیاده‌سازی نشده است.

--log-driver=driver

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

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

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

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

درایور passthrough-tty مشابه passthrough است به جز اینکه اگر کاربر واقعاً بخواهد اجازه استفاده از آن روی TTY را نیز می‌دهد.

--log-opt=name=value

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

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

path: تعیین مسیر به فایل گزارش
(مانند --log-opt path=/var/log/container/mycontainer.json)؛

max-size: تعیین حداکثر اندازه فایل گزارش
(مانند --log-opt max-size=10mb)؛

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

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

--mac-address=address

آدرس MAC رابط شبکه کانتینر (مانند 92:d0:c6:0a:29:33). این گزینه تنها زمانی قابل استفاده است که کانتینر فقط به یک شبکه پیوسته باشد — یعنی --network=network-name حداکثر یک بار استفاده شده باشد — و کانتینر از طریق --network=container:id به فضای نام شبکه کانتینر دیگری ملحق نشده باشد.

به یاد داشته باشید که آدرس MAC در یک شبکه اترنت باید یکتا باشد. نشانی link-local در IPv6 بر اساس آدرس MAC دستگاه طبق RFC4862 تعیین می‌شود.

برای تعیین چندین نشانی MAC استاتیک به ازای هر کانتینر، چندین شبکه را با استفاده از گزینه --network همراه با نشانی MAC استاتیک با استفاده از حالت mac برای آن گزینه تنظیم کنید.

--memory, -m=number[unit]

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

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

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

--memory-reservation=number[unit]

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

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

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

--memory-swap=number[unit]

مقدار محدودیتی برابر با حافظه به علاوه سواپ (swap). یک واحد unit می‌تواند b (بایت)، k (کیبی‌بایت)، m (مبی‌بایت) یا g (گیبی‌بایت) باشد.

باید همراه با پرچم -m (--memory) استفاده شود. مقدار آرگومان باید بزرگتر از مقدار -m (--memory) باشد. به طور پیش‌فرض، روی دو برابر مقدار --memory تنظیم می‌شود.

مقدار number را روی -1 تنظیم کنید تا swap نامحدود فعال شود.

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

--memory-swappiness=number

تنظیم رفتار swappiness حافظه کانتینر. یک عدد صحیح بین 0 و 100 را می‌پذیرد.

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

--mount=type=TYPE,TYPE-SPECIFIC-OPTION[,...]

اتصال یک مانت سیستم‌فایل به کانتینر.

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

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

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

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

گزینه‌های ویژه type=artifact:

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

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

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

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

گزینه‌های ویژه type=volume:

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

گزینه‌های ویژه type=image:

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

گزینه‌های ویژه bind و glob:

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

گزینه‌های ویژه type=tmpfs و ramfs:

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

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

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

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

•

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

گزینه‌های ویژه type=devpts:

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

مثال‌ها:

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

--name=name

--name=name

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

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

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

پادمن یک UUID برای هر کانتینر ایجاد می‌کند، و اگر هیچ نامی با استفاده از --name به کانتینر اختصاص داده نشود، پادمن یک نام تصادفی مانند exciting_chebyshev (صفت_اسم، سازگار با داکر) تولید می‌کند. الزامی نیست که نام کانتینرها نام‌های میزبان یا دامنه‌های معتبر باشند. زیرخط‌ها و نویسه‌های دیگری که طبق قوانین نام‌گذاری مجاز هستند پذیرفته می‌شوند. در شبکه‌های پادمن با DNS فعال، تحلیل نام کانتینر به کانتینر همچنان از نام داده‌شده استفاده می‌کند، برای مثال exciting_chebyshev. این نام به عنوان روشی انسان‌دوستانه‌تر برای شناسایی کانتینرها مفید است. این ویژگی هم برای کانتینرهای پس‌زمینه و هم پیش‌زمینه کار می‌کند. نام کانتینر همچنین با استفاده از نشانی IP اصلی کانتینر به فایل /etc/hosts اضافه می‌شود (گزینه --add-host را نیز ببینید).

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

--network=mode, --net

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

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

•

bridge[:OPTIONS,...]: ایجاد یک پشته شبکه روی پل پیش‌فرض. این پیش‌فرض کانتینرهای rootful است. گزینه‌های اضافی زیر را می‌توان مشخص کرد:

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

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

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

• <network name or ID>[:OPTIONS,...]: اتصال به یک شبکه تعریف‌شده توسط کاربر؛ این نام یا شناسه شبکه‌ای است که با podman network create ساخته شده است. می‌توان همان گزینه‌های توضیح‌داده‌شده در حالت bridge بالا را مشخص کرد. از گزینه --network چندین بار برای مشخص کردن شبکه‌های بیشتر استفاده کنید.
  برای سازگاری با نسخه‌های قبلی، می‌توان شبکه‌های جداشده با کاما را در آرگومان اول --network مشخص کرد، با این حال این کار مانع از استفاده از گزینه‌های بخش bridge بالا می‌شود.
• none: ایجاد فضای نام شبکه بدون پیکربندی رابط‌های شبکه، بنابراین کانتینر فاقد اتصال شبکه خواهد بود.
• container:id: استفاده مجدد از پشته شبکه یک کانتینر دیگر.
• host: استفاده از فضای نام شبکه میزبان برای کانتینر به جای ایجاد یک فضای نام ایزوله. هشدار: این گزینه به کانتینر دسترسی کامل به سوکت‌های انتزاعی دامین یونیکس و سوکت‌های TCP/UDP متصل به localhost را می‌دهد و استفاده از آن ممکن است مخاطره امنیتی تلقی شود.
• ns:path: مسیر به فضای نام شبکه برای پیوستن.
• private: ایجاد یک فضای نام جدید برای کانتینر. این حالت از bridge برای کانتینرهای rootful و از pasta برای rootless استفاده می‌کند.
• pasta[:OPTIONS,...]: استفاده از pasta(1) برای ایجاد یک پشته شبکه در حالت کاربر (user-mode).
  این حالت پیش‌فرض برای کانتینرهای بدون ریشه است و تنها در حالت بدون ریشه پشتیبانی می‌شود.
  به طور پیش‌فرض، آدرس‌های IPv4 و IPv6 و مسیرها و همچنین نام رابط پاد از میزبان کپی می‌شوند. فوروارد پورت نشانی IP اصلی مبدا را حفظ می‌کند. گزینه‌های شرح‌داده‌شده در pasta(1) را می‌توان به صورت آرگومان‌های جداشده با کاما تعیین کرد.
  از نظر گزینه‌های pasta(1)، پرچم --config-net به صورت پیش‌فرض داده می‌شود تا هنگام راه‌اندازی کانتینر شبکه پیکربندی شود، و --no-map-gw نیز برای اجتناب از دسترسی مستقیم از کانتینر به میزبان با نشانی گیت‌وی پیش‌فرض است. مورد اخیر را می‌توان با انتقال --map-gw در گزینه‌های اختصاصی pasta بازنویسی کرد.
  برای یکپارچگی بهتر با مدیریت DNS، گزینه --dns-forward 169.254.1.1 به طور پیش‌فرض منتقل می‌شود و این نشانی به عنوان اولین تحلیل‌گر به resolv.conf(5) اضافه می‌گردد. در صورت نیاز به IP دیگر، ارسال صریح --dns-forward ممکن است.
  برای کارکرد ورودی host.containers.internal در /etc/hosts و اجازه اتصال به میزبان، --map-guest-addr 169.254.1.2 به طور پیش‌فرض منتقل می‌شود.
  همچنین در صورتی که هیچ فورواردینگی برای درگاه‌های TCP یا UDP از میزبان به کانتینر تنظیم نشده باشد، گزینه‌های -t none و -u none منتقل می‌شوند تا فوروارد خودکار پورت بر اساس پورت‌های متصل غیرفعال شود. به همین ترتیب -T none و -U none برای غیرفعال کردن همین عملکرد از کانتینر به میزبان ارائه می‌شوند.
  تمام گزینه‌ها را می‌توان در containers.conf(5) نیز تنظیم کرد؛ کلید pasta_options را ذیل بخش network در آن فایل ببینید.
  چند مثال:

در صورت استفاده از --dns، --dns-option یا --dns-search با --network تنظیم‌شده روی none یا container:id نامعتبر است.

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

--network-alias=alias

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

--no-healthcheck

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

--no-hostname

ایجاد نکردن فایل /etc/hostname در کانتینرها.

به طور پیش‌فرض پادمن فایل /etc/hostname را مدیریت کرده و نام میزبان کانتینر را اضافه می‌کند. هنگامی که --no-hostname تنظیم شود، فایل /etc/hostname ایمیج بدون تغییر حفظ می‌شود.

--no-hosts

عدم دستکاری فایل /etc/hosts درون کانتینر.

پادمن به صورت پیش‌فرض کنترل فایل /etc/hosts کانتینر را در دست گرفته و ورودی‌هایی برای نام کانتینر (گزینه --name)، نام میزبان (گزینه --hostname)، میزبان‌های داخلی host.containers.internal و host.docker.internal و هر نام میزبان ارائه‌شده با گزینه --add-host اضافه می‌کند. برای جزئیات به گزینه --add-host مراجعه کنید. دادن --no-hosts این قابلیت را غیرفعال می‌کند تا فایل /etc/hosts ایمیج دست‌نخورده باقی بماند. همین نتیجه را می‌توان به صورت سراسری با تنظیم no_hosts=true در containers.conf به دست آورد.

این گزینه با --add-host تداخل دارد.

--oom-kill-disable

غیرفعال کردن یا نکردن OOM Killer برای کانتینر.

این پرچم در سیستم‌های با cgroups V2 پشتیبانی نمی‌شود.

--oom-score-adj=num

تنظیم ترجیحات OOM سیستم میزبان برای کانتینرها (مقادیر بین -1000 تا 1000 را می‌پذیرد).

هنگام اجرا در حالت بدون ریشه، مقدار مشخص‌شده نمی‌تواند کمتر از oom_score_adj فرایند فعلی باشد. در این حالت، oom-score-adj به مقدار فرایند فعلی محدود می‌شود.

--os=OS

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

--passwd

اجازه دادن به پادمن برای افزودن ورودی‌ها به etc/passwd/ و etc/group/ در صورت استفاده همراه با گزینه --user. این گزینه برای بازنویسی تنظیمات کاربر ارائه‌شده توسط پادمن به نفع پیکربندی‌های نقطه ورود مانند libnss-extrausers به کار می‌رود.

--passwd-entry=ENTRY

سفارشی‌سازی ورودی نوشته‌شده در فایل /etc/passwd درون کانتینر هنگام استفاده از --passwd.

متغیرهای $USERNAME، $UID، $GID، $NAME و $HOME در زمان اجرا به طور خودکار با مقدار خود جایگزین می‌شوند.

--personality=persona

تعیین دامنه اجرا از طریق تابع personality(2) لینوکس.

--pid=mode

تنظیم حالت فضای نام PID برای کانتینر. پیش‌فرض ایجاد یک فضای نام PID خصوصی برای کانتینر است.

• container:id: پیوستن به فضای نام PID کانتینر دیگر؛
• host: استفاده از فضای نام PID میزبان برای کانتینر. توجه داشته باشید که حالت host دسترسی کامل به PIDهای محلی را به کانتینر می‌دهد و ناامن تلقی می‌شود؛
• ns:path: پیوستن به فضای نام PID مشخص‌شده؛
• private: ایجاد یک فضای نام جدید برای کانتینر (پیش‌فرض).

--pidfile=path

هنگامی که مکان pidfile مشخص شود، PID فرایند کانتینر در فایل نوشته می‌شود. (این گزینه در کلاینت ریموت پادمن، از جمله ماشین‌های مک و ویندوز (به استثنای WSL2) در دسترس نیست). اگر گزینه pidfile مشخص نشود، PID فرایند کانتینر در مسیر /run/containers/storage/${storage-driver}-containers/$CID/userdata/pidfile نوشته می‌شود.

پس از شروع کانتینر، مکان pidfile را می‌توان با دستور podman inspect مشاهده کرد:

$ podman inspect --format '{{ .PidFile }}' $CID
/run/containers/storage/${storage-driver}-containers/$CID/userdata/pidfile

--pids-limit=limit

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

--platform=OS/ARCH

مشخص کردن پلتفرم برای انتخاب ایمیج (با arch-- و os-- تداخل دارد). گزینه --platform می‌تواند برای بازنویسی معماری و سیستم‌عامل فعلی استفاده شود. مگر اینکه بازنویسی شود، جستجوهای بعدی همان ایمیج در حافظه محلی با این پلتفرم مطابقت خواهند داشت، صرف‌نظر از میزبان.

--pod=name

اجرای کانتینر در یک پاد موجود. اگر نام پاد دارای پیشوند new: باشد، پادمن به صورت خودکار پاد را ایجاد می‌کند. برای ایجاد یک پاد با گزینه‌های دقیق‌تر، پیش از ایجاد کانتینر از دستور podman pod create استفاده کنید. هنگامی که کانتینر با پادی شامل infra-container اجرا شود، ابتدا infra-container راه‌اندازی می‌شود.

--pod-id-file=file

اجرای کانتینر در یک پاد موجود و خواندن شناسه پاد از file مشخص‌شده. هنگامی که کانتینر درون پادی دارای یک infra-container اجرا شود، ابتدا infra-container شروع می‌شود.

--preserve-fd=FD1[,FD2,...]

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

(این گزینه در کلاینت ریموت پادمن، از جمله ماشین‌های مک و ویندوز (به استثنای WSL2) در دسترس نیست)

--preserve-fds=N

انتقال N توصیف‌کننده فایل اضافی به فرایند (علاوه بر 0، 1 و 2). تعداد کل توصیف‌کننده‌های فایل 3+N است. (این گزینه در کلاینت ریموت پادمن، از جمله ماشین‌های مک و ویندوز (به استثنای WSL2) در دسترس نیست)

--privileged

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

به طور پیش‌فرض کانتینرهای پادمن فاقد امتیاز هستند (=false) و برای نمونه نمی‌توانند بخش‌هایی از سیستم‌عامل را دستکاری کنند. این به این دلیل است که کانتینر به صورت پیش‌فرض تنها دسترسی محدودی به دستگاه‌ها دارد. به یک کانتینر "با امتیاز" همان دسترسی به دستگاه‌ها داده می‌شود که کاربر راه‌انداز کانتینر دارد، به استثنای کنسول‌های مجازی (/dev/tty\d+) هنگام اجرا در حالت systemd (--systemd=always).

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

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

--publish, -p=[[hostIP:][hostPort]:]containerPort[/protocol]

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

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

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

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

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

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

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

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

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

نکته: اگر کانتینر درون یک پاد اجرا شود، نیازی به انتشار درگاه برای کانتینرهای داخل پاد نیست. درگاه تنها باید توسط خود پاد منتشر شود. پشته‌های شبکه پاد مانند پشته شبکه روی میزبان عمل می‌کنند — به این معنی که انواع کانتینرها در پاد و برنامه‌های درون کانتینر همگی در یک رابط شبکه، آدرس IP و درگاه‌های مرتبط مشترک هستند. اگر یک کانتینر به درگاهی متصل شود، هیچ کانتینر دیگری در داخل پاد نمی‌تواند در زمان استفاده از آن درگاه استفاده کند. کانتینرهای درون پاد همچنین می‌توانند از طریق localhost ارتباط برقرار کنند، به این صورت که یک کانتینر به localhost در پاد متصل شود و دیگری به آن درگاه متصل گردد.

--publish-all, -P

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

هنگامی که روی true تنظیم شود، تمام درگاه‌های اکسپوزشده را روی رابط‌های میزبان منتشر می‌کند. اگر کاربر از -P (یا -p) استفاده کند، پادمن درگاه اکسپوزشده را روی میزبان در دسترس قرار داده و درگاه‌ها برای هر کلاینتی که به میزبان دسترسی داشته باشد قابل دسترسی خواهند بود.

هنگام استفاده از این گزینه، پادمن هر درگاه اکسپوزشده را به یک درگاه تصادفی روی میزبان درون یک بازه درگاه موقت (ephemeral) تعریف‌شده توسط /proc/sys/net/ipv4/ip_local_port_range متصل می‌کند. برای یافتن نگاشت میان درگاه‌های میزبان و درگاه‌های اکسپوزشده، از podman port استفاده کنید.

--pull=policy

سیاست واکشی (Pull) ایمیج. پیش‌فرض missing است.

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

--quiet, -q

پنهان‌سازی خروجی اطلاعات هنگام واکشی ایمیج‌ها.

--rdt-class=intel-rdt-class-of-service

کلاس سرویس (CLOS یا COS) را برای اجرای کانتینر تنظیم می‌کند. بر اساس قابلیت فناوری تخصیص حافظه کش (CAT) که بخشی از مجموعه قابلیت‌های فناوری مدیر منبع اینتل (RDT) است، تمام فرایندهای کانتینر درون COS از پیش پیکربندی‌شده اجرا می‌شوند که بخشی از حافظه کش را نشان می‌دهد. COS باید با استفاده از یک فایل‌سیستم شبه‌واقعی (که معمولاً در /sys/fs/resctrl سوار می‌شود) که توسط درایور هسته resctrl فراهم می‌گردد ایجاد و پیکربندی شود. انتساب کانتینر به یک COS نیازمند امتیازات ریشه است و بنابراین در محیط‌های بدون ریشه کار نمی‌کند. در حال حاضر این قابلیت تنها با زمان اجرای runc پشتیبانی می‌شود. برای اطلاعات بیشتر در خصوص ایجاد یک COS پیش از اختصاص کانتینر به آن، به ⟨https://docs.kernel.org/arch/x86/resctrl.html⟩ مراجعه کنید.

--read-only

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

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

--read-only-tmpfs

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

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

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

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

--replace

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

--requires=container

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

--restart=policy

سیاست راه‌اندازی مجدد برای اعمال پس از خروج کانتینرها. اگر کانتینر از طریق دستورات podman kill یا podman stop متوقف شده باشد، سیاست راه‌اندازی مجدد اثری نخواهد داشت.

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

• no : کانتینرها پس از خروج دوباره راه‌اندازی نشوند
• never : مترادف برای no؛ کانتینرها پس از خروج دوباره راه‌اندازی نشوند
• on-failure[:max_retries] : راه‌اندازی مجدد کانتینرها در صورتی که با کد خروج غیرصفر خارج شوند؛ تلاش مجدد نامحدود است یا تا رسیدن به سقف اختیاری max_retries تکرار می‌شود
• always : راه‌اندازی مجدد کانتینرها هنگام خروج بدون توجه به وضعیت آن، با تلاش مجدد نامحدود
• unless-stopped : راه‌اندازی مجدد کانتینرها هنگام خروج، مگر اینکه کانتینر صریحاً توسط کاربر متوقف شده باشد. پس از راه‌اندازی مجدد سیستم، کانتینرهای دارای این سیاست توسط podman-restart.service تنها در صورتی دوباره راه‌اندازی می‌شوند که پیش از ریبوت سیستم صریحاً توسط کاربر متوقف نشده باشند. این با always تفاوت دارد که کانتینرها را پس از ریبوت سیستم بدون توجه به اینکه توسط کاربر متوقف شده بودند یا خیر، راه‌اندازی می‌کند

پادمن یک فایل واحد systemd به نام podman-restart.service ارائه می‌دهد که کانتینرها را پس از ریبوت سیستم دوباره راه‌اندازی می‌کند.

هنگام اجرای کانتینرها در سرویس‌های systemd، از قابلیت restart ارائه‌شده توسط خود systemd استفاده کنید. به عبارت دیگر، از این گزینه در واحدهای کانتینری استفاده نکنید؛ در عوض دستور Restart= را در بخش [Service] تنظیم نمایید. به podman-systemd.unit(5) و systemd.service(5) مراجعه کنید.

--retry=attempts

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

--retry-delay=duration

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

--rm

حذف خودکار کانتینر و هرگونه حجم ناشناس (unnamed) مرتبط با کانتینر پس از خروج آن. پیش‌فرض false است.

--rmi

پس از خروج کانتینر، ایمیج آن را حذف کن مگر اینکه کانتینر دیگری در حال استفاده از آن باشد. این گزینه متضمن --rm روی کانتینر جدید است. پیش‌فرض false است.

--rootfs

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

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

مانت‌های Overlay Rootfs

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

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

idmap

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

--sdnotify=container | conmon | healthy | ignore

نحوه استفاده از NOTIFY_SOCKET که توسط systemd و با Type=notify ارسال می‌شود را مشخص می‌کند.

مقدار پیش‌فرض container است، به این معنی که به زمان اجرای OCI اجازه می‌دهد سوکت را به کانتینر پروکسی کند تا اعلان‌های آمادگی را دریافت نماید. پادمن مقدار MAINPID را روی pid فرایند conmon تنظیم می‌کند. گزینه conmon مقدار MAINPID را روی pid فرایند conmon تنظیم کرده و پس از راه‌اندازی کانتینر پیام READY را ارسال می‌کند. سوکت هرگز به زمان اجرا یا کانتینر منتقل نمی‌شود. گزینه healthy مقدار MAINPID را روی pid فرایند conmon تنظیم کرده و زمانی که کانتینر سالم شد پیام READY را می‌فرستد؛ نیازمند تنظیم یک بررسی سلامت (healthcheck) است. سوکت هرگز به زمان اجرا یا کانتینر منتقل نمی‌شود. گزینه ignore متغیر NOTIFY_SOCKET را از محیط برای خود و فرایندهای فرزند حذف می‌کند، برای شرایطی که فرایندی بالاتر از پادمن از NOTIFY_SOCKET استفاده کرده و پادمن از آن استفاده نمی‌کند.

--seccomp-policy=policy

سیاست انتخاب نمایه seccomp را مشخص می‌کند. اگر روی image تنظیم شود، پادمن به دنبال برچسب "io.containers.seccomp.profile" در پیکربندی ایمیج کانتینر می‌گردد و از مقدار آن به عنوان نمایه seccomp استفاده می‌کند. در غیر این صورت، پادمن از سیاست default پیروی کرده و نمایه پیش‌فرض را اعمال می‌کند، مگر اینکه از طریق --security-opt seccomp مطابق توضیحات زیر جور دیگری مشخص شده باشد.

توجه داشته باشید که این ویژگی آزمایشی است و ممکن است در آینده تغییر کند.

--secret=secret[,opt=opt ...]

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

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

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

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

گزینه‌های سکرت

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

مثال‌ها

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

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

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

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

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

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

--security-opt=option

گزینه‌های امنیتی

• apparmor=unconfined : غیرفعال کردن محدودسازی apparmor برای کانتینر
• apparmor=alternate-profile : تنظیم نمایه محدودسازی apparmor برای کانتینر
• label=user:USER: تنظیم برچسب کاربر برای فرایندهای کانتینر
• label=role:ROLE: تنظیم برچسب نقش برای فرایندهای کانتینر
• label=type:TYPE: تنظیم برچسب نوع فرایند برای فرایندهای کانتینر
• label=level:LEVEL: تنظیم برچسب سطح برای فرایندهای کانتینر
• label=filetype:TYPE: تنظیم برچسب نوع فایل برای فایل‌های کانتینر
• label=disable: غیرفعال کردن جداسازی برچسب‌ها برای کانتینر

نکته: برچسب‌گذاری را می‌توان برای تمام کانتینرها با تنظیم label=false در فایل containers.conf (/etc/containers/containers.conf یا $HOME/.config/containers/containers.conf) غیرفعال کرد.

• label=nested: اجازه اعمال تغییرات SELinux را درون کانتینر می‌دهد. تا زمانی که سیاست SELinux اجازه دهد، کانتینرها مجاز به اصلاح برچسب‌های SELinux روی فایل‌ها و فرایندها هستند. بدون nested، کانتینرها SELinux را حتی در صورت فعال بودن روی میزبان غیرفعال می‌بینند و از تنظیم هرگونه برچسب منع می‌شوند.
• mask=/path/1:/path/2: مسیرهای ماسک‌شده که با دونقطه از هم جدا شده‌اند. دسترسی به یک مسیر ماسک‌شده درون کانتینر امکان‌پذیر نیست.
• no-new-privileges: جلوگیری از کسب امتیازات اضافی توسط فرایندهای کانتینر از طریق فراخوانی سیستمی execve(2) (برای نمونه از طریق بیت‌های setuid یا setgid، یا از طریق قابلیت‌های فایل). برنامه‌هایی که برای تغییر شناسه کاربری یا گروه به بیت‌های setuid/setgid متکی هستند دیگر قادر به انجام آن نخواهند بود و هرگونه قابلیت فایلی که به فایل اجرایی اضافه شود (مثلاً از طریق setcap) به مجموعه قابلیت‌های مجاز افزوده نخواهد شد. برای جزئیات بیشتر به: https://docs.kernel.org/userspace-api/no_new_privs.html مراجعه کنید.
• seccomp=unconfined: غیرفعال کردن محدودسازی seccomp برای کانتینر.
• seccomp=profile.json: فایل JSON مورد استفاده به عنوان فیلتر seccomp. توجه داشته باشید که انوتیشن io.podman.annotations.seccomp با مقدار مشخص‌شده تنظیم می‌شود همان‌طور که در podman inspect مشاهده می‌شود.
• proc-opts=OPTIONS : لیستی از گزینه‌های جداشده با کاما برای استفاده در مانت /proc. جزئیات بیشتر برای گزینه‌های ممکن مانت در صفحه راهنمای proc(5) آمده است.
• unmask=ALL یا /path/1:/path/2، یا مسیرهای بسط‌یافته شل (/proc/*): مسیرهایی برای لغو ماسک که با دونقطه جدا می‌شوند. اگر روی ALL تنظیم شود، ماسک تمام مسیرهایی که به طور پیش‌فرض ماسک یا فقط‌خواندنی شده‌اند لغو می‌شود. مسیرهای ماسک‌شده پیش‌فرض عبارتند از /proc/acpi, /proc/kcore, /proc/keys, /proc/latency_stats, /proc/sched_debug, /proc/scsi, /proc/timer_list, /proc/timer_stats, /sys/firmware, and /sys/fs/selinux, /sys/devices/virtual/powercap. مسیرهای پیش‌فرضی که فقط‌خواندنی هستند عبارتند از /proc/asound, /proc/bus, /proc/fs, /proc/irq, /proc/sys, /proc/sysrq-trigger, /sys/fs/cgroup.

نکته: برچسب‌گذاری را می‌توان برای تمام کانتینرها با تنظیم label=false در فایل containers.conf(5) غیرفعال کرد.

--shm-size=number[unit]

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

--shm-size-systemd=number[unit]

اندازه مانت‌های tmpfs اختصاصی systemd مانند /run، /run/lock، /var/log/journal و /tmp. یک unit می‌تواند b (بایت)، k (کیبی‌بایت)، m (مبی‌بایت)، یا g (گیبی‌بایت) باشد. اگر واحد حذف شود، سیستم از بایت استفاده می‌کند. اگر اندازه حذف شود، پیش‌فرض 64m است. هنگامی که size برابر با 0 باشد، میزان استفاده به ۵۰٪ حافظه در دسترس میزبان محدود می‌شود.

--sig-proxy

پروکسی کردن سیگنال‌های دریافتی به فرایند کانتینر. سیگنال‌های SIGCHLD، SIGURG، SIGSTOP و SIGKILL پروکسی نمی‌شوند.

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

--stop-signal=signal

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

--stop-timeout=seconds

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

--subgidname=name

اجرای کانتینر در یک فضای نام کاربری جدید با استفاده از نگاشت دارای name در فایل /etc/subgid. هنگام اجرای بدون ریشه (rootless)، کاربر به مجوزهای لازم برای استفاده از نگاشت نیاز دارد. به subgid(5) مراجعه کنید. این فلگ با --userns و --gidmap تداخل دارد. همراه با --gidmap به گونه‌ای عمل می‌کند که گویی --gidmap با تمام نگاشت‌های گروه name در /etc/subgid ارسال شده است.

--subuidname=name

اجرای کانتینر در یک فضای نام کاربری جدید با استفاده از نگاشت دارای name در فایل /etc/subuid. هنگام اجرای بدون ریشه (rootless)، کاربر به مجوزهای لازم برای استفاده از نگاشت نیاز دارد. به subuid(5) مراجعه کنید. این فلگ با --userns و --uidmap تداخل دارد. همراه با --uidmap به گونه‌ای عمل می‌کند که گویی --uidmap با تمام نگاشت‌های کاربر name در /etc/subuid ارسال شده است.

--sysctl=name=value

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

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

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

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

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

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

--systemd=true | false | always

اجرای کانتینر در حالت systemd. مقدار پیش‌فرض true است.

• مقدار true حالت systemd را تنها زمانی فعال می‌کند که دستور اجراشده درون کانتینر systemd، /usr/sbin/init، /sbin/init یا /usr/local/sbin/init باشد.
• مقدار false حالت systemd را غیرفعال می‌کند.
• مقدار always فعال بودن حالت systemd را تحمیل می‌کند.

اجرای کانتینر در حالت systemd تغییرات زیر را ایجاد می‌کند:

•

پادمن سیستم‌فایل‌های tmpfs را روی دایرکتوری‌های زیر سوار می‌کند

• پادمن سیگنال پیش‌فرض توقف را روی SIGRTMIN+3 تنظیم می‌کند.
• پادمن متغیر محیطی container_uuid را در کانتینر روی ۳۲ کاراکتر اول شناسه کانتینر تنظیم می‌کند.
• پادمن هنگام اجرا با --privileged کنسول‌های مجازی (/dev/tty\d+) را سوار نمی‌کند.
• در cgroup v2 مسیر /sys/fs/cgroup به صورت قابل‌نوشتن سوار می‌شود.

این به systemd اجازه می‌دهد درون یک کانتینر محدودشده بدون نیاز به هیچ تغییری اجرا شود.

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

setsebool -P container_manage_cgroup true

--timeout=seconds

حداکثر زمانی که یک کانتینر مجاز به اجرا است قبل از اینکه conmon سیگنال kill را برای آن بفرستد. به طور پیش‌فرض کانتینرها تا زمان خروج یا توقف توسط podman stop اجرا می‌شوند.

--tls-verify

الزام HTTPS و اعتبارسنجی گواهی‌ها هنگام تماس با رجیستری‌ها (پیش‌فرض: true). اگر صریحاً روی true تنظیم شود، اعتبارسنجی TLS انجام می‌شود. اگر روی false تنظیم شود، اعتبارسنجی TLS انجام نمی‌شود. اگر مشخص نشود، اعتبارسنجی TLS اعمال می‌شود مگر اینکه رجیستری هدف در containers-registries.conf(5) به عنوان یک رجیستری ناامن فهرست شده باشد.

--tmpfs=fs

ایجاد یک مانت tmpfs.

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

$ podman run -d --tmpfs /tmp:rw,size=787448k,mode=1777 my_image

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

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

$ podman run --volume myvolume:/data --tmpfs /data/sub:notmpcopyup my_image

--tty, -t

تخصیص یک شبه‌ترمینال (pseudo-TTY). پیش‌فرض false است.

هنگامی که روی true تنظیم شود، پادمن یک pseudo-tty اختصاص داده و به ورودی استاندارد کانتینر متصل می‌شود. این می‌تواند برای نمونه برای اجرای یک شل تعاملی یک‌بارمصرف استفاده شود.

نکته: فلگ --tty مانع از تغییر مسیر (redirection) خروجی استاندارد می‌شود. این فلگ STDOUT و STDERR را ترکیب می‌کند، می‌تواند کاراکترهای کنترلی درج کند، و پایپ‌ها را معلق سازد. این گزینه تنها در زمان اجرای تعاملی در ترمینال استفاده می‌شود. هنگام ارسال ورودی به پادمن، تنها از -i استفاده کنید نه -it.

echo "asdf" | podman run --rm -i someimage /bin/cat

--tz=timezone

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

--uidmap=[flags]container_uid:from_uid[:amount]

اجرای کانتینر در یک فضای نام کاربری جدید با استفاده از نگاشت UID ارائه‌شده. این گزینه با گزینه‌های --userns و --subuidname تداخل دارد. این گزینه روشی برای نگاشت UIDهای میزبان به UIDهای کانتینر فراهم می‌آورد. می‌تواند چندین بار برای نگاشت بازه‌های مختلف ارسال شود.

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

مقدار from_uid بر اساس کاربری است که دستور را اجرا می‌کند، اعم از کاربر ریشه‌دار یا بدون ریشه.

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

نگاشت‌های با ریشه (Rootful)

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

UID میزبان -> UID کانتینر

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

نگاشت‌های بدون ریشه (Rootless)

هنگامی که podman run توسط کاربر غیرممتاز (یعنی در حالت بدون ریشه) فراخوانی می‌شود، مقدار from_uid به عنوان "UID واسط" (intermediate UID) تفسیر می‌شود. در حالت بدون ریشه، UIDهای میزبان مستقیماً به UIDهای کانتینر نگاشت نمی‌شوند. در عوض نگاشت در دو مرحله صورت می‌گیرد:

UID میزبان -> UID واسط -> UID کانتینر

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

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

مرحله نخست نگاشت:

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

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

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

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

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

ارجاع به شناسه میزبان از فضای نام والد

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

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

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

گسترش نگاشت‌های قبلی

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

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

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

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

ارسال تنها یکی از گزینه‌های --uidmap یا --gidmap

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

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

podman run --gidmap "0:0:1000" --gidmap "g2000:2000:1"

از آنجا که هیچ --uidmap داده نشده است، مقدار --gidmap در --uidmap کپی می‌شود و دستوری معادل زیر ایجاد می‌کند:

podman run --gidmap "0:0:1000" --gidmap "2000:2000:1" --uidmap "0:0:1000"

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

نگاشت بدون ریشه GIDهای اضافی میزبان

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

این کار با دستور --gidmap "+gcontainer_gid:@host_gid" انجام می‌شود.

که در آن:

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

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

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

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

عدم وجود UIDهای زیرمجموعه

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

پادها (Pods)

گزینه --uidmap نمی‌تواند همراه با گزینه --pod فراخوانی شود زیرا uidmap را نمی‌توان در سطح کانتینر هنگامی که در پاد است تنظیم نمود.

--ulimit=option

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

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

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

مقدار -1 را برای حد نرم یا سخت تنظیم کنید تا حد را روی حداکثر حد فرایند جاری قرار دهد. در حالت rootful این معمولاً نامحدود است.

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

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

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

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

--umask=umask

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

--unsetenv=env

حذف تنظیم متغیرهای محیطی پیش‌فرض برای کانتینر. متغیرهای محیطی پیش‌فرض شامل متغیرهای ارائه‌شده توسط خود پادمن، متغیرهای پیکربندی‌شده توسط ایمیج و متغیرهای محیطی از containers.conf هستند.

--unsetenv-all

حذف تنظیم تمام متغیرهای محیطی پیش‌فرض برای کانتینر. متغیرهای محیطی پیش‌فرض شامل متغیرهای ارائه‌شده توسط خود پادمن، متغیرهای پیکربندی‌شده توسط ایمیج و متغیرهای محیطی از containers.conf هستند.

--user, -u=user[:group]

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

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

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

--userns=mode

تنظیم حالت فضای نام کاربری برای کانتینر.

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

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

این گزینه با --gidmap، --uidmap، --subuidname و --subgidname ناسازگار است.

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

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

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

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

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

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

گزینه‌های معتبر auto:

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

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

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

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

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

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

گزینه‌های معتبر keep-id:

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

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

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

--uts=mode

تنظیم حالت فضای نام UTS برای کانتینر. مقادیر زیر پشتیبانی می‌شوند:

• host: استفاده از فضای نام UTS میزبان درون کانتینر.
• private: ایجاد یک فضای نام جدید برای کانتینر (پیش‌فرض).
• ns:[path]: اجرای کانتینر در فضای نام UTS موجودِ مشخص‌شده.
• container:[container]: پیوستن به فضای نام UTS کانتینر مشخص‌شده.

--variant=VARIANT

استفاده از VARIANT به جای گونه معماری پیش‌فرض ایمیج کانتینر. برخی ایمیج‌ها می‌توانند از چندین گونه از معماری‌های arm استفاده کنند، مانند arm/v5 و arm/v7.

--volume, -v=[[SOURCE-VOLUME|HOST-DIR:]CONTAINER-DIR[:OPTIONS]]

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

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

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

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

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

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

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

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

$ podman run -v myvolume:/data:nocreate alpine

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

مانت‌های حجم محافظت‌شده در برابر نوشتن

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

تغییر مالکیت (Chowning) مانت‌های حجم

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

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

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

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

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

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

برچسب‌گذاری مانت‌های حجم

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

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

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

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

$ podman run --security-opt label=disable -v $HOME:/home/user fedora touch /home/user/file

مانت‌های حجم Overlay

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

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

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

یکی از موارد استفاده مانت overlay به اشتراک‌گذاری کش بسته‌ها از میزبان به درون کانتینر برای افزایش سرعت ساخت است.

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

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

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

انتشار مانت‌ها (Mounts propagation)

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

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

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

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

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

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

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

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

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

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

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

مانت Idmapped

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

از گزینه --group-add keep-groups برای انتقال دسترسی گروه تکمیلی کاربر به درون کانتینر استفاده کنید.

--volumes-from=CONTAINER[:OPTIONS]

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

• rw|ro
• z

حجم‌های از قبل سوارشده از یک کانتینر مبدا را روی کانتینر دیگر سوار می‌کند. مقدار CONTAINER می‌تواند نام یا شناسه باشد. برای اشتراک‌گذاری یک حجم، از گزینه --volumes-from هنگام اجرای کانتینر مقصد استفاده کنید. حجم‌ها را حتی در صورتی که کانتینر مبدا در حال اجرا نباشد می‌توان به اشتراک گذاشت.

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

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

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

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

--workdir, -w=dir

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

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

اجرای کانتینر در حالت فقط‌خواندنی

در طول توسعه ایمیج کانتینر، کانتینرها اغلب نیاز دارند در محتوای ایمیج بنویسند؛ برای مثال نصب بسته‌ها در /usr. در محیط عملیاتی، برنامه‌ها به ندرت نیاز به نوشتن در ایمیج دارند. برنامه‌های کانتینری در صورت نیاز به نوشتن در سیستم‌فایل، در حجم‌ها (volumes) می‌نویسند. با اجرای برنامه‌ها در حالت فقط‌خواندنی با استفاده از سوئیچ --read-only، می‌توان امنیت آن‌ها را ارتقا داد. این کار ایمیج کانتینر را در برابر تغییر محافظت می‌کند. به طور پیش‌فرض کانتینرهای فقط‌خواندنی می‌توانند روی داده‌های موقت بنویسند. پادمن یک tmpfs را روی /run و /tmp در داخل کانتینر مانت می‌کند.

$ podman run --read-only -i -t fedora /bin/bash

اگر کانتینر به هیچ سیستم‌فایلی درون کانتینر، از جمله tmpfs، نمی‌نویسد، مقدار --read-only-tmpfs=false را تنظیم کنید.

$ podman run --read-only --read-only-tmpfs=false --tmpfs /run -i -t fedora /bin/bash

ارائه کتابخانه‌های اشتراکی درون کانتینر به صورت فقط‌خواندنی با استفاده از glob

$ podman run --mount type=glob,src=/usr/lib64/libnvidiaro=true -i -t fedora /bin/bash

ارسال پیام‌های لاگ از کانتینر به سیستم لاگ میزبان

دایرکتوری /dev/log را bind mount کنید تا پیام‌هایی که در کانتینر ثبت می‌شوند در syslog/journal میزبان نمایش داده شوند.

$ podman run -v /dev/log:/dev/log -i -t fedora /bin/bash

از داخل کانتینر با ارسال یک پیام به لاگر این موضوع را آزمایش کنید:

(bash)# logger "Hello from my container"

سپس خارج شده و journal را بررسی کنید:

(bash)# exit
$ journalctl -b | grep Hello

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

اتصال به یک یا چند مورد از STDIN، STDOUT، STDERR

بدون مشخص کردن گزینه -a، پادمن همه موارد (stdin, stdout, stderr) را متصل می‌کند. با مشخص کردن a- (stdin, stdout, stderr) مقدار پیش‌فرض را بازنویسی کنید، مانند:

$ podman run -a stdin -a stdout -i -t fedora /bin/bash

اشتراک‌گذاری IPC بین کانتینرها

با استفاده از shm_server.c موجود در: https://www.cs.cf.ac.uk/Dave/C/node27.html

آزمایش حالت --ipc=host:

میزبان یک بخش حافظه اشتراکی با ۷ pid متصل نشان می‌دهد که متعلق به httpd است:

$ sudo ipcs -m
------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0x01128e25 0          root       600        1000       7

اکنون یک کانتینر معمولی را اجرا کنید؛ این کانتینر به درستی بخش حافظه اشتراکی از میزبان را نمی‌بیند:

$ podman run -it shm ipcs -m
------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status

یک کانتینر با گزینه جدید --ipc=host اجرا کنید؛ اکنون بخش حافظه اشتراکی از httpd میزبان را می‌بیند:

$ podman run -it --ipc=host shm ipcs -m
------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0x01128e25 0          root       600        1000       7

آزمایش حالت --ipc=container:id:

یک کانتینر را با برنامه‌ای برای ایجاد بخش حافظه اشتراکی شروع کنید:

$ podman run -it shm bash
$ sudo shm/shm_server &
$ sudo ipcs -m
------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0x0000162e 0          root       666        27         1

ایجاد کانتینر دوم به درستی هیچ بخش حافظه اشتراکی از کانتینر اول را نشان نمی‌دهد:

$ podman run shm ipcs -m
------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status

ایجاد کانتینر سوم با استفاده از گزینه --ipc=container:id؛ اکنون بخش حافظه اشتراکی از کانتینر اول را نشان می‌دهد:

$ podman run -it --ipc=container:ed735b2264ac shm ipcs -m
$ sudo ipcs -m
------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0x0000162e 0          root       666        27         1

نگاشت پورت‌ها برای استفاده خارجی

پورت ارائه شده یک برنامه را می‌توان با استفاده از پرچم -p به یک پورت میزبان نگاشت کرد. برای مثال، پورت 80 در httpd را می‌توان با دستور زیر به پورت 8080 میزبان نگاشت نمود:

$ podman run -p 8080:80 -d fedora/httpd

اتصال حجم‌های خارجی (Mounting External Volumes)

برای مانت کردن یک مسیر دایرکتوری میزبان به عنوان حجم کانتینر، مسیر مطلق دایرکتوری و مسیر مطلق دایرکتوری کانتینر را که با دونقطه جدا شده‌اند مشخص کنید. اگر منبع یک حجم نام‌گذاری‌شده تحت مدیریت پادمن است، توصیه می‌شود به‌جای مسیر حجم از نام آن استفاده شود. در غیر این صورت حجم به عنوان یک حجم یتیم (orphan) در نظر گرفته شده و با دستور podman volume prune پاک خواهد شد:

$ podman run -v /var/db:/data1 -i -t fedora bash
$ podman run -v data:/data2 -i -t fedora bash
$ podman run -v /var/cache/dnf:/var/cache/dnf:O -ti fedora dnf -y update

اگر کانتینر به یک حجم مانت‌شده با قابلیت نوشتن توسط کاربری غیر از root درون کانتینر نیاز دارد، از گزینه U استفاده کنید. این گزینه به پادمن دستور می‌دهد تا مالکیت (chown) حجم منبع را مطابق با UID و GID پیش‌فرض استفاده‌شده درون کانتینر تنظیم کند.

$ podman run -d -e MARIADB_ROOT_PASSWORD=root --user mysql --userns=keep-id -v ~/data:/var/lib/mysql:Z,U mariadb

همچنین اگر کانتینر به حجم قابل نوشتن توسط یک کاربر غیر root درون کانتینر نیاز دارد، گزینه --userns=keep-id به کاربران اجازه می‌دهد UID و GID کاربری را که پادمن را اجرا می‌کند به UIDها و GIDهای مشخصی در داخل کانتینر نگاشت کنند. از آنجا که فرایندهای در حال اجرا در کانتینر با UID کاربر اجرا می‌شوند، می‌توانند فایل‌های متعلق به کاربر را بخوانند/بنویسند.

$ podman run -d -e MARIADB_ROOT_PASSWORD=root --user mysql --userns=keep-id:uid=999,gid=999 -v ~/data:/var/lib/mysql:Z mariadb

با استفاده از پرچم‌های --mount برای مانت کردن یک دایرکتوری میزبان به عنوان پوشه کانتینر، مسیر مطلق دایرکتوری یا نام حجم و مسیر مطلق درون دایرکتوری کانتینر را مشخص کنید:

$ podman run --mount type=bind,src=/var/db,target=/data1 busybox sh
$ podman run --mount type=bind,src=volume-name,target=/data1 busybox sh

پرچم --mount یک ساختار کلید-مقدار برای تعریف مانت‌ها در داخل کانتینرها فراهم می‌کند. این گزینه از نظر کاربرد مشابه -v یا --volume است، اما برای پیکربندی‌های پیچیده یا دارای گزینه‌های متعدد وضوح بیشتری ارائه می‌دهد. سینتکس کلی به این صورت است:

--mount type=<TYPE>,src=<SOURCE>,dst=<TARGET>[,options...]

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

مانت‌های نوع Bind

مانت‌های Bind به طور مستقیم یک دایرکتوری یا فایل را روی میزبان به کانتینر متصل می‌کنند. تغییرات اعمال‌شده در هر یک بلافاصله در دیگری قابل مشاهده است. زمانی از bind mount استفاده کنید که هم میزبان و هم کانتینر نیاز به دسترسی به فایل‌های یکسانی دارند، مانند فایل‌های پیکربندی یا کدهای منبع.

مثال:

podman run --mount type=bind,src=/etc/config,dst=/app/config alpine cat /app/config/file.conf

مانت‌های نوع Volume

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

مثال:

podman volume create mydata
podman run --mount type=volume,src=mydata,dst=/var/lib/data postgres

مانت‌های نوع Tmpfs

یک مانت tmpfs یک سیستم‌فایل مبتنی بر حافظه موقت (RAM) روی میزبان ایجاد می‌کند که درون کانتینر مانت می‌شود. داده‌های ذخیره‌شده در اینجا موقتی هستند و با توقف کانتینر یا راه‌اندازی مجدد میزبان حذف می‌شوند. مانت‌های tmpfs برای کش‌های موقت یا داده‌های حساسی که نباید روی دیسک ذخیره شوند مفید هستند.

مثال:

podman run --mount type=tmpfs,dst=/cache,tmpfs-size=64m alpine

مانت‌های نوع Artifact، devpts، image، glob و ramfs

سایر انواع مانت‌های تخصصی برای موارد استفاده پیشرفته در دسترس هستند:

• artifact - محتوای فقط‌خواندنی را از یک ایمیج یا آرتیفکت کانتینر مانت می‌کند.
• devpts - یک دستگاه شبه‌ترمینال (pseudo-terminal) درون کانتینر ارائه می‌دهد.
• image - فایل‌ها را مستقیماً از یک ایمیج کانتینر دیگر مانت می‌کند.
• glob - چندین فایل میزبان منطبق بر یک الگوی glob را مانت می‌کند.
• ramfs - مشابه tmpfs است اما مستقیماً بر پایه‌ی RAM سیستم و بدون محدودیت اندازه کار می‌کند.

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

به طور خلاصه، --mount یک رابط منسجم برای اتصال فضاهای ذخیره‌سازی خارجی به کانتینرها فراهم می‌کند. نوع مانتی را انتخاب کنید که به بهترین شکل با نیاز شما سازگار است: bind برای دسترسی مستقیم میزبان، volume برای داده‌های ماندگار مدیریت‌شده توسط پادمن، و tmpfs برای ذخیره‌سازی موقت در حافظه.

هنگام استفاده از SELinux، توجه داشته باشید که میزبان اطلاعی از سیاست‌های SELinux کانتینر ندارد. بنابراین، در مثال بالا، در صورت اعمال سیاست SELinux، دایرکتوری /var/db برای کانتینر قابل نوشتن نخواهد بود. یک پیام "Permission Denied" رخ می‌دهد و پیام avc: به syslog میزبان اضافه می‌شود.

برای حل این مشکل، در زمان نگارش این صفحه راهنما، دستور زیر باید اجرا شود تا برچسب نوع سیاست SELinux مناسب به دایرکتوری میزبان متصل گردد:

$ chcon -Rt svirt_sandbox_file_t /var/db

اکنون نوشتن روی حجم /data1 درون کانتینر مجاز است و تغییرات در /var/db روی میزبان منعکس می‌شود.

استفاده از برچسب‌گذاری امنیتی جایگزین

طرح برچسب‌گذاری پیش‌فرض برای هر کانتینر را با مشخص کردن پرچم --security-opt بازنویسی کنید. برای نمونه، سطح MCS/MLS را مشخص کنید که الزامی برای سیستم‌های MLS است. مشخص کردن سطح در دستور زیر اجازه می‌دهد تا محتوای یکسان بین کانتینرها به اشتراک گذاشته شود.

podman run --security-opt label=level:s0:c100,c200 -i -t fedora bash

یک مثال برای MLS می‌تواند چنین باشد:

$ podman run --security-opt label=level:TopSecret -i -t rhel7 bash

برای غیرفعال کردن برچسب‌گذاری امنیتی برای این کانتینر در مقایسه با اجرا همراه با پرچم --permissive، از دستور زیر استفاده کنید:

$ podman run --security-opt label=disable -i -t fedora bash

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

$ podman run --security-opt label=type:svirt_apache_t -i -t centos bash

توجه داشته باشید که باید سیاست SELinux تعریف‌کننده نوع svirt_apache_t نوشته شده باشد.

برای ماسک کردن مسیرهای خاص اضافی در کانتینر، مسیرها را با دونقطه جدا کرده و با استفاده از گزینه mask همراه با پرچم --security-opt مشخص کنید.

$ podman run --security-opt mask=/foo/bar:/second/path fedora bash

برای رفع ماسک (unmask) از تمامی مسیرهایی که به طور پیش‌فرض ماسک شده‌اند، گزینه unmask را روی ALL تنظیم کنید. یا برای رفع ماسک تنها از مسیرهای خاص، مسیرها را همان‌طور که در بالا با گزینه mask نشان داده شد تعیین نمایید.

$ podman run --security-opt unmask=ALL fedora bash

برای رفع ماسک از تمام مسیرهایی که با proc/ شروع می‌شوند، گزینه unmask را روی /proc/* تنظیم کنید.

$ podman run --security-opt unmask=/proc/* fedora bash

$ podman run --security-opt unmask=/foo/bar:/sys/firmware fedora bash

تنظیم وزن دستگاه با پرچم --blkio-weight-device

$ podman run -it --blkio-weight-device "/dev/sda:200" ubuntu

استفاده از کانتینر پادمن با ورودی از پایپ (pipe)

$ echo "asdf" | podman run --rm -i --entrypoint /bin/cat someimage
asdf

تنظیم کانتینرهای تفکیک‌شده با فضای نام کاربری خودکار

# podman run --userns=auto:size=65536 ubi8-micro cat /proc/self/uid_map
0 2147483647      65536
# podman run --userns=auto:size=65536 ubi8-micro cat /proc/self/uid_map
0 2147549183      65536

تنظیم پارامترهای کرنل دارای فضای نام (Sysctls)

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

$ podman run --sysctl net.ipv4.ip_forward=1 someimage

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

تعریف گزینه --sysctl در بالا را برای فهرست فعلی sysctlهای پشتیبانی‌شده ببینید.

تنظیم نگاشت UID/GID در یک فضای نام کاربری جدید

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

$ podman run --uidmap 0:30000:7000 --gidmap 0:30000:7000 fedora echo hello

پیکربندی گزینه‌های ذخیره‌سازی از خط فرمان

پادمن امکان پیکربندی ذخیره‌سازی را با تغییر مقادیر در /etc/container/storage.conf یا با استفاده از گزینه‌های سراسری فراهم می‌کند. این مثال نشان می‌دهد که چگونه می‌توان از یک فضای ذخیره‌سازی ایمیج اضافی برای یک بار اجرای busybox با استفاده از گزینه‌های سراسری بهره برد.

podman --log-level=debug --storage-opt "additionalimagestore=/tmp/readonly-images" run busybox /bin/sh

پیکربندی منطقه زمانی در کانتینر

$ podman run --tz=local alpine date
$ podman run --tz=Asia/Shanghai alpine date
$ podman run --tz=US/Eastern alpine date

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

کانتینر اول، container1، در ابتدا شروع نمی‌شود، اما قبل از شروع container2 باید در حال اجرا باشد. دستور podman run پیش از راه‌اندازی container2، کانتینر وابسته را به صورت خودکار شروع می‌کند.

$ podman create --name container1 -t -i fedora bash
$ podman run --name container2 --requires container1 -t -i fedora bash

می‌توان چندین کانتینر را الزامی کرد.

$ podman create --name container1 -t -i fedora bash
$ podman create --name container2 -t -i fedora bash
$ podman run --name container3 --requires container1,container2 -t -i fedora bash

پیکربندی حفظ گروه‌های تکمیلی برای دسترسی به حجم

$ podman run -v /var/lib/design:/var/lib/design --group-add keep-groups ubi8

پیکربندی دامنه اجرا برای کانتینرها با پرچم personality

$ podman run --name container1 --personality=LINUX32 fedora bash

اجرای کانتینر با rootfs خارجی مانت‌شده به صورت overlay

$ podman run --name container1 --rootfs /path/to/rootfs:O bash

مدیریت مناطق زمانی در برنامه‌های جاوا درون کانتینر

برای استفاده از منطقه‌ای زمانی به جز UTC هنگام اجرای یک برنامه جاوا در داخل کانتینر، متغیر محیطی TZ باید درون کانتینر تنظیم شود. برنامه‌های جاوا مقدار تنظیم‌شده با گزینه --tz را نادیده می‌گیرند.

# Example run
podman run -ti --rm  -e TZ=EST mytzimage
lrwxrwxrwx. 1 root root 29 Nov  3 08:51 /etc/localtime -> ../usr/share/zoneinfo/Etc/UTC
Now with default timezone:
Fri Nov 19 18:10:55 EST 2021
Java default sees the following timezone:
2021-11-19T18:10:55.651130-05:00
Forcing UTC:
Fri Nov 19 23:10:55 UTC 2021

اجرای یک کانتینر متصل به دو شبکه (به نام‌های net1 و net2) با آی‌پی ثابت

$ podman run --network net1:ip=10.89.1.5 --network net2:ip=10.89.10.10 alpine ip addr

تعریف بررسی سلامت در زمان اجرا و تایید آن

$ podman create -d --name healthcheck-example -p 8080:80   
  --health-cmd '["CMD-SHELL","wget -q --spider http://127.0.0.1:80 || exit 1"]'   
  --health-interval 30s --health-timeout 5s --health-retries 3   
  docker.io/library/nginx:alpine
$ podman inspect healthcheck-example | jq '.[0].State.Health'

کانتینرهای بدون ریشه (Rootless Containers)

پادمن در اکثر سیستم‌ها به عنوان یک کاربر غیر ریشه اجرا می‌شود. این قابلیت نیازمند نصب نسخه به قدر کافی جدیدی از shadow-utils است. بسته shadow-utils باید شامل فایل‌های اجرایی newuidmap(1) و newgidmap(1) باشد.

برای اینکه کاربران بتوانند به صورت بدون ریشه اجرا کنند، باید ورودی‌ای برای نام کاربری آن‌ها در /etc/subuid و /etc/subgid وجود داشته باشد که UIDهای فضای نام کاربری آن‌ها را مشخص نماید.

پادمن بدون ریشه در صورت نصب بودن بسته fuse-overlayfs عملکرد بهتری دارد. بسته fuse-overlayfs یک درایور ذخیره‌سازی overlay در فضای کاربری فراهم می‌کند، در غیر این صورت کاربران باید از درایور ذخیره‌سازی vfs استفاده کنند که می‌تواند فضای دیسک زیادی مصرف کرده و کارایی کمتری نسبت به سایر درایورها داشته باشد.

برای فعال‌سازی VPN روی کانتینر، به طور پیش‌فرض از شبکه pasta استفاده می‌شود؛ در غیر این صورت، کانتینرها باید با پرچم --network=host اجرا شوند.

عیب‌یابی (Troubleshooting)

صفحه podman-troubleshooting(7) را برای راه‌حل‌های مشکلات رایج ببینید.

صفحه podman-rootless(7) را برای مشکلات مربوط به حالت بدون ریشه ببینید.