본 글은 HashiCorp의 공식 워크샵인 "Intro to Terraform on Azure" 내용을 발췌하여 작성한 글입니다. 참고

실습 원본 소스코드는 hashicat-azure 저장소에서 확인할 수 있습니다.

1. Provision

프로비저닝과 관련하여 우리는 Day 0부터 Day 2까지의 여정이 있습니다.

• Day 0에 요구사항을 분석하고 아키텍쳐를 설계하고 훈련을 합니다.
• Day 1에 드디어 설계된 아키텍쳐를 구현하지요. 인프라, 네트워크, 서비스 구성 등등 말이죠.
• Day 2는 이제 Day 1에서 구성된 요소를 유지하고 관리하고 모니터링하면서 더나은 아키텍쳐로 변경하거나 추가 서비스를 붙이는 반복적 작업을 합니다.

이번에는 인프라의 변화와 적응이라는 제목으로 인프라의 성숙도와 관련한 이야기를 나누고자 합니다.

Terraform의 가장 주요한 기능으로 Infrastructure as Code 를 이야기 할 수 있습니다. 그리고 이를 지원하는 HCL에 대해 알아보고자 합니다.

Terraform의 Remote Runs이라는 기능에 대해 확인합니다.

Terraform Cloud와 Terraform Enterprise는 원격으로 트리거링 되어 동작하는 메커니즘을 제공하고 있습니다.

Terraform을 수행하고나면 실행되고난 뒤의 상태가 저장됩니다. 로컬에서 OSS로 실행 했을 때의 terraform.tfstate 파일이 그것 입니다. 서로 다른 팀이 각자의 워크스페이스에서 작업하고 난뒤 각 상태 공유하면 변경된 내역에 따라 다음 작업을 이어갈 수 있습니다. Terraform은 Terraform Cloud, HashiCorp Consul, Amazon S3, Alibaba Cloud OSS 등에 상태 저장을 지원합니다.

Terraform은 인프라의 코드화 측면에서 그 기능을 충실히 실현해줍니다. 하지만 팀과 조직에서는 단지 인프라의 코드적 관리와 더불어 다른 기능들이 필요하기 마련입니다. 그중 하나로 정책을 꼽을 수 있습니다.

Terraform은 코드로 인프라를 관리하기위한 그 '코드'의 핵심 요소인 변수처리를 다양하게 지원합니다.

Terraform에서는 다양한 변수와 작성된 변수를 관리하기 위한 메커니즘을 제공합니다. 가장 기본이되는 기능 중 하나이며 오픈소스와 엔터프라이즈 모두에서 사용가능합니다.

Terraform의 워크스페이스(Workspace)는 일종의 원하는 인프라의 프로비저닝 단위로서, 하나의 state를 갖는 공간입니다. Terraform에서의 plan 혹은 apply 가 이뤄지는 단위이기도 합니다.