지구를 Terraform으로 물들이다.

Terraform

개요

일반적으로, 우리는 AWS와 같은 클라우드 서비스 제공업체의 콘솔을 통해 인프라 리소스를 관리하고 있을 것이다. 소규모 프로젝트나 모놀리식의 간단한 프로젝트를 구성하였을 때에는 이런 접근 방식은 문제가 되지 않을것이다. 그러나 프로젝트 규모가 확장되어 수많은 부하 분산 시스템을 구성하거나, 접근 가능한 사용자를 관리하기 위한 여러 Rule을 정의하거나, 멀티 컨테이너 환경을 구성하기 시작하는 등 복잡한 요구사항이 지속적으로 발생할 때, AWS 콘솔을 이용하여 인프라를 관리하는 것은 많은 시간이 소모될 것이고, 자신이 어떤 설계를 하였는지 잘 기억나지 않을 것이다.

 

더욱이, 운영 환경과 개발 환경을 별도로 구성하게 된다면, 동일한 행위를 반복하게 될 것이고, 또 다른 스테이지 구현이 필요하게 된다면, N번 이상의 반복을 하게 될 것이다. 이러한 반복은 결코 효율적이지않다.

 

더이상 이런 불편함을 경험하고 싶지 않다면, 코드로써 인프라를 구축할 수 있도록 IaC(Infrastructure as Code)를 도입하는 것을 강력하게 추천한다.

 

IaC (Infrastructure as Code)

IaC (Infrastructure as Code)란
코드로써 인프라를 관리하고 정의하는 것을 뜻한다.

 

일반적으로 IaC 를 구성할 수 있는 도구는 여러 가지 존재하는데,

• 서버리스 서비스를 제공하는 Lambda를 더욱 효율적으로 구축할 수 있는 Serverless Framework
• AWS Resource를 더욱 빠르게 구현할 수 있는 AWS Cloud Formation
• 일반적인 개발 언어로써 AWS 인프라를 구축할 수 있는 AWS CDK 등

위와 같은 도구 뿐만 아니라 AWS, Azure와 같은 클라우드 제공 업체(CSP, Cloud Service Provider)에 종속되지 않고, 여러 서비스를 통합하여 구축할 수 있는 Terraform이 가장 많은 사랑을 받고 있는 IaC 도구이다.

Terraform

Terraform은 Hashicorp에서 개발한, 인프라를 코드로 관리(Infrastructure as Code, IaC)하는 도구이다. 클라우드
제공업체에 종속되지 않고, 여러 서비스에 걸쳐 인프라를 구성하고 관리할 수 있다.

 

Terraform을 도입하게 된다면, GUI나 웹 콘솔을 통합 수동 작업 없이, 전체 인프라를 코드 형태로 정의하고 버전 관리할 수 있게 된다. IaC 중에서 가장 대표적인 도구이며, Open Source로써 많은 사랑을 받고 있는 도구이다.

    → 다만, 1.5.5 버전부터 BSL 1.1 라이센스가 적용되어 많은 논란이 발생하게 되었고, OpenTofu 프로젝트의 시발점이 되었다.

 

Terraform의 특징

• 선언적 인프라 관리: Terraform은 인프라 리소스를 선언적으로 정의하여, 현재 인프라의 상태를 명확하게 인지할 수 있고, 변경 사항을 쉽게 추적할 수 있게 된다.
• 플랫폼 독립성: AWS, Azure, GCP 등 다양한 클라우드 제공업체 뿐만 아니라, Helm, Kubectl과 같은 여러 Custom Provider를 도입하여 사용할 수 있는 플랫폼 독립성을 가지고 있다.
• 변경 관리 및 버전 제어: 인프라 정의하고 배포하기 전 어떤 변경사항이 발생할지 미리 확인할 수 있다. 또한, 코드로써 인프라를 관리하기 때문에, 별도의 Git과 같은 버전 관리 시스템을 사용한다면 인프라의 변경 사항 또한 함께 관리될 수 있다.

 

Terraform Setup

Terraform Install

