Cicd on 丸子有记, 记录生活、分享技术，专注于运维架构、运维开发(devops)。

Github Actions入门实践

wzdushu@gmail.com (wanzi) — Fri, 01 Nov 2024 17:22:42 +0800

Github Action是什么？

GitHub Actions 是一个持续集成和持续交付 (CI/CD) 平台，可让您自动化构建、测试和部署流程。您可以创建工作流程来构建和测试对存储库的每个拉取请求，或将合并的拉取请求部署到生产环境中。

GitHub Actions 不仅仅是 DevOps，它还允许您在存储库中发生其他事件时运行工作流程。例如，您可以运行工作流程，以便在有人在您的存储库中创建新问题时自动添加适当的标签。

GitHub提供 Linux、Windows 和 macOS 虚拟机来运行您的工作流程，或者您可以在自己的数据中心或云基础设施中托管自己的自托管运行器。

CICD工具选型

目前CICD的市场真是百花齐放，除了github actions外还有很多其他CICD工具可供选择，比如：Gitlab CI、Jenkins、专注于云原生的Tekton、Bitbucket Pipelines、AWS CodePipeline、Bitbucket Pipelines、Azure DevOps、阿里云云效等等

而选择那种方式来实现自己业务自动化流水线，就要根据自己的实际情况来选择了，下面推荐从如下几个方面入手：

成本，是选择开源方案还是选择付费商业版本，如果把成本放在第一位，需要考虑搭建开源软件服务器成本和付费软件的授权成本。
易用性和学习路线，主要考虑系统界面是否美观以及技术文档是否完善，界面这方面很难评判，而技术文档可以查看官方文档是否详细以及工作流是采用yaml还是新语言。
可扩展和灵活性，主要考虑系统插件和自定义需求是否能够满足，这方面还要看个人需求，比如有些企业需要CICD和jira打通，那选择Bitbucket Pipelines更好。
集成能力，主要考虑是否和目前代码仓库、测试框架、部署环境集成以及API功能完善程度，比如你的代码仓库在Github上，当然选择github actions更好一些。
安全性，主要考察是否有访问控制、数据加密等安全特性，这个根据自己实际需求来选择。
性能，主要考察大规模部署的性能瓶颈，往往这个需要结合成本或者资源需求来比较，比如你日常构建对文件传输和带宽有很严格需要，用github actions这种就不是最好的选择了。
企业级方案，主要考察高并发、多租户、安全合规等，往往对于企业到一定规模，会有很多定制需求，看工具是否有企业解决方案。
云原生支持，主要考察业务在kubernetes下的支持程度，特别是新版本，这方面Tekton更有优势。
社区和生态，主要考察项目或者产品哪些用户在使用，以及社区活跃度，这方面jenkins、gitlab、github相对更有优势。

Github Actions组件

1. workflow

从字面意思可以看出workflow是一种工作流程，而这里主要为了配置github actions的CICD自动化流程，通常使用yaml文件定义，定义完成以后可以自动触发工作流也可以手动触发工作流程。

workflow的工作目录一般为仓库的下.github/workflow目录下,一个存储库可以有多个工作流，每个工作流可以执行一组不同的任务，这里的任务也就是常说的job任务。例如：

构建和测试拉取请求。
每次发布时部署您的应用程序。
每当打开新问题时添加标签。

当然，工作流之间也可以相互引用。

在实际使用当中，我们通常采用workflow模版来快速编写工作流程，而github也提供了各类场景工作流模版，比如

CI：持续集成工作流
部署：部署工作流
自动化：自动化工作流
代码扫描：代码扫描工作流
github pages：pages工作流

在编写工作流的时候，需要注意常见关键字的意思，下面我简单梳理了一下，方便后面使用：

name: 定义工作流程名称
run-name: 定义工作流运行时名称
on: 定义触发器，可以是一个事件也可以是多个事件或者是根据匹配来触发
env：定义工作流全局变量
jobs: 定义工作流任务
permissions: 定义工作流对仓库权限
default: 定义默认配置,可以用在全局或者某一个job中，比如定义shell或者工作目录等
on.schedule: 定义工作流时间计划
on.workflow_call: 定义不同工作流的输入和输出过程中信息传递。
on.workflow_dispatch：定义特定工作流中，输入一些标记来触发
jobs.<job_id>.name: 定义单个job的任务名称
jobs.<job_id>.runs-on: 选择jobs运行环境，默认为github官方的，也可以选择高性能机器或者托管自己主机
jobs.<job_id>.steps: 定义单个job不同的运行阶段，比如一个job里有checkout代码，也有build
jobs.<job_id>.env：定义单个job特定变量，属于map类型，也可以设置在全局。
jobs.<job_id>.environment: 定义单个Job里引用，内容可以是变量或者上下文的表达式。
jobs.<job_id>.uses: 定义使用那种action，有的时候部署一些复杂场景，需要用到一些开源比较好的action
jobs.<job_id>.with: 指定参数，一般在任务构建的时候，需要指定一个版本
jobs.<job_id>.needs: 一般多个job的时候，处理job之间依赖关系
jobs.<job_id>.if: 指定job运行条件
jobs.<job_id>.container: 指定单个job里指定容器服务，注意对runner的操作系统有要求，比如ubuntu
jobs.<job_id>.outputs: 定义作业输出一些内容

2. 事件触发器

上一步，我们知道了工作流，那如何触发工作流呢？这个时候就需要定义一个事件触发器，比如常用事件触发器方式：

代码仓库变更触发，比如推送到代码默认分支时触发
github之外发生，并触发repository_dispatch事件
预定时间
手动触发

工作流触发器使用on定义，常见几种配置：

设置一个事件的触发器，当推送到工作流存储库中的任何分支时触发：

`1`	`on: push`

设置一个多个事件的触发器，当推送到工作流存储库中的任何分支时触发：

`1`	`on: [push, fork]`

当有多个分支的时候，需要过滤特定分支，比如main或者releases相关分支，有推送即触发：

on:
  push:
    branches:
      - main
      - 'releases/**'

github本身也可以对issues进行匹配来触发

on:
  issues:
    types:
      - opened
      - labeled

3. Jobs

一般工作流中由一个或多个jobs组成，默认情况下并行运行，需要注意：jobs.<job_id>是job的唯一标识符

比如，我们定义一个job名为Docker build，而对于这个job, build才是job的唯一标识符

jobs:
  build:
    name: Docker build
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4

另外,job之间也可以定义依赖关系，通过jobs.<job_id>.needs关键字定义，比如:

jobs:
  job1:
  job2:
    needs: job1
  job3:
    needs: [job1, job2]

在此示例中，job1必须在job2开始之前成功完成，并且job3等待job1和job2完成。

4. Actions

Action是Github上自定义应用程序，用于执行复杂但经常重复的任务。使用操作有助于减少您在工作流程文件中编写的重复代码量。

Actions可以从GitHub拉取您的Git仓库，为您的构建环境设置正确的工具链，或设置对您的云提供商的身份验证。

一般通过关键字uses来定义，比如使用官方: actions/checkout@v4

jobs:
  deploy:
    name: Deploy
    runs-on: ubuntu-latest
    environment: production

    steps:
    - name: Checkout
      uses: actions/checkout@v4

您可以编写自己的操作，也可以在 GitHub Marketplace 中找到工作流程中使用的操作。

5. Runners

Runners是一种在触发工作流程时运行工作流程的服务器。通过关键字runs-on来定义使用那种类型runners。每个运行器一次可以运行一项作业，这点确实和gitlab CI里的runner很像。

GitHub提供Ubuntu Linux、Microsoft Windows和macOS相关的runner来运行工作流。每个工作流程都运行在在全新、新配置的虚拟机中执行。

当然，如果默认Runners无法满足你的业务需求，比如需要ARM架构虚拟机，将自己服务器托管给github来管理；或者资源无法满足也可以申请更大的runners。

以下示例工作流有两个作业，名为 Run-npm-on-Ubuntu 和 Run-PSScriptAnalyzer-on-Windows。触发此工作流时，GitHub 为每个作业预配新的虚拟机。

名为 Run-npm-on-Ubuntu的作业在Linux VM上执行，因为作业runs-on: 指定 ubuntu-latest。名为 Run-PSScriptAnalyzer-on-Windows的作业在Windows VM 上执行，因为作业runs-on: 指定 windows-latest。

name: Run commands on different operating systems
on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  Run-npm-on-Ubuntu:
    name: Run npm on Ubuntu
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '14'
      - run: npm help

  Run-PSScriptAnalyzer-on-Windows:
    name: Run PSScriptAnalyzer on Windows
    runs-on: windows-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install PSScriptAnalyzer module
        shell: pwsh
        run: |
          Set-PSRepository PSGallery -InstallationPolicy Trusted
          Install-Module PSScriptAnalyzer -ErrorAction Stop
      - name: Get list of rules
        shell: pwsh
        run: |
          Get-ScriptAnalyzerRule

这个GitHub Actions工作流文件定义了两个作业：

Run-npm-on-Ubuntu: 在 Ubuntu 虚拟机上运行 npm help 命令。
Run-PSScriptAnalyzer-on-Windows: 在 Windows 虚拟机上安装 PSScriptAnalyzer 模块并列出所有可用的规则。

这两个作业分别展示了如何在不同的操作系统上运行特定的命令和脚本。通过这种方式，你可以确保在不同环境中的一致性和兼容性。

Github Actions常见示例

1. 前端构建部署

举例, 一个部署前端Nodejs项目到Azure云的模版， Deploy Node.js to Azure Web App：

on:
  push:
    branches: [ "master" ]
  workflow_dispatch:  # 允许手动触发工作流

env:
  AZURE_WEBAPP_NAME: your-app-name    # set this to your application's name
  AZURE_WEBAPP_PACKAGE_PATH: '.'      # set this to the path to your web app project, defaults to the repository root
  NODE_VERSION: '20.x'                # set this to the node version to use

permissions:
  contents: read

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4

    - name: Set up Node.js
      uses: actions/setup-node@v4
      with:
        node-version: ${{ env.NODE_VERSION }}
        cache: 'npm'

    - name: npm install, build, and test
      run: |
        npm install
        npm run build --if-present
        npm run test --if-present

    - name: Upload artifact for deployment job
      uses: actions/upload-artifact@v3
      with:
        name: node-app
        path: .

  deploy:
    permissions:
      contents: none
    runs-on: ubuntu-latest
    needs: build
    environment:
      name: 'Development'
      url: ${{ steps.deploy-to-webapp.outputs.webapp-url }}

    steps:
    - name: Download artifact from build job
      uses: actions/download-artifact@v3
      with:
        name: node-app

    - name: 'Deploy to Azure WebApp'
      id: deploy-to-webapp
      uses: azure/webapps-deploy@v2
      with:
        app-name: ${{ env.AZURE_WEBAPP_NAME }}
        publish-profile: ${{ secrets.AZURE_WEBAPP_PUBLISH_PROFILE }}
        package: ${{ env.AZURE_WEBAPP_PACKAGE_PATH }}

