0
votes

Docker registry is configured to support multiple docker registries as described by https://jfrog.com/knowledge-base/how-do-i-access-multiple-artifactory-docker-repositories-from-a-single-url/. This has allowed us to set up our local and remote repository and simply login to the virtual repository to push and pull images.

After upgrading from version 5.1.3 to 6.0.1 of Artifactory, we are no longer able to push to our virtual repository or local repository. We can login to the repository and pull from it.

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

On Artifactory we see in the artifactory.log

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/

On access.log we see

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

Even though we are signed in and can pull our images.

On request.log we see

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
1

1 Answers

4
votes

The article you referenced and the method you are using piggybacks undocumented API behaviour of the Docker V2 API in Artifactory. Specifically, it relies on the POST "blobs/uploads" endpoint (the one you included from your log) to extract the repository name from the request Host header (which Apache sets based on the request path) and reconstruct an adjacent Location response header that is used by the Docker client in subsequent requests to upload the blob content.

I would not be very surprised if this solution no longer works taking into account the fact that the Docker implementation in Artifactory underwent some changes in recent versions and now supports a "proxy-less" configuration. In fact, you can now use the very same method you are using to push and pull images to Artifactory, w/o having to configure any such hacks on your reverse proxy. I strongly recommend that you take a look at this section and consider deprecating your current solution:

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

We do still recommend using a reverse proxy server in front of Artifactory (for SSL termination, and other generic performance considerations), but since you are already including the repository name as part of your docker tags, the transition should be quite smooth for you.

I hope this helps.