[Terraform] 테라폼의 개념

IaC 란

코드형 인프라(Infrastructure as Code, IaC)는 수동 프로세스가 아닌 코드를 통해 인프라를 관리하고 프로비저닝하는 것을 말한다. IaC를 사용하면 인프라 사양을 담은 구성 파일이 생성되므로 구성을 편집하고 배포하기가 더 쉬워진다. 또한 IaC는 매번 동일한 환경을 프로비저닝하도록 보장하고, 구성 사양을 코드화하고 문서화함으로써 구성 관리를 지원합니다. 따라서 구성 변경 사항을 문서화하지 않고 임시로 변경하는 일을 막을 수 있다.

 

버전 제어는 IaC의 중요한 부분이다. 다른 소프트웨어 소스 코드 파일과 마찬가지로 구성 파일도 소스 제어가 필요하다. 다른 소프트웨어 소스 코드 파일과 마찬가지로 구성 파일도 소스 제어가 필요하다. 코드로 인프라를 배포한다는 것은 인프라를 모듈식 구성 요소로 분할하고 자동화를 통해 다양한 방식으로 결합할 수 있다는 뜻이기도 하다.

 

IaC로 인프라 프로비저닝을 자동화하면 애플리케이션을 개발하거나 배포할 때마다 개발자가 직접 서버, 운영 체제, 스토리지, 기타 인프라 구성 요소를 수동으로 프로비저닝하고 관리할 필요가 없어진다. 인프라를 코드화하여 템플릿을 만들고 프로비저닝할때 이 템플릿을 사용하면 된다. 이러한 작업은 수동으로 진행할 수도 있고 Terraform과 Ansible 같은 자동화 툴을 사용할 수도 있다.

 

Iac에 대한 선언적 접근과 명령형 접근 방식 비교

IaC에 대한 접근 방식에는 선언적 방식과 명령형 방식 두 가지가 있다. 선언적 접근 방식에서는 필요한 리소스와 리소스의 속성 등 바람직한 시스템 상태를 정의하면 IaC 툴이 바람직한 상태로 구성해 준다.

한 선언적 접근 방식에서는 시스템 오브젝트의 현재 상태 목록을 유지하며, 이를 통해 인프라를 더 쉽게 관리할 수 있다.한편 명령적 접근 방식에서는 바람직한 구성을 얻기 위한 특정 명령을 정의하며, 정의된 명령을 올바른 순서로 실행해야 한다. 많은 IaC 툴이 선언적 접근 방식에 따라 원하는 인프라를 자동으로 프로비저닝한다. 원하는 상태를 변경하면 선언적 IaC 툴은 그러한 변경 사항을 적용한다. 명령형 접근 방식의 툴을 사용하려면 변경 사항을 어떻게 적용하는지 이해해야 한다. 보통 IaC 툴은 두 가지 방식을 모두 사용하지만, 둘 중 선언적 방식을 선호하는 경향이 있다.

 

Terraform이란

HashiCorp Terraform은 버전화, 재사용 및 공유할 수 있는 사람이 읽을 수 있는 구성 파일에서 클라우드 및 온프레미스 리소스를 모두 정의할 수 있는 코드형 인프라 도구이다. 그런 다음 일관된 워크플로를 사용하여 수명 주기 동안 모든 인프라를 프로비저닝하고 관리할 수 있다. Terraform은 컴퓨팅, 스토리지 및 네트워킹 리소스와 같은 하위 수준 구성 요소와 DNS 항목 및 SaaS 기능과 같은 상위 수준 구성 요소를 관리할 수 있다.

 

IaC의 장점

원래 인프라 프로비저닝은 시간과 비용이 많이 드는 수동 프로세스였다. 하지만 이제 데이터 센터의 물리적 하드웨어(조직에서 여전히 물리적 하드웨어를 사용할 수도 있음)가 아니라 가상화, 컨테이너, 클라우드 컴퓨팅을 이용하여 인프라 관리를 하게 되었다. 

클라우드 컴퓨팅이 등장하면서 인프라 구성 요소의 수가 늘어났고, 날마다 더 많은 애플리케이션이 프로덕션 환경에 릴리스되고 있다. 이에 따라 더 잦은 빈도로 가동하고, 중지하고, 확장할 수 있는 인프라가 필요해졌다. IaC 이용 사례를 확립하지 않으면 현재 인프라의 규모를 관리하기가 갈수록 어려워질 것이다.

조직은 IaC를 이용해 IT 인프라 요구 사항을 관리함과 동시에 일관성을 높이고 오류 및 수동 구성을 줄일 수 있다.

대표적으로 장점은 아래와 같다

• 비용 절감
• 배포 속도 향상
• 오류 감소
• 인프라 일관성 향상
• 구성 변동 제거

 

Terraform은 어떻게 작동하는가?

Terraform은 API(애플리케이션 프로그래밍 인터페이스)를 통해 클라우드 플랫폼 및 기타 서비스에서 리소스를 만들고 관리한다. 공급자는 Terraform이 액세스 가능한 API를 통해 거의 모든 플랫폼 또는 서비스와 함께 작동할 수 있도록 한다.

HashiCorp 및 Terraform 커뮤니티는 다양한 유형의 리소스 및 서비스를 관리하기 위해 이미 수천 개의 프로바이더 를 작성했다. Amazon Web Services(AWS), Azure, Google Cloud Platform(GCP), Kubernetes, Helm, GitHub, Splunk, DataDog 등을 포함 하여 Terraform Registry 에서 공개적으로 사용 가능한 모든 프로바이더를 찾을 수 있다.

