[TFAS] 챕터 3 테라폼 작동 방식

TFAS (TerraForm Addicted School)의 내용을 정리한 글입니다.
심각한 테라폼 중독입니다 - 책으로 스터디를 진행합니다.

---

---

테라폼 프로젝트 구조

테라폼의 기대 상태를 사용자가 정의하는 파일을 구성 파일이라고 한다. 해당 파일은 사용자별로 혹은 팀별로 인프라 구성 의도가 담겨 있는 테라폼의 핵심 파일이다. 일반적으로. tf 확장자를 가진 파일을 일반적으로 테라폼 구성 파일이라고 명명하며 테라폼 코드라고도 부른다.

구성 파일이 존재하는 디렉터리에서 테라폼 초기화 명령인 terraform init을 수행하면 루트 모듈 설정이 진행된다. 테라폼 초기화가 완료된 디렉터리를 루트 모듈이라고 하며 루트 모듈을 초기화하는 경우. terraform 생성되면서 해당 디렉터리에 여러 필요 파일들을 저장하는 프로세스를 통해서 초기화를 진행한다.

루트 모듈에서 테라폼 명령이 실행 가능하기 때문에 루트 모듈은 테라폼의 실행 환경이라고 할 수 있다. 루트 모듈에서 상태 동기화가 수반되는 명령인 plan, apply 등을 실행하면 테라폼 코드에 정의한 리소스에 따른 실제 인프라 리소스를 읽어 JSON 형식의 테라폼 상태로 저장한다. 이를 테라폼 상태 파일이라고 하며. tfstate라는 확장자를 가진다.

하나의 루트 모듈에 하나의 상태 파일만 가질 수 있으며 별도 설정이 없는 경우 루트 모듈에 terraform.tfstate 파일명으로 생성된다. 이를 협업이나 실무에서 사용하는 경우 s3 등 상태 백엔드를 사용하여 테라폼 상태 파일을 여러 작업자들에 걸쳐 관리될 수 있도록 해아 한다.

---

테라폼 상태의 역할

테라폼은 세 가지 상태로 구성된다. 기대 상태, 테라폼 상태, 실제 인프라 상태이다. 테라폼 코드를 통해 "기대 상태"를 선언하고, "실제 인프라의 상태"를 읽어 "테라폼 상태"와 비교하여 반영한다. 이중 테라폼 상태는 기대 상태와 실제 상태를 비교하여 올바른 인프라 배포 상태를 만들어 주는 중요한 역할을 한다.

기대 상태와 실제 리소스의 매핑

테라폼 상태의 가장 주된 목적은 테라폼 코드에 정의한 기대 리소스와 실제 인프라 리소스의 매핑에 있다. 리소스 매핑을 통해서 테라폼으로 정의한 리소스 하나하나를 실제 리소스와 연결하여 정확한 리소스를 관리하고 수정 및 삭제할 수 있게 된다. 이렇게 매핑된 상태가 없다면 어떻게 될까? 

사용자가 선언한 인프라 코드가 실제 리소스로 생성이 되었는지, 어떤 리소스가 새롭게 생성된 리소스인지, 어떤 변경사항이 있고 어느 인프라를 변경할 수 있는지 확인할 수 있는 방법이 없다. 이는 매번 기대 상태대로 인프라에 배포가 되어 있지 않으면 차이가 나는 리소스에 대해서 매번 생성 요청이 발생할 것이며, 이는 멱등성을 보장하지도, 그리고 의도치 않은 인프라의 다운 타임을 초래할 수도 있다.

테라폼을 통한 관리 대상 지정

테라폼 상태는 어떤 리소스를 테라폼이 관리해야 하는 리소스인지 지정하는 역할을 한다. 사용자의 aws 환경에 이미 10대의 ec2 인스턴스가 존재한다고 해보자. 테라폼의 기대 상태에서 7대의 ec2 인스턴스를 선언했다면 기존의 10대는 그대로 두고 나머지 7대에 대해서만 관리할 수 있어야 한다. 이런 동작이 보장되지 않는다면 예상하지 못하는 작동이 일어날 수 있다.

이런 문제를 막기 위해 테라폼 상태로 저장한 리소스가 아닌 경우 인프라 조작 대상으로 인식하지 않는다. 만약 필요하다면, terraform import 명령으로 기존의 리소스를 테라폼 상태에 포함시켜 관리할 수도 있다. 

리소스 조작 순서와 의존성 지정

인프라를 반영하는 동작을 정확히 수행하기 위해선 순서에 맞게 리소스를 생성해야 한다. 예를 들어 vpc를 만들고 서브넷을 생성하는 순서이다. 테라폼의 상태는 리소스 조작 순서나 의존성을 확인할 수 있는 역할도 수행한다. 테라폼 코드에서 명시적으로 지정한 의존성이나, 테라폼 프로바이더에서 참조를 통해 암시적으로 추론한 의존성을 저장한다. 그렇기 때문에 올바른 순서대로 리소스를 생성하거나 삭제할 수 있게 된다.

협업의 관점

추가적으로 상태 파일을 로컬 환경이 아닌 별도의 상태 백엔드를 사용하면 여러 작업자들 사이에 공유할 수 있다. 상태 백엔드를 이용해 동기화가 되면 원격 환경에 상태 파일이 올라가게 된다. 여러 사람이 해당 파일을 확인할 수 있고 동일한 상태를 가지고 작업할 수 있게 된다.

