Quiz: Lifecycle and Drift

terraform plan -detailed-exitcode 가 2 를 반환했습니다. 무슨 뜻인가요?

• 변경이 없다 — 코드와 실제 인프라가 완전히 일치해 적용할 것이 없다
• 상태 잠금이 걸려 있다 — 다른 실행이 끝날 때까지 기다려야 한다
• 오류가 발생했다 — 설정이나 프로바이더 문제로 계획을 만들지 못했다
• 적용할 변경이 있다 — 드리프트이거나 아직 적용되지 않은 코드 변경이다

새벽 장애 대응으로 콘솔에서 인스턴스 타입을 키웠고 그 판단이 옳았습니다. 올바른 후속 조치는?

• 다음 apply 가 알아서 되돌리게 둔다
• 해당 리소스를 상태에서 제거한다
• 그 리소스에 ignore_changes 를 영구히 건다
• 변경된 값을 코드에 반영하고 커밋한다

ignore_changes 를 쓰기 좋은 대표적인 자리는?

• 오토스케일러가 관리하는 복제 수처럼 의도적으로 코드 밖에서 변하는 속성
• 배포마다 무작위 접미사가 새로 붙어 값이 달라지는 리소스 이름 속성
• 운영자가 콘솔에서 수시로 붙였다 떼는 모든 태그와 라벨 속성
• 장애 대응 중 임시로 열어 두는 일이 잦은 보안 그룹 인바운드 규칙

prevent_destroy = true 가 걸린 리소스를 코드에서 지우려고 하면?

• 상태에서만 지워지고 실물은 그대로 남는다
• 이번 계획에서는 빠지고 다음 apply 로 미뤄진다
• 계획 단계에서 오류가 나며 실행이 막힌다
• 경고 메시지만 뜨고 삭제는 그대로 진행된다

create_before_destroy = true 를 쓰는 이유는?

• 옛 자원의 상태 항목이 먼저 지워져 상태 파일이 작아지게 하려고
• 교체가 필요할 때 새 자원을 먼저 만들어 서비스 중단 구간을 없애려고
• 매번 새 자원을 만들어 비교함으로써 드리프트를 정확히 감지하려고
• 생성과 파괴가 동시에 진행되어 교체에 걸리는 시간을 줄이려고

드리프트 감지를 대규모 인프라에서 자주 돌릴 때 주의할 점은?

• 감지할 때마다 조회 결과가 상태에 덧붙어 상태 파일이 걷잡을 수 없이 커지고 느려진다
• 모든 자원에 프로바이더 API 를 호출하므로 요청 제한에 걸리고 상태 잠금이 배포와 충돌할 수 있다
• 발견한 차이를 도구가 코드에 자동으로 반영해 버려 저장소가 조용히 바뀐다
• 새로고침만 하고 계획은 만들지 않아 감지 결과 출력이 늘 비어 있게 된다