使用Github Actions建立CI/CD工做流

这个文章以一个简单的Nodejs应用为例，示例如何使用Github Actions来自动构建，测试和部署一个应用．

<!-- more -->

什么是Github Actions

首先简单介绍下什么是Github Actions？　Github Actions是Github官方提供的一个与Github集成在一块儿的CI/CD工具，使用Github Actions能够很是容易地自动化你的全部软件工做流程，包括持续集成（CI）和持续发布（CD）．

不过要使用Github Actions，你须要将你的项目代码库放在Github上，而后为代码库配置相应的工做流（Workflows）．　　

Actions Runner

使用Github Actions来执行工做流任务，还须要一个可执行的环境，Actions Runner就是提供这样的环境，Github Actions支持两种类型的Runner:

• Github-Hosted Runner : 由Github官方提供和维护的Runner服务器，不须要用户本身维护和更新，有支持Linnux，Windows，macOS环境的构建
• Self-Hosted Runner : 用户本身使用本地机器，云服务器安装Actions应用，用户能够自定义硬件，软件等需求

Actions

在Github Actions中有一个Action的概念，Actions是一个独立的任务，你能够组合这些任务成为要完成一个工做的步骤.　　

在工做步骤中，你能够本身写执行命令组成Action，也能够直接使用Github社区提供的针对一个写公共任务的Actions，能够到Github市场查找社区或者其余开发人员编写的Actions．　　

例如一个最经常使用的Action - checkout，可用来检出代码库：

- uses: actions/checkout@v2

除了以上概念以外，Github Actions还有其余概念须要了解，具体可参考　(https://help.github.com/en/ac...

Nodejs应用示例

接下来，咱们就那个简单的nodejs应用来看看如何使用Github Actions建立CI/CD的流程．

首先，你的项目代码库须要放在Github上，例如　https://github/mengzyou/hello... ，访问你的代码库主页，而后点击 Actions 进入Actions页面．

根据你的代码库的语言类型，Github推荐了一些Workflow的模板，这里咱们将使用Nodejs的模板　　

直接点击 Set up this workflow 来应用这个模板，而后Github会直接打来Web编辑器来编辑这个模板文件

你能够直接使用该文件，也能够修改，添加须要的Actions，完成以后能够点击　Start commit 按钮来提交Workflow文件，Github会自动为代码库建立目录　.github/workflows/，以及把该文件放在该目录下，例如　.github/workflows/nodejs.yml .　　

提交以后，Github Actions就会根据Workflow的内容开始运行相应的工做．

建立一个执行测试CI工做流

其实咱们也能够直接编辑本地代码库，添加目录　.github/workflows/，以及建立相应的Workflows配置文件，例如咱们建立一个　.github/workflows/nodejs.yml　　

name: Node.js CI

on:
  push:
    branches:
      - master

jobs:
  build:

    runs-on: ubuntu-latest
    container: node:12.16-alpine

    steps:
      - name: Checkout repository code
        uses: actions/checkout@v2
      - name: Cache node modules
        uses: actions/cache@v1
        env:
          cache-name: cache-node-modules
        with:
          path: ./node_modules
          key: ${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }}
          restore-keys: |
            ${{ runner.os }}-build-${{ env.cache-name }}-
            ${{ runner.os }}-build-
            ${{ runner.os }}-
  
      - name: Install Dependencies
        run: npm install
  
      - name: Test
        run: npm test
        env:
          CI: true

咱们就定义了一个Workflow，并命名为 Node.js CI，将在master分支发生push时执行．而且定义了一个名为　build 的工做（job），该工做将使用Github-Hosted Runner（ubuntu-latest，Github-Hosted Runner会虚拟化一个相应的操做系统环境），咱们也会使用容器来执行相应的步骤，这里使用了Docker容器镜像node:12.16-alpine.　　

setps定义将要执行的没有个步骤，能够给每一个步骤命名，也能够直接调用相应的Actions，或者直接使用　－run 来执行命令．　　
上面的步骤中，有使用　actions/checkout@v2 来拉去代码库，也有使用　actions/cache@v1 来建立使用缓存（使用缓存可加速工做流的执行），而后使用直接行命令　npm install 和　npm test　的步骤．　　

当咱们编写好以后，建立一个提交，而后Push到Github上master分支，就会出发一次定义的CI流程，以下图所示

咱们能够经过Github代码库的Actions页面查看Workflow执行的状态和结果，也能够查看执行的日志．

