特性

适用于任何注册表的拉取式缓存，不仅限于docker.io
- 这包括私有的、需要身份验证的注册表。这意味着你可以轻松创建一个无需身份验证的私有注册表镜像，并将其暴露在互联网上。请不要这样做。
两种存储后端
- S3
- 本地文件系统
占用资源小；在我的测试系统中，官方registry使用约130 MiB内存来镜像docker.io；而oci-registry的五个副本合计使用约60 MiB内存来镜像example.yaml中的所有内容，外加一个私有注册表。两者的CPU占用都可以忽略不计。
提供helm chart

局限性

目前不支持推送；oci-registry当前仅支持作为拉取式缓存（镜像）。计划添加推送支持。
目前不支持身份验证，但计划添加。
仅支持SHA256内容哈希，但计划支持其他方案。
不支持使用TLS（https）连接到oci-registry，也不会添加此支持。
- 使用nginx作为TLS终止代理简单、有良好支持和文档；如果你需要客户端和oci-registry之间的TLS，建议使用这种配置。
- 支持、推荐并通常要求使用TLS连接上游注册表。
如果两个客户端同时请求相同的blob，它会从上游并行下载两次，而不是让后来的请求等待下载完成后从缓存提供。这不会导致数据损坏，但效率不高。目前没有计划修复，但欢迎提出建议。
尚未运行OCI分发规范一致性测试套件；只进行了与docker和containerd的手动兼容性测试。计划在实现推送支持后进行测试。

示例

`docker`

镜像docker.io是默认配置。启动oci-registry：

oci-registry --listen 0.0.0.0:8080 filesystem --root /tmp/oci-mirror

配置Docker的daemon.json使用注册表：

{
	"registry-mirrors": ["http://localhost:8080"]
}

重启Docker，它将开始通过oci-registry拉取docker.io的镜像。

注意：Docker无法镜像docker.io以外的注册表。

`containerd`

containerd提供了镜像任何注册表的机制，并在所有请求中以查询字符串参数发送上游注册表。这意味着我们可以用单个oci-registry实例为containerd镜像任意数量的注册表。

`cri-o`

cri-o要求为每个想要镜像的注册表定义配置，但你可以为每个注册表使用单独的路径来告诉oci-registry请求针对的是哪个注册表。

配置`oci-registry`

oci-registry的默认配置是镜像任何收到请求的注册表，使用HTTPS连接上游，拒绝无效证书，并使用命名空间作为上游注册表主机 - 例如，对gcr.io镜像的请求将发送到https://gcr.io/ - 除了docker.io，它将指向https://registry-1.docker.io

简而言之，oci-registry的默认配置适用于大多数公共注册表，但可以通过--upstream-config-file添加配置。参见example.yaml中的实际示例，或以下虚构的私有注册表示例：

# namespace和host是唯一两个必需的键
- namespace: example.com
  host: registry.example.com
  # 默认使用TLS连接
  tls: true
  # 默认要求有效的TLS证书
  accept_invalid_certs: false
  # 这个假设的注册表检查HTTP User-Agent头以确保没有恶意行为，所以假装是containerd
  user_agent: "containerd/1.6.8"
  # 这个假设的注册表需要身份验证，所以我们提供用户名和密码
  username: example
  password: hunter2
  # 这个假设的注册表用于活跃开发，所以让我们始终检查给定镜像的最新清单
  manifest_invalidation_time: 0s
  # Blob通过其内容的SHA256哈希识别，所以它们可能不会经常变化，如果有的话
  blob_invalidation_time: 30d

为避免在明文文件中存储凭证，可以将JSON映射存储在$UPSTREAM_CREDENTIALS环境变量中，如下所示：

UPSTREAM_CREDENTIALS='{"example.com": {"username": "example", "password": "hunter2"}, "docker.io": {"username": "aaa", "password": "bbb"}}'

注意，这在Helm chart中没有暴露，因为配置本身已经从secret中挂载。

配置`containerd`

最近版本的containerd（1.5+）使用每个主机的配置文件；对于旧版本，配置说明可以在这里的已弃用部分找到。

假设使用默认路径，确保你的/etc/containerd/config.toml包含以下内容：

[plugins."io.containerd.grpc.v1.cri".registry]
	config_path = "/etc/containerd/certs.d"

然后，在/etc/containerd/certs.d中，为每个你想镜像的注册表创建一个目录，并创建一个指向oci-registry的hosts.toml：

mkdir /etc/containerd/certs.d/docker.io
cat > /etc/containerd/certs.d/docker.io/hosts.toml <<EOF
server = "https://registry-1.docker.io"

[host."http://localhost:8080"]
	capabilities = ["pull", "resolve"]
EOF

mkdir /etc/containerd/certs.d/gcr.io
cat > /etc/containerd/certs.d/gcr.io/hosts.toml <<EOF
server = "https://gcr.io"

[host."http://localhost:8080"]
	capabilities = ["pull", "resolve"]
EOF

上述示例将配置containerd尝试从监听在localhost:8080的oci-registry拉取docker.io和gcr.io的清单和blob，同时保持使用原始主机进行推送，如果oci-registry出现问题，则使用原始主机。

配置`cri-o`

cri-o使用通用的registries.conf配置文件来指定要镜像的注册表。

假设使用默认路径，只需将以下内容添加到/etc/containers/registries.conf：

[[registry]]
location = "docker.io"
[[registry.mirror]]
location = "localhost:8080/docker.io"
insecure = true

[[registry]]
location = "gcr.io"
[[registry.mirror]]
location = "localhost:8080/gcr.io"
insecure = true

上述示例将配置cri-o尝试从监听在localhost:8080的oci-registry拉取docker.io和gcr.io的清单和blob，同时保持使用原始主机进行推送，如果oci-registry出现问题，则使用原始主机。