.nh
.TH containers-registries.d 5 "اوت ۲۰۱۶" "Containers" "راهنمای لینوکس"

.SH "نام (NAME)"
containers-registries.d \- دایرکتوری پیکربندی برای مخازن مختلف رجیستری کانتینر


.SH "توضیحات (DESCRIPTION)"
دایرکتوری پیکربندی رجیستری‌ها شامل تنظیمات مربوط به رجیستری‌های گوناگون (سرورهای نگهداری ایمیج‌های دوردست کانتینر) و محتوای ذخیره‌شده در آن‌ها است؛ به گونه‌ای که نیازی به ارائه مکرر این تنظیمات در گزینه‌های خط فرمان برای تک‌تک دستورات نباشد و بتواند بین تمامی کاربران containers/image به اشتراک گذاشته شود.

.PP
به‌طور پیش‌فرض، پیکربندی registries.d می‌تواند توسط ارائه‌دهنده سیستم در مسیر \fB/usr/share/containers/registries.d/\fR فراهم شود، توسط مدیر سیستم در مسیر \fB/etc/containers/registries.d/\fR بازنویسی گردد، و به ازای هر کاربر در مسیر \fB$XDG_CONFIG_HOME/containers/registries.d/\fR (یا \fB$HOME/.config/containers/registries.d/\fR در صورت تنظیم نشدن \fB$XDG_CONFIG_HOME\fR) سفارشی‌سازی شود.

