.NET DevOps 接入指南 | 7. 使用GitLab流水线构建Docker镜像

引言

如果项目需要通过GitLab CI/CD 流水线实现自动部署到Kubernetes，那么前提就是需要构建Docker镜像，那在流水线中要如何构建镜像呢，取决于负责执行执行Job的GitLab Runner部署在何种环境，如果部署在单独的服务器上，则仅需在服务器上安装Docker，就可以直接使用服务器上的docker命令进行镜像构建。如果部署在容器中，则负责执行Job的runner将运行在容器之中，如果要在容器之中构建Docker镜像，将需要使用Docker命令，那如何在容器之中使用docker命令呢，主要有两种方式：DooD（Docker outside of Docker）和DinD（Docker in Docker）。

DooD是指使用容器所处宿主机的docker命令，主要的途径主要是通过挂载宿主机的/var/run/docker.sock到容器中来实现。目前业界主要有三种通用容器运行时：Docker、CRI-O和Docker，但只有Docker容器运行时提供有docker build命令可直接进行镜像构建。因此使用DooD的前提是，宿主机的容器运行时为Docker。

DinD是指在容器中安装一个全新的Docker来进行镜像构建，由于GitLab部署在Kubernetes上，因此接下来就来具体展开下如何使用该模式进行镜像构建。

使用Helm安装GitLab Runner

将 GitLab Runner 实例部署到 Kubernetes 集群的官方方法是使用gitlab-runnerHelm Chart。其将使用Kubernetes 执行器运行GitLab Runner实例，在接收到流水线的任务后，会在指定的命名空间创建一个新的Pod运行任务。安装步骤如下：

1. 添加GitLab Helm 仓库

为了使用Helm安装GitLab，首先就需要添加官方gitlab chart，参考以下命令进行添加：

打开命令行，执行helm repo add gitlab https://charts.gitlab.io。

      
      shengjie@Thinkpad:~$ helm version # 查看本地helm版本