这个GitHub Actions工作流文件定义了两个主要作业：build 和 deploy。build 作业负责检出代码、设置 Node.js 环境、安装依赖、构建和测试项目，并将构建结果上传为 artifact。 deploy 作业则从 build 作业下载 artifact，并将其部署到 Azure Web App。整个流程自动化了从代码提交到应用部署的全过程。

2. Golang多版本

举例：如下是一个go多版本构建示例

name: Go

on: [push]

jobs:
  build:

    runs-on: ubuntu-latest
    strategy:
      matrix:
        go-version: [ '1.19', '1.20', '1.21.x' ]

    steps:
      - uses: actions/checkout@v4
      - name: Setup Go ${{ matrix.go-version }}
        uses: actions/setup-go@v5
        with:
          go-version: ${{ matrix.go-version }}
      # You can test your matrix by printing the current Go version
      - name: Display Go version
        run: go version

这个GitHub Actions工作流文件主要定义支持多版本golang环境的构建。

3. 容器示例

举例：一个runners为ubuntu的节点里运行docker容器服务

name: CI
on:
  push:
    branches: [ main ]
jobs:
  container-test-job:
    runs-on: ubuntu-latest
    container:
      image: node:18
      env:
        NODE_ENV: development
      ports:
        - 80   # 将容器80端口映射到主机的80端口。
      volumes:
        - my_docker_volume:/volume_mount # 将名为my_docker_volume的Docker卷挂载到容器的/volume_mount路径
      options: --cpus 1 # 限制容器使用的CPU数量为1个核
    steps:
      - name: Check for dockerenv file
        run: (ls /.dockerenv && echo Found dockerenv) || (echo No dockerenv)

这个GitHub Actions工作流文件定义了一个CI任务，该任务在最新的Ubuntu虚拟机上运行，并使用 Node.js 18的Docker镜像。作业配置了环境变量、端口映射、卷挂载和CPU限制。唯一的一个步骤是检查是否存在 .dockerenv 文件，以确认当前环境是否为 Docker 容器。

4. 部署应用到AWS ECS

# This workflow will build and push a new container image to Amazon ECR,
# and then will deploy a new task definition to Amazon ECS, when there is a push to the "master" branch.
#
# To use this workflow, you will need to complete the following set-up steps:
#
# 1. Create an ECR repository to store your images.
#    For example: `aws ecr create-repository --repository-name my-ecr-repo --region us-east-2`.
#    Replace the value of the `ECR_REPOSITORY` environment variable in the workflow below with your repository's name.
#    Replace the value of the `AWS_REGION` environment variable in the workflow below with your repository's region.
#
# 2. Create an ECS task definition, an ECS cluster, and an ECS service.
#    For example, follow the Getting Started guide on the ECS console:
#      https://us-east-2.console.aws.amazon.com/ecs/home?region=us-east-2#/firstRun
#    Replace the value of the `ECS_SERVICE` environment variable in the workflow below with the name you set for the Amazon ECS service.
#    Replace the value of the `ECS_CLUSTER` environment variable in the workflow below with the name you set for the cluster.
#
# 3. Store your ECS task definition as a JSON file in your repository.
#    The format should follow the output of `aws ecs register-task-definition --generate-cli-skeleton`.
#    Replace the value of the `ECS_TASK_DEFINITION` environment variable in the workflow below with the path to the JSON file.
#    Replace the value of the `CONTAINER_NAME` environment variable in the workflow below with the name of the container
#    in the `containerDefinitions` section of the task definition.
#
# 4. Store an IAM user access key in GitHub Actions secrets named `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY`.
#    See the documentation for each action used below for the recommended IAM policies for this IAM user,
#    and best practices on handling the access key credentials.

name: Deploy to Amazon ECS

on:
  push:
    branches: [ "master" ]

env:
  AWS_REGION: MY_AWS_REGION                   # set this to your preferred AWS region, e.g. us-west-1
  ECR_REPOSITORY: MY_ECR_REPOSITORY           # set this to your Amazon ECR repository name
  ECS_SERVICE: MY_ECS_SERVICE                 # set this to your Amazon ECS service name
  ECS_CLUSTER: MY_ECS_CLUSTER                 # set this to your Amazon ECS cluster name
  ECS_TASK_DEFINITION: MY_ECS_TASK_DEFINITION # set this to the path to your Amazon ECS task definition
                                               # file, e.g. .aws/task-definition.json
  CONTAINER_NAME: MY_CONTAINER_NAME           # set this to the name of the container in the
                                               # containerDefinitions section of your task definition

permissions:
  contents: read

jobs:
  deploy:
    name: Deploy
    runs-on: ubuntu-latest
    environment: production

    steps:
    - name: Checkout
      uses: actions/checkout@v4

    - name: Configure AWS credentials
      uses: aws-actions/configure-aws-credentials@v1
      with:
        aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
        aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        aws-region: ${{ env.AWS_REGION }}

    - name: Login to Amazon ECR
      id: login-ecr
      uses: aws-actions/amazon-ecr-login@v1

    - name: Build, tag, and push image to Amazon ECR
      id: build-image
      env:
        ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
        IMAGE_TAG: ${{ github.sha }}
      run: |
        # Build a docker container and
        # push it to ECR so that it can
        # be deployed to ECS.
        docker build -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG .
        docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG
        echo "image=$ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG" >> $GITHUB_OUTPUT

    - name: Fill in the new image ID in the Amazon ECS task definition
      id: task-def
      uses: aws-actions/amazon-ecs-render-task-definition@v1
      with:
        task-definition: ${{ env.ECS_TASK_DEFINITION }}
        container-name: ${{ env.CONTAINER_NAME }}
        image: ${{ steps.build-image.outputs.image }}

    - name: Deploy Amazon ECS task definition
      uses: aws-actions/amazon-ecs-deploy-task-definition@v1
      with:
        task-definition: ${{ steps.task-def.outputs.task-definition }}
        service: ${{ env.ECS_SERVICE }}
        cluster: ${{ env.ECS_CLUSTER }}
        wait-for-service-stability: true

这个GitHub Actions工作流文件定义了一个 CI/CD流程，用于将Docker镜像构建并部署到Amazon ECS。设计内容有：检出代码、配置AWS凭证、登录到Amazon ECR、构建标记并推送镜像到ECR、更新ECS任务定义中的镜像ID、部署更新后的ECS任务定义。

5. 结合Helm部署应用到AKS集群

# This workflow will build and push an application to a Azure Kubernetes Service (AKS) cluster when you push your code
#
# This workflow assumes you have already created the target AKS cluster and have created an Azure Container Registry (ACR)
# The ACR should be attached to the AKS cluster
# For instructions see:
#   - https://docs.microsoft.com/en-us/azure/aks/kubernetes-walkthrough-portal
#   - https://docs.microsoft.com/en-us/azure/container-registry/container-registry-get-started-portal
#   - https://learn.microsoft.com/en-us/azure/aks/cluster-container-registry-integration?tabs=azure-cli#configure-acr-integration-for-existing-aks-clusters
#   - https://github.com/Azure/aks-create-action
#
# To configure this workflow:
#
# 1. Set the following secrets in your repository (instructions for getting these
#    https://docs.microsoft.com/en-us/azure/developer/github/connect-from-azure?tabs=azure-cli%2Clinux)):
#    - AZURE_CLIENT_ID
#    - AZURE_TENANT_ID
#    - AZURE_SUBSCRIPTION_ID
#
# 2. Set the following environment variables (or replace the values below):
#    - AZURE_CONTAINER_REGISTRY (name of your container registry / ACR)
#    - CONTAINER_NAME (name of the container image you would like to push up to your ACR)
#    - RESOURCE_GROUP (where your cluster is deployed)
#    - CLUSTER_NAME (name of your AKS cluster)
#    - IMAGE_PULL_SECRET_NAME (name of the ImagePullSecret that will be created to pull your ACR image)
#
# 3. Choose the appropriate render engine for the bake step https://github.com/Azure/k8s-bake. The config below assumes Helm.
#    Set your helmChart, overrideFiles, overrides, and helm-version to suit your configuration.
#    - CHART_PATH (path to your helm chart)
#    - CHART_OVERRIDE_PATH (path to your helm chart with override values)
#
# For more information on GitHub Actions for Azure, refer to https://github.com/Azure/Actions
# For more samples to get started with GitHub Action workflows to deploy to Azure, refer to https://github.com/Azure/actions-workflow-samples
# For more options with the actions used below please refer to https://github.com/Azure/login

name: Build and deploy an app to AKS with Helm

on:
  push:
    branches: ["master"]
  workflow_dispatch:

env:
  AZURE_CONTAINER_REGISTRY: "your-azure-container-registry"
  CONTAINER_NAME: "your-container-name"
  RESOURCE_GROUP: "your-resource-group"
  CLUSTER_NAME: "your-cluster-name"
  CHART_PATH: "your-chart-path"
  CHART_OVERRIDE_PATH: "your-chart-override-path"

jobs:
  buildImage:
    permissions:
      contents: read
      id-token: write
    runs-on: ubuntu-latest
    steps:
      # Checks out the repository this file is in
      - uses: actions/checkout@v4

      # Logs in with your Azure credentials
      - name: Azure login
        uses: azure/login@v1.4.6
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

      # Builds and pushes an image up to your Azure Container Registry
      - name: Build and push image to ACR
        run: |
          az acr build --image ${{ env.AZURE_CONTAINER_REGISTRY }}.azurecr.io/${{ env.CONTAINER_NAME }}:${{ github.sha }} --registry ${{ env.AZURE_CONTAINER_REGISTRY }} -g ${{ env.RESOURCE_GROUP }} .

  deploy:
    permissions:
      actions: read
      contents: read
      id-token: write
    runs-on: ubuntu-latest
    needs: [buildImage]
    steps:
      # Checks out the repository this file is in
      - uses: actions/checkout@v4

      # Logs in with your Azure credentials
      - name: Azure login
        uses: azure/login@v1.4.6
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

      # Use kubelogin to configure your kubeconfig for Azure auth
      - name: Set up kubelogin for non-interactive login
        uses: azure/use-kubelogin@v1
        with:
          kubelogin-version: 'v0.0.25'

      # Retrieves your Azure Kubernetes Service cluster's kubeconfig file
      - name: Get K8s context
        uses: azure/aks-set-context@v3
        with:
          resource-group: ${{ env.RESOURCE_GROUP }}
          cluster-name: ${{ env.CLUSTER_NAME }}
          admin: 'false'
          use-kubelogin: 'true'

      # Runs Helm to create manifest files
      - name: Bake deployment
        uses: azure/k8s-bake@v2
        with:
          renderEngine: "helm"
          helmChart: ${{ env.CHART_PATH }}
          overrideFiles: ${{ env.CHART_OVERRIDE_PATH }}
          overrides: |
            replicas:2
          helm-version: "latest"
        id: bake

      # Deploys application based on manifest files from previous step
      - name: Deploy application
        uses: Azure/k8s-deploy@v4
        with:
          action: deploy
          manifests: ${{ steps.bake.outputs.manifestsBundle }}
          images: |
            ${{ env.AZURE_CONTAINER_REGISTRY }}.azurecr.io/${{ env.CONTAINER_NAME }}:${{ github.sha }}