Terraform은 Mac을 사용한다면 Brew를 통해 설치하거나, Window를 사용한다면 Chocolatey를 통해 설치할 수 있다. 이번에는 아주 간단하게 Terraform을 설치하고 버전을 출력하는 작업을 진행해보자.

 

# [Mac] Homebrew로 설치
$ brew install terraform

# [Window] Chocolatey로 설치
$ choco install terraform

# terraform 버전 확인
$ terraform version

 

AWS Configuration Setup

이번에 예제들은 Terraform의 AWS Provider를 중점적으로 확인해볼 예정이다. 그렇기 때문에, Terraform에 대한 설정 뿐만 아니라, AWS Configuration에 대해서도 함께 설정이 진행되어야 한다.

 

AWS Configuration 설정의 경우는 아래의 AWS Documentation 을 통해 갈음하도록하겠다.

• 구성 및 자격 증명 파일 설정 - AWS Command Line Interface

 

Terraform Command

Terraform은 여러 인프라 리소스를 생성, 수정, 삭제하는 작업을 CLI를 이용하여 수행할 수 있다. Terraform을 사용하기에 앞서, 먼저 Terraform CLI의 Command에 대한 이해가 필수적이다. 그렇다면, 프로젝트의 라이프사이클을 관리하는데 필수적인 Teraform의 주요 명령어들에 대해 하나씩 알아보도록 하자.

 

Terraform init

terraform init 은 Terraform 프로젝트를 초기화하며, 필요한 Plugin과 Provider를 설치하는 명령어이다.

 

우리가 만약, AWS 와 Azure를 사용하기 위해 2가지의 Provider를 정의하게 된다면, terraform init 명령어를 통해, Provider를 설치하게 될 것이다. 또한, Terraform 구성 파일(.tf)이 있는 디렉토리에서 이 명령어를 실행하여 Back-end 저장소를 설정하거나, 모듈을 초기화할 수 있다.

 

# Terraform Project 초기화한다.
terraform init

 

 

프로젝트를 초기화 하였을 때 .terraform 폴더와 .terraform.lock.hcl 파일이 생성된다.

• .terraform 폴더는 Terraform이 관리하는 Provider 구현체와 Registry 파일들이 저장된다.
• .terraform.lock.hcl 파일은 중복되는 배포를 방지하기 위한 Lock 파일이다.

 

Terraform apply

terraform apply은 Terraform 구성 파일에 정의된 인프라 구성 요소들을 클라우드 제공 업체(CSP, Cloud Service Provider)에 배포하는 명령어이다.

 

만약, EC2 인스턴스를 Terraform 코드로써 정의하였다면, terraform apply 명령어를 통해, EC2 인스턴스를 AWS에 배포할 수 있게 되는 것이다.

 

또한, terraform apply 명령어는 먼저 실행 계획을 출력하고, 개발자에게 어떤 변경점이 발생하는지 확인을 요청하게 된다. 그로인해, 삭제, 생성 또는 수정될 리소스를 파악하고, 잘못된 요소들이 없는지 확인할 수 있게 되는 것이다.

 

# Terraform 코드에 정의된 리소스를 배포한다.
terraform apply

 

Terraform plan

terraform plan, Terraform 구성 파일을 기반으로 인프라가 어떻게 배포될 것인지 실행 계획을 출력하는 명령어이다.

 

해당 명령어로 인해, 실제 리소스에 어떤 변경사항이 발생하는지 확인할 수 있게 되고, 생성, 수정, 삭제 될 리소스를 미리 검토할 수 있어, 인프라를 배포하기 전 필수적으로 사용해야 하는 명령어이다.

 

# Terraform 코드를 기반으로 실행 계획을 조회한다.
terraform plan

 

Terraform destroy

terraform destroy, Terraform을 사용하여 배포된 모든 리소스를 삭제하는 명령어이다.

 

좀 더 자세하게 설명하자면, Terraform에 선언되어 있는 리소스를 삭제하는 것이 아닌, Terraform State 파일에 기록된 모든 리소스를 삭제하는 역할을 담당한다.

