将 Terraform 状态迁移到 GitLab CI/CD 的便捷指南

作为处理基础架构即代码 (IaC) 的软件专业人员，您很可能经常使用地貌.在帮助新客户使用 IaC 时，通常会简化事情，但管理 Terraform 状态文件是您面临的第一个挑战。本质上，Terraform 状态包含不应由源代码控制存储的敏感信息，但同时，如果您有多个用户在同一个 Terraform 状态上工作，则这些信息将无法扩展。答案是什么？后端。

请务必注意，您可以将该状态文件存储在 S3 存储桶中并使用 DynamoDB 来管理锁定状态。但是，这种方法将迫使您创建额外的资源，这使其成为一个复杂的选择，尤其是在客户端使用 GitLab 的情况下。 GitLab 最近通过提供一种存储和管理 Terraform 状态的方法，以及一种围绕它设置 CI 的简单方法，降低了集成 Terraform 的入门门槛。

在这篇博文中，我们将解释什么是 Terraform 状态文件，如何将其迁移到 GitLab，并为其设置 CI 管道。您可以访问我们的存储库这里.

目录

• 什么是 Terraform 状态？
• 如何让 GitLab 管理 Terraform 状态
• 如何让 GitLab 通过 CI 管道运行你的 IaC
• 额外提示：基础设施成本
• 结论

什么是 Terraform 状态？

Terraform 通过状态文件记录有关代码中定义的基础设施的任何信息。它以 JSON 编写，本质上记录了从 Terraform 代码到创建的真实资源的映射。下面是 terraform.tfstate 的示例。

首先，每次运行 Terraform 时，它都会获取其 EC2 实例的最新状态，并将其与 Terraform 配置进行比较，以确定需要应用哪些更改。

 { "version": 4, "terraform_version": "0.12.0", "serial": 1, "lineage": "1f2087f9-4b3c-1b66-65db-8b78faafc6fb", "outputs": {}, "resources": [ { "mode": "managed", "type": "aws_instance", "name": "example", "provider": "provider.aws", "instances": [ { "schema_version": 1, "attributes": { "ami": "ami-0c55b159cbfafe1f0", "availability_zone": "us-west-2a", "id": "i-00a123a0accffffff", "instance_state": "running", "instance_type": "t2.micro", "(...)": "(truncated)" } } ] } ] }

默认情况下，此 terraform.tfstate 存储在您拥有 Terraform 文件、规划和应用更改的本地位置。对于您只是运行一些测试的个人项目，这很好但不是推荐的方式，原因如下：

• 存储在共享位置：如果您在本地工作站上托管此状态文件并且必须与另一位工程师合作，事情就会变得复杂。你们两个都必须确保您使用的是最新版本的状态，如果您同时运行 Terraform 计划或申请，您可能会遇到竞争条件。
• 保护敏感信息：生成的状态文件可以包含加密密钥和基础设施密码。但是，默认情况下状态文件不加密，以纯文本形式存储敏感信息不是一个好主意。
• 锁定：大多数版本控制系统不支持任何形式的锁定，以防止两个团队成员同时在同一个状态文件上运行 Terraform apply。这是我们看不到由源代码管理管理的状态文件的另一个原因。

‍

如何让 GitLab 管理 Terraform 状态

随着 Terraform 被认为是云基础设施配置的标准，GitLab 开始提供一种存储和管理 Terraform 状态的方法已经有一年左右的时间了。出于这个原因，我们希望与您分享迁移过程，因为我们最近开始使用 GitLab 来管理我们的 IaC。

对于本文，我们假设您正在使用本地状态，并使用 AWS S3 Bucket 或其他后端解决方案管理您的状态。

首先，您需要更改 backend.tf 以使用 HTTP。

 terraform { backend "http" {} }

接下来，您需要在终端中设置 4 个变量：

• PROJECT_ID：您可以通过在“项目概述”页面上导航到您的存储库来轻松找到它

__ __

‍

• TF_USERNAME：可以访问您正在处理的仓库的 Gitlab 用户名。
• TF_PASSWORD：从您的 GitLab 用户生成的访问令牌。
• TF_ADDRESS：远程状态后端的URL

 PROJECT_ID="28450092" TF_USERNAME="florianpialoux" TF_PASSWORD="123456789" TF_ADDRESS="https://gitlab.com/api/v4/projects/${PROJECT_ID}/terraform/state/aws-buckets"

您现在可以运行迁移命令，使用以下命令将您的 Terraform 状态从他以前的位置移动到 GitLab：

 terraform init \ -migrate-state \ -backend-config=address=${TF_ADDRESS} \ -backend-config=lock_address=${TF_ADDRESS}/lock \ -backend-config=unlock_address=${TF_ADDRESS}/lock \ -backend-config=username=${TF_USERNAME} \ -backend-config=password=${TF_PASSWORD} \ -backend-config=lock_method=POST \ -backend-config=unlock_method=DELETE \ -backend-config=retry_wait_min=5

您需要提供“是”的确认，以便 GitLab 可以开始管理您的状态文件。这是从本地状态到 GitLab 的示例：

__ __

GitLab 的示例 s3

__ __

现在您可以从 GitLab 界面导航到Infrastructure > Terraform并查看您的状态：

__ __

我注意到即使在使用之前运行的 migrate-state 命令之后，我从 s3 获得的一些状态文件仍然是空白的，在这种情况下，您可以运行以下命令：

 terraform state pull > aws-buckets.json

从 s3 状态复制并粘贴内容并运行推送：

 terraform state push -lock=true aws-buckets.json

GitLab 支持 Terraform 状态文件的版本控制，但通过 WebUI 查看/恢复旧版本将需要您使用GitLab 高级计划.如果没有，您将需要制作一个 GraphQL API要求.

‍

如何让 GitLab 通过 CI 管道运行你的 IaC

GitLab 提供码头图像包含 GitLab-Terraform，它是官方 Terraform 二进制文件的薄包装脚本。或者，您可以使用官方码头图像由哈希公司。您可以找到有关 GitLab Terraform Image 的更多信息这里.

terraform apply 作业运行后，您将能够看到使用状态的时间以及使用的管道。

__ __

了解更多关于我们的gitlab-ci.yml的样子这里.以下是需要在项目级别定义的变量：

__ __

额外提示：基础设施成本

您可能已经注意到，查看我们添加的 gitlab-ci.yaml基础设施成本这使我们能够更好地控制我们的云计费，因为每当您为 IaC 定义新资源时，它都会为您提供成本估算。要了解有关 Infracost 的更多信息，您可以查看我们的深入文章关于它需要什么，以及我们的一步一步指导关于如何将它与 Terraform 集成。

结论

让 Terraform 状态和 CI 在 Gitlab 上运行是遵循 GitOps 最佳实践的好方法。它们都是开发和部署 IaC 的绝佳组合。由于你们中的大多数人可能已经在为您的存储库使用 GitLab，因此将 IaC 放在一个屋檐下并让 GitLab 通过支持传输中和静态加密以及版本控制、锁定和解锁来管理您的 Terraform 状态变得更加简单状态。