안녕하세요. 이전에 작성한 DevOps 역량 강화의 일환으로 Terraform을 학습하며 배운 내용을 기록했습니다.

Terraform 개념

Terraform은 인프라 코드를 선언형으로 관리할 수 있는 도구입니다.

명령형 프로그래밍은 전통적인 방식으로 프로그램이 어떤 흐름으로 동작할지 작성합니다.
반면, 선언형 프로그래밍은 프로그램이 어떤 동작을 해야하는지 작성하면 프로그램이 동작하는 런타임 레벨에서 그 동작의 결과가 나오게 만듭니다.

이를 인프라 관리에 적용해보면 Terraform을 사용할 경우 인프라가 갖춰야 할 모습을 작성(선언)하면 그 형태로 인프라가 자동으로 구성됩니다.

Terraform 학습하기
아래에서 설명할 내용들은 모두 튜토리얼에서 학습한 내용을 기반으로 합니다.
AWS, GCP, Docker 등 다양한 환경에 배포하는 시나리오로 튜토리얼을 제공하고 있으며, 본 글에서는 AWS 과금을 피하기 위해 Docker로 실습했습니다. (링크)

배포 단계

Terraform이 권장하는 배포 단계는 총 5단계로 이뤄집니다.
(Scope -> Author -> Initialize -> Plan -> Apply)

Scope

Scope 단계에서는 프로젝트를 배포하기 위해 필요한 인프라 규모를 식별하는 단계입니다.

해당 단계는 인프라가 구성된 결과를 추상적으로 설계해야 하는 단계입니다. 그렇기에 복잡한 인프라를 구성해야 한다면 필기구를 이용하여 그림을 그려보거나, 향후 산출물로 활용하기 위해 다이어그램으로 만들 수도 있습니다.

Terraform의 config 파일을 기준으로 다이어그램을 자동으로 생성해주는 pluralith라는 시각화 도구도 존재합니다. Scope 단계에서 어떤 형태로든 다이어그램을 만들어둔다면 시각화 도구로 생성한 내용과 대조하여 원하는 대로 잘 구성됐는지 확인이 가능할 것입니다.

Author

Author 단계는 추상적으로 설계된 인프라를 실제 코드로 작성하는 단계입니다.

Terraform은 Terraform Language라고 부르는 configuration 언어로 인프라 코드를 작성하게 됩니다. (과거에는 HCL; Hashicorp Configuration Language)

.tf 확장자를 사용하며, json과 유사한 형태로 코드를 작성하게 됩니다.
아래 사진은 Terraform 공식 튜토리얼에서 가져온 코드의 예시로 docker라는 provider를 사용하여, 아래 2개의 리소스를 만들 것이라고 선언한 코드입니다.

Terraform이 선언형 IaC를 구현한 방법의 주요 기능인 Provider는 각 provider가 요구하는 형태로 resource를 작성하면, resource를 생성하기 위한 세부적인 동작은 provider가 처리하도록 추상화되어 있습니다.

[Terraform provider 추상화의 한계]
resource 부분에 코드를 그대로 유지한 상태에서 provider를 갈아끼우는 것만으로 배포될 곳을 바꾸는 수준의 완전한 추상화는 불가합니다.

Initialize

Terraform이 인프라를 구성하기 전에 필요한 플러그인을 설치하는 초기화 단계입니다.

모든 provider는 init 단계에서 설치되며, 위에서 첨부했던 사진을 예시로 들면 초기화 명령어인 terraform init을 입력했을 때 docker provider kreuzwerker/docker라는 출처로부터 설치됩니다.

Plan

Terraform이 앞으로 인프라를 어떻게 구성할 것인지 확인하는 단계입니다.

작성된 configuration file을 기준으로 실제 구성을 진행하는 명령어는 terraform apply입니다. 해당 명령을 실행하면 아래처럼 구성될 것이라 알리는 내용과 동의 여부를 묻는 대화형 인터페이스가 실행됩니다.

아래 사진에서 Plan: 2 to add, ... 부분을 통해 2개의 리소스가 추가될 것이라는 것을 알 수 있습니다.

terraform plan 명령어를 사용하면 배포를 실행하지 않고, 실행됐을 때 어떤 변경사항이 발생하는지만 확인할 수 있습니다.

어떤 것을 기준으로 테스트를 작성할지는 고민할 내용이지만, 실행됐을 때 예상 결과를 미리 볼 수 있기 때문에 CI에 접목시키기 간단하겠다는 생각이 들었습니다.

Apply

배포가 실제로 실행되는 단계입니다.

Plan 단계에서 설명했던 terraform apply 실행 시 등장하는 대화형 인터페이스에서 yes를 입력해 실행했다고 가정합니다.

사진으로 첨부했던 configuration file에는 docker image 리소스를 만드는 구성과 생성된 이미지로 도커 컨테이너를 만드는 구성이 작성되어 있었습니다.

실제로 docker ps 명령어를 통해 실행 중인 컨테이너를 확인해보면 config 파일에 작성한 대로 컨테이너가 생성되어 실행 중임을 알 수 있습니다.

또한 이렇게 자동으로 프로비저닝 된 인프라는 terraform destroy 명령을 통해 고스란히 제거가 가능합니다.

State

Terraform은 앞서 설명했던 것처럼 선언형 도구이기 때문에 우리가 프로그램의 흐름을 직접 작성하지 않아도 됐습니다.

그런데 변경내용이 발생했다면 어떻게 해야 할까요?
변경내용이 파괴적인 동작을 일으키는지 미리 알 수는 없을까요?
Terraform은 어떻게 자신이 구성한 인프라만 기억하고 제거하죠?

위 질문들을 해결하기 위해서 Terraform은 state(상태)라는 기능을 제공합니다.

terraform.tfstate

Terraform 에 상태는 apply 명령 이후 같은 폴더에 terraform.tfstate라는 이름으로 자동 생성됩니다. 파일을 직접 열어볼 수도 있겠지만 terraform show 명령을 통해 현재 구성된 인프라의 상태를 확인할 수 있습니다.

위 사진처럼 Terraform이 어떤 docker 이미지를 생성했고, 컨테이너를 생성했는지 기억하고 있는 파일이 있기 때문에 다음 apply 명령 실행 때 변경될 내용들을 미리 파악하거나, Terraform 자신이 생성한 부분만 파괴하는 것이 가능합니다.

❓저는 terraform show 명령을 실행해도 아무런 결과가 나오지 않아요
해당 명령어는 결국 파일에 있는 내용을 터미널에 출력해줄 뿐입니다.
따라서 파일이 없는 위치에서 실행한다면 아무런 결과가 나오지 않거나, No State.라는 결과를 출력할 수 있습니다.

글을 마치며

튜토리얼에 있는 내용을 기록용으로 재작성한 것이라 글이 매끄럽지 못 한 점 양해 부탁드립니다.
이 글을 통해 배워가실 게 있으시면 좋겠고, 관련해서 궁금한 점이 있다면 댓글 남겨주세요.

감사합니다.