地形临时资源

时间:2019-07-31 02:29:05

标签: terraform

我们使用terraform,我正在尝试使开发人员能够按需分配开发资源。

一个用例是:我打开了一个新分支,编写了一些代码,我想在EC2实例+ RDS实例对上运行。是否有使用terraform动态地旋转这些资源的最佳实践方法?

我的意愿是创建一个接受变量的terraform模块,然后使开发人员可以通过命令行提供变量:

terraform apply -var 'ec2_instance_type=m4.xlarge' -var 'rds_instance_type=db.m4.xlarge' 

但是我不确定这是否是正确的解决方法。

有人对此有经验吗?我的问题是:

  • 让这些临时资源处于遥远的地形状态是否危险?
  • 应该像这样使用terraform,还是应该编写原始的awscli脚本?
  • 有没有办法在一段时间后自动删除这些资源?

非常感谢您的帮助!

2 个答案:

答案 0 :(得分:2)

看看test kitchen或类似的东西,例如terratest,可以自动运行测试。

带有terraform plugin的测试厨房将通过自动化方式管理案件,而无需您手动设置。

运行测试厨房时,它将开始运行terrain init / plan / apply,运行测试并破坏整个资源。

如果您有任何疑问,请告诉我。

答案 1 :(得分:0)

这当然不是Terraform的常用用例,但是您可以将Terraform用作大型系统的一部分,以处理实际进行更改的机制。

听起来每个开发人员的资源都有一个单独的生存期,所以我可以通过为每个开发人员拥有一个单独的状态文件然后构建一个自定义包装器工具来建模,以确保Terraform仅在两个特定的版本中运行方式:

  • 创建开发环境:给定标识符(用户名?)和输入变量的值,创建一个以该标识符命名的新Terraform workspace并在其中运行terraform apply
  • 更新/重新旋转开发环境:与创建类似,但适用于现有工作空间
  • 销毁环境:给定标识符,切换到适当的工作区并运行terraform destroy。如果成功,请删除工作区。

如果您能够为更新操作重新提供所有必要设置,则可以在Terraform远程后端之外进行任何额外存储的情况下完成上述操作。您可能会希望包装器将每个环境的输入值保存在某个地方,以便可以调用它们以应用更新,并在销毁成功后最终将其丢弃。

Terraform的主要工作流程已针对长期维护长久的基础架构进行了优化,但是围绕它的一些额外脚本,您可以利用其将所需结果转换为一组操作的核心操作,将其作为一个组件,同时构建一个不同的更高版本。级别的工作流程。