这个GitHub Actions工作流文件定义了一个CI/CD流程，用于将Docker镜像构建并推送到Azure容器注册表（ACR），然后将应用程序部署到Azure Kubernetes Service (AKS)集群。主要步骤包括：检出代码、使用Azure凭证登录、构建并推送Docker镜像到ACR、获取AKS集群的kubeconfig文件、使用Helm渲染部署清单文件、部署应用程序。

7. 结合Helm部署应用到阿里云ACK集群

# This workflow will build and push a new container image to Alibaba Cloud Container Registry (ACR),
# and then will deploy it to Alibaba Cloud Container Service for Kubernetes (ACK), when there is a push to the "master" branch.
#
# To use this workflow, you will need to complete the following set-up steps:
#
# 1. Create an ACR repository to store your container images.
#    You can use ACR EE instance for more security and better performance.
#    For instructions see https://www.alibabacloud.com/help/doc-detail/142168.htm
#
# 2. Create an ACK cluster to run your containerized application.
#    You can use ACK Pro cluster for more security and better performance.
#    For instructions see https://www.alibabacloud.com/help/doc-detail/95108.htm
#
# 3. Store your AccessKey pair in GitHub Actions secrets named `ACCESS_KEY_ID` and `ACCESS_KEY_SECRET`.
#    For instructions on setting up secrets see: https://developer.github.com/actions/managing-workflows/storing-secrets/
#
# 4. Change the values for the REGION_ID, REGISTRY, NAMESPACE, IMAGE, ACK_CLUSTER_ID, and ACK_DEPLOYMENT_NAME.
#

name: Build and Deploy to ACK

on:
  push:
    branches: [ "master" ]

# Environment variables available to all jobs and steps in this workflow.
env:
  REGION_ID: cn-hangzhou
  REGISTRY: registry.cn-hangzhou.aliyuncs.com
  NAMESPACE: namespace
  IMAGE: repo
  TAG: ${{ github.sha }}
  ACK_CLUSTER_ID: clusterID
  ACK_DEPLOYMENT_NAME: nginx-deployment

  ACR_EE_REGISTRY: myregistry.cn-hangzhou.cr.aliyuncs.com
  ACR_EE_INSTANCE_ID: instanceID
  ACR_EE_NAMESPACE: namespace
  ACR_EE_IMAGE: repo
  ACR_EE_TAG: ${{ github.sha }}

permissions:
  contents: read

jobs:
  build:
    runs-on: ubuntu-latest
    environment: production

    steps:
    - name: Checkout
      uses: actions/checkout@v4

    # 1.1 Login to ACR
    - name: Login to ACR with the AccessKey pair
      uses: aliyun/acr-login@v1
      with:
        region-id: "${{ env.REGION_ID }}"
        access-key-id: "${{ secrets.ACCESS_KEY_ID }}"
        access-key-secret: "${{ secrets.ACCESS_KEY_SECRET }}"

    # 1.2 Build and push image to ACR
    - name: Build and push image to ACR
      run: |
        docker build --tag "$REGISTRY/$NAMESPACE/$IMAGE:$TAG" .
        docker push "$REGISTRY/$NAMESPACE/$IMAGE:$TAG"

    # 1.3 Scan image in ACR
    - name: Scan image in ACR
      uses: aliyun/acr-scan@v1
      with:
        region-id: "${{ env.REGION_ID }}"
        access-key-id: "${{ secrets.ACCESS_KEY_ID }}"
        access-key-secret: "${{ secrets.ACCESS_KEY_SECRET }}"
        repository: "${{ env.NAMESPACE }}/${{ env.IMAGE }}"
        tag: "${{ env.TAG }}"

    # 2.1 (Optional) Login to ACR EE
    - uses: actions/checkout@v4
    - name: Login to ACR EE with the AccessKey pair
      uses: aliyun/acr-login@v1
      with:
        login-server: "https://${{ env.ACR_EE_REGISTRY }}"
        region-id: "${{ env.REGION_ID }}"
        access-key-id: "${{ secrets.ACCESS_KEY_ID }}"
        access-key-secret: "${{ secrets.ACCESS_KEY_SECRET }}"
        instance-id: "${{ env.ACR_EE_INSTANCE_ID }}"

    # 2.2 (Optional) Build and push image ACR EE
    - name: Build and push image to ACR EE
      run: |
        docker build -t "$ACR_EE_REGISTRY/$ACR_EE_NAMESPACE/$ACR_EE_IMAGE:$TAG" .
        docker push "$ACR_EE_REGISTRY/$ACR_EE_NAMESPACE/$ACR_EE_IMAGE:$TAG"
    # 2.3 (Optional) Scan image in ACR EE
    - name: Scan image in ACR EE
      uses: aliyun/acr-scan@v1
      with:
        region-id: "${{ env.REGION_ID }}"
        access-key-id: "${{ secrets.ACCESS_KEY_ID }}"
        access-key-secret: "${{ secrets.ACCESS_KEY_SECRET }}"
        instance-id: "${{ env.ACR_EE_INSTANCE_ID }}"
        repository: "${{ env.ACR_EE_NAMESPACE}}/${{ env.ACR_EE_IMAGE }}"
        tag: "${{ env.ACR_EE_TAG }}"

    # 3.1 Set ACK context
    - name: Set K8s context
      uses: aliyun/ack-set-context@v1
      with:
        access-key-id: "${{ secrets.ACCESS_KEY_ID }}"
        access-key-secret: "${{ secrets.ACCESS_KEY_SECRET }}"
        cluster-id: "${{ env.ACK_CLUSTER_ID }}"

    # 3.2 Deploy the image to the ACK cluster
    - name: Set up Kustomize
      run: |-
        curl -s "https://raw.githubusercontent.com/kubernetes-sigs/kustomize/master/hack/install_kustomize.sh"  | bash /dev/stdin 3.8.6
    - name: Deploy
      run: |-
        ./kustomize edit set image REGISTRY/NAMESPACE/IMAGE:TAG=$REGISTRY/$NAMESPACE/$IMAGE:$TAG
        ./kustomize build . | kubectl apply -f -
        kubectl rollout status deployment/$ACK_DEPLOYMENT_NAME
        kubectl get services -o wide

这个GitHub Actions工作流文件定义了一个CI/CD流程，用于将Docker镜像构建并推送到阿里云容器镜像服务（ACR），然后将应用程序部署到阿里云容器服务for Kubernetes（ACK）。具体步骤包括：检出代码、使用AccessKey对ACR进行登录、构建并推送Docker镜像到ACR、扫描ACR中的镜像、设置ACK集群的上下文、设置Kustomize、部署应用程序。

8. 结合Helm部署应用到谷歌云集群

# This workflow will build a docker container, publish it to Google Container
# Registry, and deploy it to GKE when there is a push to the "master"
# branch.
#
# To configure this workflow:
#
# 1. Enable the following Google Cloud APIs:
#
#    - Artifact Registry (artifactregistry.googleapis.com)
#    - Google Kubernetes Engine (container.googleapis.com)
#    - IAM Credentials API (iamcredentials.googleapis.com)
#
#    You can learn more about enabling APIs at
#    https://support.google.com/googleapi/answer/6158841.
#
# 2. Ensure that your repository contains the necessary configuration for your
#    Google Kubernetes Engine cluster, including deployment.yml,
#    kustomization.yml, service.yml, etc.
#
# 3. Create and configure a Workload Identity Provider for GitHub:
#    https://github.com/google-github-actions/auth#preferred-direct-workload-identity-federation.
#
#    Depending on how you authenticate, you will need to grant an IAM principal
#    permissions on Google Cloud:
#
#    - Artifact Registry Administrator (roles/artifactregistry.admin)
#    - Kubernetes Engine Developer (roles/container.developer)
#
#    You can learn more about setting IAM permissions at
#    https://cloud.google.com/iam/docs/manage-access-other-resources
#
# 5. Change the values in the "env" block to match your values.

name: 'Build and Deploy to GKE'

on:
  push:
    branches:
      - '"master"'

env:
  PROJECT_ID: 'my-project' # TODO: update to your Google Cloud project ID
  GAR_LOCATION: 'us-central1' # TODO: update to your region
  GKE_CLUSTER: 'cluster-1' # TODO: update to your cluster name
  GKE_ZONE: 'us-central1-c' # TODO: update to your cluster zone
  DEPLOYMENT_NAME: 'gke-test' # TODO: update to your deployment name
  REPOSITORY: 'samples' # TODO: update to your Artifact Registry docker repository name
  IMAGE: 'static-site'
  WORKLOAD_IDENTITY_PROVIDER: 'projects/123456789/locations/global/workloadIdentityPools/my-pool/providers/my-provider' # TODO: update to your workload identity provider

jobs:
  setup-build-publish-deploy:
    name: 'Setup, Build, Publish, and Deploy'
    runs-on: 'ubuntu-latest'
    environment: 'production'

    permissions:
      contents: 'read'
      id-token: 'write'

    steps:
      - name: 'Checkout'
        uses: 'actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332' # actions/checkout@v4

      # Configure Workload Identity Federation and generate an access token.
      #
      # See https://github.com/google-github-actions/auth for more options,
      # including authenticating via a JSON credentials file.
      - id: 'auth'
        name: 'Authenticate to Google Cloud'
        uses: 'google-github-actions/auth@f112390a2df9932162083945e46d439060d66ec2' # google-github-actions/auth@v2
        with:
          workload_identity_provider: '${{ env.WORKLOAD_IDENTITY_PROVIDER }}'

      # Authenticate Docker to Google Cloud Artifact Registry
      - name: 'Docker Auth'
        uses: 'docker/login-action@9780b0c442fbb1117ed29e0efdff1e18412f7567' # docker/login-action@v3
        with:
          username: 'oauth2accesstoken'
          password: '${{ steps.auth.outputs.auth_token }}'
          registry: '${{ env.GAR_LOCATION }}-docker.pkg.dev'

      # Get the GKE credentials so we can deploy to the cluster
      - name: 'Set up GKE credentials'
        uses: 'google-github-actions/get-gke-credentials@6051de21ad50fbb1767bc93c11357a49082ad116' # google-github-actions/get-gke-credentials@v2
        with:
          cluster_name: '${{ env.GKE_CLUSTER }}'
          location: '${{ env.GKE_ZONE }}'

      # Build the Docker image
      - name: 'Build and push Docker container'
        run: |-
          DOCKER_TAG="${GAR_LOCATION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY}/${IMAGE}:${GITHUB_SHA}"

          docker build \
            --tag "${DOCKER_TAG}" \
            --build-arg GITHUB_SHA="${GITHUB_SHA}" \
            --build-arg GITHUB_REF="${GITHUB_REF}" \
            .

          docker push "${DOCKER_TAG}"

      # Set up kustomize
      - name: 'Set up Kustomize'
        run: |-
          curl -sfLo kustomize https://github.com/kubernetes-sigs/kustomize/releases/download/kustomize%2Fv5.4.3/kustomize_v5.4.3_linux_amd64.tar.gz
          chmod u+x ./kustomize

      # Deploy the Docker image to the GKE cluster
      - name: 'Deploy to GKE'
        run: |-
          # replacing the image name in the k8s template
          ./kustomize edit set image LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY/IMAGE:TAG=$GAR_LOCATION-docker.pkg.dev/$PROJECT_ID/$REPOSITORY/$IMAGE:$GITHUB_SHA
          ./kustomize build . | kubectl apply -f -
          kubectl rollout status deployment/$DEPLOYMENT_NAME
          kubectl get services -o wide

