테라폼(Terraform) 이란?

---

 

이름만 들어도 좋은회사에서 취직할것같은 기술

테라폼

 

과연 테라폼이 무엇일까?

---

 

 

1. IaC(Infrastructure as Code)

테라폼은 대표적인 IaC 도구이다.

 

IaC란 마우스 클릭으로 일일이 만드는게 아니라, 코드를 작성하여 자동으로 생성하고 관리하는 도구를 말한다.

테라폼은 사실상 이 IaC분야의 표준으로 자리를 잡았는데, 

 

이는 단순히 테라폼이 먼저 나왔기 때문이 아니라, 클라우드 생태계 전반의 현실적인 요구를 충족했기 때문이다.

 

 

 

Aws의 CloudFormation,

Google Cloud Deployment Manager,

Azure Resource Manager 등

 

각각 클라우드 서비스만의 고유한 전용 IaC들이 있지만 

유독 테라폼이 각광받고 사랑받는 이유가 무엇일까?

 

 

---

 

 

1.1 멀티 클라우드 지원

Aws, Google Cloud Platform, Azure 전용 IaC들이 나왔음에도

테라폼은 위 메이저 클라우드들을 모두 커버할뿐만 아니라,

 

테라폼은
깃헙, 쿠버네티스, 카프카, Datadog, Cloudflare 등 수백 개의 외부 시스템을
한 언어(HCL)로 관리할 수 있다.

 

 

이런식으로 설계된것을 벤더 중립적으로 설계되었다고 하는데,

테라폼의 이런 선택은 시장의 요구와 정확하게 맞아 떨어졌다.

 

 

 

---

 

 

1.2 HCL 문법의 낮은 러닝커브

테라폼의 DSL(HCL)은 아래와 같은 특징들을 가지는데,

 

1. JSON / YAML보다 읽고 쓰기 쉬운 구조
2. 리소스 간 의존성을 자동으로 추적
3. 변수, 모듈, 로컬 변수 구조가 매우 직관적
4. 개발자, 인프라 엔지니어 모두 쉽게 접근 가능

 

이러한 특장점들 때문에,

팀 규모가 커지더라도 유지보수성이 높다.

 

 

특히 Pulumi라는 IaC와 비교했을때, 

Pulumi는 프로그래밍 언어로 작성하지만,

그만큼 복잡성이 증가하기 때문에, 조직 전체의 표준으로 삼기엔 다소 무거울 수 있다.

 

 

 

 

---

 

 

1.3 압도적인 프로바이더의 생태계

테라폼의 핵심이라고도 할 수 있는 Provider 시스템은

IaC의 본질을 꿰뚫고 있다.

 

 

IaC는 위에서도 언급했듯 클라우드 리소스를 코드로 수정, 생성 삭제 하는 도구인데,

우리네 클라우드는 지속적으로 새로운 리소스를 출시한다.

 

ex) 
- Aws에서 새로운 타입의 Lambda 기능 출시
- Cloudflare가 새로운 CDN 옵션 추가
- Github에서 새로운 API기능 오픈

 

이렇듯 새로운 리소스들이 마구 생겨날때, IaC도구가 이 기능을 빠르게 지원하지 않으면,

코드 기반 관리의 IaC의 목적이 무너진다.

 

 

 

즉 리소스 지원 속도 = IaC의 핵심이라고도 할 수 있는데,

 

테라폼은 주요 클라우드에서 발표하는 서비스가 빠르게 지원되기 때문에 큰 강점이 있고, 더 널리 사용되게 되었다.

ex)
1. AWS -> 새 서비스 출시
2. AWS Provider 팀 -> Provider 업데이트
3. 테라폼 레지스트리 -> 업데이트 반영
4. 사용자 -> 즉시 infra.tf 코드에서 사용 가능

 

 

 

 

---

 

 

2. 테라폼 사용 요령

코드로 인프라 세팅이나 설정을 관리한다는건 대충 알겠다.

그렇다면 어떤식으로 작성하고 이용하는것일까?

 

천천히 알아보자.

 

 

 

 

---

 

우리가 도커파일이나 도커컴포즈를 아키텍처 패키지에 포함시킬 필요 없듯이,

테라폼 코드의 위치도 굳이 백엔드 코드안에 둘 필요 없다.

 

project-root/
├── backend/                # Spring Boot 소스
│   └── src/...
├── frontend/               # React 소스
│   └── src/...
└── infra/                  # 여기에 Terraform 코드 작성
    ├── main.tf             # 핵심 리소스 정의 파일
    ├── variables.tf        # 변수 정의
    ├── outputs.tf          # 출력값 정의
    ├── provider.tf         # AWS 같은 provider 설정
    └── terraform.tfstate   # 실제 인프라 상태 저장 파일

(*간단한 테라폼 인프라 패키지를 포함한 프로젝트 세팅)

 

 

 

 

조금만 더 자세히 살펴보자.

 

 

 

resource "aws_instance" "example" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"
}

위 코드는 Aws의 EC2인스턴스를 실행시키는 main.tf 코드이다.

 

 

t2.micro나 익숙한 용어들이 보이기 때문에 대충 무슨뜻인지는 알겠으나,

어떻게 저 코드로 EC2 인스턴스를 띄운다는걸까?

 

 

테라폼 코드는 우리에게 익숙한 명령형 방식이 아니라 선언형 방식을 사용하는데 중점적으로 살펴봐야한다.

즉 위 코드는 "EC2 인스턴스가 있어야 한다"라는 목표 상태를 표현한것이다.

 

따라서 위 테라폼 파일을 작성하고,

실제 실행을 위해서는 실행 명령어를 CLI로 때려줘야한다.

 

 

 

 

*명령어 순서 
# 최초 1회
terraform init   # Provider 다운로드 및 초기화

# 이후 작업 시마다
terraform plan   # 변경 사항 미리보기
terraform apply  # 실제 인프라 생성/변경

+
terraform destroy  # 생성한 모든 리소스 삭제


*실 작업 순서
1. terraform apply 실행
        ↓
2. Terraform이 main.tf 파싱
        ↓
3. Provider 설정 확인 (AWS 자격증명, 리전 등)
        ↓
4. AWS Provider가 Terraform 코드(HCL)를
    AWS API 호출로 변환
        ↓
5. AWS SDK를 통해 실제 EC2 생성 요청
        ↓
6. AWS에서 EC2 생성 완료
        ↓
7. Terraform이 생성된 리소스 ID, 속성 등을
    terraform.tfstate에 저장

 

 

 

 

 

 

그리고 실제로 주로 이용되는 워크플로우는 아래와 같다.

 

 

*init은 최초 1회 또는 Provider 변경 시

** plan은 필수

 

 

 

 

결론:

메이저 클라우드 플랫폼을 사용하며 계정을 여러가지 사용하여 반복적인 인프라 구성 작업을 하거나,
중요한 인프라설정인 경우

테라폼을 이용하여 코드로 관리하게된다면 큰 이점들이 많다.

다음번에 테라폼을 실제로 사용하는 내용들을 작성해보도록 하겠다.