我们计划自动化创作＆amp;删除我们的DC中的VM，为我们的云服务提供支持。该服务使每个新客户都获得专用虚拟机（至少3个） - 因此虚拟机数量不断增长。我们已经在ESXi上运行了大约2000个VM。因此，在采用terraform之前，我们现在有两个问题需要解决 -
我们如何迁移Terraform管理的现有虚拟机（或者我们应该根除）？ 生成资源规范可以编写脚本，但验证计划以确保不会受到影响将是一个挑战 - 考虑到VM的数量和他们都是LIVE的事实给工程师带来了额外的压力。
随着虚拟机数量的增加，磁盘上的.tf文件数量将不断增加。我们可以将多个虚拟机集成到一个文件中，但这会以编程方式删除单个虚拟机，有点棘手。将文件拆分成多个目录是我能想到的简单解决方法，但...... 有没有更好的方法来处理使用terraform的比例？
我找不到任何讨论这些问题的博客，因此在这里寻找一些实践经验的建议。
答案 0 :(得分：4)
很高兴看到社区开始越来越多地询问有关Stack Overflow的Terraform相关问题。
关于你的问题：
迁移由Terraform管理的现有VM意味着更新tfstate文件。截至目前，无法为已创建的资源创建资源定义并自动将其放入状态文件中（尽管有Terraforming等工具，它可以部分地执行，仅适用于AWS资源）。因此，您必须在*.tf文件中描述资源，手动更新tfstate文件，然后通过运行tfstate == tf来验证terraform plan，这应该说没有应该应用的更改。关于究竟要放入tfstate文件的内容 - 我建议首先在tf创建资源定义，然后基于此创建虚拟VM（terraform apply），在更新的tfstate文件中查找相关对象并使用tfstate文件中虚拟机的实际值更新这些虚拟值（您还需要更新serial以防止本地/远程状态不一致错误。）
除了按目录分组之外，我不知道处理大量相关资源的其他更智能的方法。通过这种方式，您可以仅针对特定的逻辑分离目录执行计划/应用，但您必须具有分离的状态文件。它可能很容易过度杀戮（警告 - 所以不要在家试试）。
在使用Terraform时，我一直都会考虑这些建议（特别是拥有大量资源）：
-target标记来限制您要触摸的资源。希望它有所帮助！更多人会喜欢Terraform。