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

buildah-commit - ایجاد یک ایمیج از کانتینر در حال اجرا یا تغییر یافته

buildah commit [گزینه‌ها] کانتینر [ایمیج]

یک ایمیج جدید با استفاده از لایه خواندنی-نوشتنی (read-write) کانتینر مشخص‌شده، و در صورتی که بر پایه یک ایمیج باشد، لایه‌های آن ایمیج ایجاد می‌کند. اگر ایمیج با مؤلفه نام رجیستری شروع نشود، localhost به ابتدای نام اضافه خواهد شد. اگر ایمیج مشخص نشود، ایمیج بدون نام خواهد بود. هنگامی که یک ایمیج بدون نام باشد، دستور buildah images عبارت <none> را در ستون‌های REPOSITORY و TAG نمایش می‌دهد.

مقدار ایمیج از تمام روش‌های انتقال در containers-transports(5) پشتیبانی می‌کند. اگر هیچ روش انتقالی مشخص نشود، روش انتقال containers-storage (یعنی ذخیره‌سازی محلی) استفاده می‌شود.

شناسه (ID) ایمیجِ ایجادشده را برمی‌گرداند. در صورت بروز خطا، مقدار 1 و همچنین errno برگردانده می‌شود.

--add-file source[:destination]

محتویات فایل source را می‌خواند و آن را به عنوان یک فایل در مسیر destination به ایمیج کامیت‌شده اضافه می‌کند. اگر destination مشخص نشود، از مسیر source استفاده خواهد شد. فایل جدید متعلق به UID 0 و GID 0 خواهد بود، دارای مجوزهای 0644 خواهد بود، و در صورت مشخص شدن گزینه --timestamp، برچسب زمانی مشخص‌شده به آن اختصاص می‌یابد. این گزینه می‌تواند چندین بار مشخص شود.

--annotation annotation[=value]

یک یادداشت (annotation) ایمیج (مانند annotation=value) به متادیتای ایمیج اضافه می‌کند. می‌تواند چندین بار استفاده شود. اگر نام annotation مشخص شود اما نه = و نه value ارائه نشود، آنگاه مقدار annotation برابر با یک مقدار خالی قرار می‌گیرد.

نکته: این اطلاعات در فرمت‌های ایمیج Docker وجود ندارد، بنابراین هنگام نوشتن ایمیج‌ها در فرمت‌های Docker نادیده گرفته می‌شود.

--authfile path

مسیر فایل احراز هویت. مقدار پیش‌فرض ${XDG_RUNTIME_DIR}/containers/auth.json است. برای اطلاعات بیشتر containers-auth.json(5) را ببینید. این فایل با استفاده از buildah login ایجاد می‌شود.

اگر وضعیت احراز هویت در آنجا یافت نشود، مسیر ‎$HOME/.docker/config.json که با استفاده از docker login تنظیم می‌شود، بررسی خواهد شد.

نکته: همچنین می‌توانید مسیر پیش‌فرض فایل احراز هویت را با تنظیم متغیر محیطی REGISTRY_AUTH_FILE بازنویسی کنید. export REGISTRY_AUTH_FILE=path

--cert-dir path

استفاده از گواهی‌های موجود در path (*.crt, *.cert, *.key) برای اتصال به رجیستری. دایرکتوری پیش‌فرض گواهی‌ها /etc/containers/certs.d است.

--change, -c "INSTRUCTION"

اعمال تغییری بر روی ایمیج کامیت‌شده، مشابه تغییری که در صورت ساخت آن با استفاده از یک Containerfile حاوی دستورالعمل (instruction) مشخص‌شده اعمال می‌شد. این گزینه می‌تواند چندین بار مشخص شود.

--compression-format format

قالب فشرده‌سازی مورد استفاده را مشخص می‌کند. مقادیر پشتیبانی‌شده عبارتند از: gzip، zstd و zstd:chunked. در صورت عدم تعیین، قالب از تنظیم compression_format در containers.conf خوانده می‌شود. نمی‌تواند همراه با --disable-compression استفاده شود.

--compression-level level

