CircleCI 中的 Terraform 破坏失败 [英] Terraform destroy fails in CircleCI

问题描述

我目前使用 CircleCI 作为我的 CI 工具来使用 Terraform 构建 AWS 基础设施

I am currently using CircleCI as my CI tool to build AWS infrastructure using Terraform

我的流程是，

1. 使用 Terraform 创建 AWS 实例
2. 安装 Docker 并在其上运行 Nginx 映像
3. 破坏基础设施

我的 CircleCI 配置如下，

My CircleCI config is as follows,

version: 2
jobs:
  terraform_apply:
    working_directory: ~/tmp
    docker:
            - image: hashicorp/terraform:light
            - image: ubuntu:16.04

    steps:
      - checkout
      - run:
          name: terraform apply
          command: |
            terraform init
            terraform apply -auto-approve
      - store_artifacts:
          path: terraform.tfstate

  terraform_destroy:
    working_directory: ~/tmp
    docker:
            - image: hashicorp/terraform:light
            - image: ubuntu:16.04
    steps:
      - checkout
      - run:
          name: terraform destroy
          command: |
            terraform init
            terraform destroy -auto-approve

workflows:
  version: 2
  terraform:
    jobs:
      - terraform_apply
      - click_here_to_delete:
          type: approval
          requires:
            - terraform_apply
      - terraform_destroy:
          requires:
            - click_here_to_delete

这里我使用了 2 个作业，一个用于创建，一个用于在 CircleCI 工作流程中删除.

Here I am using 2 jobs, One for the creation and one for Deletion in CircleCI workflow.

我的第一份工作运行成功，但是当我开始第二份工作时，它从头开始，所以我无法获得以前的 terraform 应用状态，因此 terraform 无法破坏我已经创建的基础架构.

My first job is running successfully but when I started second it start from scratch so I could not get previous terraform apply state hence terraform could not destroy my already created infrastructure.

我正在寻找一些解决方案，我可以以某种方式保存状态文件并将其复制到 terraform 可以破坏我以前的架构的下一个工作

I am looking for some solution where I can somehow save state file and copy it to next job where terraform can destroy my previous architecture

推荐答案

你应该使用 远程状态.

本地状态只有在你总是在同一台机器上运行并且不关心如果你不小心删除某些东西等情况下丢失你的状态文件时才有用.

Local state is only ever useful if you are always running from the same machine and don't care about loss of your state file if you accidentally delete something etc.

您可以混合和匹配任何可用的状态后端，但由于您已经在使用 AWS，因此使用 S3 后端.

You can mix and match any of the available state backends but as you're using AWS already it probably makes most sense to use the S3 backend.

您需要为每个位置定义状态配置，这可以在配置中完全硬编码完成，完全通过命令行标志或部分使用两者.

You will need to define the state configuration for each location which can be done entirely hardcoded in config, entirely by command line flags or partially with both.

作为一个例子，你应该在每个运行 Terraform 的目录中都有这样的块:

As an example you should have something like this block in each of the directories you would run Terraform in:

terraform {
  backend "s3" {}
}

然后您可以在 完成配置href="https://www.terraform.io/docs/commands/init.html" rel="nofollow noreferrer">terraform init:

You could then finish configuring this during terraform init:

terraform init -backend-config="bucket=uniquely-named-terraform-state-bucket" 
               -backend-config="key=state-key/terraform.tfstate"

运行 terraform init 后，Terraform 将从 S3 获取任何计划的状态.然后在 terraform apply 或 terraform destroy 上，它将根据需要更新状态文件.

Once you have ran terraform init, Terraform will fetch the state from S3 for any plans. Then on a terraform apply or terraform destroy it will update the state file as necessary.

这将允许您在同事之间以及 CI/CD 机器之间轻松共享状态.您还应该考虑使用 DynamoDB 查看 状态锁定 以防止状态被破坏由多人同时修改状态.同样，您还应该考虑在用于存储状态的 S3 存储桶上启用版本控制，以便在出现任何问题时始终可以恢复到状态的早期版本.

This will then allow you to share the state easily among colleagues and also CI/CD machines. You should also consider looking into state locking using DynamoDB to prevent state from being corrupted by multiple people modifying state at the same time. Equally you should also consider enabling versioning on the S3 bucket used for storing your state so you can always get back to an earlier version of the state in the event of any issues.

这篇关于CircleCI 中的 Terraform 破坏失败的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！