dockerfile与gitlab-ci

gitlab的CI/CD

在日常开发过程中难免会因为某些原因需要做gitlab的CI/CD。总的来说这玩意其实并不复杂，如果没有做过这一块，很可能里面的一些东西搞不清楚，导致卡壳很久，浪费时间。经过一些学习，简单了解了其中的一些知识。其实复杂的可能是项目中找不到合适的docker镜像源、Runner机器、变量应该怎么编写等问题，其他的稍微查找下文档资料是可以明白的。

下面用一个简单的例子讲解里面各个点代表的什么意思，首先上一段.gitlab-ci.yml代码

variables: # 自定义一些用到的变量，比如下面这些
    WORKSPACE: $CI_PROJECT_DIR # $CI_PROJECT_DIR: 存放克隆项目的完整路径，作业运行的目录
    IMAGE_ADDRESS: 'xxx/xxx:xxx' # 镜像的目标地址 :后表示tag
    DOCKER_HOST: tcp://docker:2376
    DOCKER_TLS_CERTDIR: "/certs"
    DOCKER_TLS_VERIFY: 1
    DOCKER_CERT_PATH: "$DOCKER_TLS_CERTDIR/client"
    IMAGE_TAG: "${CI_COMMIT_REF_SLUG}_${CI_COMMIT_SHORT_SHA}" # CI_COMMIT_REF_SLUG: CI_COMMIT_REF_NAME的小写形式 CI_COMMIT_SHORT_SHA: 8个字符的提交哈希值
default: # 这是一个全局关键字，可以在全局设置某些关键字的的默认值，如果在job中没有定义该关键字的值，那么就会使用全局设置的默认值
  # 定义在通过新的运行使其冗余时可以取消作业。
  interruptible: true
# 开始执行脚本前所需执行脚本
before_script:
    - xxx
# 脚本执行完后的钩子，执行所需脚本
after_script:
    - rm xxx
stages:
    - build
    - deploy_test_env
# 编译
build:
    stage: build # 场景为构建
    only: # 在哪个分支上可用
        - develop
        - master
    variables:
    # `GIT_STRATEGY` 可以设置的值有：`clone`，`fetch`，和`none`[2]
    GIT_STRATEGY: "fetch"
    services:
        # 依赖的docker服务
        - docker:dind
    image: ${IMAGE_ADDRESS} # 用到了上面定义的变量
    # 指定哪个ci runner跑该工作
    tags:
        - docker
    script: # 所需执行的脚本
        - echo "IMAGE_TAG:$IMAGE_TAG" # 打印日志
        - chmod +x ./build.sh # 给执行权限
        # 当然也可以直接在这里写脚本
        - ./build.sh # 执行脚本文件 build.sh
deploy-k8s:
    stage: deploy_test_env # 场景为deploy_test_env
    rules: # 这段脚本只能满足以下条件时执行
        # 自动运行时执行
        - if : '$CI_PIPELINE_SOURCE != "web" && ($CI_COMMIT_REF_NAME =~ /develop/)'
            variables:
                YMLFILE: "xxx/xxx/values.yaml"
                APP: "xxxx-test"
                TEST_URL: "https://xxx.com"
            when: on_success # when[3]
        - when: never
    extends: .devlop-script # 继承使用某个脚本
.devlop-script:
    stage: deploy_test_env
    image: xxx:xxx
    script:
        - echo "devlop-script"
        - echo "BUNCH:$CI_COMMIT_REF_NAME"
        - echo "IMAGE_TAG:$IMAGE_TAG"
        - echo "APP:$APP"
        # Git
        - cd ..
        - if [ ! -d xxx ]; then
        - git clone --single-branch --branch develop https://xxx/xxx.git
        - else
        - cd xxx
        - git fetch https://gitlab-ci-token:${CI_GLOBAL_TOKEN}@gitlab.xxx.com/xxx/xxx/xxx.git
        - cd -
        - fi
        - cd xxx
        # update image
        - yq -i eval ".global.tag.xxx |= \"${IMAGE_TAG}\"" ${YMLFILE}
        # push
        - git config --global user.email "${CI_GLOBAL_USER}@xxx.com"
        - git config --global user.name ${CI_GLOBAL_USER}
        - git commit -m "xxx:${IMAGE_TAG}"  ${YMLFILE} || echo 1
        - git push || git pull && git push

以下是一些不可被用于任务名的保留字：

关键字	是否必须	描述
image	no	使用的docker镜像
services	no	使用的docker服务
stages	no	定义构建场景
types	no	stages的别名(不建议使用)
before_script	no	定义每个任务的脚本启动前所需执行的命令
after_script	no	定义每个任务的脚本执行结束后所需执行的命令
variables	no	定义构建变量
cache	no	定义哪些文件需要缓存，让后续执行可用

上面使用了 build.sh,当然也可以直接编写脚本

#!/bin/sh

echo "Waiting for docker to be available"
until docker info; do sleep 1; done
echo "Docker is now available"

echo "========== start build script =========="
docker login -u ${DOCKER_USER} -p ${DOCKER_PASSWD}  https://xxx.xxx.com
if [ $? -ne 0 ]; then
    echo "docker login failed!!"
    exit 127
fi
node -v
if [ $CI_COMMIT_REF_NAME == "develop" ]; then
    yarn install
    yarn run build:test
elif [ $CI_COMMIT_REF_NAME == "master" ]; then
    yarn install
    yarn run build:pro
else
    echo "========== branch name is not develop or master, exit build script =========="
    exit 127
    # yarn install
    # yarn run build:test
fi

echo "========== build docker image =========="
image_name="xxx.xxx.com:${IMAGE_TAG}"
docker build -t ${image_name} . # 表示使用dockerfile来构建，注意后面的 '.' 会自动找目录下的dockerfile
docker push ${image_name}

stages默认的5个阶段^[1]

1. .pre
2. build
3. test
4. deploy
5. .post

when一些可能的取值^[4]

1. on_success（默认）：当早期阶段的所有任务都成功运行或者有配置allow_failure: true.时运行当前任务
2. manual：在Gitlab UI中手动触发任务
3. always：无论早期阶段的作业状态如何，都运行作业。也可用于workflow: rules.
4. on_failure：仅当至少一个早期阶段的作业失败时才运行该作业
5. delayed：将作业的执行延迟 指定的持续时间
6. never: 不要运行作业。只能在rules节或中使用workflow: rules

1. stages 这是一个全局关键字，使用stages来定义一个流水线中所包含的各个stage(阶段)。如果stages在脚本中未定义，那么默认的阶段为5个阶段。如果管道中仅包含.pre 或.post阶段中的作业，那就不会运行，在不同的阶段至少有一份其他的job。.pre、.post 可以按需在作业中配置使用，分别是在作业运行之初以及运行结束之后会运行的阶段 ↩
2. GIT_STRATEGY 你可以通过设置GIT_STRATEGY用于获取最新的代码，可以再全局variables或者是在单个job的variables模块中设置。如果没有设置，将从项目中使用默认值 ↩
3. 使用when来配置作业运行的条件。如果未在作业中定义，则默认值为when: on_success ↩
4. when一些可能的取值 ↩