سطح فشرده‌سازی مورد استفاده را مشخص می‌کند. این مقدار وابسته به الگوریتم فشرده‌سازی استفاده‌شده است؛ به عنوان مثال برای zstd مقادیر مجاز در بازه ۱ تا ۲۰ (شامل هر دو) هستند، در حالی که برای gzip بین ۱ تا ۹ (شامل هر دو) است. در صورت عدم تعیین، سطح از تنظیم compression_level در containers.conf خوانده می‌شود.

--config filename

یک نسخه با کدگذاری JSON از شیء پیکربندی ایمیج را از فایل مشخص‌شده می‌خواند، و مقادیر آن را با پیکربندی ایمیجی که در حال کامیت شدن است ادغام می‌کند.

--created-annotation

یک یادداشت ایمیج (annotation، همچنین --annotation را ببینید) به متادیتای ایمیج اضافه می‌کند که در آن "org.opencontainers.image.created" روی زمان جاری، یا برچسب زمانی مشخص‌شده در فلگ --source-date-epoch یا --timestamp (در صورت استفاده از هر یک) تنظیم می‌شود. اگر false باشد، چنین یادداشتی در ایمیج نوشته‌شده وجود نخواهد داشت.

نکته: این اطلاعات در فرمت‌های ایمیج Docker وجود ندارد، بنابراین هنگام نوشتن ایمیج‌ها در فرمت‌های Docker نادیده گرفته می‌شود.

--creds creds

اطلاعات کاربری [username[:password]] مورد نیاز برای احراز هویت در رجیستری در صورت لزوم. اگر یک یا هر دو مقدار ارائه نشوند، یک اعلان خط فرمان ظاهر می‌شود و می‌توان مقدار را وارد کرد. گذرواژه بدون نمایش کاراکترها (echo) وارد می‌شود.

--cw options

ایجاد ایمیجی مناسب برای استفاده به عنوان بار کاری محرمانه (confidential workload) در حال اجرا در یک محیط اجرای قابل اعتماد (TEE) با استفاده از krun (یعنی crun ساخته‌شده با قابلیت libkrun فعال و فراخوانی‌شده به صورت krun). به جای محتویات معمول، سیستم فایل ریشه ایمیج شامل یک ایمیج دیسک رمزگذاری‌شده و اطلاعات پیکربندی برای krun خواهد بود.

مقدار options فهرستی از جفت‌های کلید=مقدار (key=value) جدا شده با کاما است که اطلاعات پیکربندی لازم برای تولید داده‌های اضافی را که در ایمیج کانتینر گنجانده می‌شوند، فراهم می‌کند.

کلیدهای (keys) شناخته‌شده عبارتند از:

attestation_url: مکان سرور ارزیابی / کارگزار کلید (key broker / attestation server). اگر مقداری مشخص شود، شناسه بار کاری (workload ID) ایمیج جدید به همراه عبارت عبور مورد استفاده برای رمزگذاری ایمیج دیسک در سرور ثبت می‌شود، و مکان سرور در ایمیج کانتینر ذخیره خواهد شد. در زمان اجرا، انتظار می‌رود krun با سرور تماس بگیرد تا با استفاده از شناسه بار کاری که آن نیز در ایمیج کانتینر ذخیره شده است، عبارت عبور را بازیابی کند. اگر مقداری مشخص نشود، یک مقدار passphrase باید مشخص شود.

cpus: تعداد پردازنده‌های مجازی (vCPU) که انتظار می‌رود ایمیج در زمان اجرا با آن‌ها اجرا شود. در صورت عدم تعیین، یک مقدار پیش‌فرض ارائه خواهد شد.

firmware_library: مکان کتابخانه مشترک libkrunfw-sev. در صورت عدم تعیین، buildah وجود آن را در تعدادی از مکان‌های پیش‌تعریف‌شده بررسی می‌کند.

memory: مقدار حافظه‌ای که انتظار می‌رود ایمیج در زمان اجرا با آن اجرا شود، به صورت تعداد مگابایت. در صورت عدم تعیین، یک مقدار پیش‌فرض ارائه خواهد شد.

passphrase: عبارت عبور مورد استفاده برای رمزگذاری ایمیج دیسک که در ایمیج کانتینر گنجانده خواهد شد. اگر مقداری مشخص نشود، اما یک مقدار attestation_url مشخص شده باشد، از یک عبارت عبور تولیدشده به صورت تصادفی استفاده خواهد شد. توسعه‌دهندگان توصیه می‌کنند که attestation_url تنظیم شود اما passphrase تنظیم نشود.

