.nh .TH buildah-run "1" "March 2017" "buildah" .SH "نام (NAME)" buildah-run \- اجرای فرمانی در داخل یک کانتینر در حال ساخت .SH "خلاصه دستور (SYNOPSIS)" .PP \fBbuildah run\fP [\fIگزینه‌ها\fP] [\fB--\fP] \fIکانتینر\fP \fIفرمان\fP .SH "توضیحات (DESCRIPTION)" .PP یک کانتینر را راه‌اندازی کرده و فرمان مشخص‌شده را در آن کانتینر با استفاده از سیستم فایل ریشه کانتینر به عنوان سیستم فایل ریشه اجرا می‌کند، در حالی که از تنظیمات پیکربندی به ارث رسیده از ایمیج کانتینر یا تنظیماتی که با استفاده از فراخوانی‌های قبلی دستور \fIbuildah config\fP مشخص شده‌اند استفاده می‌نماید. برای اجرای \fIbuildah run\fP در یک پوسته تعاملی (interactive shell)، گزینه \fB--tty\fR را مشخص کنید. .SH "گزینه‌ها (OPTIONS)" .PP \fB--add-history\fP .PP یک مدخل به تاریخچه اضافه می‌کند که نشان می‌دهد چه فرمانی فراخوانی شده است. پیش‌فرض false است. .PP نکته: شما همچنین می‌توانید مقدار پیش‌فرض \fB--add-history\fR را با تنظیم متغیر محیطی BUILDAH_HISTORY بازنویسی کنید. \fBexport BUILDAH_HISTORY=true\fR .PP \fB--cap-add\fP=\fICAP_xxx\fP .PP قابلیت (capability) مشخص‌شده را به مجموعه قابلیت‌هایی که به فرمان مشخص‌شده اعطا می‌شوند، اضافه می‌کند. برخی قابلیت‌ها به‌طور پیش‌فرض اعطا می‌شوند؛ این گزینه می‌تواند برای افزودن قابلیت‌های بیشتر فراتر از مقادیر پیش‌فرض استفاده شود، که ممکن است پیش‌تر با گزینه‌های \fB--cap-add\fP و \fB--cap-drop\fP در فراخوانی \fIbuildah from\fP که کانتینر را ایجاد کرده است، تغییر یافته باشند. .PP \fB--cap-drop\fP=\fICAP_xxx\fP .PP قابلیت مشخص‌شده را از مجموعه قابلیت‌هایی که به فرمان مشخص‌شده اعطا می‌شوند، حذف می‌کند. قابلیت‌های CAP_CHOWN،‏ CAP_DAC_OVERRIDE،‏ CAP_FOWNER،‏ CAP_FSETID،‏ CAP_KILL،‏ CAP_NET_BIND_SERVICE،‏ CAP_SETFCAP،‏ CAP_SETGID،‏ CAP_SETPCAP و CAP_SETUID به‌طور پیش‌فرض اعطا می‌شوند؛ این گزینه می‌تواند برای حذف آن‌ها از مقادیر پیش‌فرض استفاده شود، که ممکن است با گزینه‌های \fB--cap-add\fP و \fB--cap-drop\fP استفاده‌شده در فراخوانی \fIbuildah from\fP که کانتینر را ایجاد کرده است تغییر یافته باشند. فهرست قابلیت‌های پیش‌فرض در containers.conf(5) مدیریت می‌شود. .PP اگر یک قابلیت هم برای گزینه \fB--cap-add\fP و هم برای گزینه \fB--cap-drop\fP مشخص شود، بدون توجه به ترتیبی که گزینه‌ها داده شده‌اند، حذف خواهد شد. .PP \fB--cgroupns\fP \fIhow\fP .PP پیکربندی فضاهای نام cgroup را برای کانتینر تنظیم می‌کند. مقدار پیکربندی‌شده می‌تواند "" (رشته خالی) یا "private" باشد تا نشان دهد که باید یک فضای نام cgroup جدید ایجاد شود، یا می‌تواند "host" باشد تا نشان دهد فضای نام cgroup که خود \fBbuildah\fR در آن در حال اجرا است باید بازاستفاده شود. .PP \fB--contextdir\fP \fIdirectory\fP .PP امکان تنظیم دایرکتوری زمینه را برای فراخوانی فعلی RUN فراهم می‌کند. مشخص کردن یک دایرکتوری زمینه باعث می‌شود زمینه RUN دایرکتوری زمینه را به عنوان دایرکتوری ریشه برای منبع مشخص‌شده در \fB--mount\fR از نوع 'bind' در نظر بگیرد. .PP \fB--device\fP=\fIdevice\fP .PP یک دستگاه میزبان یا دستگاه‌های موجود در یک دایرکتوری را به محیطی که فرمان در آن اجرا خواهد شد اضافه می‌کند. پارامتر اختیاری \fIpermissions\fP می‌تواند برای مشخص کردن مجوزهای دسترسی دستگاه با استفاده از یک یا چند مورد از \fBr\fP برای خواندن (read)،‏ \fBw\fP برای نوشتن (write) و \fBm\fP برای \fBmknod\fP(2) استفاده شود. .PP مثال: \fB--device=/dev/sdc:/dev/xvdc:rwm\fP\&. .PP نکته: اگر \fIhost-device\fP یک پیوند نمادین (symbolic link) باشد، ابتدا حل‌وفصل می‌شود. کانتینر تنها شماره‌های اصلی (major) و فرعی (minor) دستگاه میزبان را ذخیره خواهد کرد. .PP دستگاهی که قرار است به اشتراک گذاشته شود را می‌توان با استفاده از مشخصات واسط دستگاه کانتینر (CDI) نیز تعیین کرد (https://github.com/cncf-tags/container-device-interface). .PP نکته: اگر کاربر فقط از طریق یک گروه دارای مجوزهای دسترسی باشد، دسترسی به دستگاه از داخل یک کانتینر بدون ریشه (rootless) ناموفق خواهد بود. زمان اجرای \fBcrun\fP(1) با افزودن گزینه \fB--annotation run.oci.keep_original_groups=1\fP راهکاری برای این مشکل ارائه می‌دهد. .PP \fB--env\fP, \fB-e\fP \fIenv=value\fP .PP به‌طور موقت مقداری را (مانند env=\fIvalue\fP) به متغیرهای محیطی فرایند در حال اجرا اضافه می‌کند. برخلاف \fBbuildah config --env\fR، این متغیرها برای فراخوانی‌های بعدی \fBbuildah run\fR یا در ایمیج ساخته‌شده ماندگار نخواهند بود. می‌تواند چندین بار استفاده شود. .PP \fB--hostname\fP .PP نام میزبان (hostname) را در داخل کانتینر در حال اجرا تنظیم می‌کند. .PP \fB--ipc\fP \fIhow\fP .PP پیکربندی فضاهای نام IPC را برای کانتینر تنظیم می‌کند. مقدار پیکربندی‌شده می‌تواند "" (رشته خالی) یا "private" باشد تا نشان دهد که باید یک فضای نام IPC جدید ایجاد شود، یا می‌تواند "host" باشد تا نشان دهد فضای نام IPC که خود \fBbuildah\fR در آن در حال اجرا است باید بازاستفاده شود، یا می‌تواند مسیر یک فضای نام IPC باشد که هم‌اکنون توسط فرایند دیگری در حال استفاده است. .PP \fB--isolation\fP \fItype\fP .PP کنترل می‌کند که چه نوع جداسازی (isolation) برای اجرای فرایند استفاده شود. انواع شناخته‌شده شامل \fIoci\fP (زمان اجرای سازگار با OCI، پیش‌فرض)، \fIrootless\fP (زمان اجرای سازگار با OCI که با استفاده از پیکربندی تغییریافته فراخوانی می‌شود، با اضافه شدن \fI--no-new-keyring\fP به فراخوانی \fIcreate\fP آن، بازاستفاده از فضاهای نام شبکه و UTS میزبان، و ایجاد فضاهای نام اختصاصی IPC، PID، mount و کاربر؛ پیش‌فرض برای کاربران فاقد امتیاز)، و \fIchroot\fP (یک پوشش داخلی که بیشتر به chroot(1) گرایش دارد تا فناوری کانتینر، با بازاستفاده از فضاهای نام cgroup، شبکه، IPC و PID میزبان، و ایجاد فضاهای نام اختصاصی mount و UTS، و ایجاد فضاهای نام کاربر تنها در صورتی که برای نگاشت شناسه مورد نیاز باشند) هستند. .PP نکته: شما همچنین می‌توانید نوع جداسازی پیش‌فرض را با تنظیم متغیر محیطی BUILDAH_ISOLATION بازنویسی کنید. \fBexport BUILDAH_ISOLATION=oci\fR .PP \fB--mount\fP=\fItype=TYPE,TYPE-SPECIFIC-OPTION[,...]\fP .PP متصل کردن (mount) یک سیستم‌فایل به کانتینر .PP انواع نقطه اتصال (\fBTYPES\fR) پشتیبانی‌شده کنونی شامل bind، cache، secret و tmpfs هستند. تغییرات و نوشتن‌ها در اتصال‌های \fBbind\fR و \fBtmpfs\fR پس از پایان فرمان دور ریخته می‌شوند، در حالی که تغییرات در اتصال‌های \fBcache\fR در بین استفاده‌ها ماندگار خواهند بود. .EX 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 در ماشین میزبان استفاده شود. .EE .PP \fB--network\fP, \fB--net\fP=\fImode\fP .PP پیکربندی فضای نام شبکه را برای کانتینر تنظیم می‌کند. .PP مقادیر معتبر \fImode\fP عبارتند از: .RS .IP \(bu 2 \fBnone\fP: بدون شبکه. در صورتی که سازنده با \fB--dns\fP، \fB--dns-option\fP یا \fB--dns-search\fP پیکربندی شده باشد نامعتبر است؛ .IP \(bu 2 \fBhost\fP: استفاده از پشته شبکه میزبان. نکته: حالت host به کانتینر دسترسی کامل به سرویس‌های محلی سیستم مانند D-Bus می‌دهد و بنابراین ناامن تلقی می‌شود؛ .IP \(bu 2 \fBns:\fP\fIpath\fP: مسیر به یک فضای نام شبکه برای پیوستن به آن؛ .IP \(bu 2 \fBprivate\fP: ایجاد یک فضای نام جدید برای کانتینر (پیش‌فرض) .IP \(bu 2 \fB\fP: پیوستن به شبکه با نام یا شناسه داده‌شده، به عنوان نمونه استفاده از \fB--network mynet\fR برای پیوستن به شبکه‌ای با نام mynet. تنها برای کاربران دارای دسترسی ریشه (rootful) پشتیبانی می‌شود. .IP \(bu 2 \fBpasta[:OPTIONS,...]\fP: استفاده از \fBpasta\fP(1) برای ایجاد یک پشته شبکه در حالت کاربر (user-mode). .br این گزینه تنها در حالت بدون ریشه (rootless) پشتیبانی می‌شود. .br به‌طور پیش‌فرض، نشانی‌ها و مسیرهای IPv4 و IPv6 و همچنین نام رابط pod از میزبان کپی می‌شوند. اگر هدایت پورت (port forwarding) پیکربندی نشده باشد، با مقید شدن سرویس‌ها در هر طرف (فضای نام init یا فضای نام کانتینر)، پورت‌ها به‌طور پویا هدایت می‌شوند. هدایت پورت نشانی IP مبدأ اولیه را حفظ می‌کند. گزینه‌های شرح‌داده‌شده در pasta(1) را می‌توان به صورت آرگومان‌های جداشده با کاما مشخص کرد. .br از نظر گزینه‌های pasta(1)، گزینه \fB--config-net\fP به‌طور پیش‌فرض ارائه می‌شود تا هنگام راه‌اندازی کانتینر شبکه را پیکربندی کند، و \fB--no-map-gw\fP نیز به‌طور پیش‌فرض فرض می‌شود تا از دسترسی مستقیم کانتینر به میزبان با استفاده از نشانی درگاه (gateway) جلوگیری شود. مورد دوم را می‌توان با ارسال \fB--map-gw\fP در گزینه‌های خاص pasta لغو کرد (با وجود اینکه یک گزینه واقعی pasta(1) نیست). .br همچنین، \fB-t none\fP و \fB-u none\fP برای غیرفعال کردن هدایت خودکار پورت بر پایه پورت‌های مقیدشده ارسال می‌شوند. به‌طور مشابه، \fB-T none\fP و \fB-U none\fP برای غیرفعال کردن قابلیت مشابه از کانتینر به میزبان ارائه می‌شوند. .br چند نمونه: .RS .IP \(bu 2 \fBpasta:--map-gw\fP: به کانتینر اجازه می‌دهد با استفاده از نشانی درگاه (gateway) مستقیماً به میزبان دسترسی یابد. .IP \(bu 2 \fBpasta:--mtu,1500\fP: مشخص کردن یک MTU به میزان ۱۵۰۰ بایت برای رابط \fItap\fP در کانتینر. .IP \(bu 2 \fBpasta:--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\fP، غیرفعال کردن IPv6، تخصیص \fB10.0.2.0/24\fR به رابط \fBtap0\fR در کانتینر، با درگاه \fB10.0.2.3\fR، فعال‌سازی فورواردر DNS در دسترس در \fB10.0.2.3\fR، تنظیم MTU روی ۱۵۰۰ بایت، غیرفعال کردن پشتیبانی از NDP، DHCPv6 و DHCP. .IP \(bu 2 \fBpasta:-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\fP، همانند بالا، اما باقی گذاشتن MTU روی ۶۵۵۲۰ بایت .IP \(bu 2 \fBpasta:-t,auto,-u,auto,-T,auto,-U,auto\fP: فعال‌سازی هدایت خودکار پورت بر پایه پورت‌های مقیدشده مشاهده‌شده از هر دو سمت میزبان و کانتینر .IP \(bu 2 \fBpasta:-T,5201\fP: فعال‌سازی هدایت پورت TCP شماره ۵۲۰۱ از کانتینر به میزبان، با استفاده از رابط loopback به جای رابط tap جهت بهبود عملکرد .RE .RE .PP \fB--no-hostname\fP .PP فایل \fI/etc/hostname\fP را در کانتینر برای دستورالعمل‌های RUN ایجاد نمی‌کند. .PP به‌طور پیش‌فرض، Buildah فایل \fI/etc/hostname\fP را مدیریت کرده و نام میزبان خود کانتینر را به آن اضافه می‌کند. هنگامی که گزینه \fB--no-hostname\fP تنظیم شود، فایل \fI/etc/hostname\fP ایمیج در صورت وجود بدون تغییر حفظ خواهد شد. .PP \fB--no-hosts\fP .PP فایل \fI/etc/hosts\fP را در کانتینر برای دستورالعمل‌های RUN ایجاد نمی‌کند. .PP به‌طور پیش‌فرض، Buildah فایل \fI/etc/hosts\fP را مدیریت کرده و نشانی IP خود کانتینر را به آن اضافه می‌کند. گزینه \fB--no-hosts\fP این رفتار را غیرفعال کرده و فایل \fI/etc/hosts\fP ایمیج بدون تغییر حفظ خواهد شد. .PP \fB--no-pivot\fP .PP از pivot_root برای محدود کردن فرایند در داخل rootfs استفاده نمی‌کند. این گزینه باید هر زمان که rootfs بر روی یک رم‌دیسک (ramdisk) قرار دارد استفاده شود. .PP نکته: شما می‌توانید با تنظیم متغیر محیطی BUILDAH_NOPIVOT این گزینه را پیش‌فرض کنید. \fBexport BUILDAH_NOPIVOT=true\fR .PP \fB--pid\fP \fIhow\fP .PP پیکربندی فضای نام PID را برای کانتینر تنظیم می‌کند. مقدار پیکربندی‌شده می‌تواند "" (رشته خالی) یا "private" باشد تا نشان دهد که باید یک فضای نام PID جدید ایجاد شود، یا می‌تواند "host" باشد تا نشان دهد فضای نام PID که خود \fBbuildah\fR در آن اجرا می‌شود باید بازاستفاده شود، یا می‌تواند مسیر یک فضای نام PID باشد که پیش‌تر توسط فرایند دیگری در حال استفاده است. .PP \fB--runtime\fP \fIpath\fP .PP مسیر (\fIpath\fP) به یک زمان اجرای جایگزین سازگار با OCI. پیش‌فرض \fBrunc\fR است، یا \fBcrun\fR زمانی که ماشین برای استفاده از cgroups V2 پیکربندی شده باشد. .PP نکته: شما همچنین می‌توانید زمان اجرای پیش‌فرض را با تنظیم متغیر محیطی BUILDAH_RUNTIME بازنویسی کنید. \fBexport BUILDAH_RUNTIME=/usr/bin/crun\fR .PP \fB--runtime-flag\fP \fIflag\fP .PP فلگ‌های سراسری را برای زمان اجرای کانتینر اضافه می‌کند. برای مشاهده فهرست فلگ‌های پشتیبانی‌شده، لطفاً به صفحات راهنمای (manpages) زمان اجرای کانتینر انتخاب‌شده مراجعه کنید. نکته: علامت \fB--\fR ابتدایی را به فلگ ندهید. برای ارسال فلگ runc به صورت \fB--log-format json\fR به buildah run، گزینه داده‌شده باید به شکل \fB--runtime-flag log-format=json\fR\& باشد. .PP \fB--tty\fP, \fB--terminal\fP, \fB-t\fP .PP به‌طور پیش‌فرض، یک شبه‌ترمینال (pseudo-TTY) تنها زمانی تخصیص می‌یابد که ورودی استاندارد buildah به یک pseudo-TTY متصل باشد. تنظیم گزینه \fB--tty\fR روی \fBtrue\fR باعث می‌شود یک شبه‌ترمینال درون کانتینر تخصیص یابد که "ترمینال" کاربر را به جریان‌های stdin و stdout کانتینر متصل می‌کند. تنظیم گزینه \fB--tty\fR روی \fBfalse\fR از تخصیص شبه‌ترمینال جلوگیری خواهد کرد. .PP \fB--user\fP \fIuser\fP[:\fIgroup\fP] .PP کاربر (\fIuser\fP) مورد استفاده برای اجرای فرمان در کانتینر را تعیین می‌کند. کاربر را می‌توان به عنوان نام کاربری یا UID مشخص کرد که اختیاری می‌تواند همراه با نام گروه یا GID باشد و با یک دونقطه (':') از هم جدا شوند. اگر از نام‌ها استفاده شود، کانتینر باید شامل مدخل‌هایی برای آن نام‌ها در فایل‌های \fI/etc/passwd\fP و \fI/etc/group\fP خود باشد. .PP \fB--uts\fP \fIhow\fP .PP پیکربندی فضای نام UTS را برای کانتینر تنظیم می‌کند. مقدار پیکربندی‌شده می‌تواند "" (رشته خالی) یا "private" باشد تا نشان دهد که باید یک فضای نام UTS جدید ایجاد شود، یا می‌تواند "host" باشد تا نشان دهد فضای نام UTS که خود \fBbuildah\fR در آن در حال اجرا است باید بازاستفاده شود، یا می‌تواند مسیر یک فضای نام UTS باشد که هم‌اکنون توسط فرایند دیگری در حال استفاده است. .PP \fB--valid-exit-codes\fP \fIexitcode[,exitcode,...]\fP .PP فهرستی جداشده با کاما از کدهای خروج را که باید موفقیت‌آمیز تلقی شوند مشخص می‌کند. پیش‌فرض \fB0\fP\& است. .PP \fB--volume\fP, \fB-v\fP \fIsource\fP:\fIdestination\fP:\fIoptions\fP .PP یک اتصال پیوندی (bind mount) ایجاد می‌کند. اگر مشخص کنید، \fB-v /HOST-DIR:/CONTAINER-DIR\fR، ابزار Buildah مسیر \fB/HOST-DIR\fR در میزبان را به \fB/CONTAINER-DIR\fR در کانتینر Buildah متصل (bind mount) می‌کند. گزینه‌های \fBOPTIONS\fR فهرستی جداشده با کاما هستند و می‌توانند شامل موارد زیر باشند: .RS .IP \(bu 2 [rw|ro] .IP \(bu 2 [U] .IP \(bu 2 [z|Z] .IP \(bu 2 [\fB[r]shared\fR|\fB[r]slave\fR|\fB[r]private\fR] [1] \[la]#Footnote1\[ra] .RE .PP مسیر \fBCONTAINER-DIR\fR باید یک مسیر مطلق مانند \fB/src/docs\fR\& باشد. مسیر \fBHOST-DIR\fR نیز باید یک مسیر مطلق باشد. Buildah مسیر \fBHOST-DIR\fR را به مسیری که مشخص می‌کنید bind mount می‌کند. برای نمونه، اگر \fB/foo\fR را به‌عنوان مسیر میزبان بدهید، Buildah محتویات \fB/foo\fR را در سیستم فایل کانتینر روی میزبان کپی کرده و آن را به درون کانتینر bind mount می‌کند. .PP می‌توانید چندین گزینه \fB-v\fP را برای متصل کردن یک یا چند نقطه اتصال به یک کانتینر مشخص کنید. .PP \fBاتصال‌های حجم محافظت‌شده در برابر نوشتن (Write Protected Volume Mounts)\fR .PP می‌توانید پسوند \fB:ro\fR یا \fB:rw\fR را به یک حجم اضافه کنید تا به‌ترتیب در حالت فقط‌خواندنی یا خواندنی-نوشتنی متصل شود. به‌طور پیش‌فرض، حجم‌ها به‌صورت خواندنی-نوشتنی متصل می‌شوند. مثال‌ها را ببینید. .PP \fBتغییر مالکیت اتصال‌های حجم (Chowning Volume Mounts)\fR .PP به‌طور پیش‌فرض، Buildah مالک و گروه دایرکتوری‌های حجم مبدأ متصل‌شده به کانتینرها را تغییر نمی‌دهد. اگر کانتینری در یک فضای نام کاربری جدید ایجاد شود، UID و GID درون کانتینر ممکن است با UID و GID متفاوتی روی میزبان متناظر باشند. .PP پسوند \fB:U\fR به Buildah می‌گوید تا بر اساس UID و GID درون کانتینر، از UID و GID درست میزبان برای تغییر دادن مالک و گروه حجم مبدأ استفاده کند. .PP \fBبرچسب‌گذاری اتصال‌های حجم (Labeling Volume Mounts)\fR .PP سیستم‌های برچسب‌گذاری مانند SELinux نیازمند قرارگیری برچسب‌های مناسب روی محتوای حجم متصل‌شده به کانتینر هستند. بدون برچسب، سیستم امنیتی ممکن است از استفاده فرایندهای در حال اجرا درون کانتینر از محتوا جلوگیری کند. به‌طور پیش‌فرض، Buildah برچسب‌های تنظیم‌شده توسط سیستم‌عامل را تغییر نمی‌دهد. .PP برای تغییر یک برچسب در بافت کانتینر، می‌توانید یکی از دو پسوند \fB:z\fR یا \fB:Z\fR را به اتصال حجم اضافه کنید. این پسوندها به Buildah می‌گویند که اشیاء فایل روی حجم‌های اشتراکی را دوباره برچسب‌گذاری کند. گزینه \fBz\fR به Buildah می‌گوید که دو کانتینر محتوای حجم را به اشتراک می‌گذارند. در نتیجه، Buildah محتوا را با یک برچسب محتوای مشترک برچسب‌گذاری می‌کند. برچسب‌های حجم مشترک به همه کانتینرها اجازه خواندن/نوشتن محتوا را می‌دهند. گزینه \fBZ\fR به Buildah می‌گوید که محتوا را با یک برچسب اختصاصی غیرمشترک برچسب‌گذاری کند. تنها کانتینر فعلی می‌تواند از یک حجم اختصاصی استفاده کند. .PP به‌طور پیش‌فرض حجم‌های bind mount شده به‌صورت \fBprivate\fR\& هستند. بدین معنا که هرگونه اتصال انجام‌شده درون کانتینر روی میزبان قابل مشاهده نخواهد بود و برعکس. این رفتار را می‌توان با مشخص کردن ویژگی انتشار اتصال حجم (propagation property) تغییر داد. .PP هنگامی که خط‌مشی انتشار اتصال روی \fBshared\fR تنظیم شود، هرگونه اتصال انجام‌شده درون کانتینر روی آن حجم، هم برای میزبان و هم برای کانتینر قابل مشاهده خواهد بود. هنگامی که خط‌مشی انتشار اتصال روی \fBslave\fR تنظیم شود، انتشار یک‌طرفه اتصال فعال شده و هرگونه اتصال انجام‌شده روی میزبان برای آن حجم تنها درون کانتینر قابل مشاهده خواهد بود. برای کنترل ویژگی انتشار اتصال حجم از فلگ انتشار \fB:[r]shared\fR، \fB:[r]slave\fR یا \fB:[r]private\fR استفاده کنید. ویژگی انتشار را تنها می‌توان برای حجم‌های bind mount شده مشخص کرد، نه حجم‌های داخلی یا حجم‌های نام‌گذاری‌شده. برای اینکه انتشار اتصال روی نقطه اتصال مبدأ (نقطه اتصالی که دایرکتوری مبدأ روی آن متصل شده است) کار کند، باید ویژگی‌های انتشار مناسب را داشته باشد. برای حجم‌های shared، نقطه اتصال مبدأ باید shared باشد. و برای حجم‌های slave، اتصال مبدأ باید shared یا slave باشد. [1] \[la]#Footnote1\[ra] .PP از دستور \fBdf \fR برای تعیین نقطه اتصال مبدأ و سپس از \fBfindmnt -o TARGET,PROPAGATION \fR برای تعیین ویژگی‌های انتشار نقطه اتصال مبدأ استفاده کنید؛ اگر ابزار \fBfindmnt\fR در دسترس نیست، نقطه اتصال مبدأ را می‌توان با نگاه کردن به مدخل اتصال در \fB/proc/self/mountinfo\fR\& مشخص کرد. به \fBoptional fields\fR نگاه کنید و ببینید آیا ویژگی انتشاری مشخص شده است یا خیر. \fBshared:X\fR به این معنی است که نقطه اتصال \fBshared\fR است، \fBmaster:X\fR به این معنی است که نقطه اتصال \fBslave\fR است و اگر چیزی وجود نداشته باشد به این معنی است که نقطه اتصال \fBprivate\fR\& است. [1] \[la]#Footnote1\[ra] .PP برای تغییر ویژگی‌های انتشار یک نقطه اتصال، از دستور \fBmount\fR استفاده کنید. برای نمونه، جهت bind mount کردن دایرکتوری مبدأ \fB/foo\fR، دستورهای \fBmount --bind /foo /foo\fR و \fBmount --make-private --make-shared /foo\fR\& را اجرا کنید. این کار /foo را به یک نقطه اتصال \fBshared\fR تبدیل می‌کند. ویژگی‌های انتشار نقطه اتصال مبدأ را می‌توان مستقیماً تغییر داد. برای نمونه اگر \fB/\fR نقطه اتصال مبدأ برای \fB/foo\fR باشد، از دستور \fBmount --make-shared /\fR استفاده کنید تا \fB/\fR را به یک نقطه اتصال \fBshared\fR تبدیل نماید. .PP \fB--workingdir\fP \fIdirectory\fP .PP دایرکتوری کاری (\fIdirectory\fP) را به‌طور موقت برای فرایند در حال اجرا تنظیم می‌کند. برخلاف \fBbuildah config --workingdir\fR، دایرکتوری کاری برای فراخوانی‌های بعدی \fBbuildah run\fR یا ایمیج ساخته‌شده ماندگار نخواهد بود. .PP نکته: تجزیه گزینه‌ها را با گزینه \fB--\fR خاتمه دهید، تا گزینه‌های دیگر بتوانند به فرمان داخل کانتینر ارسال شوند. .SH "مثال‌ها (EXAMPLES)" .PP buildah run containerID -- ps -auxw .PP buildah run --hostname myhost containerID -- ps -auxw .PP buildah run containerID -- sh -c 'echo $PATH' .PP buildah run --runtime-flag log-format=json containerID /bin/bash .PP buildah run --runtime-flag debug containerID /bin/bash .PP buildah run --tty containerID /bin/bash .PP buildah run --tty=false containerID ls / .PP buildah run --volume /path/on/host:/path/in/container:ro,z containerID sh .PP buildah run -v /path/on/host:/path/in/container:z,U containerID sh .PP buildah run --mount type=bind,src=/tmp/on:host,dst=/in:container,ro containerID sh .PP buildah run --valid-exit-codes 0,1 containerID grep pattern /etc/hosts .SH "همچنین ببینید (SEE ALSO)" .PP buildah(1), buildah-from(1), buildah-config(1), namespaces(7), pid_namespaces(7), crun(1), runc(8), containers.conf(5) .SH "پاورقی‌ها (FOOTNOTES)" .PP 1: پروژه Buildah به فراگیر بودن (شمولیت)، که ارزش اصلی نرم‌افزارهای متن‌باز است، متعهد است. اصطلاحات انتشار سوارکردن (mount propagation) \fBmaster\fR و \fBslave\fR استفاده‌شده در اینجا مشکل‌ساز و تفرقه‌انگیز هستند و باید تغییر کنند. با این حال، این اصطلاحات در حال حاضر در هسته لینوکس استفاده می‌شوند و در حال حاضر باید به همان شکل استفاده شوند. هنگامی که نگه‌دارندگان هسته این کاربرد را اصلاح کنند، Buildah فوراً از آن پیروی خواهد کرد.