Terraform

01무엇이고, 어떤 일을 하나

• 자원 구성과 의존 관계를 선언적으로 표현한다.
• provider를 통해 인프라 API의 조회·생성·변경·삭제를 실행한다.
• state와 plan으로 관리 대상과 예상 변경을 추적한다.

02어떤 순서로 동작하나

1. 초기화

   init이 구성에 필요한 provider와 모듈·backend를 준비한다.

2. 조회·계획

   plan이 구성·state·실제 자원 상태를 비교해 추가·변경·교체·삭제를 계산한다.

3. 의존 순서 적용

   apply가 의존 그래프와 provider 규칙에 따라 계획된 작업을 수행한다.

4. 상태 기록·재평가

   성공한 결과와 관리 관계를 state에 반영한다. 부분 실패 시 실제 생성된 자원과 state를 대조하고 다음 계획을 판단한다.

03먼저 알아둘 용어와 구성요소

configuration

Terraform 구성은 어떤 provider의 어떤 자원을 어떤 속성으로 관리할지 표현한다.

provider

provider는 특정 API와 상호작용하는 플러그인 역할을 한다.

state

state는 구성에 있는 자원 주소와 실제 원격 객체의 식별 관계 등을 기록한다.

자원 주소

구성의 자원 주소는 코드 안에서 관리 객체를 식별한다. state는 이 주소를 실제 플랫폼 객체의 ID와 연결하며 단순한 명령 실행 이력 파일에 그치지 않는다.

미확정 값

새 자원의 ID처럼 생성 전 알 수 없는 값은 계획에서 known after apply 등으로 표시될 수 있다. 빈 문자열·null·조회 실패를 뜻하는 값과 구분한다.

교체

제자리 갱신이 불가능한 속성 변경은 삭제·생성을 수반할 수 있다. create_before_destroy도 동시 존재 제약·고유 이름·자원 한도 등을 해결해 주는 만능 옵션은 아니다.

04예제로 따라가기

• 자원 하나를 교체하고 다른 하나를 수정하는 계획은 add 1·change 1·destroy 1로 표시될 수 있어 자원 세 개라는 뜻이 아니다.
• state에 민감한 출력이나 자원 속성이 들어갈 수 있으므로 소스 코드와 같은 공개 저장소에 무조건 올리지 않는다.
• 계획 뒤 다른 관리자가 실제 설정을 바꾸면 apply 시점의 조건이 달라질 수 있으므로 plan은 미래 성공 보장이 아니다.

05혼동하기 쉬운 점과 확인 기준

• API가 한 자원을 만든 뒤 다음 자원 생성에 실패할 수 있다. 오류 종료만 보고 전체 작업이 취소됐다고 처리하면 이미 만들어진 비용·노출·의존성을 놓친다.
• 연결이 끊긴 구간에서는 실제 생성 여부와 state 반영 여부를 각각 확인한다. 문제를 지우려 state를 임의 삭제하면 기존 객체를 새로 만들거나 관리에서 잃을 수 있다.
• 같은 속성을 다른 자동화와 콘솔이 동시에 바꾸면 다음 적용이 서로의 변경을 덮을 수 있다. 누가 어떤 자원을 관리하는지와 원하는 최종 상태를 일치시킨다.

06상세 노트 · 실습 자료

헤더 구조, 설정 예시, 수치 계산과 수업 캡처는 아래 노트에서 이어집니다.