• Terraform State는 실제 배포된 리소스들의 현재 상태를 추적하는 파일이다. 이 파일은 Terraform 리소스들의 상태를 관리하고, 실제 인프라와 계획된 변경 사항을 파악하는데 사용되는 요소이다.

# Terraform 으로 생성된 모든 리소스를 삭제한다.
terraform destroy

 

Other Options

--auto-approve

매번 Terraform 리소스를 배포하거나, 삭제할 때마다 yes 라는 커맨드를 추가로 입력하고 싶지 않다면, --auto-approve 옵션을 뒤에 입력해보자. 더이상 배포하거나 삭제하기 위해 추가적인 명령어를 입력하지 않아도 될 것이다.

 

이 옵션은 특히 Local 환경이 아닌 CI/CD 과정에서 유용한데, 만약, Terraform을 CI/CD와 통합한다면, 사용자의 승인 커맨드 입력 없이 자동으로 인프라 변경사항을 적용할 수 있기 때문에, 필수적으로 사용해야 하는 추가적인 옵션이다.

 

# Terraform 코드에 정의된 리소스를 배포한다. (자동 승인)
terraform apply --auto-approve

# Terraform 으로 생성된 모든 리소스를 삭제한다. (자동 승인)
terraform destroy --auto-approve

 

 

Terraform Object

Terraform은 다양한 객체를 사용하여 인프라의 구성요소를 정의하고 관리한다. 이러한 객체들은 실행 결과를 출력하거나, 클라우더 서비스 제공업체(CSP)의 구성 요소를 조회, 또는 실제 인프라 구성 요소를 정의하는 데 사용된다. 이번에는 이러한 Terraform Object에 대해 살펴보도록 하자.

 

Output

output은 Terraform의 실행 결과를 출력하는 역할을 담당한다.

 

python의 print, javascript의 console.log와 유사하게, Terraform 실행 시 확인하고자 하는 값들을 콘솔에 표시한다.

• 하지만, output이 Terraform Module 내부에 위치하게 된다면, Module의 반환값으로 사용된다.

output "item" {
  description = "Item description"
  value       = "Hell, World! my name is item"
}

Provider

provider는 Terraform이 인프라를 관리할 때 사용하는 서비스 제공 업체를 정의한다.

 

여기서 Provider란 Terraform이 공식 제공하는 클라우드 제공업체(AWS, Azure, GCP 등) 뿐만 아니라, Custom Provider를 통해 기타 서비스와 통신할 수 있도록 인터페이스를 제공하는 역할을 담당한다.

 

만약, AWS에 대한 리소스를 구현하고 싶다면, 아래와 같이 aws Provider를 선언해야만 여러 리소스를 구성 할 수 있게 되는 것이다.

 

**provider** "aws" {
  region = "ap-northeast-2"
}

 

Resource

resource는 Terraform에서 관리하는 인프라의 기본 구성 단위이다.

 

특정 Provider가 제공하는 리소스 타입을 기반으로 실제 클라우드 리소스(ex: EC2 인스턴스, VPC, S3 Bucket 등)를 정의하고 조작하는 역할을 담당한다.

 

리소스는 Terraform 코드에서 선언적으로 정의되며, 인프라를 프로비저닝할 때 실제로 생성되는 객체이다. 만약, EC2 인스턴스를 배포하고 싶다면, aws_instance 리소스 타입과 상세 요구사항을 정의할 수 있게 되는 것이다.

 

resource "aws_instance" "this" {
  ami           = "ami-07eff2bc4837a9e01" # Amazon Linux 2023 AMI 2023.3.20240205.2 x86_64 HVM kernel-6.1
  instance_type = "t3.micro"
}

 

Data Sources

data는 Terraform에서 이미 존재하는 외부 리소스의 정보를 조회하는 역할을 담당한다.

 

