feat(appendix): 添加多个交互式演示组件，完善 AI/Infra 等章节内容
- 新增 Vibe Coding 全栈相关演示组件 (DeveloperSkillShift, FrontendTriad, BackendCore 等) - 新增 RAG 相关组件 (RAGPipeline, ChunkingStrategy, Retrieval 等) - 新增 Embedding & Vector 相关组件 (EmbeddingConcept, VectorSimilarity 等) - 新增 AI Native App 设计组件 (AINativeArch, PromptDesign 等) - 新增 Infrastructure as Code 组件 (IaCConcept, TerraformWorkflow 等) - 新增 DNS & HTTPS 演示组件 (DnsResolution, HttpsHandshake 等) - 新增 Model Finetuning 组件 (FinetuningPipeline 等) - 更新多个章节的 markdown 内容，集成交互式演示
This commit is contained in:
sanbuphy
@@ -1,3 +1,173 @@
|
||||
# 基础设施即代码
|
||||
|
||||
> 待实现
|
||||
::: tip 前言
|
||||
**你有没有经历过这种噩梦：线上服务器挂了，但没人记得当初是怎么配置的？** 手动登录服务器、凭记忆敲命令、祈祷不要敲错——这就是传统运维的日常。基础设施即代码（Infrastructure as Code，IaC）彻底改变了这一切：用代码来定义和管理基础设施，让服务器配置像软件一样可版本控制、可复现、可审计。
|
||||
:::
|
||||
|
||||
**这篇文章会带你学什么？**
|
||||
|
||||
学完这章后，你将获得：
|
||||
|
||||
- **核心概念**：理解 IaC 是什么，为什么它是现代运维的基石
|
||||
- **工作流认知**：掌握 Terraform 的 Write → Plan → Apply → Destroy 四阶段流程
|
||||
- **工具选型**：了解 Terraform、Pulumi、CloudFormation 等主流工具的优劣
|
||||
- **风险意识**：理解配置漂移的危害和检测方法
|
||||
- **最佳实践**：掌握 IaC 项目的工程化管理方法
|
||||
|
||||
| 章节 | 内容 | 核心概念 |
|
||||
|-----|------|---------|
|
||||
| **第 1 章** | IaC 概念 | 手动运维 vs 代码化管理 |
|
||||
| **第 2 章** | Terraform 工作流 | Write → Plan → Apply |
|
||||
| **第 3 章** | 工具对比 | Terraform、Pulumi、CDK |
|
||||
| **第 4 章** | 配置漂移 | 检测、预防、修复 |
|
||||
| **第 5 章** | 最佳实践 | 模块化、状态管理、CI/CD |
|
||||
|
||||
---
|
||||
|
||||
## 0. 全景图：为什么基础设施也需要"源代码"？
|
||||
|
||||
想象你是一个厨师。如果每道菜都凭感觉做，今天放一勺盐、明天放两勺，味道永远不稳定。但如果你把配方写下来——精确到每种调料的克数——任何人都能复现同样的味道。
|
||||
|
||||
基础设施管理面临的是同样的问题。一台服务器的配置可能涉及操作系统、网络规则、安全组、存储卷、环境变量等几十个参数。手动配置不仅容易出错，而且**不可复现、不可审计、不可回滚**。
|
||||
|
||||
::: tip IaC 的核心价值
|
||||
- **可复现**：同一份代码，无论执行多少次，结果都一样（幂等性）
|
||||
- **可版本控制**：基础设施变更通过 Git 管理，谁改了什么、为什么改，一目了然
|
||||
- **可审计**：所有变更都有记录，满足合规要求
|
||||
- **可自动化**：通过 CI/CD 流水线自动部署，消除人为操作风险
|
||||
- **可协作**：团队成员通过 Pull Request 审查基础设施变更，就像审查代码一样
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## 1. IaC 概念：从"手动点击"到"代码声明"
|
||||
|
||||
传统运维的工作方式是：登录云平台控制台，手动点击创建服务器、配置网络、设置安全组。这种方式在管理几台服务器时还能应付，但当规模扩大到几十、几百台时，就变成了噩梦。
|
||||
|
||||
IaC 的核心思想是：**用声明式代码描述你想要的基础设施状态，让工具自动帮你实现**。你不需要告诉工具"先创建 VPC，再创建子网，再创建安全组"（命令式），只需要说"我要一个这样的网络环境"（声明式），工具会自动计算出需要执行的步骤。
|
||||
|
||||
<IaCConceptDemo />
|
||||
|
||||
| 维度 | 手动运维 | 基础设施即代码 |
|
||||
|------|---------|--------------|
|
||||
| 操作方式 | 登录控制台点击 | 编写代码文件 |
|
||||
| 可复现性 | 依赖文档和记忆 | 代码即文档，100% 可复现 |
|
||||
| 变更追踪 | 无记录或记录不全 | Git 版本控制，完整历史 |
|
||||
| 协作方式 | 口头沟通、文档传递 | Pull Request 审查 |
|
||||
| 回滚能力 | 手动逆向操作 | git revert + 重新 apply |
|
||||
| 一致性 | 环境间差异大 | 开发/测试/生产完全一致 |
|
||||
|
||||
::: tip 声明式 vs 命令式
|
||||
- **声明式（Declarative）**：描述"我要什么"，工具自动计算"怎么做"。Terraform、CloudFormation 采用这种方式。优点是幂等性好，缺点是灵活性受限。
|
||||
- **命令式（Imperative）**：描述"怎么做"，一步步执行。Ansible、Shell 脚本采用这种方式。优点是灵活，缺点是难以保证幂等性。
|
||||
- **混合式**：Pulumi、AWS CDK 用通用编程语言编写，兼具声明式的状态管理和命令式的灵活性。
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## 2. Terraform 工作流：Write → Plan → Apply
|
||||
|
||||
Terraform 是目前最流行的 IaC 工具，由 HashiCorp 开发。它的工作流程清晰直观，分为四个阶段，就像软件开发的"编码→审查→部署→清理"。
|
||||
|
||||
<TerraformWorkflowDemo />
|
||||
|
||||
::: tip 四阶段工作流
|
||||
1. **Write（编写）**：用 HCL（HashiCorp Configuration Language）编写基础设施定义文件（.tf）。声明你需要的资源：服务器、数据库、网络等。
|
||||
2. **Plan（计划）**：运行 `terraform plan`，Terraform 会对比当前状态和目标状态，生成一份"执行计划"——告诉你它打算创建、修改、删除哪些资源。这是安全网，让你在真正执行前确认变更。
|
||||
3. **Apply（执行）**：确认计划无误后，运行 `terraform apply`，Terraform 按计划创建或修改资源。执行完成后，当前状态会保存到状态文件（terraform.tfstate）。
|
||||
4. **Destroy（销毁）**：不再需要时，运行 `terraform destroy` 清理所有资源，避免产生不必要的费用。
|
||||
:::
|
||||
|
||||
| 命令 | 作用 | 是否修改基础设施 | 使用场景 |
|
||||
|------|------|----------------|---------|
|
||||
| `terraform init` | 初始化项目，下载 Provider | 否 | 首次使用或添加新 Provider |
|
||||
| `terraform plan` | 预览变更，生成执行计划 | 否 | 每次变更前必须执行 |
|
||||
| `terraform apply` | 执行变更，创建/修改资源 | 是 | 确认 plan 后执行 |
|
||||
| `terraform destroy` | 销毁所有资源 | 是 | 清理测试环境、下线服务 |
|
||||
| `terraform state` | 查看/管理状态文件 | 视操作而定 | 状态迁移、资源导入 |
|
||||
|
||||
---
|
||||
|
||||
## 3. 工具对比：选择适合你的 IaC 工具
|
||||
|
||||
IaC 领域有多种工具，各有侧重。选择工具时需要考虑团队技术栈、云平台、项目规模等因素。没有"最好"的工具，只有最适合你场景的工具。
|
||||
|
||||
<IaCToolComparisonDemo />
|
||||
|
||||
| 工具 | 语言 | 云平台支持 | 学习曲线 | 适用场景 |
|
||||
|------|------|-----------|---------|---------|
|
||||
| Terraform | HCL | 多云（AWS/Azure/GCP） | 中等 | 多云环境、团队协作 |
|
||||
| Pulumi | Python/TS/Go | 多云 | 低（熟悉编程语言） | 开发者友好、复杂逻辑 |
|
||||
| AWS CloudFormation | JSON/YAML | 仅 AWS | 中等 | 纯 AWS 环境 |
|
||||
| AWS CDK | Python/TS/Java | 仅 AWS | 低 | AWS + 编程语言偏好 |
|
||||
| Ansible | YAML | 多云 + 裸机 | 低 | 配置管理、混合环境 |
|
||||
|
||||
::: tip 如何选择？
|
||||
- **初创团队 / 单云**：CloudFormation（AWS）或对应云平台原生工具，生态集成最好
|
||||
- **多云 / 中大型团队**：Terraform，社区最大、Provider 最丰富、招聘最容易
|
||||
- **开发者主导的团队**：Pulumi 或 CDK，用熟悉的编程语言写基础设施，IDE 支持好
|
||||
- **需要配置管理**：Ansible，擅长服务器内部配置（安装软件、修改配置文件）
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## 4. 配置漂移：无声的定时炸弹
|
||||
|
||||
配置漂移（Configuration Drift）是 IaC 实践中最隐蔽的敌人。它指的是**实际基础设施状态与代码定义的状态之间逐渐产生偏差**。
|
||||
|
||||
这种偏差通常是怎么产生的？有人为了"快速修复"一个线上问题，直接登录控制台手动改了安全组规则；有人为了调试，临时加大了某台服务器的配置但忘了改回来。这些"小改动"日积月累，最终导致代码和实际环境严重脱节。
|
||||
|
||||
<ConfigDriftDemo />
|
||||
|
||||
::: tip 配置漂移的危害
|
||||
1. **不可复现**：代码描述的环境和实际环境不一致，新建环境时会出问题
|
||||
2. **回滚失败**：以为回滚到上一版本就能恢复，但实际环境已经被手动修改过
|
||||
3. **安全隐患**：手动开放的端口、放宽的权限可能被遗忘，成为攻击入口
|
||||
4. **审计失效**：合规审计基于代码，但代码不反映真实状态
|
||||
:::
|
||||
|
||||
| 预防措施 | 说明 |
|
||||
|---------|------|
|
||||
| 禁止手动变更 | 通过 IAM 策略限制控制台操作权限 |
|
||||
| 定期漂移检测 | 定时运行 `terraform plan` 检查差异 |
|
||||
| 自动修复 | 检测到漂移后自动执行 apply 恢复一致性 |
|
||||
| 变更审计 | 开启 CloudTrail 等审计日志，追踪所有变更来源 |
|
||||
|
||||
---
|
||||
|
||||
## 5. 最佳实践：让 IaC 项目可持续演进
|
||||
|
||||
IaC 代码和应用代码一样，需要良好的工程实践来保证可维护性。随着基础设施规模增长，没有章法的 IaC 代码会变成另一种形式的"技术债"。
|
||||
|
||||
<IaCBestPracticeDemo />
|
||||
|
||||
::: tip 六条核心最佳实践
|
||||
1. **模块化**：将可复用的基础设施抽象为模块（如 VPC 模块、数据库模块），避免复制粘贴。就像写函数一样，一处定义、多处调用。
|
||||
2. **环境隔离**：开发、测试、生产使用独立的状态文件和变量文件，通过 workspace 或目录结构隔离。
|
||||
3. **远程状态管理**：状态文件（tfstate）存储在远程后端（S3 + DynamoDB），支持团队协作和状态锁定，避免并发冲突。
|
||||
4. **敏感信息管理**：密码、密钥等敏感信息不要写在代码里，使用 Vault、AWS Secrets Manager 等工具管理。
|
||||
5. **CI/CD 集成**：将 terraform plan 集成到 PR 流程，apply 通过流水线自动执行，杜绝本地手动操作。
|
||||
6. **代码审查**：基础设施变更和应用代码一样需要 Code Review，尤其是涉及安全组、IAM 策略的变更。
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## 总结
|
||||
|
||||
基础设施即代码是现代云原生运维的基石。它把"不可描述的手动操作"变成了"可版本控制的代码"，让基础设施管理从"艺术"变成了"工程"。
|
||||
|
||||
回顾本章的关键要点：
|
||||
|
||||
1. **IaC 的本质**：用代码声明基础设施的期望状态，让工具自动实现
|
||||
2. **Terraform 工作流**：Write → Plan → Apply 三步走，Plan 是安全网
|
||||
3. **工具选型**：多云选 Terraform，单云选原生工具，开发者团队选 Pulumi
|
||||
4. **配置漂移**：最隐蔽的风险，需要通过流程和工具双重防护
|
||||
5. **工程化管理**：模块化、环境隔离、远程状态、CI/CD 集成缺一不可
|
||||
|
||||
## 延伸阅读
|
||||
|
||||
- [Terraform 官方教程](https://developer.hashicorp.com/terraform/tutorials) - 从零开始学 Terraform
|
||||
- [Pulumi 文档](https://www.pulumi.com/docs/) - 用编程语言写基础设施
|
||||
- [AWS CDK Workshop](https://cdkworkshop.com/) - AWS CDK 实战教程
|
||||
- [Infrastructure as Code (O'Reilly)](https://www.oreilly.com/library/view/infrastructure-as-code/9781098114664/) - IaC 领域的经典书籍
|
||||
- [Spacelift Blog](https://spacelift.io/blog) - IaC 最佳实践和行业趋势
|
||||
|
||||
Reference in New Issue
Block a user