---

테라폼 명령어

테라폼에서 사용하는 명령어는 아주 크게 상태 동기화를 일으키는 명령어 vs 상태 동기화를 일으키지 않는 명령어로 구분할 수 있다.

이중 상태 동기화를 일으키는 명령이 핵심적으로 중요한 역할을 하기 때문에 해당 명령어를 먼저 살펴보자

상태 동기화

terraform apply -refresh-only

 

 

현재 시점의 인프라 상태를 테라폼 상태 파일로 읽고 기존에 저장한 상태 파일을 덮어쓰는(혹은 새롭게 작성하는) 명령어이다. 상태 동기화를 통해 실제 인프라의 최신 상태를 테라폼 상태 파일에 반영할 수 있다. 뒤에서 확인해 볼 apply 혹은 plan 명령어를 사용하는 경우에도 내부적으로 상태 동기화를 수행하기 때문에 별도로 사용하는 경우는 많이 없다.

앞서 테라폼은 세 가지 상태로 구성된다고 했다. 기대 상태, 테라폼 상태, 실제 인프라 상태. 이때 상태 동기화를 하는 경우 각 상태에  따라서 총 2^3 = 8 가지의 경우의 수가 있을 수 있다. 기대 상태, 테라폼 상태와 실제 상태의 현재 상황을 통해 상태 동기화 명령을 수행하는 경우 어떤 결과가 나오는지 확인해 보자.

구성 파일의 정의 여부 (기대 상태 .tf)	테라폼 상태의 저장 여부 (테라폼 상태 .ftstate)	실제 리소스의 존재 여부 (실제 상태)	상태 동기화 명령 결과
x	x	x	변화 없음
x	x	o	변화 없음 - 테라폼이 관리하는 대상이 아님
x	o	x	테라폼 상태 파일에서 리소스 매핑 삭제
x	o	o	실제 리소스 삭제 테라폼 상태 파일에서 리소스 매핑 삭제
o	x	x	리소스 생성 테라폼 상태 파일에서 리소스 매핑 생성
o	x	o	리소스 생성 테라폼 상태 파일에서 리소스 매핑 생성
o	o	x	리소스 생성 테라폼 상태 파일에서 새롭게 생성된 리소스로 매핑 변경
o	o	o	기대 상태와 테라폼 상태가 같으면 변화 없음 기대 상태와 테라폼 상태가 다르면 상태 업데이트

 

계획 세우기

terraform plan

구성 파일에 정의한 기대 상태와 테라폼 상태를 비교해 각 인프라 리소스가 어떻게 변경될지 알려주는 명령어이다. 실제 인프라의 변경 없이 인프라의 변경점을 확인해 볼 수 있으며, 내부적으로 상태 동기화 작업을 수행하기 때문에 기대 상태와 실제 인프라의 상태를 비교하여 변경되는 점을 알려준다.

이를 통해 제공되는 결과는 총 3가지로 구분되는데 리소스 생성 (+), 리소스 삭제 (-), 리소스 변경(~)이다. 결과를 터미널에 색깔별로 표시해 주기 때문에 알아보기 쉽다.

 

반영

terraform apply

구성 파일에 정의한 기대 상태를 실제 인프라에 반영하기 위한 명령이다. terraform plan과 동일하게 기대 상태와 실제 리소스의 상태를 읽어 비교하고 변경점을 알려준 이후 변경사항을 반영할 것인지 묻는다. 이때 yes라고 사용자가 입력하면 api 호출을 수행하여 인프라에 기대 상태를 반영한다.

 

테라폼 상태 명령어

terraform state list  # 상태 목록 조회
terraform state show  # 상태 상세 조회
terraform state mv    # 특정 상태 값 변경
terraform state rm    # 특정 상태 값 삭제
terraform import      # 비 관리 자원 상태 등록

테라폼의 상태 파일을 관리가 필요한 경우 위와 같은 명령어를 사용할 수 있다. 명령어는 모두 직관적이며 앞으로 학습해 나가면서 상태 조작이 필요한 경우 명령어를 사용할 수 있다.

---

테라폼 프로바이더

테라폼은 다양한 프로바이더를 제공한다. 테라폼은 다양한 리소스 제공자 (aws, azure, gcp, k8s, helm, argocd 등 다양함)로부터 실제 상태를 읽어 들이고, 테라폼 명령에 따라 리소스 제공자에게 적절한 API 요청을 전송할 수 있다. 이를 추상화해서 제공하는 것이 테라폼의 플러그인이다. 그리고 이런 플러그인을 구체화해서 제공하는 것이 바로 테라폼 프로바이더이다.

테라폼 프로바이더는 프로바이더 블록이라고 하는 다음과 같은 형식으로 정의할 수 있다.

provider "aws" {
  # ...
}

terraform init 명령어를 사용하여 초기화를 수행하면 해당 프로바이더 블록을 모두 읽어 필요한 프로바이더를 확인하고, 확인한 프로바이더를. terraform 디렉터리로 다운로드한다. 

그리고 이러한 테라폼 프로바이더는 테라폼 레지스트리라고 하는 테라폼에서 자체 제공하는 다양한 종류의 테라폼 프로바이더를 다운로드할 수 있는 사이트를 제공한다.