만약, AWS VPC를 구축하는 프로젝트와 별개로 EC2 인스턴스를 구축하는 프로젝트가 있다고 가정해보자. EC2 인스턴스를 생성할 대, 소속될 VPC 정보가 필요하지만, EC2 프로젝트에서는 직접 VPC를 관리하지 않는다. 이때 data 를 사용하여 필요한 VPC 정보를 조회할 수 있게 된다.

 

data를 통해, 실제 구현체와 참고에 필요한 구현체를 명확하게 나눌 수 있게 될 것이고, 프로젝트의 관심사를 분리함으로써 관리를 단순화 할 수 있게 된다.

 

data "aws_vpc" "this" {
  cidr_block = "172.133.0.0/16"
}

 

Input Variable

variable은 Terraform에서 사용하는 변수 그 자체를 정의하기 위해 사용한다.

 

Variable은 외부에서 주입받기 위해 사용하는 변수 그 자체라고 보면된다. 만약, 구현하려고 하는 프로젝트 명을 다르게 구축해야하거나, Env를 주입하여 프로젝트의 Stage를 Prod(운영), Dev(개발) 환경으로 분리할 필요성이 있다면 Variable을 통해 각각의 변수를 별도로 주입할 수 있게 된다.

 

이로인해, 하나의 Terraform 코드 베이스로 여러 환경을 구축할 수 있게 되며, 원하는 인프라 리소스를 자유롭게 구성할 수 있게 되는 것이다.

 

variable "vpc_cidr" {
  description = "The CIDR block for the VPC"
  type        = string
  default     = "10.0.0.0/16"
}

 

Local Values

외부에서 주입받는 Variable과 달리 local은 Terraform 코드 내부에서 여러 리소스에서 반복적으로 사용될 값을 변수로써 정의한다.

 

만약, Variable을 통해, 프로젝트 명과 Stage를 전달받았다면, 실제 각각의 인스턴스 이름을 ${프로젝트명}-${Stage 명} 과 같이 구현할 수 있는데, 해당하는 인스턴스 이름을 바로 할당하지 않고, Local Values로써 정의할 수 있게 되는 것이다.

 

예를 들어, 전달받은 Variable을 통해 프로젝트 명과 환경(Stage) 명을 조합하여 사용해야 할 경우, Local Values를 사용하여 조합된 이름을 한번 정의하고 코드 내 여러 위치에서 재사용할 수 있게 된다.

 

locals {
  default_name = "${var.env}-${var.project_name}"
}

 

Terraform Settings

terraform은 Terraform의 버전 제약사항이나 Back-end, 필수 Provider 를 정의하기 위해 사용한다.

 

프로젝트에서 이전 버전에서 지원하지 않는 문법이 존재하거나, BSL 라이선스로 인해 추가적인 비용이 발생하지 않도록 하기위해 1.5.5 버전 이하로 사용하려 한다면, terraform 문법을 통해 제약사항을 더욱 상세하게 정의할 수 있게된다.

 

terraform {
  # terraform 버전을 명시해준다.
  required_version = ">= 1.3"

  # 필수로 사용할 provider를 명시해준다.
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = ">= 5.0.0"
    }
  }
}

 

Terraform Collection Types

Set

set 타입은 중복된 값을 가질 수 없는 고유한 값의 데이터 타입이며, 동일한 타입의 여러 값을 순서를 고려하지 않은 배열 형태로 사용한다.

output "set-example" {
  value = toset(["a", "b", "c", "d", "e"])
}

 

List

list 타입은 순서가 있는 데이터 타입이며, 동일한 타입의 여러 값을 배열 형태로 사용한다.

output "list-example" {
  value = ["a", "b", "c", "d", "e"]
}

 

Map

map 타입은 key-value 형식의 데이터 타입이다. object 와 동일하게 사용한다.

output "map-example" {
  value = {
    a = "a"
    b = "b"
  }
}

 

Heredoc Strings (EOT)

