跳到内容

GitLab容器注册

注:介绍了在GitLab 8.8中。

  • Docker注册表v1在GitLab 8.9中增加了对Docker 1.10之前版本的支持。
  • 本文档主要介绍用户指南。要了解如何跨GitLab实例启用GitLab容器注册表，请访问管理员文档．
  • 从GitLab 8.12开始，如果你的帐户启用了2FA，你需要通过一个个人访问令牌而不是你的密码，以便登录到GitLab的容器注册。
  • 在GitLab 9.1中增加了对多级映像名的支持

通过将Docker容器注册表集成到GitLab中，每个项目都可以拥有自己的空间来存储Docker映像。

你可以在这里阅读更多关于Docker Registry的信息https://docs.docker.com/registry/introduction/．

为项目启用容器注册表

注意:注意:如果在项目的设置下找不到容器注册表项，这意味着它在GitLab实例中没有启用。请管理员启用它。

  1. 首先，请您的系统管理员按照管理文档．如果您正在使用GitLab.com，默认情况下是启用的，因此您可以立即开始使用注册表。目前，GitLab.com上的注册表有一个软(10GB)大小限制，作为存储库大小限制．
  2. 去你的项目一般设置并启用容器注册表突出你的项目。对于新项目，这可能是默认启用的。对于现有的项目(之前的GitLab 8.8)，您必须显式地启用它。
  3. 打击保存更改以便更改生效。您现在应该能够看到注册表链接。

容器注册表

生成和推送图像

注:

  • 一旦您推送了映像，就不支持移动或重命名现有的容器注册表存储库，因为映像已签名，且签名包含存储库名称。
  • 要使用容器注册表移动或重命名存储库，必须删除所有现有映像。

如果你参观注册表链接，你可以看到使用你的GitLab凭证登录到容器注册表的显式说明。

例如，如果注册中心的URL是registry.example.com，你便可登入:

Docker登录registry.example.com

构建和发布图像应该是一个简单的过程。只需要确保你使用的注册表URL带有托管在GitLab上的名称空间和项目名称:

Docker build -t registry.example.com/group/project/image。Docker推送registry.example.com/group/project/image

您的图像将以以下方案命名:

<注册URL > / <名称> / <项目> / <图片>

GitLab最多支持三个级别的映像存储库名称。

以下图像标签的例子是有效的:

registry.example.com/group/project: some-tagregistry.example.com/group/project/image:最新registry.example.com/group/project/my/image: rc1

使用来自GitLab容器注册表的映像

要从托管在GitLab容器注册表中的映像下载并运行容器，请使用码头工人运行：

Docker运行[选项]registry.example.com/group/project/image[参数]

有关运行Docker容器的更多信息，请访问码头工人的文档．

从GitLab中控制容器注册表

GitLab提供了一个简单的容器注册管理面板。转到您的项目并单击注册表在项目菜单中。

这个视图将显示项目中的所有标签，并允许您轻松删除它们。

使用GitLab CI构建和推送图像

注意:该特性需要GitLab 8.8和GitLab Runner 1.2。

确保您的GitLab Runner配置为允许构建Docker映像使用Docker构建而且使用GitLab容器注册表文档．

与私人项目一起使用

个人访问令牌是介绍了在GitLab 9.3中。项目部署令牌介绍了在GitLab 10.7中

如果项目是私有的，则需要为授权提供凭据。要做到这一点，首选的方法是使用个人访问令牌或者一个项目部署令牌．两者所需的最小范围是read_registry．

使用个人访问令牌的示例:

Docker login registry.example.com -u  -p

疑难解答GitLab容器注册表

基本故障排除

  1. 检查确保Docker客户端和GitLab服务器上的系统时钟已经同步(例如通过NTP)。

  2. 如果您正在使用S3支持的注册表，请仔细检查IAM权限和S3凭据(包括区域)是否正确。看到IAM策略示例欲知详情。

  3. 检查注册表日志(例如:/var/log/gitlab/registry/current)和GitLab生产日志中的错误(例如:/var/log/gitlab/gitlab-rails / production.log)．你也许能在那里找到线索。

先进的故障诊断

注意:以下部分仅推荐给专家。

