这两年先后两次读过 Node.js 源码,但是每次都懒于记录,过几个月就忘记了,这次把疏理过程记录下来,以免之后再浪费时间从头看。虽然是为了备忘,我会尽量站在读者的角度写,以望能帮助想了解 Node.js 源码的朋友节省一些时间、精力。
适合谁
- 你需要熟悉 C/C++
- 你需要熟悉 Node.js,理解异步编程及原理
Web 前端的应用需要在 node 环境下安装依赖和构建,但是发布一般又是用 nginx 镜像,我们既不想在 node 容器里安装 nginx,也不想在 nginx 容器里安装 node;
所以,我们先在一个 node 容器中 build 应用,利用 GitLab CI Cache 机制,将构建后的目标文件(通常是 dist 文件夹)缓存,以便在发布阶段 (release stage) 可以使用。
这里我所谓的 release 是指发布 docker image ,所以需要一个 Dockerfile,并且是以 nginx image 为基础镜像构建的。
我这里是部署到 swarm 集群上,所以会首先把 docker-stack.yml
文件 scp 到目标服务器上。
我们通常需要频繁的将生产环境(production)的数据库同步到 develop 和 staging 环境。
之前我们的做法是写了一个 shell 在服务器上手动运行,这个需要测试人员和开发人员拥有服务器权限,甚至是生产环境的权限,风险较大且 “不够 CI/CD 化”。
后来是想写一个 HTTP 服务来触发这样的数据库同步操作,增加了额外的工作开销,还要为这个服务配相应的 CI/CD,不如直接使用 GitLab CI 来完成这个工作。
GitLab CI Pipeline 不仅可以在用户 push 代码的时候被触发,还可以通过 HTTP 调用的形式主动触发。
开发 & 测试人员将 production 环境的数据库同步到 develop / staging 环境:
- 无需接触服务器环境
- 任意时间可主动进行同步(相对于计划任务而言)
- 可指定同步某个项目相关的数据库
- 可指定同步到某个服务器环境 ( develop / staging )
预设场景:
- 有三个数据库项目:project-a project-b project-c
- 有三个服务器环境:production develop staging
- 通过 GitLab CI Pipeline Triggers 来触发执行(HTTP方式)
- 我们可任意指定同步某一个项目的 production 数据库到 develop 或 staging
通过解释说明一个简单的 Node.js 应用的 Pipeline
示例来介绍 GitLab CI 的工作方式和使用。
其中会重点介绍 GitLab CI 的执行过程,Stage
Job
等基础概念,以及缓存策略。
这篇基本介绍只介绍 GitLab CI,不会写具体的使用细节,旨在让新接触 GitLab CI 的同学先对它有个基本的认识,直接看官网文档可能需要多花点时间才能理清一些概念。
GitLab CI 的设计很灵活,有多种使用方案,我在接下来会针对最常用的几种情况写一系列包括实现细节步骤的文章。