slop: فضای اضافی برای تخصیص به ایمیج دیسک در مقایسه با اندازه محتویات ایمیج کانتینر، که به صورت درصد (..%) یا مقدار اندازه (بایت، یا واحدهای بزرگتر در صورت وجود پسوندهایی مانند KB یا MB)، یا مجموع دو یا چند مورد از این مشخصات جدا شده با "+" بیان می‌شود. در صورت عدم تعیین، buildah حدس می‌زند که ۲۵٪ فضای بیشتر از محتویات کافی است، اما این گزینه برای مواردی که این حدس نادرست باشد ارائه شده است. اگر اندازه مشخص‌شده یا محاسبه‌شده کمتر از ۱۰ مگابایت باشد، به ۱۰ مگابایت افزایش می‌یابد.

type: نوع محیط اجرای قابل اعتماد (TEE) که ایمیج باید برای استفاده با آن علامت‌گذاری شود. مقادیر پذیرفته‌شده عبارتند از "SEV" (مجازی‌سازی رمزگذاری‌شده امن AMD - وضعیت رمزگذاری‌شده) و "SNP" (مجازی‌سازی رمزگذاری‌شده امن AMD - صفحه‌بندی تودرتوی امن). در صورت عدم تعیین، مقدار پیش‌فرض "SNP" خواهد بود.

workload_id: یک شناسه بار کاری که در ایمیج کانتینر ثبت می‌شود تا در زمان اجرا برای بازیابی عبارت عبوری که برای رمزگذاری ایمیج دیسک استفاده شده بود، به کار رود. در صورت عدم تعیین، یک مقدار شبه‌تصادفی از شناسه ایمیجِ پایه مشتق خواهد شد.

--disable-compression, -D

هنگام ساخت ایمیج، لایه‌های سیستم فایل را فشرده نمی‌کند مگر اینکه در مکانی که ایمیج در آن نوشته می‌شود الزامی باشد. این تنظیم پیش‌فرض است، زیرا لایه‌های ایمیج هنگام ارسال (push) به رجیستری‌ها به طور خودکار فشرده می‌شوند، و ایمیج‌هایی که در ذخیره‌سازی محلی نوشته می‌شوند تنها برای ذخیره شدن نیاز به از حالت فشرده خارج شدن مجدد خواهند داشت. فشرده‌سازی را می‌توان در تمام موارد با تعیین --disable-compression=false اجباری کرد. نمی‌تواند همراه با --compression-format یا --force-compression استفاده شود.

--encrypt-layer layer(s)

لایه‌(ها) برای رمزگذاری: اندیس‌های لایه با مبنای ۰ به همراه پشتیبانی از اندیس‌گذاری منفی (مثلاً ۰ اولین لایه است، ۱- آخرین لایه است). در صورت عدم تعریف، اگر فلگ encryption-key مشخص شده باشد تمام لایه‌ها را رمزگذاری خواهد کرد.

--encryption-key key

مقدار [protocol:keyfile] پروتکل رمزگذاری را مشخص می‌کند که می‌تواند JWE (RFC7516)، PGP (RFC4880) و PKCS7 (RFC2315) باشد و همچنین داده‌های کلید مورد نیاز برای رمزگذاری ایمیج را تعیین می‌کند. برای نمونه، jwe:/path/to/key.pem یا pgp:admin@example.com یا pkcs7:/path/to/x509-file.

--force-compression

در صورت تنظیم، commit از الگوریتم فشرده‌سازی مشخص‌شده استفاده می‌کند حتی اگر مقصد در حال حاضر حاوی نسخه‌ای با فشرده‌سازی متفاوت باشد. اگر --compression-format صراحتاً در خط فرمان مشخص شده باشد یا compression_format در containers.conf تنظیم شده باشد مقدار پیش‌فرض true و در غیر این صورت false است.

--format, -f [oci | docker]

قالب را برای مانیفست و داده‌های پیکربندی ایمیج کنترل می‌کند. قالب‌های شناخته‌شده عبارتند از oci (مشخصات ایمیج OCI نسخه 1.0، پیش‌فرض) و docker (نسخه ۲، با استفاده از قالب شِمای ۲ برای مانیفست).

