.nh .TH buildah-commit "1" "March 2017" "buildah" .SH "نام (NAME)" buildah-commit \- ایجاد یک ایمیج از کانتینر در حال اجرا یا تغییر یافته .SH "خلاصه دستور (SYNOPSIS)" .PP \fBbuildah commit\fP [\fIگزینه‌ها\fP] \fIکانتینر\fP [\fIایمیج\fP] .SH "توضیحات (DESCRIPTION)" .PP یک ایمیج جدید با استفاده از لایه خواندنی-نوشتنی (read-write) کانتینر مشخص‌شده، و در صورتی که بر پایه یک ایمیج باشد، لایه‌های آن ایمیج ایجاد می‌کند. اگر \fIایمیج\fP با مؤلفه نام رجیستری شروع نشود، \fBlocalhost\fR به ابتدای نام اضافه خواهد شد. اگر \fIایمیج\fP مشخص نشود، ایمیج بدون نام خواهد بود. هنگامی که یک ایمیج بدون نام باشد، دستور \fBbuildah images\fR عبارت \fB\fR را در ستون‌های \fBREPOSITORY\fR و \fBTAG\fR نمایش می‌دهد. .PP مقدار \fIایمیج\fP از تمام روش‌های انتقال در \fBcontainers-transports(5)\fR پشتیبانی می‌کند. اگر هیچ روش انتقالی مشخص نشود، روش انتقال \fBcontainers-storage\fR (یعنی ذخیره‌سازی محلی) استفاده می‌شود. .SH "مقدار بازگشتی (RETURN VALUE)" .PP شناسه (ID) ایمیجِ ایجادشده را برمی‌گرداند. در صورت بروز خطا، مقدار 1 و همچنین errno برگردانده می‌شود. .SH "گزینه‌ها (OPTIONS)" .PP \fB--add-file\fP \fIsource[:destination]\fP .PP محتویات فایل \fBsource\fR را می‌خواند و آن را به عنوان یک فایل در مسیر \fBdestination\fR به ایمیج کامیت‌شده اضافه می‌کند. اگر \fBdestination\fR مشخص نشود، از مسیر \fBsource\fR استفاده خواهد شد. فایل جدید متعلق به UID 0 و GID 0 خواهد بود، دارای مجوزهای 0644 خواهد بود، و در صورت مشخص شدن گزینه \fB--timestamp\fP، برچسب زمانی مشخص‌شده به آن اختصاص می‌یابد. این گزینه می‌تواند چندین بار مشخص شود. .PP \fB--annotation\fP \fIannotation[=value]\fP .PP یک یادداشت (\fIannotation\fP) ایمیج (مانند annotation=\fIvalue\fP) به متادیتای ایمیج اضافه می‌کند. می‌تواند چندین بار استفاده شود. اگر نام \fIannotation\fP مشخص شود اما نه \fB=\fR و نه \fBvalue\fR ارائه نشود، آنگاه مقدار \fIannotation\fP برابر با یک مقدار خالی قرار می‌گیرد. .PP نکته: این اطلاعات در فرمت‌های ایمیج Docker وجود ندارد، بنابراین هنگام نوشتن ایمیج‌ها در فرمت‌های Docker نادیده گرفته می‌شود. .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--cert-dir\fP \fIpath\fP .PP استفاده از گواهی‌های موجود در \fIpath\fP (*\&.crt, *\&.cert, *\&.key) برای اتصال به رجیستری. دایرکتوری پیش‌فرض گواهی‌ها \fI/etc/containers/certs.d\fP است. .PP \fB--change\fP, \fB-c\fP \fI"INSTRUCTION"\fP .PP اعمال تغییری بر روی ایمیج کامیت‌شده، مشابه تغییری که در صورت ساخت آن با استفاده از یک Containerfile حاوی دستورالعمل (instruction) مشخص‌شده اعمال می‌شد. این گزینه می‌تواند چندین بار مشخص شود. .PP \fB--compression-format\fP \fIformat\fP .PP قالب فشرده‌سازی مورد استفاده را مشخص می‌کند. مقادیر پشتیبانی‌شده عبارتند از: \fBgzip\fR، \fBzstd\fR و \fBzstd:chunked\fR. در صورت عدم تعیین، قالب از تنظیم \fBcompression_format\fR در containers.conf خوانده می‌شود. نمی‌تواند همراه با \fB--disable-compression\fP استفاده شود. .PP \fB--compression-level\fP \fIlevel\fP .PP سطح فشرده‌سازی مورد استفاده را مشخص می‌کند. این مقدار وابسته به الگوریتم فشرده‌سازی استفاده‌شده است؛ به عنوان مثال برای zstd مقادیر مجاز در بازه ۱ تا ۲۰ (شامل هر دو) هستند، در حالی که برای gzip بین ۱ تا ۹ (شامل هر دو) است. در صورت عدم تعیین، سطح از تنظیم \fBcompression_level\fR در containers.conf خوانده می‌شود. .PP \fB--config\fP \fIfilename\fP .PP یک نسخه با کدگذاری JSON از شیء پیکربندی ایمیج را از فایل مشخص‌شده می‌خواند، و مقادیر آن را با پیکربندی ایمیجی که در حال کامیت شدن است ادغام می‌کند. .PP \fB--created-annotation\fP .PP یک یادداشت ایمیج (\fIannotation\fP، همچنین \fB--annotation\fP را ببینید) به متادیتای ایمیج اضافه می‌کند که در آن "org.opencontainers.image.created" روی زمان جاری، یا برچسب زمانی مشخص‌شده در فلگ \fB--source-date-epoch\fP یا \fB--timestamp\fP (در صورت استفاده از هر یک) تنظیم می‌شود. اگر \fIfalse\fP باشد، چنین یادداشتی در ایمیج نوشته‌شده وجود نخواهد داشت. .PP نکته: این اطلاعات در فرمت‌های ایمیج Docker وجود ندارد، بنابراین هنگام نوشتن ایمیج‌ها در فرمت‌های Docker نادیده گرفته می‌شود. .PP \fB--creds\fP \fIcreds\fP .PP اطلاعات کاربری [username[:password]] مورد نیاز برای احراز هویت در رجیستری در صورت لزوم. اگر یک یا هر دو مقدار ارائه نشوند، یک اعلان خط فرمان ظاهر می‌شود و می‌توان مقدار را وارد کرد. گذرواژه بدون نمایش کاراکترها (echo) وارد می‌شود. .PP \fB--cw\fP \fIoptions\fP .PP ایجاد ایمیجی مناسب برای استفاده به عنوان بار کاری محرمانه (confidential workload) در حال اجرا در یک محیط اجرای قابل اعتماد (TEE) با استفاده از krun (یعنی \fIcrun\fP ساخته‌شده با قابلیت libkrun فعال و فراخوانی‌شده به صورت \fIkrun\fP). به جای محتویات معمول، سیستم فایل ریشه ایمیج شامل یک ایمیج دیسک رمزگذاری‌شده و اطلاعات پیکربندی برای krun خواهد بود. .PP مقدار \fIoptions\fP فهرستی از جفت‌های کلید=مقدار (key=value) جدا شده با کاما است که اطلاعات پیکربندی لازم برای تولید داده‌های اضافی را که در ایمیج کانتینر گنجانده می‌شوند، فراهم می‌کند. .PP کلیدهای (\fIkeys\fP) شناخته‌شده عبارتند از: .PP \fIattestation_url\fP: مکان سرور ارزیابی / کارگزار کلید (key broker / attestation server). اگر مقداری مشخص شود، شناسه بار کاری (workload ID) ایمیج جدید به همراه عبارت عبور مورد استفاده برای رمزگذاری ایمیج دیسک در سرور ثبت می‌شود، و مکان سرور در ایمیج کانتینر ذخیره خواهد شد. در زمان اجرا، انتظار می‌رود krun با سرور تماس بگیرد تا با استفاده از شناسه بار کاری که آن نیز در ایمیج کانتینر ذخیره شده است، عبارت عبور را بازیابی کند. اگر مقداری مشخص نشود، یک مقدار \fIpassphrase\fP \fIباید\fP مشخص شود. .PP \fIcpus\fP: تعداد پردازنده‌های مجازی (vCPU) که انتظار می‌رود ایمیج در زمان اجرا با آن‌ها اجرا شود. در صورت عدم تعیین، یک مقدار پیش‌فرض ارائه خواهد شد. .PP \fIfirmware_library\fP: مکان کتابخانه مشترک libkrunfw-sev. در صورت عدم تعیین، \fBbuildah\fR وجود آن را در تعدادی از مکان‌های پیش‌تعریف‌شده بررسی می‌کند. .PP \fImemory\fP: مقدار حافظه‌ای که انتظار می‌رود ایمیج در زمان اجرا با آن اجرا شود، به صورت تعداد مگابایت. در صورت عدم تعیین، یک مقدار پیش‌فرض ارائه خواهد شد. .PP \fIpassphrase\fP: عبارت عبور مورد استفاده برای رمزگذاری ایمیج دیسک که در ایمیج کانتینر گنجانده خواهد شد. اگر مقداری مشخص نشود، اما یک مقدار \fIattestation_url\fP مشخص شده باشد، از یک عبارت عبور تولیدشده به صورت تصادفی استفاده خواهد شد. توسعه‌دهندگان توصیه می‌کنند که \fIattestation_url\fP تنظیم شود اما \fIpassphrase\fP تنظیم نشود. .PP \fIslop\fP: فضای اضافی برای تخصیص به ایمیج دیسک در مقایسه با اندازه محتویات ایمیج کانتینر، که به صورت درصد (..%) یا مقدار اندازه (بایت، یا واحدهای بزرگتر در صورت وجود پسوندهایی مانند KB یا MB)، یا مجموع دو یا چند مورد از این مشخصات جدا شده با "+" بیان می‌شود. در صورت عدم تعیین، \fBbuildah\fR حدس می‌زند که ۲۵٪ فضای بیشتر از محتویات کافی است، اما این گزینه برای مواردی که این حدس نادرست باشد ارائه شده است. اگر اندازه مشخص‌شده یا محاسبه‌شده کمتر از ۱۰ مگابایت باشد، به ۱۰ مگابایت افزایش می‌یابد. .PP \fItype\fP: نوع محیط اجرای قابل اعتماد (TEE) که ایمیج باید برای استفاده با آن علامت‌گذاری شود. مقادیر پذیرفته‌شده عبارتند از "SEV" (مجازی‌سازی رمزگذاری‌شده امن AMD - وضعیت رمزگذاری‌شده) و "SNP" (مجازی‌سازی رمزگذاری‌شده امن AMD - صفحه‌بندی تودرتوی امن). در صورت عدم تعیین، مقدار پیش‌فرض "SNP" خواهد بود. .PP \fIworkload_id\fP: یک شناسه بار کاری که در ایمیج کانتینر ثبت می‌شود تا در زمان اجرا برای بازیابی عبارت عبوری که برای رمزگذاری ایمیج دیسک استفاده شده بود، به کار رود. در صورت عدم تعیین، یک مقدار شبه‌تصادفی از شناسه ایمیجِ پایه مشتق خواهد شد. .PP \fB--disable-compression\fP, \fB-D\fP .PP هنگام ساخت ایمیج، لایه‌های سیستم فایل را فشرده نمی‌کند مگر اینکه در مکانی که ایمیج در آن نوشته می‌شود الزامی باشد. این تنظیم پیش‌فرض است، زیرا لایه‌های ایمیج هنگام ارسال (push) به رجیستری‌ها به طور خودکار فشرده می‌شوند، و ایمیج‌هایی که در ذخیره‌سازی محلی نوشته می‌شوند تنها برای ذخیره شدن نیاز به از حالت فشرده خارج شدن مجدد خواهند داشت. فشرده‌سازی را می‌توان در تمام موارد با تعیین \fB--disable-compression=false\fP اجباری کرد. نمی‌تواند همراه با \fB--compression-format\fP یا \fB--force-compression\fP استفاده شود. .PP \fB--encrypt-layer\fP \fIlayer(s)\fP .PP لایه‌(ها) برای رمزگذاری: اندیس‌های لایه با مبنای ۰ به همراه پشتیبانی از اندیس‌گذاری منفی (مثلاً ۰ اولین لایه است، ۱- آخرین لایه است). در صورت عدم تعریف، اگر فلگ encryption-key مشخص شده باشد تمام لایه‌ها را رمزگذاری خواهد کرد. .PP \fB--encryption-key\fP \fIkey\fP .PP مقدار [protocol:keyfile] پروتکل رمزگذاری را مشخص می‌کند که می‌تواند JWE (RFC7516)، PGP (RFC4880) و PKCS7 (RFC2315) باشد و همچنین داده‌های کلید مورد نیاز برای رمزگذاری ایمیج را تعیین می‌کند. برای نمونه، jwe:/path/to/key.pem یا pgp:admin@example.com یا pkcs7:/path/to/x509-file. .PP \fB--force-compression\fP .PP در صورت تنظیم، commit از الگوریتم فشرده‌سازی مشخص‌شده استفاده می‌کند حتی اگر مقصد در حال حاضر حاوی نسخه‌ای با فشرده‌سازی متفاوت باشد. اگر \fB--compression-format\fP صراحتاً در خط فرمان مشخص شده باشد یا \fBcompression_format\fR در containers.conf تنظیم شده باشد مقدار پیش‌فرض \fBtrue\fR و در غیر این صورت \fBfalse\fR است. .PP \fB--format\fP, \fB-f\fP \fI[oci | docker]\fP .PP قالب را برای مانیفست و داده‌های پیکربندی ایمیج کنترل می‌کند. قالب‌های شناخته‌شده عبارتند از \fIoci\fP (مشخصات ایمیج OCI نسخه 1.0، پیش‌فرض) و \fIdocker\fP (نسخه ۲، با استفاده از قالب شِمای ۲ برای مانیفست). .PP نکته: همچنین می‌توانید قالب پیش‌فرض را با تنظیم متغیر محیطی BUILDAH_FORMAT بازنویسی کنید. \fBexport BUILDAH_FORMAT=docker\fR .PP \fB--identity-label\fP \fIbool-value\fP .PP برچسب \fBio.buildah.version\fR را اضافه می‌کند که مقدار آن برابر با نسخه buildah خواهد بود که ایمیج را کامیت کرده است (پیش‌فرض true است مگر اینکه از \fB--timestamp\fR یا \fB--source-date-epoch\fR استفاده شود). .PP \fB--iidfile\fP \fIImageIDfile\fP .PP نوشتن شناسه (ID) ایمیج در فایل. .PP \fB--manifest\fP "listName" .PP نام فهرست مانیفست (manifest list) که ایمیج ساخته‌شده به آن اضافه خواهد شد. اگر فهرست مانیفست وجود نداشته باشد آن را ایجاد می‌کند. این گزینه برای ساخت ایمیج‌های چندمعماری (multi architecture) مفید است. .PP \fB--metadata-file\fP \fIMetadataFile\fP .PP نوشتن اطلاعات مربوط به ایمیج کامیت‌شده در فایل نام‌برده. .PP \fB--omit-history\fP \fIbool-value\fP .PP حذف اطلاعات تاریخچه ساخت در ایمیج ساخته‌شده. (پیش‌فرض false). .PP این گزینه برای مواردی مفید است که کاربران نهایی صراحتاً می‌خواهند \fB--omit-history\fR را تنظیم کنند تا بخش اختیاری \fBHistory\fR از ایمیج‌های ساخته‌شده حذف شود، یا هنگام کار با ایمیج‌هایی که با ابزارهای ساختی ایجاد شده‌اند که اطلاعات \fBHistory\fR را در ایمیج‌های خود شامل نمی‌شوند. .PP \fB--pull\fP .PP هنگامی که فلگ \fI--pull\fP فعال است یا صراحتاً روی \fBtrue\fR تنظیم شده است (با \fI--pull=true\fP)، در صورتی که ایمیج اسکنر SBOM محلی وجود نداشته باشد یا ایمیج موجود در رجیستری تازه‌تر از نسخه موجود در ذخیره‌سازی محلی باشد، تلاش می‌کند آخرین نسخه‌های ایمیج‌های اسکنر SBOM را از رجیستری‌های فهرست‌شده در registries.conf دریافت (pull) کند. اگر ایمیج اسکنر SBOM در هیچ‌یک از رجیستری‌های فهرست‌شده نباشد و به صورت محلی نیز وجود نداشته باشد، خطا صادر می‌شود. .PP اگر فلگ غیرفعال باشد (با \fI--pull=false\fP)، ایمیج‌های اسکنر SBOM از رجیستری‌ها دریافت نمی‌شوند و تنها از نسخه‌های محلی استفاده می‌شود. اگر ایمیج اسکنر SBOM به صورت محلی وجود نداشته باشد، خطا صادر می‌شود. .PP اگر فلگ pull روی \fBalways\fR تنظیم شده باشد (با \fI--pull=always\fP)، ایمیج‌های اسکنر SBOM را از رجیستری‌های فهرست‌شده در registries.conf دریافت می‌کند. اگر ایمیج اسکنر SBOM در رجیستری‌ها یافت نشود، حتی اگر ایمیجی با همان نام به صورت محلی موجود باشد، خطا صادر می‌شود. .PP اگر فلگ pull روی \fBmissing\fR تنظیم شده باشد (با \fI--pull=missing\fP)، ایمیج‌های اسکنر SBOM تنها در صورتی دریافت می‌شوند که در ذخیره‌سازی محلی کانتینرها یافت نشوند. اگر هیچ ایمیجی یافت نشود و دریافت با شکست مواجه شود، خطا صادر می‌شود. .PP اگر فلگ pull روی \fBnever\fR تنظیم شده باشد (با \fI--pull=never\fP)، ایمیج‌های اسکنر SBOM از رجیستری‌ها دریافت نمی‌شوند و تنها از نسخه‌های محلی استفاده می‌شود. اگر ایمیج به صورت محلی وجود نداشته باشد، خطا صادر می‌شود. .PP \fB--quiet\fP, \fB-q\fP .PP هنگام نوشتن ایمیج خروجی، نمایش اطلاعات پیشرفت را متوقف می‌کند (بی‌صدا). .PP \fB--rewrite-timestamp\fP .PP هنگام تولید لایه جدید برای ایمیج، با جایگزینی هر برچسب زمانی که بعد از مقدار ارائه‌شده در فلگ \fB--source-date-epoch\fP باشد با همان مقدار، اطمینان حاصل می‌کند که هیچ محتوای تازه اضافه‌شده‌ای برچسب زمانی بعد از آن مقدار نداشته باشد. .PP \fB--rm\fP حذف کانتینر در حال کار و محتویات آن پس از ایجاد ایمیج. رفتار پیش‌فرض، کانتینر و محتویات آن را در جای خود باقی می‌گذارد. .PP \fB--sbom\fP \fIpreset\fP .PP تولید SBOMها (فهرست مواد نرم‌افزار / Software Bills Of Materials) برای ایمیج خروجی با اسکن کانتینر در حال کار و زمینه‌های ساخت با استفاده از ترکیب نام‌برده از ایمیج اسکنر، دستورات اسکنر و استراتژی ادغام. باید با یک یا چند مورد از \fB--sbom-image-output\fP، \fB--sbom-image-purl-output\fP، \fB--sbom-output\fP و \fB--sbom-purl-output\fP مشخص شود. پیش‌تنظیم‌های شناخته‌شده، و مجموعه گزینه‌هایی که معادل آن‌ها هستند: .RS .IP \(bu 2 "syft", "syft-cyclonedx": --sbom-scanner-image=ghcr.io/anchore/syft --sbom-scanner-command="/syft scan -q dir:{ROOTFS} --output cyclonedx-json={OUTPUT}" --sbom-scanner-command="/syft scan -q dir:{CONTEXT} --output cyclonedx-json={OUTPUT}" --sbom-merge-strategy=merge-cyclonedx-by-component-name-and-version .IP \(bu 2 "syft-spdx": --sbom-scanner-image=ghcr.io/anchore/syft --sbom-scanner-command="/syft scan -q dir:{ROOTFS} --output spdx-json={OUTPUT}" --sbom-scanner-command="/syft scan -q dir:{CONTEXT} --output spdx-json={OUTPUT}" --sbom-merge-strategy=merge-spdx-by-package-name-and-versioninfo .IP \(bu 2 "trivy", "trivy-cyclonedx": --sbom-scanner-image=ghcr.io/aquasecurity/trivy --sbom-scanner-command="trivy filesystem -q {ROOTFS} --format cyclonedx --output {OUTPUT}" --sbom-scanner-command="trivy filesystem -q {CONTEXT} --format cyclonedx --output {OUTPUT}" --sbom-merge-strategy=merge-cyclonedx-by-component-name-and-version .IP \(bu 2 "trivy-spdx": --sbom-scanner-image=ghcr.io/aquasecurity/trivy --sbom-scanner-command="trivy filesystem -q {ROOTFS} --format spdx-json --output {OUTPUT}" --sbom-scanner-command="trivy filesystem -q {CONTEXT} --format spdx-json --output {OUTPUT}" --sbom-merge-strategy=merge-spdx-by-package-name-and-versioninfo .RE .PP \fB--sbom-image-output\fP \fIpath\fP .PP هنگام تولید SBOMها، SBOM تولیدشده را در مسیر مشخص‌شده در ایمیج خروجی ذخیره می‌کند. مقدار پیش‌فرضی وجود ندارد. .PP \fB--sbom-image-purl-output\fP \fIpath\fP .PP هنگام تولید SBOMها، آن‌ها را برای اطلاعات PURL (نشانی اینترنتی بسته / package URL \[la]https://github.com/package\-url/purl\-spec/blob/master/PURL\-SPECIFICATION.rst\[ra]) اسکن می‌کند و فهرستی از PURLهای یافت‌شده را در فایل نام‌برده در سیستم فایل محلی ذخیره می‌کند. مقدار پیش‌فرضی وجود ندارد. .PP \fB--sbom-merge-strategy\fP \fImethod\fP .PP اگر بیش از یک مقدار برای \fB--sbom-scanner-command\fP استفاده شود، از روش مشخص‌شده برای ادغام خروجی دستورات بعدی با خروجی دستورات قبلی استفاده می‌کند. مقادیر شناخته‌شده عبارتند از: .RS .IP \(bu 2 cat پیوست کردن فایل‌ها به یکدیگر. .IP \(bu 2 merge-cyclonedx-by-component-name-and-version ادغام فیلدهای "component" اسناد JSON، با صرف‌نظر کردن از مقادیر اسنادی که ترکیب مقادیر "name" و "version" آن‌ها از قبل وجود دارد. اسناد به همان ترتیبی که تولید می‌شوند، که همان ترتیب مشخص شدن دستورات تولیدکننده آن‌ها است، پردازش می‌شوند. .IP \(bu 2 merge-spdx-by-package-name-and-versioninfo ادغام فیلدهای "package" اسناد JSON، با صرف‌نظر کردن از مقادیر اسنادی که ترکیب مقادیر "name" و "versionInfo" آن‌ها از قبل وجود دارد. اسناد به همان ترتیبی که تولید می‌شوند، که همان ترتیب مشخص شدن دستورات تولیدکننده آن‌ها است، پردازش می‌شوند. .RE .PP \fB--sbom-output\fP \fIfile\fP .PP هنگام تولید SBOMها، SBOM تولیدشده را در فایل نام‌برده روی سیستم فایل محلی ذخیره می‌کند. مقدار پیش‌فرضی وجود ندارد. .PP \fB--sbom-purl-output\fP \fIfile\fP .PP هنگام تولید SBOMها، آن‌ها را برای اطلاعات PURL (نشانی اینترنتی بسته / package URL \[la]https://github.com/package\-url/purl\-spec/blob/master/PURL\-SPECIFICATION.rst\[ra]) اسکن می‌کند و فهرستی از PURLهای یافت‌شده را در فایل نام‌برده در سیستم فایل محلی ذخیره می‌کند. مقدار پیش‌فرضی وجود ندارد. .PP \fB--sbom-scanner-command\fP \fIimage\fP .PP تولید SBOMها با اجرای دستور مشخص‌شده از ایمیج اسکنر. اگر چندین دستور مشخص شوند، به ترتیبی که تعیین شده‌اند اجرا می‌شوند. این جایگزینی‌های متنی انجام می‌شوند: - {ROOTFS} ریشه سیستم فایل ایمیج ساخته‌شده، که به صورت bind سوار (mount) شده است. - {CONTEXT} زمینه ساخت و زمینه‌های ساخت اضافی، که به صورت bind سوار شده‌اند. - {OUTPUT} نام یک فایل خروجی موقت، جهت خوانده شدن و ادغام با سایر موارد یا کپی شدن در جای دیگر. .PP \fB--sbom-scanner-image\fP \fIimage\fP .PP تولید SBOMها با استفاده از ایمیج اسکنر مشخص‌شده. .PP \fB--sign-by\fP \fIfingerprint\fP .PP امضای ایمیج جدید با استفاده از کلید GPG منطبق با اثر انگشت (fingerprint) مشخص‌شده. .PP \fB--source-date-epoch\fP \fIseconds\fP .PP تنظیم برچسب زمانی "created" برای ایمیج به این تعداد ثانیه پس از مبدأ زمانی (زمان مبدأ یونیکس 0، یعنی ساعت 00:00:00 UTC در ۱ ژانویه ۱۹۷۰) جهت سهولت در ایجاد ساخت‌های قطعی و تکرارپذیر (در صورت تنظیم، پیش‌فرض ‎$SOURCE_DATE_EPOCH است، در غیر این صورت از زمان جاری استفاده خواهد شد). .PP برچسب زمانی "created" هنگام کامیت شدن ایمیج در پیکربندی و مانیفست ایمیج نوشته می‌شود؛ بنابراین کامیت کردن یک کانتینر در حال کار یکسان در دو زمان متفاوت منجر به تولید ایمیج‌هایی با هش‌های sha256 متفاوت می‌شود، حتی اگر هیچ تغییر دیگری در این بین در کانتینر در حال کار ایجاد نشده باشد. .PP هنگامی که --source-date-epoch تنظیم شده باشد، برچسب زمانی "created" همیشه روی زمان مشخص‌شده تنظیم می‌شود، که باید امکان کامیت کردن ایمیج‌های یکسان را در زمان‌های مختلف فراهم سازد. .PP با فلگ مشابه \fB--timestamp\fP که زمان مشخص‌شده را روی محتویات لایه نیز تنظیم می‌کند، تداخل دارد. .PP \fB--squash\fP .PP ادغام و فشرده‌سازی تمام لایه‌های ایمیج جدید (از جمله لایه‌های به ارث رسیده از یک ایمیج پایه) در یک لایه جدید منفرد. .PP \fB--timestamp\fP \fIseconds\fP .PP تنظیم برچسب زمانی "created" برای ایمیج به این تعداد ثانیه پس از مبدأ زمانی (زمان مبدأ یونیکس 0، یعنی ساعت 00:00:00 UTC در ۱ ژانویه ۱۹۷۰) جهت سهولت در ایجاد ساخت‌های قطعی و تکرارپذیر (پیش‌فرض زمان جاری است). .PP برچسب زمانی "created" هنگام کامیت شدن ایمیج در پیکربندی و مانیفست ایمیج نوشته می‌شود؛ بنابراین کامیت کردن یک کانتینر در حال کار یکسان در دو زمان متفاوت منجر به تولید ایمیج‌هایی با هش‌های sha256 متفاوت می‌شود، حتی اگر هیچ تغییر دیگری در این بین در کانتینر در حال کار ایجاد نشده باشد. .PP هنگامی که --timestamp تنظیم شده باشد، برچسب زمانی "created" همیشه روی زمان مشخص‌شده تنظیم می‌شود، که باید امکان کامیت کردن ایمیج‌های یکسان را در زمان‌های مختلف فراهم سازد. تمام محتویات لایه جدید اضافه شده به عنوان بخشی از ایمیج نیز این برچسب زمانی را خواهند داشت. .PP با فلگ مشابه \fB--source-date-epoch\fP که به طور پیش‌فرض بر برچسب زمانی محتویات لایه‌ها تأثیر نمی‌گذارد، تداخل دارد. .PP \fB--tls-verify\fP \fIbool-value\fP .PP الزام به استفاده از HTTPS و اعتبارسنجی گواهی‌ها هنگام برقراری ارتباط با رجیستری‌های کانتینر (پیش‌فرض true است). اعتبارسنجی TLS هنگام ارتباط با رجیستری‌های ناامن نمی‌تواند استفاده شود. .PP \fB--unsetannotation\fP \fIannotation\fP .PP حذف یادداشت (annotation) ایمیج، که باعث می‌شود این یادداشت از ایمیج پایه به ارث برده نشود. .PP \fB--unsetenv\fP \fIenv\fP .PP حذف متغیرهای محیطی از ایمیج نهایی. .SH "مثال (EXAMPLE)" .PP این مثال یک ایمیج بر پایه کانتینر ذخیره می‌کند. \fBbuildah commit containerID newImageName\fR .PP این مثال یک ایمیج با نام newImageName بر پایه کانتینر ذخیره کرده و کانتینر در حال کار را حذف می‌کند. \fBbuildah commit --rm containerID newImageName\fR .PP این مثال بر پایه کانتینر، در یک فایل آرشیو OCI به نام /tmp/newImageName کامیت می‌کند. \fBbuildah commit containerID oci-archive:/tmp/newImageName\fR .PP این مثال یک ایمیج بدون نام ذخیره می‌کند، کانتینر در حال کار را حذف می‌نماید و با استفاده از شناسه ایمیج، کانتینر جدیدی ایجاد می‌کند. \fBbuildah from $(buildah commit --rm containerID)\fR .PP این مثال یک ایمیج بر پایه کانتینر با غیرفعال کردن فشرده‌سازی ذخیره می‌کند. \fBbuildah commit --disable-compression containerID\fR .PP این مثال یک ایمیج با نام newImageName بر پایه کانتینر با غیرفعال کردن فشرده‌سازی ذخیره می‌کند. \fBbuildah commit --disable-compression containerID newImageName\fR .PP این مثال کانتینر را در ایمیج روی رجیستری محلی کامیت می‌کند در حالی که اعتبارسنجی TLS غیرفعال است. \fBbuildah commit --tls-verify=false containerID docker://localhost:5000/imageId\fR .PP این مثال کانتینر را با استفاده از اطلاعات کاربری و گواهی‌ها برای احراز هویت، در ایمیج روی رجیستری محلی کامیت می‌کند. \fBbuildah commit --cert-dir ~/auth --tls-verify=true --creds=username:password containerID docker://localhost:5000/imageId\fR .PP این مثال کانتینر را با استفاده از اطلاعات کاربری موجود در فایل /tmp/auths/myauths.json و گواهی‌ها برای احراز هویت، در ایمیج روی رجیستری محلی کامیت می‌کند. \fBbuildah commit --authfile /tmp/auths/myauths.json --cert-dir ~/auth --tls-verify=true --creds=username:password containerID docker://localhost:5000/imageName\fR .PP این مثال یک ایمیج بر پایه کانتینر ذخیره می‌کند، اما تاریخ‌ها را بر اساس زمان مبدأ (epoch) ذخیره می‌نماید. \fBbuildah commit --timestamp=0 containerID newImageName\fR .SS "ساخت یک ایمیج چندمعماری با استفاده از گزینه --manifest (نیازمند نرم‌افزار شبیه‌ساز)" .EX #!/bin/sh build() { ctr=$(./bin/buildah from --arch $1 ubi8) ./bin/buildah run $ctr dnf install -y iputils ./bin/buildah commit --manifest ubi8ping $ctr } build arm build amd64 build s390x .EE .SH "محیط (ENVIRONMENT)" .PP \fBBUILD_REGISTRY_SOURCES\fP .PP متغیر BUILD_REGISTRY_SOURCES در صورت تنظیم، به عنوان یک شیء JSON در نظر گرفته می‌شود که شامل فهرست‌هایی از نام‌های رجیستری تحت کلیدهای \fBinsecureRegistries\fR، \fBblockedRegistries\fR و \fBallowedRegistries\fR است. .PP هنگام کامیت کردن یک ایمیج، اگر قرار باشد نامی به ایمیج اختصاص داده شود، بخشی از نام که متناظر با رجیستری است با موارد موجود در فهرست \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-images(1), containers-policy.json(5), containers-registries.conf(5), containers-transports(5), containers-auth.json(5)