github actions转cnb.cool

1. 核心痛点：低配服务器的“不可承受之重”

在资源有限的服务器上（硬盘小、内存紧缺）部署现代前端项目（如 Next.js），我遇到了两个无法忽视的致命问题：

硬盘空间的“黑洞”：传统的 git pull + npm install 模式会导致 node_modules 占用大量空间。如果服务器上同时运行多个小项目，硬盘容量瞬间告急。
构建过程的“内存杀手”： Next.js 等现代框架的构建过程（Build Time）非常消耗内存。在直接在服务器上执行构建时，经常导致服务器内存耗尽直接卡死，必须重启服务器才能恢复，这对于生产环境是不可接受的。

为什么选择 Docker？基于以上痛点，Docker 成为了最佳解法：

环境隔离与一致性：解决依赖冲突。

空间优化：虽然镜像也占空间，但配合多阶段构建（Multi-stage builds），我们可以丢弃庞大的 node_modules 开发依赖，只保留产物。分离构建与运行：最关键的一点，我可以不在服务器上构建！在 CI 环境构建好镜像，服务器只负责“拉取并运行”，彻底解决了构建卡死服务器的问题。

为了实现“代码提交即上线”，我尝试了三种主流方案，但各有优缺：

流程：本地提交 -> 服务器拉代码 -> 服务器执行 npm install & pm2 reload。

弃用理由：

效率低：整个流程非常耗时，且并未解决服务器直接构建代码的资源消耗问题。

维护累：需要在服务器上手动配置环境，缺乏原子性，回滚麻烦。

流程：GitHub 推送 -> Actions 触发构建 -> 推送镜像到腾讯云 TCR -> 服务器拉取。

弃用理由：

网络瓶颈：虽然功能强大，但 GitHub Actions 的服务器位于海外。当构建完成后，推送镜像到国内的腾讯云容器镜像服务（TCR）时，速度极慢，经常超时或耗时过长，严重影响发布体验。

流程：代码推送 -> 触发 CNB 构建 -> 内网高速推送到 TCR -> 自动部署。

最终选择：✅

经过对比，我最终锁定了 CNB，理由非常务实：

国内网络优势（速度优先）：由于我的服务器和业务都在腾讯云，使用国内的 CNB 服务，构建环境与腾讯云 TCR 之间几乎是内网级别的传输速度。
流水线效率：相比 GitHub Actions 漫长的上传等待，CNB 实现了一整套“构建 -> 推送 -> 部署”的极速闭环，大大缩短了 CI/CD 的总时长。
资源解耦：利用云端构建资源代替本地服务器构建，彻底释放了我的低配服务器压力，再也不用担心因为发布更新而导致服务器卡死了。