01～08 篇其实只在回答一个问题：如何把一次生产变更（Production Change）对生产环境配置或产物进行的实际修改与发布，通常需门禁、可回滚，并视为敏感运维动作。，从“某个人记住的一串操作”，逐步变成“仓库里可审查、可复现、可验证的交付系统”？

这条路径不是工具堆砌，而是职责不断被拆开：Git 管源码和版本，Docker 管运行环境，流水线（Pipeline）将软件从代码提交到最终交付的各阶段（构建、测试、部署等）自动化串联的有序步骤序列，确保每次变更以可重复、可审计的方式完成交付。管交付触发，Compose 管单机多服务拓扑。到这里，一人公司和大多数中小型公司已经有了一套足够实用的自动化运维基础。

运维的目标是简化繁琐工作，而不是不断增加平台本身的复杂度。Kubernetes 很强，但它适合解决多机调度、弹性扩缩容和故障自愈等问题；如果项目仍然是单机或少量独立部署，Docker Compose 往往是更合适的默认选择。先用足够简单的方案把自动化闭环跑通，再根据真实的规模和可靠性需求升级，通常比一开始就引入 Kubernetes 更稳妥。

八篇文章做了什么

01～04 篇先把“服务如何在服务器上运行”这件事讲清楚：从 Nginx 承接静态资源（Static Asset）无需服务端动态计算即可直接返回给浏览器的文件，常见为 HTML、CSS、JavaScript 与图片等。、Linux 服务器和 SSH 开始，到用 systemd（Systemd）现代 Linux 发行版默认的 init 系统与服务管理器，通过 unit 文件声明进程的启动命令、重启策略、依赖关系、日志输出等，使进程具备开机自启、崩溃自愈、统一日志等生产级保活能力。 保证后端进程持续运行，再到用日志和健康检查确认服务状态。随后引入 Git 和 GitHub，把源码、配置和版本历史纳入管理，让部署不再依赖某台机器上的临时文件。这个阶段的变化，是把一台能访问的服务器逐步变成一套可持续、可追溯的源码交付基础。

05～08 篇继续解决“环境、动作和拓扑如何稳定交付”：Docker Image 固化应用及其运行依赖，容器（Container）基于操作系统内核的 Namespace（命名空间视图隔离）与 Cgroups（物理资源配额限制）技术构建的轻量级、自包含应用运行实例。与虚拟机不同，容器直接共享宿主机操作系统内核，具备秒级启动、极低资源开销与环境一致性优势。 让服务器回归运行服务本身；Shell、Jenkinsfile 和 GitHub Actions 把重复命令变成可触发、可记录的生产变更；当应用拆成多个服务后，Docker Compose 再把服务、网络、卷、配置和依赖写进 compose.yaml，让单机上的多个容器作为一个整体运行。每一步都没有消灭前一步，而是把前一步的职责固定下来：容器负责运行服务，Git 负责管理变更，流水线负责交付，Compose 负责组织应用拓扑。

从手动到声明式

最初的部署可能是：

ssh → cd → git pull → build → restart → curl

逐步演进后，职责变成：

Git：保存源码、配置和历史
Docker：封装运行环境和应用制品
Pipeline：触发构建、推送镜像、反馈结果
Compose：声明服务、网络、卷、依赖和生命周期

这就是基础篇的核心范式：把动作代码化，把环境容器化，把拓扑声明化，把变更流水线化。

职责边界

对象	负责什么	不负责什么
Git	源码、配置、历史、Review	不负责运行服务
Docker Image	固化应用和依赖	不负责多服务拓扑
Container	运行一个服务实例	不负责版本审计
Compose	管理单机多服务拓扑和生命周期	不负责多机集群调度
GitHub Actions / Jenkins	构建、触发、交付、记录结果	不应承载全部服务拓扑细节
Kubernetes	多机调度、弹性、自愈	不一定适合单机小项目

当职责边界清晰后，流水线可以被“打薄”：它不再逐个创建网络、启动容器、判断依赖，而是交付版本并调用 Compose。Compose 也不需要知道什么时候发布，它只负责把描述的应用状态收敛到目标机器。读者可以把这张表当成排查问题时的索引：源码不一致先看 Git，运行环境不一致先看 Image，多服务启动异常先看 Compose，交付过程失败再看 Pipeline。

