10

我在同一个 JFrog 云帐户/实例上运行了两个 docker 存储库。一个用于内部候选版本，另一个用于潜在的外部 GC 版本。我希望能够构建 docker 映像并推送到内部存储库，让 QA/UAT 去城里，然后将映像复制到发布存储库。我不想从源代码重建图像。不幸的是，当我尝试拉取、标记然后推送图像时，出现错误：

未经授权：将具有清单 v2 模式 1 的 Docker 映像推送到此存储库被阻止。

两个存储库都阻止模式 1 清单，但我正在将其推送到内部存储库，因此我无法将相同的图像推送到发布存储库并没有多大意义。

我设置了一个非常简单的测试来确认（实际存储库 URL 被审查）：

% docker pull hello-world:latest
latest: Pulling from library/hello-world
0e03bdcc26d7: Pull complete
...
% docker tag hello-world:latest internal-rc.jfrog.io/hello-world:1.0.0-beta
% docker push internal-rc.jfrog.io/hello-world:1.0.0-beta
The push refers to repository [internal-rc.jfrog.io/hello-world]
9c27e219663c: Pushed
...
% docker system prune -a
...
Total reclaimed space: 131.8MB
% docker image pull internal-rc.jfrog.io/hello-world:1.0.0-beta
1.0.0-beta: Pulling from hello-world
0e03bdcc26d7: Pull complete
...
% docker image tag internal-rc.jfrog.io/hello-world:1.0.0-beta docker-release.jfrog.io/hello-world:1.0.0
% docker image push docker-release.jfrog.io/hello-world:1.0.0
The push refers to repository [docker-release.jfrog.io/hello-world]
9c27e219663c: Layer already exists
[DEPRECATION NOTICE] registry v2 schema1 support will be removed in an upcoming release. Please contact admins of the docker-release.jfrog.io registry NOW to avoid future disruption. More information at https://docs.docker.com/registry/spec/deprecated-schema-v1/
unauthorized: Pushing Docker images with manifest v2 schema 1 to this repository is blocked. For more information visit https://www.jfrog.com/confluence/display/RTF/Advanced+Topics#AdvancedTopics-DockerManifestV2Schema1Deprecation

所以我可以将图片上传到第一个存储库，并确认它使用的是模式 2：

{
  "schemaVersion": 2,
  "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
  "config": {
    "mediaType": "application/vnd.docker.container.image.v1+json",
    "size": 7004,
    "digest": "sha256:66f750f4871ba45724699d7341ee7135caba46f63fb205351197464a66b55eff"
...

那mediaType是v1重要吗？清单本身似乎是第 2 版......但我不知道我将如何更改它，或者为什么它会被允许在一个存储库中而不是另一个存储库中。

我正在使用我相信最新版本的 dockerDocker version 19.03.8, build afacb8b

有人知道那里发生了什么吗？架构版本在我第一次上传和下载之间是否发生了变化？还是当我标记它或第二次上传它时？

4

3 回答 3

15

这个问题的根源大概可以归类为用户错误。具体来说，我正在使用的用户以某种方式从发布存储库中删除了权限。一旦恢复，一切都会按预期工作。

我说“可能”是因为错误消息与实际问题无关，并且花了我 2-3 个小时的时间去追逐野鹅。

所以...如果您看到此错误，请继续仔细检查权限/访问权限周围的所有其他内容，然后再尝试确定您的图像架构版本是否确实存在问题。

于 2020-04-22T02:14:18.017 回答
7

我们今天有一个不同的案例，有类似的错误。我在这里添加是因为这是目前谷歌的最高结果。

将具有清单 v2 架构 1 的Docker映像拉到此存储库被阻止。

修复是更改远程存储库上的设置。

通过 UI：Artifactory Admin -> Repositories -> Repositories -> Remote 选项卡

然后选择您的 Docker Hub 存储库，无论您将其命名为什么，然后在 Basic settings -> Docker Settings 下，取消选中标记为的复选框

图像清单 v2 架构 1 的块拉取

之后，我们的图像再次开始正常拉动。

本地 repos 上有一个类似的复选框用于推送。

对于它的价值，我们使用的是 Artifactory 版本7.18.5 rev 71805900

编辑：我们的特定问题的令人惊讶的是（可能）在此处更详细地解释：https ://www.jfrog.com/jira/browse/RTFACT-2591

由于 Docker Hub 行为的变化，Docker 拉取请求失败。现在 Docker Hub HTTP 响应标头以小写形式返回，例如，“content-type”而不是“Content-Type”，导致 Artifactory 无法从 Docker Hub 下载和缓存 Docker 图像。

但我们尚未测试升级是否允许我们重新启用上述复选框。

于 2021-05-13T16:46:48.397 回答
0

从构建服务器拉取或推送 docker 映像时，我遇到了以下错误。我在 env 中有一个代理，用于连接 docker 注册表。我的 DNS 服务器在解析代理 FQDN 时返回了一个不起作用的 IP 地址。我有 4 个 DNS 服务器和多个基于区域的代理服务器。一旦 DNS 更新并返回工作/功能代理，它就开始工作。在网络端也检查一下，它可能会解决问题。错误消息最初是误导性的，我虽然是 docker 层问题，凭据问题..但没有网络问题。对于以下错误

拉取图像配置时出错：未知 blob 或

[弃用通知] registry v2 schema1 支持将在即将发布的版本中删除。请立即联系 docker 注册表的管理员以避免将来中断。更多信息，请访问https://docs.docker.com/registry/spec/deprecated-schema-v1/ manifest invalid: manifest invalid 。将开始No.6尝试。

于 2021-05-13T13:38:49.863 回答