有时，哪里出了问题并不明显，您可能需要深入研究Docker客户端和Registry之间的通信以找出哪里出了问题。我们将在过去使用一个具体示例来说明如何诊断S3设置中的问题。

推送过程中出现意外403错误

用户试图启用s3支持的注册表。的码头工人登录步骤很顺利。然而，当推送图像时，输出显示:

推送指的是一个存储库[s3-testing.myregistry.com:4567/root/docker-test/docker-image]dc5e59c14160:推  [==================================================>] 14.85 kB03 c20c1a019a:推  [==================================================>] 2.048 kBa08f14ef632e:推  [==================================================>] 2.048 kB228950524c88: push 2.048 kB6a8ecde4cc03: Pushing [==>] 9.901 MB/205.7 MB5f70bf18a086:推送1.024 kB737 f40e80b7f:等待82 b57dbc5385:等待19429 b698a22:等待9436069 b92a3:等待HTTP 403响应体:JSON输入的意外结束:""

这个错误是不明确的，因为它不清楚403是来自GitLab Rails应用程序、Docker Registry还是其他什么。在本例中，由于我们知道登录成功后，我们可能需要查看客户机和Registry之间的通信。

Docker客户端和注册表之间的REST API是这里描述．通常情况下，人们只需要使用Wireshark或tcpdump来捕获流量并查看哪里出了问题。然而，由于Docker客户端和服务器之间的所有通信都是通过HTTPS完成的，即使知道私钥，也很难快速解密流量。我们能做些什么呢?

一种方法是通过设置一个不安全的注册表．这可能会引入安全漏洞，仅建议用于本地测试。如果您有一个生产系统，不能或不想这样做，还有另一种方法:使用mitmproxy，它代表Man-in-the-Middle Proxy。

mitmproxy

mitmproxy允许您在客户端和服务器之间放置代理，以检查所有流量。一个问题是，您的系统需要信任mitmproxy SSL证书才能正常工作。

下面的安装说明假设你运行的是Ubuntu:

  1. 安装mitmproxy(参见http://docs.mitmproxy.org/en/stable/install.html）
  2. 运行Mitmproxy——端口9000来生成其证书。输入CTRL-C戒烟。

  3. 从安装证书~ / .mitmproxy对您的系统:

    sudo cp~ / .mitmproxy / mitmproxy-ca-cert。pem /usr/local/share/ca-certificates / mitmproxy-ca-cert.crtsudoupdate-ca-certificates

如果成功，输出应该表明添加了证书:

更新的证书在/etc/ssl/certs...加1，减0；完成．运行的钩子在/etc/ca-certificates / update.d……。

要验证证书是否正确安装，请执行:

mitmproxy——港口9000

这将在端口上运行mitmproxy9000．在另一个窗口中运行:

旋度——代理https://httpbin.org/status/200 http://localhost: 9000

如果一切设置正确，您将在mitmproxy窗口中看到信息，并且curl命令没有错误。

使用代理运行Docker守护进程

为了让Docker通过代理连接，必须使用适当的环境变量启动Docker守护进程。最简单的方法是关闭Docker。Sudo initctl stop docker)，然后手动运行Docker。以root用户运行:

出口HTTP_PROXY＝“http://localhost: 9000”出口HTTPS_PROXY＝“https://localhost: 9000”码头工人守护进程——调试

这将启动Docker守护进程并通过mitmproxy代理所有连接。

运行Docker客户端

现在我们已经运行了mitmproxy和Docker，我们可以尝试登录并推送一个容器映像。您可能需要以root用户身份运行来执行此操作。例如:

Docker登录s3-testing.myregistry.com:4567Docker推送s3-testing.myregistry.com:4567/root/ Docker -test/ Docker -image

在上面的例子中，我们在mitmproxy窗口上看到了以下跟踪:

从Docker输出mitmproxy

上图显示:

  • 最初的PUT请求顺利通过，状态代码为201。
  • 201将客户端重定向到S3桶。
  • AWS桶的HEAD请求报告了403未授权。

这是什么意思?这强烈地表明S3用户没有权限执行HEAD请求的权限．解决方案:检查再次查看IAM权限．一旦设置了正确的权限，错误就会消失。

Baidu
map