[Terraform] 기본 구성 및 개념 정리
1. 데브옵스의 등장
1️⃣ DevOps의 등장
2007~2008년 사이에 IT 운영 및 소프트웨어 개발 커뮤니티가 업계에 치명적인 문제가 있다는 우려를 제기하면서 DevOps 움직임이 시작되었다. 개발자 및 IT/Ops 전문가는 서로 다른 목표(상충하는 목표), 서로 다른 부서 리더십, 서로 다른 주요 성과 지표를 가지고 있었고, 다른 층 또는 다른 빌딩에서 근무하는 경우도 많았다. 그 결과 각 부서는 사일로화(서로 분리되어 관리되는 상황)되어 각자의 분야나 투입 시간, 릴리스 실패, 고객 불만에만 신경쓰는 팀이 되었고, 사일로화된 팀과 회사 내 커뮤니케이션 라인이 무너짐으로 인해 어려움을 겪게 되었다. 이러한 배경으로 인해 DevOps 소프트웨어 개발 방법론이 나오게 된 것이다.
DevOps는 'development(개발)'와 'operations(운영)'가 합쳐진 단어이지만, 단순히 각각의 용어를 결합한 것 이상의 포괄적인 아이디어와 방식을 나타낸다. DevOps는 시스템 개발자와 운영을 담당하는 정보 기술 전문가 사이의 소통, 협업, 통합 및 자동화를 강조하는 소프트웨어 개발 방법론이다.
DevOps는 새로운 소프트웨어 기능, 개선 요청 또는 버그 수정 등 하나의 아이디어가 개발에서 배포에 이르는 프로세스의 속도를 높임으로써 더 빨리 프로덕션 환경에 전달되어 사용자에게 가치를 전달한다. 이러한 접근 방식을 적용하려면 개발 팀과 운영 팀이 자주 커뮤니케이션하고 팀원들과 공감하면서 업무에 접근해야 한다. 그리고 확장성과 유연한 프로비저닝도 필요하다. DevOps를 확립하면 셀프 서비스와 자동화를 통해 다양한 이점과 경쟁력을 얻을 수가 있다. 일반적으로 개발자는 IT 운영 담당자와 긴밀하게 협력하여 소프트웨어 빌드, 테스트, 출시 속도를 가속화할 수 있다.
2️⃣ DevOps 이점
- 속도
- 신속한 제공
- 안정성
- 확장 가능
- 협업 가능
3️⃣ DevOps 엔지니어
DevOps 엔지니어는 코딩, 인프라 관리, 시스템 관리 및 DevOps 도구 체인을 포함하여 개발 및 운영에 대한 광범위한 지식을 갖춰야 하는 IT 전문가이다. DevOps 엔지니어는 공동 작업에 더 적합한 환경을 만들기 위해 사일로 전반에서 작업하므로 대인 관계 스킬을 보유해야 한다.
DevOps 엔지니어는 일반적인 시스템 아키텍처, 프로비저닝 및 관리에 대해 잘 알고 있어야 하지만, 소스 제어 사용, 코드 검토 주고받기, 단위 테스트 작성, 애자일 원칙에 대한 친숙도 등 기존 개발자 도구 세트 및 관행에 대한 경험도 있어야 한다.
DevOps 엔지니어의 역할은 조직마다 다르지만 공통적으로 릴리스 엔지니어링, 인프라 프로비저닝 및 관리, 시스템 관리, 보안 및 DevOps 지원이 어느 정도 결합되어 있다.
2. 코드형 인프라(infrastructure as Code)란?
1️⃣ IaC ?
코드형 인프라(Infrastructure as Code, IaC)는 컴퓨터에서 읽을 수 있는 정의 파일(미리 구성이 정의된 코드 형태의 파일)을 사용해 인프라나 서비스를 관리하고 프로비저닝하는 프로세스를 말한다.
- Provisioning(프로비저닝) : Provider가 코드를 인프라로 반영되는 과정을 말한다.
2️⃣ IaC는 왜 생겨났는가?
VM ware, Hyper-V와 같은 기술이 발전하면서 여러 대의 웹 서버를 더 쉽게 더 많이 만들 수 있게 되었다. 이로 인해 기하급수적으로 서버가 늘어나면서 서버에 관한 프로비저닝과 운영에 대한 이슈가 발생하였고, 이를 해결하기 위해 서버 구축 및 운영에 대한 자동화 기술이 필요하게 되었다. 이러한 배경을 통해 코드로 인프라를 구축 및 운영할 수 있는 IaC가 생겨나게 된 것이다. 이로 인해 IaC를 이용하여 IT 인프라 요구 사항을 관리함과 동시에 일관성을 높이고 오류 및 수동 구성을 줄일 수 있다.
⚙️ IaC는 다음과 같이 2가지 형태의 코드를 제공할 수 있다.
| 선언형 (일반적으로 IaC에서 많이 선택하는 형태) |
절차형 (=명령형) |
|
|
3. 코드형 인프라(IaC)의 장점
- 비용 절감
- 배포 속도 향상
- 오류 감소
- 인프라 일관성 향상
- 구성 변동 제거
4. 테라폼(Terraform) 작동 방식
1️⃣ Terraform 개념
테라폼(Terraform)은 하시코프사(HashiCorp)에서 공개한 선언형 IaC 도구다. 테라폼은 세 가지 중요한 철학(워크플로에 집중, 코드형 인프라, 실용주의)을 담아 설계되었다.
- 테라폼(Terraform)은 HCL(Hashicorp Configuration Language)라는 테라폼 특유의 문법을 사용한다.
- 테라폼 코드는 모두 HCL 문법으로 선언적으로 작성한다.
- HCL은 JSON 형식과 비슷하다. (JSON 문법이 원형이기 때문이다)
- 테라폼(Terraform)으로 다양한 클라우드를 사용할 수 있다.
- 같은 테라폼 코드 구성으로 다른 클라우드를 쉽게 작동시킬 수 있다.
- 다만, AWS의 테라폼 코드로 Azure를 작동시킬 수는 없다.
- 하지만 AWS나 Azure의 클라우드 구성이 같기 때문에 코드의 이름과 설정만 조금 바꿔주면 작동 시킬 수 있다. (AWS의 가상머신 = EC2 / Azure의 가상머신 = Virtual Compute Service)
- 같은 테라폼 코드 구성으로 다른 클라우드를 쉽게 작동시킬 수 있다.
- 테라폼(terraform)의 명령어를 실행하면 실행한 위치의 모든 .tf 파일을 읽어서 실행한다.
일반적으로 아래와 같은 폴더 구조로 된다.
# 기본 구조 (minimal)
Terraform_folder/
├── README.md
├── main.tf
├── variables.tf
├── outputs.tf# 기본 구조 (maximal)
Terraform_folder/
├── README.md
├── main.tf
├── variables.tf
├── outputs.tf
├── modules/
| ├── main.tf
| ├── variables.tf
| ├── outputs.tf# 개발 환경별 폴더 나누는 방법
# - 각 환경에 맞게 각각 나눠줌으로써 실행 가능
# - 각 폴더마다 .tfstate 파일을 따로 생성함으로써 꼬임 방지 가능
├── dev/
│ ├── main.tf
│ ├── variables.tf
├── stage/
│ ├── main.tf
│ ├── variables.tf
└── prod/
├── main.tf
└── variables.tf
2️⃣ Terraform 구성 파일
.tf 파일, .tfstate 상태 파일, .backup 파일, .main.tf 파일, .lock.hcl 잠금 파일, .variables.tf 파일, *.tfvars 파일
| 📁 .tf 파일 |
|
| 📁 .terraform.tfstate (상태 파일) |
|
| 📁 .terraform.tfstate.backup (백업 파일) |
테라폼 명령어를 실행하여 인프라 반영하면 테라폼에 의해 자동으로 생성되는 특별한 파일
|
| 📁 .main.tf |
|
| 📁 .terraform.lock.hcl (잠금 파일) |
terraform init을 실행 했을 때, 그 위치의 디렉토리에 자동으로 생성되는 잠금 파일 (.terraform.lock.hcl 파일 뿐만 아니라, 📁.terraform 파일도 같이 생성된다.)
|
| 📁 .variables.tf |
테라폼 모듈 내에서 사용할 변수를 정의하는 데 사용되는 파일
|
| 📁 *.tfvars 파일 |
테라폼 변수에 값을 할당하는 데 사용되는 파일
|
3️⃣ 테라폼(Terraform) Workflow
4️⃣ Main Commands (주요 커맨드)
init, validate, plan, apply, destroy
| init (초기화) |
|
terraform [global options] init [options]- 테라폼을 시작하고 테라폼의 상태를 저장하기 위한 .tfstate 파일을 생성한다.
- 테라폼은 기존 내용과 변경이 있는 내용을 확인하여 변경된 내용만을 반영한다. (형상관리도구)
- 상태 파일은 백업을 위해 별도로 .backup 파일도 생성한다.
- 0.14 버전 이후부터 프로바이더 종속성을 고정시키는 .lock.hcl 파일이 추가되었다.
- .lock.hcl 파일이 있으면 해당 파일에 명시된 버전으로 init을 수행한다. 이후 작업자가 의도적으로 버전 변경하거나, 코드에 명시한 다른 버전으로 변경하려면 terraform init -upgrade를 수행해야 한다.
# upgrade (버전 변경)
terraform init -upgrade
| validate (검증) |
|
terraform [global options] validate [options]- -no-color : 해당 옵션을 추가하면 출력의 색 표기를 제거해준다.
- -json : 서브 커맨드 옵션 중에 -json 옵션을 사용할 수 있는 명령어는 실행 결과를 JSON 형식으로 출력할 수 있다.
- 단어 의미 그대로 디렉터리에 있는 테라폼 구성 파일의 유효성을 확인한다. (이 때, 코드적인 유효성만 검토)
# -no-color
terraform validate -no-color
# -json
terraform validate -json
| plan (계획) |
|
terraform [global options] plan [options]- -detailed-exitcode
- 옵션이 없던 때와 결과는 같지만, exitcode가 환경 변수로 구성된다.
- exitcode 또는 errorlevel은 동작의 결과를 숫자 코드로 제공한다.
- 0 : 변경 사항이 없는 성공
- 1 : 오류가 있음
- 2 : 변경 사항이 있는 성공
- -out=<파일명> : -out=<파일명> 형식으로 파일 이름이 정해져 플랜 결과가 생성된다. 바이너리 형태이기 때문에 내용을 확인할 수 는 없다.
- plan 명령어는 테라폼으로 적용할 인프라의 변경 사항에 관한 실행 계획을 생성하는 동작이다. 즉, 실제로 프로비전이 되는 것이 아닌, 미리 예측해보는 테스트인 것이다.
- 테스트를 통해 리소스 내에 데이터 값으로 어떤 값이 사용되는지 여부 또는 코드의 오류를 미리 점검해볼 수 있다.
- 그러나, plan에서 오류가 없다고 하더라도 실제 프로비전에서는 이를 보장해주지는 않는다.
| apply (실행) |
|
terraform [global options] apply [options] [PLAN]- .tf 파일의 terraform 코드(변경 사항)를 클라우드 서비스에 배포하는 명령어
- ‘실제 프로비전’ > 변경 사항을 실제 인프라에 적용한다.
- 생성된 최종 정보는 .tfstate 파일이 저장되며, .backup 파일에도 이를 저장 시켜 준다.
| destory (제거) |
|
terraform [global options] destory [options]- .tf 파일에 기반하여 프로비전된 리소스를 일괄 삭제한다. (만들어진 인프라 삭제)
- terraform apply와는 반대로 삭제되는 리소스들을 조회한 후, yes를 입력하게 되면 삭제를 진행한다.
5️⃣ Terraform 기본 개념
Provider, Provisioner, Resource, Variables, Locals, Outputs, State, Module, data Source
| Provider (프로바이더) |
|
provider "<provider>" {
attribute1 = value1
}| Provisioner (프로비저너) |
|
resource "aws_instance" "example" {
provisioner "local-exec" {
command = "echo 'Hello, world!'"
}
}| Resouce (리소스) |
|
# resource_name은 사용자가 임의로 지정할 수 있다.
resource "<provider>_<resource_type>" "<resource_name>" {
attribute1 = value1 # 속성과 설정
}| Variables (베리어블 ; 변수) |
|
variable <name> {
description = <value>
type = <value>
default = <value>
}
# var.<name>| Locals (로컬) |
|
locals {
name = "my-instance"
}| Outputs (아웃풋 ; 출력) |
|
# output 콘솔 확인 가능
$ terraform apply
...(생략)
Apply complete! Resources: 0 added, 0 changed, 0 destroyed.
Outputs:
vpc_id = "vpc-0xxxxxxxxxxxb3d6"
# 명령을 통해 터미널에서 쉽게 출력 가능
terraform output <target>
# 기본 문법
output <output_name> {
value = <value>
}| State (스테이트 ; 상태) |
|
| Module (모듈) |
|
module "<name>" {
source = <source_path>
}| Data Source (데이터) |
|
# external_data_source_type : 각 공급자의 데이터 유형을 지정.
# data_block_name : 데이터 블록의 이름을 지정.
data <external_data_source_type> <data_block_name> {
# 데이터 블록 설정 및 속성
}
🔎 HCL (Hashicorp configuration Language)
HCL(HashiCorp configuration language)은 하시코프사에서 IaC와 구성 정보를 명시하기 위해 개발된 오픈 소스 도구다.
- 테라폼에서는 HCL이 코드의 영역을 담당한다.
- HCL은 쉽게 읽을 수 있고 빠르게 배울 수 있는 언어의 특성을 가진다.
- 선언적(인프라=코드) 특성을 갖게 되고, Turing-complete(튜링 완전한) 언어적 특성을 갖는다.
- 즉, 일반적인 프로그래밍 언어의 조건문 처리 같은 동작이 가능하다는 것이다.
HCL을 사용하는 이유
하시코프사에서 Ruby 같은 여타 프로그래밍 언어를 사용해 JSON 같은 구조를 만들어 내기 위한 작업을 진행하면서 알게 된 것은 어떤 사용자는 사람에게 친화적인 언어를 원하고, 또 어떤 사용자는 기계 친화적인 언어를 원한다는 것이다. 그러나, 아래에 정리된 표와 같이 어느 것을 골라 정하기도 쉽지 않다.
| JSON | YAML | 일반적인 프로그래밍 언어 |
|
|
|
그래서 하시코프사에서는 HCL을 개발하였고, HCL을 사용하면 동일한 내용을 JSON으로 표현하는 것보다 50~70퍼센트 더 간결하고 읽기 쉽게 작성할 수 있다. 그리고 HCL 표현식에는 일반적으로 코드에서 사용되는 주석 표기부터 변수 정의 등을 포함하고 프로그래밍적인 연산과 구성 편의성을 높이기 위한 function도 제공하고 있다.
https://developer.hashicorp.com/terraform/language/functions
https://github.com/hashicorp/hcl
5. 테라폼과 다른 코드형 인프라 도구
Terraform, Chef, Puppet, Ansible, AWS Cloudformation...
6. 출처 및 참고 자료
- [도서] 테라폼으로 시작하는 IaC - 한빛미디어 (김민수 김재준 이규석 이유종 지음)
- https://www.redhat.com/ko/topics/automation/what-is-infrastructure-as-code-iac [코드형 인프라 개념 및 인프라 프로비저닝 자동화 방법]
- https://www.atlassian.com/ko/devops/what-is-devops/history-of-devops [데브옵스의 역사]
- https://jibinary.tistory.com/86 [테라폼의 기본 구성과 용어 쉽게 정리 등...]
- https://developer.hashicorp.com/terraform/language/files/dependency-lock [terraform Dependency Lock File]
- https://registry.terraform.io/browse/providers [Provider 종류 - AWS, Azure, ...etc]
- https://registry.terraform.io/providers/hashicorp/aws/latest/docs [Provider Docs]
- https://registry.terraform.io/providers/hashicorp/kubernetes/latest/docs [k8s Provider]
- https://developer.hashicorp.com/terraform/language/resources/provisioners/syntax#provisioners-are-a-last-resort [Provisioners]