Не удается перейти в реестр Artifactory Docker

Question

Реестр Docker настроен для поддержки нескольких реестров докеров, как описано в https://jfrog.com/knowledge-base/how-do-i-access-multiple-artifactory-docker-repositories-from-a-single-url/. Это позволило нам настроить наш локальный и удаленный репозиторий и просто войти в виртуальный репозиторий для отправки и извлечения образов.

После обновления версии Artifactory с версии 5.1.3 до 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 мы видим в 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/

На access.log мы видим

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

Даже если мы вошли в систему и можемпотяните наши изображения.

По запросу.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

Статья, на которую вы ссылались, и метод, который вы используете в качестве контрагента, недокументированное поведение API Docker V2 API в Artifactory.В частности, он использует конечную точку POST «blobs / uploads» (ту, которую вы включили в ваш журнал) для извлечения имени репозитория из заголовка Host запроса (который Apache устанавливает на основе пути запроса) и восстановления соседнего заголовка ответа Location, которыйиспользуется клиентом Docker в последующих запросах для загрузки содержимого BLOB-объекта.

Я не был бы очень удивлен, если бы это решение больше не работало, принимая во внимание тот факт, что реализация Docker в Artifactory претерпела некоторые изменения в последних версияхи теперь поддерживает конфигурацию без прокси.Фактически, теперь вы можете использовать тот же метод, который вы используете для передачи и извлечения изображений в Artifactory, без необходимости настраивать любые такие хаки на вашем обратном прокси-сервере.Я настоятельно рекомендую вам взглянуть на этот раздел и рассмотреть вопрос об устаревании вашего текущего решения:

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

Мы по-прежнему рекомендуем использовать обратный прокси-сервер перед Artifactory (для завершения SSL и других общих соображений производительности), но поскольку вы уже включили имя репозитория в свои теги Docker, переход должен быть достаточно плавным для вас.

Надеюсь, это поможет.