Question

Docker注册表配置为支持多个docker注册表，如https://jfrog.com/knowledge-base/how-do-i-access-multiple-artifactory-docker-repositories-from-a-single-url/所述。这使我们能够设置本地和远程存储库，只需登录虚拟存储库即可推送和提取图像。

从版本5.1.3升级到Artifactory的6.0.1后，我们无法再推送到虚拟存储库或本地存储库。我们可以登录到存储库并从中获取。

docker push mycompany.com:6555/docker-virtual/helloworld
The push refers to repository [mycompany.com:6555/docker-virtual/helloworld]
2b8cbd0846c5: Pushing  1.848kB/1.848kB
http: no Host in request URL

我们在artifactory.log中看到的Artifactory

2018-06-05 08:15:19,879 [ajp-nio-8019-exec-2] [DEBUG] (o.a.w.s.AccessFilter:305) - Header authentication org.artifactory.security.props.auth.PropsAuthenticationToken@2473d3d9: Principal: USERHERE; Credentials: [PROTECTED]; Authenticated: true; Details: org.springframework.security.web.authentication.WebAuthenticationDetails@7798: RemoteIpAddress: 172.24.142.95; SessionId: null; Granted Authorities: admin, user found in cache.2018-06-05 08:15:19,879 [ajp-nio-8019-exec-2] [DEBUG] (o.a.w.s.RepoFilter  :100) - Entering request POST (172.24.142.95) /api/docker/docker-virtual/v2/helloworld/blobs/uploads/.
2018-06-05 08:15:19,880 [ajp-nio-8019-exec-2] [DEBUG] (o.a.w.s.RepoFilter  :337) - Identified'/api/lfs' in incoming ServletRequest path. Wrapping it with a GitLfsMalformedRequestWrapper
2018-06-05 08:15:19,880 [ajp-nio-8019-exec-2] [DEBUG] (o.a.w.s.RepoFilter  :380) - Returning fixed Docker Content-Type header content-type
2018-06-05 08:15:19,880 [ajp-nio-8019-exec-2] [DEBUG] (o.a.a.m.ModuleInfoUtils:348) - Could not transform helloworld/_uploads to a valid module info.
2018-06-05 08:15:19,880 [ajp-nio-8019-exec-2] [DEBUG] (o.a.a.m.ModuleInfoUtils:348) - Could not transform helloworld/_uploads to a valid module info.
2018-06-05 08:15:19,881 [ajp-nio-8019-exec-2] [DEBUG] (o.a.r.RealRepoBase  :79) - docker-virtual is not a valid module info -  'helloworld/_uploads': not enforcing snapshot/release policy.
2018-06-05 08:15:19,881 [ajp-nio-8019-exec-2] [DEBUG] (o.a.w.s.RepoFilter  :188) - Exiting request POST (172.24.142.95) /api/docker/docker-virtual/v2/helloworld/blobs/uploads/

在access.log上我们看到了

2018-06-05 08:21:17,525 [DENIED LOGIN]  for NA/172.24.142.95.

即使我们已登录并可以提取我们的图像。

在request.log上我们看到

20180605082119|19|REQUEST|IPHERE|USERNAMEHERE|POST|/api/docker/docker-virtual/v2/helloworld/blobs/uploads/|HTTP/1.1|202|0
20180605082124|10|REQUEST|IPHERE|USERNAMEHERE|POST|/api/docker/docker-virtual/v2/helloworld/blobs/uploads/|HTTP/1.1|202|0
20180605082135|10|REQUEST|IPHERE|USERNAMEHERE|POST|/api/docker/docker-virtual/v2/helloworld/blobs/uploads/|HTTP/1.1|202|0
20180605082150|10|REQUEST|IPHERE|USERNAMEHERE|POST|/api/docker/docker-virtual/v2/helloworld/blobs/uploads/|HTTP/1.1|202|0

Answer 1

您引用的文章以及您在Artifactory中使用Docker V2 API的未记录API行为的方法。具体来说，它依赖POST“blobs / uploads”端点（您在日志中包含的端点）从请求主机头（Apache根据请求路径设置）中提取存储库名称，并重新构建相邻的Location响应头， Docker客户端在后续请求中使用blob内容。

如果考虑到Artifactory中的Docker实现在最近的版本中经历了一些更改并且现在支持“无代理”配置，这个解决方案不再有效的话我不会感到非常惊讶。实际上，您现在可以使用与用于将图像推送到Artifactory的方法完全相同的方法，而无需在反向代理上配置任何此类黑客。我强烈建议您查看本节并考虑弃用您当前的解决方案：

https://www.jfrog.com/confluence/display/RTF/Configuring+a+Reverse+Proxy#ConfiguringaReverseProxy-UsingDirectAccess

我们仍然建议在Artifactory前面使用反向代理服务器（用于SSL终止，以及其他一般性能注意事项），但由于您已经将存储库名称包含在docker标记中，因此转换应该非常顺利对你而言。

我希望这会有所帮助。

无法推送Artifactory Docker Registry

1 个答案: