Terraform、Terragrunt、Sematic Release 和亚特兰蒂斯

基础设施即代码或 IaC 简而言之，就是使用代码管理、配置和配置您的基础设施系统（如负载平衡器、服务器、数据库等）的方法。就像使用代码构建软件应用程序一样，您可以利用代码构建自己的基础架构。使用代码创建基础设施有很多选择，每种都有自己的优点和缺点，但最常用的此类工具之一是 Terraform。 Terraform 是由 Hashicorp 创建的工具，它使用一种称为 HashiCorp 配置语言 (HCL) 的语言。使用 Terraform 的主要优点之一是 状态管理和锁定机制 .

这些机制有助于 Terraform 跟踪对系统的更改，还有助于锁定代码，以便使用版本控制等处理代码的任何其他人不会进行导致代码漂移的不必要的更改。

下面附上一个简单的代码，它在新加坡地区的 Terraform 应用程序上创建了一个名为“blog-website”的 AWS EC2 机器。请注意，我们添加了一个用于存储状态文件的 s3 存储桶和一个用于锁定状态的 Dynamo DB。

 提供者“aws”{  
 地区=“ap-southeast-1”  
 } 地形{  
 后端“s3”{  
 加密=真  
 桶=“地形状态桶博客”  
 dynamodb_table = "terraform-state-lock-dynamo-blog"  
 键=“terraform.tfstate”  
 地区=“ap-southeast-1”  
 }  
 } 资源“aws_instance”“testinstance”{ ami = "ami-123456789101112"  
 instance_type = "m5.4xlarge"  
 subnet_id = "subnet-123abcd456efg"  
 associate_public_ip_address = "假"  
 vpc_security_group_ids = [“sg-789hij101112klm”]  
 key_name "ssh 博客网站"  
 标签{  
 名称 = “博客网站”  
 }  
 }

为了更好地安排代码，我使用文件夹结构来存储各种 Terraform 文件，例如在上面的情况下，我创建如下文件夹并存储主文件我的博客网站名为 blog-website 的文件夹中的文件。

因此，如果我有更多项目，我会根据每个项目的名称相应地创建文件夹并创建主文件文件并将代码复制到每个文件夹，附在下面以供参考，这里我为孟买地区的营销网站创建了另一个文件夹并复制了相同的代码，创建了一个新的 S3 存储桶和 Dynamo DB 表用于状态管理并制作对代码的更改，例如更改网站实例名称以及 Terraform 计划和应用。

如果我有更多项目，那么我将相应地创建文件夹并每次复制代码，这看起来不错，但是如果您需要使用 Terraform 管理 100 多个或 1000 多个服务器项目文件夹怎么办？每次将代码复制到各个文件夹都很困难，并且使用相同代码管理 100 个文件夹是一团糟，此外，如果您有这样 100 个项目，那么为了保持状态和锁定，您每次都需要创建一个 s3 存储桶和每个项目的 DynamoDB 表，所以这是另外 100 个 s3 存储桶，有时可能是 100 个 DynamoDB 表！！。

在这种情况下，为了让您的代码保持干燥（不要重复自己），我们使用 Terragrunt，Terragrunt 是对 Terraform 的薄包装，我看到使用 Terraform 的主要优点之一是您不必创建每个 s3每个项目的存储桶和 DynamoDB 表，这里您只需在根文件夹中定义一次，Terragrunt 将根据路径选择它。为了更好地理解，我真的建议阅读本文 __ 基于此，我创建并安排了我的 Terraform 代码。

因此，在我的例子中，我有两个文件夹结构，单击标题以便将您带到相应的代码仓库。

基础设施-aws

▹ 这个 repo 包含我的 terragrunt 文件。

▹ 其根据项目以文件夹结构排列

▹ 每个文件夹都有 1 个 terragrunt.hcl 文件，我们在其中使用 git ref 引用模块 repo

▹ 附在参考下方，每个项目的排列方式是在相应的文件夹中每个项目都有一个 terragrunt.hcl

▹ 每个 terragrunt.hcl 都有要传递给模块 repo 并引用它的变量的详细信息。

▹ 使用 Terragrunt 帮助我们避免了将代码复制到类似的项目中，我们只需要在每个子文件夹中定义一次 terragrunt.hcl 并相应地传递变量。

▹ 正如您在下面的根文件夹中看到的，我只定义了一次状态 s3 存储桶和 DynamoDB。

基础设施模块

▹ 这个 repo 包含实际 Terraform 代码的模块

▹ 项目在基础设施-aws 中通过 git ref 使用 terragrunt.hcl 文件引用此 repo。

▹ 例如在 test-ec2 文件夹中 terragrunt.hcl 我们调用 ec2 模块并传递变量，下面附上此的参考代码。

 地形{ source = "git::https://github.com/neeltom92/infrastructure-modules.git//ec2?ref=v1.1.19" }

因此，使用 Terragrunt 帮助我们避免了重复代码，这是一件好事，也帮助我们避免在创建每个项目的 s3 存储桶和 DynamoDB 表时产生混淆。

如果您注意到上述 git 参考代码中的一件事，您会发现它使用了语义版本控制 (v1.1.19)。在我的模块仓库中，我已经实现了 语义释放 为了更好地控制我的项目。

 Semantic Release 遵循 v{Major}{Minor}{Patch} 的标准语义版本控制格式，例如 v1.2.3

因此，这带来的好处是，在将软件项目发布到生产环境时，版本控制可能是一个很容易被忽视的话题，因为它过于琐碎并且需要手动完成，这个特性有助于实现自动化。只需添加适当的提交消息，它就会自动标记和版本您的项目。下面附上参考资料。

我利用 Github 操作对该链接引用的项目进行版本控制 https://svdoscience.com/2020-10-31/versioning-with-semantic-release , 添加为 Github 操作工作流程，例如这里 .

并根据提交消息相应地增加版本。假设我们要提交一个新的更改，你的提交消息应该遵循格式“New：添加新功能”，其中“New”这个词匹配 { “tag”: “New”, “release”: “minor” } release规则，例如，从 v1.0.0 到 v1.1.0）。同样，当我们使用“Fix: fix bug 123”提交消息提交修复时，这将匹配 { “tag”: “Fix”, “release”: “patch” } 发布规则，并将增加补丁版本（例如, 从 v1.0.0 到 v1.0.1)

例如，如果我需要将 v1.1.19 升级为“新版本”v1.2.0，我会进行更改并将代码添加到存储库，然后使用适当的提交消息将代码推送到远程存储库。正如您在提交消息中看到的那样，我使用关键字“New”添加了正确的消息。

提交将导致更新发布标签的 Github 操作。

GitHub 操作会自动更新发布标签。

语义版本控制是一个很好的功能，您可以轻松地将其添加到您的存储库中以保持其正确的版本控制，并有助于了解任何读者您项目的发布版本。接下来解释亚特兰蒂斯。

作为软件工程师，可以帮助我们更好地编码的一件事是同行评审，因为如今大多数代码都在版本控制中，如 GitHub 或 Gitlab，并且像任何常规编程语言一样，我们需要适当的同行评审并更好地理解代码在被推送之前的作用到生产， 亚特兰蒂斯 就是这样一个工具。

亚特兰蒂斯非常强大，它可以做很多事情，比如在你的拉取请求中帮助同行评审，并应用代码来创建基础设施发表评论等。要安装亚特兰蒂斯，你需要一个 K8s 集群并发布参考此链接进行安装 https://www.runatlantis.io/docs/installation-guide.html

这里需要注意的一点是，上述步骤是针对 Terraform 的配置，对于 Terragrunt 来说有点不同。此处提到了 Terragrunt 的解决方法： runatlantis.io/docs/custom-workflows.html#terragrunt 唯一的问题是我们需要更改 Atlantis pod 的镜像，因为默认的 Atlantis 镜像没有 Terragrunt 二进制文件，因此您必须创建一个新的镜像，并将适当的二进制文件添加到镜像中，然后使用 k8s 在 k8s 中安装 Atlantis 应用程序这个带有 Terragrunt 二进制文件的新图像。 runatlantis.io/docs/deployment.html#customization

正确配置并添加 webhook 后，您就可以添加亚特兰蒂斯工作所需的 atlantis.yaml上。