[Terraform] concept

이번 글에서는 테라폼에서 통용되는 주요 키워드를 통해 테라폼을 이해하도록 합니다.

---

 

테라폼은 크게 configure, plan, apply 세 가지의 단계가 있습니다. 풀어서 보자면 설정(configure)하고 실행 계획(plan)을 살펴본 후에 배포(apply)하는 구조입니다. 실행 계획이라고 하면 SQL에서 explain을 생각하면 되고 apply는 배포에서 일반적으로 사용되는 deploy 키워드를 생각하면 됩니다. 여러 팀원이 인프라를 같이 만지더라도 VCS에 의해 인프라가 관리되기 때문에 충돌을 피해 갈 수 있습니다. 이로 인해 서비스 가용성을 보장받을 수 있습니다. 사실 여러 사람이 동시에 같은 인프라를 만지는 상황 자체가 정상은 아니지만 말입니다.

configure

설정은 HLC(Hashicorp Configuration Language)로 *. tf에 작성합니다. 테라폼은 확장자가 tf인 파일을 모두 읽어 들여 서로 간의 의존관계를 해석하고 리소스의 생성/수정/삭제를 통해 인프라 구축을 진행합니다. 일부 변수 선언을 위해서는 *. tfvars을 사용합니다. ( terraform 명령어가 실행되는 디렉터리에 있는 파일만 읽어 들입니다. 다른 경로의 파일을 읽기 위해서는 module 기능을 사용하면 됩니다 )

tf 파일은 서비스, 혹은 모듈 단위로 분리해서 관리하면 재사용에 유리합니다. 예를 들어 main.tf, cloudwatch.tf, monitor.tf, s3.tf, 그리고 development.tfvars, production.tfvars 같은 형상을 생각하면 됩니다.

 

# Terraform CLI 옵션

plan

작성한 설정(코드)을 실행했을 때 인프라에 어떤 변화가 있는지 검토하고 결과를 화면에 출력합니다. 리눅스의 diff 명령이나 git처럼 line by line으로 +, -가 표시되기 때문에 잘 확인한다면 휴먼 에러를 사전에 예방할 수 있습니다.

apply

plan에서 확인한 내용을 인프라에 배포합니다. 최초 배포의 경우에는 모든 내용이 구축되지만 이후에 update 하는 경우에는 인프라에 변경된 부분만 전파가 이루어집니다. 예를 들면 LB IP를 변경, 인스턴스 타입을 변경하는 경우가 있겠습니다.

destroy

테라폼 코드로 배포된 모든 인프라를 삭제시킵니다. 퍼블릭 클라우드 콘솔에서 테스트로 배포한 환경을 정리할 때 말끔하지 못하게 놓치는 것들이 있고 이게 또 레거시가 되는 경우가 있는데 테라폼을 이용하면 그럴 일이 없습니다. 한방에 모든 게 정리됩니다.

• 안타깝지만 모든 케이스에서 그렇지는 못합니다
• 앞서 이야기한 것처럼 인프라 리소스의 의존관계를 해석하기는 하지만 완벽하지 못합니다
• 아직 태동하고 있는 단계이고 빠르게 발전하고 있기 때문에 이 부분은 조금 더 지켜봐야겠습니다
• 한방에 모든 게 정리되지 않는 경우에는 중간에 사람 손을 조금 태우면 되겠습니다
  • 예를 들어 의존관계 파악에 따라 AWS ECS를 삭제했는데 서비스는 테라폼 코드에 남아있어서 삭제 오류가 뜨는 경우 등. 
  • 이때는 tfstate 파일을 직접 수정해주면 됩니다

# 설정

*.tf, *.tfvars 파일 안에는 providers, resource, output, module, variable, locals, data 등 다양한 키워드를 정의하고 사용할 수 있는데 다음 장에서 하나씩 살펴보도록 하겠습니다.