نکته: همچنین می‌توانید قالب پیش‌فرض را با تنظیم متغیر محیطی BUILDAH_FORMAT بازنویسی کنید. export BUILDAH_FORMAT=docker

--identity-label bool-value

برچسب io.buildah.version را اضافه می‌کند که مقدار آن برابر با نسخه buildah خواهد بود که ایمیج را کامیت کرده است (پیش‌فرض true است مگر اینکه از --timestamp یا --source-date-epoch استفاده شود).

--iidfile ImageIDfile

نوشتن شناسه (ID) ایمیج در فایل.

--manifest "listName"

نام فهرست مانیفست (manifest list) که ایمیج ساخته‌شده به آن اضافه خواهد شد. اگر فهرست مانیفست وجود نداشته باشد آن را ایجاد می‌کند. این گزینه برای ساخت ایمیج‌های چندمعماری (multi architecture) مفید است.

--metadata-file MetadataFile

نوشتن اطلاعات مربوط به ایمیج کامیت‌شده در فایل نام‌برده.

--omit-history bool-value

حذف اطلاعات تاریخچه ساخت در ایمیج ساخته‌شده. (پیش‌فرض false).

این گزینه برای مواردی مفید است که کاربران نهایی صراحتاً می‌خواهند --omit-history را تنظیم کنند تا بخش اختیاری History از ایمیج‌های ساخته‌شده حذف شود، یا هنگام کار با ایمیج‌هایی که با ابزارهای ساختی ایجاد شده‌اند که اطلاعات History را در ایمیج‌های خود شامل نمی‌شوند.

--pull

هنگامی که فلگ --pull فعال است یا صراحتاً روی true تنظیم شده است (با --pull=true)، در صورتی که ایمیج اسکنر SBOM محلی وجود نداشته باشد یا ایمیج موجود در رجیستری تازه‌تر از نسخه موجود در ذخیره‌سازی محلی باشد، تلاش می‌کند آخرین نسخه‌های ایمیج‌های اسکنر SBOM را از رجیستری‌های فهرست‌شده در registries.conf دریافت (pull) کند. اگر ایمیج اسکنر SBOM در هیچ‌یک از رجیستری‌های فهرست‌شده نباشد و به صورت محلی نیز وجود نداشته باشد، خطا صادر می‌شود.

اگر فلگ غیرفعال باشد (با --pull=false)، ایمیج‌های اسکنر SBOM از رجیستری‌ها دریافت نمی‌شوند و تنها از نسخه‌های محلی استفاده می‌شود. اگر ایمیج اسکنر SBOM به صورت محلی وجود نداشته باشد، خطا صادر می‌شود.

اگر فلگ pull روی always تنظیم شده باشد (با --pull=always)، ایمیج‌های اسکنر SBOM را از رجیستری‌های فهرست‌شده در registries.conf دریافت می‌کند. اگر ایمیج اسکنر SBOM در رجیستری‌ها یافت نشود، حتی اگر ایمیجی با همان نام به صورت محلی موجود باشد، خطا صادر می‌شود.

اگر فلگ pull روی missing تنظیم شده باشد (با --pull=missing)، ایمیج‌های اسکنر SBOM تنها در صورتی دریافت می‌شوند که در ذخیره‌سازی محلی کانتینرها یافت نشوند. اگر هیچ ایمیجی یافت نشود و دریافت با شکست مواجه شود، خطا صادر می‌شود.

اگر فلگ pull روی never تنظیم شده باشد (با --pull=never)، ایمیج‌های اسکنر SBOM از رجیستری‌ها دریافت نمی‌شوند و تنها از نسخه‌های محلی استفاده می‌شود. اگر ایمیج به صورت محلی وجود نداشته باشد، خطا صادر می‌شود.

--quiet, -q

هنگام نوشتن ایمیج خروجی، نمایش اطلاعات پیشرفت را متوقف می‌کند (بی‌صدا).

--rewrite-timestamp

