斯科特•莫舍
2023-01-22 11:06

Docker调试和理解对传入请求的期望

在本文中，我们将不再赘述wiki at中已经列出的Docker配置步骤//www.si-fil.com/confluence/display/JFROG/Docker+Registry，但将有助于理解配置实现了什么，它如何与Artifactory一起工作，以及如果我们遇到配置问题时如何调试。

每个Docker方法(Repository Path、子域和端口)都以Artifactory期望的方式格式化请求。它最终不会改变Artifactory处理传入Docker请求的方式。我们将遍历可以解析每种请求类型的预期请求。

码头工人登录:

在初始身份验证请求期间，我们总是会在Docker客户端看到401，这是预料之中的。一旦401返回，Docker客户端就发送凭据。
| non_authenticated_user | | / api /码头工人/ v2 / | 401 | |user|GET|/api/docker/null/v2/token|200|(这个请求中的null也可以是我们正在登录的存储库名称，但在这个请求中，我们获得的是Artifactory注册表本身的令牌) 用户| | | / api /码头工人/ v2 / | 200 |

我们可以通过curl模拟Docker登录来进一步调试以收集更多的信息(这是特定于存储库路径的请求，但可以通过其他方法更新)。

curl -uuser http://PLATFORM_URL/v2/DOCKER_REPO/token -v

提取Docker映像:

对于多克拉，我们不期望同样的401。现在我们有了令牌，因此我们应该在请求中看到经过身份验证的用户。我们现在期待HEAD和GET请求。
|用户| |头/ api /码头工人/ docker-remote / v2 /图像/表现/ some-tag | 200 |

然后我们开始看到舱单拉力。
用户| | | / api /码头工人/ docker-remote / v2 /图像/表现/ sha256:12321321adfasdf1f6a2a14b56891f10b6c87b7d7b846253f95934dd6932 | 200 |

一旦我们得到清单，我们就可以提取实际的斑点。
用户| | | / api /码头工人/ docker-remote / v2 /图像/团/ sha256: eaaf2ec477ce7fcb2bc1f6a2a14b1f10b6c87b7d77b846253f95934dd6932 | 200 | 用户| | | / api /码头工人/ docker-remote / v2 /图像/团/ sha256:1f10b6c87b7d79222265c132a5231af7c8584a907e2afc6df0634b78ba98f | 200 |

同样，我们可以通过curl请求进一步测试这种拉力。我们将使用从之前运行的登录请求返回的令牌。

curl -H "Authorization: Bearer " -vk
https://PLATFORM_URL/v2/docker/hello-world/manifests/latest

(在这个例子中，docker是一个虚拟存储库，它包含一个指向dockerhub的docker远程存储库)

推送Docker镜像

对于Docker推送，这些请求就不那么简单了。同样，所有这些请求都应该经过身份验证，并且最初将是HEAD请求。
用户| | |头/ api /码头工人/ docker-local / v2 /道路/图像/团/ sha256: be248e90f762e2a43bb52249552e74eceb8e629f1392c664468bf946ea12472c | 404 | 用户| | |头/ api /码头工人/ docker-local / v2 /道路/图像/团/ sha256:73dd2a7a91633255c1c8687f3a368b651f6cdc87637e1aa3e6a67ac7868a296b | 404 |

然后我们看到POST命令上传到临时上传目录。
用户| | |后/ api /码头工人/码头工人/ v2 /道路/一些图像/团/上传/ | 202 | 用户| | |后/ api /码头工人/码头工人/ v2 /道路/一些图像/团/上传/ | 202 |

然后应该看到以下针对blob的PATCH和PUT请求，最后一个请求将是清单/标记。
| |用户|补丁/ api /码头工人/ docker-local / v2 /道路/图像/团/上传/ b3526fec - 5803 - 4733 - a1ac e52e7d09173b | 202 | | | |用户补丁/ api /码头工人/ docker-local / v2 /道路/图像/团/上传/ 7953 cdb7-9a59-4b7e-bab9-fcbde155e972 | 202 | | |用户把| / api /码头工人/ docker-local / v2 /道路/图像/团/上传/ b3526fec - 5803 - 4733 - a1ac e52e7d09173b | 201 | | |用户把| / api /码头工人/ docker-local / v2 /道路/图像/团/上传/ 9 ce1ffc5-bf15-4eae-b4dd-2bd030aa8dc6 | 201 | | |用户把| / api /码头工人/ docker-local / v2 /道路/图像/表现/最新| 201 |

了解代理配置以及如何调试

我们将采用通用的nginx反向代理配置，因为在设置子域Docker方法时将使用这个或Apache。必需的配置是设置服务器名并进行重写。

server_name ~(? <回购>。+)。PLATFORM_URL PLATFORM_URL;
重写^ / (v1 | v2) / (. *) / artifactory / api /码头工人/回购美元/ 1 / 2美元;

这将使用子域中提供的存储库来按照Artifactory的期望构造请求。如果我们继续看到问题，我们也可以查看我们设置的标题。

proxy_set_header X-Forwarded-Port $server_port;
$http_x_forwarded_proto;
proxy_set_header $http_host;

上面的POST命令将获取请求中的报头集，并将PATCH请求推送到此位置。如果我们看到POST命令像预期的那样命中Artifactory，但是PATCH请求失败，这通常是无效报头的结果。

把这些放在一起

通过了解上述预期请求以及反向代理配置的目的，我们可以进一步调试并查明问题可能产生的位置。即使没有反向代理，我们仍然可以通过理解我们期望在日志中看到的内容来进一步排除故障。

首先要确认的是请求结构。我们希望在artifactory-request.log中看到，每个请求都以/api/docker/REPO_NAME开头。如果我们没有看到这种格式，我们可以指出Docker请求或反向代理配置是问题的原因，因为Artifactory正在接收错误格式的请求。

以下是一些糟糕请求的例子及其原因:

用户| | |后/ api /码头工人/ / v2 /道路/图像/团/上传/ | 404 |

(存储库名称丢失，这可能是由于反向代理没有正确设置$repo变量造成的)

用户| | | / v2 | 202 |

(由于来自Docker客户端的v2请求没有被重写到/api/ Docker /REPO_NAME/…)

用户| | | / api /码头工人/图像/ | 404 |

(Docker拉取请求中没有存储库名称)

在Artifactory配置中出现Docker问题的另一个常见原因是我们使用的Docker方法与管理面板上Artifactory -> Http设置选项卡下选择的Docker方法不匹配。我们还需要确认在我们正在访问的虚拟存储库中设置了默认部署存储库。

JFrog高级安全