containers-registries.d man page
Miloslav Trmač August 2016
containers-registries.d — Directory for various registries configurations The registries configuration directory contains configuration for various registries (servers storing remote container images), and for content stored in them, so that the configuration does not have to be provided in command-line options over and over for every command, and so that it can be shared by all users of containers/image. By default (unless overridden at compile-time), the registries configuration directory is The directory may contain any number of files with the extension The contents of these files are merged together; to have a well-defined and easy to understand behavior, there can be only one configuration section describing a single namespace within a registry (in particular there can be at most one one Thus, it is forbidden to have two conflicting configurations for a single registry or scope, and it is also forbidden to split a configuration for a single registry or scope across more than one file (even if they are not semantically in conflict). Each YAML file must contain a “YAML mapping” (key-value pairs). Two top-level keys are defined: This key is optional. This key is optional. Scopes matching individual images are named Docker references in the fully expanded form, either More general scopes are prefixes of individual-image scopes, and specify a repository (by omitting the tag or digest), Note that if a registry is accessed using a hostname+port configuration, the port-less hostname When searching for a configuration to apply for an individual container image, only the configuration for the most-precisely matching scope is used; configuration using more general scopes is ignored. For example, if any configuration exists for A single configuration section is selected for a container image using the process described above. The configuration section is a YAML mapping, with the following keys: This key is optional; if it is missing, This key is optional; if it is missing, no signature storage is defined (no signatures The following demonstrates how to to consume and run images from various registries and namespaces: For developers in If a company publishes its products using a different domain, and different registry hostname for each of them, it is still possible to use a single signature storage server without listing each domain individually. This is expected to rarely happen, usually only for staging new signatures. Miloslav Trmač mitr@redhat.com ⟨mailto:mitr@redhat.com⟩Description
/etc/containers/registries.d
; applications may allow using a different directory instead.Directory Structure
.yaml
, each using the YAML format. Other than the mandatory extension, names of the files don’t matter.default-docker
section across all files, and there can be at most one instance of any key under the the docker
section; these sections are documented later).Registries, Scopes and Search Order
default-docker
is the configuration section (as documented below) for registries implementing "Docker Registry HTTP API V2".docker
is a mapping, using individual registries implementing "Docker Registry HTTP API V2", or namespaces and individual images within these registries, as keys; the value assigned to any such key is a configuration section.
using a tag or digest. For example, docker.io/library/busybox:latest
(not busybox:latest
).
a repository namespace, or a registry host (and a port if it differs from the default).
is not used as parent scope.docker.io/library/busybox
, the configuration for docker.io
is ignored (even if some element of the configuration is defined for docker.io
and not for docker.io/library/busybox
).Individual Configuration Sections
sigstore-staging
defines an URL of of the signature storage, used for editing it (adding or deleting signatures).sigstore
below is used.sigstore
defines an URL of the signature storage. This URL is used for reading existing signatures, and if sigstore-staging
does not exist, also for adding or removing them.
are download along with images, adding new signatures is possible only if sigstore-staging
is defined).Examples
Using Containers from Various Origins
docker:
registry.database-supplier.com:
sigstore: https://sigstore.database-supplier.com
distribution.great-middleware.org:
sigstore: https://security-team.great-middleware.org/sigstore
docker.io/web-framework:
sigstore: https://sigstore.web-framework.io:8080
Developing and Signing Containers, Staging Signatures
example.com
:docker:
registry.example.com:
sigstore: https://registry-sigstore.example.com
registry.example.com/mydepartment:
sigstore: https://sigstore.mydepartment.example.com
sigstore-staging: file:///mnt/mydepartment/sigstore-staging
registry.example.com/mydepartment/myproject:mybranch:
sigstore: http://localhost:4242/sigstore
sigstore-staging: file:///home/useraccount/webroot/sigstore
A Global Default
default-docker:
sigstore-staging: file:///mnt/company/common-sigstore-staging
Authors
Info