这个GitHub Actions工作流文件定义了一个CI/CD流程，用于将Docker镜像构建并推送到Google Cloud Artifact Registry（GAR），然后将应用程序部署到Google Kubernetes Engine（GKE）。

具体步骤包括：检出代码、使用Workload Identity Provider认证到Google Cloud、对Docker进行认证以推送镜像到Artifact Registry、获取GKE集群的凭证、构建并推送Docker镜像到Artifact Registry、设置Kustomize、部署应用程序到GKE。

Github Actions优缺点

通过这几天使用，我觉得GitHub Actions是一个强大的工具，用于自动化软件开发工作流程，如持续集成（CI）、持续部署（CD）、测试、发布等。它直接集成在GitHub平台上，提供了丰富的功能和灵活性。

然而，像所有工具一样，GitHub Actions也有其优点和缺点。以下是对其优缺点的总结：

优点

无缝集成：
- 与 GitHub 无缝集成：GitHub Actions 直接集成在 GitHub 平台内，可以轻松访问仓库中的代码和元数据。
- 自动触发：可以根据代码推送、拉取请求、标签创建等事件自动触发工作流。
丰富的市场：
- Action 市场：GitHub 提供了丰富的 Action 市场，用户可以找到大量的预构建 Action，用于常见的任务，如代码质量检查、部署、通知等。
- 社区支持：庞大的开发者社区提供了大量的资源和最佳实践，帮助用户快速解决问题。
灵活性和可扩展性：
- 自定义工作流：用户可以自定义复杂的多步骤工作流，满足特定需求。
- 环境变量和密钥管理：支持环境变量和密钥管理，确保敏感信息的安全。
- 并行执行：支持并行执行多个任务，提高效率。
内置安全性和审计：
- 安全特性：GitHub 提供了多种安全特性，如依赖项审查、代码扫描等。
- 审计日志：详细的审计日志记录，方便追踪和调试。
成本效益：
- 免费计划：对于开源项目和个人开发者，GitHub 提供了免费的 Actions 使用额度。
- 按需付费：对于企业用户，可以根据实际使用量付费，避免浪费资源。

缺点

学习曲线：
- 复杂性：虽然提供了丰富的功能，但配置和管理复杂的工作流可能需要一定的学习时间和经验。
- 文档和示例：尽管有大量文档和示例，但对于初学者来说，找到合适的资源和最佳实践可能需要一些时间。
性能和资源限制：
- 资源限制：免费计划的资源有限，对于大型项目或高频率的 CI/CD 管道可能不够用。
- 性能波动：在高峰时段，GitHub Actions 的性能可能会受到影响，导致构建和部署速度变慢。
依赖于 GitHub：
- 平台锁定：使用 GitHub Actions 会增加对 GitHub 平台的依赖，迁移成本较高。
- 外部集成：虽然 GitHub Actions 支持与外部工具和服务的集成，但相比其他 CI/CD 工具，可能需要更多的配置和维护。
调试困难：
- 调试工具：虽然提供了日志和输出，但调试复杂的多步骤工作流可能较为困难，尤其是当出现问题时。
- 可视化不足：相比于一些商业 CI/CD 工具，GitHub Actions 的可视化和监控功能较为有限。
安全风险：
- 第三方 Action：使用第三方 Action 可能带来安全风险，需要仔细评估和选择。
- 权限管理：不当的权限管理可能导致安全漏洞，需要谨慎配置。

总结

GitHub Actions是一个功能强大且灵活的CI/CD 工具，特别适合与GitHub集成的项目。它的优点在于无缝集成、丰富的市场、灵活性和安全性。

然而，它也存在一些缺点，如学习曲线较陡、资源限制、平台锁定和调试困难。选择是否使用GitHub Actions 应根据项目的具体需求和团队的技术栈来决定。

对于小型项目和开源项目，GitHub Actions是一个非常不错的选择；对于大型企业项目，可能需要考虑更专业的 CI/CD工具。

Github Action通过ssh方式部署静态文件到云主机

wzdushu@gmail.com (wanzi) — Wed, 30 Oct 2024 21:22:42 +0800

前面我们使用Github Action配置了Hugo的自动化部署，今天主要记录一下使用Github Action配置ssh方式部署到腾讯云。

由于，wnote.com采用了DNS智能调度，海外区域访问的是Github Page，而国内我是部署在腾讯云主机的容器环境，所以需要将Github Action和腾讯云联动。

配置secrets

这里主要配置腾讯云SSH相关信息

这里我们配置：

配置文件新增腾讯云部署

name: Deploy Hugo site to Pages

on:
  # Runs on pushes targeting the default branch
  push:
    branches: ["master"]

  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

# Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages
permissions:
  contents: read
  pages: write
  id-token: write

# Allow only one concurrent deployment, skipping runs queued between the run in-progress and latest queued.
# However, do NOT cancel in-progress runs as we want to allow these production deployments to complete.
concurrency:
  group: "pages"
  cancel-in-progress: false

# Default to bash
defaults:
  run:
    shell: bash

jobs:
  # Build job and Deploy hugo to pages
  build-deploy:
    runs-on: ubuntu-latest
    env:
      HUGO_VERSION: 0.121.0
    steps:
      - name: Install Hugo CLI
        run: |
          wget -O ${{ runner.temp }}/hugo.deb https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_extended_${HUGO_VERSION}_linux-amd64.deb \
          && sudo dpkg -i ${{ runner.temp }}/hugo.deb

      - name: Install Dart Sass
        run: sudo snap install dart-sass

      - name: Checkout
        uses: actions/checkout@v4
        with:
          submodules: recursive

      - name: Build with Hugo
        env:
          HUGO_CACHEDIR: ${{ runner.temp }}/hugo_cache
          HUGO_ENVIRONMENT: production
        run: |
          hugo \
            --minify \
            --baseURL "https://wnote.com/"
            #--baseURL "${{ steps.pages.outputs.base_url }}/"

      - name: Upload artifact
        uses: actions/upload-pages-artifact@v3
        with:
          path: ./public
          
      - name: Deploy to GitHub Pages
        uses: peaceiris/actions-gh-pages@v4
        with:
          deploy_key: ${{ secrets.ACTIONS_DEPLOY_KEY }}
          external_repository: wzdushu/wzdushu.github.io
          publish_dir: ./public
          publish_branch: master
          cname: wnote.com
          commit_message: ${{ github.event.head_commit.message }}

      - name: Deploy to Tencent Cloud
        uses: easingthemes/ssh-deploy@v5.1.0
        with:
          SSH_PRIVATE_KEY: ${{ secrets.SSH_PRIVATE_KEY }}
          ARGS: "-avzr --delete"
          SSH_CMD_ARGS: "-o StrictHostKeyChecking=no"
          SOURCE: "public/"
          REMOTE_HOST: ${{ secrets.TENCENT_REMOTE_HOST }}
          REMOTE_PORT: ${{ secrets.TENCENT_REMOTE_PORT }}
          REMOTE_USER: ${{ secrets.TENCENT_REMOTE_USR }}
          TARGET: ${{ secrets.TENCENT_REMOTE_TARGET }} # /opt/wwwroot/xxx
          EXCLUDE: "/dist/, /node_modules/"
          SCRIPT_BEFORE: |
            whoami
            ls -al
          SCRIPT_AFTER: |
            whoami
            ls -al
            echo $RSYNC_STDOUT

至此，完成Github Action通过ssh部署到腾讯云.

Github Actions自动化部署hugo到Github Pages

wzdushu@gmail.com (wanzi) — Thu, 17 Oct 2024 17:22:42 +0800

前言

最近计划把博客主题升级一下，由于在倒腾Github Actions，打算用它实现一下CICD。写完文章提交以后自动将hugo产出静态文件自动化部署到Github pages、Netlify、Vercel、Cloud flare Pages等第三方平台，今天先记录Github pages自动化部署过程，这样就省很多事儿。

由于网站使用的Hugo静态网站生成器，涉及到敏感配置，我这里将Hugo的源代码放到私有仓库中，然后Hugo生成的前端静态页面放到Github公有仓库中，这样我们就需要准备两个Github仓库，然后通过私有仓库中github actions实现CICD。

Github Actions 官方文档: https://docs.github.com/zh/actions

Github Pages 官方标准: https://pages.github.com/

Github Token配置

由于涉及到部署，这个过程中会用到认证，而Github提供了三种token认证方式：

github_token
deploy_key
personal_token

其实在每个工作流中，github每次都会自动创建一个唯一的GITHUB_TOKEN密钥用于工作流的认证，GITHUB_TOKEN将在作业完成时或最多24小时后过期，这是一种临时认证策略。

注意: 由于我们这里涉及到跨仓库部署，所以github_token就无法使用了.

更多github_token可以参考：https://docs.github.com/actions/security-guides/automatic-token-authentication

personal_token 主要用个人账户生成token。

https://github.com/settings/tokens

对于deploy_token，主要是自己生成密钥对，将公钥附加到github仓库，自己存放私钥。

更多deploy_token参考：https://docs.github.com/en/authentication/connecting-to-github-with-ssh/managing-deploy-keys

这里我们采用deploy_token方式认证，将公钥附加到公有仓库的deploy-token上，私钥附加到私有仓库的secret。

创建deploy_token

1
2

ssh-keygen -t rsa -b 4096 -C "$(git config user.email)" -f gh-pages-wzdushu -N ""
# 当前目录下会生成密钥对gh-pages-wzdushu和gh-pages-wzdushu.pub

公有仓库wzdushu/wzdushu.github.io配置Deploy keys设置gh-pages-wzdushu.pub内容。

私有仓库创建secret,指定名称为：ACTIONS_DEPLOY_KEY 内容为gh-pages-wzdushu

