gpt4 book ai didi

terraform - 亚特实验室 CI : terraform destroy doesn't destroy?

转载 作者:行者123 更新时间:2023-12-02 03:07:06 27 4
gpt4 key购买 nike

我定义了以下简单的管道:

image:
name: hashicorp/terraform:light
entrypoint:
- '/usr/bin/env'
- 'PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'

variables:
PLAN: dbrest.tfplan
STATE: dbrest.tfstate

cache:
paths:
- .terraform

before_script:
- terraform --version
- terraform init

stages:
- validate
- build
- deploy
- destroy

validate:
stage: validate
script:
- terraform validate

plan:
stage: build
script:
- terraform plan -state=$STATE -out=$PLAN
artifacts:
name: plan
paths:
- $PLAN
- $STATE

apply:
stage: deploy
environment:
name: production
script:
- terraform apply -state=$STATE -input=false $PLAN
- terraform state show aws_instance.bastion
dependencies:
- plan
when: manual
only:
- master

destroy:
stage: destroy
environment:
name: production
script:
- terraform destroy -state=$STATE -auto-approve
dependencies:
- apply
when: manual
only:
- master

当我运行它时,一切都非常成功 - 但 destroy 阶段实际上并没有破坏我在 apply 阶段创建的环境。这是我所看到的:

Running with gitlab-runner 10.5.0 (80b03db9)
on ip-10-74-163-110 5cf66672
Using Docker executor with image hashicorp/terraform:light ...
Pulling docker image hashicorp/terraform:light ...
Using docker image sha256:5d5c9faad78b96bb84555a584fe729260d7ff7d3fb973e105690ddc0dab48fb5 for hashicorp/terraform:light ...
Running on runner-5cf66672-project-1136-concurrent-0 via ip-10-197-79-116...
Fetching changes...
Removing .terraform/
Removing dbrest.tfplan
Removing dbrest.tfstate
HEAD is now at f798b05 Update .gitlab-ci.yml
Checking out f798b05a as master...
Skipping Git submodules setup
Checking cache for default-1...
Successfully extracted cache
$ terraform --version
Terraform v0.12.13
+ provider.aws v2.34.0
$ terraform init

Initializing the backend...

Initializing provider plugins...

The following providers do not have any version constraints in configuration,
so the latest version was installed.

To prevent automatic upgrades to new major versions that may contain breaking
changes, it is recommended to add version = "..." constraints to the
corresponding provider blocks in configuration, with the constraint strings
suggested below.

* provider.aws: version = "~> 2.34"

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
$ terraform destroy -state=$STATE -auto-approve

Destroy complete! Resources: 0 destroyed.
Creating cache default-1...
.terraform: found 5 matching files
Created cache
Job succeeded

很明显,我调用 terraform destroy 的方式缺少了一些东西,但我不知道是什么 - 有人可以解释一下吗?

最佳答案

您没有正确地从 apply 作业传递状态,因为您没有像 plan -> apply< 那样设置工件。您的申请工作应如下所示:

apply:
stage: deploy
environment:
name: production
script:
- terraform apply -state=$STATE -input=false $PLAN
- terraform state show aws_instance.bastion
artifacts:
name: apply
paths:
- $STATE
dependencies:
- plan
when: manual
only:
- master

但是,更好的解决方案是不在这里使用基于文件的状态,而是使用正确的 remote state (例如 S3 如果您使用的是 AWS),或者稍后当多个用户(包括 CI 作为潜在的自并发用户)运行 Terraform 时,您将会遇到大量问题。这使您可以利用state locking并且还允许对状态文件进行版本控制,以防 Terraform 操作期间出现问题,例如将状态作为重构的一部分移动。

关于terraform - 亚特实验室 CI : terraform destroy doesn't destroy?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/58728425/

27 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com