우리는 일반적으로 개발을 하더라도 1개의 변수에 String 뿐만 아니라, Multi Line String을 구현하는 과정을 많이 겪었을 것이다. 하지만, Terraform은 변수에 너무 많은 String을 삽입하게 된다면, 코드를 한눈에 보기 불편한 상황이 발생하게 될 것이다. 또한, Json 형태의 데이터를 하나의 변수에 할당하기 위해서는 1개의 String으로는 표현하기 어려움을 겪을 것이다.

 

이러한 문제점을 해결하기 위한 방법이 “Heredoc Strings” 문법이다.

 

이 문법을 이용하여 더욱 편리하게 json, yaml과 같은 여러 타입의 문서를 더욱 명확하고 간결하게 표현할 수 있게 되었고, AWS EC2 Instance의 user data, Kubernetes의 manifest를 별도의 파일이 아닌, 하나의 .tf 파일로써 관리할 수 있게 해준다.

 

output "heredoc_strings" {
  value = <<EOT
    Heredoc
      Is
    G o o D!
EOT
}

# Print
# + heredoc_strings = <<-EOT
#         Heredoc
#               Is
#             G o o D!
#     EOT

 

Terraform Loop

Terraform을 사용할 때, 여러 리소스를 반복적으로 구성해야 하는 경우가 종종 발생한다. 이를 위해 Terraform은 count와 for_each 두 가지 주요 방법을 제공하는데, 이 두 방법은 유사한 작업을 수행하지만, 사용법과 적용 시나리오에 차이가 있다.

 

count

count는 리소스를 특정 횟수만큼 반복하여 리소스를 생성하거나 정의하기 위해 사용한다.

 

만약, 동일한 설정을 가진 리소스를 여러개 생성하려 해보자. 일반적인 생각으로는 “동일한 이름으로 리소스를 생성하면 되지 않을까?” 라는 생각을 하겠지만, 실제로 구현하려 했을때, 아래와 같은 에러가 발생하게 될 것이다.

 

이런 문제점을 해결하기 위해, Terraform은 동일한 이름을 가진 Resource를 배열 형태로 가질 수 있게된다. 만약, 동일한 설정을 가진 EC2 인스턴스를 5개 생성하려 한다면 count 를 사용하게 되었을 때, 간단히 여러개의 리소스를 생성할 수 있게 된다.

 

resource "aws_instance" "this" {
  count = 5

  ami           = "ami-07eff2bc4837a9e01" # Amazon Linux 2023 AMI 2023.3.20240205.2 x86_64 HVM kernel-6.1
  instance_type = "t3.micro"

  tags = {
    Name = "Hello-World-${count.index + 1}"
  }
}

 

이 코드는 ami-07eff2bc4837a9e01를 사용하는 t3.micro 타입의 EC2 인스턴스를 5개 생성한다. count는 0부터 시작하여, 각 인스턴스에 고유한 인덱스를 부여하며, 이를 통해 각 인스턴스를 구별할 수 있게 된다.

 

for_each

for_each는 맵(Map) 또는 집합(Set)과 같은 컬렉션을 이용하여 각 항목에 대해 리소스를 반복한다.

 

for_each는 보다 복잡한 반복 구조를 구현할 때 사용되며, 주로 각 리소스에 대해 다른 설정을 적용해야 할 때 사용한다.

 

locals {
  example_map = {
    key1 = "t3.micro"
    key2 = "c5.large"
  }
}

resource "aws_instance" "for_each_example" {
  for_each = local.example_map

  ami           = "ami-07eff2bc4837a9e01" # Amazon Linux 2023 AMI 2023.3.20240205.2 x86_64 HVM kernel-6.1
  instance_type = each.value

  tags = {
    Name = "Hello-World-${each.key}"
  }
}

 

이 코드는 두 개의 EC2 인스턴스를 생성하며, 각각 다른 instance_type을 사용한다. for_each를 사용하면, 컬렉션의 각 항목에 대해 적용할 수 있으며, each.key와 each.value를 통해 키(Key)와 값(Value)을 참조할 수 있다.

 

Other

Terraform의 반복문은 Resource에만 적용되는 것이 아니라 변수에도 할당할 수 있는데, python의 list comprehension과 비슷하게 사용할 수 있다.

 

