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

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

name.pod

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

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

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

گزینه‌های [Pod] معادل در podman pod create
AddHost=example.com:192.168.10.11 --add-host example.com:192.168.10.11
ContainersConfModule=/etc/nvd.conf --module=/etc/nvd.conf
DNS=192.168.55.1 --dns=192.168.55.1
DNSOption=ndots:1 --dns-option=ndots:1
DNSSearch=example.com --dns-search example.com
ExitPolicy=stop --exit-policy stop
GIDMap=0:10000:10 --gidmap=0:10000:10
GlobalArgs=--log-level=debug --log-level=debug
HostName=name --hostname=name
IP=192.5.0.1 --ip 192.5.0.1
IP6=2001:db8::1 --ip6 2001:db8::1
Label="XYZ" --label "XYZ"
Network=host --network host
NetworkAlias=name --network-alias name
PodmanArgs=--cpus=2 --cpus=2
PodName=name --name=name
PublishPort=8080:80 --publish 8080:80
ServiceName=name نام‌گذاری واحد systemd به name.service
ShmSize=100m --shm-size=100m
SubGIDMap=gtest --subgidname=gtest
SubUIDMap=utest --subuidname=utest
UIDMap=0:10000:10 --uidmap=0:10000:10
UserNS=keep-id:uid=200,gid=210 --userns keep-id:uid=200,gid=210
Volume=/source:/dest --volume /source:/dest

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

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

این گزینه یک یا چند نام میزبان جداشده با نقطه ویرگول (semicolon) را دریافت می‌کند که با یک دونقطه به یک آدرس 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 پیکربندی کرد.

ماژول مشخص‌شده‌ی containers.conf(5) را بارگذاری می‌کند.

این گزینه می‌تواند چندین بار درج شود.

سرورهای 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 ارائه‌شده فوروارد می‌کند.

تنظیم گزینه‌های سفارشی DNS. در صورت استفاده از DNSOption= همراه با Network= که روی none یا container:id تنظیم شده باشد، نامعتبر است.

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

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

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

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

نکته: گزینه GIDMap= نمی‌تواند همراه با گزینه Pod= فراخوانی شود زیرا در سطح کانتینر درون یک پاد نمی‌توان یک gidmap تنظیم کرد.

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

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

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

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

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

زمانی که HostName= تنظیم نشده باشد و کانتینر از فضای نام UTS خصوصی استفاده کند (پیش‌فرض)، پادمن نام میزبان را برابر با ۱۲ نویسه‌ی اول شناسه کانتینر (Container ID) قرار می‌دهد. نام کانتینر تعیین‌شده با ContainerName= استفاده نمی‌شود مگر اینکه container_name_as_hostname=true در containers.conf تنظیم شده باشد.

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

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

برای مشخص کردن چندین آدرس IP ایستا برای هر کانتینر، چندین شبکه را با استفاده از گزینه Network= تنظیم کرده و با استفاده از حالت ip برای آن گزینه، برای هر شبکه یک آدرس IP ایستا تعیین کنید.

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

برای مشخص کردن چندین آدرس IPv6 ایستا برای هر کانتینر، چندین شبکه را با استفاده از گزینه Network= تنظیم کرده و با استفاده از حالت ip6 برای آن گزینه، برای هر شبکه یک آدرس IPv6 ایستا تعیین کنید.

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

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

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

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

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

•
bridge[:OPTIONS,...]: ایجاد یک پشته شبکه روی بریج پیش‌فرض. این حالت پیش‌فرض برای کانتینرهای با دسترسی ریشه (rootful) است. امکان تعیین این گزینه‌های اضافی وجود دارد:
  • alias=name: افزودن نام مستعار در حوزه شبکه برای کانتینر.
  • ip=IPv4: مشخص کردن آدرس استاتیک IPv4 برای این کانتینر.
  • ip6=IPv6: مشخص کردن آدرس استاتیک IPv6 برای این کانتینر.
  • mac=MAC: مشخص کردن آدرس استاتیک MAC برای این کانتینر.
  • interface_name=name: مشخص کردن یک نام برای رابط شبکه ایجادشده درون کانتینر.
  • host_interface_name=name: مشخص کردن یک نام برای رابط شبکه ایجادشده در خارج از کانتینر.
هر گزینه دیگری بدون اعتبارسنجی به netavark ارسال خواهد شد. این ویژگی می‌تواند برای ارسال آرگومان‌ها به پلاگین‌های netavark مفید باشد.

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

