·vincent

我的项目服务器发布流程2

我的项目服务器发布流程

Dockerblog开发

前端开发者的服务器部署探索：从零到稳定的发布流程

Server Deployment
（Banner示意图：服务器部署流程）

作为一名前端开发者，我们的核心工作通常聚焦于构建精美的用户界面和流畅的交互逻辑。然而，在项目开发的完整链路中，服务器端的部署环节同样关键且充满挑战。本文将分享我在服务器项目发布过程中的探索与心得，帮助前端开发者更好地理解并掌握部署流程。

一、云厂商容器服务与镜像构建

在项目发布流程启动时，我借助 Git 进行版本管理与操作。当准备发布一个新版本时，我会在 Git 中创建 Release 并打上特定的 Tag，随后执行 git push tag。这一操作就像是给云厂商容器服务发送了一个信号，触发其开始构建容器镜像。

云厂商容器服务在接收到来自 Git 的 Webhook 通知后，便着手进行镜像构建工作。它会依据项目代码以及相关依赖，将其整合并打包成一个独立的容器镜像。这一过程犹如精心雕琢一件艺术品，把项目的运行所需的各种元素巧妙地融合在一起。

以阿里云为例：
阿里云容器服务

二、为何不在本地构建镜像上传？

也许有人会问，为什么不在本地构建好镜像然后上传到服务器呢？其实这里面是有原因的：

  1. 镜像体积大：构建好的镜像往往体积较大，本地传输会占用大量网络资源和时间。
  2. 网络不稳定：在带宽有限或网络不稳定的情况下，传输可能失败。
  3. 效率低：本地构建和上传的流程耗时较长，影响发布效率。

解决方案：
采用云厂商的容器构建服务，镜像在云厂商的内网环境中构建和拉取，速度极快且稳定性高。

三、私有镜像的构建与应用

由于国内网络环境对 Docker 官方镜像存在限制，且考虑到项目的安全性与独特性，我选择构建 私有镜像 并存储于自己的镜像仓库中。

构建私有镜像的关键点：

  1. 基础镜像选择：从最小化的基础镜像（如 alpine）开始，减少镜像体积。
  2. 依赖项管理：确保所有依赖项正确安装，避免运行时错误。
  3. 镜像优化：通过多阶段构建（Multi-stage Build）减少最终镜像大小。

示例：

dockerfile
1# 第一阶段：构建环境
2FROM node:16 AS build
3WORKDIR /app
4COPY package*.json ./
5RUN npm install
6COPY . .
7RUN npm run build
8
9# 第二阶段：运行环境
10FROM node:16-alpine
11WORKDIR /app
12COPY --from=build /app/dist ./dist
13COPY package*.json ./
14RUN npm install --production
15CMD ["node", "dist/index.js"]

优势：

  • 避免网络限制
  • 提高安全性
  • 确保稳定性

四、拉取镜像与项目准备

在镜像构建完成后，基于 Webhook 传递的信息，拉取镜像的操作随即展开。这一步骤至关重要，它确保了项目部署环境能够获取到准确且最新的镜像，为项目的后续运行奠定坚实基础。

流程示例：

  1. Webhook 通知服务器拉取新镜像。
  2. 服务器从私有镜像仓库拉取镜像。
  3. 启动新容器，停止旧容器，实现无缝更新。

五、CICD - Service：Node 实现

在整个项目发布流程中，CICD - Service 扮演着极为重要的角色。它负责运行新拉取的镜像，并在启动新容器之前停止旧的容器。

实现方式：

javascript
1const { exec } = require('child_process');
2
3async function deploy() {
4  try {
5    // 停止旧容器
6    await exec('docker stop my-app');
7    // 拉取新镜像
8    await exec('docker pull my-registry/my-app:latest');
9    // 启动新容器
10    await exec('docker run -d --name my-app -p 3000:3000 my-registry/my-app:latest');
11    console.log('Deployment successful!');
12  } catch (error) {
13    console.error('Deployment failed:', error);
14  }
15}
16
17deploy();

优势：

  • 快速且稳定
  • 无缝更新与升级
  • 通过邮件通知发布状态

六、为何不选 Jenkins 等传统工具？

或许有人会疑惑，为何不采用 Jenkins 等成熟的自动化构建工具呢？主要原因如下：

  1. 资源占用高：Jenkins 对服务器的配置要求较高，内存和 CPU 占用较大。
  2. 复杂度高：配置和维护 Jenkins 需要一定的时间和经验。
  3. 定制化需求：我的服务器资源有限，需要更轻量级的解决方案。

解决方案：
基于容器镜像和 Node.js 的自定义 CICD 流程，既节省资源，又满足项目需求。

七、六年实践，成果斐然

值得欣慰的是，这套流程在我的服务器上已经稳定运行了 五六年 之久。这期间，经历了无数次项目的迭代与更新，它始终如一地保障着项目的顺利发布。

实践心得：

  1. 技术探索：从对服务器部署懵懂无知，到熟练驾驭整个流程。
  2. 持续优化：不断改进镜像构建和部署脚本，提高效率。
  3. 分享价值：希望我的经验能为其他开发者提供参考，让大家在技术探索的道路上更加自信与从容。

八、总结与展望

通过这套基于容器镜像的发布流程，我实现了高效、稳定的项目部署。未来，我计划进一步探索以下方向：

  1. Serverless 架构：结合云函数实现更轻量级的部署。
  2. 自动化测试：在 CICD 流程中集成自动化测试，提高代码质量。
  3. 监控与告警：引入监控工具，实时跟踪项目运行状态。

技术探索之路虽然充满艰辛，但只要坚持不懈，就一定能够收获满满的自信与成就感！

扩展阅读：