هنگام تولید لایه جدید برای ایمیج، با جایگزینی هر برچسب زمانی که بعد از مقدار ارائه‌شده در فلگ --source-date-epoch باشد با همان مقدار، اطمینان حاصل می‌کند که هیچ محتوای تازه اضافه‌شده‌ای برچسب زمانی بعد از آن مقدار نداشته باشد.

--rm حذف کانتینر در حال کار و محتویات آن پس از ایجاد ایمیج. رفتار پیش‌فرض، کانتینر و محتویات آن را در جای خود باقی می‌گذارد.

--sbom preset

تولید SBOMها (فهرست مواد نرم‌افزار / Software Bills Of Materials) برای ایمیج خروجی با اسکن کانتینر در حال کار و زمینه‌های ساخت با استفاده از ترکیب نام‌برده از ایمیج اسکنر، دستورات اسکنر و استراتژی ادغام. باید با یک یا چند مورد از --sbom-image-output، --sbom-image-purl-output، --sbom-output و --sbom-purl-output مشخص شود. پیش‌تنظیم‌های شناخته‌شده، و مجموعه گزینه‌هایی که معادل آن‌ها هستند:

  • "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
  • "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
  • "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
  • "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

--sbom-image-output path

هنگام تولید SBOMها، SBOM تولیدشده را در مسیر مشخص‌شده در ایمیج خروجی ذخیره می‌کند. مقدار پیش‌فرضی وجود ندارد.

--sbom-image-purl-output path