핵심 Terraform 워크플로는 다음 세 단계로 구성된다.

• write: 여러 클라우드 공급자 및 서비스에 걸쳐 있을 수 있는 리소스를 정의한다. 예를 들어 보안 그룹 및 로드 밸런서가 있는 Virtual Private Cloud(VPC) 네트워크의 가상 머신에 애플리케이션을 배포하는 구성을 생성할 수 있다.
• plan: Terraform은 기존 인프라 및 구성을 기반으로 생성, 업데이트 또는 파괴할 인프라를 설명하는 실행 계획을 생성한다.
• apply: 승인 시 Terraform은 모든 리소스 종속성을 고려하여 올바른 순서로 제안된 작업을 수행한다. 예를 들어 VPC의 속성을 업데이트하고 해당 VPC의 가상 머신 수를 변경하면 Terraform은 가상 머신을 확장하기 전에 VPC를 다시 생성한다.

Terraform 주요 구조

테라폼은 프로바이더와 리소스를 구성하게되는데 각 블록으로 정의한다 

 

Providers

아래의 블록은 provider를 구성하는데 aws 프로바이더는 Terraform이 리소스를 만들고 관리하는 데 사용하는 플러그인이다.

Terraform 구성에서 여러 프로바이더 블록을 사용하여 다른 프로바이더의 리소스를 관리할 수 있다. 다른 프로바이더를 함께 사용할 수도 있다. 예를 들어 AWS EC2 인스턴스의 IP 주소를 DataDog의 모니터링 리소스에 전달할 수 있다.

provider "aws" {
  region  = "us-west-2"
}

 

Resources

블록을 사용 하여 인프라의 구성 요소를 정의한다. 리소스는 EC2 인스턴스와 같은 물리적 또는 가상 구성 요소이거나 Heroku 애플리케이션과 같은 논리적 리소스일 수 있다. 리소스 블록에는 블록 앞에 리소스 유형과 리소스 이름이라는 두 개의 문자열이 있다. 이 예에서 자원 유형은 aws_instance이고 이름은 app_server이다. 유형의 접두사는 공급자의 이름에 매핑된다. 예시 구성에서 Terraform은 공급자 를 사용하여 aws_instance리소스를 관리한다. aws리소스 유형과 리소스 이름은 함께 리소스의 고유 ID를 형성한다. 예를 들어 EC2 인스턴스의 ID는 aws_instance.app_server.이다 리소스 블록에는 리소스를 구성하는 데 사용하는 인수가 포함되어 있다. 인수에는 머신 크기, 디스크 이미지 이름 또는 VPC ID와 같은 항목이 포함될 수 있다. 프로바이더 참조는 각 리소스에 대한 필수 및 선택적 인수를 나열한다. EC2 인스턴스의 경우 예제 구성은 AMI ID를 Ubuntu 이미지로 설정하고 인스턴스 유형을 t2.micro AWS의 프리 티어에 적합하게 설정한다. 또한 인스턴스에 이름을 지정하는 태그를 설정한다.

resource "aws_instance" "app_server" {
  ami           = "ami-830c94e3"
  instance_type = "t2.micro"

  tags = {
    Name = "ExampleAppServerInstance"
  }
}

 

Terraform 주요 명령어

init

$ terraform init

새 구성을 생성하거나 버전 제어에서 기존 구성을 체크아웃할 때 terraform init.

구성 디렉터리를 초기화하면 구성에 정의된 프로바이더가aws라면 aws 프로바이더를 다운로드하고 설치한다

 

fmt

$ terraform fmt

terraform fmt명령은 가독성과 일관성을 위해 현재 디렉터리의 구성을 자동으로 업데이트한다

 

validate

$ terraform validate
Success! The configuration is valid.

terraform validate명령을 사용하여 구성이 구문적으로 유효하고 내부적으로 일관성이 있는지 확인할 수도 있다.

 

plan

$ terraform plan

실제로 어떻게 만들어질지에 대한 예측 결과를 보여주는 명령어이다. plan에 문제가 없어야 apply에 문제가 없을 확률이 높다 물론 plan이 정상적이어도 apply에서 문제가 일어날 때도 있다

 

apply

$ terraform apply

terraform apply 명령어는 변경 사항을 적용하기 전에 Terraform은 구성과 일치하도록 인프라를 변경하기 위해 Terraform이 수행할 작업을 설명하는plan을 출력한다. 문제가 없다면 apply를 실행하기위해 yes를 입력하고 엔터를 하게되면 프로비저닝이 시작된다

 

show

$ terraform show

apply를 하게된다면 로컬에 terraform.tfstate라는 상태를 저장하는 파일이 생성되는데 show옵션을 통해서 현재 상태를 검사할 수 있다

 

state list

$ terraform state list

show는 모든 내용을 출력했다면 terraform state list 명령어는 현재 apply중인 리소스의 이름만 리스트로 출력하게된다

 

 

 

 

기술출처

https://www.redhat.com/ko/topics/automation/what-is-infrastructure-as-code-iac

코드형 인프라(IaC)란? 개념 및 인프라 프로비저닝 자동화 방법

https://developer.hashicorp.com/terraform/tutorials/aws-get-started/aws-build

Build Infrastructure | Terraform | HashiCorp Developer