Quiz: Manipulating State and import

terraform state rm aws_instance.web 을 실행하면 실제로 무슨 일이 일어나나요?

• 상태와 함께 코드의 리소스 블록까지 정리되어 사라진다
• 상태 파일에서만 항목이 사라지고 실물은 그대로 남는다
• 지정한 인스턴스가 백업 상태 파일로 옮겨져 따로 보관된다
• 실제 EC2 인스턴스가 종료되고 상태에서도 함께 지워진다

리소스 이름을 코드에서만 바꾸고 상태는 그대로 두면 계획에 무엇이 뜨나요?

• 이름은 상태 주소와 무관하므로 변경 없음으로 나온다
• 리소스 이름만 바뀐다는 안내가 뜨고 실물은 그대로 유지된다
• 상태에 없는 주소라며 오류가 나고 계획이 중단된다
• 옛 이름의 파괴와 새 이름의 생성이 나란히 뜬다

state mv 대신 moved 블록을 쓰는 이점은?

• 상태 주소만 바꾸는 state mv 와 달리 실물 자원까지 새 이름으로 옮겨 준다
• 상태 전체를 다시 쓰지 않고 해당 항목만 고치므로 대규모 상태에서 훨씬 빠르다
• 리팩터링 이력이 코드에 남아 다른 사람이 plan 만 돌려도 같은 이주가 자동으로 일어난다
• 코드로 처리되므로 원격 백엔드의 상태 잠금을 잡지 않고도 이주를 끝낼 수 있다

콘솔에서 만들어진 자원을 코드 관리 아래로 데려오려 합니다. 반드시 먼저 해야 할 일은?

• 상태 파일을 열어 리소스 항목을 손으로 적어 넣는다
• import 는 원격 백엔드에서만 되므로 백엔드를 먼저 옮긴다
• 콘솔에서 그 자원을 지우고 같은 설정으로 코드에서 다시 만든다
• 코드에 그 자원의 리소스 블록을 먼저 선언한다

import 직후 첫 계획을 반드시 읽어야 하는 이유는?

• import 로 올린 항목은 임시 표시가 붙어 있어 계획을 한 번 통과해야 확정되기 때문
• import 중에 걸린 상태 잠금이 다음 계획을 한 번 돌려야 비로소 풀리기 때문
• 실물의 실제 속성이 코드와 다르면 다음 apply 가 그 차이를 코드 기준으로 밀어 버리기 때문
• 가져오는 순간 실물의 모든 속성이 코드 블록에 자동으로 채워져 그 결과를 검토해야 하기 때문

상태를 만지기 전 사본이 올바른지 확인하는 실용적인 방법은?

• 사본과 현재 파일의 바이트 크기가 같은지 비교한다
• 파일 수정 시각이 마지막 apply 시각과 맞는지 비교한다
• 사본과 현재 상태의 lineage 값이 같은지 비교한다
• 두 파일의 리소스 이름 목록을 눈으로 훑어 비교한다