Github Actions配置

私有仓库创建workflow，我这里路径为：.github/workflows/cicd.yml，编辑这个文件内容如下：

name: Deploy Hugo site to Pages

on:
  # Runs on pushes targeting the default branch
  push:
    branches: ["master"]

  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

# Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages
permissions:
  contents: read
  pages: write
  id-token: write

# Allow only one concurrent deployment, skipping runs queued between the run in-progress and latest queued.
# However, do NOT cancel in-progress runs as we want to allow these production deployments to complete.
concurrency:
  group: "pages"
  cancel-in-progress: false

# Default to bash
defaults:
  run:
    shell: bash

jobs:
  # Build job and Deploy hugo to pages
  build-deploy:
    runs-on: ubuntu-latest
    env:
      HUGO_VERSION: 0.121.0
    steps:
      - name: Install Hugo CLI
        run: |
          wget -O ${{ runner.temp }}/hugo.deb https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_extended_${HUGO_VERSION}_linux-amd64.deb \
          && sudo dpkg -i ${{ runner.temp }}/hugo.deb

      - name: Install Dart Sass
        run: sudo snap install dart-sass

      - name: Checkout
        uses: actions/checkout@v4
        with:
          submodules: recursive

      - name: Build with Hugo
        env:
          HUGO_CACHEDIR: ${{ runner.temp }}/hugo_cache
          HUGO_ENVIRONMENT: production
        run: |
          hugo \
            --minify \
            --baseURL "${{ steps.pages.outputs.base_url }}/"

      - name: Upload artifact
        uses: actions/upload-pages-artifact@v2
        with:
          path: ./public

      - name: Deploy to GitHub Pages
        uses: peaceiris/actions-gh-pages@v4
        with:
          deploy_key: ${{ secrets.ACTIONS_DEPLOY_KEY }}
          external_repository: wzdushu/wzdushu.github.io
          publish_dir: ./public
          publish_branch: master
          cname: wnote.com
          commit_message: ${{ github.event.head_commit.message }}

on 这里有三种触发方式：

push：git push 推送时执行。
workflow_dispatch：项目仓库的 Actions 手动执行。
schedule：定时执行

由于这里hugo主题新版本依赖Sass，所以这里需要安装，非每个人必须。

这里部署没有使用官方actions，采用了开源的peaceiris/actions-gh-pages，主要是这个仓库对Hugo、MkDocs、Gatsby、mdBook、Next、Nuxt等比较友好。

其他配置可以参考github actions官方文档，不再一一说明。

执行部署

后面，我们就开心的像往常一样，写完文章提交到Github上，通过触发GitHub Actions 执行生成静态文件推送到GitHub Pages，剩下的时间就喝一杯咖啡让等它干完活了。

总结：对于Github actions自动化部署的功能，不仅仅局限于今天用来部署静态页面，对于实际项目和生产环境中，往往会将应用部署到k8s集群或者一些其他PAAS平台，比如阿里云ACK、AWS的EKS、Azure 的AKS等等，当然类似Jenkins或者Gitlab CI的其他功能，Github Actions也是一点不少。

自定义Jenkins Agent集成docker和kubectl工具

wzdushu@gmail.com (wanzi) — Wed, 22 Mar 2023 18:22:42 +0800

由于我们Jenkins构建的时候，官方提供的jenkins-agent没有我们使用的工具，比如helm，kubectl，curl，argocd等，因此，我们需要集成进来。

注意官方镜像名称有变化： jenkins/agent镜像，原名称为jenkins/slave，从4.3-2 开始更名为jenkins/agent jenkins/inbound-agent 镜像：原名称为 jenkins/jnlp-slave ，从 4.3-2 开始更名为 jenkins/inbound-agent

Dockerfile

FROM jenkins/inbound-agent:4.11-1-alpine-jdk11
 
USER root
 
ADD docker/docker /usr/bin/docker
ADD kubectl /usr/bin/kubectl
ADD helm /usr/bin/helm
 
RUN sed -i 's/dl-cdn.alpinelinux.org/mirrors.aliyun.com/g' /etc/apk/repositories
RUN chmod +x /usr/bin/docker /usr/bin/kubectl /usr/bin/helm
RUN apk add curl
 
ENTRYPOINT ["/usr/local/bin/jenkins-agent"]

构建

`1`	`docker build -t harbor.test.com/tools/jnlp-docker:4.11-1-alpine-jdk11 -f Dockerfile .`

Jenkins Workspace和Maven仓库本地持久化存储

wzdushu@gmail.com (wanzi) — Wed, 22 Mar 2023 16:22:42 +0800

创建本地存储

由于是测试集群，我们这里直接使用本地volume存储即可；

由于这里jenkins server里运行用户为jenkins，且jenkins的uid为1000，我们需要在node1上提前将/opt/jenkins_agent/和/opt/jenkins_maven/权限授权给jenkins

1
2

chown 1000.1000 -R  /opt/jenkins_agent -R
chown 1000.1000 -R  /opt/jenkins_maven/ -R

本地存储：agent-pv-pvc.yaml

apiVersion: v1
kind: PersistentVolume
metadata:
  name: jenkins-agent-pv
spec:
  storageClassName: local # Local PV
  capacity:
    storage: 30Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  local:
    path: /opt/jenkins_agent
  nodeAffinity:
    required:
      nodeSelectorTerms:
        - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
                - node01
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: jenkins-agent-pvc
  namespace: kube-ops
spec:
  storageClassName: local
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 30Gi

本地存储：maven-pv-pvc.yaml

apiVersion: v1
kind: PersistentVolume
metadata:
  name: jenkins-maven-pv
spec:
  storageClassName: local # Local PV
  capacity:
    storage: 30Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  local:
    path: /opt/jenkins_maven
  nodeAffinity:
    required:
      nodeSelectorTerms:
        - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
                - node01
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: jenkins-maven-pvc
  namespace: kube-ops
spec:
  storageClassName: local
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 30Gi

创建PV和PVC资源

# kubectl apply -f  agent-pv-pvc.yaml
persistentvolume/jenkins-agent-pv created
persistentvolumeclaim/jenkins-agent-pvc created

# kubectl apply -f  maven-pv-pvc.yaml
persistentvolume/jenkins-maven-pv created
persistentvolumeclaim/jenkins-maven-pvc created

kubernetes环境下部署Jenkins

wzdushu@gmail.com (wanzi) — Thu, 16 Mar 2023 16:22:42 +0800

一、安装部署Jenkins

1、手动安装

手动安装就很简单，提前将yaml配置准备好即可，所有CICD资源jenkins-install.yaml内容如下：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: jenkins-pv
spec:
  storageClassName: local # Local PV
  capacity:
    storage: 30Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  local:
    path: /opt/jenkins
  nodeAffinity:
    required:
      nodeSelectorTerms:
        - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
                - node02
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: jenkins-pvc
  namespace: kube-ops
