gitlab-runner

CI/CD实际执行器，Saas架构。
支持的客户端有docker、kubernetes、Linux、Windows
https://docs.gitlab.com/runner/install/linux-manually.html
按照说明，一步步操作即可实现安装。

可能遇到的问题

• Docker in Docker

由于gitlab-runner使用的执行器为容器，例如docker或者kubernetes。就可能遇到在Docker容器里面执行Docker命令的问题，即Docker in Docker。Docker官网给出的解决方案：https://hub.docker.com/_/docker/。具体操作见https://docs.gitlab.com/ee/ci/docker/using_docker_build.html。
Runner的配置样例：
样例的gitlab-runner为Linux部署
[runners.docker]
tls_verify = false
image = "docker:19.03.12"
privileged = true
disable_entrypoint_overwrite = false
oom_kill_disable = false
disable_cache = false
volumes = ["/certs/client", "/cache"]
shm_size = 0

• 任务缓存问题

  gitlab的pipeline拥有多个子任务，每个子任务执行完都会产生中间结果数据，可能下一个子任务就需要用到，因此就需要缓存中间结果。官方提供的解决方案：https://docs.gitlab.com/runner/configuration/autoscale.html#distributed-runners-caching。
  安装一个minio：

 docker run -p 9000:9000 -p 9001:9001 --name minio1 -v D:\data:/data -v D:\minio\config:/root/.minio -e "MINIO_ROOT_USER=minio" -e "MINIO_ROOT_PASSWORD=12345678"  minio/minio server /data  --console-address ":9001"

配置一个bucket

image.png

配置一个serviceAccount

image.png

Runner添加cache的配置：
[runners.cache]
Type = "s3"
Path = "node_cache"
[runners.cache.s3]
ServerAddress = "172.20.0.14:9000"
AccessKey = "PBCBXQJIW7LUOT931243"
SecretKey = "fDJag3laL2EiIbwzwC9WtfEOizvBg22NorwsJ+86"
BucketName = "test"
Insecure = true

• Runner执行Kubectl命令

对于使用Kubernetes管理的集群，最后一步都是部署应用到k8s集群，一般都需要执行kubectl命令进行发布。gitlab的解决方案为使用代理。

image.png

简易完整gitlab-ci.yml 样例：

variables:
  # When using dind service, you must instruct Docker to talk with
  # the daemon started inside of the service. The daemon is available
  # with a network connection instead of the default
  # /var/run/docker.sock socket.
  DOCKER_HOST: tcp://docker:2376
  #
  # The 'docker' hostname is the alias of the service container as described at
  # https://docs.gitlab.com/ee/ci/services/#accessing-the-services.
  # If you're using GitLab Runner 12.7 or earlier with the Kubernetes executor and Kubernetes 1.6 or earlier,
  # the variable must be set to tcp://localhost:2376 because of how the
  # Kubernetes executor connects services to the job container
  # DOCKER_HOST: tcp://localhost:2376
  #
  # Specify to Docker where to create the certificates. Docker
  # creates them automatically on boot, and creates
  # `/certs/client` to share between the service and job
  # container, thanks to volume mount from config.toml
  DOCKER_TLS_CERTDIR: "/certs"
  # These are usually specified by the entrypoint, however the
  # Kubernetes executor doesn't run entrypoints
  # https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4125
  DOCKER_TLS_VERIFY: 1
  DOCKER_CERT_PATH: "$DOCKER_TLS_CERTDIR/client"

stages:          # List of stages for jobs, and their order of execution
  - build
  - push
  - deploy

build-job:       # This job runs in the build stage, which runs first.
  stage: build
  image: harbor.lib-mat.ac.cn/library/node-builder:latest
  script:
    - npm config set registry http://registry.npm.taobao.org/
    - npm install
    - npm run build
  cache:
    key: build-cache
    paths:
      - dist/

push-job:   # This job runs in the test stage.
  stage: push
  image: docker:19.03.12
  services:
    - docker:19.03.12-dind
  script:
    - docker login $HARBOR_URL -u $HARBOR_USERNAME -p $HARBOR_PASSWORD
    - docker build -t $CI_PROJECT_NAME:$CI_COMMIT_SHORT_SHA .
    - docker tag $CI_PROJECT_NAME:$CI_COMMIT_SHORT_SHA $HARBOR_URL/apps/$CI_PROJECT_NAME:$CI_COMMIT_SHORT_SHA
    - docker push $HARBOR_URL/apps/$CI_PROJECT_NAME:$CI_COMMIT_SHORT_SHA
  cache:
    key: build-cache
    paths:
      - dist/

deploy-job:      # This job runs in the deploy stage.
  stage: deploy  # It only runs when *both* jobs in the test stage complete successfully.
  image:
    name: bitnami/kubectl:latest
    entrypoint: [ '' ]
  script:
    - kubectl config get-contexts
    - kubectl config use-context root/pipelin-test:gusulab
    - kubectl get pods

即使用工件又使用缓存：

variables:
  # When you use the dind service, you must instruct Docker to talk with
  # the daemon started inside of the service. The daemon is available
  # with a network connection instead of the default
  # /var/run/docker.sock socket. Docker 19.03 does this automatically
  # by setting the DOCKER_HOST in
  # https://github.com/docker-library/docker/blob/d45051476babc297257df490d22cbd806f1b11e4/19.03/docker-entrypoint.sh#L23-L29
  #
  # The 'docker' hostname is the alias of the service container as described at
  # https://docs.gitlab.com/ee/ci/services/#accessing-the-services.
  #
  # Specify to Docker where to create the certificates. Docker
  # creates them automatically on boot, and creates
  # `/certs/client` to share between the service and job
  # container, thanks to volume mount from config.toml
  DOCKER_TLS_CERTDIR: "/certs"
  CI_IMAGE_TAG: ""


stages:          # List of stages for jobs, and their order of execution
  - build
  - push
  - deploy

build-job:       # This job runs in the build stage, which runs first.
  stage: build
  image: harbor.lab/library/node-builder@sha256:30212862eeb3477a6e6823ce13dd697af2e820e75d7cd1411a84a00452e72d07
  script:
    - export
    - npm config set registry http://registry.npm.taobao.org/
    - npm install
    - npm run build
    - echo 'Hello' > a.txt
  tags:
    - docker
  cache:
    key: build-cache
    paths:
      - dist/
  artifacts:
    name: "build-job-artifacts"
    paths:
      - a.txt
build_image:
  stage: push
  image: docker:19.03.12
  services:
      - docker:19.03.12-dind
  tags:
    - docker
  script:
    - ls /cache/cicd/test/node_modules
    - export
    - docker login $HARBOR_URL -u $HARBOR_USERNAME -p $HARBOR_PASSWORD
    - docker build -t test:$CI_COMMIT_SHORT_SHA .
    - docker tag test:$CI_COMMIT_SHORT_SHA $HARBOR_URI/apps/test:$CI_COMMIT_SHORT_SHA
    - docker push $HARBOR_URI/apps/test:$CI_COMMIT_SHORT_SHA
  cache:
    key: build-cache
    paths:
      - dist/
pages:
  stage: deploy
  script:
    - mkdir .public
    - cp -r * .public
    - mv .public public
  artifacts:
    paths:
      - public
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
  tags:
    - docker

下图可以简单观察cache和artifacts的先后关系

image.png

下图是工件上传后的结果：

image.png