Gitlab Runner、Docker Registry和自签名证书

90次阅读

问题描述

在设置了一个使用自签名证书的Gitlab Registry后，需要让docker应用程序信任他的CA。他通过将CA.crt放入/etc/docker/certs.d/registry.gitlab.yourdomain:5000目录中来实现这一点。但是，他还需要让Gitlab Runner中的docker executor和dind服务信任该证书。他通过在config.toml中通过卷传递证书来解决这个问题。然而，Gitlab Runner使用的是旧的卷规范，所以:5000部分会导致问题。他知道有一个pre_clone_script存在，可以将证书映射到某个文件夹，然后移动它。但这并不能解决dind服务的问题，因为pre_clone_script只会在“main”容器中执行。

解决方案

请注意以下操作注意版本差异及修改前做好备份。

方案1

你可以通过将包含证书的文件夹进行卷映射来解决这个问题，而不仅仅是传输文件。
以下是在config.toml中如何实现的步骤：
1. 打开config.toml文件。
2. 找到volumes部分。
3. 将包含证书的文件夹添加到卷列表中。
下面是一个示例config.toml文件：

[[runners]]
  name = "My Runner"
  url = "https://gitlab.com/"
  token = "xxxxxxxxxx"
  executor = "docker"
  [runners.docker]
    tls_verify = false
    image = "alpine:latest"
    privileged = false
    disable_entrypoint_overwrite = false
    oom_kill_disable = false
    disable_cache = false
    volumes = ["/cache", "/certs/client", "/path/to/cert/folder:/etc/docker/registry.gitlab.yourdomain:5000"]

在上面的示例中，我们将包含证书的文件夹/path/to/cert/folder添加到了卷列表中。这将确保Gitlab Runner中的docker executor和dind服务可以访问到证书。
请注意，这里的路径/etc/docker/registry.gitlab.yourdomain:5000是根据你的实际情况进行修改的。

方案2

使用脚本或工具来管理容器的启动顺序可能会增加复杂性，并且需要确保容器A和容器B之间的依赖关系正确设置。
另一种方法是编写脚本或使用工具来控制容器的运行顺序。你可以使用docker run命令来手动控制容器的启动顺序，或者使用一些第三方工具来管理容器的依赖关系。

示例：

以下是一个简单的bash脚本示例，可以在容器A启动后启动容器B：

#!/bin/bash
# 启动容器A
docker run -d --name container_a your_image_a
# 等待容器A完全启动
while ! docker exec container_a echo "Container A is ready"; do
  sleep 1
done
# 启动容器B
docker run -d --name container_b your_image_b

在这个示例中，我们首先使用docker run命令启动容器A，并将其命名为container_a。然后，使用一个循环来等待容器A完全启动（这里是通过在容器内运行echo命令来测试）。一旦容器A就绪，我们再使用docker run命令启动容器B，并将其命名为container_b。

正文完