工程提速,自动部署

135 阅读7分钟

持续集成需要长久的不断的完善规范,但自动部署可是能够立竿见影的见效的东西了。

这个东西虽然是运维的工作,但在实际生活中,我们每个开发者都可以学一手。

通过自动化部署,我们可以省去很多运维的人力。

正文

自动化部署,也有个说法叫CD(CD-continuous deployment,持续部署)

这两者可能在细分的含义上有点区别,但总的来说,这都是为了工程提速提出来的概念。

严格意义上来说,自动化部署是CD(CD-continuous deployment,持续部署)的一种手段。

目前,市面上已有的手段我这里稍微列举下。

  • github提供git flow,通过git Action实现自动化部署
  • 国内,阿里云的云效平台,腾讯云的coding,码云平台都有自己的自动化流程工具
  • gitlab提供的工作流,不过这个流程需要用户需要懂很多自动化部署的工具,如docker,JENKINS等。

市面上常规的手段大多是以上介绍的内容,大多通过以上手段,搭建一套自动化部署的管线,缩减手动部署的时间和人力损耗。

通过让机器去处理重复事务的手段,让开发者更专注于开发和思考,不必被这些繁琐重复的事情所拖累。

持续部署

持续部署,也就是CD(CD-continuous deployment)

是基于某种工具或平台实现代码自动化的构建、测试和部署到线上环境以实现交付高质量的产品。

持续部署在某种程度上代表了一个开发团队的更新迭代速率。

持续部署是持续交付的下一步,指的是代码通过评审以后,自动部署到生产环境。

持续部署的目标是,代码在任何时刻都是可部署的,可以进入生产阶段。

注:持续部署的前提是能自动化完成测试、构建、部署等步骤。

个人DevOps

DevOps这个词也是最近两年的招聘要求和社区中频繁出现。

这个词如果不深究其含义的话,其实就是Development(开发)和Operation(运维)组合而成的新词汇。

当然,DevOps里边的玩法不仅仅是我字面上说的这么简单,大多数公司都是用gitlab部署了自己的工作流程,然后需要自己用docker,JENKINS等方式搭建自己的自己自动化流程。

这个流程较为麻烦,我们今天这里不去详解用docker搭建自动化流水管线那一套,那个太过麻烦,很多人如果不对安全有有要求的话,未必用的上。

本次,通过github Action实现文档的自动化发布,以此为例,大家可以将这套流程应用在码云,云效等平台。

毕竟,这些成熟的自动化流程管线大多相差不多,都很好用。

Github Action

参考这篇:作为前端 leader,怎么快速搭建多环境CICD自动化部署? - 掘金 (juejin.cn)

我通过Github Action的工作流,实现了部署自动化,在部署完成后,还可以通过外部的微信机器人告诉我,具体哪个项目已经完成更新。

而且,Github Action简单易用,非常的好上手,如果你是之前没用过这种自动化部署的流程的新手,非常推荐入门使用。

功能介绍

  1. 推送主分支后,自动部署项目到服务器
  2. 部署完成后,通过公众号通知部署成功

配置脚本

这一套流程是从别人那边上边的参考文档中套过来的,基本上和HEXO博客的自动部署发布类似,写的非常清楚简单。

稳定好用,这里推荐给大家使用,如果要是有需求,其实也可以考虑用GPT帮忙写流程。

name: 更新文档到服务器

on:
  push:
    branches:
      - main