validation_record_fqdns = [for record in aws_route53_record.request : record.fqdn]

 

AWS Provider

AWS Provider는 Terraform이 공식적으로 제공하는 대표적인 CSP Provider이다.

 

AWS Provider는 Terraform을 사용하는 대다수의 개발자가 경험하는 프로바이더이다. AWS 리소스를 관리하고자 하는 거의 모든 개발자에게 필수적인 프로바이더로써, AWS 라는 가장 널리 사용되는 클라우드 플랫폼을 사용할 수 있도록 도와준다.

 

provider "aws" {
  # provider는 terraform이 사용할 클라우드 서비스를 명시해준다.
  region = "ap-northeast-2"
}

terraform {
  # terraform 버전을 명시해준다.
  required_version = ">= 1.3"

  # 필수로 사용할 provider를 명시해준다.
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = ">= 5.0.0"
    }
  }
}

 

Terraform Resource Naming Convention

Terraform의 리소스 네이밍 컨벤션은 ${provider}_${resource name} 의 형식을 따르며, Camel Case를 사용한다.

예를 들어, AWS의 VPC를 사용하고 싶다면, aws_vpc를, AWS의 Internet Gateway를 사용하고 싶다면, aws_internet_gateway로 사용할 수 있다.

 

일반적으로, CSP(Cloud Service Provider)의 리소스를 Terraform에서 찾고자 할 때는 Terraform 문서를 참조하거나, 네이밍 컨벤션을 기반으로 검색 엔진에서 찾아보는 것을 추천한다.

 

AWS VPC

AWS VPC(Virtual Private Cloud)는 AWS 클라우드에서 격리된 네트워크 공간을 생성할 수 있는 서비스이다.

 

Terraform에서는 aws_vpc Resource를 이용하여 VPC를 구축할 수 있으며, VPC 내부적으로 사용할 네트워크 IP 주소 범위를 CIDR 표기법으로 정의한다.

 

# Docs: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/vpc
resource "aws_vpc" "this" {
  cidr_block = "10.133.0.0/16" # CIDR Block을 정의한다.

  tags = {
    Name = "tf-aws-provider-tutorial-vpc" # VPC에 이름을 추가한다.
  }
}

 

AWS Subnet

AWS Subnet은 VPC 내에서 IP 주소 대역대를 지정하여 네트워크를 세분화한다. 각 서브넷은 다른 서브넷과 논리적으로 분리가 되어 있으므로 별도의 설정 없이는 동일한 VPC 내부라도 다른 서브넷에 접근할 수 없다.

 

Terraform 에서는 aws_subnet Resource를 이용하여 Subnet을 구성할 수 있다. Subnet의 필수(required)인자는 VPC ID가 존재하며, 해당 인자 없이는 인프라 리소스를 배포할 수 없다.

 

# Docs: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/subnet
resource "aws_subnet" "this" {
  vpc_id            = aws_vpc.this.id # 서브넷과 연동할 VPC의 ID를 지정한다.
  cidr_block        = "10.133.16.0/20" # 서브넷의 CIDR 블록을 지정한다.
  availability_zone = "ap-northeast-2a" # 서브넷이 생성될 가용영역을 지정한다.

  tags = {
    Name = "tf-aws-provider-tutorial-subnet" # 서브넷의 이름을 지정한다.
  }
}

 

위 예제에서는 이전에 생성한 this 이름을 가진 aws_vpc 리소스의 id 값을 사용하여 Subnet을 정의하게 된다. 대다수의 Terraform 리소스들은 이전에 정의한 리소스의 정보를 바탕으로 다음 리소스를 생성한다.

• 만약, 인프라 리소스가 생성되는 순서가 중요하다면, depends_on으로 생성 순서를 지정할 수 있다.

 

AWS Security Group

AWS Security Group은 VPC 내에서 특정 인스턴스를 대상으로 하는 가상 방화벽 역할을 담당한다.

 

