基于GitLab的CICD流程是怎样的

发布时间：2021-10-19 18:36:19 作者：柒染
来源：亿速云阅读：156

基于GitLab的CICD流程是怎样的，针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。

最近想把公司基于Jenkins的自动化构建修改到GitLab上，主要原因是在Jenkins上没有做权限控制，大家使用同一个账号，造成不同项目组的源码泄漏问题；另外还有一个使用Jenkins的独立服务器，感觉还是资源浪费了点。

配置GitLab的runner

从gitlab上获取Runner注册的token。有三种方式

按项目
项目->设置->CI/CD->Runner
按分组
分组->设置->CI/CD->Runner
全局
管理中心->概览->Runner

运行Runner

从gitee上下载对应的的helm包，地址
修改values文件的gitlabUrl、runnerRegistrationToken、tags
执行以下命令

helm package .
helm install --namespace gitlab --name gitlab-runner *.tgz

说明：

gitlabUrl 就是你gitlab私服地址
runnerRegistrationToken 就是从第1步获取的runner注册的token值
tags 标识这个runner，stage的job就是根据该tag选择对应的runner的
Chart.yaml定义该helm的基本信息，注意里面的name字段必须和当前目录的名称一致
templates/pvc.yaml 定义了一个Dynamic Provisioning的PVC，使用的storageClassName是阿里云的alicloud-disk-efficiency(我们的k8s是阿里云的容器服务)，它会自动创建对应的PV，并创建一个云盘实例。这个可以用来处理多个Job之间的缓存文件
templates/configmap.yaml文件的runners.kubernetes.volumes.pvc定义了PVC的名称，即上一步定义的PVC名称，如果有修改注意同步

至此，一个gitlab-runner应该就可以注册到对应的gitlab server上去了。

配置环境变量

对于在构建过程使用到比较私密的信息，应该直接配置到gitlab server的环境变量上，这里我们主要配置一下三个参数：

REGISTRY_PASSWORD Harbor私服的密码
REGISTRY_USERNAME Harbor私服的用户名
KUBE_CONFIG kubectl执行所需的账号、证书等信息，该字符串可以使用以下命令获取

echo $(cat ~/.kube/config | base64) | tr -d " "

这里的环境变量是配置在group下的CI/CD页面的环境变量

对于以下容器的配置为了纯手工配置，更好的方式应该是使用Dockerfile进行编写。这里只是为了更好的说明基础镜像的制作过程。

配置Node容器

Node容器主要用于编译前端项目，一般主要使用yarn下载依赖，npm编译打包。所以Node容器需要包含这两个命令。

$ docker pull node //拉取最新的node镜像
$ docker run -it --rm --name node node /bin/sh //运行node镜像，并且进入
$ yarn config set registry https://registry.npm.taobao.org //配置yarn的源为淘宝源
$ yarn config list //查看配置
--------------------------------
info yarn config
{
  'version-tag-prefix': 'v',
  'version-git-tag': true,
  'version-commit-hooks': true,
  'version-git-sign': false,
  'version-git-message': 'v%s',
  'init-version': '1.0.0',
  'init-license': 'MIT',
  'save-prefix': '^',
  'bin-links': true,
  'ignore-scripts': false,
  'ignore-optional': false,
  registry: 'https://registry.yarnpkg.com',
  'strict-ssl': true,
  'user-agent': 'yarn/1.16.0 npm/? node/v12.5.0 linux x64',
  version: '1.16.0'
}
info npm config
{
  version: '1.16.0'
}
Done in 0.07s.
--------------------------------
$ docker commit node harbor_url/tools/node-taobao //另外打开一个窗口，提交修改后的node镜像
$ docker push harbor_url/tools/node-taobao //推送镜像到Harbor私服

配置Java容器

Java容器主要用于编译Java项目，主要用到JDK和MAVEN

