terraform으로 aws의 fargate를 구축하면서 apply가 실패할 때

잘못 이해한 개념이 있을 수 있습니다.

TL;DR

terraform의 remote state를 실수로 삭제했고, 그 이후에 벌어진 카오스

도입을 고려하시는 분들은 아래 글을 참고하셔도 좋을 것 같습니다.
우아한 형제들 - 좌충우돌 Terraform 입문기

개요

사내의 개발환경을 EC2에서 Fargate로 옮기면서,
AWS 환경을 GUI가 아닌 CLI로 자동으로 구축해주는 terraform도 함께 도입했는데,
그 과정에서 해서는 안 되는 것들에 대해 실제로 부딪치면서 알게 된 것을 남긴다.

간단히 알게된 Fargate, ECR, terraform 에 대해서 글로 남기고, 실패한 이유및 시도해 본 방법들에 대해서도 남기고자 한다.

Fargate

구성요소

1. cluster
   프로덕트 또는 프로젝트의 큰 단위.
2. service
   서비스를 나누면 naming이 어렵게 된다.
   다른 서비스로 접근하기 위해서는 DNS로 이름풀이(Naming Resolution)을 해줘야 하고, cache가 남는 등 문제가 다소 복잡해지는 것을 고려해야 한다.
3. task
   container의 집합체. 하나의 service가 하나의 task 구성 가능하며, n개의 container도 가능하다.

• service를 나누는 것과, task를 나누는 것의 차이는?
  1) network의 차이. 하나의 서비스는 하나의 localhost이다.. service를 나누면 위에서 언급한 것처럼 DNS로 이름풀이를 해야한다.
  2) deploy를 하면 정의된 task의 increment가 증가하는데, 서비스를 나누면 이 increment가 과도하게 증가하지 않게 된다.

• 환경변수는 container에 넣고, 소스관리가 됩니다. 보안이 필요한 내용은, AWS의 secret manager로 관리한다. (소스관리 대상에서 제외시킴으로써 보안강화)

EX) 향후 동작방향
circle ci -> docker build -> image build -> task에서 정의한 ECR

terraform

인프라 베이스의 코드관리.

구성

・remote state(S3)
・variables
・local
・main
・module

명령어

init -> .terraform 에 .tfstate가 작성됨. 초기화
plan -> diff가 표시된다. 반드시 차이를 확인하자!
apply -> 실행
destroy -> 기존 구성을 삭제

실행하면 무엇이 동작하는가

• 같은 디렉토리 안에 존재하는 .tf파일은 전부 하나의 파일로 인식된다.
• S3의 remote state와 local의 환경의 차이를 확인 후, remote state를 기준으로 차이가 적용된다.

terraform으로 aws의 fargate를 구축하면서 apply가 실패했던 이유

가장 큰 실패 요인 : S3에 있는 remote state를 실수로 삭제해 버린것...
명확한 이유가 없는 이상 해서는 안 된다... ㅠㅠ
S3에 있는 remote state를 지워버린 후, init, plan, apply, destroy 등의 명령어가 제대로 실행되지 않게 되었다.

가장 먼저 취한 조치는

1. 실행 도중 생성된 AWS구성을 수작업으로 모두 삭제
2. terraform의 캐시를 삭제
3. 그리고 다시 init 후, plan과 apply를 실행

그 이후에 취한 조치

1. terraform을 사용하기 전에 AWS콘솔 화면으로 직접 만들었던 구성들이 아직 남아있는 상태.
   -> 따라서 기존 구성들을 모두 수작업으로 삭제처리.
2. secret manager의 secret key가 아직 남아있었다.
   -> 수작업으로 삭제. (AWS에서 강제로 7일~30일간 남아있도록 설정할 수 밖에 없음)
   -> 다시 init 후 apply 해보았으나, 이번에는 already scheduled for deletion 에러가 뜨면서 다시 문제가 발생.
   -> 일단 삭제한 것을 다시 되돌리고(삭제하면 화면상으로 표시되지 않기 때문에 설정에서 표시를 눌러야 합니다.)
   -> terraform 의 캐시를 삭제한 후 다시 실행했으나 실패
   -> S3의 remote state를 수정한 후 다시 실행했으나 실패...(하면 안 되는 줄 알면서도 하고 싶어지는 간사한 사람의 마음...)
   -> 일단은 secret manager의 secret key가 지워지도록 7일간 기다리기로 했다.
3. CloudWatch에Log그룹이 남아있다는 에러가 표시
   -> 수작업으로 삭제
   -> 에러가 표시되지 않게 되었다.

반성

우선 S3에 있는 remote state는 정말로 필요한 경우가 아니면 수정해서는 안 된다는 것을 깊이 깨달았다. 그 이후는 정말 혼란에 빠지는 상황이 발생...
개발서버라서 다행이지 실제 서비스였으면 정말 큰 일 날뻔했다.