GitLab CI登录到没有DinD的私有回购

Question

我是GitLab的新手，不知道这是否可能，我已经在前提下建立和工作了GitLab，以及Artifactory私有回购。

我总是使用DinD配置，使用Docker作为DinD服务的主要映像，然后在登录和从私有回购中提取不同映像的阶段。

但是我听说在没有DinD的情况下可以缩短执行时间。所需的图像在舞台开始时就会被拉出来。

而不是这样：

image: docker:latest

services:
  - docker:18.09.8-dind

variables:
  DOCKER_DRIVER: overlay2
  DOCKER_HOST: tcp://localhost:2375 

stages:
  - run_script

run_script:
  stage:
    run_script
  script:
    - docker login -u $DOCKER_TECHNICAL_USER -p $DOCKER_TECHNICAL_USER_PASSWORD $DOCKER_REGISTRY_URL
    - docker pull artifactory.example.com:5000/repo/powershell-core:6.3
    - docker run -it artifactory.example.com:5000/repo/powershell-core:6.3 pwsh -command "get-process"

我想这样做(整个yml)：

stages:
  - run_script

run_script:
  before_script:
    - docker login -u $DOCKER_TECHNICAL_USER -p $DOCKER_TECHNICAL_USER_PASSWORD $DOCKER_REGISTRY_URL
  image: artifactory.example.com:5000/repo/powershell-core:6.3
  stage:
    run_script
  script:
    - pwsh -command "get-process"

如果我尝试这样做，它会说它无法验证：

ERROR: Job failed: image pull failed: rpc error: code = Unknown desc = Get https://artifactory.example.com:5000/v2/repo/powershell-core/manifests/6.3: unknown: Authentication is required

这是不可能的，还是我在某个地方犯了一个错误，而且它是可以修复的？

Answer 1

你的问题

您的CI失败了，因为它在下载基本映像artifactory.example.com时不知道artifactory.example.com:5000/repo/powershell-core:6.3的凭据。为了让你理解，我将解释你给出的两个顺流子的不同步骤，然后我会给出一个解决方案的轨道。

第一CI (DinD)

在您的第一个CI (使用DinD的CI)中，所发生的情况是：

• Gitlab-runner下载映像docker:18.09.8-dind，然后将映像作为您的CI服务启动。
• Gitlab执行器下载base映像 docker:latest，然后使用它执行作业run_script。
• 在您的停靠库docker:latest中，作业run_script日志使用您的凭据并通过DinD服务在您的私有存储库中进行记录。
• 然后下载映像artifactory.example.com:5000/repo/powershell-core:6.3并使用它运行脚本，全部通过DinD服务运行。

第二次CI

在这个例子中，您只是尝试执行映像artifactory.example.com:5000/repo/powershell-core:6.3并使用它运行一个脚本。您是对的，因为这样一个简单的目标是不需要DinD的。以下是对您的CI所做工作的分析：

• Gitlab执行器尝试下载作业 run_script：artifactory.example.com:5000/repo/powershell-core:6.3指定的基本映像。
• 存储库artifactory.example.com请求凭据
• 执行器不知道任何凭据，因此它返回一个错误并停止

如您所见，在本例中，作业run_script从未执行，因为执行程序未能下载作业指定的基本映像。作业中负责登录的before_script部分也不会执行，因为是在基本映像中执行的，而执行程序无法下载最后一个。

因此，解决方案只是将凭据交给执行者，以便它可以登录，然后下载作业的基本映像。另外，您的作业的before_script部分应该被移除，因为它不是在您想要的时候执行的，因此没有必要。

解决方案

因此，您需要的是一种将存储库artifactory.example.com的凭据交给您的工作所使用的Gilab-runner执行者的方法。可悲的是，没有一种独特的方法来做这样的事情，因为它取决于您正在使用的执行者。由于您在问题中没有指定执行者，我将给出解决方案，我认为，对于Docker和Kubernetes来说，这是最常用和最方便的解决方案。

使用DOCKER_AUTH_CONFIG

一个与多个执行器一起工作的解决方案是在Gitlab中直接定义一个(秘密)变量，正如这个Gitlab文档中所解释的那样。

在这里，我介绍第二种方法来准备您的凭据。修改以下内容以生成您自己的auth：

echo -n "USERNAME:PASSWORD" | base64
VVNFUk5BTUU6UEFTU1dPUkQ=

然后在Gitlab中创建一个变量DOCKER_AUTH_CONFIG，其内容如下：

{
  "auths": {
    "artifactory.example.com:5000": {
      "auth": "VVNFUk5BTUU6UEFTU1dPUkQ="
    }
  }
}

使用此方法，您的CI只会变成：

stages:
  - run_script

run_script:
  image: artifactory.example.com:5000/repo/powershell-core:6.3
  stage:
    run_script
  script:
    - pwsh -command "get-process"

此解决方案在大多数情况下都有效。但是，根据您的执行器和您对它的访问权限，您可能需要使用其他特定的解决方案。

库伯奈特遗嘱执行人

如果使用Kubernetes executor，最简单的解决方案是创建包含存储库凭据的秘密。使用runner的Helm图表，这个秘密可以在安装图表的过程中使用在runners.imagePullSecrets中描述的图表的values.yaml键给出。该解决方案使用Kubernetes的机制对注册表进行身份验证，如Kubernetes文件中所解释的那样。

我给出这个示例来说明这样一个事实，即运行者对注册表的身份验证使用的是独立于运行程序本身的机制。在这种情况下，这是Kubernetes的机制。因此，对于跑步者来说，没有唯一的认证方法。

Answer 2

@Bichon谢谢您的精彩回复。这里还有另一种情况，在您的k8s cluster.In中使用kubernetes执行器和dind --我的dind服务工作得很好--当我通过exec向pod.But证明它时，我的运行程序(带有“docker:cluster.In”映像的k8s执行器)仍然出错，尽管我已经配置了DOCKER_HOST，并使客户机指针指向dind。

我搜索了很多地方，他们并没有提到这个案例，我只是在我的跑步者脚本中重新登录来解决这个问题：https://forum.gitlab.com/t/insecure-docker-registry-kubernetes-runner/51271/2?u=lzd-1230

虽然我用无数的特灵解决了这个问题，但我仍然对此感到困惑.因为我认为这是不必要的，因为服务器在dind中，而且配置也很好！！