$ docker pull alpine // 拉取最新的alpine镜像
$ docker run -it --rm --name java alpine //进入镜像
$ mkdir -p /opt/java // 创建java目录
$ mkdir -p /opt/maven //创建maven目录
$ docker cp jdk-8u211-linux-x64.tar.gz java:/opt/java/    //从主机上拷贝JDK到容器内部 
$ docker cp apache-maven-3.6.1-bin.tar.gz java:/opt/maven/   //从主机上拷贝MAVEN到容器内部
/opt/maven $ tar -xzvf apache-maven-3.6.1-bin.tar.gz  //在容器内解压MAVEN
/opt/maven $ rm -rf apache-maven-3.6.1-bin.tar.gz     //删除MAVEN压缩包
/opt/java $ tar -xzvf jdk-8u211-linux-x64.tar.gz      //在容器内解压JDK
/opt/java $ rm -rf jdk-8u211-linux-x64.tar.gz         //删除JDK压缩包
$ vi /etc/profile	//配置环境变量
--------------------------------
export JAVA_HOME=/opt/java/jdk1.8.0_211
export M2_HOME=/opt/maven/apache-maven-3.6.1
export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:$JAVA_HOME/bin:$M2_HOME/bin
--------------------------------
//Java是基于GUN Standard C library(glibc),Alpine是基于MUSL libc(mini libc),所以需要安装glibc库
// 参考地址：https://blog.csdn.net/Dannyvon/article/details/80092834
$ echo http://mirrors.ustc.edu.cn/alpine/v3.10/main > /etc/apk/repositories
$ echo http://mirrors.ustc.edu.cn/alpine/v3.10/community >> /etc/apk/repositories
$ apk update
$ apk --no-cache add ca-certificates
$ wget https://github.com/sgerrand/alpine-pkg-glibc/releases/download/2.27-r0/glibc-2.27-r0.apk
$ wget -q -O /etc/apk/keys/sgerrand.rsa.pub https://alpine-pkgs.sgerrand.com/sgerrand.rsa.pub
$ apk add glibc-2.27-r0.apk  // 至此glibc库安装完毕
$ source /etc/profile  //生效环境变量
$ java -version  //查看JAVA版本
--------------------------------
java version "1.8.0_211"
Java(TM) SE Runtime Environment (build 1.8.0_211-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.211-b12, mixed mode)
--------------------------------
$ mvn -v  //查看MAVEN版本
--------------------------------
Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555; 2019-04-04T19:00:29Z)
Maven home: /opt/maven/apache-maven-3.6.1
Java version: 1.8.0_211, vendor: Oracle Corporation, runtime: /opt/java/jdk1.8.0_211/jre
Default locale: en_US, platform encoding: ANSI_X3.4-1968
OS name: "linux", version: "4.9.125-linuxkit", arch: "amd64", family: "unix"
--------------------------------
$ docker commit java harbor_url/tools/java:1.8  //在另外一个窗口，提交镜像
$ docker push harbor_url/tools/java:1.8   //将镜像推送到Harbor私服

注意source /etc/profile这个命令只是当前有效，在提交镜像后，使用镜像重新运行容器还需要在执行一次该命令。具体如何永久生效，还不知道。如果大佬知道可以告知下。

配置Curl&Git容器

该容器只是适应我们公司的状况，我们公司的前端打包其实并不需要Node容器。前端打包过程是在本地打包编译后生成dist目录下的文件，然后压缩上传到内网的oss上。接着在Jenkins上执行脚本，其实是从内网的oss下载并解压，然后根据Dockerfile在制作业务镜像。这个过程就需要使用到Curl和Git命令。整个过程是为了解决线上打包环境可能跟开发本地不一致，以及前端打包需要下载依赖和编译耗时的问题，通过这样的一个流程，前端每次构建的时间就非常短，几秒钟就能搞定。

$ docker run -it --rm --name curl-git alpine
$ echo http://mirrors.ustc.edu.cn/alpine/v3.10/main > /etc/apk/repositories
$ echo http://mirrors.ustc.edu.cn/alpine/v3.10/community >> /etc/apk/repositories
$ apk update
$ apk add curl
$ apk add git
$ curl -V
--------------------------------
curl 7.61.1 (x86_64-alpine-linux-musl) libcurl/7.61.1 LibreSSL/2.6.5 zlib/1.2.11 libssh3/1.8.2
Release-Date: 2018-09-05
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IPv6 Largefile NTLM NTLM_WB SSL libz UnixSockets HTTPS-proxy
--------------------------------
$ git version
--------------------------------
git version 2.15.3
--------------------------------
$ docker commit curl-git harbor_url/tools/curl-git  //在另外一个窗口，提交镜像
$ docker push harbor_url/tools/curl-git   //将镜像推送到Harbor私服

配置kubectl容器

