상태만 고치면 되는데 자원을 다시 만들 뻔했다

목표

새로고침 전용 계획과 적용, 실물을 읽지 않는 계획의 착시, 저장한 파괴 계획, 파괴의 역순, 대상을 좁힌 파괴의 경고, 그리고 다 지운 뒤 상태에 남는 것까지를 OpenTofu 로 하나씩 확인합니다.

왜 중요한가

계획은 두 가지를 견줍니다 — 코드와 상태, 그리고 상태와 실물입니다. 이 둘을 따로 다룰 수 있다는 것이 새로고침 계열 명령의 핵심입니다. 상태가 실물과 어긋났을 뿐이라면 코드를 건드리지 않고 상태만 맞출 수 있고, 그러면 자원을 다시 만들지 않아도 됩니다. 반대로 실물을 읽지 않고 계획을 뽑으면 도구는 상태에 적힌 값을 사실로 믿습니다. 큰 저장소에서 속도를 얻는 대신 정확도를 내주는 선택인데, 그렇게 뽑은 계획으로 승인을 받으면 어긋난 채로 적용이 들어갑니다. 파괴 쪽도 순서가 전부입니다. 만드는 순서의 역순으로 지워야 아직 남은 것이 이미 사라진 것을 가리키지 않습니다. 대상을 좁혀 지우면 그 보장이 깨지므로 도구가 경고를 붙입니다. 마지막으로 다 지운 뒤에도 상태 파일 자체는 남는다는 것을 알아야 '상태를 지우는 것' 과 '자원을 지우는 것' 을 헷갈리지 않습니다.

단계

1. /root/tfb-refresh/base/main.tf 에 app.conf 에 mode=managed 한 줄을 쓰는 local_file.conf 와, 그 리소스의 id 를 conf=<id> 한 줄로 audit.txt 에 쓰는 local_file.audit 를 두세요. init·apply 하고 계획이 깨끗한지 확인하세요.
2. 도구를 거치지 않고 /root/tfb-refresh/base/app.conf 를 HANDEDIT 한 줄로 바꾸세요. 그다음 tofu plan -refresh-only 출력을 /root/tfb-refresh/refresh-plan.txt 에 저장하세요. 아직 아무것도 적용하지 마세요.
3. 같은 디렉터리에서 tofu plan -refresh=false 출력을 /root/tfb-refresh/norefresh.txt 에, 그냥 tofu plan 출력을 /root/tfb-refresh/withrefresh.txt 에 저장하세요. 두 출력이 어떻게 다른지 확인하세요. 여전히 적용하지 않습니다.
4. tofu apply -refresh-only -auto-approve 를 돌리세요. 그다음 /root/tfb-refresh/refresh-report.txt 에 네 줄을 적으세요 — serial_before=<새로고침 직전 상태의 serial>, serial_after=<지금 serial>, resources_after=<지금 상태의 리소스 수>, conf_first_line=<지금 디스크의 app.conf 첫 줄>. 직전 상태는 백업 파일에 남아 있습니다.
5. /root/tfb-refresh/chain/main.tf 에 terraform_data 세 개를 사슬로 두세요 — net, 그 output 을 참조하는 db, 그 output 을 참조하는 app. 셋 모두 파괴 시점에 자기 이름을 /root/tfb-refresh/chain/order.log 에 덧붙이는 프로비저너를 갖고, app.output 을 내보내는 출력 chain 도 두세요. init·apply 한 뒤 tofu plan -destroy -out=destroy.tfplan 으로 계획을 저장하고, tofu show -json 으로 삭제 대상 주소를 사전순으로 /root/tfb-refresh/destroy-targets.txt 에 한 줄씩 적으세요.
6. 저장한 destroy.tfplan 을 그대로 적용해 사슬을 지우세요. /root/tfb-refresh/chain/order.log 에 남은 순서를 확인하고, 같은 순서를 /root/tfb-refresh/order.txt 에 한 줄씩 적으세요.
7. /root/tfb-refresh/tgt/main.tf 에 같은 모양의 사슬(net·db·app)을 프로비저너 없이 두고 init·apply 하세요. 그다음 tofu destroy -target=terraform_data.app -auto-approve 로 맨 끝 하나만 지우고 출력을 /root/tfb-refresh/target-destroy.txt 에 저장하세요. 남은 상태의 주소를 사전순으로 /root/tfb-refresh/target-left.txt 에 적으세요.
8. /root/tfb-refresh/chain 의 파괴 뒤 상태를 백업 파일과 견줘 /root/tfb-refresh/leftover.txt 에 네 줄을 적으세요 — resources=<지금 상태의 리소스 수>, outputs=<지금 상태의 출력 수>, lineage_changed=<yes 또는 no>, serial_up=<yes 또는 no>. 그리고 tofu plan 을 한 번 더 돌려 출력을 /root/tfb-refresh/after-destroy-plan.txt 에 저장하세요.

참고

• 파괴 순서는 terraform_data 의 파괴 시점 프로비저너가 로그 파일에 이름을 덧붙여 눈으로 확인합니다.
• 저장한 계획 파일은 적용한 뒤에도 읽을 수 있습니다. 파괴처럼 되돌릴 수 없는 작업은 계획을 저장해 리뷰한 뒤 그 파일만 적용합니다.
• 흔한 실수: 2·3단계에서 확인만 하라는데 적용해 버리는 것. 그러면 4단계가 견줄 직전 상태가 사라집니다.
• 흔한 실수: 6단계에서 저장한 계획 대신 destroy 명령을 새로 돌리는 것. 저장한 계획을 적용하는 것이 과제입니다.
• [tofu refresh](https://opentofu.org/docs/cli/commands/refresh/) · [tofu plan](https://opentofu.org/docs/cli/commands/plan/) · [tofu destroy](https://opentofu.org/docs/cli/commands/destroy/) · [terraform_data](https://developer.hashicorp.com/terraform/language/resources/terraform-data) · [State](https://opentofu.org/docs/language/state/)

단계 8개

1. 기준선을 만든다
2. 밖에서 바뀐 것을 새로고침 전용 계획으로 본다
3. 실물을 읽지 않은 계획은 아무 일도 없다고 말한다
4. 상태만 고치고 실물은 건드리지 않는다
5. 파괴 계획을 파일로 저장해 리뷰한다
6. 지우는 순서는 만드는 순서의 역순이다
7. 대상을 좁힌 파괴는 경고를 달고 나온다
8. 다 지운 뒤 상태에 남는 것