손으로 만든 클라우드 인프라를 테라폼 코드로 옮기는 시리즈. 손으로 만든 서버가 무엇을 잃는지에서 출발해 plan 과 apply, 상태 파일, 이미 있는 자원을 코드로 가져오는 import, 누가 콘솔에서 손댔을 때의 드리프트, 여럿이 같이 쓰기 위한 원격 상태와 잠금까지 간다. 전부 로컬에서 AWS 를 흉내 내 직접 돌려 본다.
- 1/5 IAC 01 손으로 만든 서버는 무엇을 잃나 — 명령형 스크립트와 선언형 코드보안 그룹·인스턴스·버킷을 만드는 셸 스크립트를 두 번 돌렸더니 에러가 세 줄 찍히고도 종료 코드는 0이었습니다. 에러를 피하게 고친 스크립트는 돌릴 때마다 인스턴스를 한 대씩 늘려 세 대가 됐습니다. 같은 세 자원을 테라폼으로 적자 두 번째 apply 는 변경 0이었습니다. 스테이징 한 벌은 명령 2개·코드 수정 0줄·약 24.5초에 나왔습니다. 대신 만드는 시간은 스크립트가 약 4.7초로 다섯 배 빨랐고, 테라폼 쪽에는 인스턴스마다 10초씩 기다리는 고정 대기가 들어 있었습니다
- 2/5 IAC 02 plan 이 말해 주는 것 — 제자리 변경·교체·상태 파일코드 네 줄을 하나씩 바꿔 plan 을 돌리면 AMI·서브넷은 서버를 지우고 새로 만드는 교체(-/+)로, 태그·인스턴스 유형은 그대로 고치는 제자리 변경(~)으로 나옵니다. 그런데 제자리 변경이라던 인스턴스 유형을 적용하자 서버 ID 는 그대로인데 공인 IP 가 54.214.192.34 에서 54.214.196.184 로 바뀌었습니다. 상태 파일에는 코드에 적은 속성 5개가 아니라 63개가 들어 있습니다. 이 파일을 지우고 apply 할 때마다 인스턴스가 1 → 2 → 3대로 늘어납니다
- 3/5 IAC 03 이미 있는 것을 코드로 가져오기 — import보안 그룹 설명 문자열 하나가 달랐을 뿐인데, import 뒤 첫 plan 은 운영 중인 보안 그룹을 지우고 다시 만들겠다고 했습니다(`# Warning: this will destroy the imported resource`). 손으로 만든 자원을 테라폼으로 가져오는 두 길 — 직접 쓴 코드와 `plan -generate-config-out` 이 뽑아 준 코드 — 을 moto 위에서 돌려 둘 다 plan 몇 번 만에 `No changes` 에 닿는지 셉니다. import 는 자원을 건드리지 않고 상태 파일에 「이 코드 주소 = 이 실제 ID」 한 줄을 적는 일입니다. 진짜 일은 그 뒤 코드를 실제에 맞추는 반복입니다
- 4/5 IAC 04 누가 콘솔에서 손대면 — 드리프트와 테라폼이 못 보는 것손으로 연 8080 포트 하나를 두고 같은 테라폼이 한쪽에서는 plan 으로 잡아 apply 한 번에 닫았습니다. 다른 쪽에서는 「No changes」를 내고 apply 뒤에도 열어 둔 채 남겼습니다. 보안 그룹 규칙을 인라인으로 적었나 별도 리소스로 적었나의 차이입니다. `plan -refresh-only` 에는 두 쪽 다 8080 이 보였습니다. 테라폼이 관리한다는 말이 「코드에 없는 것은 없앤다」가 아니라는 것을, 새로 고침 단계와 `ignore_changes` 까지 실측으로 따라갑니다
- 5/5 IAC 05 둘이 같이 apply 하면 — 원격 상태와 잠금두 사람이 같은 코드를 각자 apply 했더니 둘 다 exit 0, 오류는 0줄인데 인스턴스는 2대가 됐습니다. 동시에 돌려서가 아니라 상태 파일이 둘로 갈라져서 생긴 일입니다. 원리상 실행 간격과 상관없이 벌어집니다. 상태를 S3 한 곳에 모으고 잠금을 켜면 둘째 apply 는 HTTP 412 로 막힙니다. 그런데 잠금을 끄면 나중 쓰기가 앞 상태를 덮어써 고아 인스턴스가 남습니다. apply 도중 죽은 뒤 force-unlock 으로 잠금만 풀면 인스턴스가 한 대 더 생깁니다. 원격 상태와 잠금이 각각 무엇을 막고 무엇을 못 막는지 실측으로 가릅니다