docker - 如何在不导致缓存未命中的情况下将 gitlab 作业 token 传递到 docker 构建中？

Question

我们正在使用 gitlab 部署中内置的 PyPI 存储库与多个内部项目共享我们的内部包。当我们构建我们的 docker 镜像时，我们需要安装这些包作为镜像创建的一部分。然而 gitlab CI token我们用来访问 gitlab PyPI 存储库的 token 是一次性 token ，因此每次运行构建时都是不同的。

我们的 Dockerfile 开始是这样的:

FROM python:3.9

WORKDIR /project

COPY poetry.lock pyproject.toml
RUN pip install poetry

ARG CI_JOB_TOKEN
RUN poetry config http-basic.gitlab-pypi-repo gitlab-ci-token ${CI_JOB_TOKEN}
RUN poetry install --no-interaction

现在因为我们正在使用 poetry 并且版本被锁定在 poetry.lock 中，当我们到达 poetry 步骤时我们不需要重新安装 poetry 除非 poetry.lock 文件已更改，但由于 CI_JOB_TOKEN 始终不同，我们总是会错过缓存，并且不得不重建诗歌和下游的所有内容(这实际上是大部分工作所在的位置)。

那么有没有一种方法可以将 CI_JOB_TOKEN 传递到 docker build 中，但是为了缓存的目的而忽略的方式？或者也许有另一种方法可以实现这一目标？

Answer 1

使用build secrets相反(需要构建套件)

您可以在构建时使用--mount 参数到RUN 指令来装载 secret 。假设您在 dockerfile 中有以下内容:

# ...
RUN --mount=type=secret,id=mysecret echo "$(cat /run/secrets/mysecret)" > .foo
RUN echo "another layer" > .bar

然后您可以使用 --secret 标志将 secret 传递到构建中。

在第一次运行时，你会看到 RUN 指令被执行，如果你要检查 .foo 文件，它会包含 secret (因为我们回应了它到 RUN 命令中的文件——实际上，例如，这可能是您的诗歌配置)。

$ echo -n supersecret > ../secret.txt
$ docker build --secret id=mysecret,src=../secret.txt -t test .
# ...
 => [3/4] RUN --mount=type=secret,id=mysecret echo "$(cat /run/secrets/mysecret)" > .foo                                                0.2s
 => [4/4] RUN echo "another layer" > .bar                                                                                                         0.4s
# ...

即使您的 secret 发生变化，在后续运行中，您也会看到相关层仍保持缓存状态:

$ echo -n newvalue > ../secret.txt
$ docker build --secret id=mysecret,src=../secret.txt -t test .
# ...
 => CACHED [3/4] RUN --mount=type=secret,id=mysecret echo "$(cat /run/secrets/mysecret)" > .foo                                         0.0s
 => CACHED [4/4] RUN echo "another layer" > .bar                                                                                                  0.0s
# ...

当然，因为 RUN 指令被缓存，您会在生成的构建中的 .foo 中看到旧的 secret 值。

---

作为单独的注释，您应该知道您的poetry config 命令正在写入磁盘。这意味着您的 secret 将包含在生成的图像层中，从安全角度来看，这可能并不理想。