## 两个版本的 Terraform 有什么区别，推荐使用哪一款？ cc 版本的 terraform volcenginecc provider 和旧版的 terraform volcengine provider 是两个完全独立的 Provider，相较于旧版 Terraform 在资源模型一致性、新产品特性覆盖等方面的局限，cc 版本的 IaC 依托 CCAPI 提供统一的资源操作接口，具备更完善的资源支持矩阵、更清晰的版本演进路径以及更强的稳定性保障。因此，**我们推荐您使用 cc 版本的 Terraform 工具，以获得更统一的资源管理体验和更可持续的长期支持**。 ## 如果我已经使用老版本的 Terraform，如何迁移呢？如果您正在使用老版本的 IaC 工具，我们为您提供了两种迁移路径，您可以根据团队情况和业务复杂度灵活选择。 | |**方案描述** |**适用场景** |**优点** |**缺点** | |---|---|---|---|---| |方案一（**推荐**）|在同一个 Terraform 项目中同时使用旧版 Terraform 和 Terraformcc，实现平滑、渐进的迁移。|1. 生产环境复杂，希望最大程度降低迁移风险。|风险低，迁移过程平滑可控，不影响现有基础设施的稳定性，实现渐进式迁移，您可以按照自己的业务节奏逐步适应和采纳新技术。 |短期内会增加一定的代码管理复杂度，需要明确区分两个 Provider 的使用边界 |\ | | |2. 存量 IaC 代码规模较大，无法一次性完成重构。| | |\ | | |3. 希望在新业务或新模块中优先试用 Terraformcc。 | | | |方案二 |完整梳理当前代码结构，将存量资源和代码一次性切换到 Terraformcc |1. 适用于希望彻底统一 Terraform 依赖、避免长期维护双轨系统的场景。|一步到位，彻底享受 Terraformcc 带来的所有优势，降低长期维护成本。 |迁移风险相对集中，依旧需要人工确认和手动修改代码及状态文件，对复杂的代码框架的处理要求较高，需要进行详细的可迁移性分析、备份和迁移后的验证。 |\ | | |2. IaC 项目框架清晰，规模较小，项目资源依赖关系清晰。| | |\ | | |3. 有充分的测试窗口，能够对迁移后的基础设施进行全面验证。 | | | 如果您选择混用，以下示例展示了如何在同一个程序中同时使用两个版本的 IaC 工具： ```Python // 使用旧版 Terraform 工具创建一个私有网络，然后使用 cc 版本的 Pulumi 创建一个路由表，并关联到该私有网络。 terraform { required_providers { volcengine = { source = "volcengine/volcengine" version = ">= 0.0.173" } volcenginecc = { source = "volcengine/volcenginecc" version = ">= 0.0.30" } } } # use volcenginecc create vpc resource "volcenginecc_vpc_vpc" "tfcc_vpc" { vpc_name = "vpc-demo" cidr_block = "172.16.0.0/16" } # use volcengine create route_table resource "volcengine_route_table" "tf_route_table" { vpc_id = volcenginecc_vpc_vpc.tfcc_vpc.vpc_id route_table_name = "route-table-demo" } ``` ## 已经在控制台创建的资源能纳入 Terraform 管理吗？可以。通过 import 功能将已有资源导入 Terraform 管理范围，导入后编写对应的配置文件描述这些资源，即可通过 Terraform 统一管理。 ## 通过 Terraform 管理的资源还能在控制台操作吗？技术上可以，但不推荐。Terraform 通过状态文件追踪资源状态，在控制台手动修改会导致状态文件与实际状态不一致，下次执行时可能覆盖手动修改或产生冲突。建议 Terraform 管理的资源统一通过 Terraform 操作。