本项目代码已开源，具体见：
后端工程：express-blog-backend
数据库初始化脚本：关注公众号程序员白彬，回复关键字“博客数据库脚本”，即可获取。
前言
作为前端开发，你或许开发过很多酷酷的界面效果，做过很多复杂的产品需求，但是可能对服务器生产部署还不是很清楚。没关系，本文会分享一个开源博客系统是如何将前后端自动化部署到生产环境的，如果你正好缺乏这项技能，相信本文一定会给你带来巨大的价值，系好安全带，准备发车吧！
旧事重提
关于自动化部署，我曾有过很多探索和实践，也在公司内部搭建了支撑所有前端项目的 CI/CD 体系，如今也全部升级接入到了 K8S 架构中。
很早之前，我就有写博客介绍过如何写自动化脚本，以及如何使用 gitlab 之类平台支持的 CI/CD 能力。
借着今天这个开源博客项目，我们再来实操一下自动化部署流程。
经典的动静分离部署
我们知道，博客是一个网站，用户都是从域名（本博客是 blog.wbjiang.cn）进来访问的，对静态资源和接口数据的访问从这个域名经过，通常会使用 Nginx 进行规则转发。
首先看前端部分，不管是 Vue 还是 React 项目，打包后的资源默认都会到 dist 目录下。
我们只要把这部分文件放在服务器目录上，再通过 nginx 配置访问即可。
server {
listen 80 default_server;
server_name _;
return 403;
}
server {
listen 80;
server_name blog.wbjiang.cn;
rewrite ^(.*)$ https://$server_name$1 permanent;
}
# https 配置
server {
listen 443 ssl http2;
server_name blog.wbjiang.cn;
root /usr/share/nginx/html/vue3-ts-blog-frontend;
# 省略其他配置...
}
以上配置的效果是：当用户访问 blog.wbjiang.cn 的时候，如果是通过 http 协议访问的，自动 301 重定向到 https 访问；而 https 访问会去找 nginx root 配置对应的目录下的文件。
当我们访问网站时，能看到每一个前端静态资源文件的请求和响应。
那么后端接口是怎么访问到的呢？我们可以观察到，接口请求都有一个前缀 /api。
这是一种约定。由于我们的前后端访问都是从一个域名接入的，必须要约定一种访问规则。比如，/api 前缀的请求，就是服务请求，针对这类请求，我们给它转发到 nodejs 服务，其他的请求默认为前端请求，即访问 root 配置的目录即可。
这种约定对应着 Nginx 的规则，是通过 location 来配置的。
#api转发
location /api {
proxy_pass http://127.0.0.1:8002;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
rewrite ^/api/(.*)$ /$1 break;
}
以上配置的含义就是：如果一个请求是 /api 开头的，就转发到 8002 端口（8002端口部署着我们的 nodejs 后端服务）。最后还有一行 rewrite 配置，这是因为 express router 并未设置 /api 前缀，通过 rewrite 抹掉 /api 前缀才能被 express router 处理。
nodejs 8002 端口的服务是怎么开启的呢，其实也很简单，与我们在本地启动 express 服务并无太多差异，同样也是启动 pm2，只不过对应的 NODE_ENV 是 production。
pm2 start ecosystem.config.js --env production
从同一个域名接入前后端还有一个好处，那就是没有跨域问题，这也是反向代理的一个常见应用场景。
以上是服务器部署的最终形态，包括前端和后端部分。但是我们还需要实现自动化部署，这样才能解放我们的生产力，同时也能降低人工部署出事故的可能性。
提及自动化部署时，往往会提及脚本、事件驱动等概念。
我们期望做到的效果是：当一个功能开发完了，或者一个bug修复完了，提交代码后就能自动完成部署工作，不需要人力登录服务器进行手工部署。
写脚本是不可或缺的，写好部署脚本后，我们可以执行脚本，通过脚本完成部署工作，也就是所谓的一键部署。不过这依然需要人来执行脚本，完全的自动化部署可以基于一些 CI/CD 工具来完成。
github actions 自动化部署 Vue 前端
由于是前后端分离项目，整个部署我们要分两部分来看。我们的项目是在 github 上开源的，可以选择利用 github 的 actions 来实现 CI/CD。
CI/CD 一般都是通过一个 yaml 配置文件来驱动的，各个平台的配置项大同小异，我们只需要抓住一些关键概念：env, secrets, workflow, stage, job, step, run 等，它们可能在不同 CI/CD 平台中的叫法不一样，但是本质上是一样的，这些概念可以在各个 CI/CD 平台的官方文档中查阅。
也可以先看看下面这篇文章了解下，对 CI/CD 有个基本认识。
在完成配置一个 CI/CD 之前，我们要问问自己，“整个流程是什么样的？”
- 什么时候触发 CI/CD ？
- 可以手动触发 CI/CD 吗？
- CI/CD 中要做哪些事？
针对第一个问题，我们可以根据自己的需要进行选择，比如 push 代码时就触发 CI/CD，或者打 tag 时触发 CI/CD，或者是发布 release 时触发 CI/CD。这些都是 git 操作中一些关键事件，所以我称之为“事件驱动”。
当我们希望 push 代码到 main 分支时直接触发 CI/CD，就可以这样配置：
on:
push:
branches:
- main
针对第二个问题，github actions 是支持手动触发 CI/CD 的，对应的配置是workflow_dispatch。
# Controls when the action will run. Workflow runs when manually triggered using the UI or API.
on:
workflow_dispatch:
# Inputs the workflow accepts.
inputs:
name:
# Friendly description to be shown in the UI instead of 'name'
description: 'Remarks'
# Default value if no value is explicitly provided
default: 'trigger a release'
# Input has to be provided for the workflow to run
required: true
第三个问题也是最关键的，CI/CD 中我们要执行哪些任务？简单列举一下。
- 检出代码：保证当前工作目录是最新的代码。
- nodejs 版本指定：保证 nodejs 版本是所期望的。
- 安装依赖：对应着 npm install 或者 yarn install。
- 项目打包：使用 build 脚本进行打包。
- 发送到服务器：将打包好的前端静态资源发送到服务器 nginx 资源目录下。
其中有些任务可以直接引用社区的 actions，比如检出代码、设置 nodejs 版本、上传/下载构建产物等，具体可以前往ci_cd.yaml源码查看。
有了这些配置，当代码被 push 到远程 main 分支时，就会触发 CI/CD。
pm2 自动化部署后端服务
对于 nodejs 后端服务，我暂时没有将部署过程迁移到 github actions 上，而是直接用 pm2 提供的 deploy 命令实现。
pm2 deploy 命令执行过程中需要一些配置项，这些配置项可以通过 ecosystem.config.js 文件中的 deploy 配置维护。
由于 deploy 配置可能会涉及到一些私密信息，比如你的服务器 ip 和用户名，服务器部署路径等等，这些信息最好不要公开在开源项目中，所以我将 deploy 配置单独抽取了一个文件来维护，也就是 deploy.config.js，并且提供了配置示例。
此时，只要我们执行 pm2 deploy production 命令，就会开始 nodejs express 服务的部署。
当然，pm2 deploy 也可以放在 github actions 中执行，相关私密信息可以用 secrets 替代。
小结
作为一个前端开发，掌握全栈项目自动化部署会对你有极大帮助，你会站在一个“伪架构师”的视角去看待系统全局，知晓一个 Web 项目运行的本质、前后端在服务器上是如何工作和协调的。当你学会使用 CI/CD 后，你会对 git, ssh 等相关知识有更多的理解。
2037
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
