buildah-run(1) General Commands Manual buildah-run(1)

buildah-run - اجرای فرمانی در داخل یک کانتینر در حال ساخت

buildah run [گزینه‌ها] [--] کانتینر فرمان

یک کانتینر را راه‌اندازی کرده و فرمان مشخص‌شده را در آن کانتینر با استفاده از سیستم فایل ریشه کانتینر به عنوان سیستم فایل ریشه اجرا می‌کند، در حالی که از تنظیمات پیکربندی به ارث رسیده از ایمیج کانتینر یا تنظیماتی که با استفاده از فراخوانی‌های قبلی دستور buildah config مشخص شده‌اند استفاده می‌نماید. برای اجرای buildah run در یک پوسته تعاملی (interactive shell)، گزینه --tty را مشخص کنید.

--add-history

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

نکته: شما همچنین می‌توانید مقدار پیش‌فرض --add-history را با تنظیم متغیر محیطی BUILDAH_HISTORY بازنویسی کنید. export BUILDAH_HISTORY=true

--cap-add=CAP_xxx

قابلیت (capability) مشخص‌شده را به مجموعه قابلیت‌هایی که به فرمان مشخص‌شده اعطا می‌شوند، اضافه می‌کند. برخی قابلیت‌ها به‌طور پیش‌فرض اعطا می‌شوند؛ این گزینه می‌تواند برای افزودن قابلیت‌های بیشتر فراتر از مقادیر پیش‌فرض استفاده شود، که ممکن است پیش‌تر با گزینه‌های --cap-add و --cap-drop در فراخوانی buildah from که کانتینر را ایجاد کرده است، تغییر یافته باشند.

--cap-drop=CAP_xxx

قابلیت مشخص‌شده را از مجموعه قابلیت‌هایی که به فرمان مشخص‌شده اعطا می‌شوند، حذف می‌کند. قابلیت‌های CAP_CHOWN،‏ CAP_DAC_OVERRIDE،‏ CAP_FOWNER،‏ CAP_FSETID،‏ CAP_KILL،‏ CAP_NET_BIND_SERVICE،‏ CAP_SETFCAP،‏ CAP_SETGID،‏ CAP_SETPCAP و CAP_SETUID به‌طور پیش‌فرض اعطا می‌شوند؛ این گزینه می‌تواند برای حذف آن‌ها از مقادیر پیش‌فرض استفاده شود، که ممکن است با گزینه‌های --cap-add و --cap-drop استفاده‌شده در فراخوانی buildah from که کانتینر را ایجاد کرده است تغییر یافته باشند. فهرست قابلیت‌های پیش‌فرض در containers.conf(5) مدیریت می‌شود.

اگر یک قابلیت هم برای گزینه --cap-add و هم برای گزینه --cap-drop مشخص شود، بدون توجه به ترتیبی که گزینه‌ها داده شده‌اند، حذف خواهد شد.

--cgroupns how

پیکربندی فضاهای نام cgroup را برای کانتینر تنظیم می‌کند. مقدار پیکربندی‌شده می‌تواند "" (رشته خالی) یا "private" باشد تا نشان دهد که باید یک فضای نام cgroup جدید ایجاد شود، یا می‌تواند "host" باشد تا نشان دهد فضای نام cgroup که خود buildah در آن در حال اجرا است باید بازاستفاده شود.

--contextdir directory

امکان تنظیم دایرکتوری زمینه را برای فراخوانی فعلی RUN فراهم می‌کند. مشخص کردن یک دایرکتوری زمینه باعث می‌شود زمینه RUN دایرکتوری زمینه را به عنوان دایرکتوری ریشه برای منبع مشخص‌شده در --mount از نوع 'bind' در نظر بگیرد.

--device=device

یک دستگاه میزبان یا دستگاه‌های موجود در یک دایرکتوری را به محیطی که فرمان در آن اجرا خواهد شد اضافه می‌کند. پارامتر اختیاری permissions می‌تواند برای مشخص کردن مجوزهای دسترسی دستگاه با استفاده از یک یا چند مورد از r برای خواندن (read)،‏ w برای نوشتن (write) و m برای mknod(2) استفاده شود.

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

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

