这不是一组互不相关的工具教程，而是一条完整的生产交付路径：代码如何到达服务器，服务如何稳定运行，多个服务如何协作，部署动作如何被记录、复用和自动执行。
很多人一想到 DevOps，就直接想到 Kubernetes。但对一人公司、个人项目和大多数中小型应用来说，真正需要解决的通常不是多集群调度，而是把重复、繁琐、容易出错的部署工作稳定地自动化。Kubernetes 本身也需要较高的学习、配置和运维投入，如果业务还没有达到集群化的规模，过早引入反而会增加负担。
因此，本篇先从更朴素、也更贴近多数项目的方案开始：Docker Compose 负责单机多应用，GitHub Actions 负责托管式。Compose 把服务拓扑随源码提交管理；GitHub Actions 提供免费额度内的托管 Runner、声明式 YAML、丰富模板和完整的 GitHub 配套。对多数中小项目而言，这套组合已经是低成本、低复杂度且足够可靠的自动化运维起点。
本篇不追求把所有概念和术语一次讲完，也不把文章写成工具名词大全。每引入一个工具，都是因为前一步已经暴露了一个真实问题：手动部署容易漏步骤，就先用脚本固化；服务器环境难以复现，就用 Docker 封装；重复动作需要触发和记录，就引入流水线；服务数量增加，就用 Compose 管理整体拓扑。先实践，再抽象；先解决眼前问题，再逐步升级，是这套基础篇的阅读方法。
这套内容解决什么问题
从手动部署开始，问题会逐步暴露：
- 命令靠记忆，漏一步就可能发布失败；
- 服务器需要安装越来越多的和构建工具；
- 版本、配置和部署步骤难以追溯；
- 服务从一个变成多个后，网络、卷和依赖关系变得复杂；
- 流水线如果承担所有细节，也会重新变成一份难以维护的脚本。
基础篇的目标，是把这些问题逐层拆开，再用合适的工具收敛：Git 管版本，Docker 管运行环境，流水线管交付触发，Compose 管单机多服务应用拓扑。
推荐阅读路径
| 篇目 | 解决的问题 | 关键产物 |
|---|---|---|
| 01 | Nginx 如何承接 | Nginx 配置 |
| 02 | 一台生产服务器如何运行服务 | 公网服务器、SSH |
| 03 | 后端进程如何持续运行 | 、健康检查 |
| 04 | 源码和版本如何管理 | Git、GitHub |
| 05 | 如何隔离运行环境 | Docker Image、Container |
| 06 | 重复命令如何形成流水线 | Shell、Jenkinsfile、DAG |
| 07 | 如何使用托管式流水线 | GitHub Actions、Runner |
| 08 | 多个容器如何作为一个应用运行 | compose.yaml |
| 09 | 如何判断方案是否够用 | 能力地图与边界 |
建议按顺序阅读并至少完成一次最小部署。不要一开始就跳到 Kubernetes：先理解单机部署中的服务、版本、配置、拓扑和验证，再判断是否真的需要集群。
读完之后应该具备的能力
- 能把静态站点或后端服务部署到一台 Linux 服务器；
- 能用 Git 管理源码、配置和运维文件；
- 能用 Docker 固化运行环境，避免在服务器上散落安装依赖；
- 能区分镜像、容器、服务、流水线和 Runner 的职责；
- 能用 GitHub Actions 或 Jenkins 自动触发构建与部署；
- 能用 Compose 管理单机上的网关、应用、数据库和其他依赖；
- 能判断什么时候继续使用 Compose，什么时候进入 Kubernetes 等进阶方案。
先建立一个总心智模型
源码与配置
↓ Git 管理
镜像与制品
↓ Docker 封装
生产变更
↓ Jenkins / GitHub Actions 触发
单机应用拓扑
↓ Docker Compose 收敛
服务运行与健康验证对一人公司和大多数中小型公司来说，基础篇已经足以建立一套可落地的自动化运维方案：源码可追溯，镜像可复用，变更可触发，拓扑可声明，结果可验证。只有当业务规模和可靠性要求超出单机边界时，才需要继续引入更复杂的平台。