AWS 인프라, 콘솔 대신 Terraform으로 관리해보자

 

그동안 프로젝트를 진행하면서 필요한 리소스들은 AWS 콘솔에서 직접 만들어서 사용했다. EC2, S3, RDS, Redis와 같은 리소스를 하나씩 늘려가면서 작업했다.

콘솔에서 필요한 순간에 바로 만들 수 있고, 화면에서 설정을 확인할 수 있다보니 쉽게 느껴졌다.

 

그런데 리소스가 하나씩 늘어나다보니 생각보다 신경 쓸 부분이 많아졌다. 특히, 삭제할 때 불편했다. 인스턴스를 지웠다고 생각했는데 어디선가 비용이 청구되고 있었고, 어떤 리소스가 어떤 이유로 만들어졌는지도 시간이 지나면 점점 흐려졌다.

 

콘솔 기반 작업은 어떤 과정을 거쳐 리소스를 만들었는지 기록을 남기기 어려워서 배포 자동화를 고민하면서 다른 방식도 도입해보자는 생각이 들었다.

 

그래서 Terraform을 도입하게 되었다

인프라로 코드를 관리할 수 있으면 좋을 것 같았고 IaC 방식을 직접 경험해보고 싶었기 때문에 테라폼이 적절해 보였다. 이번 글에서는 테라폼을 도입하면서 AWS 인증과 리소스 생성 과정까지 정리해보려고 한다.

 

Terraform 설치와 실행 환경 확인

테라폼을 사용하기 위해 가장 먼저 로컬 환경에 테라폼을 설치했다. 

brew tap hashicorp/tap
brew install hashicorp/tap/terraform

 

설치 자체는 어렵지 않았고, 버전 확인으로 정상적으로 실행되는지 확인했다.

terraform version

 

테라폼만 설치했다고 바로 AWS 리소스를 만들 수 있는 것은 아니었다. 실제로는 AWS Provider를 통해 AWS API를 호출해야 하기 때문에 AWS CLI와 인증 정보도 준비되어 있어야 한다.

 

AWS 인증 준비

AWS 인증이 되어 있지 않았기 때문에 먼저 IAM 사용자부터 만들었다. 테라폼은 AWS 리소스를 생성하기 위해 적절한 권한을 가진 사용자가 필요하기 때문이다.

 

IAM 사용자를 생성하기 위해 사용자 이름을 설정한다.

 

테라폼과 AWS CLI에서 사용할 수 있도록 필요한 정책을 연결한다.

 

설정을 마친 뒤 사용자를 생성하면 된다.

 

 

위와 같이 사용자가 생성된 것을 확인할 수 있다.

 

액세스 키를 발급받기 위해 보안 자격 증명 메뉴로 이동한다.

 

CLI를 선택한 후 발급 받으면 액세스 키가 생성된다. 이때 발급된 키는 이후에 다시 확인하기 어렵기 때문에 저장해두는 것이 중요하다.

 

aws configure

AWS Access Key ID [None]: <YOUR_ACCESS_KEY>
AWS Secret Access Key [None]: <YOUR_SECRET_ACCESS_KEY>
Default region name [None]: ap-northeast-2
Default output format [None]: json

액세스 키를 발급받은 뒤에는 AWS CLI에 자격 증명을 반영했다.

aws sts get-caller-identity

설정 후에는 위 명령으로 인증이 정상적으로 적용되었는지 확인했다.

 

Terraform 코드 작성

AWS 인증 준비가 끝난 뒤에는 테라폼 코드 작성을 시작했다. 먼저 S3 버킷을 기준으로 테라폼 구조를 잡고 테스트를 진행해봤다.

 

provider.tf

terraform {
  required_version = ">= 1.6.0"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = var.aws_region
}

provider.tf에서는 테라폼 버전과 AWS Provider를 설정했다.

 

main.tf

resource "aws_s3_bucket" "terraform_test_bucket" {
  bucket = var.bucket_name

  tags = {
    Name    = "${var.project_name}-terraform-test"
    Project = var.project_name
  }
}

main.tf에서는 실제로 생성할 S3 버킷 리소스를 정의했다.

 

variables.tf

variable "aws_region" {
  description = "AWS region"
  type        = string
}

variable "project_name" {
  description = "Project name"
  type        = string
}

variable "bucket_name" {
  description = "S3 bucket name"
  type        = string
}

프로젝트명, 버킷 이름과 같은 값들은 variables.tf로 분리했다.

 

outputs.tf

output "s3_bucket_name" {
  description = "Created S3 bucket name"
  value       = aws_s3_bucket.terraform_test_bucket.bucket
}

리소스 생성 이후 바로 확인하고 싶은 값은 outputs.tf로 정의했다. 이렇게 output을 정의해두면 리소스 생성이 끝난 뒤 콘솔에 다시 들어가지 않아도 주요 정보를 빠르게 확인할 수 있다.

 

Terraform 초기화

코드 작성 후에 테라폼 작업 디렉터리에서 초기화를 진행했다.

cd infra/terraform
terraform init

terraform init을 실행하면 필요한 provider를 내려받고, 현재 디렉터리를 테라폼이 사용할 수 있는 상태로 준비한다.

 

실행 계획 확인

초기화가 끝난 뒤에는 바로 리소스를 생성하지 않고, 먼저 어떤 리소스가 생성될지 확인했다.

terraform plan

테라폼의 장점 중 하나는 실제 적용 전에 변경 사항을 미리 검토할 수 있다는 점이었다. 콘솔에서 직접 리소스를 생성할 때는 결과를 만든 뒤 확인하게 되는데, 테라폼은 적용 전에 한 번 더 점검할 수 있어서 훨씬 안정적으로 느껴졌다.

 

리소스 생성

검토가 끝난 뒤에는 실제로 리소스를 생성했다.

terraform apply

적용 전에 생성 예정인 리소스를 다시 한 번 보여주고, 마지막에 yes를 입력하면 실제 생성이 시작된다. 로컬에서 작성한 코드가 AWS 리소스로 반영되는 흐름을 직접 확인할 수 있어서 테라폼을 쓰는 이유가 조금 더 분명하게 느껴졌다.

 

생성 결과 확인

적용이 끝난 뒤에는 output 값을 통해 생성 결과를 확인했다.

 

S3 버킷 이름이 정상적으로 출력되는 것을 확인한 뒤, AWS 콘솔에서도 실제로 버킷이 생성되었는지 다시 확인했다.

 

여기까지는 S3를 기준으로 테라폼 도입 과정을 정리한 내용이다. 프로젝트에서는 EC2, RDS, Redis, ECR까지 함께 Terraform으로 관리했고, 전체 코드는 GitHub 저장소에서 확인할 수 있다.

moongchijang-BE/infra/terraform at develop · MOONGCHIJANG/moongchijang-BE

 

마무리

이번에 테라폼을 처음 도입해보면서, AWS 리소스를 직접 만드는 것과 코드로 관리하는 것은 확실히 다르다고 느꼈다. 콘솔에서는 빠르게 만들 수 있지만, 시간이 지나면 어떤 리소스를 왜 만들었는지 흐려지기 쉽고, 다시 같은 환경을 구성하는 것도 번거롭다.

 

반면 테라폼은 인프라 구성을 코드로 남길 수 있어서, 생성 과정과 설정을 함께 관리할 수 있다는 점이 좋았다. 이번 글에서는 S3를 기준으로 정리했지만, 실제 프로젝트에서는 EC2, RDS, Redis, ECR까지 함께 테라폼으로 관리했다.

 

다음에는 이 인프라를 바탕으로 CI/CD 파이프라인 구축 과정을 정리해보려고 한다.