单机多服务的推荐闭环

对于一人公司、个人项目、开源项目和中小型单机应用，推荐采用以下路径：

compose.yaml 随源码提交
        ↓
选择 Build in Server 或 CI Build
        ↓
docker compose config
        ↓
docker compose up --build -d
        或
docker compose pull && docker compose up -d
        ↓
docker compose ps / logs / healthcheck

两种构建模式都成立：

模式	适合场景	主要代价
Build in Server	单机、个人项目、开源项目自部署	占用生产资源，构建环境依赖服务器
CI Build	多环境、团队协作、需要审计和快速回滚	需要 Registry 和构建流水线

关键不在于“哪种模式绝对正确”，而在于是否明确了镜像在哪里构建、谁负责触发、如何验证和如何回滚。

你能解决什么

可以独立完成

• 部署 Nginx 静态站点和 Spring Boot（Spring Boot）基于 Spring 框架的企业级 Java 微服务脚手架与事实工业标准。采用“约定优于配置”理念，通过 Starter 依赖和内嵌 Servlet 容器（如 Tomcat），支持快速构建并打包为自包含的独立常驻进程（fat jar）。 / Flask 等后端服务；
• 用 Git 管理源码、配置和运维文件；
• 用 Docker 固化单个服务的运行环境；
• 用 GitHub Actions 或 Jenkins 自动构建和部署；
• 用 Compose 在一台服务器上运行网关、应用、数据库、缓存和监控组件；
• 通过日志、健康检查和运行历史定位常见发布问题。

仍然需要进阶方案

需求	下一步方案
多节点统一调度	Kubernetes / K3s
自动扩缩容和故障迁移	Kubernetes 控制器、HPA
灰度、蓝绿和渐进式发布	Argo Rollouts、Service Mesh
多区域容灾	多集群、跨区域复制、流量治理
基础设施整体代码化	Terraform、Pulumi、Ansible
完整安全供应链	镜像扫描、签名、SBOM、准入控制

发布检查

发布一个 Compose 应用前，至少确认：

1. compose.yaml 已提交 Git，变更可 Review；
2. 镜像使用明确版本，生产环境（Production Environment）面向真实用户提供服务的运行环境，变更需受发布门禁约束。避免依赖漂移的 latest；
3. 密钥没有写入仓库明文；
4. 数据库和其他持久化数据使用卷或独立存储；
5. 依赖服务配置了健康检查，应用具备连接重试；
6. 发布前执行 docker compose config；
7. 发布后检查 ps、日志和业务健康接口；
8. 明确上一版本如何恢复。

下一步

建议按问题而不是按工具继续深入：

环境和密钥越来越多 → 配置管理与 Secrets
构建和部署职责混在一起 → CI/CD 权责分离
镜像越来越多 → 私有 Registry 与供应链治理
单机不够用了 → K3s / Kubernetes
服务越来越难观察 → Metrics / Logs / Traces

基础篇的终点不是“学完所有 DevOps 工具”，而是能够判断：当前问题属于源码、运行环境、交付流程、应用拓扑，还是集群治理，并把它交给合适的层次解决。

因此，这套内容不会把重点放在术语数量或概念覆盖率上，而是坚持实践优先：每一步都从一个真实的运维麻烦出发，用足够简单的工具解决，再观察新的边界。读者不需要先背完 Kubernetes、GitOps 或 IaC 的全部定义，先把一人公司或中小项目的部署闭环跑通，概念会在实践中逐渐变得清晰。

小结

01～08 篇完成了一次从手动部署到可复现交付的演进：Git 保存变更，Docker 固化环境，流水线触发交付，Compose 声明单机应用拓扑。对于绝大多数个人和中小型项目，这套组合已经足够；只有当问题超出单机边界，才需要进入 Kubernetes、GitOps、可观测性和安全供应链等进阶领域。

参考

• DevOps 基础篇导读
• Docker Compose 官方文档
• GitHub Actions 官方文档
• Jenkins Pipeline 官方文档