要配置 Terraform ?给您五条建议

本文介绍我使用 Terraform 五年之后吸取到的经验。

使用 Terraform 五年的经历让我吸取到一些重要经验。无论团队大小、项目性质,有五条要点对于配置合乎逻辑且可用的 Terraform 平台至关重要。

1、了解你的目标受众

这一点似乎显而易见,但我也见过一些在这方面犯错的案例。当组织和规划 Terraform 的相关代码时,无论是将目录结构标准化还是确定命名规范,考虑目标受众是非常重要的。例如:你的团队是否会使用这些 Terraform 脚本和模块?你是否会向其他团队交接工作?你的团队是否会有新成员加入?你是否正在独自进行项目开发?你是否会半年或一年后仍然使用这些配置,还是会将它安排给别人?

这类问题会影响某些决策。理想情况下,无论如何都应该有 ​​远程状态​​Remote State 和 ​​状态锁定​​State Locking

命名规范应该对项目的最终拥有者有意义,而不是只对开发团队有意义。如果项目会转交给其他团队,应该确保他们对命名规范有发言权。如果代码由非技术的利益相关者或内部安全/ GCR 团队负责审查,应该确保他们会检查命名规范。另外,对于资源名称,为了让代码审查人员更仔细地进行检查,你应该使用资源标签,把有关的数据分类/隐私需求(高、中、低)标示出来。

2、重用,重用,重用

​​Terraform 注册表​​ 为大多数普通用例提供了现成模块类库。我已经使用过 VPC 模块和安全模块中的大量功能,这些功能只需要提供相关的参数就能使用。使用不同的参数,简单调用这些模块对于处理大部分用例已经足够了。尽可能多地重用这些公共模块,可以避免大量且重复的编码、测试、检查、修复、重构等操作。

我也发现,基于使用或变更的频率划分模块和资源大有好处。例如,只使用一次的基础设施手脚架,例如 VPC 相关设置、安全模块、路由表、VPC 端点等,可以放在一起。但是像私有托管域条目、自动伸缩模块、目标模块、负载均衡器等,每次部署时都会变化,所以把这些与一次性的基础设施手脚架分离开来,会令代码检查更方便,调试更快速。

3、要明确,而非隐含

Terraform 代码中有一些常见的模式,它会导致设计中出现错误的假设。团队可以假设用来写代码的 Terraform 版本永远保持不变,外部模块不会变化,或它们使用的提供者不会变更。当这些外部依赖不可避免地发生变化时,就会导致一些难以发现的问题。

无论何处(包括主要的 Terraform 组、提供者组、功能模块组)都要确保定义是明确的。事先定义版本,可以确保依赖库是固定的,因此你可以在讨论、审查、测试后,明明白白地更新依赖关系。

4、自动化每一处,包括笔记本电脑、共享虚拟机、CI/CD。

在部署的各个阶段使用自动化方法,可以避免可能发生的问题。

在你提交代码前,使用 ​​Git 预提交钩子​​ 运行 ​​terraform fmt​​ 和 ​​terraform validate​​。预提交钩子的作用是确保你的代码满足最低程度的格式和语法正确。把这个预提交文件检入到仓库,对你的团队成员都有好处。项目的第一步就进行质量控制相关的操作,它虽然表面上是小事一桩,但也很重要,能为项目节省大量时间。

一切现代化部署工具都有 CI 流程。当你向原始仓库推送代码时,可以使用它来运行 SAST 和单元测试工具。我写过一篇 ​​博客​​,是关于使用 Checkov 测试 Terraform 代码的安全性和合规性,并为组织特定的惯例创建自定义检查。把这些单元测试工具加入到你的 CI 管道,可以改进代码质量和健壮性。

5、写个好的 README.md 文件

我们都认为 Terraform 代码是自文档化的。的确如此,但是只有当未来的团队已经了解你的公司的命名规范、开发指南、机密通信、圈内笑话,以及你的仓库内除有效的 Terraform 代码之外其他所有东西,才会如此。维护 ​​README.md​​ 文件是个好习惯,它能节省大量时间,而且团队成员要为自己向 README 文件提交的任何内容负责,这样也就确保团队成员的忠诚度。

你的 README 文件至少应该包含在你的工作环境下(Linux、 Windows、Mac 等等)初始化 Terraform 环境的步骤,包括 Terraform 的版本信息。它应当确定需要的依赖库(Checkov、 TerraGrunt 及其他依赖)和其版本,以及团队使用的方便的 Linux 别名(例如有人喜欢将 ​​terraform fmt​​ 简写为 ​​tff​​)。最重要的是,需要确定分支和 PR 审核策略和流程、命名规范和资源标签的相关标准。

README 文件需要通过这样的检验:如果团队有新成员加入,能否告诉他们做什么以及如何正确地完成工作?如果不能,在后续的几个月内,你将面对的是无休止的标准和流程讨论会议。

结束语

这些就是我使用 Terraform 多年后,认为需要传授给大家的五条有用的建议。

 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
以下是使用Terraform配置ECS的步骤: 1. 安装Terraform:首先,您需要在本地计算机上安装Terraform。您可以从Terraform官方网站下载适用于您操作系统的安装程序,并按照说明进行安装。 2. 创建Terraform配置文件:在您的项目目录中创建一个新的Terraform配置文件(例如,main.tf)。在该文件中,您可以定义您的ECS集群的配置。 3. 引入必要的提供者:在配置文件的开头,您需要引入AWS提供者。您可以使用以下代码行引入AWS提供者: ```terraform provider "aws" { region = "your_aws_region" } ``` 请将"your_aws_region"替换为您要使用的AWS区域。 4. 定义ECS集群:使用以下代码行在配置文件中定义ECS集群: ```terraform resource "aws_ecs_cluster" "ecs_cluster" { name = "your_cluster_name" } ``` 请将"your_cluster_name"替换为您要创建的ECS集群的名称。 5. 配置ECS服务:使用以下代码行在配置文件中定义ECS服务: ```terraform resource "aws_ecs_service" "ecs_service" { name = "your_service_name" cluster = aws_ecs_cluster.ecs_cluster.id task_definition = aws_ecs_task_definition.ecs_task_definition.arn desired_count = 1 } ``` 请将"your_service_name"替换为您要创建的ECS服务的名称。 6. 配置ECS任务定义:使用以下代码行在配置文件中定义ECS任务定义: ```terraform resource "aws_ecs_task_definition" "ecs_task_definition" { family = "your_task_definition_family" container_definitions = file("path_to_container_definitions_file") requires_compatibilities = ["FARGATE"] network_mode = "awsvpc" cpu = "256" memory = "512" } ``` 请将"your_task_definition_family"替换为您要创建的ECS任务定义的名称,并将"path_to_container_definitions_file"替换为包含您的容器定义的文件路径。 7. 部署ECS堆栈:在命令行中导航到您的项目目录,并运行以下命令来初始化Terraform并部署ECS堆栈: ```shell terraform init terraform apply ``` 这将初始化Terraform并根据您的配置文件创建ECS集群和服务。 请注意,上述步骤仅提供了一个基本的配置示例。根据您的需求,您可以进一步配置ECS集群和服务,例如定义任务定义参数、容器定义和其他资源。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值