kubectl容器是用于部署应用到k8s集群，需要用到config的配置信息。但是这个信息一般比较私密，不会直接打到容器里面，容器里面只会放一个kubectl客户端，然后具体的配置文件在运行期间在放到~/.kube/config文件内。

$ docker run -it --rm --name kubectl alpine  //运行并且进入容器
$ docker cp kubectl kubectl:/usr/bin/  //拷贝kubectl客户端到容器内部，kubectl客户端可以直接在k8s的master节点找到，或者直接在github上下载到对应版本的客户端
$ chmod +x /usr/bin/kubectl //设置为可执行文件
$ kubectl version //查看版本，因为没有配置服务的证书，所以服务端的信息打印不出来
--------------------------------
Client Version: version.Info{Major:"1", Minor:"12+", GitVersion:"v1.12.6-aliyun.1", GitCommit:"4304b26", GitTreeState:"", BuildDate:"2019-04-08T08:50:29Z", GoVersion:"go1.10.8", Compiler:"gc", Platform:"linux/amd64"}
The connection to the server localhost:8080 was refused - did you specify the right host or port?
--------------------------------
$ docker commit kubectl harbor_url/tools/kubectl:1.12.6  //在另外一个窗口，提交镜像
$ docker push  harbor_url/tools/kubectl:1.12.6   //将镜像推送到Harbor私服

配置.gitlab-ci.yml

# 如果各个stage没有使用镜像，则使用默认镜像
image: $HARBOR_URL/tools/alpine
stages:
  - build
  - deploy
# 全局变量定义
variables:
  # 镜像名，tag默认使用pipeline_id
  IMAGE_NAME: <harbor_url>/<image_path>/<image_name>
  # 定义应用名称，即deployment_name、container_name、service_name等
  APP_NAME: <application_name>
  # 应用端口，一般应用端口和service的端口一致
  APP_PORT: 80
  # 定义命名空间，需要根据不同的打包命令替换为真实命名空间
  NAMESPACE: dev
  # HARBOR_URL
  HARBOR_URL: <harbor_url>
docker_build_job:
  # 包含curl 和 git 工具的镜像
  image: $HARBOR_URL/tools/curl-git
  stage: build
  # 定义只有dev分支push或者merge事件触发Job
  only:
    refs:
      - dev
  tags:
    - <runner_tag>
  # 使用dind模式，连接到一个有启动docker的容器
  services:
    - $HARBOR_URL/tools/docker-dind:18.09.7
  variables:
    # docker daemon 启动的参数
    DOCKER_DRIVER: overlay
    DOCKER_HOST: tcp://localhost:2375
  # 该 stage 执行的脚本命令
  # 1. 执行构建脚本build.sh
  # 2. 登录Harbor私服
  # 3. 根据Dockerfile构建image
  # 4. push image 到Harbor
  script:
  	# build.sh脚本为公司内部脚本，根据后面的参数配置不同的环境
    # 主要流程是下载开发打包好的压缩文件，然后解压，接着根据不同环境替换变量
    - sh ./build.sh -b development
    - docker login -u $REGISTRY_USERNAME -p $REGISTRY_PASSWORD $HARBOR_URL
    - docker build -t $IMAGE_NAME:$CI_PIPELINE_ID .
    - docker push $IMAGE_NAME:$CI_PIPELINE_ID
k8s_deploy_job:
  # 包含kubectl 工具的镜像
  image: $HARBOR_URL/tools/kubectl:1.12.6
  stage: deploy
  only:
    refs:
      - dev
  tags:
    - <runner_tag>
  # 该 stage 执行的脚本命令
  # 1. 创建/etc/deploy/config文件
  # 2. 将k8s的证书信息写入/etc/deploy/config
  # 3. 替换deployment.yaml文件中的各个变量
  # 4. 部署到k8s集群环境中
  script:
    - mkdir -p ~/.kube
    - touch ~/.kube/config
    # KUBE_CONFIG这个环境变量是在gitlab server中配置的
    - echo $KUBE_CONFIG | base64 -d > ~/.kube/config
    # 对deployment.yaml进行对应的变量替换
    - sed -i "s?IMAGE_TAG?$CI_PIPELINE_ID?g" deployment.yaml
    - sed -i "s?IMAGE_NAME?$IMAGE_NAME?g" deployment.yaml
    - sed -i "s?APP_NAME?$APP_NAME?g" deployment.yaml
    - sed -i "s?NAMESPACE?$NAMESPACE?g" deployment.yaml
    - sed -i "s?APP_PORT?$APP_PORT?g" deployment.yaml
    - kubectl apply -f deployment.yaml

