.nh .TH buildah-from "1" "March 2017" "buildah" .SH "نام (NAME)" .PP buildah-from - یک کانتینر کاری جدید، چه از ابتدا (scratch) و چه با استفاده از یک تصویر مشخص به عنوان نقطه شروع ایجاد می‌کند. .SH "خلاصه دستور (SYNOPSIS)" .PP \fBbuildah from\fP [\fIoptions\fP] \fIimage\fP .SH "توضیحات (DESCRIPTION)" .PP یک کانتینر کاری بر پایه نام تصویر مشخص‌شده ایجاد می‌کند. اگر نام تصویر ارائه‌شده "scratch" باشد، یک کانتینر خالی جدید ایجاد می‌شود. نام‌های تصاویر از قالب "transport":"details" استفاده می‌کنند. .PP چندین روش انتقال (transports) پشتیبانی می‌شوند: .PP \fBdir:\fP\fIpath\fP یک مسیر دایرکتوری محلی موجود (\fIpath\fP) شامل مانیفست، بایگانی‌های تار لایه‌ها و امضاها در فایل‌های جداگانه. این یک قالب غیراستاندارد است که عمدتاً برای اشکال‌زدایی یا بازرسی بدون تغییر تصویر کاربرد دارد. .PP \fBdocker://\fP\fIdocker-reference\fP (پیش‌فرض) تصویری در یک رجیستری که "Docker Registry HTTP API V2" را پیاده‌سازی می‌کند. به‌طور پیش‌فرض، از وضعیت مجوزدهی در \fB$XDG_RUNTIME_DIR/containers/auth.json\fR استفاده می‌کند، که با استفاده از \fB(buildah login)\fR\& تنظیم می‌شود. برای اطلاعات بیشتر به containers-auth.json(5) مراجعه کنید. اگر وضعیت مجوزدهی در آنجا یافت نشود، \fB$HOME/.docker/config.json\fR بررسی می‌شود که با استفاده از \fB(docker login)\fR\& تنظیم شده است. اگر \fIdocker-reference\fP شامل نام رجیستری نباشد، ابتدا با \fIlocalhost\fP مشورت می‌شود و سپس با هر رجیستری نام‌برده‌شده در پیکربندی registries. .PP \fBdocker-archive:\fP\fIpath\fP تصویر به صورت فایلی با قالب \fBpodman load\fR بازیابی می‌شود. .PP \fBdocker-daemon:\fP\fIdocker-reference\fP تصویری با \fIdocker-reference\fP که در فضای ذخیره‌سازی داخلی دیمن داکر ذخیره شده است. \fIdocker-reference\fP باید شامل یک برچسب (tag) یا دایجست (digest) باشد. همچنین هنگام خواندن تصاویر، قالب می‌تواند به صورت docker-daemon:algo:digest (شناسه تصویر) نیز باشد. .PP \fBoci:\fP\fIpath\fP\fB:\fP\fItag\fP** یک برچسب تصویر در یک دایرکتوری سازگار با "Open Container Image Layout Specification" در \fIpath\fP\&. .PP \fBoci-archive:\fP\fIpath\fP\fB:\fP\fItag\fP یک برچسب تصویر (\fItag\fP) در یک دایرکتوری سازگار با "Open Container Image Layout Specification" در \fIpath\fP\&. .SS "وابستگی‌ها (DEPENDENCIES)" .PP ابزار Buildah مسیر رجیستری برای واکشی (pull) را با استفاده از فایل /etc/containers/registries.conf،‏ containers-registries.conf(5) حل‌وفصل می‌کند. اگر دستور \fBbuildah from\fR با خطای "image not known" مواجه شد، ابتدا بررسی کنید که فایل registries.conf نصب و به درستی پیکربندی شده باشد. .SH "مقدار بازگشتی (RETURN VALUE)" .PP شناسه کانتینر (container ID) مربوط به کانتینری که ایجاد شده است. در صورت بروز خطا 1 بازگردانده می‌شود. .SH "گزینه‌ها (OPTIONS)" .PP \fB--add-host\fP=[] .PP افزودن یک نگاشت سفارشی میزبان به IP (host:ip) .PP افزودن یک خط به /etc/hosts. قالب به صورت hostname:ip است. گزینه \fB--add-host\fP می‌تواند چندین بار تعیین شود. .PP \fB--arch\fP="ARCH" .PP تنظیم ARCH تصویر مورد نظر برای واکشی روی مقدار ارائه‌شده به جای استفاده از معماری میزبان. (نمونه‌ها: arm، arm64، 386، amd64، ppc64le، s390x) .PP \fB--authfile\fP \fIpath\fP .PP مسیر فایل احراز هویت. پیش‌فرض ${XDG_RUNTIME_DIR}/containers/auth.json است. برای اطلاعات بیشتر به containers-auth.json(5) مراجعه کنید. این فایل با استفاده از \fBbuildah login\fR\& ایجاد می‌شود. .PP اگر وضعیت مجوزدهی در آنجا یافت نشود، $HOME/.docker/config.json بررسی می‌شود که با استفاده از \fBdocker login\fR\& تنظیم شده است. .PP نکته: همچنین می‌توانید مسیر پیش‌فرض فایل احراز هویت را با تنظیم متغیر محیطی REGISTRY_AUTH_FILE بازنویسی کنید. \fBexport REGISTRY_AUTH_FILE=path\fR .PP \fB--cap-add\fP=\fICAP_xxx\fP .PP افزودن قابلیت (capability) مشخص‌شده به مجموعه پیش‌فرض قابلیت‌هایی که برای فراخوانی‌های بعدی \fIbuildah run\fP که از این کانتینر استفاده می‌کنند، ارائه خواهد شد. برخی قابلیت‌ها به‌طور پیش‌فرض اعطا می‌شوند؛ این گزینه می‌تواند برای افزودن موارد بیشتر استفاده شود. .PP \fB--cap-drop\fP=\fICAP_xxx\fP .PP حذف قابلیت مشخص‌شده از مجموعه پیش‌فرض قابلیت‌هایی که برای فراخوانی‌های بعدی \fIbuildah run\fP که از این کانتینر استفاده می‌کنند، ارائه خواهد شد. قابلیت‌های CAP_CHOWN، CAP_DAC_OVERRIDE، CAP_FOWNER، CAP_FSETID، CAP_KILL، CAP_NET_BIND_SERVICE، CAP_SETFCAP، CAP_SETGID، CAP_SETPCAP و CAP_SETUID به‌طور پیش‌فرض اعطا می‌شوند؛ این گزینه می‌تواند برای حذف آن‌ها استفاده شود. فهرست قابلیت‌های پیش‌فرض در containers.conf(5) مدیریت می‌شود. .PP اگر یک قابلیت هم برای گزینه \fB--cap-add\fP و هم برای گزینه \fB--cap-drop\fP مشخص شود، صرف‌نظر از ترتیبی که گزینه‌ها داده شده‌اند، حذف خواهد شد. .PP \fB--cert-dir\fP \fIpath\fP .PP استفاده از گواهی‌ها در \fIpath\fP (*\&.crt، *\&.cert، *\&.key) برای اتصال به رجیستری. دایرکتوری پیش‌فرض گواهی‌ها \fI/etc/containers/certs.d\fP\& است. .PP \fB--cgroup-parent\fP="" .PP مسیر cgroups که cgroup کانتینر تحت آن ایجاد خواهد شد. اگر مسیر مطلق نباشد، مسیر نسبت به مسیر cgroups فرایند init در نظر گرفته می‌شود. اگر cgroups از قبل وجود نداشته باشند، ایجاد خواهند شد. .PP \fB--cgroupns\fP \fIhow\fP .PP تنظیمات فضاهای نام IPC را زمانی که کانتینر متعاقباً برای \fBbuildah run\fR\& استفاده می‌شود پیکربندی می‌کند. مقدار پیکربندی‌شده می‌تواند "" (رشته خالی) یا "private" برای نشان دادن اینکه یک فضای نام cgroup جدید باید ایجاد شود، یا "host" برای نشان دادن اینکه فضای نام cgroup که خود \fBbuildah\fR در آن در حال اجرا است باید دوباره استفاده شود، باشد. .PP \fB--cidfile\fP \fIContainerIDFile\fP .PP نوشتن شناسه کانتینر در فایل. .PP \fB--cpu-period\fP=\fI0\fP .PP محدود کردن دوره CFS (زمان‌بند کاملاً منصفانه) پردازنده .PP محدود کردن استفاده کانتینر از پردازنده. این پرچم به هسته می‌گوید استفاده کانتینر از پردازنده را به دوره‌ای که مشخص می‌کنید محدود کند. .PP \fB--cpu-quota\fP=\fI0\fP .PP محدود کردن سهمیه CFS (زمان‌بند کاملاً منصفانه) پردازنده .PP محدود کردن استفاده کانتینر از پردازنده. به‌طور پیش‌فرض، کانتینرها با منابع کامل پردازنده اجرا می‌شوند. این پرچم به هسته می‌گوید استفاده کانتینر از پردازنده را به سهمیه‌ای که مشخص می‌کنید محدود کند. .PP \fB--cpu-shares\fP, \fB-c\fP=\fI0\fP .PP سهم‌های پردازنده (وزن نسبی) .PP به‌طور پیش‌فرض، همه کانتینرها سهم یکسانی از چرخه‌های پردازنده دریافت می‌کنند. این نسبت می‌تواند با تغییر وزن سهم پردازنده کانتینر نسبت به وزن سایر کانتینرهای در حال اجرا اصلاح شود. .PP برای تغییر نسبت از مقدار پیش‌فرض 1024، از پرچم \fB--cpu-shares\fP برای تنظیم وزن به 2 یا بالاتر استفاده کنید. .PP این نسبت تنها زمانی اعمال خواهد شد که فرایندهای با بار پردازشی بالا در حال اجرا باشند. هنگامی که وظایف در یک کانتینر بیکار هستند، کانتینرهای دیگر می‌توانند از زمان پردازنده باقی‌مانده استفاده کنند. مقدار واقعی زمان پردازنده بسته به تعداد کانتینرهای در حال اجرا روی سیستم متغیر خواهد بود. .PP به عنوان مثال، سه کانتینر را در نظر بگیرید که یکی دارای cpu-share معادل 1024 و دو کانتینر دیگر دارای تنظیم cpu-share برابر با 512 هستند. هنگامی که فرایندها در هر سه کانتینر تلاش می‌کنند از %100 پردازنده استفاده کنند، کانتینر اول %50 از کل زمان پردازنده را دریافت خواهد کرد. اگر کانتینر چهارمی با cpu-share معادل 1024 اضافه کنید، کانتینر اول تنها %33 از پردازنده را دریافت می‌کند. کانتینرهای باقی‌مانده %16.5، %16.5 و %33 از پردازنده را دریافت خواهند کرد. .PP روی یک سیستم چند‌هسته‌ای، سهم‌های زمان پردازنده میان تمام هسته‌های پردازنده توزیع می‌شود. حتی اگر یک کانتینر به کمتر از %100 زمان پردازنده محدود شده باشد، می‌تواند از %100 هر هسته پردازنده به صورت جداگانه استفاده کند. .PP به عنوان مثال، سیستمی با بیش از سه هسته را در نظر بگیرید. اگر یک کانتینر \fB{C0}\fP را با \fB-c=512\fP در حال اجرای یک فرایند، و کانتینر دیگری \fB{C1}\fP را با \fB-c=1024\fP در حال اجرای دو فرایند راه‌اندازی کنید، این کار می‌تواند منجر به تقسیم سهم‌های پردازنده به شکل زیر شود: .EX PID container CPU CPU share 100 {C0} 0 100% of CPU0 101 {C1} 1 100% of CPU1 102 {C1} 2 100% of CPU2 .EE .PP \fB--cpuset-cpus\fP="" .PP پردازنده‌هایی که اجازه اجرا در آن‌ها داده می‌شود (0-3, 0,1) .PP \fB--cpuset-mems\fP="" .PP گره‌های حافظه (MEMها) که اجازه اجرا در آن‌ها داده می‌شود (0-3, 0,1). تنها روی سیستم‌های NUMA موثر است. .PP اگر چهار گره حافظه روی سیستم خود دارید (0-3)، از \fB--cpuset-mems=0,1\fR استفاده کنید؛ آنگاه فرایندها در کانتینر شما تنها از حافظه دو گره نخست حافظه استفاده خواهند کرد. .PP \fB--creds\fP \fIcreds\fP .PP مقدار [username[:password]] برای استفاده در احراز هویت با رجیستری در صورت نیاز. اگر یک یا هر دو مقدار ارائه نشوند، یک اعلان در خط فرمان ظاهر می‌شود و مقدار می‌تواند وارد شود. گذرواژه بدون بازتاب وارد می‌شود. .PP \fB--decryption-key\fP \fIkey[:passphrase]\fP .PP مقدار [key[:passphrase]] برای استفاده در رمزگشایی تصاویر. کلید می‌تواند به کلیدها و/یا گواهی‌ها اشاره کند. رمزگشایی با تمام کلیدها امتحان خواهد شد. اگر کلید با یک عبارت عبور (passphrase) محافظت شده باشد، ارسال آن در آرگومان الزامی است و در غیر این صورت حذف می‌شود. .PP \fB--device\fP=\fIdevice\fP .PP افزودن یک دستگاه میزبان، یا دستگاه‌های زیر یک دایرکتوری، به محیط فراخوانی‌های بعدی \fBbuildah run\fP برای کانتینر کاری جدید. پارامتر اختیاری \fIpermissions\fP می‌تواند برای مشخص کردن مجوزهای دستگاه با استفاده از یک یا چند مورد از \fBr\fP برای خواندن، \fBw\fP برای نوشتن و \fBm\fP برای \fBmknod\fP(2) استفاده شود. .PP مثال: \fB--device=/dev/sdc:/dev/xvdc:rwm\fP\&. .PP نکته: اگر \fIhost-device\fP یک پیوند نمادین (symbolic link) باشد، ابتدا حل‌وفصل خواهد شد. کانتینر تنها شماره‌های عمده (major) و جزئی (minor) دستگاه میزبان را ذخیره خواهد کرد. .PP دستگاه برای اشتراک‌گذاری همچنین می‌تواند با استفاده از مشخصات واسط دستگاه کانتینر (CDI - Container Device Interface) مشخص شود (https://github.com/cncf-tags/container-device-interface). .PP نکته: اگر کاربر تنها از طریق یک گروه دارای حقوق دسترسی باشد، دسترسی به دستگاه از داخل یک کانتینر بدون ریشه (rootless) ناموفق خواهد بود. زمان اجرای \fBcrun\fP(1) با افزودن گزینه \fB--annotation run.oci.keep_original_groups=1\fP\& راهکاری برای این مورد ارائه می‌دهد. .PP \fB--dns\fP=[] .PP تنظیم سرورهای DNS سفارشی .PP این گزینه می‌تواند برای بازنویسی پیکربندی DNS ارائه‌شده به کانتینر استفاده شود. معمولاً زمانی این کار لازم است که پیکربندی DNS میزبان برای کانتینر نامعتبر باشد (برای نمونه 127.0.0.1). در این حالت، پرچم \fB--dns\fR برای هر بار اجرا ضروری است. .PP مقدار ویژه \fBnone\fP می‌تواند برای غیرفعال کردن ایجاد /etc/resolv.conf در کانتینر توسط Buildah تعیین شود. فایل /etc/resolv.conf موجود در تصویر بدون تغییر استفاده خواهد شد. .PP \fB--dns-option\fP=[] .PP تنظیم گزینه‌های DNS سفارشی .PP \fB--dns-search\fP=[] .PP تنظیم دامنه‌های جستجوی DNS سفارشی .PP \fB--format\fP, \fB-f\fP \fIoci\fP | \fIdocker\fP .PP کنترل قالب برای مانیفست و داده‌های پیکربندی تصویر ساخته‌شده. قالب‌های شناخته‌شده شامل \fIoci\fP (مشخصات OCI image-spec v1.0، پیش‌فرض) و \fIdocker\fP (نسخه 2، با استفاده از قالب شِمای 2 برای مانیفست) هستند. .PP نکته: همچنین می‌توانید قالب پیش‌فرض را با تنظیم متغیر محیطی BUILDAH_FORMAT بازنویسی کنید. \fBexport BUILDAH_FORMAT=docker\fR .PP \fB--group-add\fP=\fIgroup\fP | \fIkeep-groups\fP .PP اختصاص گروه‌های اضافی به کاربر اصلی در حال اجرا درون فرایند کانتینر. .RS .IP \(bu 2 \fBkeep-groups\fR یک پرچم ویژه است که به Buildah اعلام می‌کند دسترسی به گروه‌های تکمیلی (supplementary group access) را حفظ کند\&. .RE .PP به کانتینر اجازه می‌دهد از دسترسی گروه تکمیلی کاربر استفاده کند\&. اگر سامانه‌های پرونده یا دستگاه‌ها تنها از طریق گروه کاربر بدون ریشه (rootless) قابل دسترسی باشند، این پرچم به زمان اجرای OCI اعلام می‌کند که دسترسی گروه را به درون کانتینر منتقل کند\&. در حال حاضر تنها با زمان اجرای OCI موسوم به \fBcrun\fR در دسترس است\&. توجه: \fBkeep-groups\fR مانعة‌الجمع است و گروه‌های دیگر را نمی‌توان با این پرچم مشخص کرد\&. .PP \fB--http-proxy\fP .PP به‌طور پیش‌فرض، در صورتی که متغیرهای محیطی پیشکار (proxy) برای فرایند Buildah تنظیم شده باشند، به درون کانتینر منتقل می‌شوند\&. این رفتار را می‌توان با تنظیم گزینه \fB--http-proxy\fR روی \fBfalse\fR غیرفعال کرد\&. متغیرهای محیطی منتقل‌شده شامل \fBhttp_proxy\fR، \fBhttps_proxy\fR، \fBftp_proxy\fR، \fBno_proxy\fR و همچنین نگارش‌های با حروف بزرگ آن‌ها هستند\&. .PP پیش‌فرض \fBtrue\fR است\&. .PP \fB--ipc\fP \fIhow\fP .PP پیکربندی فضاهای نام IPC را برای زمانی که کانتینر متعاقباً در \fBbuildah run\fR استفاده شود، تنظیم می‌کند\&. مقدار پیکربندی‌شده می‌تواند "" (رشته خالی) یا "container" باشد تا نشان دهد که باید یک فضای نام IPC جدید ساخته شود، یا می‌تواند "host" باشد تا نشان دهد فضای نام IPC که خود \fBBuildah\fR در آن اجرا می‌شود باید بازاستفاده شود، یا می‌تواند مسیر یک فضای نام IPC باشد که پیش‌تر توسط فرایند دیگری در حال استفاده است\&. .PP \fB--isolation\fP \fItype\fP .PP کنترل می‌کند چه نوع جداسازی (isolation) برای اجرای فرایندها تحت \fBbuildah run\fR به کار رود\&. نوع‌های شناخته‌شده عبارتند از \fIoci\fP (زمان اجرای سازگار با OCI، پیش‌فرض)، \fIrootless\fP (زمان اجرای سازگار با OCI که با پیکربندی تغییریافته فراخوانی می‌شود، همراه با افزودن \fI--no-new-keyring\fP به فراخوانی \fIcreate\fP آن، با استفاده مجدد از فضاهای نام شبکه و UTS میزبان، و ایجاد فضاهای نام اختصاصی IPC، PID، سوار کردن (mount) و کاربر؛ پیش‌فرض برای کاربران بدون امتیاز)، و \fIchroot\fP (یک لفاف داخلی که بیشتر به chroot(1) تمایل دارد تا فناوری کانتینر، با بازاستفاده از فضاهای نام گروه کنترل، شبکه، IPC و PID میزبان، و ایجاد فضاهای نام اختصاصی سوار کردن و UTS، و ایجاد فضاهای نام کاربر تنها هنگامی که برای نگاشت شناسه مورد نیاز باشند)\&. .PP توجه: همچنین می‌توانید با مقداردهی متغیر محیطی BUILDAH_ISOLATION، نوع جداسازی پیش‌فرض را بازنویسی کنید\&. \fBexport BUILDAH_ISOLATION=oci\fR .PP \fB--memory\fP, \fB-m\fP="" .PP محدودیت حافظه (قالب: []، که در آن واحد می‌تواند b، k، m یا g باشد) .PP به شما امکان می‌دهد حافظه در دسترس کانتینر را محدود کنید\&. اگر میزبان از حافظه swap پشتیبانی کند، تنظیم حافظه \fB-m\fP می‌تواند بزرگ‌تر از رم (RAM) فیزیکی باشد\&. اگر محدودیت 0 مشخص شود (عدم استفاده از \fB-m\fP)، حافظه کانتینر محدود نمی‌شود\&. محدودیت واقعی ممکن است به ضریبی از اندازه صفحه سیستم‌عامل گرد شود (این مقدار بسیار بزرگ خواهد بود، یعنی میلیون‌ها تریلیون)\&. .PP \fB--memory-swap\fP="LIMIT" .PP یک مقدار محدودیت برابر با مجموع حافظه به علاوه swap\&. باید همراه با پرچم \fB-m\fP (\fB--memory\fP) استفاده شود\&. مقدار \fBLIMIT\fR برای swap همواره باید بزرگ‌تر از مقدار \fB-m\fP (\fB--memory\fP) باشد\&. به‌طور پیش‌فرض، مقدار \fBLIMIT\fR برای swap روی دو برابر مقدار --memory تنظیم خواهد شد\&. .PP قالب \fBLIMIT\fR به‌صورت \fB[]\fR است\&. واحد می‌تواند \fBb\fR (بایت)، \fBk\fR (کیلوبایت)، \fBm\fR (مگابایت) یا \fBg\fR (گیگابایت) باشد\&. اگر واحدی مشخص نکنید، \fBb\fR به کار می‌رود\&. برای فعال‌سازی swap نامحدود، مقدار LIMIT را روی \fB-1\fR قرار دهید\&. .PP \fB--name\fP \fIname\fP .PP یک \fIname\fP (نام) برای کانتینر کاری .PP \fB--network\fP=\fImode\fP, \fB--net\fP=\fImode\fP .PP پیکربندی فضاهای نام شبکه را برای زمانی که کانتینر متعاقباً در \fBbuildah run\fR استفاده شود، تنظیم می‌کند\&. .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--os\fP="OS" .PP تنظیم سیستم‌عامل تصویری که باید واکشی شود روی مقدار ارائه‌شده، به جای استفاده از سیستم‌عامل کنونی میزبان\&. .PP \fB--pid\fP \fIhow\fP .PP پیکربندی فضاهای نام PID را برای زمانی که کانتینر متعاقباً در \fBbuildah run\fR استفاده شود، تنظیم می‌کند\&. مقدار پیکربندی‌شده می‌تواند "" (رشته خالی) یا "container" باشد تا نشان دهد که باید یک فضای نام PID جدید ایجاد شود، یا می‌تواند "host" باشد تا نشان دهد فضای نام PID که خود \fBBuildah\fR در آن اجرا می‌شود باید بازاستفاده شود، یا می‌تواند مسیر یک فضای نام PID باشد که پیش‌تر توسط فرایند دیگری در حال استفاده است\&. .PP \fB--platform\fP="OS/ARCH[/VARIANT]" .PP تنظیم OS/ARCH تصویر مورد نظر برای واکشی روی مقدار ارائه‌شده به جای استفاده از سیستم‌عامل و معماری کنونی میزبان (به عنوان نمونه \fBlinux/arm\fR)\&. .PP جفت‌های OS/ARCH مواردی هستند که توسط زبان برنامه‌نویسی Go استفاده می‌شوند\&. در چندین مورد، مقدار ARCH برای یک پلتفرم با مقدار تولیدشده توسط ابزارهای دیگر مانند دستور \fBarch\fR تفاوت دارد\&. ترکیب‌های معتبر نام سیستم‌عامل و معماری به عنوان مقادیر $GOOS و $GOARCH در نشانی https://golang.org/doc/install/source#environment فهرست شده‌اند و همچنین با اجرای دستور \fBgo tool dist list\fR قابل یافتن هستند\&. .PP اگرچه \fBbuildah from\fR با کمال میل تصویری را برای هر پلتفرم موجود واکشی می‌کند، اما \fBbuildah run\fR بدون کمک شبیه‌سازی ارائه‌شده توسط بسته‌هایی مانند \fBqemu-user-static\fR قادر به اجرای باینری‌های ارائه‌شده توسط آن تصویر نخواهد بود\&. .PP \fBیادداشت (NOTE):\fP گزینه \fB--platform\fR نباید در ترکیب با گزینه‌های \fB--arch\fR، \fB--os\fR یا \fB--variant\fR استفاده شود\&. .PP \fB--pull\fP .PP سیاست واکشی تصویر (Pull image policy)\&. در صورت عدم تعیین، مقدار پیش‌فرض \fBmissing\fP است\&. اگر یک آرگومان صریح \fB--pull\fP بدون هیچ مقداری ارائه شود، رفتار \fBalways\fP به کار می‌رود\&. .RS .IP \(bu 2 \fBalways\fP: دریافت (Pull) تصویر پایه و تصاویر پایشگر SBOM از مخازن فهرست‌شده در registries.conf. اگر تصویر پایه یا تصویر پایشگر SBOM در مخازن یافت نشود، حتی در صورتی که تصویری با همان نام به صورت محلی وجود داشته باشد، خطا ایجاد می‌شود. .IP \(bu 2 \fBmissing\fP: دریافت تصاویر پایشگر SBOM تنها در صورتی که در فضای ذخیره‌سازی محلی کانتینرها یافت نشوند. در صورتی که هیچ تصویری یافت نشود و فرایند دریافت با شکست مواجه شود، خطا صادر می‌شود. .IP \(bu 2 \fBnever\fP: عدم دریافت تصویر پایه و تصاویر پایشگر SBOM از مخازن؛ تنها از نسخه‌های محلی استفاده می‌شود. در صورتی که تصویر به صورت محلی موجود نباشد، خطا رخ می‌دهد. .IP \(bu 2 \fBnewer\fP: دریافت تصویر پایه و تصاویر پایشگر SBOM از مخازن فهرست‌شده در registries.conf در صورت جدیدتر بودن. اگر تصویری با همان نام به صورت محلی وجود نداشته باشد و تصویر پایه یا تصویر پایشگر SBOM در مخازن یافت نشود، خطا صادر می‌شود. .RE .PP \fB--quiet\fP, \fB-q\fP .PP در صورتی که نیاز به دریافت تصویر از مخزن باشد، از نمایش روند پیشرفت جلوگیری می‌کند. .PP \fB--retry\fP \fIattempts\fP .PP تعداد دفعات تلاش مجدد در صورت بروز خطا هنگام دریافت تصاویر از مخزن. .PP مقدار پیش‌فرض \fB3\fR\& است. .PP \fB--retry-delay\fP \fIduration\fP .PP مدت‌زمان تاخیر بین تلاش‌های مجدد در صورت بروز خطا هنگام دریافت تصاویر از مخزن. .PP مقدار پیش‌فرض \fB2s\fR\& است. .PP \fB--security-opt\fP=[] .PP گزینه‌های امنیتی (Security Options) .PP "label=user:USER" : تنظیم کاربر برچسب برای کانتینر "label=role:ROLE" : تنظیم نقش برچسب برای کانتینر "label=type:TYPE" : تنظیم نوع برچسب برای کانتینر "label=level:LEVEL" : تنظیم سطح برچسب برای کانتینر "label=disable" : غیرفعال‌سازی محدودسازی برچسب برای کانتینر "no-new-privileges" : جلوگیری از دستیابی فرایندهای کانتینر به مجوزهای بیشتر .PP "seccomp=unconfined" : غیرفعال‌سازی محدودسازی seccomp برای کانتینر "seccomp=profile.json : فایل JSON شامل فراخوان‌های سیستمی مجاز برای استفاده به عنوان فیلتر seccomp .PP "apparmor=unconfined" : غیرفعال‌سازی محدودسازی apparmor برای کانتینر "apparmor=your-profile" : تنظیم نمایه محدودسازی apparmor برای کانتینر .PP \fB--shm-size\fP="" .PP اندازه \fB/dev/shm\fR\&. قالب آن به صورت \fB\fR\& است. مقدار \fBnumber\fR باید بزرگتر از \fB0\fR\& باشد. واحد اختیاری است و می‌تواند \fBb\fR (بایت)، \fBk\fR (کیلوبایت)، \fBm\fR (مگابایت) یا \fBg\fR (گیگابایت) باشد. اگر واحد حذف شود، سیستم از بایت استفاده می‌کند. اگر اندازه به طور کامل حذف شود، سیستم از \fB64m\fR\& استفاده می‌کند. .PP \fB--tls-verify\fP \fIbool-value\fP .PP الزام استفاده از HTTPS و اعتبارسنجی گواهی‌ها هنگام برقراری ارتباط با مخازن کانتینر (پیش‌فرض true است). هنگام برقراری ارتباط با یک مخزن ناامن نمی‌توان از اعتبارسنجی TLS استفاده کرد. .PP \fB--ulimit\fP \fItype\fP=\fIsoft-limit\fP[:\fIhard-limit\fP] .PP محدودیت‌های منابع را برای اعمال روی فرایندهای اجراشده هنگام \fBbuildah run\fR\& تعیین می‌کند. این گزینه می‌تواند چندین بار مشخص شود. انواع منابع شناخته‌شده عبارتند از: "core": حداکثر اندازه تخلیه حافظه هسته (ulimit -c) "cpu": حداکثر زمان پردازنده (ulimit -t) "data": حداکثر اندازه بخش داده‌های یک فرایند (ulimit -d) "fsize": حداکثر اندازه فایل‌های جدید (ulimit -f) "locks": حداکثر تعداد قفل‌های فایل (ulimit -x) "memlock": حداکثر مقدار حافظه قفل‌شده (ulimit -l) "msgqueue": حداکثر مقدار داده در صف‌های پیام (ulimit -q) "nice": تنظیم مقدار اولویت فرایند (nice -n, ulimit -e) "nofile": حداکثر تعداد فایل‌های باز (ulimit -n) "nofile": حداکثر تعداد فایل‌های باز (1048576)؛ هنگام اجرا توسط ریشه (root) "nproc": حداکثر تعداد فرایندها (ulimit -u) "nproc": حداکثر تعداد فرایندها (1048576)؛ هنگام اجرا توسط ریشه (root) "rss": حداکثر اندازه حافظه فیزیکی فرایند (ulimit -m) "rtprio": حداکثر اولویت زمان‌بندی بی‌درنگ (ulimit -r) "rttime": حداکثر زمان اجرای بی‌درنگ بین فراخوان‌های سیستمی مسدودکننده "sigpending": حداکثر تعداد سیگنال‌های در انتظار (ulimit -i) "stack": حداکثر اندازه پشته (ulimit -s) .PP \fB--userns\fP \fIhow\fP .PP پیکربندی فضاهای نام کاربری (User Namespaces) را هنگامی که کانتینر پس از آن برای \fBbuildah run\fR\& استفاده می‌شود تنظیم می‌کند. مقدار پیکربندی‌شده می‌تواند "" (رشته خالی) یا "container" باشد تا نشان دهد یک فضای نام کاربری جدید باید ساخته شود، می‌تواند "host" باشد تا نشان دهد فضای نام کاربری که خود \fBBuildah\fR در آن اجرا می‌شود باید بازاستفاده شود، یا می‌تواند مسیری به یک فضای نام کاربری باشد که پیش‌تر توسط فرایند دیگری در حال استفاده است. .PP \fB--userns-gid-map\fP \fImapping\fP .PP به طور مستقیم نگاشت GID را مشخص می‌کند که باید برای تنظیم مالکیت در سطح سیستم فایل بر محتوای کانتینر کاری استفاده شود. دستوراتی که هنگام پردازش دستورالعمل‌های \fBRUN\fR اجرا می‌شوند، به طور پیش‌فرض در فضاهای نام کاربری اختصاصی خود اجرا خواهند شد که با استفاده از نگاشت‌های UID و GID پیکربندی شده‌اند. .PP مدخل‌های این نگاشت به شکل یک یا چند سه‌تایی جداشده با دونقطه از GID آغازین درون کانتینر، یک GID آغازین متناظر در سطح میزبان، و تعداد شناسه‌های متوالی که مدخل نگاشت نشان می‌دهد هستند. .PP این گزینه بر تنظیم \fIremap-gids\fP در بخش \fIoptions\fP از /etc/containers/storage.conf ارجحیت دارد. .PP اگر این گزینه مشخص نشده باشد، اما یک تنظیم سراسری --userns-gid-map ارائه شده باشد، تنظیمات گزینه سراسری استفاده خواهد شد. .PP \fB--userns-gid-map-group\fP \fImapping\fP .PP به طور مستقیم نگاشت GID را مشخص می‌کند که باید برای تنظیم مالکیت در سطح سیستم فایل بر محتوای کانتینر استفاده شود. دستورات اجراشده با استفاده از \fBbuildah run\fR به طور پیش‌فرض در فضاهای نام کاربری اختصاصی خود اجرا می‌شوند که با استفاده از نگاشت‌های UID و GID پیکربندی شده‌اند. .PP مدخل‌های این نگاشت به شکل یک یا چند سه‌تایی از GID آغازین درون کانتینر، یک GID آغازین متناظر در سطح میزبان، و تعداد شناسه‌های متوالی که مدخل نگاشت نشان می‌دهد هستند. .PP این گزینه بر تنظیم \fIremap-gids\fP در بخش \fIoptions\fP از /etc/containers/storage.conf ارجحیت دارد. .PP اگر این گزینه مشخص نشده باشد، اما یک تنظیم سراسری --userns-gid-map ارائه شده باشد، تنظیمات گزینه سراسری استفاده خواهد شد. .PP اگر هیچ‌کدام از گزینه‌های --userns-uid-map-user یا --userns-gid-map-group یا --userns-gid-map مشخص نشده باشند، اما --userns-uid-map مشخص شده باشد، نگاشت GID برای استفاده از مقادیر عددی یکسان با نگاشت UID تنظیم خواهد شد. .PP \fBنکته (NOTE):\fP هنگامی که این گزینه توسط یک کاربر بدون ریشه (rootless) مشخص شود، نگاشت‌های تعیین‌شده نسبت به فضای نام کاربری بدون ریشه در کانتینر سنجیده می‌شوند، نه نسبت به میزبان آن‌گونه که در اجرای با ریشه (rootful) رخ می‌دهد. .PP \fB--userns-gid-map-group\fP \fIgroup\fP .PP مشخص می‌کند نگاشت GID که باید برای تنظیم مالکیت در سطح سیستم فایل بر محتوای کانتینر استفاده شود، می‌تواند در مدخل‌های مربوط به گروه مشخص‌شده در فایل \fB/etc/subgid\fR یافت شود. دستورات اجراشده با استفاده از \fBbuildah run\fR به طور پیش‌فرض در فضاهای نام کاربری اختصاصی خود اجرا می‌شوند که با استفاده از نگاشت‌های UID و GID پیکربندی شده‌اند. اگر --userns-uid-map-user مشخص شده باشد، اما --userns-gid-map-group مشخص نشده باشد، \fBBuildah\fR فرض می‌کند نام کاربر مشخص‌شده نیز نام گروهی مناسب برای استفاده به عنوان تنظیم پیش‌فرض این گزینه است. .PP \fB--userns-uid-map\fP \fImapping\fP .PP به طور مستقیم نگاشت UID را مشخص می‌کند که باید برای تنظیم مالکیت در سطح سیستم فایل بر محتوای کانتینر کاری استفاده شود. دستوراتی که هنگام پردازش دستورالعمل‌های \fBRUN\fR اجرا می‌شوند، به طور پیش‌فرض در فضاهای نام کاربری اختصاصی خود اجرا خواهند شد که با استفاده از نگاشت‌های UID و GID پیکربندی شده‌اند. .PP مدخل‌های این نگاشت به شکل یک یا چند سه‌تایی جداشده با دونقطه از UID آغازین درون کانتینر، یک UID آغازین متناظر در سطح میزبان، و تعداد شناسه‌های متوالی که مدخل نگاشت نشان می‌دهد هستند. .PP این گزینه بر تنظیم \fIremap-uids\fP در بخش \fIoptions\fP از /etc/containers/storage.conf ارجحیت دارد. .PP اگر این گزینه مشخص نشده باشد، اما یک تنظیم سراسری --userns-uid-map ارائه شده باشد، تنظیمات گزینه سراسری استفاده خواهد شد. .PP \fB--userns-uid-map-user\fP \fImapping\fP .PP به طور مستقیم نگاشت UID را مشخص می‌کند که باید برای تنظیم مالکیت در سطح سیستم فایل بر محتوای کانتینر استفاده شود. دستورات اجراشده با استفاده از \fBbuildah run\fR به طور پیش‌فرض در فضاهای نام کاربری اختصاصی خود اجرا می‌شوند که با استفاده از نگاشت‌های UID و GID پیکربندی شده‌اند. .PP مدخل‌های این نگاشت به شکل یک یا چند سه‌تایی از UID آغازین درون کانتینر، یک UID آغازین متناظر در سطح میزبان، و تعداد شناسه‌های متوالی که مدخل نگاشت نشان می‌دهد هستند. .PP این گزینه بر تنظیم \fIremap-uids\fP در بخش \fIoptions\fP از /etc/containers/storage.conf ارجحیت دارد. .PP اگر این گزینه مشخص نشده باشد، اما یک تنظیم سراسری --userns-uid-map ارائه شده باشد، تنظیمات گزینه سراسری استفاده خواهد شد. .PP اگر هیچ‌کدام از گزینه‌های --userns-uid-map-user یا --userns-gid-map-group یا --userns-uid-map مشخص نشده باشند، اما --userns-gid-map مشخص شده باشد، نگاشت UID برای استفاده از مقادیر عددی یکسان با نگاشت GID تنظیم خواهد شد. .PP \fBنکته (NOTE):\fP هنگامی که این گزینه توسط یک کاربر بدون ریشه (rootless) مشخص شود، نگاشت‌های تعیین‌شده نسبت به فضای نام کاربری بدون ریشه در کانتینر سنجیده می‌شوند، نه نسبت به میزبان آن‌گونه که در اجرای با ریشه (rootful) رخ می‌دهد. .PP \fB--userns-uid-map-user\fP \fIuser\fP .PP مشخص می‌کند نگاشت UID که باید برای تنظیم مالکیت در سطح سیستم فایل بر محتوای کانتینر استفاده شود، می‌تواند در مدخل‌های مربوط به کاربر مشخص‌شده در فایل \fB/etc/subuid\fR یافت شود. دستورات اجراشده با استفاده از \fBbuildah run\fR به طور پیش‌فرض در فضاهای نام کاربری اختصاصی خود اجرا می‌شوند که با استفاده از نگاشت‌های UID و GID پیکربندی شده‌اند. اگر --userns-gid-map-group مشخص شده باشد، اما --userns-uid-map-user مشخص نشده باشد، \fBBuildah\fR فرض می‌کند نام گروه مشخص‌شده نیز نام کاربری مناسبی برای استفاده به عنوان تنظیم پیش‌فرض این گزینه است. .PP \fB--uts\fP \fIhow\fP .PP پیکربندی فضاهای نام UTS را هنگامی که کانتینر پس از آن برای \fBbuildah run\fR\& استفاده می‌شود تنظیم می‌کند. مقدار پیکربندی‌شده می‌تواند "" (رشته خالی) یا "container" باشد تا نشان دهد یک فضای نام UTS جدید باید ساخته شود، یا می‌تواند "host" باشد تا نشان دهد فضای نام UTS که خود \fBBuildah\fR در آن اجرا می‌شود باید بازاستفاده شود، یا می‌تواند مسیری به یک فضای نام UTS باشد که پیش‌تر توسط فرایند دیگری در حال استفاده است. .PP \fB--variant\fP="" .PP گونه (variant) معماری تصویری که باید دریافت شود را تنظیم می‌کند. .PP \fB--volume\fP, \fB-v\fP[=\fI[HOST-DIR:CONTAINER-DIR[:OPTIONS]]\fP] .PP ایجاد یک اتصال پیوندی (bind mount). اگر مشخص کنید \fB-v /HOST-DIR:/CONTAINER-DIR\fR، ابزار Buildah مسیر \fB/HOST-DIR\fR در میزبان را به \fB/CONTAINER-DIR\fR درون کانتینر Buildah پیوند می‌زند. مقادیر \fBOPTIONS\fR فهرستی جداشده با کاما هستند و می‌توانند شامل موارد زیر باشند: .RS .IP \(bu 2 [rw|ro] .IP \(bu 2 [U] .IP \(bu 2 [z|Z|O] .IP \(bu 2 [\fB[r]shared\fR|\fB[r]slave\fR|\fB[r]private\fR|\fB[r]unbindable\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 مالک و گروه دایرکتوری‌های جلد منبع متصل‌شده به کانتینرها را تغییر نمی‌دهد. اگر کانتینری در یک فضای‌نام کاربری (user namespace) جدید ایجاد شود، 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 \fBاتصال‌های جلد اورلی (Overlay Volume Mounts)\fR .PP پرچم \fB:O\fR به Buildah اعلام می‌کند دایرکتوری را از میزبان با استفاده از سیستم‌فایل Overlay به‌عنوان یک فضای ذخیره‌سازی موقت سوار کند. کانتینرهای دستور \fBRUN\fR مجاز هستند محتویات درون نقطه اتصال را تغییر دهند و این تغییرات در فضای ذخیره‌سازی کانتینر در یک دایرکتوری جداگانه ذخیره می‌شوند. در اصطلاحات سامانه فایل Overlay، دایرکتوری منبع lower و دایرکتوری ذخیره‌سازی کانتینر upper خواهد بود. اصلاحات انجام‌شده در نقطه اتصال هنگام پایان اجرای دستور \fBRUN\fR از بین می‌روند، شبیه به یک نقطه اتصال tmpfs. .PP هر اجرای بعدی دستورهای \fBRUN\fR محتوای دایرکتوری منبع اصلی را می‌بیند؛ و هر تغییری از دستورات RUN قبلی دیگر وجود نخواهد داشت. .PP یک مورد استفاده از اتصال \fBoverlay\fR، به اشتراک گذاشتن حافظه نهان بسته‌ها (package cache) از میزبان به درون کانتینر برای افزایش سرعت ساخت است. .PP نکته: .RS .IP \(bu 2 پرچم \fBO\fR مجاز نیست همراه با پرچم‌های \fBZ\fR یا \fBz\fR مشخص شود. محتوای متصل‌شده به درون کانتینر با برچسب خصوصی برچسب‌گذاری می‌شود. در سامانه‌های SELinux، برچسب‌های موجود در دایرکتوری منبع باید برای برچسب کانتینر قابل‌خواندن باشند. در غیر این صورت، تفکیک کانتینر SELinux باید غیرفعال شود تا کانتینر کار کند. .IP \(bu 2 تغییر دایرکتوری جلدی که با یک اتصال overlay به درون کانتینر متصل شده است می‌تواند خطاهای غیرمنتظره به وجود آورد. توصیه می‌شود تا پایان اجرای کانتینر این دایرکتوری را تغییر ندهید. .RE .PP به‌طور پیش‌فرض جلدهای bind-mount شده \fBprivate\fR\& هستند. بدین معنا که هرگونه اتصالی که درون کانتینر انجام شود روی میزبان قابل مشاهده نخواهد بود و برعکس. این رفتار را می‌توان با مشخص کردن ویژگی انتشار اتصال جلد تغییر داد. .PP هنگامی که خط‌مشی انتشار اتصال روی \fBshared\fR تنظیم شود، هرگونه اتصال انجام‌شده درون کانتینر روی آن جلد هم برای میزبان و هم کانتینر قابل مشاهده خواهد بود. هنگامی که خط‌مشی انتشار اتصال روی \fBslave\fR تنظیم شود، انتشار یک‌طرفه اتصال فعال شده و هرگونه اتصال انجام‌شده روی میزبان برای آن جلد تنها در داخل کانتینر قابل مشاهده خواهد بود. برای کنترل ویژگی انتشار اتصال جلد، از پرچم‌های انتشار \fB:[r]shared\fR، \fB:[r]slave\fR، \fB[r]private\fR یا \fB[r]unbindable\fR استفاده کنید. ویژگی انتشار را فقط می‌توان برای جلدهای bind-mount شده تعیین کرد و نه جلدهای داخلی یا جلدهای نام‌گذاری‌شده. برای کارکرد انتشار اتصال روی نقطه اتصال منبع (نقطه اتصالی که دایرکتوری منبع روی آن سوار شده است)، باید ویژگی‌های انتشار مناسب را داشته باشد. برای جلدهای shared، نقطه اتصال منبع باید shared باشد. و برای جلدهای slave، اتصال منبع باید shared یا slave باشد. [1] \[la]#Footnote1\[ra] .PP از دستور \fBdf \fR برای تعیین اتصال منبع و سپس از دستور \fBfindmnt -o TARGET,PROPAGATION \fR برای تعیین ویژگی‌های انتشار اتصال منبع استفاده کنید؛ اگر ابزار \fBfindmnt\fR در دسترس نیست، نقطه اتصال منبع را می‌توان با بررسی مدخل mount در فایل \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 به کار ببرید. .SH "مثال (EXAMPLE)" .PP buildah from --pull imagename .PP buildah from --pull docker://myregistry.example.com/imagename .PP buildah from docker-daemon:imagename:imagetag .PP buildah from --name mycontainer docker-archive:filename .PP buildah from oci-archive:filename .PP buildah from --name mycontainer dir:directoryname .PP buildah from --pull-always --name "mycontainer" myregistry.example.com/imagename .PP buildah from --tls-verify=false myregistry/myrepository/imagename:imagetag .PP buildah from --creds=myusername:mypassword --cert-dir ~/auth myregistry/myrepository/imagename:imagetag .PP buildah from --authfile=/tmp/auths/myauths.json myregistry/myrepository/imagename:imagetag .PP buildah from --memory 40m --cpu-shares 2 --cpuset-cpus 0,2 --security-opt label=level:s0:c100,c200 myregistry/myrepository/imagename:imagetag .PP buildah from --ulimit nofile=1024:1028 --cgroup-parent /path/to/cgroup/parent myregistry/myrepository/imagename:imagetag .PP buildah from --volume /home/test:/myvol:ro,Z myregistry/myrepository/imagename:imagetag .PP buildah from -v /home/test:/myvol:z,U myregistry/myrepository/imagename:imagetag .PP buildah from -v /var/lib/yum:/var/lib/yum:O myregistry/myrepository/imagename:imagetag .PP buildah from --arch=arm --variant v7 myregistry/myrepository/imagename:imagetag .SH "متغیرهای محیطی (ENVIRONMENT)" .PP \fBBUILD_REGISTRY_SOURCES\fP .PP متغیر BUILD_REGISTRY_SOURCES در صورت مقداردهی، به عنوان یک شیء JSON در نظر گرفته می‌شود که شامل فهرست‌هایی از نام‌های رجیستری ذیل کلیدهای \fBinsecureRegistries\fR، \fBblockedRegistries\fR و \fBallowedRegistries\fR\& است. .PP هنگام دریافت (pull) تصویر از یک رجیستری، اگر نام رجیستری با هر یک از موارد موجود در فهرست \fBblockedRegistries\fR مطابقت داشته باشد، تلاش برای دریافت تصویر رد می‌شود. اگر در فهرست \fBallowedRegistries\fR رجیستری‌هایی وجود داشته باشند و نام رجیستری در فهرست نباشد، تلاش برای دریافت رد می‌شود. .PP \fBTMPDIR\fP متغیر محیطی TMPDIR به کاربر امکان می‌دهد محل ذخیره پرونده‌های موقت را هنگام دریافت و ارسال (pull و push) تصاویر مشخص کند. مقدار پیش‌فرض '/var/tmp' است. .SH "پرونده‌ها (FILES)" .PP \fBregistries.conf\fP (\fB/etc/containers/registries.conf\fR) .PP پرونده registries.conf پرونده پیکربندی است که مشخص می‌کند هنگام تکمیل نام‌های تصاویری که فاقد بخش رجیستری یا دامنه هستند، باید به کدام رجیستری‌های کانتینر مراجعه شود. .PP \fBpolicy.json\fP (\fB/etc/containers/policy.json\fR) .PP پرونده سیاست امضا. این پرونده سیاست اعتماد را برای تصاویر کانتینر تعریف می‌کند. تعیین می‌کند کدام رجیستری‌های کانتینر می‌توانند برای تصاویر استفاده شوند و این‌که آیا ابزار باید به تصاویر اعتماد کند یا خیر. .SH "همچنین ببینید (SEE ALSO)" .PP buildah(1), buildah-pull(1), buildah-login(1), docker-login(1), namespaces(7), pid_namespaces(7), containers-policy.json(5), containers-registries.conf(5), user_namespaces(7), containers.conf(5), containers-auth.json(5) .SH "پانویس‌ها (FOOTNOTES)" .PP ۱: پروژه Buildah به فراگیری، از ارزش‌های بنیادین متن‌باز، متعهد است. اصطلاحات انتشار سوارکردن (mount propagation) شامل \fBmaster\fR و \fBslave\fR که در این‌جا استفاده شده، مشکل‌ساز و تفرقه‌افکن است و باید دگرگون شود. با این حال، این اصطلاحات هم‌اکنون درون هسته لینوکس استفاده می‌شوند و در این مقطع زمانی باید به همان صورت به کار روند. هنگامی که نگه‌دارندگان هسته این کاربرد را اصلاح کنند، Buildah بی‌درنگ از آن پیروی خواهد کرد.