دستگاهی که قرار است به اشتراک گذاشته شود را می‌توان با استفاده از مشخصات واسط دستگاه کانتینر (CDI) نیز تعیین کرد (https://github.com/cncf-tags/container-device-interface).

نکته: اگر کاربر فقط از طریق یک گروه دارای مجوزهای دسترسی باشد، دسترسی به دستگاه از داخل یک کانتینر بدون ریشه (rootless) ناموفق خواهد بود. زمان اجرای crun(1) با افزودن گزینه --annotation run.oci.keep_original_groups=1 راهکاری برای این مشکل ارائه می‌دهد.

--env, -e env=value

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

--hostname

نام میزبان (hostname) را در داخل کانتینر در حال اجرا تنظیم می‌کند.

--ipc how

پیکربندی فضاهای نام IPC را برای کانتینر تنظیم می‌کند. مقدار پیکربندی‌شده می‌تواند "" (رشته خالی) یا "private" باشد تا نشان دهد که باید یک فضای نام IPC جدید ایجاد شود، یا می‌تواند "host" باشد تا نشان دهد فضای نام IPC که خود buildah در آن در حال اجرا است باید بازاستفاده شود، یا می‌تواند مسیر یک فضای نام IPC باشد که هم‌اکنون توسط فرایند دیگری در حال استفاده است.

--isolation type

کنترل می‌کند که چه نوع جداسازی (isolation) برای اجرای فرایند استفاده شود. انواع شناخته‌شده شامل oci (زمان اجرای سازگار با OCI، پیش‌فرض)، rootless (زمان اجرای سازگار با OCI که با استفاده از پیکربندی تغییریافته فراخوانی می‌شود، با اضافه شدن --no-new-keyring به فراخوانی create آن، بازاستفاده از فضاهای نام شبکه و UTS میزبان، و ایجاد فضاهای نام اختصاصی IPC، PID، mount و کاربر؛ پیش‌فرض برای کاربران فاقد امتیاز)، و chroot (یک پوشش داخلی که بیشتر به chroot(1) گرایش دارد تا فناوری کانتینر، با بازاستفاده از فضاهای نام cgroup، شبکه، IPC و PID میزبان، و ایجاد فضاهای نام اختصاصی mount و UTS، و ایجاد فضاهای نام کاربر تنها در صورتی که برای نگاشت شناسه مورد نیاز باشند) هستند.

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

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

متصل کردن (mount) یک سیستم‌فایل به کانتینر

انواع نقطه اتصال (TYPES) پشتیبانی‌شده کنونی شامل bind، cache، secret و tmpfs هستند. تغییرات و نوشتن‌ها در اتصال‌های bind و tmpfs پس از پایان فرمان دور ریخته می‌شوند، در حالی که تغییرات در اتصال‌های cache در بین استفاده‌ها ماندگار خواهند بود.

e.g.
type=bind,source=/path/on/host,destination=/path/in/container
type=tmpfs,tmpfs-size=512M,destination=/path/in/container
type=cache,target=/path/in/container
Common Options (گزینه‌های عمومی):
       · src, source: مشخصات منبع اتصال برای bind و cache. برای bind الزامی است. اگر `from` مشخص شده باشد، `src` زیرمسیر در فیلد `from` خواهد بود.
       · dst, destination, target: مکانی که فرمان در حال اجرا باید محتوای متصل‌شده را در آنجا ببیند.
       · ro, read-only: (پیش‌فرض برای `type=bind` برابر true، برای `type=tmpfs` و `type=cache` برابر false).
       · rw, read-write: (پیش‌فرض برای `type=bind` برابر false، برای `type=tmpfs` و `type=cache` برابر true).
Options specific to bind (گزینه‌های ویژه bind):
       · bind-propagation: مقادیر shared، slave، private، rshared، rslave یا rprivate (پیش‌فرض). همچنین به mount(2) رجوع کنید. [[1]](#Footnote1)
       . bind-nonrecursive: نقطه اتصال bind را به‌صورت بازگشتی برپا نکن. به‌طور پیش‌فرض بازگشتی است.
       · from: نام ایمیج برای ریشه منبع. پیش‌فرض **--contextdir** است، در صورتی که **--contextdir** مشخص نشده باشد اجباری است.
       · src: مکانی در دایرکتوری زمینه (یا ایمیج، در صورتی که گزینه **from** استفاده شده باشد) برای اتصال به جای دایرکتوری سطح بالای آن.
       · z: تنظیم برچسب اشتراکی SELinux روی مقصد متصل‌شده. در صورت فعال بودن SELinux در ماشین میزبان استفاده شود.
       · Z: تنظیم برچسب اختصاصی SELinux روی مقصد متصل‌شده. در صورت فعال بودن SELinux در ماشین میزبان استفاده شود.
Options specific to tmpfs (گزینه‌های ویژه tmpfs):
       · tmpfs-size: اندازه نقطه اتصال tmpfs به بایت. به‌طور پیش‌فرض در لینوکس نامحدود است.
       · tmpfs-mode: حالت فایل مربوط به tmpfs در مبنای هشت. (مانند 700 یا 0700). به‌طور پیش‌فرض در لینوکس 1777 است.
       · tmpcopyup: مسیری که توسط اتصال tmpfs پوشانده شده است به‌طور بازگشتی به درون خود tmpfs کپی می‌شود.
Options specific to secret (گزینه‌های ویژه secret):
       · id: شناسه برای داده‌های محرمانه (secret) ارسال‌شده به فرمان `buildah bud --secret` یا `podman build --secret`.
Options specific to cache (گزینه‌های ویژه cache):
       · id: متمایز ساختن این حافظه نهان از سایر کش‌ها با استفاده از این شناسه، به جای مسیر مقصد اتصال.
       · mode: حالت فایل برای دایرکتوری جدید حافظه نهان در مبنای هشت. پیش‌فرض 0755.
       · src: مکانی در حافظه نهان (یا در ایمیج، در صورتی که گزینه **from** استفاده شده باشد) برای اتصال به جای دایرکتوری سطح بالای آن.
       · uid: شناسه uid برای دایرکتوری حافظه نهان.
       · gid: شناسه gid برای دایرکتوری حافظه نهان.
       · from: نام مرحله (stage) برای ریشه منبع. پیش‌فرض دایرکتوری کش میزبان است.
       · sharing: آیا سایر کاربران این حافظه نهان باید منتظر بمانند تا این فرمان کامل شود (`sharing=locked`) یا خیر (`sharing=shared` که حالت پیش‌فرض است).
       · z: تنظیم برچسب اشتراکی SELinux روی مقصد متصل‌شده. در صورت فعال بودن SELinux در ماشین میزبان به‌طور پیش‌فرض فعال است.
       · Z: تنظیم برچسب اختصاصی SELinux روی مقصد متصل‌شده. در صورت فعال بودن SELinux در ماشین میزبان استفاده شود.

--network, --net=mode

پیکربندی فضای نام شبکه را برای کانتینر تنظیم می‌کند.

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

  • none: بدون شبکه. در صورتی که سازنده با --dns، --dns-option یا --dns-search پیکربندی شده باشد نامعتبر است؛
  • host: استفاده از پشته شبکه میزبان. نکته: حالت host به کانتینر دسترسی کامل به سرویس‌های محلی سیستم مانند D-Bus می‌دهد و بنابراین ناامن تلقی می‌شود؛
  • ns:path: مسیر به یک فضای نام شبکه برای پیوستن به آن؛
  • private: ایجاد یک فضای نام جدید برای کانتینر (پیش‌فرض)
  • <network name|ID>: پیوستن به شبکه با نام یا شناسه داده‌شده، به عنوان نمونه استفاده از --network mynet برای پیوستن به شبکه‌ای با نام mynet. تنها برای کاربران دارای دسترسی ریشه (rootful) پشتیبانی می‌شود.
  • pasta[:OPTIONS,...]: استفاده از pasta(1) برای ایجاد یک پشته شبکه در حالت کاربر (user-mode).
    این گزینه تنها در حالت بدون ریشه (rootless) پشتیبانی می‌شود.
    به‌طور پیش‌فرض، نشانی‌ها و مسیرهای IPv4 و IPv6 و همچنین نام رابط pod از میزبان کپی می‌شوند. اگر هدایت پورت (port forwarding) پیکربندی نشده باشد، با مقید شدن سرویس‌ها در هر طرف (فضای نام init یا فضای نام کانتینر)، پورت‌ها به‌طور پویا هدایت می‌شوند. هدایت پورت نشانی IP مبدأ اولیه را حفظ می‌کند. گزینه‌های شرح‌داده‌شده در pasta(1) را می‌توان به صورت آرگومان‌های جداشده با کاما مشخص کرد.
    از نظر گزینه‌های pasta(1)، گزینه --config-net به‌طور پیش‌فرض ارائه می‌شود تا هنگام راه‌اندازی کانتینر شبکه را پیکربندی کند، و --no-map-gw نیز به‌طور پیش‌فرض فرض می‌شود تا از دسترسی مستقیم کانتینر به میزبان با استفاده از نشانی درگاه (gateway) جلوگیری شود. مورد دوم را می‌توان با ارسال --map-gw در گزینه‌های خاص pasta لغو کرد (با وجود اینکه یک گزینه واقعی pasta(1) نیست).
    همچنین، -t none و -u none برای غیرفعال کردن هدایت خودکار پورت بر پایه پورت‌های مقیدشده ارسال می‌شوند. به‌طور مشابه، -T none و -U none برای غیرفعال کردن قابلیت مشابه از کانتینر به میزبان ارائه می‌شوند.
    چند نمونه:
  • pasta:--map-gw: به کانتینر اجازه می‌دهد با استفاده از نشانی درگاه (gateway) مستقیماً به میزبان دسترسی یابد.
  • 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 جهت بهبود عملکرد

--no-hostname

فایل /etc/hostname را در کانتینر برای دستورالعمل‌های RUN ایجاد نمی‌کند.

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

--no-hosts

فایل /etc/hosts را در کانتینر برای دستورالعمل‌های RUN ایجاد نمی‌کند.

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

--no-pivot

از pivot_root برای محدود کردن فرایند در داخل rootfs استفاده نمی‌کند. این گزینه باید هر زمان که rootfs بر روی یک رم‌دیسک (ramdisk) قرار دارد استفاده شود.

نکته: شما می‌توانید با تنظیم متغیر محیطی BUILDAH_NOPIVOT این گزینه را پیش‌فرض کنید. export BUILDAH_NOPIVOT=true

--pid how

پیکربندی فضای نام PID را برای کانتینر تنظیم می‌کند. مقدار پیکربندی‌شده می‌تواند "" (رشته خالی) یا "private" باشد تا نشان دهد که باید یک فضای نام PID جدید ایجاد شود، یا می‌تواند "host" باشد تا نشان دهد فضای نام PID که خود buildah در آن اجرا می‌شود باید بازاستفاده شود، یا می‌تواند مسیر یک فضای نام PID باشد که پیش‌تر توسط فرایند دیگری در حال استفاده است.

--runtime path

مسیر (path) به یک زمان اجرای جایگزین سازگار با OCI. پیش‌فرض runc است، یا crun زمانی که ماشین برای استفاده از cgroups V2 پیکربندی شده باشد.

نکته: شما همچنین می‌توانید زمان اجرای پیش‌فرض را با تنظیم متغیر محیطی BUILDAH_RUNTIME بازنویسی کنید. export BUILDAH_RUNTIME=/usr/bin/crun

--runtime-flag flag

فلگ‌های سراسری را برای زمان اجرای کانتینر اضافه می‌کند. برای مشاهده فهرست فلگ‌های پشتیبانی‌شده، لطفاً به صفحات راهنمای (manpages) زمان اجرای کانتینر انتخاب‌شده مراجعه کنید. نکته: علامت -- ابتدایی را به فلگ ندهید. برای ارسال فلگ runc به صورت --log-format json به buildah run، گزینه داده‌شده باید به شکل --runtime-flag log-format=json باشد.

--tty, --terminal, -t

به‌طور پیش‌فرض، یک شبه‌ترمینال (pseudo-TTY) تنها زمانی تخصیص می‌یابد که ورودی استاندارد buildah به یک pseudo-TTY متصل باشد. تنظیم گزینه --tty روی true باعث می‌شود یک شبه‌ترمینال درون کانتینر تخصیص یابد که "ترمینال" کاربر را به جریان‌های stdin و stdout کانتینر متصل می‌کند. تنظیم گزینه --tty روی false از تخصیص شبه‌ترمینال جلوگیری خواهد کرد.

--user user[:group]

کاربر (user) مورد استفاده برای اجرای فرمان در کانتینر را تعیین می‌کند. کاربر را می‌توان به عنوان نام کاربری یا UID مشخص کرد که اختیاری می‌تواند همراه با نام گروه یا GID باشد و با یک دونقطه (':') از هم جدا شوند. اگر از نام‌ها استفاده شود، کانتینر باید شامل مدخل‌هایی برای آن نام‌ها در فایل‌های /etc/passwd و /etc/group خود باشد.

--uts how

پیکربندی فضای نام UTS را برای کانتینر تنظیم می‌کند. مقدار پیکربندی‌شده می‌تواند "" (رشته خالی) یا "private" باشد تا نشان دهد که باید یک فضای نام UTS جدید ایجاد شود، یا می‌تواند "host" باشد تا نشان دهد فضای نام UTS که خود buildah در آن در حال اجرا است باید بازاستفاده شود، یا می‌تواند مسیر یک فضای نام UTS باشد که هم‌اکنون توسط فرایند دیگری در حال استفاده است.

--valid-exit-codes exitcode[,exitcode,...]

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

--volume, -v source:destination:options

یک اتصال پیوندی (bind mount) ایجاد می‌کند. اگر مشخص کنید، -v /HOST-DIR:/CONTAINER-DIR، ابزار Buildah مسیر /HOST-DIR در میزبان را به /CONTAINER-DIR در کانتینر Buildah متصل (bind mount) می‌کند. گزینه‌های OPTIONS فهرستی جداشده با کاما هستند و می‌توانند شامل موارد زیر باشند:

  • [rw|ro]
  • [U]
  • [z|Z]
  • [[r]shared|[r]slave|[r]private] [1] ⟨#Footnote1⟩

مسیر CONTAINER-DIR باید یک مسیر مطلق مانند /src/docs باشد. مسیر HOST-DIR نیز باید یک مسیر مطلق باشد. Buildah مسیر HOST-DIR را به مسیری که مشخص می‌کنید bind mount می‌کند. برای نمونه، اگر /foo را به‌عنوان مسیر میزبان بدهید، Buildah محتویات /foo را در سیستم فایل کانتینر روی میزبان کپی کرده و آن را به درون کانتینر bind mount می‌کند.

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

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

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

تغییر مالکیت اتصال‌های حجم (Chowning Volume Mounts)

به‌طور پیش‌فرض، Buildah مالک و گروه دایرکتوری‌های حجم مبدأ متصل‌شده به کانتینرها را تغییر نمی‌دهد. اگر کانتینری در یک فضای نام کاربری جدید ایجاد شود، UID و GID درون کانتینر ممکن است با UID و GID متفاوتی روی میزبان متناظر باشند.

پسوند :U به Buildah می‌گوید تا بر اساس UID و GID درون کانتینر، از UID و GID درست میزبان برای تغییر دادن مالک و گروه حجم مبدأ استفاده کند.

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

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

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

به‌طور پیش‌فرض حجم‌های bind mount شده به‌صورت private هستند. بدین معنا که هرگونه اتصال انجام‌شده درون کانتینر روی میزبان قابل مشاهده نخواهد بود و برعکس. این رفتار را می‌توان با مشخص کردن ویژگی انتشار اتصال حجم (propagation property) تغییر داد.

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

از دستور df <source-dir> برای تعیین نقطه اتصال مبدأ و سپس از findmnt -o TARGET,PROPAGATION <source-mount-dir> برای تعیین ویژگی‌های انتشار نقطه اتصال مبدأ استفاده کنید؛ اگر ابزار findmnt در دسترس نیست، نقطه اتصال مبدأ را می‌توان با نگاه کردن به مدخل اتصال در /proc/self/mountinfo مشخص کرد. به optional fields نگاه کنید و ببینید آیا ویژگی انتشاری مشخص شده است یا خیر. shared:X به این معنی است که نقطه اتصال shared است، master:X به این معنی است که نقطه اتصال slave است و اگر چیزی وجود نداشته باشد به این معنی است که نقطه اتصال private است. [1] ⟨#Footnote1⟩

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

--workingdir directory

دایرکتوری کاری (directory) را به‌طور موقت برای فرایند در حال اجرا تنظیم می‌کند. برخلاف buildah config --workingdir، دایرکتوری کاری برای فراخوانی‌های بعدی buildah run یا ایمیج ساخته‌شده ماندگار نخواهد بود.

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

buildah run containerID -- ps -auxw

buildah run --hostname myhost containerID -- ps -auxw

buildah run containerID -- sh -c 'echo $PATH'

buildah run --runtime-flag log-format=json containerID /bin/bash

buildah run --runtime-flag debug containerID /bin/bash

buildah run --tty containerID /bin/bash

buildah run --tty=false containerID ls /

buildah run --volume /path/on/host:/path/in/container:ro,z containerID sh

buildah run -v /path/on/host:/path/in/container:z,U containerID sh

buildah run --mount type=bind,src=/tmp/on:host,dst=/in:container,ro containerID sh

buildah run --valid-exit-codes 0,1 containerID grep pattern /etc/hosts

buildah(1), buildah-from(1), buildah-config(1), namespaces(7), pid_namespaces(7), crun(1), runc(8), containers.conf(5)

1: پروژه Buildah به فراگیر بودن (شمولیت)، که ارزش اصلی نرم‌افزارهای متن‌باز است، متعهد است. اصطلاحات انتشار سوارکردن (mount propagation) master و slave استفاده‌شده در اینجا مشکل‌ساز و تفرقه‌انگیز هستند و باید تغییر کنند. با این حال، این اصطلاحات در حال حاضر در هسته لینوکس استفاده می‌شوند و در حال حاضر باید به همان شکل استفاده شوند. هنگامی که نگه‌دارندگان هسته این کاربرد را اصلاح کنند، Buildah فوراً از آن پیروی خواهد کرد.

March 2017 buildah