这个.gitlab-ci.yml文件少了基于node和java镜像的配置。不过都是大同小异，就不在复述。对于node镜像打包后一般会生成dist目录，这个时候可以加个步骤把dist目录压缩，然后定义artifacts，这样当前的stage执行完后就会上传该压缩包到gitlab-server。接着下一个stage就会自动下载这个压缩包，这样我们就可以解压这个压缩包，然后再根据Dockerfile进行打包了，同样是使用dind的模式。对于java镜像同样可以使用这个原理，mvn编译打包出一个jar包或者war包，然后传递到下一个stage，再进行构建镜像；不过如果使用maven的docker插件的话，那就不用分两个stage了，直接在java的那个镜像加个services的定义，这样就可以使用mvn docker:build docker:push命令了。不过要注意，使用maven的docker插件，镜像是定义在pom.xml文件的，这个需要和外部的.gitlab-ci.yml文件定义的镜像名称同步

node镜像部分定义

node_build_job:
  image: $HARBOR_URL/tools/node-taobao
  stage: package
  only:
    refs:
      - dev
  tags:
    - <runner_tag>
  script:
  	# 下载依赖
    - yarn
    # 编译打包
    - npm run build --qa
    # 压缩dist目录
    - tar -czvf dist.tar.gz dist/
  # 定义artifacts，会上传到gitlab-server
  artifacts:
    paths:
    - dist.tar.gz

java镜像部分定义

java_build_job:
  image: $HARBOR_URL/tools/java:1.8
  stage: package
  only:
    refs:
      - dev
  # services定义，使用dind模式，其实就是通过link指令把docker容器链接到java镜像，使得java镜像可以使用docker命令
  services:
    - $HARBOR_URL/tools/docker-dind:18.09.7
  variables:
    DOCKER_DRIVER: overlay
    DOCKER_HOST: tcp://localhost:2375
  tags:
    - <runner_tag>
  script:
    # 重新使得JAVA_HOME、M2_HOME环境变量生效
    - source /etc/profile
    - mvn -P$NAMESPACE clean package
    - cd <module_dir>
    - mvn -P$NAMESPACE docker:build docker:push

配置deployment.yaml

deployment.yaml文件中包含2部分，k8s的deployment对象和service对象。

apiVersion: apps/v1beta2
kind: Deployment
metadata:
  labels:
    app: APP_NAME
  name: APP_NAME
  namespace: NAMESPACE
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: APP_NAME
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: APP_NAME
    spec:
      affinity: {}
      containers:
        - image: 'IMAGE_NAME:IMAGE_TAG'
          imagePullPolicy: Always
          name: APP_NAME
          # 前端项目，使用的是nginx基础镜像，一般使用内存都比较低
          resources:
            limits:
              cpu: '1'
              memory: 64Mi
            requests:
              cpu: '0'
              memory: 32Mi
          terminationMessagePath: /dev/termination-log
          terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30

---

apiVersion: v1
kind: Service
metadata:
  name: APP_NAME
  namespace: NAMESPACE
spec:
  ports:
    - port: APP_PORT
      protocol: TCP
      targetPort: APP_PORT
  selector:
    app: APP_NAME
  sessionAffinity: None
  type: ClusterIP

结束

至此，一个完整的基于gitlab的CICD流程可以跑起来了。因为是配合k8s运行的，在整个搭建的过程还是坎坷。例如使用javaj镜像但是需要运行docker命令，services那块的定义如果不去看文档就稀里糊涂的；然后前端的yarn和mvn install等命令都会涉及到从公网下载依赖包，这些依赖包如何缓存才能使得下一次构建可以直接使用，这个就涉及到k8s的PV和PVC的相关概念和使用。

另外，对于.gitlab-ci.yml的变量还是有写死的内容，例如namespace，还需要另外一个脚本根据打包命令来替换对应的变量。还有待优化。

这个整套流程跑下来，感觉又学到了一些东西。

关于基于GitLab的CICD流程是怎样的问题的解答就分享到这里了，希望以上内容可以对大家有一定的帮助，如果你还有很多疑惑没有解开，可以关注亿速云行业资讯频道了解更多相关知识。