文档/教程【免费下载链接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.项目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps点击查看免费下载导读本篇文章是 90DaysOfDevOps 挑战系列中关于**基础设施即代码Infrastructure as CodeIaC**的起点对应仓库中 day56 越南语版文档 的主题脉络。文章将带你理解 IaC 为什么是 DevOps 理念落地的关键一环从人都会犯错、自动化才是正路的朴素出发点到宠物 vs 牲口Pets vs Cattle的运维模型转变再到供应Provisioning、配置管理Configuration Management与软件部署Deployment三者之间的分工。读完本文你将掌握 IaC 的核心概念、声明式与过程式、可变与不可变的区别并能结合仓库中真实的 Terraform 示例Hello-world、VirtualBox、Docker、Kubernetes理解从零到一的实践路径。为什么需要基础设施即代码自动化是正确之路文章的开篇观点非常直白人类会犯错而自动化是正确的道路。这句话是整个 IaC 章节的哲学起点。它引出了一连串值得每个运维与开发人员认真思考的问题你现在是如何构建你的系统的如果今天你失去了所有东西——物理服务器、虚拟机、云上的 VM、云 PaaS 服务——你的计划是什么你需要花多长时间才能把所有东西恢复原状在传统运维模式下这些问题往往令人不安环境的搭建依赖少数几个知道怎么做的人过程不可重复、不可审计、充满人为错误。IaC 正是为这些问题提供的解决方案——用代码重新构建整个环境并且可以对这套构建过程进行测试。需要特别强调的是这不是备份与恢复backup and recovery的概念备份解决的是数据丢了怎么还原而 IaC 解决的是整个平台和环境如何按代码重建。从基础设施与环境的视角看你的平台应该被当作牲口而不是宠物来对待。如果把视野拉回 DevOps 的初衷DevOps 的本质是打破障碍让系统能够快速且安全地部署到生产环境。IaC 正是实现这一目标的手段——它把基础设施的构建纳入软件工程的流程代码化、版本化、可评审、可测试。手工运维时代像照顾宠物一样维护服务器在 DevOps 出现之前如果有一个新应用需要上线大部分服务器的准备工作都是手工完成的。这个过程就像照顾自己的宠物一样每台服务器都有独特的配置管理员知道每台机器的脾性。原文档列出的典型手工任务包括部署虚拟机在虚拟化技术出现之前则是采购物理服务器并安装操作系统安装与配置网络安装与配置路由表安装所需的软件、库并更新它们配置软件安装数据库在规模化场景下应用越大、需要的资源和服务器越多这些任务的劳动量就呈线性甚至指数级增长。它们消耗大量的人力也就是我们自己与时间而这些正是企业在整个 IT 应用环境建设过程中必须持续支付的成本。尤其可怕的是正如文章开头所说人为失误随时可能发生而补救这些错误的代价可能非常高昂——所以自动化成为首选方案。更重要的是初始安装只是开始。环境上线之后还有持续不断的维护、管理与运营工作更新到新版本部署这些新版本管理数据应用出现故障时的恢复在必要时移除、添加和扩展服务器与硬件资源配置网络请想象一下以上这一整套工作需要在开发dev、测试test、生产production等多个环境中一遍又一遍地重复复杂度随之成倍增长。这正是 IaC 登场的时机。宠物与牲口从命名服务器到可丢弃的牲畜传统模式下管理员把服务器当作宠物来养给它们起名字或至少当成家庭一员因为它们会存在很长时间管理员倾注心血手工配置、小心维护。而 IaC 带来的转变是把所有上述任务从头到尾自动化。当某台服务器出了问题你不会去修复它而是直接丢弃它、启动一台新的。整个过程由代码驱动新服务器会被精确地构建成代码中声明的样子。此时你不再关心这台机器叫什么名字——它存在的唯一目的就是提供服务直到不再需要为止也许是因为故障也许是因为整个应用已经更新换代总会有新的实例来替换它。这一思维模型被称为Pets vs Cattle宠物 vs 牲口维度宠物Pets牲口Cattle对待方式每台服务器都独特、有名字、手工配置服务器可替换、按代码批量生成故障处理花时间修复直接丢弃并重建生命周期长短管理方式手工运维自动化、代码驱动IaC 几乎应用于所有平台形态虚拟化技术、云计算技术以及利用云计算优势的云原生Cloud Native技术如 Kubernetes 和容器。IaC 的三大职责域供应、配置管理与软件部署并非所有 IaC 工具都能覆盖以下全部职责。原文档明确指出本章节要学习的工具Terraform实际上只覆盖下面列表中的前两个领域。需要把供应基础设施和配置管理/部署应用区分开来看待。基础设施供应Provisioning创建新服务器配置计算机网络配置应用负载均衡器基础设施层面的配置Terraform 是这一领域的代表它让我们从零开始在代码中定义基础设施应有的样子然后部署它它也能管理这些基础设施的整个生命周期。Terraform 最初也能部署一个应用但之后它不会继续管理应用本身——这正是下一个工具如 Ansible 这类配置管理工具登场的时机配置管理工具在这方面更为擅长。配置管理Configuration Management在服务器上安装应用所需的软件例如运行应用所需的 Python、Go 等运行时在大量服务器上批量准备应用部署环境在众多机器上重复上述步骤chef、puppet和ansible从一开始就是非常适合解决配置安装与软件管理需求的一类工具。仓库中对应的实战资源位于 2022/Days/Configmgmt 目录其中包含大量 Ansible 的 YAML playbook 与 Jinja2 模板文件可以作为配置管理环节的配套参考。软件部署Deployment当服务器基础设施就绪之后把应用部署到这些服务器上包括部署并管理应用包括应用本身及其依赖库维护更新软件也可能是更新依赖库必要时重新配置声明式 vs 过程式两种 IaC 工具的实现哲学IaC 工具之间存在重要差异首先就是声明式Declarativevs 过程式Procedural过程式Procedural按照步骤一步步执行。IaC 中的操作按顺序逐条执行——先创建服务器再把它加入系统再改变配置。你描述的是怎么做到。声明式Declarative声明你想要的最终结果。例如创建一台或多台服务器而不关心执行的先后细节。声明式工具会自动计算出如何从当前状态到达目标状态。例子初始化 2 台服务器或者 2 个 bucket一次性完成。这一差异直接决定了工具的使用体验过程式工具如早期的配置脚本、部分配置管理工具忠实执行你写的每一步声明式工具如 Terraform则对比当前状态与期望状态只执行必要的变更。可变与不可变理解每个资源的生命周期特性第二个重要维度是可变性Mutable与不可变性Immutable这正是宠物 vs 牲口模型在技术层面的具体化可变Mutable可以就地修改配置而不是覆盖或替换。例如修改 Windows 服务器的计算机名、修改 S3 bucket 的标签tag。因为可变所以资源生命周期更长——它被养着可以被修补。不可变Immutable需要变更时直接替换为新实例不做原地修改。生命周期更短——它被丢弃并重建。需要特别强调的是系统中的每个资源都可能同时具有可变和不可变的属性。原文档给出的两个经典例子AWS S3 bucketbucket 名称name必须全局唯一且一旦创建不可更改但它的标签tag完全可以就地修改无需重新创建 bucket。容器镜像container image通常要求是不可变的——当代码需要更新时必须构建一个新的容器镜像而不是修改旧镜像。理解每个资源的这些属性是正确选择 IaC 工具和设计自动化流程的前提。正如原文档所说IaC 的可选方案很多但没有任何一个 IaC 工具能定义并解决所有资源的全部特性我们必须逐一理解每个资源resource/infra的性质再决定用哪种方式管理它。Terraform本系列将实践的 IaC 工具在讨论了上述概念之后本系列选择Terraform作为实践工具因为它在当前阶段被认为是最适合展示 IaC 收益的工具之一。原文档给出的路线是先进行 Terraform 的基础理论101随后进入动手实践。这也是实践是提升能力与编程技能的最佳途径这一理念的延续。仓库中已经沉淀了一套从入门到进阶的完整 Terraform 代码位于 2022/Days/IaC 目录与后续 day57Terraform 入门、day58HCL 语言、day59用 Terraform 与变量创建 VM的讲解一一对应。下面结合这些真实文件把原文档的概念落到具体代码上。最小可运行示例Hello-world最简单的 Terraform 模块就是输出一句话对应 Hello-world/main.tfterraform { required_version 0.12.26 } output hello_world { value Hello, 90DaysOfDevOps from Terraform }这段代码不创建任何真实资源只声明一个输出output。但它是理解 Terraform 四大核心 CLI 命令的最佳起点terraform init初始化项目目录下载并安装配置中声明的 providers。terraform plan生成执行计划预览 Terraform 将对基础设施做出的变更。terraform apply部署代码中定义的资源内置安全确认步骤。terraform destroy销毁本项目创建的所有资源同样需要确认也可以用--auto-approve跳过但只建议在学习和测试时使用。每一次 apply 都会在目录中生成.tfstate状态文件——这是 Terraform 对世界的 JSON 化表示其中可能包含敏感数据最佳实践是把它加入.gitignore并避免提交到仓库。在生产环境中状态文件通常存放在远程共享位置例如 S3 bucket以获得加密、协作与自动化能力。在 VirtualBox 中创建 VM声明式与 count 的威力VirtualBox/virtualbox.tf 展示了如何用社区 providerterra-farm/virtualbox在本地虚拟化环境创建两台 VMterraform { required_providers { virtualbox { source terra-farm/virtualbox version 0.2.2-alpha.1 } } } resource virtualbox_vm node { count 2 name format(node-%02d, count.index 1) image https://app.vagrantup.com/ubuntu/boxes/bionic64/versions/20180903.0.0/providers/virtualbox.box cpus 2 memory 512 mib network_adapter { type hostonly host_interface vboxnet1 } }这个例子非常典型地体现了原文档中声明式与可变的概念count 2是声明式地表达我要 2 台 VM而不是写两次创建过程后续 day59 还演示了把count从 2 改成 3再次terraform apply即可扩展节点这正是修改代码驱动基础设施变更的直观体现。format(node-%02d, count.index 1)生成 node-01、node-02 这样的可读命名。输出output通过element(...)和*展开语法取出每台机器的 IPv4 地址说明 Terraform 资源间引用与输出的基本用法。用 Docker provider 部署容器IaC 不只用于虚拟机也适用于容器。仓库中的 Docker/docker.tf 演示了用社区 providerkreuzwerker/docker拉取 nginx 镜像并启动容器并把容器内部 80 端口映射到宿主机 8000 端口provider docker {} resource docker_image nginx { name nginx:latest keep_locally false } resource docker_container nginx { image docker_image.nginx.latest name tutorial ports { internal 80 external 8000 } }这里能看到 IaC 中资源间依赖与引用的机制docker_container.nginx通过docker_image.nginx.latest引用镜像资源的属性Terraform 会自动排序依赖。这与原文档中容器镜像应当不可变的观点相呼应——代码中声明的是镜像与容器的期望状态变更时通过更新代码重新 apply。用 Kubernetes provider 管理云原生基础设施Kubernetes/kubernetes.tf 进一步展示了 IaC 在云原生领域的应用用官方hashicorp/kubernetesprovider 一次声明 Namespace、Deployment 与 Serviceprovider kubernetes { config_path ~/.kube/config } resource kubernetes_namespace test { metadata { name nginx } } resource kubernetes_deployment test { metadata { name nginx namespace kubernetes_namespace.test.metadata.0.name } spec { replicas 2 ... } }它通过引用kubernetes_namespace.test.metadata.0.name把 Deployment 放进刚创建的命名空间并以 NodePort 类型暴露 Servicenode_port 30201。这印证了原文档的观点IaC 适用于从虚拟机、容器到 Kubernetes 的几乎一切基础设施形态。多资源编排WordPress 全栈示例Docker-Wordpress/docker-wordpress.tf 是一个更完整的编排示例它用变量variable wordpress_port、卷docker_volume、网络docker_network和两个容器MySQL 5.7 与 WordPress拼装出一套可运行的应用栈并通过env列表注入数据库连接信息variable wordpress_port { default 8080 } resource docker_network wordpress_net { name wordpress_net } resource docker_container db { name db image mysql:5.7 restart always network_mode wordpress_net env [ MYSQL_ROOT_PASSWORDwordpress, MYSQL_DATABASEwordpress, ... ] mounts { type volume target /var/lib/mysql source db_data } }这个示例展示了声明式 IaC 如何把网络、存储与多个服务组合成完整应用环境同时提醒我们像数据库密码这类敏感信息应通过变量管理day59 还专门介绍了sensitive true的变量声明方式避免敏感数据明文暴露在状态文件中。测试你的 IaCTerratest 集成IaC 既然可以测试仓库也提供了实际测试代码。位于 Terratest/test/terraform_test.go 的 Go 测试使用 Gruntwork 的 Terratest 库对 Terratest/examples 下的 AWS 实例instance.tf执行完整的init → apply → 验证 → destroy闭环terraformOptions : terraform.WithDefaultRetryableErrors(t, terraform.Options{ TerraformDir: ../examples, }) defer terraform.Destroy(t, terraformOptions) terraform.InitAndApply(t, terraformOptions) publicIp : terraform.Output(t, terraformOptions, public_ip) url : fmt.Sprintf(http://%s:8080, publicIp) http_helper.HttpGetWithRetry(t, url, nil, 200, Hello, World!, 30, 5*time.Second)测试先用user_data在 EC2 上启动一个返回 Hello, World! 的轻量 HTTP 服务见 instance.tf再通过terraform output拿到公网 IP最后用 HTTP 请求断言 200 响应与正文内容。这正是原文档IaC 可以测试论断的仓库级证据基础设施代码与应用程序代码一样可以纳入自动化测试。本篇章脉络与后续路径在本节day56建立了 IaC 全景概念之后系列将依次展开day57Terraform 入门——它是一款聚焦供应provisioning的工具通过 Write / Plan / Apply 工作流管理数百种云服务且是云厂商无关cloud agnostic的选择对比 AWS CloudFormation、Azure Resource Manager 等云厂商绑定工具。day58HashiCorp Configuration LanguageHCL语法与 Terraform state 的深入讲解包括 provider、resource 块与terraform init/plan/apply/destroy全流程。day59用 Terraform 在 VirtualBox 中创建 VM并系统讲解变量变量声明的多种方式、.tfvars文件、TF_VAR_环境变量、-var参数与输出output。配置管理工具如 Ansible的深入实践则对应仓库中的 2022/Days/Configmgmt 目录那里保存了大量 Ansible playbook 与模板文件可作为理解供应与配置管理分工的延伸材料。总结基础设施即代码不是某一款工具的代名词而是一整套围绕用代码定义、重建、测试与管理基础设施的实践范式。本文梳理了它诞生的理由人为错误与手工运维的高成本、它带来的思维转变从宠物到牲口、从过程式到声明式、从可变到不可变以及它在供应、配置管理、软件部署三大职责域中的分工。仓库中的 IaC 示例目录 提供了从最小输出、本地 VirtualBox、Docker、Kubernetes 到 Terratest 测试的完整代码链让每个概念都能对应到可直接阅读和运行的实现。理解这些基础概念之后就可以跟随 day57 进入 Terraform 的实战世界。赞分享文档/教程【免费下载链接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.项目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps点击查看免费下载相关推荐90DaysOfDevOps 第 56 天基础设施即代码IaC全景解读——从 Pets vs Cattle 到声明式基础设施90DaysOfDevOps 第 56 天基础设施即代码IaC全景解读——从 Pets vs Cattle 到声明式基础设施 本篇文章是 90DaysOf文档/教程Easy-Vibe 基础设施即代码IaC实战指南从手动运维到代码声明Easy Vibe 基础设施即代码IaC实战指南从手动运维到代码声明 本文是 Datawhale Easy Vibe 项目「基础设施与运维」附录中「基础设教程文档90DaysOfDevOps 之 Day 56基础设施即代码IaC全景解读 —— 从 Pets 到 Cattle 的思维转变90DaysOfDevOps 之 Day 56基础设施即代码IaC全景解读 —— 从 Pets 到 Cattle 的思维转变 基础设施即代码Infras文档/教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 90DaysOfDevOps 之基础设施即代码（IaC）全景：从手工运维到声明式自动化
文档/教程【免费下载链接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.项目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps点击查看免费下载导读本篇文章是 90DaysOfDevOps 挑战系列中关于**基础设施即代码Infrastructure as CodeIaC**的起点对应仓库中 day56 越南语版文档 的主题脉络。文章将带你理解 IaC 为什么是 DevOps 理念落地的关键一环从人都会犯错、自动化才是正路的朴素出发点到宠物 vs 牲口Pets vs Cattle的运维模型转变再到供应Provisioning、配置管理Configuration Management与软件部署Deployment三者之间的分工。读完本文你将掌握 IaC 的核心概念、声明式与过程式、可变与不可变的区别并能结合仓库中真实的 Terraform 示例Hello-world、VirtualBox、Docker、Kubernetes理解从零到一的实践路径。为什么需要基础设施即代码自动化是正确之路文章的开篇观点非常直白人类会犯错而自动化是正确的道路。这句话是整个 IaC 章节的哲学起点。它引出了一连串值得每个运维与开发人员认真思考的问题你现在是如何构建你的系统的如果今天你失去了所有东西——物理服务器、虚拟机、云上的 VM、云 PaaS 服务——你的计划是什么你需要花多长时间才能把所有东西恢复原状在传统运维模式下这些问题往往令人不安环境的搭建依赖少数几个知道怎么做的人过程不可重复、不可审计、充满人为错误。IaC 正是为这些问题提供的解决方案——用代码重新构建整个环境并且可以对这套构建过程进行测试。需要特别强调的是这不是备份与恢复backup and recovery的概念备份解决的是数据丢了怎么还原而 IaC 解决的是整个平台和环境如何按代码重建。从基础设施与环境的视角看你的平台应该被当作牲口而不是宠物来对待。如果把视野拉回 DevOps 的初衷DevOps 的本质是打破障碍让系统能够快速且安全地部署到生产环境。IaC 正是实现这一目标的手段——它把基础设施的构建纳入软件工程的流程代码化、版本化、可评审、可测试。手工运维时代像照顾宠物一样维护服务器在 DevOps 出现之前如果有一个新应用需要上线大部分服务器的准备工作都是手工完成的。这个过程就像照顾自己的宠物一样每台服务器都有独特的配置管理员知道每台机器的脾性。原文档列出的典型手工任务包括部署虚拟机在虚拟化技术出现之前则是采购物理服务器并安装操作系统安装与配置网络安装与配置路由表安装所需的软件、库并更新它们配置软件安装数据库在规模化场景下应用越大、需要的资源和服务器越多这些任务的劳动量就呈线性甚至指数级增长。它们消耗大量的人力也就是我们自己与时间而这些正是企业在整个 IT 应用环境建设过程中必须持续支付的成本。尤其可怕的是正如文章开头所说人为失误随时可能发生而补救这些错误的代价可能非常高昂——所以自动化成为首选方案。更重要的是初始安装只是开始。环境上线之后还有持续不断的维护、管理与运营工作更新到新版本部署这些新版本管理数据应用出现故障时的恢复在必要时移除、添加和扩展服务器与硬件资源配置网络请想象一下以上这一整套工作需要在开发dev、测试test、生产production等多个环境中一遍又一遍地重复复杂度随之成倍增长。这正是 IaC 登场的时机。宠物与牲口从命名服务器到可丢弃的牲畜传统模式下管理员把服务器当作宠物来养给它们起名字或至少当成家庭一员因为它们会存在很长时间管理员倾注心血手工配置、小心维护。而 IaC 带来的转变是把所有上述任务从头到尾自动化。当某台服务器出了问题你不会去修复它而是直接丢弃它、启动一台新的。整个过程由代码驱动新服务器会被精确地构建成代码中声明的样子。此时你不再关心这台机器叫什么名字——它存在的唯一目的就是提供服务直到不再需要为止也许是因为故障也许是因为整个应用已经更新换代总会有新的实例来替换它。这一思维模型被称为Pets vs Cattle宠物 vs 牲口维度宠物Pets牲口Cattle对待方式每台服务器都独特、有名字、手工配置服务器可替换、按代码批量生成故障处理花时间修复直接丢弃并重建生命周期长短管理方式手工运维自动化、代码驱动IaC 几乎应用于所有平台形态虚拟化技术、云计算技术以及利用云计算优势的云原生Cloud Native技术如 Kubernetes 和容器。IaC 的三大职责域供应、配置管理与软件部署并非所有 IaC 工具都能覆盖以下全部职责。原文档明确指出本章节要学习的工具Terraform实际上只覆盖下面列表中的前两个领域。需要把供应基础设施和配置管理/部署应用区分开来看待。基础设施供应Provisioning创建新服务器配置计算机网络配置应用负载均衡器基础设施层面的配置Terraform 是这一领域的代表它让我们从零开始在代码中定义基础设施应有的样子然后部署它它也能管理这些基础设施的整个生命周期。Terraform 最初也能部署一个应用但之后它不会继续管理应用本身——这正是下一个工具如 Ansible 这类配置管理工具登场的时机配置管理工具在这方面更为擅长。配置管理Configuration Management在服务器上安装应用所需的软件例如运行应用所需的 Python、Go 等运行时在大量服务器上批量准备应用部署环境在众多机器上重复上述步骤chef、puppet和ansible从一开始就是非常适合解决配置安装与软件管理需求的一类工具。仓库中对应的实战资源位于 2022/Days/Configmgmt 目录其中包含大量 Ansible 的 YAML playbook 与 Jinja2 模板文件可以作为配置管理环节的配套参考。软件部署Deployment当服务器基础设施就绪之后把应用部署到这些服务器上包括部署并管理应用包括应用本身及其依赖库维护更新软件也可能是更新依赖库必要时重新配置声明式 vs 过程式两种 IaC 工具的实现哲学IaC 工具之间存在重要差异首先就是声明式Declarativevs 过程式Procedural过程式Procedural按照步骤一步步执行。IaC 中的操作按顺序逐条执行——先创建服务器再把它加入系统再改变配置。你描述的是怎么做到。声明式Declarative声明你想要的最终结果。例如创建一台或多台服务器而不关心执行的先后细节。声明式工具会自动计算出如何从当前状态到达目标状态。例子初始化 2 台服务器或者 2 个 bucket一次性完成。这一差异直接决定了工具的使用体验过程式工具如早期的配置脚本、部分配置管理工具忠实执行你写的每一步声明式工具如 Terraform则对比当前状态与期望状态只执行必要的变更。可变与不可变理解每个资源的生命周期特性第二个重要维度是可变性Mutable与不可变性Immutable这正是宠物 vs 牲口模型在技术层面的具体化可变Mutable可以就地修改配置而不是覆盖或替换。例如修改 Windows 服务器的计算机名、修改 S3 bucket 的标签tag。因为可变所以资源生命周期更长——它被养着可以被修补。不可变Immutable需要变更时直接替换为新实例不做原地修改。生命周期更短——它被丢弃并重建。需要特别强调的是系统中的每个资源都可能同时具有可变和不可变的属性。原文档给出的两个经典例子AWS S3 bucketbucket 名称name必须全局唯一且一旦创建不可更改但它的标签tag完全可以就地修改无需重新创建 bucket。容器镜像container image通常要求是不可变的——当代码需要更新时必须构建一个新的容器镜像而不是修改旧镜像。理解每个资源的这些属性是正确选择 IaC 工具和设计自动化流程的前提。正如原文档所说IaC 的可选方案很多但没有任何一个 IaC 工具能定义并解决所有资源的全部特性我们必须逐一理解每个资源resource/infra的性质再决定用哪种方式管理它。Terraform本系列将实践的 IaC 工具在讨论了上述概念之后本系列选择Terraform作为实践工具因为它在当前阶段被认为是最适合展示 IaC 收益的工具之一。原文档给出的路线是先进行 Terraform 的基础理论101随后进入动手实践。这也是实践是提升能力与编程技能的最佳途径这一理念的延续。仓库中已经沉淀了一套从入门到进阶的完整 Terraform 代码位于 2022/Days/IaC 目录与后续 day57Terraform 入门、day58HCL 语言、day59用 Terraform 与变量创建 VM的讲解一一对应。下面结合这些真实文件把原文档的概念落到具体代码上。最小可运行示例Hello-world最简单的 Terraform 模块就是输出一句话对应 Hello-world/main.tfterraform { required_version 0.12.26 } output hello_world { value Hello, 90DaysOfDevOps from Terraform }这段代码不创建任何真实资源只声明一个输出output。但它是理解 Terraform 四大核心 CLI 命令的最佳起点terraform init初始化项目目录下载并安装配置中声明的 providers。terraform plan生成执行计划预览 Terraform 将对基础设施做出的变更。terraform apply部署代码中定义的资源内置安全确认步骤。terraform destroy销毁本项目创建的所有资源同样需要确认也可以用--auto-approve跳过但只建议在学习和测试时使用。每一次 apply 都会在目录中生成.tfstate状态文件——这是 Terraform 对世界的 JSON 化表示其中可能包含敏感数据最佳实践是把它加入.gitignore并避免提交到仓库。在生产环境中状态文件通常存放在远程共享位置例如 S3 bucket以获得加密、协作与自动化能力。在 VirtualBox 中创建 VM声明式与 count 的威力VirtualBox/virtualbox.tf 展示了如何用社区 providerterra-farm/virtualbox在本地虚拟化环境创建两台 VMterraform { required_providers { virtualbox { source terra-farm/virtualbox version 0.2.2-alpha.1 } } } resource virtualbox_vm node { count 2 name format(node-%02d, count.index 1) image https://app.vagrantup.com/ubuntu/boxes/bionic64/versions/20180903.0.0/providers/virtualbox.box cpus 2 memory 512 mib network_adapter { type hostonly host_interface vboxnet1 } }这个例子非常典型地体现了原文档中声明式与可变的概念count 2是声明式地表达我要 2 台 VM而不是写两次创建过程后续 day59 还演示了把count从 2 改成 3再次terraform apply即可扩展节点这正是修改代码驱动基础设施变更的直观体现。format(node-%02d, count.index 1)生成 node-01、node-02 这样的可读命名。输出output通过element(...)和*展开语法取出每台机器的 IPv4 地址说明 Terraform 资源间引用与输出的基本用法。用 Docker provider 部署容器IaC 不只用于虚拟机也适用于容器。仓库中的 Docker/docker.tf 演示了用社区 providerkreuzwerker/docker拉取 nginx 镜像并启动容器并把容器内部 80 端口映射到宿主机 8000 端口provider docker {} resource docker_image nginx { name nginx:latest keep_locally false } resource docker_container nginx { image docker_image.nginx.latest name tutorial ports { internal 80 external 8000 } }这里能看到 IaC 中资源间依赖与引用的机制docker_container.nginx通过docker_image.nginx.latest引用镜像资源的属性Terraform 会自动排序依赖。这与原文档中容器镜像应当不可变的观点相呼应——代码中声明的是镜像与容器的期望状态变更时通过更新代码重新 apply。用 Kubernetes provider 管理云原生基础设施Kubernetes/kubernetes.tf 进一步展示了 IaC 在云原生领域的应用用官方hashicorp/kubernetesprovider 一次声明 Namespace、Deployment 与 Serviceprovider kubernetes { config_path ~/.kube/config } resource kubernetes_namespace test { metadata { name nginx } } resource kubernetes_deployment test { metadata { name nginx namespace kubernetes_namespace.test.metadata.0.name } spec { replicas 2 ... } }它通过引用kubernetes_namespace.test.metadata.0.name把 Deployment 放进刚创建的命名空间并以 NodePort 类型暴露 Servicenode_port 30201。这印证了原文档的观点IaC 适用于从虚拟机、容器到 Kubernetes 的几乎一切基础设施形态。多资源编排WordPress 全栈示例Docker-Wordpress/docker-wordpress.tf 是一个更完整的编排示例它用变量variable wordpress_port、卷docker_volume、网络docker_network和两个容器MySQL 5.7 与 WordPress拼装出一套可运行的应用栈并通过env列表注入数据库连接信息variable wordpress_port { default 8080 } resource docker_network wordpress_net { name wordpress_net } resource docker_container db { name db image mysql:5.7 restart always network_mode wordpress_net env [ MYSQL_ROOT_PASSWORDwordpress, MYSQL_DATABASEwordpress, ... ] mounts { type volume target /var/lib/mysql source db_data } }这个示例展示了声明式 IaC 如何把网络、存储与多个服务组合成完整应用环境同时提醒我们像数据库密码这类敏感信息应通过变量管理day59 还专门介绍了sensitive true的变量声明方式避免敏感数据明文暴露在状态文件中。测试你的 IaCTerratest 集成IaC 既然可以测试仓库也提供了实际测试代码。位于 Terratest/test/terraform_test.go 的 Go 测试使用 Gruntwork 的 Terratest 库对 Terratest/examples 下的 AWS 实例instance.tf执行完整的init → apply → 验证 → destroy闭环terraformOptions : terraform.WithDefaultRetryableErrors(t, terraform.Options{ TerraformDir: ../examples, }) defer terraform.Destroy(t, terraformOptions) terraform.InitAndApply(t, terraformOptions) publicIp : terraform.Output(t, terraformOptions, public_ip) url : fmt.Sprintf(http://%s:8080, publicIp) http_helper.HttpGetWithRetry(t, url, nil, 200, Hello, World!, 30, 5*time.Second)测试先用user_data在 EC2 上启动一个返回 Hello, World! 的轻量 HTTP 服务见 instance.tf再通过terraform output拿到公网 IP最后用 HTTP 请求断言 200 响应与正文内容。这正是原文档IaC 可以测试论断的仓库级证据基础设施代码与应用程序代码一样可以纳入自动化测试。本篇章脉络与后续路径在本节day56建立了 IaC 全景概念之后系列将依次展开day57Terraform 入门——它是一款聚焦供应provisioning的工具通过 Write / Plan / Apply 工作流管理数百种云服务且是云厂商无关cloud agnostic的选择对比 AWS CloudFormation、Azure Resource Manager 等云厂商绑定工具。day58HashiCorp Configuration LanguageHCL语法与 Terraform state 的深入讲解包括 provider、resource 块与terraform init/plan/apply/destroy全流程。day59用 Terraform 在 VirtualBox 中创建 VM并系统讲解变量变量声明的多种方式、.tfvars文件、TF_VAR_环境变量、-var参数与输出output。配置管理工具如 Ansible的深入实践则对应仓库中的 2022/Days/Configmgmt 目录那里保存了大量 Ansible playbook 与模板文件可作为理解供应与配置管理分工的延伸材料。总结基础设施即代码不是某一款工具的代名词而是一整套围绕用代码定义、重建、测试与管理基础设施的实践范式。本文梳理了它诞生的理由人为错误与手工运维的高成本、它带来的思维转变从宠物到牲口、从过程式到声明式、从可变到不可变以及它在供应、配置管理、软件部署三大职责域中的分工。仓库中的 IaC 示例目录 提供了从最小输出、本地 VirtualBox、Docker、Kubernetes 到 Terratest 测试的完整代码链让每个概念都能对应到可直接阅读和运行的实现。理解这些基础概念之后就可以跟随 day57 进入 Terraform 的实战世界。赞分享文档/教程【免费下载链接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.项目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps点击查看免费下载相关推荐90DaysOfDevOps 第 56 天基础设施即代码IaC全景解读——从 Pets vs Cattle 到声明式基础设施90DaysOfDevOps 第 56 天基础设施即代码IaC全景解读——从 Pets vs Cattle 到声明式基础设施 本篇文章是 90DaysOf文档/教程Easy-Vibe 基础设施即代码IaC实战指南从手动运维到代码声明Easy Vibe 基础设施即代码IaC实战指南从手动运维到代码声明 本文是 Datawhale Easy Vibe 项目「基础设施与运维」附录中「基础设教程文档90DaysOfDevOps 之 Day 56基础设施即代码IaC全景解读 —— 从 Pets 到 Cattle 的思维转变90DaysOfDevOps 之 Day 56基础设施即代码IaC全景解读 —— 从 Pets 到 Cattle 的思维转变 基础设施即代码Infras文档/教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考