spec:
  storageClassName: local
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 30Gi
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: jenkins
  namespace: kube-ops
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: jenkins
rules:
  - apiGroups: ["extensions", "apps"]
    resources: ["deployments", "ingresses"]
    verbs: ["create", "delete", "get", "list", "watch", "patch", "update"]
  - apiGroups: [""]
    resources: ["services"]
    verbs: ["create", "delete", "get", "list", "watch", "patch", "update"]
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["create", "delete", "get", "list", "patch", "update", "watch"]
  - apiGroups: [""]
    resources: ["pods/exec"]
    verbs: ["create", "delete", "get", "list", "patch", "update", "watch"]
  - apiGroups: [""]
    resources: ["pods/log", "events"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["secrets"]
    verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: jenkins
  namespace: kube-ops
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: jenkins
subjects:
  - kind: ServiceAccount
    name: jenkins
    namespace: kube-ops
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: jenkins
  namespace: kube-ops
spec:
  selector:
    matchLabels:
      app: jenkins
  template:
    metadata:
      labels:
        app: jenkins
    spec:
      serviceAccount: jenkins
      initContainers:
        - name: fix-permissions
          image: busybox
          command: ["sh", "-c", "chown -R 1000:1000 /var/jenkins_home"]
          securityContext:
            privileged: true
          volumeMounts:
            - name: jenkinshome
              mountPath: /var/jenkins_home
      containers:
        - name: jenkins
          #image: jenkins/jenkins:lts
          image: jenkins/jenkins:2.375.3-lts #这里我们选用最新稳定版本
          imagePullPolicy: IfNotPresent
          env:
          - name: JAVA_OPTS
            value: -Dhudson.model.DownloadService.noSignatureCheck=true
          ports:
            - containerPort: 8080
              name: web
              protocol: TCP
            - containerPort: 50000
              name: agent
              protocol: TCP
          resources:
            limits:
              cpu: 1500m
              memory: 4096Mi
            requests:
              cpu: 1500m
              memory: 2048Mi
          readinessProbe:
            httpGet:
              path: /login
              port: 8080
            initialDelaySeconds: 60
            timeoutSeconds: 5
            failureThreshold: 12
          volumeMounts:
            - name: jenkinshome
              mountPath: /var/jenkins_home
      volumes:
        - name: jenkinshome
          persistentVolumeClaim:
            claimName: jenkins-pvc
---
apiVersion: v1
kind: Service
metadata:
  name: jenkins
  namespace: kube-ops
  labels:
    app: jenkins
spec:
  selector:
    app: jenkins
  ports:
    - name: web
      port: 8080
      targetPort: web
    - name: agent
      port: 50000
      targetPort: agent
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: jenkins
  namespace: kube-ops
spec:
  ingressClassName: traefik
  rules:
  - host: jenkins.test.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: jenkins
            port:
              number: 8080

安装Jenkins

`1`	`kubectl apply -f jenkins-install.yaml`

整个安装过程，牵涉如下资源配置：

本地存储：hostpath方式
权限认证相关：ServiceAccount、Clusterrole、ClusterRoleBinding
部署和服务：deployment、service、ingress

2、配置Jenkins

这里需要注意，由于 jenkens 会对 update-center.json 做签名校验安全检查，这里我们需要先提前关闭，否则下面更改插件源可能会失败，通过配置环境变量 JAVA_OPTS=-Dhudson.model.DownloadService.noSignatureCheck=true 即可；

安装完成jenkins后，打开https://jenkins.test.com，会让你输入Jenkins管理员密码，通过如下方式获取即可：

1
2

kubectl exec -it jenkins-d995d6d4-srfr8 -n kube-ops -- cat /var/jenkins_home/secrets/initialAdminPassword
a571eb7a8ac54256ae638bb4a61fd31b

然后跳过插件安装，选择默认安装插件过程会非常慢（也可以选择安装推荐的插件），点击右上角关闭选择插件，等配置好插件中心国内镜像源后再选择安装一些插件。

打开：https://jenkins.test.com/chinese/ 配置国内镜像源地址，我这里选择阿里云（https://mirrors.aliyun.com/jenkins/updates/update-center.json）的：

3、安装插件

https://jenkins.test.com/manage/pluginManager/available

我这里主要安装kubernetes、中文语言包、pipeline等，具体安装步骤这里省略。

Jenkins汉化：https://plugins.jenkins.io/localization-zh-cn/
Build With Parameters：https://plugins.jenkins.io/build-with-parameters
Kubernetes：https://plugins.jenkins.io/kubernetes/
Pipeline：https://plugins.jenkins.io/workflow-aggregator/
Git：https://plugins.jenkins.io/git/
zentimestamp：https://plugins.jenkins.io/zentimestamp/

二、连接Kubernetes集群

1、k8s集群信息配置

打开https://jenkins.test.com/configureClouds/

直接新建集群，选择kubernetes，配置集群地址、namespace：

2、Jenkins地址配置

配置Jenkins在k8s集群调用地址，以及Jenkins通道地址:

3、Pod Template配置

主要配置命名空间、标签

4、Container Template配置

主要配置slave构建容器信息，注意容器名称必须是jnlp。

Docker镜像我这里是自己构建，集成了docker、kubectl等工具，另外，需要注意运行命令、命令参数留空即可，不然创建容器会失效。

配置卷，挂载docker socket文件，共享宿主机docker（Docker in docker）；挂载kubeconfig配置，主要方便kubectl、helm等命令可以操作k8s集群资源。

最后，配置下service account为Jenkins，这个账户是之前我们创建jenkins的时候的名称。

三、简单测试

1、创建一个自由风格Job任务

2、绑定Slave Pod

3、配置shell测试命令

4、执行一个构建任务

执行完成以后，我们查看任务构建历史记录发现，这个过程中会自动创建一个slave的pod，同时完成任务以后，该Pod也会自动销毁。

四、总结：

对于持续构建与发布是日常研发体系中必不可少的一步，目前大部分公司采用 Jenkins 集群搭建CICD环境，传统的Jenkins Slave 一主多从方式会存在一些痛点，比如：

主 Master发生单点故障，整个流程都不可用了
每个 Slave的配置环境不一样，来完成不同语言的编译打包等操作，但是这些差异化的配置导致管理起来非常不方便，维护起来也是比较费劲
资源分配不均衡，有的 Slave 要运行的 job 出现排队等待，而有的 Slave 处于空闲状态
资源有浪费，每台 Slave 可能是物理机或者虚拟机，当 Slave 处于空闲状态时，也不会完全释放掉资源。

正因为上面的这些种种痛点，我们渴望一种更高效更可靠的方式来完成这个 CI/CD 流程，而 Docker 虚拟化容器技术能很好的解决这个痛点，又特别是在 Kubernetes 集群环境下面能够更好来解决上面的问题，下图是基于 Kubernetes 搭建 Jenkins 集群的简单示意图：

从图上可以看到 Jenkins Master 和 Jenkins Slave 以 Pod 形式运行在 Kubernetes 集群的 Node 上，Master 运行在其中一个节点，并且将其配置数据存储到一个 Volume 上去，Slave 运行在各个节点上，并且它不是一直处于运行状态，它会按照需求动态的创建并自动删除。

这种方式的工作流程大致为：当 Jenkins Master 接受到 Build 请求时，会根据配置的 Label 动态创建一个运行在 Pod 中的 Jenkins Slave 并注册到 Master 上，当运行完 Job 后，这个 Slave 会被注销并且这个 Pod 也会自动删除，恢复到最初状态。

那么我们使用这种方式带来了哪些好处呢？

服务高可用，当 Jenkins Master 出现故障时，Kubernetes 会自动创建一个新的 Jenkins Master 容器，并且将 Volume 分配给新创建的容器，保证数据不丢失，从而达到集群服务高可用。
动态伸缩，合理使用资源，每次运行 Job 时，会自动创建一个 Jenkins Slave，Job 完成后，Slave 自动注销并删除容器，资源自动释放，而且 Kubernetes 会根据每个资源的使用情况，动态分配 Slave 到空闲的节点上创建，降低出现因某节点资源利用率高，还排队等待在该节点的情况。
扩展性好，当 Kubernetes 集群的资源严重不足而导致 Job 排队等待时，可以很容易的添加一个 Kubernetes Node 到集群中，从而实现扩展。是不是以前我们面临的种种问题在 Kubernetes

集群环境下面是不是都没有了啊？看上去非常完美。

最后，基于jenkins+kubernetes实现CICD容器化部署方案，无论在工作流程还是资源成本上，都有一定有优势。

Argo Events入门实践

wzdushu@gmail.com (wanzi) — Wed, 07 Jul 2021 16:22:42 +0800

前面我们介绍了Argo Workflow如何安装与触发任务，这一篇主要介绍一个新工具：

ArgoEvents是什么？

Argo Events是一个事件驱动的 Kubernetes 工作流自动化框架。它支持20 多种不同的事件（例如 webhook、S3 drop、cronjob、消息队列-例如 Kafka、GCP PubSub、SNS、 SQS等）

特性：

支持来自20多个事件源和10多个触发器的事件。
能够为工作流自动化定制业务级约束逻辑。
管理从简单、线性、实时到复杂、多源事件的所有内容。
符合CloudEvents。

组件：

EventSource(类似Gateway,把消息发送给eventbus)
EventBus(事件消息队列，基于高性能分布式消息中间件NATS实现，不过看NATS官网到2023年后不再维护了，估计后期架构也会调整)
EventSensor(订阅消息队列，事件参数化并对事件过滤)

ArgoEvents部署安装

argo-events部署：

1
2

kubectl create ns argo-events
kubectl apply -n argo-events -f https://raw.githubusercontent.com/argoproj/argo-events/v1.2.3/manifests/install.yaml

argo-eventbus部署:

`1`	`kubectl apply -n argo-events -f https://raw.githubusercontent.com/argoproj/argo-events/stable/examples/eventbus/native.yaml`

RBAC账户授权

创建operate-workflow-sa账户

授权operate-workflow-sa可以在argo-events namespace下创建argo workflow任务，这个对于后边EventSensor自动化创建workflow会用到。

apiVersion: v1
kind: ServiceAccount
metadata:
  namespace: argo-events
  name: operate-workflow-sa
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: operate-workflow-role
  namespace: argo-events
rules:
  - apiGroups:
      - argoproj.io
    verbs:
      - "*"
    resources:
      - workflows
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: operate-workflow-role-binding
  namespace: argo-events
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: operate-workflow-role
subjects:
  - kind: ServiceAccount
    name: operate-workflow-sa
    namespace: argo-events

创建workflow-pods-sa账户

授权workflow-pods-sa可以在argo-events下通过workflow自动创建pod

apiVersion: v1
kind: ServiceAccount
metadata:
  namespace: argo-events
  name: workflow-pods-sa
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: workflow-pods-role
rules:
  - apiGroups:
      - ""
    verbs:
      - "*"
    resources:
      - pods
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: workflow-pods-role-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: workflow-pods-role
subjects:
  - kind: ServiceAccount
    name: workflow-pods-sa
    namespace: argo-events

ArgoEvents自动化触发任务

启动一个event-sources接受请求：

`1`	`kubectl apply -n argo-events -f https://raw.githubusercontent.com/argoproj/argo-events/stable/examples/event-sources/webhook.yaml`

注意：这里event-sources里name为example，对于实际生产环境下边创建sensor需要指定这里的名称

创建 webhook方式sensor消费请求：

apiVersion: argoproj.io/v1alpha1
kind: Sensor
metadata:
  name: webhook
spec:
  template:
    serviceAccountName: operate-workflow-sa
  dependencies:
    - name: test-dep
      eventSourceName: webhook
      eventName: example
  triggers:
    - template:
        name: webhook-workflow-trigger
        k8s:
          group: argoproj.io
          version: v1alpha1
          resource: workflows
          operation: create
          source:
            resource:
              apiVersion: argoproj.io/v1alpha1
              kind: Workflow
              metadata:
                generateName: webhook-
              spec:
                serviceAccountName: workflow-pods-sa
                entrypoint: whalesay
                arguments:
                  parameters:
                  - name: message
                    # the value will get overridden by event payload from test-dep
                    value: hello world
                templates:
                - name: whalesay
                  inputs:
                    parameters:
                    - name: message
                  container:
                    image: docker/whalesay:latest
                    command: [cowsay]
                    args: ["{{inputs.parameters.message}}"]
          parameters:
            - src:
                dependencyName: test-dep
              dest: spec.arguments.parameters.0.value

参考：https://raw.githubusercontent.com/argoproj/argo-events/stable/examples/sensors/webhook.yaml

forward本地请求到远端：

`1`	`kubectl -n argo-events port-forward <name-of-event-source-pod> <local port>:12000`

往event-sources筛数据：

`1`	`curl -d '{"message":"ok"}' -H "Content-Type: application/json" -X POST http://localhost:12000/example`

至此，通过ArgoEvents就可以自动化创建workflow任务了

Argo Worflow实践一安装部署

wzdushu@gmail.com (wanzi) — Fri, 07 May 2021 16:22:42 +0800

简介&架构

Argo Workflows是一个开源容器级别工作流引擎，用于在Kubernetes上协调并行作业。 Argo Workflows通过抽象Kubernetes CRD（自定义资源定义）来实现整个架构功能，比如Workflow Template、Workflow、Cron Workflow。

Argo workflow能做什么？

定义工作流，工作流中的每个步骤都是一个容器。
将多步骤工作流建模为一系列任务，或者使用有向无环图（DAG）捕获任务之间的依存关系。
使用Kubernetes上的ArgoWorkflow，可以在短时间内轻松运行用于计算机学习或数据处理的计算密集型作业。
无需配置复杂的软件开发产品，即可在Kubernetes上本地运行CI / CD管道。

Argo workflow有哪些功能?

Workflow ：调用多个工作流模版进行任务编排，通过不同顺序来执行，
Workflow Template：Workflow的模版，是对workflow的一种定义，因此workflow template内部或者集群其他workflow和workflow template都可以调用。
Cluster Workflow Template：集群级别Workflow Template，通过clusterrole角色授权可以访问集群所有namespace
Cron Wrokflow：任务计划类型工作流，相当于高级版的k8s cronjob。

安装配置

安装argo workflow

这里我们安装的稳定版本2.12.10，整个安装过程会配置service account、role、ClusterRole、deployment等

1
2

kubectl create ns argo
kubectl apply -n argo -f https://raw.githubusercontent.com/argoproj/argo/v2.12.10/manifests/install.yaml

设置Ingress集群外部访问

由于我们的集群环境ingress controller采用的是traefik，而argo workflow默认内部访问的方式是通过https访问，因此我这里只有添加相关注解(annotations)才能转发请求到argo-server

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: traefik
    traefik.ingress.kubernetes.io/redirect-entry-point: https
  name: argo-server
  namespace: argo
spec:
  rules:
  - host: argo.test.cn
    http:
      paths:
      - backend:
          serviceName: argo-server
          servicePort: web
        path: /
status:
  loadBalancer: {}

集群外部访问：https://argo.test.cn

workflow简单测试

这里我们以hello world为例子测试：

# argo submit -n argo --watch https://raw.githubusercontent.com/argoproj/argo-workflows/master/examples/hello-world.yaml
Name:                hello-world-4mffd
Namespace:           argo
ServiceAccount:      default
Status:              Pending
Created:             Fri May 07 16:11:25 +0800 (now)
Name:                hello-world-4mffd
Namespace:           argo
ServiceAccount:      default
Status:              Pending
Created:             Fri May 07 16:11:25 +0800 (now)
Name:                hello-world-4mffd
Namespace:           argo
ServiceAccount:      default
Status:              Running
Created:             Fri May 07 16:11:25 +0800 (now)
Started:             Fri May 07 16:11:25 +0800 (now)
Duration:            0 seconds

STEP                  TEMPLATE  PODNAME            DURATION  MESSAGE
 ◷ hello-world-4mffd  whalesay  hello-world-4mffd  0s
Name:                hello-world-4mffd
Namespace:           argo
ServiceAccount:      default
Status:              Running
Created:             Fri May 07 16:11:25 +0800 (10 seconds ago)
Started:             Fri May 07 16:11:25 +0800 (10 seconds ago)
Duration:            10 seconds

STEP                  TEMPLATE  PODNAME            DURATION  MESSAGE
 ◷ hello-world-4mffd  whalesay  hello-world-4mffd  10s       ContainerCreating
Name:                hello-world-4mffd
Namespace:           argo
ServiceAccount:      default
Status:              Succeeded
Conditions:
 Completed           True
Created:             Fri May 07 16:11:25 +0800 (2 minutes ago)
Started:             Fri May 07 16:11:25 +0800 (2 minutes ago)
Finished:            Fri May 07 16:14:18 +0800 (now)
Duration:            2 minutes 53 seconds
ResourcesDuration:   1m18s*cpu,1m18s*memory

STEP                  TEMPLATE  PODNAME            DURATION  MESSAGE
 ✔ hello-world-4mffd  whalesay  hello-world-4mffd  2m

# argo list -n argo
NAME                STATUS      AGE   DURATION   PRIORITY
hello-world-4mffd   Succeeded   3m    2m         0

# argo logs -f hello-world-4mffd -n argo
hello-world-4mffd:  _____________
hello-world-4mffd: < hello world >
hello-world-4mffd:  -------------
hello-world-4mffd:     \
hello-world-4mffd:      \
hello-world-4mffd:       \
hello-world-4mffd:                     ##        .
hello-world-4mffd:               ## ## ##       ==
hello-world-4mffd:            ## ## ## ##      ===
hello-world-4mffd:        /""""""""""""""""___/ ===
hello-world-4mffd:   ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ /  ===- ~~~
hello-world-4mffd:        \______ o          __/
hello-world-4mffd:         \    \        __/
hello-world-4mffd:           \____\______/

Gitlab runner配置ceph s3

wzdushu@gmail.com (wanzi) — Fri, 26 Mar 2021 17:22:42 +0800

对于前端项目Npm构建的时候，经常拉取前端库耗时比较长，另外不同的job之间复用也是一个问题，无论是artifacts或者cache最终我们需要持久化复用文件，这里我们以cache为例

注意：这里的Gitlab runner是采用helm chart方式部署到k8s集群，runner部署忽略；需要提前准备ceph s3的密钥对，用于配置accesskey和secretkey

创建k8s secret

给后边Gitlab Runner连接ceph s3使用。

apiVersion: v1
data:
  accesskey: N1NMT0hIRzYxddfsgxVzVssddfsdY=
  secretkey: d25Uc0NDQVdsfsdUkssCQ1VsdEwxeUsdsNwb2R4TnRzZDliTG1DTUN6cQ==
kind: Secret
metadata:
  name: gitlab-runner-s3
  namespace: gitlab-managed-apps
type: Opaque

helm部署gitlab runner

具体Gitlab helm chart参考：https://gitlab.com/gitlab-org/charts/gitlab-runner.git，修改helm chart目录下values.yaml内容如下：

cache:
  ## General settings
  cacheType: s3
  cachePath: "devops" #指定ceph s3缓存路径，这里我们以部门来区分
  cacheShared: true
   
  ## S3 settings
  s3ServerAddress: "ops-rgw.test.cn"
  s3BucketName: "runners-cache"
  s3BucketLocation:
  s3CacheInsecure: true
  secretName: "gitlab-runner-s3"

更新helm配置

1
2

cd gitlab-runner
helm upgrade   runner-devops -f values.yaml -n gitlab-runner .

测试gitlab CI任务

配置gitlab Ci，修改.gitlab-ci.yaml，这里以前端项目构建为例：

stages:
  - Build
   
build-and-deploy:
  image: registry.test.cn/devops/node:latest
  stage: Build
  cache:
    key: devops-vue
    paths:
      - node_modules/
      - .yarn
  tags:
    - devopstest
  script:
    - yarn config set registry https://r.cnpmjs.org
    - yarn config set @test:registry https://npm.test.cn/
    - yarn --pure-lockfile --cache-folder .yarn --network-timeout 600000
    - yarn build
  when: always

Gitlab CI触发构建任务以后，我们观察JOB构建任务实时情况，这时缓存文件已经上传到ceph s3，后期再构建编译就大大提高了效率！

64 Creating cache devops-vue-4...
65 node_modules/: found 30710 matching files and directories
66 .yarn: found 34390 matching files and directories 
67 Uploading cache.zip to https://ops-rgw.test.cn/runners-cache/devops/project/4187/devops-vue-js-starter-4
68 Created cache
70Cleaning up file based variables
00:00
72 Job succeeded

ArgoCD配合Jenkins Pipeline自动化部署应用

wzdushu@gmail.com (wanzi) — Wed, 29 Jul 2020 15:22:42 +0800

创建helm仓库

首先，创建基础Helm模版仓库：

`1`	`helm create template .`

对于实际的部署中，需要根据自己的业务定制自己的helm模版，我这里直接使用我们内部自定义的通用模版，方便快速部署;另外也可以参考bitnami家维护的helm chart(https://github.com/bitnami/charts/tree/master/bitnami)

jenkins凭证配置argocd token信息

配置jenkins pipeline编写

这里我们以gotest项目(https://code.test.cn/hqliang/gotest)为例

pipeline {
    environment {
    GOPROXY = "http://repo.test.cn/repository/goproxy/"
    HUB_URL = "registry.test.cn"
        ARGOCD_SERVER="qacd.test.cn"
    ARGOCD_PROJ="test-project"
        ARGOCD_APP="gotest"
    ARGOCD_REPO="https://code.test.cn/devops/cicd/qa.git"
    ARGOCD_PATH="devops/gotest"
    ARGOCD_CLUSTER="https://172.16.19.250:8443"
        ARGOCD_NS="default"
    }
 
    agent {
        node {
            label 'aiops'
        }
    }
 
    stages {      
        stage ('Docker_Build') {
            steps {
        withCredentials([[$class: 'UsernamePasswordMultiBinding',
                credentialsId: '12ff2942-972c-4df3-8d2d-2cfcb25e00de',
                usernameVariable: 'DOCKER_HUB_USER',
                passwordVariable: 'DOCKER_HUB_PASSWORD']]) {
                sh '''
                TAG=$(git describe --tags  `git rev-list --tags --max-count=1`)
                            docker login registry.test.cn -u ${DOCKER_HUB_USER} -p ${DOCKER_HUB_PASSWORD}
                            make docker-all VERSION=$TAG
                    '''
            }
            }
        }
 
        stage ('Deploy_K8S') {
             steps {
                     withCredentials([string(credentialsId: "qa-argocd", variable: 'ARGOCD_AUTH_TOKEN')]) {
                        sh '''
            TAG=$(git describe --tags  `git rev-list --tags --max-count=1`)
            # create app
            ARGOCD_SERVER=$ARGOCD_SERVER argocd --grpc-web app create $ARGOCD_APP --project $ARGOCD_PROJ --repo $ARGOCD_REPO --path $ARGOCD_PATH --dest-namespace  $ARGOCD_NS --dest-server $ARGOCD_CLUSTER --upsert --insecure
                        # deploy app
                        ARGOCD_SERVER=$ARGOCD_SERVER argocd --grpc-web app set $ARGOCD_APP -p containers.tag=$TAG  --insecure
                        # Deploy to ArgoCD
                        ARGOCD_SERVER=$ARGOCD_SERVER argocd --grpc-web app sync $ARGOCD_APP  --force --insecure
                        ARGOCD_SERVER=$ARGOCD_SERVER argocd --grpc-web app wait $ARGOCD_APP  --timeout 600 --insecure
                        '''
               }
            }
        }
    }
}

配置gitlab webhook触发Jenkins

jenkins配置触发构建

gitlab配置webhook

推送tag到远端分支

jenkins pipeline构建

到jenkins查看pipeline构建结果如下：

docker自动打包并推送到harbor上

创建Argo应用并同步部署到k8s集群

最后查看同步状态，途中说明已经正常发布到k8s集群：

我们到argocd的dashboard看一下应用流程图，应用各个组件已经正常运行。

通过kubectl获取已经创建好的资源：

最后验证一下业务是否可以访问呢，访问http://gotest.test.cn/df 即可查看容器磁盘空间

总结&优化

无论通过jenkins的pipeline还是通过gitlab CI我们都可以更好的整合argocd,最终实现一键部署业务应用.

argocd部署deployment出现: no space left on device

wzdushu@gmail.com (wanzi) — Mon, 18 May 2020 10:22:42 +0800

故障现象

上午通过argocd部署几个业务应用，部署了2个以后，第三方死活部署不成功，相同的配置，知识集群不一样，怎么会出现这样的问题呢？

于是查看了下日志,如下：

1
2
3

  Warning  Failed     1m                kubelet, 172.16.25.13  Error: Error response from daemon: error creating overlay mount to /var/lib/docker/overlay2/ba37165607862efb350093e5e287207e2547759fd81dc4e5e356a86ac5e28324-init/merged: no space left on device
  Warning  Failed     1m                kubelet, 172.16.25.13  Error: Error response from daemon: error creating overlay mount to /var/lib/docker/overlay2/f69b62f360fc2a94487aca041b08d0929810beab0602e0ec8b90c94b2e893337-init/merged: no space left on device
  Warning  Failed     48s               kubelet, 172.16.25.13  Error: Error response from daemon: error creating overlay mount to /var/lib/docker/overlay2/a8d20a44183b39ae989eee8a442960124ff23844482f726ea7ab39a292aecbb3-init/merged: no space left on device

解决方法

排查磁盘空间,发现没有满

1
2
3

root@gpu613:~# df -Th /
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/sda2      ext4  1.8T  359G  1.3T  22% /

经过谷歌，发现可能是inotify watch 耗尽导致

1
2

#cat /proc/sys/fs/inotify/max_user_watches
8192

尝试修改fd watch的目录数量

1
2

echo "fs.inotify.max_user_watches=100000" >> /etc/sysctl.conf
sysctl -p

重新发送argocd sync同步应用，发现这次成功创建了deployment,果真是这货的原因.

ArgoCD添加多集群

wzdushu@gmail.com (wanzi) — Tue, 05 May 2020 15:22:42 +0800

生成argocd管理用户token

登陆dashboard，settings–>Accounts–>admin–>Generate New 生成后，请记录下token信息，类似如下：

fyJhbGciOiJ3UzI1NiIsInR5cCI6IkpXVCJ9.eyJqdGkiOiI2OWI0M2M0Mi01MmZiLTRlZmItODIxOC0yOWU3NGM5MWI0NDIiLCJpYXQiOjE1OTUzMTEx3zQsImlzcyI6ImFyZ29jZCIsIm5iZiI6MTU5NTMxMTE3NCwic3ViIjoib3duZXIifQ.9u4XzArEeaz7G2Q2TWusnTkakEmq9BYDAUHr3dC6wG5

配置argocd config

对于开启了https认证的argocd在添加集群的时候比较鸡肋，需要登陆到server端POD里进行配置，具体如下：

# cat ~/.argocd/config
contexts:
- name: argocd-server.argocd
  server: qacd.test.cn
  user: argocd-server.argocd
current-context: argocd-server.argocd
servers:
- grpc-web-root-path: ""
  insecure: true
  server: qacd.test.cn
users:
- auth-token: xxxxxx #这里就是第一步生成token信息
  name: argocd-server.argocd

配置kubeconfig

具体配置这里忽略，请参考以往文档，前提要能访问集群并且是集群管理员，这里配置CONTEXT为idc-bj-k8s

添加集群

# argocd  --grpc-web cluster  add  idc-bj-k8s  --kubeconfig ~/.kube/config
INFO[0000] ServiceAccount "argocd-manager" already exists in namespace "kube-system"
INFO[0000] ClusterRole "argocd-manager-role" updated
INFO[0000] ClusterRoleBinding "argocd-manager-role-binding" updated
Cluster 'https://172.16.16.250:8443' added
# argocd --grpc-web cluster list
SERVER                          NAME        VERSION  STATUS      MESSAGE
https://172.16.16.250:8443      idc-bj-k8s  1.14     Successful
https://kubernetes.default.svc              1.14     Successful

目前看北京idc集群已经添加到argocd里,后边就可以往集群里部署应用啦啦

删除集群

# argocd --grpc-web  cluster rm https://172.16.16.250:8443
# argocd --grpc-web cluster list
SERVER                          NAME        VERSION  STATUS      MESSAGE
https://kubernetes.default.svc              1.14     Successful

ArgoCD安装部署

wzdushu@gmail.com (wanzi) — Fri, 01 May 2020 15:22:42 +0800

安装部署

ArgoCD的部署非常简单，安装官方的部署方法(HA模式：

1
2

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/v1.5.2/manifests/ha/install.yaml

可以按照需求调整部署文件，待pod顺利启动后

# kubectl  -n argocd get pod
NAME                                             READY   STATUS    RESTARTS   AGE
argocd-application-controller-66fbf66657-ghf2c   1/1     Running   0          6d17h
argocd-application-controller-66fbf66657-gpm7d   1/1     Running   0          6d17h
argocd-application-controller-66fbf66657-tr5kd   1/1     Running   0          6d17h
argocd-dex-server-5c5f986596-c8ftv               1/1     Running   0          9d
argocd-redis-ha-haproxy-69c6df79c6-2fxd6         1/1     Running   0          9d
argocd-redis-ha-haproxy-69c6df79c6-mksg2         1/1     Running   0          9d
argocd-redis-ha-haproxy-69c6df79c6-wq57f         1/1     Running   0          9d
argocd-redis-ha-server-0                         2/2     Running   0          9d
argocd-redis-ha-server-1                         2/2     Running   0          9d
argocd-redis-ha-server-2                         2/2     Running   0          9d
argocd-repo-server-76bbb56cc7-d8fp5              1/1     Running   0          7d
argocd-repo-server-76bbb56cc7-qvl5z              1/1     Running   0          7d
argocd-repo-server-76bbb56cc7-xqrfn              1/1     Running   0          7d
argocd-server-6464c7bcd-fgktr                    1/1     Running   0          6d19h
argocd-server-6464c7bcd-jkqdb                    1/1     Running   0          6d19h
argocd-server-6464c7bcd-nfdwn                    1/1     Running   0          6d19h

配置ingress访问argocd

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: argocd-server-ingress
  namespace: argocd
  annotations:
    kubernetes.io/ingress.class: traefik
    traefik.ingress.kubernetes.io/redirect-entry-point: https
spec:
  rules:
    - host: cd.testcn
      http:
        paths:
        - backend:
            serviceName: argocd-server
            servicePort: https
          path: /

通过https://cd.test.cn/访问argocd，默认本地用户名是admin，密码是其中一个pod的name，获取密码使用如下方法：

`1`	`# kubectl get pods -n argocd -l app.kubernetes.io/name=argocd-server -o name \| cut -d'/' -f 2`

用户管理

argocd默认使用本地用户，可以支持ldap。本地用户管理使用修改argocd-cm这个configmap方式，新增用户如下：

apiVersion: v1
kind: ConfigMap
metadata:
  annotations:
  labels:
    app.kubernetes.io/name: argocd-cm
    app.kubernetes.io/part-of: argocd
  name: argocd-cm
  namespace: argocd
data:
  accounts.chlai: apiKey,login  #允许用户login和生成aipkey
  users.anonymous.enabled: "true"  #允许匿名用户登陆。

修改完保存立即生效。

系统默认的role有readonly和admin两个，授予用户admin的权限方法是修改argocd-rbac-cm这个configmap：

apiVersion: v1
kind: ConfigMap
metadata:
  labels:
    app.kubernetes.io/name: argocd-rbac-cm
    app.kubernetes.io/part-of: argocd
  name: argocd-rbac-cm
  namespace: argocd
data:
  policy.csv: |-
    g, chlai, role:admin
  policy.default: role:readonly  #匿名登陆默认使用readonly角色。

生成登陆密码需要使用admin用户cli方式login server，通过argocd account update-password命令修改：

argocd login <argocd-server>
argocd account list
argocd account update-password \
  --account <name> \
  --current-password <current-admin> \
  --new-password <new-user-password>

使用新的用户密码登陆argocd web ui。

ArgoCD UI界面来创建应用

点击“+ NEW APP”按钮创建应用；

填写应用名称：guestbook；项目：default；同步策略：手动；

配置来源。这里配置的是Git ，代码仓库的URL配置为 Github上的项目地址为：https://github.com/argoproj/argocd-example-apps.git；Revision选择：HEAD；项目路径选择：guestbook；

选择应用部署的目标集群：https://kubernetes.default.svc ，因为此次的Argo CD部署在Kubernetes集群当中，默认Argo CD已经帮我们添加好当前所在的Kubernetes集群，直接使用即可。Namespace选择：my-app。Namespcae可以在Kubernetes集群上使用# kubectl create namespace my-app 命令来创建；

填写完成后，点击 “CREATE” 按钮进行创建；

由于尚未部署应用程序，并且尚未创建Kubernetes资源，所以Status还是OutOfSync状态，因此我们还需要点击 “SYNC”按钮进行同步（部署）。同时也可以安装argocd客户端，使用Argo CD CLI进行同步：# argocd app sync guestbook

应用创建完成，处于“未同步”状态，手动同步应用，开始部署应用

等待应用创建完成

在Kubernetes集群中查看应用

基于K8S部署gitlab-runner

wzdushu@gmail.com (wanzi) — Thu, 14 Nov 2019 17:22:42 +0800

部署gitlab-runner

这里基于helm部署，参考：https://gitlab.com/gitlab-org/charts/gitlab-runner.git

`1`	`helm install --namespace gitlab-managed-apps --name k8s-gitlab-runner -f values.yaml`

注意：values.yaml文件需要设置privileged: true

构建基础镜像(docker in docker)

Dockerfile文件内容：

FROM docker:19.03.1-dind
WORKDIR /opt
RUN echo "nameserver 114.114.114.114" >> /etc/resolv.conf
RUN sed -i 's/dl-cdn.alpinelinux.org/mirrors.aliyun.com/g' /etc/apk/repositories
RUN apk update
RUN apk upgrade
RUN apk add g++ gcc make docker docker-compose  git

构建镜像并推送到harbor

1
2

docker build -t registry.test.cn/devops/docker-tool:19.03.1  .
docker push  registry.test.cn/devops/docker-tool:19.03.1

Gitlab-CI测试

.gitlab-ci.yml文件内容如下:

image: registry.test.cn/devops/docker-tool:19.03.1

variables:
  REPO_NAME: gitlab.test.cn/xxx/xxxx
  DOCKER_DRIVER: overlay2
  DOCKER_TLS_CERTDIR: ""
  
before_script:
  - mkdir -p $GOPATH/src/$(dirname $REPO_NAME)
  - ln -svf $CI_PROJECT_DIR $GOPATH/src/$REPO_NAME
  - cd $GOPATH/src/$REPO_NAME

stages:
  - deploy

deploy:
  tags:
    - k8s-gitlab-runner #指定runner
  only:
    - tags
  stage: deploy
  services:
    - registry.test.cn/devops/docker-tool:19.03.1
  script:
    - export DOCKER_HOST='tcp://localhost:2375'
    - docker login -u "$Harbor_bce_user" -p "$Harbor_ecs_passwd" $Harbor_ecs_address #gitlab后台设置统一变量
    - make deploy VERSION=$CI_COMMIT_REF_NAME #根据git tag构建镜像

基于Docker-compose搭建jenkins

wzdushu@gmail.com (wanzi) — Mon, 11 Nov 2019 16:22:42 +0800

docker-compose配置

version: '2'
 
services:
  jenkins:
    image: jenkins/jenkins:latest
    restart: always
    environment:
      JAVA_OPTS: "-Dorg.apache.commons.jelly.tags.fmt.timeZone=Asia/Shanghai -Djava.awt.headless=true -Dmail.smtp.starttls.enable=true"
    ports:
      - "80:8080"
      - "50000:50000"
    volumes:
      - '/ssd/jenkins:/var/jenkins_home'
      - '/var/run/docker.sock:/var/run/docker.sock'
      - '/etc/localtime:/etc/localtime:ro'
    dns: 223.5.5.5
    networks:
      - extnetwork
networks:
   extnetwork:
      ipam:
         config:
         - subnet: 172.255.0.0/16

启动服务

`1`	`docker-compose up -d`