在上面的示例中，咱们的工做流里只有一个Job，就是测试代码，咱们能够添加更多的Job来只想其余任务．例如打包咱们的应用，部署咱们的应用．

下面咱们就添加更多工做来完成咱们的整个CI/CD工做流．

添加一个工做打包应用的Docker镜像

咱们编辑　.github/workflows/nodejs.yml 文件，添加如下内容　　

package:
    runs-on: ubuntu-latest
    needs: build
    steps:
      - name: Checkout repository code
        uses: actions/checkout@v2
      - name: Build & Push container image
        uses: mr-smithers-excellent/docker-build-push@v2
        with:
          image: mengzyou/hellonode
          tag: latest
          registry: docker.io
          username: ${{ secrets.DOCKERHUB_USERNAME }}
          password: ${{ secrets.DOCKERHUB_TOKEN }}

咱们添加两一个job - package，这个job将运行在Github-Hosted Runner（ubuntu-latest）上，needs 表示该job须要 build　job成功执行完成以后才执行．
包括了两个步骤，拉取代码库，而后是使用 mr-smithers-excellent/docker-build-push@v2 Action来执行容器镜像的构建和推送．　　
这个Action中，咱们还使用到了Github Actions的Secrets，Secrets能够配置一些敏感的变量，到Github代码库设置的Secrets进行配置

这里咱们配置了推送Docker镜像到Dokcer Hub须要的用户名和访问凭证. 对于Docker Hub，推荐使用Docker Hub Access Token做为访问密码．

咱们将Workflow提交到master分支后，在地一个build工做以后，就发触发这个job，打包镜像并推送到Docker Hub.　　

添加一个工做来自动部署

接下来，为了完成整个CI/CD的演示，咱们再添加一个job，名为　deploy．　对于这个job的执行，咱们须要使用一个Self-Hosted的Runner．

访问代码库的Github界面，点击Settings，而后点击左侧边栏的Actions，再点击Add runner按钮

按照弹出来的指导，在须要部署应用的服务器上安装 action-runner，这里咱们选择的是在一个Linux上安装，成功启动runner应用以后，会链接Github服务，在Gihub的Self-hosted runners下能看到添加的runner的状态，这样添加的一个Self-hosted runner会具备标签['self-hosted','linux','x86']，这些标签将会用于job选择合适runner来执行．

添加了Self-hosted　Runner以后，咱们就能够在Workflow里添加相应的job了　　

deploy:
    runs-on: [self-hosted,linux]
    needs: package
    env:
      CONTAINER_IMAGE: mengzyou/hellonode
      CONTAINER_NAME: webapps_hellonode
    steps:
      - name: Docker pull image
        run: docker image pull $CONTAINER_IMAGE
      - name: Docker stop container
        run: docker container stop $CONTAINER_NAME
      - name: Docker remove container
        if: always()
        run: docker container rm -f $CONTAINER_NAME
      - name: Docker run container
        if: always()
        run: docker container run --name $CONTAINER_NAME -d -p 8000:3000 $CONTAINER_IMAGE
      - name: Prune images
        if: always()
        run: docker image prune -f    # remove the dangling images

这里，咱们将 runs-on　设置为　[self-hosted,linux]　来选择运行的Runner服务器，而后该job须要　package job 成功完成以后才会执行．　　
咱们还配置了两个Job（．job.env）范围内的变量来使用咱们的容器镜像和名字．而后包含了如下执行步骤：　　

1. 从Docker Hub拉取上一个Job构建出来的容器镜像
2. 中止运行的容器
3. 删除以前的应用容器
4. 使用新的镜像运行一个新的应用容器
5. 清理旧的容器镜像

提交代码，Push到master分支，这样一个包含３个Jobs的Workflow就会自动执行，若是在任何一个Job中只想错误，都会中止后续的Jobs，而且给出反馈．

总结

上面经过为一个简单的nodejs应用添加了Github Actions来完成了一个构建，打包，部署的CI/CD流程．经过使用Github Actions，能够很容易地为咱们放在Github上的项建立CI/CD流程，管理软件开发的生命周期（SDLC）．　　

Gihhub Actions相似于Gitlab的Gitlab-CI，以及［Jinkens］(https://jenkins.io/zh/)，还有不少第三方的CI/CD服务．

Github Actions是Github原生支持的，所以对于代码库管理在Github上的组织和用户，更容易使用．

参考

https://help.github.com/en/ac...