Terraform 最佳实践¶

一最佳实践¶

Plan before Apply/Stage before Prod

在正式应用资源清单钱，先plan，为保障线上安全，需要现在dev/stage环境测试，再上prod

环境隔离(global/stage/prod/mgmt)

单个环境进行隔离

每个目录单独.tfstate 状态管理，避免项目冲突与混乱

目录间使用terraofrm_remote_state共享状态
功能组件分离(web/db...)
使用模块modules
Version Constraints
variable中添加validation rules
使用带模版的模块(git ref)
将模块代码放到单独Repo
Remote state存储使用加密，并启用版本（S3 Versioning）
TF模版中避免硬编码（eg：使用date获取vpc_id/account_id/region）
Tag（跟踪成本/区分手动创建）
使用terrascan扫描隐患。
module编写完成后，
利用terraform fmt格式化内容
利用terratest进行测试

二编写module规范¶

Module 仓库建立完毕后，首先要 fork 仓库并将其clone到本地。接下来，开始 Mudole 的编写工作。官方已经给出了一个标准的 Module 应该遵循的原则和规范，详见 standard-module-structure . 本文将在此基础上进行补充。

基本原则每个Module不宜包含过多的资源，要尽可能只包含同一产品的相关资源，这样带来的好处是Module的复杂度不高，便于维护和阅读；对于统一产品的不同资源，应该分别放在不同的子module中，然后在最外层的main.tf中组织所有的子资源，比如 module slb 中定义了两个资源 slb instance 和 slb attachment，这两个子资源分别定义在了 modules/slb 和 modules/slb_attachment 中，然后在最外层的 main.tf中将这两个module组合为一个新的module 每个module要尽可能单元化，以便可以在实际使用过程中自由添加和删除而不影响其他resource。即一个module尽可能叙述1-2件事情，如创建一个slb实例，并将一组ecs的挂载到这个slb下（slb的作用就是实现对ecs的负载均衡），至于slb的listener配置，应该放置在一个独立的mudule中，一方面listeners比较复杂，涉及四种协议，另一方面，对于同一协议的listener，除了监听端口外，大部分的配置都是相同的，而这些相同的配置可以通过一个单独的module被复用在不同其他资源模板中；模板编写过程中，需要使用到大量的TF语法，详见configuration syntax 和 interpolation syntax。
main.tf 每个 Module 都必须包含一个 main.tf 用于存放 resource 和 datasource。resource和datasource的参数禁止使用硬编码，必须通过变量进行引用；为了标准起见，每个 resource 和 data source 的命名均以一些关键字或者关键字前缀为主，如this，default，尽量避免使用foo，test等为了更好的了解Module被他人引用的次数，阿里云Provider支持对每个Module进行打标，即在main.tf的provider中声明字段configuration_source，格式如下： provider "alicloud" { ... configuration_source = "terraform-alicloud-modules/demo" // This should be replaced by the specified owner and module name }
variables.tf 每个变量都要添加该参数对应的描述信息，这个信息最终是要呈现在terraform registry官网上的；对于一些非关系型的参数，可设置一个默认值，如name，description等对于复杂类型的变量，要显示声明其类型，如list，map 子资源的变量要在Readme中以列表的形式予以呈现
outputs.tf module中output的作用是被其他模板和module引用，因此，每个module要讲一些重要的信息输出出来，如资源ID，资源name 等；重复资源的变量要以列表的形式予以输出，如module ecs-instance中，创建多个instance资源，这些资源的ID应该输出到一个list变量instance_ids中和variables一样，子资源的output变量也要在Readme中以列表的形式予以呈现
README 描述下当前Module是用来干什么的，涉及哪些resource和data source 增加 Usage，指明该如何使用这个 Module。Module 的source 格式为 source = "//alicloud"，如：source = "terraform-alicloud-modules/slb-listener/alicloud" 添加module暴露的入参和出参，帮助开发者更好的使用Module 具体细节可参考其他module
执行可开启日志

export TF_LOG=TRACE
export TF_LOG_PATH=./terraform.log

执行完毕后，可查看 Terraform 本地文件夹会生成一个 terraform.log 的文件。文件记录了 provider 定义的日志输出。

三实战¶

3.1 使用stats文件作为查询源¶

在实际应用场景中，可能module A 需要依赖已经运行完成后的module B 的outputs，例如实例绑定安全组，需要先运行安全组module将结果存储在state文件中，module A以module B的运行结果state文件作为数据输入源进行查询操作。

例如使用cos作为backend后端存储。

provider "tencentcloud" {
  region = "ap-beijing"
}

terraform {
  required_providers {
    tencentcloud = {
      source  = "registry.terraform.io/tencentcloudstack/tencentcloud"
      version = ">=1.61.5"
    }
  }
  backend "cos" {
    region = "ap-beijing"
    bucket = "cfabackend-xxxxxx"
    prefix = "terraform/state"
  }
}

使用cos中的state文件作为terraform_remote_state。

data "terraform_remote_state" "cam" {
  backend = "cos"
  config = {
    region = "ap-beijing"
    bucket = "cfabackend-xxxxxx"
    prefix = "terraform/state"
  }
}

locals {
    standards = data.terraform_remote_state.cam.outputs
}

output "result" {
  value = {
    items = { for k, v in local.standards :k=>v}
  }
}

Terraform 最佳实践¶

一 最佳实践¶

二 编写module规范¶

三 实战¶

3.1 使用stats文件作为查询源¶

一最佳实践¶

二编写module规范¶

三实战¶