Terraform 에서는 aws_security_group Resource를 이용하여 Security Group을 구성할 수 있다. Security Group의 필수 인자는 ingress, egress 가 존재하는데, 일반적인 설정을 할당하는 방식이 아닌 Attributes as Blocks 형태로 할당하는 특성을 가지고 있다.

 

또한, 이후 생성하게될 EC2는 직접적으로 Security Group과 Subnet을 할당해줄 수 있지만, Network Interface를 사용한다면, 네트워크 설정 정보를 통합하여 정의할 수 있다.

 

# Docs: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/security_group
resource "aws_security_group" "this" {
  name        = "tf-aws-provider-tutorial-sg" # 보안 그룹에 이름을 추가한다.
  description = "Allow inbound traffic" # 보안 그룹에 설명을 추가한다.

  vpc_id = aws_vpc.this.id # 보안 그룹을 VPC에 연결한다.

  ingress {
    # 외부에서 들어오는 트래픽을 정의한다.
    from_port   = 0 # 포트 대역대 시작 부분을 정의한다.
    to_port     = 0 # 포트 대역대 종료 부분을 정의한다.
    protocol    = "tcp" # 프로토콜을 정의한다.
    cidr_blocks = ["0.0.0.0/0"] # 허용할 IP 대역대를 정의한다.
  }

  egress {
    # 외부로 나가는 트래픽을 정의한다.
    from_port   = 0 # 포트 대역대 시작 부분을 정의한다.
    to_port     = 0 # 포트 대역대 종료 부분을 정의한다.
    protocol    = "-1"# 모든 프로토콜이 외부로 나갈 수 있도록 정의한다.
    cidr_blocks = ["0.0.0.0/0"] # 허용할 IP 대역대를 정의한다.
  }

  tags = {
    Name = "tf-aws-provider-tutorial-sg" # 보안 그룹에 태그를 추가한다.
  }
}

# Docs: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/network_interface
resource "aws_network_interface" "this" {
  subnet_id       = aws_subnet.this.id # 네트워크 인터페이스를 생성할 서브넷 ID를 지정한다.
  security_groups = [aws_security_group.this.id] # 네트워크 인터페이스에 보안 그룹을 지정한다.

  tags = {
    Name = "tf-aws-provider-tutorial-ni" # 네트워크 인터페이스에 태그를 추가한다.
  }
}

 

 

AWS EC2

AWS EC2(Elastic Compute Cloud)는 대표적으로 AWS의 컴퓨팅 리소스를 대여받을 수 있는 서비스이다.

 

Terraform 에서는 aws_instance Resource를 이용하여 EC2 Instance를 구성할 수 있다. EC2 Instance의 필수 인자는 ami, instance_type이 존재한다.

사용할 AMI(Amazon Machine Image)와 인스턴스 유형을 지정하여, 컴퓨팅 리소스를 대여받을 수 있다.

 

# Docs: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/instance
resource "aws_instance" "this" {
  ami           = "ami-07eff2bc4837a9e01" # AMI ID를 지정한다.
  instance_type = "t3.micro" # 인스턴스 유형을 지정한다.

  network_interface {
    device_index         = 0 # 네트워크 인터페이스의 디바이스 인덱스를 지정한다.
    network_interface_id = aws_network_interface.this.id # 네트워크 인터페이스 ID를 지정한다.
  }

  tags = {
    Name = "tf-aws-provider-tutorial-instance" # EC2 인스턴스에 태그를 추가한다.
  }
}

 

결론

이렇게 Teraform의 기본 문법과 AWS 프로바이더의 사용 방법에 대해 알아보게 되었다. 우리는 현재 인프라 리소스를 어떻게 작성할 수 있는지 알아보는 정도에 그쳤지만, 다음에는 AWS 리소스를 보다 체계적으로 설계하고 모듈화하여 효율적으로 관리하는 방법에 대해 알아보고자한다.

 

또한, 인프라 리소스에 대한 태깅 컨벤션을 정립하여, 다른 Terraform 프로젝트에서도 해당 리소스들을 쉽게 참조하고 구성할 수 있도록 만들어 볼 예정이다.