前言

在综合各方面的考量后，最终笔者选择使用 Coding + 自建构建节点作为 CI 工具。

Coding

简介、注册：略。

自建构建节点

参考：自定义节点 - 什么是 DevOps? DevOps 介绍 ｜ CODING DevOps (opens new window)

基于对构建节点性能、网络等因素的考虑，因此推荐使用自建的节点，只需要一台有网（无需公网）的服务器就可以了，在内部 PVE 开一个虚拟机，再执行一键脚本即可。

笔记

在选择 Coding 之前，一直使用的 Jenkins 的，而 Coding 本质上是一个加了商业属性的 Jenkins，选择 Coding 也是看中这一点，Coding 相当于是把 Jenkins 的主节点，自定义节点相当于 Jenkins 的 Agent，这既是 Coding 的优点也是缺点，作为优点它提供了体验远超于 Jenkins 的控制面板，作为缺点将原来可控的内部 Jenkins 变成了不可控，这就涉及到对 Coding 这个团队的信任问题了，那么多企业都选择 Coding，还是值得相信的。

安装 JDK

apt update
apt install openjdk-11-jdk

安装 Docker

参考：「Linux」一键安装 Docker | NipGeihou's blog

安装 KubeCtl

参考：在 Linux 系统中安装并设置 kubectl | Kubernetes (opens new window)

# 下载
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"

# 校验，可选
curl -LO "https://dl.k8s.io/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl.sha256"
echo "$(cat kubectl.sha256)  kubectl" | sha256sum --check

# 安装
sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl

# 测试
kubectl version --client

执行 Coding 节点脚本

选择【持续集成】->【构建节点】中，点击右上角的【接入新节点】，选中 Linux，选择 Bash 接入方式。设置完成后在 Linux 环境中运行已生成的接入配置命令。

流水线配置

pipeline {
  agent any
  stages {
    stage('检出') {
      steps {
        checkout([$class: 'GitSCM',
        branches: [[name: GIT_BUILD_REF]],
        userRemoteConfigs: [[
          url: GIT_REPO_URL,
          credentialsId: CREDENTIALS_ID
        ]]])
      }
    }

    stage('安装依赖&编译') {
      agent {
        docker {
          reuseNode 'true'
          registryUrl 'https://coding-public-docker.pkg.coding.net'
          image 'public/docker/nodejs:16-2022'
          args '-v /root/.npm:/root/.npm'
        }

      }
      steps {
        sh '''npm install
npm run build'''
      }
    }

    stage('Docker镜像') {
      steps {
        sh '''# 构建
docker build -t $REGISTRY/$DOCKERHUB_NAMESPACE/$APP_NAME:latest .

# 登录
echo "$DOCKER_PASSWORD" | docker login $REGISTRY -u "$DOCKER_USERNAME" --password-stdin

# 上传
docker push $REGISTRY/$DOCKERHUB_NAMESPACE/$APP_NAME:latest'''
      }
    }

    stage('部署K8S') {
      steps {
        script {
          withKubeConfig([credentialsId: "$K8S_CREDENTIAL_ID"]) {
            // 通过更新版本配置，实现重新部署（latest不可用，会提示 no change）
            //sh "kubectl patch deployment nipgeihou-blog --patch '{\"spec\": {\"template\": {\"spec\": {\"containers\": [{\"name\": \"nipgeihou-blog\", \"image\": \"${REGISTRY}/${DOCKERHUB_NAMESPACE}/${APP_NAME}:latest\"}], \"imagePullSecrets\": [{\"name\": \"txy-docer-registry\"}]}}}}'"
            // 通过删除pod，实现重新部署
            // sh "kubectl delete pod -l app=$APP_NAME"
            // 适用于部署latest版本
            sh "kubectl rollout restart deployment/<deployment-name>"
          }
        }

      }
    }

  }
}

关于k8s部署命令的区别

• 对于镜像版本号有变化的更新，应使用类似于如下的更新方式，通过更改 yaml 配置文件内容实现重新部署。

kubectl patch deployment nipgeihou-blog --patch '{\"spec\": {\"template\": {\"spec\": {\"containers\": [{\"name\": \"nipgeihou-blog\", \"image\": \"${REGISTRY}/${DOCKERHUB_NAMESPACE}/${APP_NAME}:新的版本号\"}], \"imagePullSecrets\": [{\"name\": \"txy-docer-registry\"}]}}}}'

• 对于镜像版本号没有变化的更新，通常为 latest ，应使用如下方式，强制重新部署，前提需要配置 imagePullPolicy: Always 。

kubectl rollout restart deployment/<deployment-name>

# 不推荐使用，这种方式无法实现流量平稳切换，会出现无法访问的空窗期。
# kubectl delete pod -l app=$APP_NAME

参考：

• How do I force Kubernetes to re-pull an image? - Stack Overflow (opens new window)

参考

• 部署到 K8S - 什么是 DevOps? DevOps 介绍 ｜ CODING DevOps (opens new window)