.PP
دایرکتوری‌های الحاقی ویژه حالت‌های با ریشه (rootful) و بدون ریشه (rootless) نیز در صورت امکان مورد بررسی قرار می‌گیرند:
.IP \(bu 2
\fB/usr/share/containers/registries.rootful.d/\fR (شناسه کاربر UID == 0)
.IP \(bu 2
\fB/usr/share/containers/registries.rootless.d/\fR (شناسه کاربر UID > 0)
.IP \(bu 2
\fB/usr/share/containers/registries.rootless.d/<UID>/\fR (شناسه کاربر UID > 0)
.IP \(bu 2
\fB/etc/containers/registries.rootful.d/\fR (شناسه کاربر UID == 0)
.IP \(bu 2
\fB/etc/containers/registries.rootless.d/\fR (شناسه کاربر UID > 0)
.IP \(bu 2
\fB/etc/containers/registries.rootless.d/<UID>/\fR (شناسه کاربر UID > 0)

.PP
تنها فایل‌های با پسوند \fB\&.yaml\fR خوانده می‌شوند. برنامه‌ها ممکن است امکان استفاده از یک دایرکتوری دیگر را نیز فراهم کنند (برای مثال از طریق بازنویسی صریح).

.SH "ساختار دایرکتوری (DIRECTORY STRUCTURE)"
این دایرکتوری می‌تواند شامل هر تعداد فایل با پسوند \fB\&.yaml\fR باشد که هر کدام از قالب YAML پیروی می‌کنند. به‌جز پسوند اجباری، نام فایل‌ها اهمیتی ندارد.

.PP
محتوای این فایل‌ها با یکدیگر ادغام می‌شوند؛ به منظور داشتن رفتاری کاملاً مشخص و شفاف، در میان تمام فایل‌ها تنها یک بخش پیکربندی می‌تواند یک فضای نام مشخص در یک رجیستری را توصیف کند (به‌ویژه در میان تمامی فایل‌ها حداکثر یک بخش \fBdefault-docker\fR می‌تواند وجود داشته باشد و حداکثر یک نمونه از هر کلید در زیر بخش \fBdocker\fR مجاز است؛ این بخش‌ها در ادامه توضیح داده شده‌اند).

.PP
بنابراین، وجود دو پیکربندی متناقض برای یک رجیستری یا دامنه کاری (scope) واحد ممنوع است؛ همچنین تقسیم پیکربندی یک رجیستری یا دامنه منفرد در بیش از یک فایل نیز ممنوع می‌باشد (حتی اگر از نظر معنایی با هم تناقضی نداشته باشند).

.SH "رجیستری‌ها، دامنه‌ها و ترتیب جستجو (REGISTRIES, SCOPES AND SEARCH ORDER)"
هر فایل YAML باید شامل یک «نگاشت YAML» (جفت‌های کلید-مقدار) باشد. دو کلید سطح بالا (top-level) تعریف شده‌اند:
.IP \(bu 2
کلید \fBdefault-docker\fR یک \fIبخش پیکربندی\fP (مطابق مستندات زیر) برای رجیستری‌های پیاده‌سازی‌کننده "Docker Registry HTTP API V2" است.

.PP
این کلید اختیاری است.
.IP \(bu 2
کلید \fBdocker\fR یک نگاشت است که رجیستری‌های منفرد پیاده‌سازی‌کننده "Docker Registry HTTP API V2"، یا فضاهای نام و ایمیج‌های منفرد درون این رجیستری‌ها را به عنوان کلید استفاده می‌کند؛ مقدار اختصاص‌یافته به هر یک از این کلیدها یک \fIبخش پیکربندی\fP است.

.PP
این کلید اختیاری است.

.PP
دامنه‌هایی که با ایمیج‌های منفرد تطابق دارند، ارجاعات نام‌گذاری‌شده داکر \fIبه صورت کامل و بسط‌یافته\fP هستند، چه با استفاده از تگ یا شناسه یکتای هش (digest). برای مثال، \fBdocker.io/library/busybox:latest\fR (و \fIنه\fP \fBbusybox:latest\fR).

.PP
دامنه‌های عمومی‌تر، پیشوندهای دامنه‌های مربوط به ایمیج منفرد هستند و یک مخزن (با حذف برچسب یا شناسه هش)، یک فضای نام مخزن، یا یک میزبان رجیستری (و پورت آن در صورت تفاوت با پیش‌فرض) را مشخص می‌کنند.

.PP
توجه داشته باشید که اگر به یک رجیستری از طریق پیکربندی hostname+port دسترسی پیدا شود، نام میزبان بدون پورت به عنوان دامنه والد استفاده \fIنمی‌شود\fP.

.PP
هنگام جستجو برای یافتن پیکربندی قابل اعمال بر روی یک ایمیج کانتینر منفرد، تنها پیکربندی دقیق‌ترین دامنه منطبق استفاده می‌شود؛ و پیکربندی‌های دارای دامنه‌های عمومی‌تر نادیده گرفته می‌شوند. برای مثال، اگر \fIهرگونه\fP پیکربندی برای \fBdocker.io/library/busybox\fR وجود داشته باشد، پیکربندی مربوط به \fBdocker.io\fR نادیده گرفته خواهد شد (حتی اگر بخشی از پیکربندی برای \fBdocker.io\fR تعریف شده باشد و برای \fBdocker.io/library/busybox\fR وجود نداشته باشد).

.SS "پیش‌فرض‌های توکار (Built-in Defaults)"
اگر هیچ بخش \fBdocker\fR برای ایمیج کانتینر پیدا نشود و بخش \fBdefault-docker\fR نیز پیکربندی نشده باشد:
.IP \(bu 2
دایرکتوری پیش‌فرض، \fB/var/lib/containers/sigstore\fR برای کاربر ریشه و \fB$HOME/.local/share/containers/sigstore\fR برای کاربر غیرممتاز، جهت خواندن و نوشتن امضاها استفاده خواهد شد.
.IP \(bu 2
پیوست‌های Sigstore خوانده یا نوشته نخواهند شد.

.SH "بخش‌های پیکربندی منفرد (INDIVIDUAL CONFIGURATION SECTIONS)"
یک بخش پیکربندی منفرد برای یک ایمیج کانتینر با استفاده از فرآیند شرح‌داده‌شده در بالا انتخاب می‌شود. بخش پیکربندی یک نگاشت YAML با کلیدهای زیر است:

.IP \(bu 2
کلید \fBlookaside-staging\fR یک نشانی وب (URL) از فضای ذخیره‌سازی امضا تعیین می‌کند که برای ویرایش آن (افزودن یا حذف امضاها) استفاده می‌شود.

.PP
این کلید اختیاری است؛ اگر وجود نداشته باشد، کلید \fBlookaside\fR در زیر استفاده خواهد شد.
.IP \(bu 2
کلید \fBlookaside\fR یک نشانی وب از فضای ذخیره‌سازی امضا مشخص می‌کند.
این URL برای خواندن امضاهای موجود استفاده می‌شود، و اگر \fBlookaside-staging\fR وجود نداشته باشد، برای افزودن یا حذف امضاها نیز به کار می‌رود.

.PP
این کلید اختیاری است؛ در صورت عدم وجود، هیچ فضای ذخیره‌سازی امضایی تعریف نمی‌شود (هیچ امضایی همراه ایمیج‌ها بارگیری نمی‌شود، و افزودن امضاهای جدید تنها در صورتی ممکن است که \fBlookaside-staging\fR تعریف شده باشد).
.IP \(bu 2
کلید \fBuse-sigstore-attachments\fR مشخص می‌کند که آیا پیوست‌های ایمیج sigstore (امضاها، تاییدیه‌ها و موارد مشابه) همراه با ایمیج خوانده/نوشته شوند یا خیر.
در صورت غیرفعال بودن، با ایمیج‌ها به گونه‌ای رفتار می‌شود که گویی هیچ پیوستی وجود ندارد؛ تلاش‌ها برای نوشتن پیوست با شکست مواجه خواهد شد.

.SH "مثال‌ها (EXAMPLES)"
.SS "استفاده از کانتینرها از منابع گوناگون"
مثال زیر نحوه استفاده و اجرای ایمیج‌ها از رجیستری‌ها و فضاهای نام مختلف را نشان می‌دهد:

.EX
docker:
    registry.database-supplier.com:
        lookaside: https://lookaside.database-supplier.com
    distribution.great-middleware.org:
        lookaside: https://security-team.great-middleware.org/lookaside
    docker.io/web-framework:
        lookaside: https://lookaside.web-framework.io:8080
.EE

.SS "توسعه و امضای کانتینرها، مرحله‌بندی امضاها"
برای توسعه‌دهندگان در \fBexample.com\fR:
.IP \(bu 2
بیشتر ایمیج‌های کانتینر با استفاده از سرورهای عمومی که کاربران نیز استفاده می‌کنند، دریافت شوند.
.IP \(bu 2
استفاده از یک فضای ذخیره‌سازی امضای جداگانه برای ایمیج‌های کانتینر در یک فضای نام مربوط به بخش توسعه‌دهندگان، همراه با فضای مرحله‌بندی (staging) که پیش از انتشار امضاها استفاده می‌شود.
.IP \(bu 2
ایجاد یک استثنای اختصاصی برای یک شاخه منفرد که یک توسعه‌دهنده خاص به صورت محلی بر روی آن کار می‌کند.

.EX
docker:
    registry.example.com:
        lookaside: https://registry-lookaside.example.com
    registry.example.com/mydepartment:
        lookaside: https://lookaside.mydepartment.example.com
        lookaside-staging: file:///mnt/mydepartment/lookaside-staging
    registry.example.com/mydepartment/myproject:mybranch:
        lookaside: http://localhost:4242/lookaside
        lookaside-staging: file:///home/useraccount/webroot/lookaside
.EE

.SS "یک پیش‌فرض عمومی و سراسری"
اگر شرکتی محصولات خود را با دامنه‌ای متفاوت و نام میزبان رجیستری متمایز برای هر یک از آن‌ها منتشر کند، همچنان می‌توان از یک سرور ذخیره‌سازی امضای واحد بدون نیاز به فهرست کردن تک‌تک دامنه‌ها استفاده کرد. انتظار می‌رود این حالت به ندرت پیش بیاید و معمولاً تنها برای مرحله‌بندی امضاهای جدید کاربرد دارد.

.EX
default-docker:
    lookaside-staging: file:///mnt/company/common-lookaside-staging
.EE

.SH "نویسندگان (AUTHORS)"
Miloslav Trmač mitr@redhat.com
\[la]mailto:mitr@redhat.com\[ra]