# 推送之后执行一系列的任务
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      # 获取代码
      - name: 迁出代码
        # 使用action库 action/checkout获取代码
        uses: actions/checkout@main
      # 安装Node环境

      - name: 安装node.js
        # 使用action库  actions/setup-node安装node
        uses: actions/setup-node@main
        with:
          node-version: lts/*

      # 安装依赖
      - name: 安装依赖
        run: npm install

      # 打包
      - name: 打包
        run: npm run build
      # 上传到腾讯云
      - name: 发布到腾讯云
        uses: easingthemes/ssh-deploy@main
        env:
          # 私钥
          SSH_PRIVATE_KEY: ${{ secrets.PRIVATE_KEY }}
          # SCP参数
          ARGS: '-avzr --delete'
          # 源目录
          SOURCE: 'docs/.vitepress/dist/'
          # 服务器ip
          REMOTE_HOST: ${{ secrets.REMOTE_TXHOST }}
          # 用户
          REMOTE_USER: 'root'
          # 目标地址
          # TARGET: '/var/www/html'
          TARGET: '/usr/local/lintdoc'
      # 推送信息到微信
      - name: 推送信息到微信
        uses: easychen/github-action-server-chan@main
        with:
          sendkey: ${{ secrets.SERVER_J }}
          title: '项目更新!Ciallo~(∠・ω< )⌒★'

配置KEY

在实现功能之前,我们先做一些准备,以github为例,我们需要配置项目setting中的内容。

我们进入setting > secrets and variables > Actions的目录下,设置如下三个配置项

  • PRIVATE_KEY,私钥,用来配对服务器上的公钥
  • REMOTE_TXHOST,服务器地址
  • SERVER_J,方糖服务号提供的SendKey,需要先微信关注,获取对应的SENDKEY之后,添加到github的Action中

这里可能有些新手不清楚上边说的一些概念,这里先简单解释一下,后续会专门的就这些内容出文章仔细解释这些概念。

私钥与公钥

自动化部署,我们显然不该把自己的IP扔到流程上,那么,我们也要把服务器密码放在流程上吗?

显然,这种流程不可能将密码放在流程中裸奔,如此,我们需要将密码进行一个处理,这就是我们说到的私钥公钥。

这里打个不恰当的比方,私钥是电子门卡,公钥是电子锁。

公钥作为电子锁,谁都能看到,但如果没有电子门卡,自然就无法打开电子锁。

而我们自动部署,将私钥放在流程中,每次自动部署,就是将私钥丢给公钥解锁,连接服务器之后,自动部署。

这里要注意,私钥是本人需要保存的答案,是公钥的唯一解,请注意保存。

setting安全性

有些人可能会担心,如果我写了一个开源项目,项目中配置好的key会泄露吗?

这个可以不用担心,因为在yml的文件中,写的都是你配置的key,即便别人看到你的源码,也不用担心他人会发现你的配置项的内容。

而这些开源项目的setting不会被外部访问,除了当前项目的主导者,其他人无法访问到这个项目的setting里的配置。

因此,安全性是不用担心的。

使用场景

github action 这套流程,应该是目前我看过的所有管线中最成熟的一套了。

但是,github因为不在境内,而且出于安全性的考虑,很多公司项目都不会部署在github上。

因此这套流程大多都是用来放一下个人项目,大概应用场景如下。

  1. 文档类项目,如个人博客,团队规范,使用说明等
  2. 开源项目的自动化部署,可以用来部署开源项目的Demo和wiki

结语

最近因为个人生活的问题,本来想整理更详细的,将云效平台的部署流程也放上来。

但是时间实在不允许,所以这里就简单整理了一下github的部署。

后续如果时间允许,我会整理其他类型的自动化部署方式,如果文中写的有什么不对的地方,欢迎大家在评论区中指出。

参考

GitHub Actions 文档 - GitHub 文档

前端项目自动化部署——超详细教程(Jenkins、Github Actions)

作为前端 leader,怎么快速搭建多环境CICD自动化部署?

GitHub Actions 入门教程 - 阮一峰的网络日志 (ruanyifeng.com)

打造前端自己的CI/CD集成环境 - 掘金 (juejin.cn)

DevOps是什么?只看这篇文章就够了!

DevOps概念及搭建全过程(Jenkins、Harbor、SonarQube、K8s)_devops流程-CSDN博客