برای مثال، برای تنظیم یک آدرس استاتیک IPv4 و یک آدرس مک استاتیک، از --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 و برای کانتینرهای بدون ریشه از pasta استفاده می‌کند.
  • pasta[:OPTIONS,...]: استفاده از pasta(1) برای ایجاد پشته شبکه در حالت کاربر (user-mode).
    این حالت پیش‌فرض برای کانتینرهای بدون ریشه است و فقط در حالت بدون ریشه پشتیبانی می‌شود.
    به‌طور پیش‌فرض، آدرس‌ها و مسیرهای IPv4 و IPv6 و همچنین نام رابط پاد از میزبان کپی می‌شوند. فوروارد پورت، آدرس IP مبدا اصلی را حفظ می‌کند. گزینه‌های شرح داده شده در pasta(1) می‌توانند به‌صورت آرگومان‌های جداشده با کاما مشخص شوند.
    از نظر گزینه‌های pasta(1)، به‌طور پیش‌فرض --config-net برای پیکربندی شبکه هنگام شروع کانتینر اعمال می‌شود و --no-map-gw نیز به‌طور پیش‌فرض فرض می‌شود تا از دسترسی مستقیم کانتینر به میزبان با استفاده از آدرس گیت‌وی جلوگیری شود. مورد دوم می‌تواند با ارسال --map-gw در گزینه‌های اختصاصی pasta بازنویسی شود (با وجود اینکه گزینه واقعی pasta(1) نیست).
    برای یکپارچگی بهتر با مدیریت 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 ارسال می‌شود. مجدداً می‌توان آن را برای انتخاب آدرس IP دیگر به‌صورت صریح تنظیم کرد.
    همچنین در صورتی که فوروارد پورت TCP یا UDP از میزبان به کانتینر پیکربندی نشده باشد (از طریق --publish پادمن یا با ارسال مستقیم گزینه‌های -t/-u در pasta)، گزینه‌های -t none و -u none ارسال می‌شوند تا فوروارد خودکار پورت بر اساس پورت‌های متصل غیرفعال شود. به همین ترتیب، -T none و -U none برای غیرفعال کردن همین عملکرد از کانتینر به میزبان ارسال می‌گردند.
    همه گزینه‌ها همچنین می‌توانند در containers.conf(5) تنظیم شوند؛ کلید pasta_options را ذیل بخش شبکه در آن فایل ببینید.
    چند مثال:
  • pasta:--map-gw: اجازه دسترسی مستقیم کانتینر به میزبان با استفاده از آدرس گیت‌وی.
  • pasta:--mtu,1500: مشخص کردن یک MTU معادل ۱۵۰۰ بایت برای رابط tap در کانتینر.
  • pasta:--ipv4-only,-a,10.0.2.0,-n,24,-g,10.0.2.2,--dns-forward,10.0.2.3,-m,1500,--no-ndp,--no-dhcpv6,--no-dhcp: غیرفعال کردن IPv6، تخصیص 10.0.2.0/24 به رابط tap0 در کانتینر با گیت‌وی 10.0.2.3، فعال‌سازی ارسال‌کننده DNS قابل دسترسی در 10.0.2.3، تنظیم MTU روی ۱۵۰۰ بایت، غیرفعال‌سازی پشتیبانی NDP، DHCPv6 و DHCP.
  • pasta:-I,tap0,--ipv4-only,-a,10.0.2.0,-n,24,-g,10.0.2.2,--dns-forward,10.0.2.3,--no-ndp,--no-dhcpv6,--no-dhcp: مشابه بالا، اما رها کردن MTU روی ۶۵۵۲۰ بایت.
  • pasta:-t,auto,-u,auto,-T,auto,-U,auto: فعال‌سازی فوروارد خودکار پورت بر اساس پورت‌های متصل مشاهده‌شده از سمت میزبان و کانتینر.
  • pasta:-T,5201: فعال‌سازی فوروارد پورت TCP به شماره ۵۲۰۱ از کانتینر به میزبان، با استفاده از رابط loopback به‌جای رابط tap برای کارایی بهتر.

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

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

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

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

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

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

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

هر دو مقدار 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"] باعث می‌شود پورت به‌ترتیب روی آدرس localhost در ipv4 و ipv6 منتشر شود. یک hostIP صریح که در دستور تنظیم شده باشد همواره گزینه پیکربندی را بازنویسی می‌کند.

به‌طور پیش‌فرض، پادمن پورت‌های TCP را منتشر می‌کند. برای انتشار پورت UDP، مقدار udp را به‌عنوان پروتکل ارائه دهید. برای انتشار هر دو پورت TCP و UDP، گزینه --publish را دو بار، به‌ترتیب با پروتکل‌های tcp و udp تنظیم کنید. کانتینرهای با دسترسی ریشه همچنین می‌توانند پورت‌ها را با استفاده از پروتکل sctp منتشر کنند.

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

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

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

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

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

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

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