هنگام تولید SBOMها، آن‌ها را برای اطلاعات PURL (نشانی اینترنتی بسته / package URL ⟨https://github.com/package-url/purl-spec/blob/master/PURL-SPECIFICATION.rst⟩) اسکن می‌کند و فهرستی از PURLهای یافت‌شده را در فایل نام‌برده در سیستم فایل محلی ذخیره می‌کند. مقدار پیش‌فرضی وجود ندارد.

--sbom-merge-strategy method

اگر بیش از یک مقدار برای --sbom-scanner-command استفاده شود، از روش مشخص‌شده برای ادغام خروجی دستورات بعدی با خروجی دستورات قبلی استفاده می‌کند. مقادیر شناخته‌شده عبارتند از:

  • cat
    پیوست کردن فایل‌ها به یکدیگر.
  • merge-cyclonedx-by-component-name-and-version
    ادغام فیلدهای "component" اسناد JSON، با صرف‌نظر کردن از مقادیر اسنادی که ترکیب مقادیر "name" و "version" آن‌ها از قبل وجود دارد. اسناد به همان ترتیبی که تولید می‌شوند، که همان ترتیب مشخص شدن دستورات تولیدکننده آن‌ها است، پردازش می‌شوند.
  • merge-spdx-by-package-name-and-versioninfo
    ادغام فیلدهای "package" اسناد JSON، با صرف‌نظر کردن از مقادیر اسنادی که ترکیب مقادیر "name" و "versionInfo" آن‌ها از قبل وجود دارد. اسناد به همان ترتیبی که تولید می‌شوند، که همان ترتیب مشخص شدن دستورات تولیدکننده آن‌ها است، پردازش می‌شوند.

--sbom-output file

هنگام تولید SBOMها، SBOM تولیدشده را در فایل نام‌برده روی سیستم فایل محلی ذخیره می‌کند. مقدار پیش‌فرضی وجود ندارد.

--sbom-purl-output file

هنگام تولید SBOMها، آن‌ها را برای اطلاعات PURL (نشانی اینترنتی بسته / package URL ⟨https://github.com/package-url/purl-spec/blob/master/PURL-SPECIFICATION.rst⟩) اسکن می‌کند و فهرستی از PURLهای یافت‌شده را در فایل نام‌برده در سیستم فایل محلی ذخیره می‌کند. مقدار پیش‌فرضی وجود ندارد.

--sbom-scanner-command image

تولید SBOMها با اجرای دستور مشخص‌شده از ایمیج اسکنر. اگر چندین دستور مشخص شوند، به ترتیبی که تعیین شده‌اند اجرا می‌شوند. این جایگزینی‌های متنی انجام می‌شوند:
- {ROOTFS}
ریشه سیستم فایل ایمیج ساخته‌شده، که به صورت bind سوار (mount) شده است.
- {CONTEXT}
زمینه ساخت و زمینه‌های ساخت اضافی، که به صورت bind سوار شده‌اند.
- {OUTPUT}
نام یک فایل خروجی موقت، جهت خوانده شدن و ادغام با سایر موارد یا کپی شدن در جای دیگر.

--sbom-scanner-image image

تولید SBOMها با استفاده از ایمیج اسکنر مشخص‌شده.

--sign-by fingerprint

امضای ایمیج جدید با استفاده از کلید GPG منطبق با اثر انگشت (fingerprint) مشخص‌شده.

--source-date-epoch seconds

تنظیم برچسب زمانی "created" برای ایمیج به این تعداد ثانیه پس از مبدأ زمانی (زمان مبدأ یونیکس 0، یعنی ساعت 00:00:00 UTC در ۱ ژانویه ۱۹۷۰) جهت سهولت در ایجاد ساخت‌های قطعی و تکرارپذیر (در صورت تنظیم، پیش‌فرض ‎$SOURCE_DATE_EPOCH است، در غیر این صورت از زمان جاری استفاده خواهد شد).

برچسب زمانی "created" هنگام کامیت شدن ایمیج در پیکربندی و مانیفست ایمیج نوشته می‌شود؛ بنابراین کامیت کردن یک کانتینر در حال کار یکسان در دو زمان متفاوت منجر به تولید ایمیج‌هایی با هش‌های sha256 متفاوت می‌شود، حتی اگر هیچ تغییر دیگری در این بین در کانتینر در حال کار ایجاد نشده باشد.

هنگامی که --source-date-epoch تنظیم شده باشد، برچسب زمانی "created" همیشه روی زمان مشخص‌شده تنظیم می‌شود، که باید امکان کامیت کردن ایمیج‌های یکسان را در زمان‌های مختلف فراهم سازد.

با فلگ مشابه --timestamp که زمان مشخص‌شده را روی محتویات لایه نیز تنظیم می‌کند، تداخل دارد.

--squash

ادغام و فشرده‌سازی تمام لایه‌های ایمیج جدید (از جمله لایه‌های به ارث رسیده از یک ایمیج پایه) در یک لایه جدید منفرد.

--timestamp seconds

تنظیم برچسب زمانی "created" برای ایمیج به این تعداد ثانیه پس از مبدأ زمانی (زمان مبدأ یونیکس 0، یعنی ساعت 00:00:00 UTC در ۱ ژانویه ۱۹۷۰) جهت سهولت در ایجاد ساخت‌های قطعی و تکرارپذیر (پیش‌فرض زمان جاری است).

برچسب زمانی "created" هنگام کامیت شدن ایمیج در پیکربندی و مانیفست ایمیج نوشته می‌شود؛ بنابراین کامیت کردن یک کانتینر در حال کار یکسان در دو زمان متفاوت منجر به تولید ایمیج‌هایی با هش‌های sha256 متفاوت می‌شود، حتی اگر هیچ تغییر دیگری در این بین در کانتینر در حال کار ایجاد نشده باشد.

هنگامی که --timestamp تنظیم شده باشد، برچسب زمانی "created" همیشه روی زمان مشخص‌شده تنظیم می‌شود، که باید امکان کامیت کردن ایمیج‌های یکسان را در زمان‌های مختلف فراهم سازد. تمام محتویات لایه جدید اضافه شده به عنوان بخشی از ایمیج نیز این برچسب زمانی را خواهند داشت.

با فلگ مشابه --source-date-epoch که به طور پیش‌فرض بر برچسب زمانی محتویات لایه‌ها تأثیر نمی‌گذارد، تداخل دارد.

--tls-verify bool-value

الزام به استفاده از HTTPS و اعتبارسنجی گواهی‌ها هنگام برقراری ارتباط با رجیستری‌های کانتینر (پیش‌فرض true است). اعتبارسنجی TLS هنگام ارتباط با رجیستری‌های ناامن نمی‌تواند استفاده شود.

--unsetannotation annotation

حذف یادداشت (annotation) ایمیج، که باعث می‌شود این یادداشت از ایمیج پایه به ارث برده نشود.

--unsetenv env

حذف متغیرهای محیطی از ایمیج نهایی.

این مثال یک ایمیج بر پایه کانتینر ذخیره می‌کند.
buildah commit containerID newImageName

این مثال یک ایمیج با نام newImageName بر پایه کانتینر ذخیره کرده و کانتینر در حال کار را حذف می‌کند.
buildah commit --rm containerID newImageName

این مثال بر پایه کانتینر، در یک فایل آرشیو OCI به نام /tmp/newImageName کامیت می‌کند.
buildah commit containerID oci-archive:/tmp/newImageName

این مثال یک ایمیج بدون نام ذخیره می‌کند، کانتینر در حال کار را حذف می‌نماید و با استفاده از شناسه ایمیج، کانتینر جدیدی ایجاد می‌کند.
buildah from $(buildah commit --rm containerID)

این مثال یک ایمیج بر پایه کانتینر با غیرفعال کردن فشرده‌سازی ذخیره می‌کند.
buildah commit --disable-compression containerID

این مثال یک ایمیج با نام newImageName بر پایه کانتینر با غیرفعال کردن فشرده‌سازی ذخیره می‌کند.
buildah commit --disable-compression containerID newImageName

این مثال کانتینر را در ایمیج روی رجیستری محلی کامیت می‌کند در حالی که اعتبارسنجی TLS غیرفعال است.
buildah commit --tls-verify=false containerID docker://localhost:5000/imageId

این مثال کانتینر را با استفاده از اطلاعات کاربری و گواهی‌ها برای احراز هویت، در ایمیج روی رجیستری محلی کامیت می‌کند.
buildah commit --cert-dir ~/auth --tls-verify=true --creds=username:password containerID docker://localhost:5000/imageId

این مثال کانتینر را با استفاده از اطلاعات کاربری موجود در فایل /tmp/auths/myauths.json و گواهی‌ها برای احراز هویت، در ایمیج روی رجیستری محلی کامیت می‌کند.
buildah commit --authfile /tmp/auths/myauths.json --cert-dir ~/auth --tls-verify=true --creds=username:password containerID docker://localhost:5000/imageName

این مثال یک ایمیج بر پایه کانتینر ذخیره می‌کند، اما تاریخ‌ها را بر اساس زمان مبدأ (epoch) ذخیره می‌نماید. buildah commit --timestamp=0 containerID newImageName

#!/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

BUILD_REGISTRY_SOURCES

متغیر BUILD_REGISTRY_SOURCES در صورت تنظیم، به عنوان یک شیء JSON در نظر گرفته می‌شود که شامل فهرست‌هایی از نام‌های رجیستری تحت کلیدهای insecureRegistries، blockedRegistries و allowedRegistries است.

هنگام کامیت کردن یک ایمیج، اگر قرار باشد نامی به ایمیج اختصاص داده شود، بخشی از نام که متناظر با رجیستری است با موارد موجود در فهرست blockedRegistries مقایسه می‌شود و در صورت تطابق با هر یک از آن‌ها، تلاش برای کامیت رد خواهد شد. اگر رجیستری‌هایی در فهرست allowedRegistries وجود داشته باشد و بخشی از نام که متناظر با رجیستری است در آن فهرست نباشد، تلاش برای کامیت رد می‌شود.

TMPDIR متغیر محیطی TMPDIR به کاربر امکان می‌دهد مشخص کند که فایل‌های موقت هنگام دریافت (pull) و ارسال (push) ایمیج‌ها در کجا ذخیره شوند. پیش‌فرض '/var/tmp' است.

registries.conf (/etc/containers/registries.conf)

فایل registries.conf فایل پیکربندی است که مشخص می‌کند هنگام تکمیل نام ایمیج‌هایی که فاقد بخش رجیستری یا دامنه هستند، به کدام رجیستری‌های کانتینر باید مراجعه شود.

policy.json (/etc/containers/policy.json)

فایل خط‌مشی امضا. این فایل خط‌مشی اعتماد را برای ایمیج‌های کانتینر تعریف می‌کند. کنترل می‌کند که کدام رجیستری‌های کانتینر می‌توانند برای ایمیج استفاده شوند، و آیا ابزار باید به ایمیج‌ها اعتماد کند یا خیر.

buildah(1), buildah-images(1), containers-policy.json(5), containers-registries.conf(5), containers-transports(5), containers-auth.json(5)

March 2017 buildah