跳到正文 Lab学后总结 · Jimmy Huang's Blog
以前你创建两台 VM，可能要手动去 Nectar Dashboard 里操作：
选择镜像；
选择 flavor；
选择 key pair；
设置 security group；
点击创建；
等待 VM 启动；
SSH 进去；
手动安装 Apache。
这个 Lab 把这些手动步骤写进 Ansible 文件，让 Ansible 自动做两类事情：
第一类：Provisioning，创建资源 Ansible 通过 OpenStack / Nectar API 创建新的 VM。
也就是说，它不是 SSH 进一台已有机器后再操作，而是先直接告诉云平台：
第二类：Configuration Management，配置资源 VM 创建出来以后，Ansible 再通过 SSH 登录到这些 VM 上，执行安装和配置动作，例如安装 Apache。
也就是说，Task 1 让你看到 Ansible 的两个角色：
这个阶段的 Apache 主要是一个验证目标：如果你能自动创建 VM 并自动安装 Apache，说明你的自动化链路基本跑通了。
Task 2：继续用 Ansible，把两台 VM 配成 2 节点 Kubernetes 集群 把多台服务器上的复杂安装流程，也写成 Ansible Playbook 自动执行。 Kubernetes 集群不是单纯“装一个软件”就完事，它通常涉及很多步骤，例如：
安装容器运行环境；
安装 Kubernetes 组件；
初始化 master 节点；
让 worker 节点加入集群；
配置网络组件；
验证节点是否 Ready。
如果这些步骤全部手动做，很容易因为命令顺序、配置文件、节点角色搞错而失败。Ansible 的价值就是把这些步骤写成 YAML 格式的 Playbook，然后按照顺序批量执行。
Task 3：用 Pulumi 把上周的 ToDo Web Service 部署到 Kubernetes 到了这一步，VM 和 Kubernetes 集群已经准备好了。接下来要做的是把应用部署进去。
这个 Lab 的应用是上周的 ToDo Web Service 。Pulumi 负责把应用部署过程代码化，大致包括：
从应用源码构建 Docker 镜像；
把 Docker 镜像推送到 Docker Hub；
在 Kubernetes 里创建 Deployment；
在 Kubernetes 里创建 Service；
让外部用户可以通过 Service 访问应用。
Ansible 更像“服务器配置师”；Pulumi 更像“云资源和应用部署编排师”。 Pulumi 的特点是可以用真实编程语言来定义基础设施和应用部署逻辑。也就是说，你不是只写一堆手动命令，而是写一份程序来描述：
“我希望 Kubernetes 里有这个 Deployment、这个 Service、这个镜像、这个端口暴露方式。” 然后执行 Pulumi 后，它会尽量把实际环境调整到你代码描述的状态。
Appendix：用 Git 管理 IaC 代码版本 最后的 Git 部分不是单纯为了学 Git 命令，而是为了理解：
当基础设施变成代码以后，基础设施也应该像普通软件代码一样被版本控制。 Ansible Playbook 可以放进 Git；
Pulumi 项目代码可以放进 Git；
inventory、变量文件、部署脚本也可以放进 Git；
每次改动都可以 commit；
出问题可以回滚；
多人协作可以用 branch / merge / rebase 管理变化。
3. 每个核心组件有什么用
3.1 Control VM / 控制节点
它是什么？
它在这个 Lab 里负责什么？ OpenStack CLI；
Ansible；
SSH / SCP；
Pulumi；
Git 操作。
没有它会发生什么？ 没有控制节点，你就可能要在自己的电脑上配置所有依赖、认证文件、SSH key、Python 包、Pulumi 环境。这样不仅容易混乱，而且环境不稳定，换电脑后还可能全部失效。
和其他组件有什么关系？
3.2 OpenRC 文件
它是什么？ OpenRC 文件通常用来保存 OpenStack / Nectar 的认证信息和环境变量。
它在这个 Lab 里负责什么？ 你是谁；
你属于哪个项目；
应该连接哪个 OpenStack API；
你有没有权限创建 VM、网络、安全组等资源。
没有它会发生什么？ OpenStack CLI 或 Ansible 的 OpenStack 模块可能无法认证，也就不能自动创建 VM。
和其他组件有什么关系？
3.3 SSH Key
它是什么？ SSH key 是用来安全登录 Linux VM 的密钥。
它在这个 Lab 里负责什么？ 让控制节点可以免密码、安全地登录到新创建的 Master VM 和 Worker VM。
没有它会发生什么？ Ansible 不能通过 SSH 登录目标机器，也就不能安装 Apache、配置 Kubernetes、让 worker 加入集群。
和其他组件有什么关系？
3.4 Ansible
它是什么？ Ansible 是一个自动化配置管理工具。你写好 YAML 格式的 Playbook，它就按照你的说明去多台机器上执行任务。
它在这个 Lab 里负责什么？ 调用 OpenStack / Nectar API 创建 VM；
通过 SSH 登录 VM，安装 Apache，并配置 Kubernetes 集群。
没有它会发生什么？ 你就要手动创建 VM、手动 SSH 到每台机器、手动安装软件、手动复制配置、手动加入 Kubernetes 集群。步骤多、容易错，也难以复现。
和其他组件有什么关系？
3.5 Ansible Inventory
它是什么？ Inventory 是 Ansible 的“目标机器名单”。
它在这个 Lab 里负责什么？ 哪台是 master；
哪台是 worker；
每台机器的 IP 是什么；
用什么用户名连接；
可能还包括 SSH key、变量、分组等。
没有它会发生什么？ Ansible 不知道要连接谁，也不知道哪些机器属于哪一组。
和其他组件有什么关系？
3.6 Ansible Playbook
它是什么？ Playbook 是 Ansible 的自动化脚本，通常是 YAML 文件。
它在这个 Lab 里负责什么？ 把“创建 VM、安装 Apache、安装 Kubernetes、初始化 master、加入 worker”等步骤写成可重复执行的任务。
没有它会发生什么？ 你只能手动一步一步敲命令，不能形成可复用的自动化流程。
和其他组件有什么关系？
3.7 Nectar / OpenStack
它是什么？ Nectar 是云平台环境，底层使用 OpenStack 相关能力提供 VM、网络、安全组等云资源。
它在这个 Lab 里负责什么？ VM；
IP；
security group；
key pair；
网络连接。
没有它会发生什么？ Ansible 和 Pulumi 只是自动化工具，本身不会凭空产生服务器。没有云平台，就没有地方创建 VM 和部署集群。
和其他组件有什么关系？
3.8 Master VM / Kubernetes Control Plane
它是什么？ Master VM 在这个 Lab 中是 Kubernetes 的控制平面节点。
它在这个 Lab 里负责什么？ 接收部署请求；
维护集群状态；
调度 Pod；
管理 worker 节点；
处理 Kubernetes API 请求。
没有它会发生什么？ Kubernetes 集群没有“大脑”，无法决定应用应该运行在哪里，也无法维护 Deployment / Service 等资源。
和其他组件有什么关系？
3.9 Worker VM / Kubernetes Worker Node
它是什么？ Worker VM 是 Kubernetes 里真正运行应用容器的节点。
它在这个 Lab 里负责什么？ 它负责运行实际的应用 Pod，例如 ToDo Web Service 的容器。
没有它会发生什么？ Master 只能管理集群，但没有地方运行应用。至少需要 worker 才能承载应用 workload。
和其他组件有什么关系？
3.10 Kubernetes
它是什么？ Kubernetes 是容器编排平台。它负责管理容器应用的部署、运行、扩缩容、重启和服务暴露。
它在这个 Lab 里负责什么？ 它承载上周的 ToDo Web Service，让应用以容器形式运行在集群中。
没有它会发生什么？ 你可以手动 docker run 启动一个容器，但很难管理多节点、多副本、服务暴露、自动恢复等复杂场景。
和其他组件有什么关系？
3.11 Docker Image / Docker Hub
它是什么？ Docker Image 是应用的打包结果，里面包含应用代码、依赖和运行环境。Docker Hub 是镜像仓库。
它在这个 Lab 里负责什么？ Pulumi 会构建 ToDo Web Service 的 Docker 镜像，并把镜像推送到 Docker Hub。之后 Kubernetes 可以从 Docker Hub 拉取镜像来运行应用。
没有它会发生什么？ Kubernetes 不知道该运行什么应用。没有镜像，就没有可部署的容器应用包。
和其他组件有什么关系？
3.12 Pulumi
它是什么？ Pulumi 是 Infrastructure as Code 工具。它允许你用编程语言定义云资源和应用部署。
它在这个 Lab 里负责什么？ Pulumi 负责把 ToDo Web Service 自动部署到 Kubernetes 中，包括镜像构建、镜像推送、Kubernetes Deployment 和 Service 创建。
没有它会发生什么？ docker build；
docker push；
kubectl apply；
手动写 YAML；
手动检查 Service 和 Pod。
和其他组件有什么关系？
3.13 Kubernetes Deployment
它是什么？ Deployment 是 Kubernetes 中用来声明“我要运行什么应用、运行几个副本、使用哪个镜像”的资源。
它在这个 Lab 里负责什么？ “请用这个 Docker 镜像运行 ToDo Web Service。”
没有它会发生什么？ Kubernetes 不知道要运行你的应用，也不知道应用副本应该如何维护。
和其他组件有什么关系？
3.14 Kubernetes Service
它是什么？ Service 是 Kubernetes 里用来暴露应用访问入口的资源。
它在这个 Lab 里负责什么？ 它让外部或集群内部可以通过一个稳定入口访问 ToDo Web Service，而不是直接访问某个变化中的 Pod。
没有它会发生什么？ Pod 即使运行了，外部也不一定能稳定访问它。因为 Pod 的 IP 可能会变化，且默认不一定对外暴露。
和其他组件有什么关系？
3.15 Git
它是什么？
它在这个 Lab 里负责什么？ 管理 Ansible、Pulumi、配置文件和部署脚本的版本变化。
没有它会发生什么？ 你的基础设施代码改了什么、什么时候改的、谁改的、出了问题怎么回滚，都会变得难以追踪。
和其他组件有什么关系？
4. 用初学者类比解释 可以把这个 Lab 想象成：你要开一家小型外卖店，但是不想每次都手动搭店、手动装设备、手动安排员工，而是希望写一套“开店自动化方案”。
4.1 整体类比
4.2 更形象地理解整个流程 你先租了一间“总指挥办公室”（Control VM）。
总指挥办公室里放好了授权文件（OpenRC）和钥匙（SSH key）。
施工队队长（Ansible）拿着地址清单（Inventory）和施工说明书（Playbook）。
施工队先去商业地产平台（Nectar / OpenStack）申请两个房间（两台 VM）。
一个房间装修成“店长办公室”（Master / Control Plane）。
另一个房间装修成“厨房”（Worker Node）。
门店管理系统（Kubernetes）开始工作，店长办公室负责调度，厨房负责真正做菜。
自动上架系统（Pulumi）把你的菜品包（Docker Image）放到中央仓库（Docker Hub），再通知门店管理系统去运行它。
顾客不能直接冲进厨房拿饭，而是通过前台窗口（Service）访问应用。
所有装修说明、开店说明、上架说明都保存在版本档案馆（Git）里。
5. 重点区分容易混淆的概念
5.1 Control VM 和 Kubernetes Master 是一回事吗？ Kubernetes Master 是集群内部负责“管理容器”的机器。
Control VM 管自动化流程；Kubernetes Master 管 Kubernetes 集群。
5.2 Ansible 和 Pulumi 有什么区别？ Ansible 更偏“把机器配置好”；Pulumi 更偏“把资源和应用部署状态代码化”。
5.3 Ansible Inventory 和 Playbook 有什么区别？ Inventory 管“谁”；Playbook 管“做什么”。
5.4 VM、Container、Pod 有什么区别？ VM 是房间，Container 是盒饭制作包，Pod 是 Kubernetes 管理这个制作包的最小运行单位。
5.5 Kubernetes Deployment 和 Service 有什么区别？ 应用怎么运行？运行几个？用哪个镜像？挂了要不要重启？ Deployment 管“运行”；Service 管“访问”。
5.6 Docker Image 和 Docker Hub 有什么区别？ Image 是包裹；Docker Hub 是放包裹的仓库。
5.7 OpenRC 和 SSH Key 有什么区别？ OpenRC 是“进云平台后台的身份”；SSH key 是“进服务器房间的钥匙”。
5.8 谁能访问谁？
5.9 哪个是入口？哪个是数据库？哪个是权限控制？哪个是网络控制？ 这个 Lab 的材料主线里没有明确引入数据库，所以不能把某个组件说成数据库。
6. 这个 Lab 有什么实际用途 这个 Lab 的真实价值不在于“我装了 Apache”或者“我跑了一个 ToDo App”，而在于你学会了一种真实 DevOps 工作方式。
6.1 在真实云架构里的用途 容易漏步骤；
不知道谁改了什么；
不能快速复现环境；
出问题不好回滚；
团队成员之间环境不一致。
IaC 的作用就是让这些资源都能通过代码定义、审查、执行和回滚。
6.2 在后端开发里的用途 应用源码如何变成 Docker 镜像；
镜像如何推送到仓库；
Kubernetes 如何拉取镜像运行应用；
Service 如何暴露后端接口；
自动化工具如何减少部署错误。
这对以后做 Spring Boot、FastAPI、Node.js、Go 后端部署都很有用。
6.3 在 DevOps / SRE 里的用途 自动化；
可重复；
可观测；
可回滚；
可审查；
减少人为错误。
6.4 在安全设计里的用途 这些都是云安全和 DevOps 安全里的基础概念。
6.5 在团队协作里的用途 当基础设施变成代码以后，团队可以像审查普通代码一样审查基础设施变更：
通过 Git branch 开发新改动；
通过 merge 合并稳定改动；
通过 rebase 保持提交历史更线性；
通过 commit 记录每一次环境变化；
通过代码审查减少误操作。
这就是为什么 Lab 里最后还要讲 Code Versioning Systems。
7. 生动形象的示意图（Mermaid 文本版） 如果你的 Markdown 编辑器支持 Mermaid，下面会渲染成流程图。
8. 最后帮你压缩成考试/复习版记忆
8.1 一句话记忆 这个 Lab 是把云资源创建、服务器配置、Kubernetes 搭建、应用部署和代码版本管理串成一条自动化 IaC 流水线。
8.2 五个关键词
8.3 最容易考/最容易被问的区别
8.4 最核心的流程
9. 我不确定或材料中没有明确显示的内容 为了避免编造，这里明确列出材料可见内容中没有完全展开的部分：
具体 Ansible Playbook 文件名、完整命令和每个 YAML 字段，在可见材料中没有完整显示；
具体 Pulumi 使用的语言、完整项目结构和代码细节，在可见材料中没有完整显示；
ToDo Web Service 的具体业务逻辑、端口号、副本数量、Service 类型，在可见材料中没有完整显示；
材料主线中没有明确数据库组件，所以本总结没有把任何组件解释成数据库；
如果你的实际 Lab 页面下方还有未展开内容，以上总结应以你完整 Lab 文档和老师要求为准。
10. 资料依据 本总结依据你提供的 Notion Lab 材料整理，核心可见信息包括：
Lab 06 主题：Configuration Automation and Code Versioning Systems（Pulumi）；
主线：控制节点准备 → Ansible 建资源 → Ansible 装集群 → Pulumi 部署应用 → Git 管理 IaC 文件版本；
Task 0：创建控制节点 VM 并准备环境；
Task 1：用 Ansible 创建两台 VM 并安装 Apache；
Task 2：用 Ansible 搭建 2 节点 Kubernetes 集群；
Task 3：用 Pulumi 部署上周 ToDo Web Service 到 Kubernetes；
Appendix：用 Git 管理自动化代码版本变化。
你的电脑
↓ SSH 登录
Control VM / 控制节点
↓ Ansible 调用 OpenStack / Nectar API
自动创建 Master VM 和 Worker VM
↓ Ansible 通过 SSH 配置两台 VM
搭建 2 节点 Kubernetes 集群
↓ Pulumi 构建镜像、推送镜像、创建 K8s 资源
部署上周的 ToDo Web Service
↓ Git
管理这些自动化代码的版本变化Ansible 调云平台 API → 创建 VM
Ansible 通过 SSH → 配置 VM / 安装 Apache两台普通 VM
↓ Ansible 自动安装和配置
一台变成 Kubernetes Master
一台变成 Kubernetes Worker
↓
形成一个最小可用的 Kubernetes 集群基础设施不再只是“云平台上点出来的东西”
而是“代码仓库里可审查、可追踪、可复现的工程资产”你的电脑 → SSH → Control VM
Control VM → OpenStack API → 创建 VM
Control VM → SSH / Ansible → 配置 VM
Control VM → Pulumi → 部署应用到 KubernetesOpenRC → 给 OpenStack CLI / Ansible 提供云平台认证
Ansible → 使用这些认证信息创建 Nectar VMControl VM 持有私钥
目标 VM 配置公钥
Control VM 通过 SSH 控制目标 VM
Ansible 基于 SSH 执行远程任务Ansible + OpenRC → 创建 Nectar VM
Ansible + SSH Key → 配置 VM
Ansible + Inventory → 知道要操作哪些机器
Ansible + Playbook → 知道要执行哪些步骤Inventory 定义目标主机
Playbook 定义操作步骤
Ansible = 根据 Inventory 对目标主机执行 PlaybookPlaybook = 操作说明书
Inventory = 目标机器名单
Ansible = 按说明书去目标机器执行任务的工具Ansible → 调用 OpenStack / Nectar API → 创建 VM
创建出来的 VM → 被配置成 Kubernetes 节点Pulumi / kubectl → Kubernetes API → Master / Control Plane
Master → 调度应用到 Worker 节点运行Master 负责管理和调度
Worker 负责运行 Pod
Pod 里运行 ToDo Web Service 容器Ansible → 搭建 Kubernetes 集群
Pulumi → 往 Kubernetes 里创建 Deployment 和 Service
Docker 镜像 → 被 Kubernetes 拉取并运行成 Pod应用源码 → Docker build → Docker Image
Docker Image → push → Docker Hub
Kubernetes → pull image → 创建 PodPulumi → 构建 Docker 镜像
Pulumi → 推送 Docker Hub
Pulumi → 调用 Kubernetes API
Pulumi → 创建 Deployment / ServicePulumi 创建 Deployment
Deployment 创建 / 管理 Pod
Pod 运行 ToDo Web Service 容器用户请求 → Kubernetes Service → 转发到 Pod → ToDo Web ServiceGit 管理 IaC 代码
IaC 代码包括 Ansible Playbook、Pulumi 项目、配置文件等你的电脑
可以 SSH 到 Control VM
Control VM
可以用 OpenRC 调 Nectar / OpenStack API
可以用 SSH key 登录 Master / Worker VM
可以运行 Ansible / Pulumi / Git
Ansible
可以创建 VM
可以配置 VM
可以搭 Kubernetes
Pulumi
可以构建和推送 Docker 镜像
可以调用 Kubernetes API 创建 Deployment / Service
外部用户 / 浏览器
通常应该通过 Kubernetes Service 访问应用
不应该直接访问 Pod 内部
不应该直接操作 Kubernetes 控制平面或 SSH 到节点Ansible → 自动配置
Pulumi → 自动部署
Kubernetes → 自动运行和管理容器
Git → 记录和审查变化flowchart TB
title[Lab 06：从手动部署到 IaC 自动化流水线]
subgraph Local[你的本地环境]
PC[你的电脑 / Laptop]
end
subgraph Control[控制区：自动化指挥中心]
CVM[Control VM\n控制节点\n运行 OpenStack CLI / Ansible / Pulumi / Git]
OpenRC[OpenRC 文件\n云平台认证]
SSHKEY[SSH Key\n登录 VM 的钥匙]
INV[Ansible Inventory\n目标机器名单]
PLAY[Ansible Playbook\n自动化施工说明书]
PUL[Pulumi Program\n应用部署代码]
GIT[Git Repository\n版本管理]
end
subgraph Cloud[Nectar / OpenStack 云平台]
API[OpenStack API\n创建和管理云资源]
MASTER[Master VM\nKubernetes Control Plane\n集群大脑]
WORKER[Worker VM\nKubernetes Worker Node\n运行应用]
end
subgraph K8S[Kubernetes 集群]
DEPLOY[Deployment\n声明应用如何运行]
POD[Pod\n运行 ToDo Web Service 容器]
SVC[Service\n稳定访问入口]
end
subgraph Registry[镜像仓库]
IMG[Docker Image\nToDo App 镜像]
HUB[Docker Hub\n镜像仓库]
end
subgraph User[外部访问]
BROWSER[浏览器 / 用户]
end
PC -->|SSH 登录| CVM
CVM --> OpenRC
CVM --> SSHKEY
CVM --> INV
CVM --> PLAY
CVM --> PUL
CVM --> GIT
CVM -->|Ansible + OpenRC\n调用 API 创建 VM| API
API --> MASTER
API --> WORKER
CVM -->|Ansible + SSH\n安装 Apache / 配置 K8s| MASTER
CVM -->|Ansible + SSH\n加入集群 / 配置 Worker| WORKER
MASTER -->|管理和调度| WORKER
PUL -->|docker build| IMG
IMG -->|docker push| HUB
PUL -->|调用 Kubernetes API| MASTER
MASTER --> DEPLOY
DEPLOY --> POD
POD --> WORKER
HUB -->|K8s 拉取镜像| POD
SVC -->|转发请求| POD
BROWSER -->|正常访问路径| SVC
BROWSER -.->|❌ 不应直接访问 Pod| POD
BROWSER -.->|❌ 不应直接 SSH / 操作节点| MASTER
BROWSER -.->|❌ 不应直接 SSH / 操作节点| WORKER
CORE[你要记住的核心区别：\n1. Control VM 是自动化指挥中心，不是 K8s Master。\n2. Ansible 主要负责创建和配置 VM / K8s 环境。\n3. Pulumi 主要负责把应用和 K8s 资源代码化部署。\n4. Deployment 管应用怎么运行，Service 管用户怎么访问。\n5. Git 管这些 IaC 文件的版本历史。]
CORE --- CVM
CORE --- SVCControl VM：指挥中心
Ansible：自动创建和配置 VM
Kubernetes：运行容器应用的平台
Pulumi：用代码部署应用和 K8s 资源
Git：管理基础设施代码版本Control VM ≠ Kubernetes Master
Inventory ≠ Playbook
Deployment ≠ Service
Docker Image ≠ Docker Hub
OpenRC ≠ SSH Key
Ansible ≠ Pulumi
VM ≠ Pod ≠ Container1. 本地电脑 SSH 到 Control VM
2. Control VM 使用 OpenRC 认证 Nectar / OpenStack
3. Ansible 自动创建 Master VM 和 Worker VM
4. Ansible 自动配置它们成为 Kubernetes 集群
5. Pulumi 构建并推送 Docker 镜像
6. Pulumi 在 Kubernetes 中创建 Deployment 和 Service
7. 用户通过 Service 访问 ToDo Web Service
8. Git 记录所有 IaC 文件的版本变化