اجرای کانتینر در یک فضای نام کاربری جدید با استفاده از نگاشت با نام name در فایل /etc/subgid. هنگام اجرا در حالت بدون ریشه، کاربر برای استفاده از این نگاشت نیازمند مجوزهای لازم است. به subgid(5) مراجعه کنید. این پرچم با UserNS= و GIDMap= تداخل دارد. همراه با GIDMap= طوری عمل می‌کند که گویی GIDMap= با تمام نگاشت‌های گروه name در /etc/subgid ارسال شده باشد.

اجرای کانتینر در یک فضای نام کاربری جدید با استفاده از نگاشت با نام name در فایل /etc/subuid. هنگام اجرا در حالت بدون ریشه، کاربر برای استفاده از این نگاشت نیازمند مجوزهای لازم است. به subuid(5) مراجعه کنید. این پرچم با UserNS= و UIDMap= تداخل دارد. همراه با UIDMap= طوری عمل می‌کند که گویی UIDMap= با تمام نگاشت‌های کاربر name در /etc/subuid ارسال شده باشد.

اجرای تمام کانتینرهای درون پاد در یک فضای نام کاربری جدید با استفاده از نگاشت ارائه‌شده. این گزینه با گزینه‌های UserNS= و SubUIDMap= تداخل دارد. این گزینه روشی برای نگاشت UIDهای میزبان به UIDهای کانتینر فراهم می‌کند. می‌تواند چندین بار برای نگاشت محدوده‌های مختلف ارسال شود.

تنظیم حالت فضای نام کاربری برای تمام کانتینرهای یک پاد. مقدار پیش‌فرض آن به متغیر محیطی PODMAN_USERNS بستگی دارد. مقدار خالی ("") به معنای غیرفعال بودن فضاهای نام کاربری است.

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

کلید کاربر میزبان کاربر کانتینر
"" $UID 0 (حساب کاربر پیش‌فرض به کاربر root در کانتینر نگاشت می‌شود.)
host $UID 0 (حساب کاربر پیش‌فرض به کاربر root در کانتینر نگاشت می‌شود.)
keep-id $UID $UID (نگاشت حساب کاربر به همان UID درون کانتینر.)
auto $UID nil (شناسه UID کاربر میزبان به درون کانتینر نگاشت نمی‌شود.)
nomap $UID nil (شناسه UID کاربر میزبان به درون کانتینر نگاشت نمی‌شود.)

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

•
auto[:OPTIONS,...]: ایجاد خودکار یک فضای نام. امکان تعیین این گزینه‌ها برای auto وجود دارد:
  • gidmapping=CONTAINER_GID:HOST_GID:SIZE: اجبار به حضور یک نگاشت GID در فضای نام کاربر.
  • size=SIZE: برای تعیین یک اندازه صریح برای فضای نام کاربر خودکار. مثلاً UserNS=auto:size=8192. اگر size مشخص نشود، auto اندازه فضای نام کاربر را برآورد می‌کند.
  • uidmapping=CONTAINER_UID:HOST_UID:SIZE: اجبار به حضور یک نگاشت UID در فضای نام کاربر.
  • host: اجرا در فضای نام کاربر فراخواننده. فرآیندهای در حال اجرا درون کانتینر همان امتیازات را روی میزبان دارند که هر فرآیند دیگری توسط کاربر فراخواننده اجرا شود دارد (پیش‌فرض).
  • keep-id: یک فضای نام کاربر ایجاد می‌کند که در آن UID:GID کاربر بدون ریشه جاری به همان مقادیر درون کانتینر نگاشت می‌شوند. این گزینه برای کانتینرهای ایجادشده توسط کاربر root مجاز نیست.
  • nomap: یک فضای نام کاربر ایجاد می‌کند که در آن UID:GID کاربر بدون ریشه جاری به درون کانتینر نگاشت نمی‌شوند. این گزینه برای کانتینرهای ایجادشده توسط کاربر root مجاز نیست.

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

حالت خاص:

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

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

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

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

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

تغییر مالکیت اتصالات حجم (Chowning)

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

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

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

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

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

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

برچسب‌گذاری اتصالات حجم (Labeling)

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

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

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

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

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

اتصالات حجم اورلی (Overlay)

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

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

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

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

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

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

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

انتشار اتصالات (Mounts propagation)

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

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

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

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

اتصال حجم‌ها با گزینه‌های 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 بررسی کنید. به "optional fields" نگاه کنید تا ببینید آیا ویژگی انتشاری مشخص شده است یا خیر. در آنجا، shared:N به معنای اشتراکی بودن اتصال، master:N به معنای slave بودن، و عدم وجود چیزی به معنای خصوصی (private) بودن اتصال است. [1] ⟨#Footnote1⟩

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

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

اتصال نگاشت شناسه (Idmapped mount)

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

مثال: کانتینر درون یک پاد

test.pod:

[Pod]
PodName=test

centos.container:

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

podman-kube-play(1), podman-systemd.unit(5), systemd.unit(5)