文档/教程【免费下载链接】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 挑战中 Day 59 的完整实战记录以 Terraform 的「期望状态配置」为核心通过社区terra-farm/virtualboxProvider 在本地 VirtualBox 上批量创建并管理多台 Ubuntu 虚拟机并深入讲解变量Variables与输出Outputs的多种定义方式、优先级规则和敏感信息处理。读完本文你将掌握一套不依赖云端账号、在笔记本上即可复现的 Terraform 全流程init → plan → apply → destroy并能将其无缝迁移到 AWS、Azure 等公有云环境。为什么用 Terraform 管理本地 VirtualBox通常 Terraform 被用于公有云AWS、Google Cloud、Microsoft Azure以及 VMware、Hyper-V、Nutanix AHV 等虚拟化平台的资源编排。VirtualBox 属于工作站级虚拟化软件正常情况下并不是 Terraform 的典型使用场景——正如原文档作者所言本次演示发生在三万六千英尺的高空航班上相比在云端开通资源在笔记本电脑本地创建虚拟机要快得多。但这并不妨碍我们用它来理解核心思想编写一份描述目标状态的配置代码HCL交给 Provider 去执行让基础设施按声明的方式被创建、修改与销毁。这个「声明式」过程与以往用 Vagrant 的体验不同——在本章节开头已经对比过 Vagrant 与 Terraform 的差异简单来说Terraform以「期望状态」为驱动力配置变更时对比状态文件只做必要的增删改Vagrant更偏向开发环境的可重复供给provisioning面向单机工作流。Terraform 的架构由两部分组成代码configuration与状态state二者合称 Terraform Core而真正与目标平台通信的是Provider如 AWS Provider、Azure Provider以及本次使用的 VirtualBox 社区 Provider它们通过平台 API 执行创建、更新、删除操作。Terraform Registry 上有数百个 Provider既能引用官方发布的如hashicorp/aws也能自行编写并本地使用或发布到 Registry。前置准备动手前需要在本机准备好两样东西VirtualBoxProvider 实际调用的虚拟化引擎负责承载并运行虚拟机Terraform CLI解析 HCL 配置并驱动 Provider 的命令行工具。接着创建项目目录mkdir virtualbox cd virtualbox在目录内新建virtualbox.tf所有资源定义都写在这个文件中。仓库中对应的完整源码位于 2022/Days/IaC/Virtualbox/virtualbox.tf下文将逐段拆解。编写 virtualbox.tfProvider、资源与输出virtualbox.tf由三个层次组成声明 Provider 的terraform块、描述资源的resource块、以及展示结果的output块。1. 声明 Providerterraform { required_providers { virtualbox { source terra-farm/virtualbox version 0.2.2-alpha.1 } } } # There are currently no configuration options for the provider itself.sourceProvider 在 Registry 上的发布地址terra-farm/virtualbox是社区维护的 VirtualBox Providerversion锁定0.2.2-alpha.1版本。这是一个alpha 版本说明 VirtualBox Provider 仍处于活跃迭代期实际生产环境建议优先使用官方云平台 Provider该 Provider 目前没有可供配置的 provider 级选项所以无需写provider virtualbox {}块。2. 定义资源批量创建两台 VMresource 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 } }关键参数说明参数值含义count2元参数meta-argument将同一资源块实例化 2 份生成node[0]、node[1]两个实例nameformat(node-%02d, count.index 1)利用format函数格式化名称count.index从 0 开始%02d保证两位补零最终得到node-01、node-02imageUbuntu bionic64 的 VirtualBox box 下载地址虚拟机模板镜像Provider 会据此创建系统盘cpus2每台虚拟机分配 2 个 vCPUmemory512 mib每台分配 512 MiB 内存注意是带单位的字符串network_adapter.typehostonly使用 VirtualBox 仅主机host-only网络network_adapter.host_interfacevboxnet1绑定到宿主机已创建的vboxnet1虚拟网卡3. 定义输出读取每台 VM 的 IPoutput IPAddr { value element(virtualbox_vm.node.*.network_adapter.0.ipv4_address, 1) } output IPAddr_2 { value element(virtualbox_vm.node.*.network_adapter.0.ipv4_address, 2) }virtualbox_vm.node.*.network_adapter.0.ipv4_address是splat 表达式把所有node实例的第一个网卡下标 0的 IPv4 地址收集成列表element(list, index)按索引取值分别取出第 1 个与第 2 个元素的地址输出到终端。原文档有意从1而非0开始取仅作演示读者可根据实际实例数调整索引。apply完成后Terraform 会在终端打印这两个输出值方便你直接 SSH 登录对应虚拟机。三步创建init → plan → apply代码就绪后按顺序执行三个核心命令。整个 CLI 流程与 Day 58HCL 基础 中 hello-world 示例一脉相承仓库中的 2022/Days/IaC/Hello-world/main.tf 就是那个最小示例。terraform init初始化项目并下载 Providerterraform initinit是任何 Terraform 项目的第一步解析required_providers从 Registry 下载terra-farm/virtualbox插件到本地并在项目目录生成.terraform目录与.terraform.lock.hcl锁文件记录 Provider 版本哈希保证后续执行的一致性。terraform plan预览执行计划terraform planplan会读取配置与现有状态输出一份「将要创建 / 变更 / 销毁什么资源」的执行计划相当于真正的apply之前的安全预览不会对基础设施产生任何实际改动。terraform apply落地创建terraform applyapply内置安全确认机制先展示与plan相同的执行计划并要求你输入yes才真正创建资源。下图展示了 2 台名为node[0]、node[1]的虚拟机创建完成、以及输出的内网 IP 地址完成后打开 VirtualBox 管理器即可看到 2 台正在运行的虚拟机node-01、node-02。横向扩容修改 count 增加节点Terraform 最核心的价值在于通过修改期望状态驱动基础设施变更。现在想把集群扩到 3 台只需把count从2改成3resource virtualbox_vm node { count 3 # ...其余参数保持不变 }再次执行terraform applyTerraform 会对比状态文件已有的 2 台保持不变只新增第 3 台node-03。这种「增量式、幂等化」的变更能力正是声明式 IaC 相比手工操作的根本优势——同样的配置反复执行得到的结果始终一致全程无需人工干预。terraform destroy一键清理实验结束后用一条命令移除全部资源terraform destroy同样带安全确认预览即将销毁的资源清单含虚拟机网卡等配置输入yes后执行删除如果你希望在自动化脚本中跳过确认可以在apply/destroy末尾追加--auto-approve。但建议仅在学习和测试环境使用——资源往往销毁得比创建时更快生产环境请务必保留人工确认环节。Day 58 把本次用到的 CLI 命令总结为四件套这里一并列出命令作用terraform init初始化项目目录、下载并锁定 Providerterraform plan预览将要创建、变更的资源terraform apply按代码部署资源terraform destroy销毁项目创建的资源对应的两个核心配置概念是providersTerraform 如何通过 API 与目标平台通信与resources我们想用代码部署什么。变量与输出六种定义方式与优先级Day 59 的另一个重头戏是变量系统。上一节的 hello-world 示例已经展示过output的用法本节深入变量定义。六种变量来源Terraform 允许通过以下方式为变量赋值在terraform plan/terraform apply命令中手动交互输入在.tf文件内的variable块中定义通常配合default使用系统环境变量格式为TF_VAR_变量名在项目目录放置terraform.tfvars文件作者的个人偏好也是团队协作最常见的做法使用*.auto.tfvars文件文件名以.auto.tfvars结尾Terraform 启动时自动加载无需显式指定执行命令时通过-var或-var-file参数显式传入。优先级规则上述来源的优先级从高到低即-var/-var-file最高命令行-var与-var-file*.auto.tfvars文件terraform.tfvars文件TF_VAR_环境变量.tf文件内的default默认值手动交互输入仅当变量未被任何来源赋值时才触发也就是说高优先级的来源会覆盖低优先级来源对同一变量的赋值而default仅在没有任何来源提供值时生效。原文档中「从列表底部往上数就是变量生效的顺序」描述的正是指向这一规则。仓库中的真实变量示例仓库 2022/Days/IaC/Terratest/examples/vars.tf 展示了生产风格的定义方式variable AWS_ACCESS_KEY { } variable AWS_SECRET_KEY { } variable AWS_REGION { default ap-south-1 } variable AMIS { type map(string) default { ap-south-1 ami-0860c9429baba6ad2 } }这里可以看到没有default的变量如AWS_ACCESS_KEY必须在 apply 前由外部来源提供值否则 Terraform 会交互式询问而带default的变量如AWS_REGION在未显式赋值时自动回退到默认值AMIS则演示了map(string)这类复合类型的默认值写法。配套的 terraform.tfvars 文件即用于集中存放这类敏感或区域相关的赋值。sensitive 变量保护状态文件中的敏感信息前面 Day 58 已提醒过terraform.tfstate状态文件是 JSON 格式的「Terraform 眼中的世界」其中会明文记录敏感数据。最佳实践是将.tfstate文件加入.gitignore避免提交到代码仓库生产环境把状态存到远端共享位置如 S3 桶、Terraform Cloud以换取加密、协作与自动化能力代价是增加一定的复杂度。针对敏感数据可以为变量开启sensitive标记注意 HCL 赋值语法是原文档示例中的type:应写作type variable some_resource { description something important type string sensitive true }标记后该变量在plan/apply输出中会被脱敏隐藏避免密码、密钥等直接暴露在终端日志中。延伸从本地 VirtualBox 到云端与容器本次演示虽然跑在 VirtualBox 上但掌握的原理完全可迁移把resource块换成aws_instance参考 Day 58 的 AWS 示例配合hashicorp/awsProvider即可在 AWS 上创建 EC2 并注入user_data启动脚本仓库的 2022/Days/IaC/Docker/docker.tf 与 2022/Days/IaC/Kubernetes/kubernetes.tf 还提供了用 Terraform 管理 Docker 容器与 Kubernetes 资源的示例可作为后续深入方向若要为 Terraform 代码编写自动化测试可参考仓库中的 Terratest 示例测试用例把「配置 → 应用 → 验证 → 清理」固化为可重复的测试流程。小结通过 Day 59 的完整演练你掌握了用virtualbox_vm资源 count元参数批量创建虚拟机并用format、splat 表达式、element组织名称与输出Terraform 的标准工作流init下载 Provider、plan预览变更、apply落地资源、destroy一键清理六种变量赋值方式及其优先级以及用sensitive true保护敏感信息状态文件的安全风险与远程存储方案。这套「代码定义期望状态 → Provider 执行 → 状态文件追踪」的心智模型是后续在公有云、容器与 Kubernetes 场景下使用 Terraform 的通用基础。下一节Day 60将继续深入 Terraform 的进阶用法。注原文档末尾附有若干 Terraform 学习视频与资源清单此处不再逐一罗列外部链接仓库内 2022/Days/day59.md 保留了完整原文可直接查阅。赞分享文档/教程【免费下载链接】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 实战用 Terraform 与变量在 VirtualBox 中创建虚拟机Day 5990DaysOfDevOps 实战用 Terraform 与变量在 VirtualBox 中创建虚拟机Day 59 在 90DaysOfDevOps 的文档/教程90DaysOfDevOps使用 Terraform 与变量在 VirtualBox 中创建虚拟机Day 59 实战指南90DaysOfDevOps使用 Terraform 与变量在 VirtualBox 中创建虚拟机Day 59 实战指南 本文是 90DaysOfDevO文档/教程90DaysOfDevOps 第 59 天用 Terraform 与变量在 VirtualBox 中创建虚拟机90DaysOfDevOps 第 59 天用 Terraform 与变量在 VirtualBox 中创建虚拟机 导读 本文是《90DaysOfDevOps》学文档/教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/7 20:19:38 · 阅读 1.2k 90DaysOfDevOps 实战：用 Terraform 与变量在 VirtualBox 上批量创建虚拟机（Day 59）
文档/教程【免费下载链接】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 挑战中 Day 59 的完整实战记录以 Terraform 的「期望状态配置」为核心通过社区terra-farm/virtualboxProvider 在本地 VirtualBox 上批量创建并管理多台 Ubuntu 虚拟机并深入讲解变量Variables与输出Outputs的多种定义方式、优先级规则和敏感信息处理。读完本文你将掌握一套不依赖云端账号、在笔记本上即可复现的 Terraform 全流程init → plan → apply → destroy并能将其无缝迁移到 AWS、Azure 等公有云环境。为什么用 Terraform 管理本地 VirtualBox通常 Terraform 被用于公有云AWS、Google Cloud、Microsoft Azure以及 VMware、Hyper-V、Nutanix AHV 等虚拟化平台的资源编排。VirtualBox 属于工作站级虚拟化软件正常情况下并不是 Terraform 的典型使用场景——正如原文档作者所言本次演示发生在三万六千英尺的高空航班上相比在云端开通资源在笔记本电脑本地创建虚拟机要快得多。但这并不妨碍我们用它来理解核心思想编写一份描述目标状态的配置代码HCL交给 Provider 去执行让基础设施按声明的方式被创建、修改与销毁。这个「声明式」过程与以往用 Vagrant 的体验不同——在本章节开头已经对比过 Vagrant 与 Terraform 的差异简单来说Terraform以「期望状态」为驱动力配置变更时对比状态文件只做必要的增删改Vagrant更偏向开发环境的可重复供给provisioning面向单机工作流。Terraform 的架构由两部分组成代码configuration与状态state二者合称 Terraform Core而真正与目标平台通信的是Provider如 AWS Provider、Azure Provider以及本次使用的 VirtualBox 社区 Provider它们通过平台 API 执行创建、更新、删除操作。Terraform Registry 上有数百个 Provider既能引用官方发布的如hashicorp/aws也能自行编写并本地使用或发布到 Registry。前置准备动手前需要在本机准备好两样东西VirtualBoxProvider 实际调用的虚拟化引擎负责承载并运行虚拟机Terraform CLI解析 HCL 配置并驱动 Provider 的命令行工具。接着创建项目目录mkdir virtualbox cd virtualbox在目录内新建virtualbox.tf所有资源定义都写在这个文件中。仓库中对应的完整源码位于 2022/Days/IaC/Virtualbox/virtualbox.tf下文将逐段拆解。编写 virtualbox.tfProvider、资源与输出virtualbox.tf由三个层次组成声明 Provider 的terraform块、描述资源的resource块、以及展示结果的output块。1. 声明 Providerterraform { required_providers { virtualbox { source terra-farm/virtualbox version 0.2.2-alpha.1 } } } # There are currently no configuration options for the provider itself.sourceProvider 在 Registry 上的发布地址terra-farm/virtualbox是社区维护的 VirtualBox Providerversion锁定0.2.2-alpha.1版本。这是一个alpha 版本说明 VirtualBox Provider 仍处于活跃迭代期实际生产环境建议优先使用官方云平台 Provider该 Provider 目前没有可供配置的 provider 级选项所以无需写provider virtualbox {}块。2. 定义资源批量创建两台 VMresource 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 } }关键参数说明参数值含义count2元参数meta-argument将同一资源块实例化 2 份生成node[0]、node[1]两个实例nameformat(node-%02d, count.index 1)利用format函数格式化名称count.index从 0 开始%02d保证两位补零最终得到node-01、node-02imageUbuntu bionic64 的 VirtualBox box 下载地址虚拟机模板镜像Provider 会据此创建系统盘cpus2每台虚拟机分配 2 个 vCPUmemory512 mib每台分配 512 MiB 内存注意是带单位的字符串network_adapter.typehostonly使用 VirtualBox 仅主机host-only网络network_adapter.host_interfacevboxnet1绑定到宿主机已创建的vboxnet1虚拟网卡3. 定义输出读取每台 VM 的 IPoutput IPAddr { value element(virtualbox_vm.node.*.network_adapter.0.ipv4_address, 1) } output IPAddr_2 { value element(virtualbox_vm.node.*.network_adapter.0.ipv4_address, 2) }virtualbox_vm.node.*.network_adapter.0.ipv4_address是splat 表达式把所有node实例的第一个网卡下标 0的 IPv4 地址收集成列表element(list, index)按索引取值分别取出第 1 个与第 2 个元素的地址输出到终端。原文档有意从1而非0开始取仅作演示读者可根据实际实例数调整索引。apply完成后Terraform 会在终端打印这两个输出值方便你直接 SSH 登录对应虚拟机。三步创建init → plan → apply代码就绪后按顺序执行三个核心命令。整个 CLI 流程与 Day 58HCL 基础 中 hello-world 示例一脉相承仓库中的 2022/Days/IaC/Hello-world/main.tf 就是那个最小示例。terraform init初始化项目并下载 Providerterraform initinit是任何 Terraform 项目的第一步解析required_providers从 Registry 下载terra-farm/virtualbox插件到本地并在项目目录生成.terraform目录与.terraform.lock.hcl锁文件记录 Provider 版本哈希保证后续执行的一致性。terraform plan预览执行计划terraform planplan会读取配置与现有状态输出一份「将要创建 / 变更 / 销毁什么资源」的执行计划相当于真正的apply之前的安全预览不会对基础设施产生任何实际改动。terraform apply落地创建terraform applyapply内置安全确认机制先展示与plan相同的执行计划并要求你输入yes才真正创建资源。下图展示了 2 台名为node[0]、node[1]的虚拟机创建完成、以及输出的内网 IP 地址完成后打开 VirtualBox 管理器即可看到 2 台正在运行的虚拟机node-01、node-02。横向扩容修改 count 增加节点Terraform 最核心的价值在于通过修改期望状态驱动基础设施变更。现在想把集群扩到 3 台只需把count从2改成3resource virtualbox_vm node { count 3 # ...其余参数保持不变 }再次执行terraform applyTerraform 会对比状态文件已有的 2 台保持不变只新增第 3 台node-03。这种「增量式、幂等化」的变更能力正是声明式 IaC 相比手工操作的根本优势——同样的配置反复执行得到的结果始终一致全程无需人工干预。terraform destroy一键清理实验结束后用一条命令移除全部资源terraform destroy同样带安全确认预览即将销毁的资源清单含虚拟机网卡等配置输入yes后执行删除如果你希望在自动化脚本中跳过确认可以在apply/destroy末尾追加--auto-approve。但建议仅在学习和测试环境使用——资源往往销毁得比创建时更快生产环境请务必保留人工确认环节。Day 58 把本次用到的 CLI 命令总结为四件套这里一并列出命令作用terraform init初始化项目目录、下载并锁定 Providerterraform plan预览将要创建、变更的资源terraform apply按代码部署资源terraform destroy销毁项目创建的资源对应的两个核心配置概念是providersTerraform 如何通过 API 与目标平台通信与resources我们想用代码部署什么。变量与输出六种定义方式与优先级Day 59 的另一个重头戏是变量系统。上一节的 hello-world 示例已经展示过output的用法本节深入变量定义。六种变量来源Terraform 允许通过以下方式为变量赋值在terraform plan/terraform apply命令中手动交互输入在.tf文件内的variable块中定义通常配合default使用系统环境变量格式为TF_VAR_变量名在项目目录放置terraform.tfvars文件作者的个人偏好也是团队协作最常见的做法使用*.auto.tfvars文件文件名以.auto.tfvars结尾Terraform 启动时自动加载无需显式指定执行命令时通过-var或-var-file参数显式传入。优先级规则上述来源的优先级从高到低即-var/-var-file最高命令行-var与-var-file*.auto.tfvars文件terraform.tfvars文件TF_VAR_环境变量.tf文件内的default默认值手动交互输入仅当变量未被任何来源赋值时才触发也就是说高优先级的来源会覆盖低优先级来源对同一变量的赋值而default仅在没有任何来源提供值时生效。原文档中「从列表底部往上数就是变量生效的顺序」描述的正是指向这一规则。仓库中的真实变量示例仓库 2022/Days/IaC/Terratest/examples/vars.tf 展示了生产风格的定义方式variable AWS_ACCESS_KEY { } variable AWS_SECRET_KEY { } variable AWS_REGION { default ap-south-1 } variable AMIS { type map(string) default { ap-south-1 ami-0860c9429baba6ad2 } }这里可以看到没有default的变量如AWS_ACCESS_KEY必须在 apply 前由外部来源提供值否则 Terraform 会交互式询问而带default的变量如AWS_REGION在未显式赋值时自动回退到默认值AMIS则演示了map(string)这类复合类型的默认值写法。配套的 terraform.tfvars 文件即用于集中存放这类敏感或区域相关的赋值。sensitive 变量保护状态文件中的敏感信息前面 Day 58 已提醒过terraform.tfstate状态文件是 JSON 格式的「Terraform 眼中的世界」其中会明文记录敏感数据。最佳实践是将.tfstate文件加入.gitignore避免提交到代码仓库生产环境把状态存到远端共享位置如 S3 桶、Terraform Cloud以换取加密、协作与自动化能力代价是增加一定的复杂度。针对敏感数据可以为变量开启sensitive标记注意 HCL 赋值语法是原文档示例中的type:应写作type variable some_resource { description something important type string sensitive true }标记后该变量在plan/apply输出中会被脱敏隐藏避免密码、密钥等直接暴露在终端日志中。延伸从本地 VirtualBox 到云端与容器本次演示虽然跑在 VirtualBox 上但掌握的原理完全可迁移把resource块换成aws_instance参考 Day 58 的 AWS 示例配合hashicorp/awsProvider即可在 AWS 上创建 EC2 并注入user_data启动脚本仓库的 2022/Days/IaC/Docker/docker.tf 与 2022/Days/IaC/Kubernetes/kubernetes.tf 还提供了用 Terraform 管理 Docker 容器与 Kubernetes 资源的示例可作为后续深入方向若要为 Terraform 代码编写自动化测试可参考仓库中的 Terratest 示例测试用例把「配置 → 应用 → 验证 → 清理」固化为可重复的测试流程。小结通过 Day 59 的完整演练你掌握了用virtualbox_vm资源 count元参数批量创建虚拟机并用format、splat 表达式、element组织名称与输出Terraform 的标准工作流init下载 Provider、plan预览变更、apply落地资源、destroy一键清理六种变量赋值方式及其优先级以及用sensitive true保护敏感信息状态文件的安全风险与远程存储方案。这套「代码定义期望状态 → Provider 执行 → 状态文件追踪」的心智模型是后续在公有云、容器与 Kubernetes 场景下使用 Terraform 的通用基础。下一节Day 60将继续深入 Terraform 的进阶用法。注原文档末尾附有若干 Terraform 学习视频与资源清单此处不再逐一罗列外部链接仓库内 2022/Days/day59.md 保留了完整原文可直接查阅。赞分享文档/教程【免费下载链接】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 实战用 Terraform 与变量在 VirtualBox 中创建虚拟机Day 5990DaysOfDevOps 实战用 Terraform 与变量在 VirtualBox 中创建虚拟机Day 59 在 90DaysOfDevOps 的文档/教程90DaysOfDevOps使用 Terraform 与变量在 VirtualBox 中创建虚拟机Day 59 实战指南90DaysOfDevOps使用 Terraform 与变量在 VirtualBox 中创建虚拟机Day 59 实战指南 本文是 90DaysOfDevO文档/教程90DaysOfDevOps 第 59 天用 Terraform 与变量在 VirtualBox 中创建虚拟机90DaysOfDevOps 第 59 天用 Terraform 与变量在 VirtualBox 中创建虚拟机 导读 本文是《90DaysOfDevOps》学文档/教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考