version.BuildInfo{Version:"v3.7.1", GitCommit:"1d11fcb5d3f3bf00dbe6fe31b8412839a96b3dc4", GitTreeState:"clean", GoVersion:"go1.16.9
shengjie@Thinkpad:~$ helm repo add gitlab https://charts.gitlab.io # 添加gitlab helm 仓库
"gitlab" has been added to your repositories
shengjie@Thinkpad:~$ helm search repo gitlab/gitlab-runner
NAME                    CHART VERSION   APP VERSION     DESCRIPTION
gitlab/gitlab-runner    0.32.0          14.2.0          GitLab Runner

2. 下载GitLab Helm Chart

为了方便根据需要配置Helm Chart，可以先将特定版本的GitLab Runner Helm Chart 下载至本地进行修改，下载命令仅需执行以下命令：

      
      shengjie@Thinkpad:~$ mkdir cloud-native # 创建目录
shengjie@Thinkpad:~$ cd cloud-native 
shengjie@Thinkpad:~/cloud-native$ helm pull gitlab/gitlab-runner --version 0.32.0 --untar # 下载指定版本的gitlab-runner chart
shengjie@Thinkpad:~/cloud-native$ cd gitlab-runner; ls
CHANGELOG.md  CONTRIBUTING.md  Chart.yaml  LICENSE  Makefile  NOTICE  README.md  templates  values.yaml
shengjie@Thinkpad:~/cloud-native/gitlab-runner$ cp values.yaml dind-values.yaml # 复制一份配置，在此基础上进行配置

3. 配置GitLab Runner

要在 Kubernetes 中启用 TLS 的情况下使用 DinD，需要找到复制的dind-values.yaml配置文件下的runners:config节点，修改配置如下：

      
      runners:
  config: |  
    [[runners]]
      [runners.kubernetes]
        namespace = "{{.Release.Namespace}}"
        image = "ubuntu:20.04"
        privileged = true
      [[runners.kubernetes.volumes.empty_dir]]
        name = "docker-certs"
        mount_path = "/certs/client"
        medium = "Memory"

由于要在由于后续要配合使用MinIO进行分布式缓存，有两种配置方式：第一种就是继续修改runners:config节点，添加[runners.cache]配置，配置如下。这里需要额外说明的是，其中AccessKey和SecretKey可以通过gitlab-minio-secret中获取。

      
      runners:
  config: |  
    [[runners]]
      [runners.kubernetes]
        namespace = "{{.Release.Namespace}}"
        image = "ubuntu:20.04"
        privileged = true
      [[runners.kubernetes.volumes.empty_dir]]
        name = "docker-certs"
        mount_path = "/certs/client"
        medium = "Memory"
      [runners.cache]
        Type = "s3" # 指定缓存类型为s3
        Shared = true 
        Path = "gitlab-runner" # 指定缓存路径
        [runners.cache.s3]
          ServerAddress = "minio.shengjie.dev" # 指定MinIO地址
          AccessKey = "A4ZBHe0YNiZi0Ewu1W4dsY56aJGeUFTQpg" # 指定AccessKey
          SecretKey = "2P5jn5LoT7Z5OKUA0VQdsZezZg4IJ49fU" # 指定SecretKey
          BucketName = "runner-cache" # 指定MinIO Bucket

另外一种是配置runners:cache节点，配置如下。从配置中可以看到配置项已经被标记为DEPRECATED(已过时)，因此不建议使用该方式配置，但就目前使用的版本0.32.0，使用该方式仍旧可以生效。

      
      runners:
 ## 省略其他配置
 cache:
    ## General settings
    ## DEPRECATED
    cacheType: s3
    cachePath: "gitlab-runner"
    cacheShared: true
    ## S3 settings
    ## DEPRECATED
    s3ServerAddress: minio.shengjie.dev
    s3BucketName: runner-cache
    ## S3 the name of the secret.
    secretName: gitlab-minio-secret

为了快速注册，还需要修改gitlabUrl、runnerRegistrationToken和rbac.create配置，参考配置如下所示：

      
      gitlabUrl: https://gitlab.shengjie.dev/  # gitlab 地址，注意替换为自己的地址
runnerRegistrationToken: "np4P4dnfmeyDIWZBZnfcoLtNPMxxxxx" # 注册凭证
rbac:
 create: true

其中gitlabUrl和runnerRegistrationToken可以通过菜单->管理员->Runner获取，如下图所示：

3. 安装GitLab-Runner Helm Chart

完成以上配置后，就可以使用dind-values.yaml配置文件进行安装，执行以下命令即可安装：

      
      shengjie@Thinkpad:~/cloud-native/gitlab-runner$ helm install dind-runner . -f dind-values.yaml -n gitlab
NAME: dind-runner
LAST DEPLOYED: Tue Oct 26 01:08:42 2021
NAMESPACE: gitlab
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Your GitLab Runner should now be registered against the GitLab instance reachable at: "https://gitlab.shengjie.dev/"

安装后，依次点击菜单->管理员->Runner，即可看到类似以下的GitLab Runner 列表，如果出现以dind-runner开头的Runner即说明安装并注册成功。

4. 设置GitLab Runner标签

对于需要构建镜像的Job来说，很显然要调度到刚刚注册的runner里，否则无法进行镜像构建。那如何做呢？可以通过两种手段：第一种通过限制适用于该Runner的项目；另一种就是设置标签，比如将刚刚创建的Runner标签设置为docker，然后在流水线中通过tags标签指定即可。具体配置界面如下图所示：

集成 GitLab Registry

镜像构建的环境准备好了，接下来还得考虑一个问题，那就是构建好的镜像放在哪里？很显然要上传到镜像仓库，GitLab基于MinIO提供了镜像仓库功能，因此可以直接上传到GitLab Registry。但上传GitLab Registry需要访问凭证，这个凭证需要提前做好配置。配置方法也很简单，那就是为项目创建名为gitlab-deploy-token的部署令牌即可，具体创建步骤如下图所示，其中注意的是名称必须是gitlab-deploy-token，且范围必须勾选read_package_registry和write_package_registry。

创建成功后，即可在Job中通过docker login -u $CI_DEPLOY_USER -p $CI_DEPLOY_PASSWORD $CI_REGISTRY 登录到指定的镜像仓库。

配置镜像构建Job

完成了准备工作，接下来回到流水线编辑器来创建镜像构建Job。对于ASP.NET Core的镜像构建需要两部，首先使用dotnet publish发布，然后再就发布内容打包为镜像。由于镜像构建阶段主要是进行打包，因此可以和之前publish-job做好配合，通过下载publish-job的artifact，然后再进行构建。下面添加一个build-docker-job，如下所示：

      
      variables:
    IMAGE_TAG: $CI_REGISTRY_IMAGE/$CI_PROJECT_PATH_SLUG:$CI_COMMIT_SHORT_SHA # 定义全局标签，方便后续复用
    
build-docker-job:
    image: docker:19.03.13
    variables:
        DOCKER_HOST: tcp://docker:2376
        DOCKER_TLS_CERTDIR: "/certs"
        DOCKER_TLS_VERIFY: 1
        DOCKER_CERT_PATH: "$DOCKER_TLS_CERTDIR/client"
    services:
        - docker:19.03.13-dind
    tags:
        - docker
    stage: deploy
    cache: [] # 禁用缓存，因仅需要从artifacts中获取发布目录
    before_script:      
        - ls
        - until docker info; do sleep 1; done # 确保docker正常启动
        - docker login -u $CI_DEPLOY_USER -p $CI_DEPLOY_PASSWORD $CI_REGISTRY   # 登录docker 
        - image_tag = $CI_REGISTRY_IMAGE/$CI_PROJECT_PATH_SLUG:$CI_COMMIT_SHORT_SHA # 定以标签
        - echo $IMAGE_TAG
    script:
        - cd publish
        - docker build -f ../AspNetCore.CiCd.Web/Dockerfile -t $IMAGE_TAG .
        - echo 'build succeed'
        - docker push $IMAGE_TAG
        - docker image rm $IMAGE_TAG
    needs:
     - build-job #通过needs限定当前Job只有build-job执行后才可执行
    when: on_success

在开始之前，还需要注意一点是要创建Dockerfile，由于只需要发布Web项目，因此可直接打开解决方案下Asp.NetCore.CiCd.Web文件夹，为该项目创建Dockerfile即可，Dockerfile内容如下。在GitLab中打开内容下图所示。

      
      FROM mcr.microsoft.com/dotnet/aspnet:5.0
EXPOSE 80
EXPOSE 443
COPY . .
ENTRYPOINT ["dotnet", "AspNetCore.CiCd.Demo.dll"]

完毕之后，就可以提交流水线。提交流水线稍等片刻，会发现流水线运行状况如下图所示：

其中publish-job由于指定when: manual，需要手动触发执行，而build-docker-job由于指定needs为publish-job，因此只有publish-job执行后才会执行。手动触发后，即可进行镜像构建。流水线执行成功后，可以通过路径：软件包与镜像库->容器镜像库，查看已构建的镜像，如下图所示：

这里有几点需要注意：

publish-job中产生的artifact会自动在同一流水线中的后续Job中共享，会自动下载恢复到代码目录。可以通过查看docker-build-job的日志确认，会有类似以下的输出：

      
      Getting source from Git repository
00:01
Fetching changes with git depth set to 50...
Initialized empty Git repository in /builds/vE-o9qLi/0/demos/aspnetcore.cicd.demo/.git/
Created fresh repository.
Checking out 7a824deb as develop...
Skipping Git submodules setup
Downloading artifacts
00:00
Downloading artifacts for publish-job (401)...
Downloading artifacts from coordinator... ok        id=401 responseStatus=200 OK token=gcfdxUkT
$ ls
AspNetCore.CiCd.Demo.sln
AspNetCore.CiCd.Web
AspNetCore.CiCd.Web.Tests
README.md
publish

镜像标签要遵守特定格式，才能推送到项目路径。格式为：{register-address}/{namespace}/{projectname}:{tag}。Job中定义的image_tag = $CI_REGISTRY_IMAGE/$CI_PROJECT_PATH_SLUG:$CI_COMMIT_SHORT_SHA就是通过GitLab预置的环境变量来组装镜像完整名称的，本例中，产生的镜像名称为：registry.shengjie.dev/demos/aspnetcore.cicd.demo/demos-aspnetcore-cicd-demo:7a824deb。那如何知道预置的环境变量的值是什么呢？简单可以通过加个export的命令到Job中的before_script中，通过查看执行日志即可获取预置的环境变量及对应值。

至此，完成了镜像的构建和推送工作，下一节来学一学如何发布到Kubernetes。