浅谈 Github Action CI CD

传统流程

来自RedHat的官方解释

CI/CD 管道是为了交付新版本的软件而必须执行的一系列步骤。持续集成/持续交付（CI/CD）管道是一套专注于使用 DevOps 或站点可靠性工程（SRE）方法来改进软件交付的实践。

CI/CD 管道加入了监控和自动化来改进应用开发过程，尤其是在集成和测试阶段以及交付和部署过程中。尽管可以手动执行 CI/CD 管道的每个步骤，但 CI/CD 管道的真正价值在于自动化。

DevOps

DevOps是Development和Operations的组合

DevOps是一种重视软件开发人员（Dev）和IT运维技术人员（Ops）

通过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。具体来说，就是在软件交付和部署过程中提高沟通与协作的效率，旨在更快、更可靠的的发布更高质量的产品。

在以前的时候或者现在还有一些公司还是没有专业的运维人员, 还是由后端程序员亦或是前端程序员在本地打包完成后手动发布到生产环境。虽然不是说不行，但是时代在变迁，这种问题的弊端就迅速的浮现出来。由于每次上线都需要开发手动一步一步进行操作,那么这样必然会出现人工所造成的失误，例如博主的一个朋友在一家软件公司实习的时候，一次误操作对生产环境执行了 sudo rm -rf /*导致生产环境整个的崩溃, 所幸生产环境有备份,但是也会对公司造成一定的损失。当然在测试环境 每次的测试版本也需要这么去操作显得非常繁琐

CI CD

那么经过时间的流逝，有没有一种不需要繁琐的方式 不需要开发人员 一步一步的去参与操作。像流水线一样，自动的去完成操作呢

答案是有的 在互联网爆炸的信息时代 各种 CI CD的持续交付 持续部署工具 平台井喷式的出现

• Jenkins --- Jenkins是CI市场中最知名且最常见的名号之一 免费
• Travis CI ---- Travis CI是CI / CD生态系统中比较常见的名号之一，最初设定为开源项目，并在多年扩展之后转为闭源项目
• Circle CI ---- Circle CI能够与您当前的版本控制系统（如GitHub，Bitbucket等）集成，并在检测到变更时运行多种操作
• oneDev ---- 暂时文档不全 但是颜值非常好看
• .......等等

上述所说是 进行CI的工具

那么 有没有类似的平台让我们去操作呢

• Github
• Gitlab
• Coding （已经付费了）
• .......等等

Github Action

在 GitHub Actions 的仓库中自动化、自定义和执行软件开发工作流程。 您可以发现、创建和共享操作以执行您喜欢的任何作业（包括 CI/CD），并将操作合并到完全自定义的工作流程中。

GIthub Doc

Github Action Demo

GitHub Actions 的组件

工作流程

文档

工作流程是一个可配置的自动化过程，它将运行一个或多个作业。 工作流程由签入到存储库的 YAML 文件定义，并在存储库中的事件触发时运行，也可以手动触发，或按定义的时间表触发

1. 首先你得有一个github的仓库 并且在仓库的根目录新建一个叫做 .github的文件夹
2. 然后在此目录下新建一个 workflows的文件夹 在此文件夹里面新建一个yaml文件

事件

文档

工作流程是一个可配置的自动化过程，它将运行一个或多个作业。 工作流程由签入到存储库的 YAML 文件定义，并在存储库中的事件触发时运行，也可以手动触发，或按定义的时间表触发

例如此时我触发一个push的操作并且进行操作的是master分支就会运行这个流水线作业

Jobs

文档

例如这就是我的一整个 GitHub 的 Job作业

包括了 自动集成代码 自动进行打包 自动发布到dockerHub 自动部署到服务器的操作

uses 用的是大佬写好的 插件

例如下文就用到

• actions/checkout@v2
• actions/cache@v2
• docker/build-push-action@v2
• docker/setup-buildx-action@v1
• 。。。。 等

name 是在执行是 日志打印的名字

run 则是在执行具体的命令

在我们需要输入密钥 密码等私人信息的时候 可以去仓库设置 Actions secrets

做为全局变量来进行引用 例如secrets.*

jobs:
  compile:
    runs-on: ubuntu-latest
    name: Running Java ${{ matrix.java }} compile
    steps:
      - uses: actions/checkout@v2
      - name: Set up JDK 1.8
        uses: actions/setup-java@v1
        with:
          java-version: 1.8
      - name: 缓存 Maven 依赖
        uses: actions/cache@v2
        with:
          path: ~/.m2/repository
          key: ${{ runner.os }}-maven-${{ hashFiles('**/pom.xml') }}
          restore-keys: |
            ${{ runner.os }}-maven-
      - name: 编译代码
        run: mvn compile
      - name: Deploy the JAR file to the remote server
        uses: actions/checkout@v2
      - name: 设置JDK版本为1.8
        uses: actions/setup-java@v1
        with:
          java-version: 1.8
      - name: 用Maven打成Jar包
        run: mvn -B package --file pom.xml -Dmaven.test.skip=true
      - name: 设置Docker USER 和 TOKEN
        uses: docker/login-action@v1
        with:
          username: ${{ secrets.DOCKER_HUB_USERNAME }}
          password: ${{ secrets.DOCKER_HUB_ACCESS_TOKEN }}
      - name: 设置Docker Buildx
        id: buildx
        uses: docker/setup-buildx-action@v1
      - name: 构建以及推送镜像
        id: docker_build
        uses: docker/build-push-action@v2
        with:
          context: ./
          file: ./Dockerfile
          platforms: |
            linux/amd64
            linux/arm64/v8
          push: true
          tags: ${{ secrets.DOCKER_HUB_USERNAME }}/demoaction:latest
      - name: ssh连接服务器执行脚本
#        if: always()
        uses: fifsky/ssh-action@master
        with:
          command: | # 命令中的 & 表示在后台运行进程
            sh start.sh
          host: ${{ secrets.HOST }}
          user: root
          key: ${{ secrets.PRIVATE_KEY}}
          args: "-tt -vvv"

黑科技

假设你的docker原始镜像是有 amd arm64 这种架构的话

 platforms: |
     linux/amd64
     linux/arm64/v8

就可以这样写那么发布的时候你就会发现 DockerHub仓库有两种架构的镜像

当然你也可以在 GitHub指定的Ubuntu容器里面再次指定一个qemu容器进行你想要自定义的操作