IaC on 엔지니어 생존기록

How to Terraform(7) - 코드 중복 최소화하기

Sat, 16 Dec 2023 14:09:14 +0900

시리즈 목차

이전 글에서 우리는 모듈을 활용하여 코드를 재사용하는 방법을 알아봤습니다. 그 결과 동일한 리소스에 대해서 코드 중복을 많이 줄일 수 있었죠. 그런데 여전히 중복되는 코드가 있었습니다. 각 리소스마다 프로바이더와 백엔드는 어쩔 수 없이 매번 작성해야 했습니다. 이번 글에서는 이런 중복을 최소화하는 방법을 알아보겠습니다.

Terragrunt 설치하기

Terragrunt는 Terraform의 래퍼(wrapper)로 동작하며, Terraform 코드에서 중복되는 부분을 많이 줄일 수 있도록 도와줍니다. 래퍼로 동작하기 때문에 Terraform으로 실행가능한 init, plan, apply, destroy등의 명령은 그대로 사용할 수 있습니다. 우선 Terragrunt를 설치해볼까요?

Homebrew로 설치하기

리눅스와 맥에서는 Homebrew를 사용해서 Terragrunt를 설치할 수 있습니다.

> brew install terragrunt
> terragrunt --version
terragrunt version 0.54.5

Terraform과 Terragrunt는 다음과 같이 alias로 등록하여 각각 tf, tg로 사용할 수 있습니다.
alias tf="terraform"
alias tg="terragrunt"

Terragrunt 설정하기

먼저 이전 글에서 작업하던 폴더 구조를 다시 확인해볼까요?

terraform-live
└── dev
 └── ec2
 ├── service1
 | ├── main.tf
 | └── outputs.tf
 └── service2
 ├── main.tf
 └── outputs.tf

terraform-modules 리포지토리에 정의되어 있는 모듈을 참조하여 service1, service2를 정의했었습니다. 각 서비스의 main.tf 파일에는 다음과 같은 내용이 공통으로 존재했습니다.

// AWS 프로바이더 설정
provider "aws" {
 // 아시아 태평양(서울) 리전
 region = "ap-northeast-2"
}

...

Terragrunt로 이 중복을 제거해보겠습니다.

terraform-live/terragrunt.hcl 파일을 생성하고 다음과 같이 작성합니다.

generate "providers" {
 path = "providers.tf"
 if_exists = "overwrite_terragrunt"
 contents = <<EOF
provider "aws" {
 // 아시아 태평양(서울) 리전
 region = "ap-northeast-2"
}
EOF
}

그리고 service1의 모든 파일을 삭제하고 terragrunt.hcl 파일을 생성하고 다음과 같이 작성합니다.

terraform {
 source = "github.com/netscout/terraform-modules//modules/ec2?ref=v0.0.1"
}

include {
 path = find_in_parent_folders()
}

inputs = {
 env = "dev"
 port = 8080
}

현재까지의 내용을 정리해보자면, 폴더 구조는 다음과 같습니다.

terraform-live
├── terragrunt.hcl
└── dev
 └── ec2
 ├── service1
 | └── terragrunt.hcl
 └── service2
 ├── main.tf
 └── outputs.tf

그리고 Terragrunt의 plan 명령을 실행합니다. 참고로, Terragrunt는 plan 명령을 실행 할 때, init 명령을 자동으로 실행합니다.

> cd dev/ec2/service1
> tg plan
...
Plan: 2 to add, 0 to change, 0 to destroy.

Changes to Outputs:
 + public_ip = (known after apply)
...

provider 설정이 없는데도 정상적으로 동작합니다. 그리고 outputs.tf가 없어졌는데도 출력값을 확인할 수 있습니다. 어떻게 가능한지 확인해볼까요? service1 폴더를 다시 확인해보면, .terragrunt-cache 폴더가 생성되어 있습니다. 이 폴더에는 Terragrunt가 실행될 때 자동으로 생성된 Terraform 코드가 저장되어 있습니다. 폴더 구조를 볼까요?

service1
├── .terragrunt-cache
│ └── lIQuDV1aWBSG5nm4zKCulAdnsus
│ └── modules
│ └── ec2
│ ├── main.tf
│ ├── outputs.tf
│ ├── providers.tf
│ └── variables.tf
└── terragrunt.hcl

다른 파일들이 있긴 하지만, 핵심만 추리면 이렇습니다. 그러니까 모듈로 선언된 Terraform 코드가 그대로 다운로드 되어 있고, providers.tf 파일이 새로 생성되어 있습니다. 이 파일의 내용을 보면 다음과 같습니다.

# Generated by Terragrunt. Sig: nIlQXj57tbuaRZEa
provider "aws" {
 // 아시아 태평양(서울) 리전
 region = "ap-northeast-2"
}

provider 설정 없이도 plan 명령이 정상적으로 동작한 이유가 뭔지 이제 알 수 있죠? Terragrunt가 자동으로 생성해준 코드를 통해 provider 설정이 추가되었기 때문입니다. 다시 terraform-live/terragrunt.hcl 파일의 내용을 확인해볼까요?

generate "providers" {
 path = "providers.tf"
 if_exists = "overwrite_terragrunt"
 contents = <<EOF
provider "aws" {
 // 아시아 태평양(서울) 리전
 region = "ap-northeast-2"
}
EOF
}

providers.tf 파일을 생성하도록 설정하였고, 파일이 존재한다면 덮어쓰도록 했습니다. 그리고 파일의 내용은 provider 블록을 통해 aws 프로바이더를 정의해두었습니다. 그래서 tg plan명령이 실행 될 때 Terragrunt가 providers.tf 파일을 생성하고, 이 파일을 통해 provider 설정이 추가되었던 것입니다.

좀 더 복잡한 경우

겨우 이 몇 줄의 코드 때문에 Terragrunt를 써야 하는 거냐고 생각하실 수도 있지만 이 코드는 좀 더 길어질 수도 있습니다. 예를 들어 프로바이더 설정과 백엔드 설정을 추가한다면 어떻게 될까요?

# terragrunt가 각 모듈에 대해서 backend.tf를 생성한다.
remote_state {
 backend = "s3"

 generate = {
 path = "backend.tf"
 if_exists = "overwrite"
 }

 config = {
 bucket = "terraform-state-example-20231216"
 # 상태 파일이 저장될 경로
 key = "${path_relative_to_include()}/terraform.tfstate"
 region = "ap-northeast-2"

 # 상태 파일을 락으로 사용할 DynamoDB 테이블
 dynamodb_table = "terraform_locks"
 # 상태 파일을 암호화
 encrypt = true
 }
}

generate "providers" {
 path = "providers.tf"
 if_exists = "overwrite_terragrunt"
 contents = <<EOF
terraform {
 # 필요한 프로바이더 목록과 버전 정보
 required_providers {
 aws = {
 source = "hashicorp/aws"
 version = "~> 5.0" # 5.0 이상 버전 사용
 }
 }
}

// AWS 프로바이더 설정
provider "aws" {
 // 아시아 태평양(서울) 리전
 region = "ap-northeast-2"
}
EOF
}

remote_state 블록에는 모든 Terraform 리소스에 적용될 backend 설정을 정의했습니다. config 속성의 내용은 기존의 backend 속성의 내용을 그대로 옮긴 것이며, generate 속성에는 backend.tf 파일을 생성하고 기존에 존재하는 경우 덮어쓰도록 설정했습니다. 자세히 보시면 config.key 속성이 기존과 다릅니다.

key = "${path_relative_to_include()}/terraform.tfstate"

즉, 현재 이 파일의 위치를 기준으로 해서 Terragrunt 명령이 실행되는 폴더의 경로를 가져오도록 했습니다. 만약 dev/ec2/service1 폴더에서 tg plan 명령을 실행한다면, key 값은 dev/ec2/service1/terraform.tfstate가 됩니다. 매번 리소스를 정의할 때 마다 폴더 경로를 key 값으로 수정하지 않아도 알아서 해준다는 거죠!

그리고 generate 블록에는 프로바이더 버전 정보를 추가했습니다. 이렇게 하면 모든 리소스에 대해서 프로바이더 버전을 일괄적으로 관리할 수 있습니다.

정리

이제 Terraform을 통해 IaC를 구현하는 방법의 기초적인 내용은 모두 알아보았습니다. 익숙해지기 전에는 예전에 하던 것 처럼 수작업으로 일일이 리소스를 생성하는 게 훨씬 빠르다는 생각도 들게 됩니다. 하지만, 한 번 잘 설정해두면 속도가 빨라지는 것 뿐만 아니라 리소스의 변경을 추적할 수 있고, 리소스를 정리할 때도 커맨드 한 번으로 정리할 수 있게 됩니다. 지금까지 읽어주셔서 감사드리며, 도움이 되셨기를 바랍니다.

참고자료

License

저작자표시-비영리-변경금지 2.0 대한민국 (CC BY-NC-ND 2.0 KR)

How to Terraform(6) - 모듈 버전관리

Sat, 09 Dec 2023 14:04:13 +0900

시리즈 목차

이전 글에서는 모듈을 활용해서 반복되는 리소스를 재사용 가능한 형태로 정의하는 방법을 알아봤습니다. 그런데 모듈로 재사용성을 높이는 건 좋지만, 문제가 있긴 했습니다. 모듈을 업데이트해야 하는 경우, 이미 모듈을 사용해서 생성된 리소스 역시 업데이트되는 모듈의 영향을 받게 된다는 점입니다. 모듈을 업데이트 하되 기존 리소스는 기존 모듈을 그대로 사용할 수 있도록 하위호환성을 도입하려면 어떻게 해야 할까요?

Git 으로 모듈 버전 관리하기

여기서는 Git을 이용해서 모듈의 버전을 관리하고, 리소스도 각 모듈의 버전을 지정해서 참조하도록 해서 모듈과 리소스 간의 의존성을 관리하는 방법을 알아보겠습니다. 이렇게 하면 모듈을 업데이트할 때 기존 리소스에 영향을 주지 않으면서도 모듈을 업데이트할 수 있습니다. Git으로 모듈 버전을 관리하려면 2개의 Git 리포지토리가 필요합니다. 하나는 모듈을 관리하는 리포지토리, 또 하나는 모듈을 사용하여 리소스를 정의하는 리포지토리입니다. 우선 모듈을 관리하는 리포지토리를 만들어 보겠습니다.

모듈 리포지토리 만들기

모듈을 관리하는 리포지토리를 terraform-modules, 모듈을 사용해서 리소스를 관리하는 리포지토리를 terraform-live라고 가정하고 진행하겠습니다. 먼저 terraform-modules 리포지토리를 생성하고, 이전 글에서 작성했던 EC2 인스턴스 모듈을 이 리포지토리에 옮깁니다. 폴더 구조는 다음과 같습니다.

terraform-modules
└── modules
 └── ec2
 ├── main.tf
 ├── outputs.tf
 └── variables.tf

그리고 이 리포지토리를 GitHub에 푸시합니다. 그리고 다음 명령을 통해 모듈의 버전을 태그합니다.

> git tag -a v0.0.1 -m "EC2 모듈 추가"

~/src/terraform-modules main
> git push --follow-tags
Enumerating objects: 1, done.
Counting objects: 100% (1/1), done.
Writing objects: 100% (1/1), 185 bytes | 185.00 KiB/s, done.
Total 1 (delta 0), reused 0 (delta 0), pack-reused 0
To https://github.com/netscout/terraform-modules.git
 * [new tag] v0.0.1 -> v0.0.1

만약 이전 커밋에 지정된 태그를 삭제하고 싶다면 git tag -d v0.0.1의 형태로 명령을 사용하고 새로운 커밋에 다시 태그를 붙이면 됩니다. 이미 태그를 푸시한 상태라면 git push --delete origin v0.0.1 명령을 사용하면 됩니다.

모듈 리포지토리 참조하기

EC2 모듈의 첫 버전을 v0.0.1로 태그 했습니다. 이제 리소스 리포지토리를 만들어서 이 모듈을 참조해보겠습니다. 우선 terraform-live라는 리포지토리를 생성하고, 이전 글에서 작성했던 EC2 인스턴스 리소스를 이 리포지토리로 옮겨줍니다. 폴더 구조는 다음과 같습니다.

terraform-live 폴더 안에 dev 폴더를 만들고, 그 안에 ec2 폴더를 만들고, service1 폴더를 만들어서 EC2 인스턴스 리소스를 옮겨줍니다.

terraform-live
└── dev
 └── ec2
 └── service1
 ├── main.tf
 └── outputs.tf

이전 글에서 작성한 main.tf는 로컬에 있는 모듈을 참조하도록 설정되어 있습니다. 로컬 대신에 Git의 모듈 리포지토리를 참조하도록 변경하겠습니다.

// AWS 프로바이더 설정
provider "aws" {
 // 아시아 태평양(서울) 리전
 region = "ap-northeast-2"
}

// 모듈 사용
module "ec2" {
 //source = "../../modules/ec2"
 source = "github.com/netscout/terraform-modules//modules/ec2?ref=v0.0.1"

 // 모듈에 전달할 인자
 env = "dev"
 port = 8080
}

source 속성을 자세히 보시면 중간에 //가 들어가 있습니다. //의 앞쪽에는 모듈이 저장된 git 리포지토리의 주소를, 그리고 뒤 쪽에는 모듈의 경로와 태그로 지정된 버전을 명시합니다. 모듈을 참조하기 위한 Terraform 코드 작성은 완료됐지만 아직 한 가지 더 검토해야 할 게 남아있습니다.

Terraform 에게 Git 리포지토리 접근 허용해주기

아마도 모듈 리포지토리는 private 리포지토리로 생성되었을 겁니다. 회사에서 작업하는 모듈에 대한 정의를 public 하게 공개할 수는 없기 때문이죠. 그렇다면 Terraform이 private 리포지토리에 접근할 수 있는 방법을 알려줘야 합니다.

SSH 키 생성 및 등록하기

Terraform이 모듈 리포지토리를 참조하기 위해서 SSH 키를 생성해서 github에 등록해야 합니다. 여기서는 ed25519 알고리즘을 사용해서 키를 생성하겠습니다. ed25519는 rsa보다 보안이 더 강화된 알고리즘으로, 최근에는 ed25519를 사용하는 것을 권장하고 있습니다. 다음 명령을 실행하여 키를 생성합니다.

# "your_email@example.com" 대신에 github 이메일 주소를 입력하세요.
> ssh-keygen -t ed25519 -C "your_email@example.com"
# ssh-agent를 실행하여, 키를 등록한다.
> eval "$(ssh-agent -s)"
> ssh-add ~/.ssh/id_ed25519

그리고 생성된 키의 내용을 클립보드에 복사한 후, 그 내용을 github에 등록합니다. 키의 내용을 클립보드에 복사하려면 ubuntu에서는 xclip을 사용하고,

> cat ~/.ssh/id_ed25519.pub | xclip -selection clipboard

mac에서는 pbcopy를 사용하면 됩니다.

> cat ~/.ssh/id_ed25519.pub | pbcopy

이제 클립보드에 복사된 키를 github에 등록할 차례입니다. github에 접속하고 우측 상단의 아바타 버튼을 누르고 Settings > SSH and GPG keys > New SSH key를 클릭합니다.

Title에는 키를 등록하는 컴퓨터의 이름을 적고, Key에는 위에서 복사한 키를 붙여넣으면 완료입니다. 그러면 모듈을 잘 참조하는지 확인해볼까요?

> cd dev/ec2/service1
> tf init
Initializing the backend...
Initializing modules...
Downloading git::https://github.com/netscout/terraform-modules.git?ref=v0.0.1 for ec2...
- ec2 in .terraform/modules/ec2/modules/ec2

...
Terraform has been successfully initialized!
...

정상적으로 잘 참조하고 있습니다! 이제 모듈을 업데이트 해볼까요?

모듈 업데이트하기

모듈 리포지토리의 EC2 모듈을 업데이트 해보겠습니다. modules/ec2/main.tf 파일을 열고, locals의 변수 정의를 수정하고 aws_security_group.sg 리소스에 ssh 접속을 위한 인바운트 규칙을 추가합니다.

// 로컬 변수 정의
locals {
 // EC2 인스턴스에 할당할 태그
 security_group_name = "${var.name}-${var.env}"
}

resource "aws_instance" "ec2" {
 // ap-northeast-2 리전의 Ubuntu 20.04 AMI
 ami = var.ami_id # 변수 ami_id 참조
 instance_type = var.instance_type

 vpc_security_group_ids = [aws_security_group.sg.id]

 // 최초 인스턴스 생성 시에만 실행
 user_data = <<-EOF
 #!/bin/bash
 echo "Hello, World" > index.html
 nohup busybox httpd -f -p ${var.port} &
 EOF

 tags = {
 Name = "terraform-example"
 }
}

resource "aws_security_group" "sg" {
 name = local.security_group_name

 // 인바운드 규칙
 ingress {
 from_port = var.port
 to_port = var.port
 protocol = "tcp"
 cidr_blocks = var.cidr_blocks
 }

 // ssh 접속을 위한 인바운드 규칙(새로 추가)
 ingress {
 from_port = 22
 to_port = 22
 protocol = "tcp"
 cidr_blocks = var.cidr_blocks
 }
}

다음으로 variables.tf 파일을 열고, name 변수를 추가합니다.

// name 변수 추가
variable "name" {
 type = string
}

variable "env" {
 type = string
 // 변수 값이 "dev", "stg", "prod" 중에 하나로 설정되야함
 validation {
 condition = contains(["dev", "stg", "prod"], var.env)
 error_message = "env must be one of dev, stg, prod"
 }
}

variable "ami_id" {
 type = string
 default = "ami-0c6e5afdd23291f73"
}

variable "instance_type" {
 type = string
 default = "t2.micro"
}

variable "port" {
 type = number
}

variable "cidr_blocks" {
 type = list(string)
 default = ["0.0.0.0/0"]
}

그리고 변경 내용을 커밋하고, 모듈 리포지토리를 푸시, 그리고 태그를 추가합니다.

> git tag -a v0.0.2 -m "EC2에 SSH 인바운드 규칙 추가"
> git push --follow-tags
Enumerating objects: 1, done.
Counting objects: 100% (1/1), done.
Writing objects: 100% (1/1), 207 bytes | 207.00 KiB/s, done.
Total 1 (delta 0), reused 0 (delta 0), pack-reused 0
To https://github.com/netscout/terraform-modules.git
 * [new tag] v0.0.2 -> v0.0.2

업데이트된 모듈 참조하기

이제 업데이트된 모듈을 참조해보겠습니다. terraform-live/dev/ec2/service2 폴더를 추가하고, terraform-live/dev/ec2/service1 폴더에 작성된 main.tf, outputs.tf 파일을 복사해서 붙여넣습니다. 그리고 service2 폴더에 있는 main.tf 파일을 열고, 다음과 같이 모듈의 버전을 v0.0.2로 변경하고 name 변수에 인자를 할당합니다.

// AWS 프로바이더 설정
provider "aws" {
 // 아시아 태평양(서울) 리전
 region = "ap-northeast-2"
}

// 모듈 사용
module "ec2" {
 //source = "../../modules/ec2"
 source = "github.com/netscout/terraform-modules//modules/ec2?ref=v0.0.2"

 // 모듈에 전달할 인자
 name="service2"
 env = "dev"
 port = 8080
}

init 명령을 실행해서 모듈 참조를 확인합니다.

> cd dev/ec2/service2
> tf init
Initializing the backend...
Initializing modules...
Downloading git::https://github.com/netscout/terraform-modules.git?ref=v0.0.2 for ec2...
- ec2 in .terraform/modules/ec2/modules/ec2
...

v0.0.2 버전의 모듈의 정상적으로 참조하고 있죠? v0.0.1을 참조하는 service1을 다시 확인해볼까요?

# 모듈 다시 업데이트 하기
> tf get -update
> tf plan
...

service1의 리소스 정의에는 모듈 v0.0.2에서 새로 추가된 name 변수가 지정되어 있지 않지만, name 변수가 아직 추가되지 않는 v0.0.1을 참조하고 있기 때문에 모듈의 버전 변경과 관계없이 잘 동작하는 걸 확인할 수 있습니다.

정리

Git으로 모듈의 버전을 관리하면 모듈이 변경되더라도 이전에 생성된 리소스에는 영향을 주지 않고 안전하게 모듈을 업데이트할 수 있습니다. 점점 좋아지고 있죠? 그런데 여전히 중복은 남아있습니다. service1과 service2 에는 각각 provider에 대한 정의가 있습니다. 그리고 여기서는 backend를 사용하지 않았지만, S3같은 backend를 사용하면 그 설정 역시 각 리소스에 중복해서 들어가게 될 겁니다. 다음에는 이런 중복을 제거할 수 있는 방법을 알아보겠습니다.

참고자료

Terraform Up and Running, 3rd Edition

License

저작자표시-비영리-변경금지 2.0 대한민국 (CC BY-NC-ND 2.0 KR)

How to Terraform(5) - 모듈

Sat, 02 Dec 2023 13:47:25 +0900

시리즈 목차

Terraform을 사용하다보면 동일한 유형의 리소스를 여러번 생성해야 할 때가 있습니다. 예를 들면 개발, 스테이징, 운영 환경을 각각 분리된 EC2 인스턴스로 생성한다고 했을 때, 거의 동일한 EC2 인스턴스를 리소스로 정의하게 되겠죠. 지금까지는 동일한 코드를 복사해서 붙여넣는 방식으로 각 리소스를 정의했습니다. 그런데 이렇게 하면 EC2 인스턴스의 설정이 복잡해지고, 개수가 많아질 수록 중복되는 코드의 양이 늘어나겠죠? 만약 기존에 정의된 EC2 인스턴스의 AMI를 변경해야 한다면, 모든 코드를 찾아서 일일이 변경해야만 할 겁니다. 그리고 이렇게 하다 보면 실수할 확률이 높아지겠죠?

이렇게 동일한 리소스를 반복해서 사용해야 하는 경우, 리소스의 공통적인 내용을 재사용 가능한 형태로 정의해놓고 필요할 때마다 참조해서 사용하되, 바뀌는 부분만 따로 명시해줄 수 있으면 좋을 겁니다. 이런 재사용 가능한 형태로 정의된 리소스를 모듈이라고 합니다.

모듈이란?

Terraform 모듈은 동일한 유형의 리소스를 여러 번 생성할 때, 코드를 중복해서 작성하지 않도록 재사용 가능한 형태로 정의할 수 있습니다. 프로그래밍 언어에서는 함수나 클래스를 떠올려보시면 비슷합니다. 자 그럼 우선 모듈을 사용하기 전에 중복해서 리소스를 정의하는 코드를 먼저 확인해볼까요?

// AWS 프로바이더 설정
provider "aws" {
 // 아시아 태평양(서울) 리전
 region = "ap-northeast-2"
}

// 개발 환경 EC2 인스턴스
resource "aws_instance" "example_dev" {
 // ap-northeast-2 리전의 Ubuntu 20.04 AMI
 ami = "ami-0c6e5afdd23291f73"
 instance_type = "t2.micro"

 vpc_security_group_ids = [aws_security_group.example_dev.id]

 // 최초 인스턴스 생성 시에만 실행
 user_data = <<-EOF
 #!/bin/bash
 echo "Hello, World" > index.html
 nohup busybox httpd -f -p 8080 &
 EOF

 tags = {
 Name = "terraform-example"
 }
}

resource "aws_security_group" "example_dev" {
 name = "terraform-example"

 // 인바운드 규칙
 ingress {
 from_port = 8080
 to_port = 8080
 protocol = "tcp"
 cidr_blocks = ["0.0.0.0/0"]
 }
}

// 스테이징 환경 EC2 인스턴스
resource "aws_instance" "example2_stg" {
 // ap-northeast-2 리전의 Ubuntu 20.04 AMI
 ami = "ami-0c6e5afdd23291f73"
 instance_type = "t2.micro"

 vpc_security_group_ids = [aws_security_group.example_stg.id]

 // 최초 인스턴스 생성 시에만 실행
 user_data = <<-EOF
 #!/bin/bash
 echo "Hello, World" > index.html
 nohup busybox httpd -f -p 8080 &
 EOF

 tags = {
 Name = "terraform-example"
 }
}

resource "aws_security_group" "example_stg" {
 name = "terraform-example-stg"

 // 인바운드 규칙
 ingress {
 from_port = 8080
 to_port = 8080
 protocol = "tcp"
 cidr_blocks = ["0.0.0.0/0"]
 }
}

개발 환경과 스테이징 환경에서 동작할 EC2 인스턴스를 2개 정의해놓았습니다. 대부분의 코드가 중복되어 있죠? 간단한 코드지만 계속해서 늘어난다고 생각하면 좀 별로이긴합니다. 그러면 일단 중복을 제거할 수 있도록 모듈을 작성해보겠습니다. modules/ec2 폴더를 만들고, 그 안에 ec2 폴더를 만들어서 main.tf 파일을 생성합니다.

// 로컬 변수 정의
locals {
 // EC2 인스턴스에 할당할 태그
 security_group_name = "terraform-example-${var.env}"
}

resource "aws_instance" "ec2" {
 // ap-northeast-2 리전의 Ubuntu 20.04 AMI
 ami = var.ami_id # 변수 ami_id 참조
 instance_type = var.instance_type

 vpc_security_group_ids = [aws_security_group.sg.id]

 // 최초 인스턴스 생성 시에만 실행
 user_data = <<-EOF
 #!/bin/bash
 echo "Hello, World" > index.html
 nohup busybox httpd -f -p ${var.port} &
 EOF

 tags = {
 Name = "terraform-example"
 }
}

resource "aws_security_group" "sg" {
 name = local.security_group_name

 // 인바운드 규칙
 ingress {
 from_port = var.port
 to_port = var.port
 protocol = "tcp"
 cidr_blocks = var.cidr_blocks
 }
}

그리고 variables.tf 파일을 생성해서 변수를 정의합니다.

variable "env" {
 type = string
 // 변수 값이 "dev", "stg", "prod" 중에 하나로 설정되야함
 validation {
 condition = contains(["dev", "stg", "prod"], var.env)
 error_message = "env must be one of dev, stg, prod"
 }
}

variable "ami_id" {
 type = string
 default = "ami-0c6e5afdd23291f73"
}

variable "instance_type" {
 type = string
 default = "t2.micro"
}

variable "port" {
 type = number
}

variable "cidr_blocks" {
 type = list(string)
 default = ["0.0.0.0/0"]
}

마지막으로 outputs.tf 파일을 생성해서 EC2 인스턴스의 public IP 주소를 출력하도록 설정합니다.

output "public_ip" {
 value = aws_instance.ec2.public_ip
}

이제 모듈을 사용하는 코드를 작성해보겠습니다. dev/ec2 폴더에 main.tf 파일을 생성하고, 다음과 같이 작성합니다.

// AWS 프로바이더 설정
provider "aws" {
 // 아시아 태평양(서울) 리전
 region = "ap-northeast-2"
}

// 모듈 사용
module "ec2" {
 // 모듈의 소스 경로 지정
 source = "../../modules/ec2"

 // 모듈에 전달할 인자
 env = "dev"
 port = 8080
}

모듈의 소스 경로를 상대 경로로 지정해주고, 모듈에 전달하고 싶은 변수를 지정해줍니다. 그리고 stg/ec2 폴더에도 main.tf 파일을 생성하고, 다음과 같이 작성합니다.

// AWS 프로바이더 설정
provider "aws" {
 // 아시아 태평양(서울) 리전
 region = "ap-northeast-2"
}

// 모듈 사용
module "ec2" {
 source = "../../modules/ec2"

 // 모듈에 전달할 인자
 env = "stg"
 port = 8080
}

그리고 모듈의 output을 이용해서 EC2 인스턴스의 public IP 주소를 출력하도록 outputs.tf 파일을 생성합니다.

output "public_ip" {
 value = module.ec2.public_ip
}

참고로 폴더 구조는 다음과 같습니다.

.
├── modules
│ └── ec2
│ ├── main.tf
│ └── variables.tf
| └── outputs.tf
├── dev
│ └── ec2
│ └── main.tf
│ └── outputs.tf
└── stg
 └── ec2
 └── main.tf
 └── outputs.tf

우선 dev/ec2 폴더에서 tf init 명령을 실행합니다.

terraform이라고 매번 입력하는게 어려우니 .zshrc나 .bashrc에 다음과 같이 alias 설정을 해서 tf로 사용하는 것도 방법입니다.
alias tf=terraform

> cd dev/ec2
> tf init

Initializing the backend...
Initializing modules...
- ec2 in ../../modules/ec2

Initializing provider plugins...
...

가장 먼저 지정된 모듈의 소스 경로에서 모듈을 가져와서 초기화 하는 걸 확인할 수 있죠? 그리고 tf plan 명령을 실행해볼까요?

참고로 모듈을 수정한 다음에 수정된 모듈을 반영하려면 tf get -update명령을 실행해야 합니다.

> tf plan
...
Plan: 2 to add, 0 to change, 0 to destroy.

Changes to Outputs:
 + public_ip = (known after apply)
...

> tf apply
...
Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

Outputs:

public_ip = "..."

모듈에 설정된 내용대로 인스턴스가 생성되었고, 모듈의 출력으로 설정된 public_ip도 출력을 확인할 수 있습니다. 이제 stg/ec2 폴더에서도 동일한 명령을 실행해서 인스턴스를 추가로 생성할 수 있습니다.

정리

모듈을 활용하면 코드의 중복을 줄일 수 있으며, 수작업으로 인해 실수를 방지할 수 있습니다. 하지만 모듈은 또 다른 단점을 가지고 있습니다. 모듈을 수정하게 되면 모듈을 참조하는 모든 리소스의 상태 관리에 영향을 미친다는 점입니다. 어떻게 하면 모듈을 업데이트하면서도 특정 리소스는 이전 모듈을 참조하고, 특정 리로스는 새로 업데이트된 모듈을 참조하도록 할 수 있을까요? 다음 시간에는 그 방법을 알아보겠습니다!

참고자료

Terraform Up and Running, 3rd Edition

License

저작자표시-비영리-변경금지 2.0 대한민국 (CC BY-NC-ND 2.0 KR)

How to Terraform(4) - 상태관리 개선하기

Sat, 25 Nov 2023 14:14:54 +0900

시리즈 목차

이전 글에서는 Terraform의 상태에 대해 알아보았고, 로컬 파일로 관리할 때의 단점을 해결하기 위해서 상태를 S3에 저장하는 방법을 알아보았습니다. 하지만 여전히 문제가 남아있었습니다. 그 문제가 뭐였는지 알아볼까요?

현재 상태관리의 문제점

이전 글에서는 모든 테라폼 리소스가 한 개의 상태 파일로 관리되고 있었습니다. 예시를 위해서 새로 폴더를 만들고 다음 코드를 main.tf에 작성합니다.

일단 예시를 위해서 S3를 사용하지 않고 로컬 파일을 사용합니다.

// AWS 프로바이더 설정
provider "aws" {
 // 아시아 태평양(서울) 리전
 region = "ap-northeast-2"
}

resource "aws_instance" "example" {
 // ap-northeast-2 리전의 Ubuntu 20.04 AMI
 ami = "ami-0c6e5afdd23291f73"
 instance_type = "t2.micro"
}

그리고 init, plan, apply 명령을 실행합니다.

terraform이라고 매번 입력하는게 어려우니 .zshrc나 .bashrc에 다음과 같이 alias 설정을 해서 tf로 사용하는 것도 방법입니다.
alias tf=terraform

> tf init
...
Terraform has been successfully initialized!
...

> tf plan
...
Plan: 1 to add, 0 to change, 0 to destroy.
...

> tf apply
...
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

자 여기까지는 뭐 기존과 다를 게 하나도 없습니다. 여기에 두번째 EC2 인스턴스를 추가해볼까요?

//main.tf 기존 코드...

resource "aws_instance" "example2" {
 // ap-northeast-2 리전의 Ubuntu 20.04 AMI
 ami = "ami-0c6e5afdd23291f73"
 instance_type = "t2.micro"
}

그리고 다시 plan을 실행해봅니다.

> tf plan
aws_instance.example: Refreshing state... [id=i-00c12ab694ff80dfa]

...
Plan: 1 to add, 0 to change, 0 to destroy.
...

두번째 EC2 인스턴스를 추가할 때 우리의 관심사는 aws_instance.example2 리소스 입니다. 하지만 plan 명령을 실행하자 이미 추가된 리소스인 aws_instance.example에 대한 검사가 먼저 진행되었죠? aws_instance.example 리소스가 aws_instance.example2 리소스와 하나의 상태 파일로 관리되고 있기 때문에 Terraform으로서는 어쩔 수 없이 상태 파일의 내용과 테라폼 코드의 리소스를 모두 비교할 수 밖에 없는 거죠. EC2 인스턴스 몇 개는 금방 끝나니까 별 문제가 아닐 수 있지만, 이런 식으로 리소스가 계속 늘어나다 보면 어느새 plan 한번 실행하는데 몇 분이 걸리는 일도 발생할 수 있습니다.

그리고 좀 더 복잡한 문제가 생기는 경우도 있습니다. 만약 반드시 변수로 입력받아야 하는 값이 있다고 생각해볼까요? 테라폼 코드에 작성된 상당수의 리소스가 환경변수 등을 통해서 변수를 입력받아야 한다면 어떨까요? 내가 관심 있는 리소스 하나 작업하기 위해서 모든 변수 값을 제대로 설정해야만 하는 문제가 발생합니다. 정리해보자면,

여러 리소스가 하나의 상태 파일로 관리되기 때문에, 리소스가 추가됨에 따라 상태 파일이 점점 거대해진다.
따라서 새로 추가하는 리소스에 대한 plan, apply 명령에도 기존에 관리되고 있는 모든 리소스에 대한 검사가 진행되므로 시간이 점점 더 오래걸린다.
모든 리소스가 하나의 상태 파일로 관리되면 다른 사람이 일부 리소스를 변경했을 때 변경된 상태 값 역시 공유된다. 만약 다른 사람이 변경한 테라폼 코드를 업데이트 받지 않은 상태에서 내 작업을 진행하면 리소스의 상태를 다시 변경 이전 상태로 되돌리는 등의 예상치 못한 오류가 발생할 수 있다.

이러한 문제를 해결하기 위해서는 각 리소스에 대한 상태를 최대한 작게 나눠서 관리하는 게 좋을 것 같습니다. 나눠서 관리한다는 게 생각보다 별 거 없습니다. 그냥 폴더를 쪼개면 됩니다.

폴더로 나눠서 관리하기

S3 백엔드와 EC2 인스턴스 2개를 만드는 상황을 가정하면 폴더는 대강 이렇게 나눌 수 있습니다.

.
├── global
│ └── s3
│ └── main.tf
├── dev
│ └── ec2
│ └── example
│ └── main.tf
│ └── example2
│ └── main.tf

우선 global 폴더에는 S3 백엔드를 생성하는 코드를 작성합니다.

// AWS 프로바이더 설정
provider "aws" {
 // 아시아 태평양(서울) 리전
 region = "ap-northeast-2"
}

# S3 버킷 생성
resource "aws_s3_bucket" "terraform_state" {
 bucket = "terraform-state-example-20231125"

 # 실수로 버킷이 삭제되지 않도록 하려면 아래 주석을 해제하세요.
 # lifecycle {
 # prevent_destroy = true
 # }
}

# 버킷 버전 관리 활성화(상태 파일의 히스토리를 관리하기 위함)
resource "aws_s3_bucket_versioning" "enabled" {
 bucket = aws_s3_bucket.terraform_state.id

 versioning_configuration {
 status = "Enabled"
 }
}

# S3에 저장될 때 암호화 하도록 설정
resource "aws_s3_bucket_server_side_encryption_configuration" "default" {
 bucket = aws_s3_bucket.terraform_state.id

 rule {
 apply_server_side_encryption_by_default {
 sse_algorithm = "AES256"
 }
 }
}

# 모든 public access를 차단(실수로 버킷이 공개되지 않도록 하기 위함)
resource "aws_s3_bucket_public_access_block" "public_access" {
 bucket = aws_s3_bucket.terraform_state.id

 block_public_acls = true
 block_public_policy = true
 ignore_public_acls = true
 restrict_public_buckets = true
}

# 여러 사람이 동시에 상태 파일을 수정하지 못하도록 DynamoDB를 사용한 락 설정
resource "aws_dynamodb_table" "terraform_locks" {
 name = "terraform_locks"
 billing_mode = "PAY_PER_REQUEST"
 hash_key = "LockID"

 attribute {
 name = "LockID"
 type = "S"
 }
}

그리고 우선 init, plan, apply 를 실행해서 백엔드 설정을 위한 S3 버킷을 생성합니다.

참고로, VS Code에서는 cd 명령 대신에 폴더에 우클릭하고 통합 터미널에서 열기를 선택하면 해당 폴더로 터미널이 이동합니다.

> cd global/s3
> tf init
...
Terraform has been successfully initialized!
...

> tf plan
...
Plan: 5 to add, 0 to change, 0 to destroy.
...

> tf apply
...
Apply complete! Resources: 5 added, 0 changed, 0 destroyed.

그리고 생성된 S3에 현재 생성된 리소스의 상태를 저장하기 위해서 main.tf상단에 다음 코드를 추가합니다.

terraform {
 # 필요한 프로바이더 목록과 버전 정보
 required_providers {
 aws = {
 source = "hashicorp/aws"
 version = "~> 5.0" # 5.0 이상 버전 사용
 }
 }

 # 상태 파일을 S3에 저장하도록 설정
 backend "s3" {
 bucket = "terraform-state-example-20231125"
 # 상태 파일이 저장될 경로
 key = "global/s3/terraform.tfstate"
 region = "ap-northeast-2"

 # 상태 파일을 락으로 사용할 DynamoDB 테이블
 dynamodb_table = "terraform_locks"
 # 상태 파일을 암호화
 encrypt = true
 }
}

// main.tf 기존 코드...

여기서 주목해야 할 점은 상태 파일이 저장될 경로를 리소스 파일이 정의된 폴더 경로와 일치하도록 설정했다는 점입니다. 이렇게 하면 리로스와 상태 파일의 경로가 일치하므로 상태 파일을 덮어쓴다던지 하는 오류를 피할 수 있습니다. 이제 init 명령을 통해 벡엔드를 설정하겠습니다.

> tf init
Initializing the backend...
Do you want to copy existing state to the new backend?
 Pre-existing state was found while migrating the previous "local" backend to the
 newly configured "s3" backend. No existing state was found in the newly
 configured "s3" backend. Do you want to copy this state to the new "s3"
 backend? Enter "yes" to copy and "no" to start with an empty state.

 Enter a value: yes


Successfully configured the backend "s3"! Terraform will automatically
use this backend unless the backend configuration changes.
...

콘솔에서 S3를 확인해보면,

지정된 경로에 상태 파일이 생성된 것을 확인할 수 있습니다.

이렇게 리소스 별로 상태를 관리할 때 아무래도 자주 관리하지 않는 리소스가 생기기 마련입니다. 시간이 한참 지나서 다시 관리를 해야 할 때, 이전에 사용하던 프로바이더의 버전과 현재 버전이 차이가 많이 날 수도 있겠죠. 그럴 때 기존에 작성한 코드가 제대로 동작하지 않는 문제가 생길 수도 있으므로 프로바이더의 버전을 명시하는 것도 좋은 방법입니다!

이제 dev/ec2/example/main.tf 파일을 생성하고 다음 코드를 작성합니다.

terraform {
 # 필요한 프로바이더 목록과 버전 정보
 required_providers {
 aws = {
 source = "hashicorp/aws"
 version = "~> 5.0" # 5.0 이상 버전 사용
 }
 }

 # 상태 파일을 S3에 저장하도록 설정
 backend "s3" {
 bucket = "terraform-state-example-20231125"
 # 상태 파일이 저장될 경로
 key = "dev/ec2/example/terraform.tfstate"
 region = "ap-northeast-2"

 # 상태 파일을 락으로 사용할 DynamoDB 테이블
 dynamodb_table = "terraform_locks"
 # 상태 파일을 암호화
 encrypt = true
 }
}

// AWS 프로바이더 설정
provider "aws" {
 // 아시아 태평양(서울) 리전
 region = "ap-northeast-2"
}

resource "aws_instance" "example" {
 // ap-northeast-2 리전의 Ubuntu 20.04 AMI
 ami = "ami-0c6e5afdd23291f73"
 instance_type = "t2.micro"
}

그리고 역시 dev/ec2/example 폴더에서 init, plan, apply 명령을 실행합니다.

> cd dev/ec2/example
> tf init
...
Terraform has been successfully initialized!
...

> tf plan
...
Plan: 1 to add, 0 to change, 0 to destroy.
...

> tf apply
...
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

그리고 dev/ec2/example2/main.tf 파일을 생성하고 동일한 과정으로 EC2 인스턴스를 추가할 수 있습니다.

정리

이제 우리는 각 리소스에 대해 개별적으로 상태 관리를 진행할 수 있습니다. 리소스는 각각의 상태를 가지므로 다른 리소스에 대해 신경쓰지 않고 관리할 수 있고, 특히 새로운 리소스를 추가할 때 역시 기존 리소스의 상태에 대해서 전혀 신경쓰지 않아도 됩니다. 다만 역시나 한 가지 마음에 걸리는 게 있습니다. EC2 인스턴스를 작성 할 때 저희는 동일한 코드를 복붙해서 새로운 인스턴스를 생성했었죠. 사실 지금은 EC2에 별다른 설정을 하지 않아서 뭐 복잡할 건 없습니다만, VPC등의 설정에 따라서는 EC2도 매우 복잡해질 수 있고 저희가 Terraform으로 EC2만 관리할 것도 아니기 때문에 이 부분은 더 나은 방법이 필요해보입니다. 다음 글에서는 모듈을 통해 중복을 줄이는 방법을 알아보겠습니다.

참고자료

Terraform Up and Running, 3rd Edition

License

저작자표시-비영리-변경금지 2.0 대한민국 (CC BY-NC-ND 2.0 KR)

How to Terraform(3) - 상태 관리

Sat, 18 Nov 2023 15:28:03 +0900

시리즈 목차

상태라니 무슨 상태?

상태가 뭔지 설명하기 전에 간단한 실험을 해보죠! 새로운 폴더를 생성하고 아래 코드를 main.tf에 추가하겠습니다.

// AWS 프로바이더 설정
provider "aws" {
 // 아시아 태평양(서울) 리전
 region = "ap-northeast-2"
}

그리고 tf init을 실행해봅시다.

terraform이라고 매번 입력하는게 어려우니 .zshrc나 .bashrc에 다음과 같이 alias 설정을 해서 tf로 사용하는 것도 방법입니다.
alias tf=terraform

> tf init

Initializing the backend...

Initializing provider plugins...
...

Terraform has been successfully initialized!
...

맨 처음에 backend라는 표현이 등장합니다. 이게 웹 어플리케이션도 아닌데 backend는 뭘 말하는 걸까요~? 일단은 궁금증을 뒤로 하고 tf plan을 실행해봅시다.

> tf plan
No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration and found no differences, so no changes
are needed.

아무 것도 바꿀 게 없다고 합니다. 리소스를 하나도 선언하지 않았으니 당연하겠죠. 그런데 여기서 tf apply를 실행해볼까요?

> tf apply
No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration and found no differences, so no changes
are needed.

Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

바꿀건 하나도 없지만 apply 명령이 완료되었습니다. 그런데 apply 명령을 실행한 폴더를 확인해보시면, terraform.tfstate라는 파일이 생겼습니다! 파일을 확인 해보면 이런 내용이 있습니다.

{
 "version": 4,
 "terraform_version": "1.6.2",
 "serial": 1,
 "lineage": "2e6b0c74-0e92-bfe8-1197-36e5547d9375",
 "outputs": {},
 "resources": [],
 "check_results": null
}

이 파일에는 현재 Terraform 코드를 apply해서 구성된 리소스의 상태가 기록되고 있습니다. 즉, 가장 최근에 실행한 apply 명령을 통해 구성된 리소스의 상태(여기서는 aws 클라우드에 생성된 리소스의 상태)가 기록됩니다. 여러분이 plan 명령을 실행 할 때 뭐가 추가되고, 뭐가 수정되며 뭐가 삭제되는지를 이 파일에 기록된 현재 상태를 기준으로 판단하는 거죠. 이 파일에 포함된 속성은 다음과 같습니다.

version: Terraform의 상태 파일 형식 버전입니다. 현재는 4입니다.
terraform_version: Terraform의 버전입니다.
serial: 상태 파일이 변경될 때마다 증가하는 숫자입니다. 이 숫자는 상태 파일이 변경될 때마다 증가하며, 이 숫자를 통해 상태 파일이 변경되었는지를 판단합니다.
lineage: 상태 파일의 고유 식별자입니다. 처음 생성될 때 부여되고, 그 이후로는 변경되지 않습니다.
outputs: Terraform 코드에서 output으로 정의한 출력 값들이 기록됩니다.
resources: Terraform 코드에서 resource로 정의한 리소스들의 상태가 기록됩니다.
check_results: Terraform 코드에서 data로 정의한 데이터 소스들의 상태가 기록됩니다.

그렇다면 EC2 인스턴스를 하나 추가해서 상태 파일이 어떻게 바뀌는지 확인해봅시다! main.tf에 아래 코드를 추가합니다.

resource "aws_instance" "example" {
 // ap-northeast-2 리전의 Ubuntu 20.04 AMI
 ami = "ami-0c6e5afdd23291f73"
 instance_type = "t2.micro"
}

그리고 tf plan을 실행합니다.

> tf plan
Terraform used the selected providers to generate the following execution plan. Resource actions are indicated
with the following symbols:
 + create

Terraform will perform the following actions:

 # aws_instance.example will be created
 + resource "aws_instance" "example" {
 + ami = "ami-0c6e5afdd23291f73"
 + arn = (known after apply)
 + associate_public_ip_address = (known after apply)
 + availability_zone = (known after apply)
 + cpu_core_count = (known after apply)
 + cpu_threads_per_core = (known after apply)
 + disable_api_stop = (known after apply)
 + disable_api_termination = (known after apply)
 + ebs_optimized = (known after apply)
 + get_password_data = false
 + host_id = (known after apply)
 + host_resource_group_arn = (known after apply)
 + iam_instance_profile = (known after apply)
 + id = (known after apply)
 + instance_initiated_shutdown_behavior = (known after apply)
 + instance_lifecycle = (known after apply)
 + instance_state = (known after apply)
 + instance_type = "t2.micro"
 + ipv6_address_count = (known after apply)
 + ipv6_addresses = (known after apply)
 + key_name = (known after apply)
 + monitoring = (known after apply)
 + outpost_arn = (known after apply)
 + password_data = (known after apply)
 + placement_group = (known after apply)
 + placement_partition_number = (known after apply)
 + primary_network_interface_id = (known after apply)
 + private_dns = (known after apply)
 + private_ip = (known after apply)
 + public_dns = (known after apply)
 + public_ip = (known after apply)
 + secondary_private_ips = (known after apply)
 + security_groups = (known after apply)
 + source_dest_check = true
 + spot_instance_request_id = (known after apply)
 + subnet_id = (known after apply)
 + tags_all = (known after apply)
 + tenancy = (known after apply)
 + user_data = (known after apply)
 + user_data_base64 = (known after apply)
 + user_data_replace_on_change = false
 + vpc_security_group_ids = (known after apply)
 }

Plan: 1 to add, 0 to change, 0 to destroy.

──────────────────────────────────────────────────────────────────────────────────────────────────────────────────

Note: You didn't use the -out option to save this plan, so Terraform can't guarantee to take exactly these actions
if you run "terraform apply" now.

현재는 생성된 리소스가 하나도 없기 때문에, 상태 값은 비어있는 상태죠. 그래서 Terraform 코드에 정의된 리소스는 모두 새로 추가됩니다. 이제 tf apply를 실행합니다.

> tf apply
...
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

이제 다시 terraform.tfstate 파일의 내용을 확인합니다.

{
 "version": 4,
 "terraform_version": "1.6.2",
 "serial": 3,
 "lineage": "2e6b0c74-0e92-bfe8-1197-36e5547d9375",
 "outputs": {},
 "resources": [
 {
 "mode": "managed",
 "type": "aws_instance",
 "name": "example",
 "provider": "provider[\"registry.terraform.io/hashicorp/aws\"]",
 "instances": [
 {
 "schema_version": 1,
 "attributes": {
 "ami": "ami-0c6e5afdd23291f73",
 ...
 },
 "sensitive_attributes": [],
 "private": "..."
 }
 ]
 }
 ],
 "check_results": null
}

방금 전 apply 명령으로 추가된 리소스를 확인할 수 있습니다.

상태는 Terraform이 리소스를 관리할 때 어떻게 변경해야 할지 판단하는 기준이 됩니다. 그렇기 때문에 상태는 Terraform에서 가장 중요합니다. 상태가 제대로 관리되지 않으면 어떤 리소스를 어떻게 변경해야 할지 Terraform이 제대로 판단할 수 없겠죠.

그렇기 때문에 Terraform으로 생성된 리소스를 관리 콘솔에서 직접 변경하면 안됩니다! 상태 파일에 기록된 내용과 실제 리소스의 상태가 달라지기 때문에 Terraform이 제대로 동작하지 않을 수 있습니다.

확인이 끝났으므로 destroy 명령으로 생성된 리소스를 모두 제거합니다. 참고로 제거 작업이 끝난 후 상태 파일은 이렇습니다.

{
 "version": 4,
 "terraform_version": "1.6.2",
 "serial": 5,
 "lineage": "2e6b0c74-0e92-bfe8-1197-36e5547d9375",
 "outputs": {},
 "resources": [],
 "check_results": null
}

serial을 제외하고는 모두 원래대로 돌아왔죠?

상태 파일 관리

보시다시피 별다른 설정이 없다면, 상태 파일은 현재 Terraform 명령을 실행하는 폴더에 생성됩니다. 실습을 위해 간단하게 테스트를 하는 경우라면 문제가 없겠지만, 계속 상태 파일을 이렇게 사용하는 건 매우 위험합니다. 그 이유는!

output등의 민감한 정보가 상태 파일에 기록되기 때문에 파일에 접근할 수 있다면, 민감한 정보를 보호할 수 없습니다.
동일한 리소스에 대해, 여러 장소(컴퓨터)에서 Terraform을 실행해야 하는 경우 각 장소마다 동일한 상태 파일을 가지고 있어야 합니다. 그래서 git등의 버전 관리 시스템으로 상태 파일을 관리할 수도 있지만, commit이나 pull을 까먹는다면 무슨 일이 벌어질까요?

그래서 실제 Terraform을 사용하려면 상태 파일은 로컬 컴퓨터가 아닌, git같은 버전 관리 시스템도 아닌 어딘가 안전하고 항상 접근 가능한 곳에 저장되어야 합니다. 그리고 가능하면 암호화되어야 겠죠! 이 글 서두에 보셨던 backend가 바로 이런 상태 파일을 어딘가에서 안전하게 잘 관리해주는 역할을 합니다. 우리는 지금 AWS를 사용하고 있죠? 그렇다면 이제 S3를 통해 backend를 구성해보겠습니다.

S3 backend 구성

S3로 backend를 구성하려면 우선 S3를 생성해야겠죠? 일단 Terraform으로 S3를 생성하고 그 이후에 backend를 구성해서 상태를 backend로 옮기겠습니다. 새로 폴더를 만들고 main.tf를 다음과 같이 작성합니다.

// AWS 프로바이더 설정
provider "aws" {
 // 아시아 태평양(서울) 리전
 region = "ap-northeast-2"
}

# S3 버킷 생성
resource "aws_s3_bucket" "terraform_state" {
 bucket = "terraform-state-example-20231118"

 # 실수로 버킷이 삭제되지 않도록 하려면 아래 주석을 해제하세요.
 # lifecycle {
 # prevent_destroy = true
 # }
}

# 버킷 버전 관리 활성화(상태 파일의 히스토리를 관리하기 위함)
resource "aws_s3_bucket_versioning" "enabled" {
 bucket = aws_s3_bucket.terraform_state.id

 versioning_configuration {
 status = "Enabled"
 }
}

# S3에 저장될 때 암호화 하도록 설정
resource "aws_s3_bucket_server_side_encryption_configuration" "default" {
 bucket = aws_s3_bucket.terraform_state.id

 rule {
 apply_server_side_encryption_by_default {
 sse_algorithm = "AES256"
 }
 }
}

# 모든 public access를 차단(실수로 버킷이 공개되지 않도록 하기 위함)
resource "aws_s3_bucket_public_access_block" "public_access" {
 bucket = aws_s3_bucket.terraform_state.id

 block_public_acls = true
 block_public_policy = true
 ignore_public_acls = true
 restrict_public_buckets = true
}

# 여러 사람이 동시에 상태 파일을 수정하지 못하도록 DynamoDB를 사용한 락 설정
resource "aws_dynamodb_table" "terraform_locks" {
 name = "terraform_locks"
 billing_mode = "PAY_PER_REQUEST"
 hash_key = "LockID"

 attribute {
 name = "LockID"
 type = "S"
 }
}

우선 aws_s3_bucket 리소스를 통해 S3 버킷을 생성하는데요, 이 버킷에 상태 파일을 저장하게 됩니다. 그리고 필요한 경우 상태 파일의 히스토리를 버전 별로 관리할 수 있도록 버전 관리를 활성화 합니다. 버전 관리를 사용하도록 설정한다면 뭔가 상태 파일에 문제가 있을 경우 이전 버전으로 복구할 수 있겠죠?

그리고 상태 파일은 암호화되어 저장되도록 설정했고, 실수로 버킷이 공개되지 않도록 모든 public access를 차단했습니다. 마지막으로 여러 사람이 동시에 상태 파일을 수정하지 못하도록 DynamoDB를 사용한 락을 설정했습니다. 이제 tf init을 실행해봅시다.

> tf init
...
Terraform has been successfully initialized!
...

그리고 tf plan으로 변경될 리소스를 확인합니다.

> tf plan
...
Plan: 5 to add, 0 to change, 0 to destroy.
...

이어서 tf apply로 리소스를 생성합니다.

> tf apply
...
Apply complete! Resources: 5 added, 0 changed, 0 destroyed.

만약 이전글에서 사용했던 것처럼 제한된 IAM 사용자 권한을 사용하는 경우 “sts:GetCallerIdentity”,“s3:CreateBucket”,“dynamodb:CreateTable”,“dynamodb:DescribeTable”,“s3:ListBucket”,“s3:GetBucketPolicy”,“s3:GetBucketAcl”,“s3:GetBucketCORS”,“s3:GetBucketWebsite”,“s3:GetBucketVersioning”,“s3:GetAccelerateConfiguration”,“s3:GetBucketRequestPayment”,“s3:GetBucketLogging”,“s3:GetLifecycleConfiguration”,“s3:GetReplicationConfiguration”,“s3:GetEncryptionConfiguration”,“s3:GetBucketObjectLockConfiguration”,“s3:GetBucketTagging”,“s3:PutBucketVersioning”,“dynamodb:DescribeContinuousBackups”,“s3:PutBucketPublicAccessBlock”,“s3:PutEncryptionConfiguration”,“dynamodb:DescribeTimeToLive”,“dynamodb:ListTagsOfResource”,“s3:GetBucketPublicAccessBlock”,“s3:GetObject”,“s3:GetObjectVersion”,“dynamodb:GetItem”,“dynamodb:PutItem”,“dynamodb:DeleteItem” 등의 권한이 추가로 필요합니다.

S3는 잘 생성되었지만, 여전히 terraform.tfstate파일은 현재 폴더에 그대로 남아있습니다. 파일 내용을 확인해보면, 방금 생성한 S3의 정보가 담겨있습니다. 아직 backend설정을 하지 않았기 때문에 여전히 상태 파일은 로컬 컴퓨터에서 관리하고 있는 거죠. 그렇다면 backend를 S3로 설정하겠습니다. main.tf에서 기존에 작성된 코드 위에 다음 코드를 추가합니다.

# Terraform 설정
terraform {
 # 필요한 프로바이더 목록과 버전 정보
 required_providers {
 aws = {
 source = "hashicorp/aws"
 version = "~> 5.0" # 5.x 버전 사용
 }
 }

 # 상태 파일을 S3에 저장하도록 설정
 backend "s3" {
 bucket = "terraform-state-example-20231118"
 # 상태 파일이 저장될 경로
 key = "example/terraform.tfstate"
 region = "ap-northeast-2"

 # 상태 파일을 락으로 사용할 DynamoDB 테이블
 dynamodb_table = "terraform_locks"
 # 상태 파일을 암호화
 encrypt = true
 }
}

...

Terraform 블록을 선언하고 사용할 프로바이더와 버전 정보, 그리고 S3를 backend로 사용하도록 설정했습니다. 이제 tf init을 실행하면 로컬에 저장된 상태 파일을 새로 지정된 S3로 이동하게 됩니다.

> tf init
Initializing the backend...
Acquiring state lock. This may take a few moments...
Do you want to copy existing state to the new backend?
 Pre-existing state was found while migrating the previous "local" backend to the
 newly configured "s3" backend. No existing state was found in the newly
 configured "s3" backend. Do you want to copy this state to the new "s3"
 backend? Enter "yes" to copy and "no" to start with an empty state.

 Enter a value: yes

Releasing state lock. This may take a few moments...

Successfully configured the backend "s3"! Terraform will automatically
use this backend unless the backend configuration changes.
...

로컬에 저장된 상태를 S3로 복사하겠냐는 질문이 나오는데, yes를 입력하면 로컬에 저장된 상태 파일이 S3로 복사됩니다. 그리고 terraform.tfstate 파일이 남아있긴 하지만, 내용을 확인 해보면 텅텅 비어 있습니다. 이제 삭제해도 문제가 없겠죠! 참고로 backend에서 상태 파일을 로컬로 다운로드 하고 싶다면 terraform state pull 명령을 사용하면 됩니다.

iamlive를 실행 중이라면 tls: failed to verify certificate: x509 오류나 request send failed, Post "https://sts.ap-northeast-2.amazonaws.com/": proxyconnect tcp: dial tcp 127.0.0.1:80 등의 오류가 발생할 수 있습니다. iamlive의 실행을 위해 선언해둔 환경 변수 때문인데요, 해당 환경 변수를 주석처리하고 터미널 세션을 다시 시작하거나, unset 등의 명령어로 현재 터미널 세션에서 환경 변수를 제거할 수 있습니다.

그렇다면 이제 간단한 EC2 인스턴스를 추가해서 상태가 잘 관리되는지 확인하겠습니다. main.tf에 다음 코드를 추가합니다.

...

resource "aws_instance" "example" {
 // ap-northeast-2 리전의 Ubuntu 20.04 AMI
 ami = "ami-0c6e5afdd23291f73"
 instance_type = "t2.micro"
}

tf plan과 tf apply를 실행하여 동작을 확인합니다.

> tf plan
...
Plan: 1 to add, 0 to change, 0 to destroy.
...

> tf apply
...
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

더 이상 로컬에 상태 파일이 생성되지 않지만, 원격의 S3에서 상태를 읽어와서 잘 관리하고 있네요!

마치며

이제 우리는 상태를 로컬 파일이 아니라 S3를 통해 안전하고 안정적으로 그리고 어디서나 활용할 수 있도록 변경할 수 있습니다. 하지만 여전히 불안한 점은 남아있습니다. EC2를 추가하면서 plan, apply를 실행해보신 분들은 아시겠지만, 여전히 이미 생성된 S3에 대한 상태를 매번 비교하고 있습니다. 하나의 상태에 많은 리소스가 연결되면 이렇게 아주 작은 부분만을 바꿀 때도 전체 상태와 비교를 하게 됩니다. 그리고 아무리 리소스 파일이 공유된 상태라고는 하지만, 여러 사람이 동시에 서로 다른 부분에서 코드를 변경하면 예상하지 어려운 상황이 발생하겠죠. 그래서 상태 파일은 가능하면 작게 유지하는 게 좋습니다. 다음 시간에는 상태 파일을 작게 유지하는 방법에 대해 알아보겠습니다.

참고자료

Terraform Up and Running, 3rd Edition

License

저작자표시-비영리-변경금지 2.0 대한민국 (CC BY-NC-ND 2.0 KR)

How to Terraform(2) - 변수와 출력

Sat, 11 Nov 2023 15:30:01 +0900

시리즈 목차

How to Terraform(1) - 테라폼과의 가벼운(?) 첫 만남

이전 글 복습

이전 글에서 작성한 코드를 다시 한 번 볼까요?

// AWS 프로바이더 설정
provider "aws" {
 // 아시아 태평양(서울) 리전
 region = "ap-northeast-2"
}

resource "aws_instance" "example" {
 // ap-northeast-2 리전의 Ubuntu 20.04 AMI
 ami = "ami-0c6e5afdd23291f73"
 instance_type = "t2.micro"
 vpc_security_group_ids = [aws_security_group.example.id]

 // 최초 인스턴스 생성 시에만 실행
 user_data = <<-EOF
 #!/bin/bash
 echo "Hello, World" > index.html
 nohup busybox httpd -f -p 8080 &
 EOF

 tags = {
 Name = "terraform-example"
 }
}

resource "aws_security_group" "example" {
 name = "terraform-example"

 // 인바운드 규칙
 ingress {
 from_port = 8080
 to_port = 8080
 protocol = "tcp"
 cidr_blocks = ["0.0.0.0/0"]
 }
}

위 코드에는 몇 가지 개선할 점이 있습니다. 만약 EC2 인스턴스를 몇 개 더 만든다고 했을 때 중복될 만한 부분이 있습니다. AMI ID나 인스턴스 타입 등이 그렇죠. 이렇게 중복될 만한 내용은 변수로 선언하여 중복을 줄일 수 있고, 중복을 줄이면 실수를 줄일 수 있습니다. 또한 EC2 인스턴스에 접근할 수 있는 IP를 AWS 콘솔에서 확인하는 번거로움이 있었습니다. 이 또한 출력을 통해 확인할 수 있습니다. 자 그럼 하나씩 해봅시다!

변수

가장 먼저 AMI ID 부터 변수를 선언해볼까요? main.tf 파일이 있는 위치에 variables.tf 파일을 만들고 아래와 같이 작성해봅시다.

variable "ami_id" {
 type = string
 default = "ami-0c6e5afdd23291f73"
}

변수의 이름은 ami_id이고, 타입은 string입니다. 그리고 default에는 별도로 값이 주어지지 않는 경우 사용할 기본값을 설정합니다. 이제 main.tf 파일에서 ami 속성을 변수를 통해 입력받도록 변경합니다.

resource "aws_instance" "example" {
 ami = var.ami_id # 변수 ami_id 참조
 instance_type = "t2.micro"
 vpc_security_group_ids = [aws_security_group.example.id]

 ...
}

VS Code를 사용하신다면 Terraform Extension for Visual Studio Code를 꼭 설치하세요! 선언된 변수나 리소스에 대해서 자동완성 기능과 오류 등을 미리 확인할 수 있게 도와줍니다!

기존에 직접 값을 지정했던 ami 속성에 변수 ami_id를 참조하도록 변경했습니다. tf plan을 통해 스크립트에 이상이 없는지 확인합니다. 참고로 지난 시간에 만든 EC2 인스턴스는 tf destroy를 통해 삭제되었다고 가정하겠습니다.

terraform이라고 매번 입력하는게 어려우니 .zshrc나 .bashrc에 다음과 같이 alias 설정을 해서 tf로 사용하는 것도 방법입니다.
alias tf=terraform

> tf plan

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following
symbols:
 + create

Terraform will perform the following actions:

 # aws_instance.example will be created
 + resource "aws_instance" "example" {
 + ami = "ami-0c6e5afdd23291f73"
 ...
 }

 # aws_security_group.example will be created
 + resource "aws_security_group" "example" {
 ...
 }

Plan: 2 to add, 0 to change, 0 to destroy.

───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

Note: You didn't use the -out option to save this plan, so Terraform can't guarantee to take exactly these actions if you run
"terraform apply" now.

ami 속성이 변수에 설정된 기본값으로 설정된 걸 확인할 수 있습니다. 그렇다면 기본값 대신에 변수에 값을 넘겨볼까요?

커맨드로 변수 지정하기

tf plan 또는 tf apply를 실행할 때 -var 옵션을 사용하면 변수에 값을 넘길 수 있습니다. -var 옵션은 변수의 개수 만큼 여러 번 사용할 수 있습니다.

> tf plan -var "ami_id=ami-09eb4311cbaecf89d"
...
 # aws_instance.example will be created
 + resource "aws_instance" "example" {
 + ami = "ami-09eb4311cbaecf89d"
 ...
 }

파일로 변수 지정하기

이번에는 terraform.tfvars 파일을 통해 변수에 값을 지정해보겠습니다. terraform.tfvars 파일을 만들고 아래와 같이 작성해봅시다.

ami_id = "ami-09eb4311cbaecf89d"

그리고 tf plan을 실행하면, 동일한 결과를 확인할 수 있습니다.

> tf plan
...
 # aws_instance.example will be created
 + resource "aws_instance" "example" {
 + ami = "ami-09eb4311cbaecf89d"
 ...
 }

파일 이름이 terraform.tfvars 또는 terraform.tfvars.json(json 형태로 작성가능)이거나, 파일 이름이 .auto.tfvars 또는 .auto.tfvars.json으로 끝나는 경우, Terraform 코드가 실행 될 때 자동으로 파일을 읽어서 변수에 값을 지정합니다. 만약 파일 이름 앞서 설명드린 규칙과 다르다면, 파일 이름을 -var-file 옵션을 사용하여 파일을 지정할 수 있습니다.

한 가지 주의 할 점은 terraform.tfvars 파일을 사용하는 경우, 반드시 .gitignore에 terraform.tfvars를 추가해야 합니다! 참고로 gitignore.io를 통해 Terraform의 .gitignore 파일을 생성해보면 다음과 같습니다.

# Created by https://www.toptal.com/developers/gitignore/api/terraform
# Edit at https://www.toptal.com/developers/gitignore?templates=terraform

### Terraform ###
# Local .terraform directories
**/.terraform/*

# .tfstate files
*.tfstate
*.tfstate.*

# Crash log files
crash.log
crash.*.log

# Exclude all .tfvars files, which are likely to contain sensitive data, such as
# password, private keys, and other secrets. These should not be part of version
# control as they are data points which are potentially sensitive and subject
# to change depending on the environment.
*.tfvars
*.tfvars.json

# Ignore override files as they are usually used to override resources locally and so
# are not checked in
override.tf
override.tf.json
*_override.tf
*_override.tf.json

# Include override files you do wish to add to version control using negated pattern
# !example_override.tf

# Include tfplan files to ignore the plan output of command: terraform plan -out=tfplan
# example: *tfplan*

# Ignore CLI configuration files
.terraformrc
terraform.rc

# End of https://www.toptal.com/developers/gitignore/api/terraform

환경변수로 변수 지정하기

마지막으로는 환경변수를 지정하는 방법이 있습니다. TF_VAR_로 시작해서 변수 이름을 적어주면 됩니다. ~/.zshrc등에 환경변수를 적어도 되지만 일단은 확인을 위해 인라인으로 환경변수를 지정해서 tf plan을 실행해보겠습니다.

> TF_VAR_ami_id=ami-09eb4311cbaecf89d tf plan
...
 # aws_instance.example will be created
 + resource "aws_instance" "example" {
 + ami = "ami-09eb4311cbaecf89d"
 ...
 }

변수 작업을 더 해보자

이제 변수를 사용하는 방법을 알았으니 나머지 값들도 변수로 변경하겠습니다.

우선 변수를 선언합니다.

variable "ami_id" {
 type = string
 default = "ami-0c6e5afdd23291f73"
}

variable "instance_type" {
 type = string
 default = "t2.micro"
}

variable "port" {
 type = number
}

variable "cidr_blocks" {
 type = list(string)
 default = ["0.0.0.0/0"]
}

그리고 이 변수를 사용하도록 코드를 변경합니다.

resource "aws_instance" "example" {
 // ap-northeast-2 리전의 Ubuntu 20.04 AMI
 ami = var.ami_id # 변수 ami_id 참조
 instance_type = var.instance_type
 vpc_security_group_ids = [aws_security_group.example.id]

 // 최초 인스턴스 생성 시에만 실행
 user_data = <<-EOF
 #!/bin/bash
 echo "Hello, World" > index.html
 nohup busybox httpd -f -p ${var.port} &
 EOF

 tags = {
 Name = "terraform-example"
 }
}

resource "aws_security_group" "example" {
 name = "terraform-example"

 // 인바운드 규칙
 ingress {
 from_port = var.port
 to_port = var.port
 protocol = "tcp"
 cidr_blocks = var.cidr_blocks
 }
}

그리고 terraform.tfvars 파일을 사용해서 변수를 지정합니다.

ami_id = "ami-09eb4311cbaecf89d"
port = 8080

마지막으로 tf plan을 실행해서 변수가 잘 작동하는지 확인합니다.

다음은 출력

현재 작성 중인 코드에는 외부에서 EC2 인스턴스에 접근할 수 있는 IP를 확인할 수 있는 방법이 없고, AWS 콘솔에 접속해서 생성된 EC2 인스턴스를 찾아가야만 합니다. 이제 출력값을 설정해서 생성된 EC2 인스턴스의 IP를 확인해 보겠습니다.

outputs.tf 파일을 만들고 아래와 같이 작성합니다.

output "public_ip" {
 value = aws_instance.example.public_ip
 sensitive = false
}

그리고 tf plan을 실행합니다. 그리고 마지막에 출력되는 내용을 잘 보세요!

> tf plan
...
Plan: 2 to add, 0 to change, 0 to destroy.

Changes to Outputs:
 + public_ip = (known after apply)

...

출력값이 추가되었다는 걸 알려주죠? 이 출력값은 EC2 인스턴스가 실제로 만들어진 다음에 확인할 수 있기 때문에 known after apply라고 표시되었습니다. 이제 tf apply를 실행해봅시다.

> tf apply
...
Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

Outputs:

public_ip = "13.209.17.62"

약 1-2분 뒤에 해당 IP의 지정된 포트(기본 값은 8080으로 설정했었죠?)로 접속하면 Hello, World가 출력되는 걸 확인할 수 있습니다.

그런데 이런 출력 값이 있다는 건 어디서 알 수 있는 걸까요? EC2 인스턴스의 공식 문서를 확인해볼까요?

이 문서에는 EC2 인스턴스를 Terraform으로 관리할 때 사용할 수 있는 속성들이 아주 많이, 상세하게 정리되어 있습니다. 여기서 우리가 주목해야 할 곳은 문서 우측 상단의 ON THIS PAGE 영역의 Attribute Reference입니다.

이 영역에는 생성된 EC2 인스턴스를 통해 확인할 수 있는 속성들이 정리되어 있습니다. public_ip를 찾아볼까요?

이렇게 필요한 속성을 찾아서 활용하면 됩니다. 물론… 보시면 알겠지만 속성이 좀 많습니다. 뭐 하다보면 하나씩 눈에 보이는 거죠 하하하하하…

내친 김에 SSH 키도 설정해보자

이번에는 EC2 인스턴스에 접속할 때 SSH 키를 사용하도록 설정해보겠습니다. 먼저 main.tf에서 SSH 키를 생성 및 설정합니다.

...

resource "aws_instance" "example" {
 ...

 key_name = aws_key_pair.ssh.key_name # ssh 키 이름 참조

 tags = {
 Name = "terraform-example"
 }
}

resource "aws_security_group" "example" {
 ...

 // ssh 접속을 위한 인바운드 규칙
 ingress {
 from_port = 22
 to_port = 22
 protocol = "tcp"
 cidr_blocks = var.cidr_blocks
 }
}

# ssh 키 쌍(pair) 생성
resource "tls_private_key" "ssh" {
 algorithm = "RSA"
 rsa_bits = 4096
}

# ssh 키 쌍(pair) 리소스
resource "aws_key_pair" "ssh" {
 key_name = "terraform-example"
 public_key = tls_private_key.ssh.public_key_openssh
}

그리고 outputs.tf에 SSH 키를 출력하도록 설정합니다.

output "tls_private_key" {
 value = tls_private_key.ssh.private_key_pem
 sensitive = true # 민감한 정보이므로 출력하지 않음
}

tls_private_key 리소스는 hashicorp/tls 프로바이더를 통해 제공되므로 tf init을 통해 프로바이더를 설치합니다.

> tf init
Initializing the backend...

Initializing provider plugins...
...
- Installing hashicorp/tls v4.0.4...
- Installed hashicorp/tls v4.0.4 (signed by HashiCorp)

...

Terraform has been successfully initialized!

그리고 tf plan으로 이상이 없는지 확인합니다.

> tf plan
...
Plan: 3 to add, 0 to change, 0 to destroy.

Changes to Outputs:
 + public_ip = (known after apply)
 + tls_private_key = (sensitive value)
...

이제 tf apply를 실행합니다. 그런데 만약 이전 글의 내용을 따라 오면서 제한된 IAM이 설정된 계정을 사용하신다면 이런 에러가 발생합니다.

> tf apply
...
│ Error: importing EC2 Key Pair (terraform-example): UnauthorizedOperation: You are not authorized to perform this operation. User: arn:aws:iam::246181472423:user/terraform-user is not authorized to perform: ec2:ImportKeyPair on resource:
...

이 작업을 위해서는 여기서 에러가 발생한 ec2:ImportKeyPair, 그리고 ec2:DescribeKeyPairs, ec2:DeleteKeyPair 권한이 필요합니다. 이 권한을 추가해줍시다. 권한을 추가하고 다시 tf apply를 실행합니다.

> tf apply
...
Apply complete! Resources: 2 added, 0 changed, 1 destroyed.

Outputs:

public_ip = "15.164.214.233"
tls_private_key = <sensitive>

tls_private_key는 민감한 정보를 의미하는 sensitive = true로 설정되었으므로 터미널을 통해서는 확인할 수 없습니다. 하지만 EC2에 접속하려면 ssh 파일이 필요하죠? Terraform의 상태로 부터 이 파일을 생성합니다.

> tf output tls_private_key > ~/.ssh/ec2_example.pem
> chmod 400 ~/.ssh/ec2_example.pem # 권한 설정

그리고 생성된 파일을 통해 EC2에 접속해봅시다. 그리고 접속이 확인되면 exit을 통해 접속을 종료합니다.

> ssh -i ~/.ssh/ec2_example.pem ubuntu@15.164.214.233
Welcome to Ubuntu 20.04.6 LTS (GNU/Linux 5.15.0-1048-aws x86_64)
...
ubuntu@ip-172-31-43-230:~$ exit

모두 확인이 되었다면 tf destroy를 통해 리소스를 꼭 삭제 해주세요!

> tf destroy
...
Destroy complete! Resources: 4 destroyed.

하나만 더!

참고로 지금 우리가 사용한 pem 파일은 로컬 폴더의 terraform.tfstate에 저장되어 있어서 언제든지 파일로 생성할 수 있는 상태므로, 이 파일은 권한이 없는 사람들이 접근할 수 없도록 관리되어야 합니다. 만약 이 파일에서 pem 파일을 생성하고 싶지 않다면, 별도로 파일을 생성한 뒤에 생성된 파일을 Terraform 코드를 통해 주입하는 방법이 있습니다.

> ssh-keygen -t rsa -b 4096 -f ~/.ssh/ec2_example
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /Users/onlifecoding/.ssh/ec2_example
...

보안을 위해 passphrase에 원하는 암호를 설정할 수 있으며, 암호를 입력하고 싶지 않은 경우는 그냥 엔터를 누르면 됩니다. 그리고 생성된 파일을 Terraform코드에서 참조하도록 설정합니다.

resource "aws_key_pair" "ssh" {
 key_name = "terraform-example"
 public_key = file("~/.ssh/ec2_example.pub")
}

이렇게 하면 Terraform의 상태에 키 값을 저장하지 않고도 Terraform 코드를 통해 키 값을 주입할 수 있습니다. 상황에 맞게 적절한 방법을 사용하면 되겠죠!

마치며

사실 Terraform에서 제일 중요한 걸 한 가지 꼽아보자면, Terraform의 상태를 잘 관리하는 겁니다. 지금까지는 Terraform 상태에 대한 고려 없이 그냥 진행했고, 상태는 로컬의 terraform.tfstate파일에 저장되어 있습니다. 다음에는 Terraform의 상태를 어떻게 관리하면 좋을지 살펴보겠습니다.

참고자료

License

저작자표시-비영리-변경금지 2.0 대한민국 (CC BY-NC-ND 2.0 KR)

How to Terraform(1) - 테라폼과의 가벼운(?) 첫 만남

Wed, 15 Mar 2023 09:00:00 +0900

Terraform이란?

Terraform은 DevOps의 필수 구성 요소로 자리 잡고 있습니다. Terraform을 통해 서비스를 지탱하는 인프라에 대한 정의, 배포, 업데이트 그리고 삭제를 코드로 정의할 수 있으며 이러한 개념을 IaC(infrastructure as code)라고 합니다.

DevOps는 소프트웨어 배포를 빠르고 효율적으로 할 수 있게 해주는 프로세스, 아이디어, 테크닉을 말한다.

그런데, 인프라를 코드로 작성하면 무슨 장점이 있는 걸까요?

자동화: 인프라를 코드로 작성할 수 있다면 자동화할 수 있고, 필요할 때 언제든 즉시 실행 가능합니다.
실수 방지: 자동화를 통해 수작업에서 발생하는 오류를 줄일 수 있고, 몇 번이고 반복해서 실행해도 안심할 수 있죠.
문서화: 또한 코드는 인프라에 대한 문서로 볼 수도 있습니다. 누군가의 머리 속에만 존재하지 않고, 누구나 볼 수 있는 코드에 인프라의 정보가 담기는 셈이죠.
버전 관리: 그리고 매우 큰 장점이 또 있는데요, 마치 소스 코드를 git으로 버전 관리 하듯이 인프라의 구성 역시 코드로써 버전 관리 할 수 있습니다. 뭔가 잘 못 됐을 때, 빠르게 커밋 로그를 통해 변경점을 찾을 수 있고 이전 버전으로 돌아갈 수도 있죠! 😊

그런데 Terraform으로 관리를 시작하면 누구나 거치는 어려움이 있습니다. 그건 바로 모든 리소스를 Terraform을 통해서만 관리해야 한다는 점입니다. Terraform으로 리소스를 만들어 놓고 나서, 나도 모르게 습관적으로 포털에 들어가서 마우스를 클릭클릭해서 설정을 변경하고 싶은 유혹에 빠집니다. 수작업을 추가하는 순간 Terraform의 상태 관리에서 벗어나기 시작하므로 피치 못할 사정이 아니면 Terraform을 통해서 상태를 변경해야 합니다.

오래된 습관은 아주 무섭습니다. 문제를 해결하려다 보면 저도 모르게 포털에 들어가서 설정을 바꾸곤 합니다…😅

Terraform 설치하기

Terraform을 설치하는 방법은 여려가지가 있지만, 저는 tfenv를 추천합니다. tfenv는 Terraform의 버전을 관리해주는 도구로, 여러 버전의 Terraform을 설치하고 각각의 버전을 쉽게 전환할 수 있습니다. 예를 들어 1.4.0 버전의 Terraform을 사용하던 중에 1.5.0이 출시되었다고 해보죠. 1.5.0을 사용해보다가 뭔가 문제가 있어서 다시 1.4.0으로 돌아오고 싶을 수도 있습니다. 그런 경우에 1.4.0을 삭제하고 1.5.0을 설치하고… 다시 1.5.0을 삭제하고 1.4.0을 설치하고… 하는 번거로운 작업을 해야 하지만, tfenv를 사용하면 여러 버전을 동시에 설치하고 각각의 버전을 쉽게 전환할 수 있습니다.

# tfenv 설치
> brew install tfenv

# 설치 가능한 버전 목록 확인하기
> tfenv list-remote
1.7.0-alpha20231025
1.6.2
1.6.1
1.6.0
1.6.0-rc1
1.6.0-beta3
1.6.0-beta2
1.6.0-beta1
1.6.0-alpha20230816
1.6.0-alpha20230802
1.6.0-alpha20230719
1.5.7
1.5.6
...

# 현재 설치된 버전 확인(terraform을 alias인 tf로 등록해서 사용하고 있습니다.)
> tf version
Terraform v1.5.3
on darwin_arm64

Your version of Terraform is out of date! The latest version
is 1.6.2. You can update by downloading from https://www.terraform.io/downloads.html

# 1.6.2 버전 설치하기
> tfenv install 1.6.2
Installing Terraform v1.6.2
...
Installation of terraform v1.6.2 successful. To make this your default version, run 'tfenv use 1.6.2'

# 1.6.2 버전으로 전환하기
> tfenv use 1.6.2

# 현재 설치된 버전 확인하기
> tf version
Terraform v1.6.2
on darwin_arm64

terraform이라고 매번 입력하는게 어려우니 .zshrc나 .bashrc에 다음과 같이 alias 설정을 해서 tf로 사용하는 것도 방법입니다.
alias tf=terraform

terraform 1.0 부터는 v1-compatibility-promises가 적용되는데요, 1.0 부터 향후 출시될 1.x 버전까지는 코드 변경 없이 동작한다는 걸 보장합니다. 따라서 1.x 버전에서는 최신 버전을 사용하지 않을 이유가 없을지도…?

AWS IAM 사용자 생성하기

Terraform이 AWS의 리소스를 관리하기 위해서는 Terraform이 사용할 수 있는 AWS IAM 사용자가 필요합니다. AWS IAM 사용자를 생성하고 Terraform이 사용할 수 있는 권한을 부여해보겠습니다.

IAM 사용자 생성하기

먼저 AWS 계정이 필요하겠죠? 계정을 생성하고 로그인하면 AWS 콘솔에 접속할 수 있습니다. AWS 콘솔에서 IAM을 검색하고 IAM을 선택합니다.

좌측의 엑세스 관리 > 사용자 > 사용자 생성을 클릭합니다. 이어지는 단계에서 사용자 이름을 입력하고 다음으로 이동합니다.

우선 사용자 그룹 생성을 눌러 사용자 그룹의 이름을 설정하고 권한 정책에서는 일단 모든 AWS 리소스에 대한 권한을 가지는 AdministratorAccess를 선택하고 사용자 그룹 생성을 누릅니다.

전체 권한이 부여된 계정이 잘못 사용되면 큰 문제를 일으킬 수 있으므로 필요한 권한만을 부여하는 게 좋습니다. 필요한 만큼 권한을 부여하는 방법에 대해서는 추후 다시 설명하겠습니다.

사용자 그룹이 생성되면 다음과 같이 생성된 그룹을 선택하고 다음을 누릅니다.

그리고 마지막으로 검토 및 생성단계에서 사용자 정보를 확인하고 사용자 생성을 누릅니다. 이제 사용자 목록에서 생성된 사용자를 확인할 수 있습니다.

사용자 이름을 눌러 세부 정보 페이지로 이동하고 우측 상단의 액세스 키 만들기를 클릭하고, 목록에서 Command Line Interface(CLI)를 선택하고 다음을 누릅니다.

설명 태그 설정에서 태그 이름을 작성(ex: Terraform-Access)하고 액세스 키 만들기를 누릅니다. 이제 액세스 키 ID와 비밀 액세스 키를 확인할 수 있습니다.

비밀 액세스 키를 잃어버리면 다시 발급해야 하므로 잘 보관해두시기 바랍니다.

Terraform 계정 정보 설정하기

앞서 Terraform이 사용할 계정을 생성하고 해당 계정의 액세스 키도 생성을 마쳤습니다. 이제 Terraform이 해당 계정을 사용할 수 있도록 환경 변수에 계정 정보를 설정해보겠습니다.

# zsh을 사용하는 경우
> vi ~/.zshrc

# bash를 사용하는 경우
> vi ~/.bashrc

그리고 다음과 같이 환경 변수를 설정합니다.

export AWS_ACCESS_KEY_ID={액세스 ID}
export AWS_SECRET_ACCESS_KEY={비밀 액세스 키}

참고로 vi로 파일을 열고 i를 누르면 편집 모드로 전환되고, esc를 누르면 편집 모드에서 빠져나올 수 있습니다. :wq를 입력하면 저장하고 빠져나올 수 있습니다. 그리고 환경 변수를 설정한 후에는 source ~/.zshrc 또는 source ~/.bashrc를 입력해서 환경 변수를 적용할 수 있습니다.

다음 명령어를 통해서 환경 변수가 잘 설정되었는지 확인할 수 있습니다.

> echo $AWS_ACCESS_KEY_ID
{액세스 ID}

첫 Terraform 코드 작성하기

이제 Terraform을 사용할 준비가 끝났습니다. 터미널을 열고 다음과 같이 작업할 공간을 생성합니다.

~/src
> mkdir how-to-terraform

~/src
> cd how-to-terraform

~/src/how-to-terraform
> code .

이 시리즈에서는 Visual Studio Code를 사용합니다.

에디터에서 chapter01 폴더를 생성하고 폴더 안에 main.tf 파일을 생성합니다. 그리고 다음과 같이 코드를 작성합니다.

provider "aws" {
 // 아시아 태평양(서울) 리전
 region = "ap-northeast-2"
}

resource "aws_instance" "example" {
 // ap-northeast-2 리전의 Ubuntu 20.04 AMI
 ami = "ami-0c6e5afdd23291f73"
 instance_type = "t2.micro"

 // 최초 인스턴스 생성 시에만 실행
 user_data = <<-EOF
 #!/bin/bash
 echo "Hello, World" > index.html
 nohup busybox httpd -f -p 8080 &
 EOF

 tags = {
 Name = "terraform-example"
 }
}

AWS에서 제공하는 프로바이더를 선언하였고, AWS의 ap-northeast-2(서울)리전을 대상으로 Terraform 코드를 실행하도록 설정하였습니다. 그리고 Ubuntu 20.04로 동작하는 EC2 인스턴스를 하나 생성하였습니다. 그리고 최초 인스턴스가 생성 될 때 user_data에 지정한 스크립트가 실행되면서 웹에서 접속하면 Hello, World를 출력하는 웹 서버가 실행되도록 설정하였습니다.

Terraform 초기화 및 실행 계획 확인하기

main.tf 파일에 우클릭하고 통합 터미널에서 열기를 선택하여 main.tf파일이 위치한 경로에서 터미널을 실행합니다.

그리고 다음과 같이 Terraform을 초기화합니다.

> tf init

Initializing the backend...

Initializing provider plugins...
- Finding latest version of hashicorp/aws...
- Installing hashicorp/aws v5.23.1...
- Installed hashicorp/aws v5.23.1 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

AWS 프로바이더 5.23.1 버전이 설치되었고, Terraform이 정상적으로 초기화 되었음을 알 수 있습니다. 그렇다면, 이제 Terraform 코드로 인프라가 어떻게 구성될지 미리 살펴볼까요?

> tf plan
Terraform used the selected providers to generate the following execution plan. Resource
actions are indicated with the following symbols:
 + create

Terraform will perform the following actions:

 # aws_instance.example will be created
 + resource "aws_instance" "example" {
 + ami = "ami-0c6e5afdd23291f73"
 + arn = (known after apply)
 + associate_public_ip_address = (known after apply)
 + availability_zone = (known after apply)
 + cpu_core_count = (known after apply)
 + cpu_threads_per_core = (known after apply)
 + disable_api_stop = (known after apply)
 + disable_api_termination = (known after apply)
 + ebs_optimized = (known after apply)
 + get_password_data = false
 + host_id = (known after apply)
 + host_resource_group_arn = (known after apply)
 + iam_instance_profile = (known after apply)
 + id = (known after apply)
 + instance_initiated_shutdown_behavior = (known after apply)
 + instance_lifecycle = (known after apply)
 + instance_state = (known after apply)
 + instance_type = "t2.micro"
 + ipv6_address_count = (known after apply)
 + ipv6_addresses = (known after apply)
 + key_name = (known after apply)
 + monitoring = (known after apply)
 + outpost_arn = (known after apply)
 + password_data = (known after apply)
 + placement_group = (known after apply)
 + placement_partition_number = (known after apply)
 + primary_network_interface_id = (known after apply)
 + private_dns = (known after apply)
 + private_ip = (known after apply)
 + public_dns = (known after apply)
 + public_ip = (known after apply)
 + secondary_private_ips = (known after apply)
 + security_groups = (known after apply)
 + source_dest_check = true
 + spot_instance_request_id = (known after apply)
 + subnet_id = (known after apply)
 + tags = {
 + "Name" = "terraform-example"
 }
 + tags_all = {
 + "Name" = "terraform-example"
 }
 + tenancy = (known after apply)
 + user_data = "c765373c563b260626d113c4a56a46e8a8c5ca33"
 + user_data_base64 = (known after apply)
 + user_data_replace_on_change = false
 + vpc_security_group_ids = (known after apply)
 }

Plan: 1 to add, 0 to change, 0 to destroy.

──────────────────────────────────────────────────────────────────────────────────────────────

Note: You didn't use the -out option to save this plan, so Terraform can't guarantee to take
exactly these actions if you run "terraform apply" now.

tf plan명령을 실행하면 Terraform이 현재 인프라의 상태와 코드에 정의된 인프라를 비교해서 어떻게 인프라에 반영할 것인지 미리 확인해볼 수 있습니다. 추가될 요소는 앞에 +가 붙고 삭제된 요소는 앞에 -가 붙습니다. 그리고 코드에서 지정해준 인스턴스의 ami, instance_type, user_data 등을 제외하면 모두 known after apply라고 표시되어 있습니다. 이런 정보는 인스턴스가 실제로 생성되고 나서 확인할 수 있다는 의미입니다.

이렇게 코드가 반영되면 어떻게 인프라가 변경될지 미리 상세하게 확인해볼 수 있구요, 맨 마지막 줄에는 요약 정보가 표시됩니다. 코드의 실행 게획을 미리 짜본 결과 1개의 리소스가 추가되고, 변경될 리소스는 0개, 삭제될 리소스 역시 0개라고 합니다. Terraform 코드를 처음 실행하는 거니까 당연한 결과겠죠?

Terraform 코드 실행하기

실행 계획을 확인해보고 문제가 없으면 코드를 실행해서 인프라를 변경할 수 있습니다. 다음과 같이 tf apply를 입력하면 코드가 실행되고 인프라가 변경됩니다.

> tf apply
Terraform used the selected providers to generate the following execution plan. Resource
actions are indicated with the following symbols:
 + create

Terraform will perform the following actions:

 # aws_instance.example will be created
 + resource "aws_instance" "example" {
 + ami = "ami-0c6e5afdd23291f73"
 + arn = (known after apply)
 + associate_public_ip_address = (known after apply)
 + availability_zone = (known after apply)
 + cpu_core_count = (known after apply)
 + cpu_threads_per_core = (known after apply)
 + disable_api_stop = (known after apply)
 + disable_api_termination = (known after apply)
 + ebs_optimized = (known after apply)
 + get_password_data = false
 + host_id = (known after apply)
 + host_resource_group_arn = (known after apply)
 + iam_instance_profile = (known after apply)
 + id = (known after apply)
 + instance_initiated_shutdown_behavior = (known after apply)
 + instance_lifecycle = (known after apply)
 + instance_state = (known after apply)
 + instance_type = "t2.micro"
 + ipv6_address_count = (known after apply)
 + ipv6_addresses = (known after apply)
 + key_name = (known after apply)
 + monitoring = (known after apply)
 + outpost_arn = (known after apply)
 + password_data = (known after apply)
 + placement_group = (known after apply)
 + placement_partition_number = (known after apply)
 + primary_network_interface_id = (known after apply)
 + private_dns = (known after apply)
 + private_ip = (known after apply)
 + public_dns = (known after apply)
 + public_ip = (known after apply)
 + secondary_private_ips = (known after apply)
 + security_groups = (known after apply)
 + source_dest_check = true
 + spot_instance_request_id = (known after apply)
 + subnet_id = (known after apply)
 + tags = {
 + "Name" = "terraform-example"
 }
 + tags_all = {
 + "Name" = "terraform-example"
 }
 + tenancy = (known after apply)
 + user_data = "c765373c563b260626d113c4a56a46e8a8c5ca33"
 + user_data_base64 = (known after apply)
 + user_data_replace_on_change = false
 + vpc_security_group_ids = (known after apply)
 }

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
 Terraform will perform the actions described above.
 Only 'yes' will be accepted to approve.

 Enter a value:

코드를 실행하면 앞서 확인한 것 처럼 실행 계획을 한 번 더 확인합니다. 그리고 정말 이 코드를 실행하려면 yes를 입력하라고 합니다. yes이외의 값을 입력하면 코드 실행이 취소됩니다.

aws_instance.example: Creating...
aws_instance.example: Still creating... [10s elapsed]
aws_instance.example: Still creating... [20s elapsed]
aws_instance.example: Creation complete after 22s [id=i-00229af6743e0ba4b]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

참고로 실행 계획을 생성할 때, 실행 계획을 파일로 출력하여 코드를 실행할 때 실행 계획대로 바로 실행되도록 할 수도 있습니다. tf plan -out plan.out을 입력하면 실행 계획이 plan.out 파일로 저장되고, tf apply plan.out을 입력하면 plan.out 파일에 저장된 실행 계획대로 코드가 실행됩니다.

코드 실행 결과로 1개의 리소스가 생성되었습니다. 포털에서 EC2로 검색하여 EC2 포털로 들어가면 인스턴스(실행 중) 항목이 1인 걸 확인할 수 있으며, 해당 항목을 누르면 실행 중인 EC2를 확인할 수 있습니다.

인스턴스 ID를 눌러 상세 페이지로 들어가면 우측 상단에서 퍼블릭 IPv4 주소, 퍼블릭 IPv4 DNS 등을 확인할 수 있지만, 해당 주소로 접속은 불가합니다.

main.tf 코드에 다음 항목을 추가해서 외부에서의 접속을 허용합니다.

// AWS 프로바이더 설정
provider "aws" {
 // 아시아 태평양(서울) 리전
 region = "ap-northeast-2"
}

resource "aws_instance" "example" {
 // ap-northeast-2 리전의 Ubuntu 20.04 AMI
 ami = "ami-0c6e5afdd23291f73"
 instance_type = "t2.micro"
 // 외부에서 접속을 허용하기 위한 설정
 vpc_security_group_ids = [aws_security_group.example.id]

 // 최초 인스턴스 생성 시에만 실행
 user_data = <<-EOF
 #!/bin/bash
 echo "Hello, World" > index.html
 nohup busybox httpd -f -p 8080 &
 EOF

 tags = {
 Name = "terraform-example"
 }
}

// 인바운드 규칙을 설정하기 위한 보안 그룹
resource "aws_security_group" "example" {
 name = "terraform-example"

 // 인바운드 규칙
 ingress {
 from_port = 8080
 to_port = 8080
 protocol = "tcp"
 cidr_blocks = ["0.0.0.0/0"]
 }
}

다시 실행 계획을 확인해봅니다.

> tf plan
aws_instance.example: Refreshing state... [id=i-00229af6743e0ba4b]

Terraform used the selected providers to generate the following execution plan. Resource
actions are indicated with the following symbols:
 + create
 ~ update in-place

Terraform will perform the following actions:

 # aws_instance.example will be updated in-place
 ~ resource "aws_instance" "example" {
 id = "i-00229af6743e0ba4b"
 tags = {
 "Name" = "terraform-example"
 }
 ~ vpc_security_group_ids = [
 - "sg-0908fdbf1d8c6156e",
 ] -> (known after apply)
 # (31 unchanged attributes hidden)

 # (8 unchanged blocks hidden)
 }

 # aws_security_group.example will be created
 + resource "aws_security_group" "example" {
 + arn = (known after apply)
 + description = "Managed by Terraform"
 + egress = (known after apply)
 + id = (known after apply)
 + ingress = [
 + {
 + cidr_blocks = [
 + "0.0.0.0/0",
 ]
 + description = ""
 + from_port = 8080
 + ipv6_cidr_blocks = []
 + prefix_list_ids = []
 + protocol = "tcp"
 + security_groups = []
 + self = false
 + to_port = 8080
 },
 ]
 + name = "terraform-example"
 + name_prefix = (known after apply)
 + owner_id = (known after apply)
 + revoke_rules_on_delete = false
 + tags_all = (known after apply)
 + vpc_id = (known after apply)
 }

Plan: 1 to add, 1 to change, 0 to destroy.

──────────────────────────────────────────────────────────────────────────────────────────────

Note: You didn't use the -out option to save this plan, so Terraform can't guarantee to take
exactly these actions if you run "terraform apply" now.

새로운 리소스(시큐리티 그룹)이 추가되고 시큐리티 그룹을 통해 외부에서의 접속을 허용하도록 EC2 인스턴스가 변경되는 것을 확인할 수 있습니다. 이제 코드를 실행합니다.

> tf apply
...
aws_security_group.example: Creating...
aws_security_group.example: Creation complete after 1s [id=sg-057069d47b3e7f650]
aws_instance.example: Modifying... [id=i-00229af6743e0ba4b]
aws_instance.example: Modifications complete after 2s [id=i-00229af6743e0ba4b]

Apply complete! Resources: 1 added, 1 changed, 0 destroyed.

이제 다시 퍼블릭 IPv4 주소, 퍼블릭 IPv4 DNS를 통해 8080번 포트로 접속하면 Hello, World를 확인할 수 있습니다.

리소스 삭제하기

Terraform 코드로 생성된 리소스는 destroy 명령어로 일괄 삭제할 수 있다.

> tf destroy
aws_security_group.example: Refreshing state... [id=sg-057069d47b3e7f650]
aws_instance.example: Refreshing state... [id=i-00229af6743e0ba4b]

Terraform used the selected providers to generate the following execution plan. Resource
actions are indicated with the following symbols:
 - destroy

Terraform will perform the following actions:

 # aws_instance.example will be destroyed
 - resource "aws_instance" "example" {
 - ami = "ami-0c6e5afdd23291f73" -> null
 - arn = "arn:aws:ec2:ap-northeast-2:246181472423:instance/i-00229af6743e0ba4b" -> null
 - associate_public_ip_address = true -> null
 - availability_zone = "ap-northeast-2c" -> null
 - cpu_core_count = 1 -> null
 - cpu_threads_per_core = 1 -> null
 - disable_api_stop = false -> null
 - disable_api_termination = false -> null
 - ebs_optimized = false -> null
 - get_password_data = false -> null
 - hibernation = false -> null
 - id = "i-00229af6743e0ba4b" -> null
 - instance_initiated_shutdown_behavior = "stop" -> null
 - instance_state = "running" -> null
 - instance_type = "t2.micro" -> null
 - ipv6_address_count = 0 -> null
 - ipv6_addresses = [] -> null
 - monitoring = false -> null
 - placement_partition_number = 0 -> null
 - primary_network_interface_id = "eni-06474393b32e2d8fc" -> null
 - private_dns = "ip-172-31-45-210.ap-northeast-2.compute.internal" -> null
 - private_ip = "172.31.45.210" -> null
 - public_dns = "ec2-3-39-10-27.ap-northeast-2.compute.amazonaws.com" -> null
 - public_ip = "3.39.10.27" -> null
 - secondary_private_ips = [] -> null
 - security_groups = [
 - "terraform-example",
 ] -> null
 - source_dest_check = true -> null
 - subnet_id = "subnet-03d036291a1b8a65a" -> null
 - tags = {
 - "Name" = "terraform-example"
 } -> null
 - tags_all = {
 - "Name" = "terraform-example"
 } -> null
 - tenancy = "default" -> null
 - user_data = "c765373c563b260626d113c4a56a46e8a8c5ca33" -> null
 - user_data_replace_on_change = false -> null
 - vpc_security_group_ids = [
 - "sg-057069d47b3e7f650",
 ] -> null

 - capacity_reservation_specification {
 - capacity_reservation_preference = "open" -> null
 }

 - cpu_options {
 - core_count = 1 -> null
 - threads_per_core = 1 -> null
 }

 - credit_specification {
 - cpu_credits = "standard" -> null
 }

 - enclave_options {
 - enabled = false -> null
 }

 - maintenance_options {
 - auto_recovery = "default" -> null
 }

 - metadata_options {
 - http_endpoint = "enabled" -> null
 - http_protocol_ipv6 = "disabled" -> null
 - http_put_response_hop_limit = 1 -> null
 - http_tokens = "optional" -> null
 - instance_metadata_tags = "disabled" -> null
 }

 - private_dns_name_options {
 - enable_resource_name_dns_a_record = false -> null
 - enable_resource_name_dns_aaaa_record = false -> null
 - hostname_type = "ip-name" -> null
 }

 - root_block_device {
 - delete_on_termination = true -> null
 - device_name = "/dev/sda1" -> null
 - encrypted = false -> null
 - iops = 100 -> null
 - tags = {} -> null
 - throughput = 0 -> null
 - volume_id = "vol-0f74f2dbc1d7880c1" -> null
 - volume_size = 8 -> null
 - volume_type = "gp2" -> null
 }
 }

 # aws_security_group.example will be destroyed
 - resource "aws_security_group" "example" {
 - arn = "arn:aws:ec2:ap-northeast-2:246181472423:security-group/sg-057069d47b3e7f650" -> null
 - description = "Managed by Terraform" -> null
 - egress = [] -> null
 - id = "sg-057069d47b3e7f650" -> null
 - ingress = [
 - {
 - cidr_blocks = [
 - "0.0.0.0/0",
 ]
 - description = ""
 - from_port = 8080
 - ipv6_cidr_blocks = []
 - prefix_list_ids = []
 - protocol = "tcp"
 - security_groups = []
 - self = false
 - to_port = 8080
 },
 ] -> null
 - name = "terraform-example" -> null
 - owner_id = "246181472423" -> null
 - revoke_rules_on_delete = false -> null
 - tags = {} -> null
 - tags_all = {} -> null
 - vpc_id = "vpc-089687c07f7572271" -> null
 }

Plan: 0 to add, 0 to change, 2 to destroy.

Do you really want to destroy all resources?
 Terraform will destroy all your managed infrastructure, as shown above.
 There is no undo. Only 'yes' will be accepted to confirm.

 Enter a value: yes

aws_instance.example: Destroying... [id=i-00229af6743e0ba4b]
aws_instance.example: Still destroying... [id=i-00229af6743e0ba4b, 10s elapsed]
aws_instance.example: Still destroying... [id=i-00229af6743e0ba4b, 20s elapsed]
aws_instance.example: Destruction complete after 30s
aws_security_group.example: Destroying... [id=sg-057069d47b3e7f650]
aws_security_group.example: Destruction complete after 0s

Destroy complete! Resources: 2 destroyed.

만약 특정한 리소스만 삭제하고 싶다면 tf destroy -target {리소스 타입}.{리소스 이름}을 입력하면 됩니다. 리소스 이름을 어떻게 확인하냐구요? 좋은 질문입니다! 리소스 이름은 tf state list를 입력하면 확인할 수 있습니다!

IAM 권한 제한하기

IAM에 딱 필요한 권한 허용하려면, 우선 어떤 권한이 필요한지 알아야 합니다. 그런데…. 그걸 어떻게 알 수 있을까요??

여기서 iamlive이 등장할 차례입니다!

설명보다는 iamlive 사이트에서 제공하는 예시를 한 번 보시죠.

감이 오시나요?

aws를 대상으로 뭔가 작업을 진행할 때, 그 작업에서 요구되는 IAM을 바로 확인할 수 있게 해줍니다!

iamlive 설정하기

iamlive는 homebrew등으로 직접 설치할 수도 있지만, 설치하지 않고 docker를 이용하는 방법도 있습니다.

여기서는 docker를 통해 iamlive를 실행하겠습니다. 우선, docker로 해당 이미지를 실행합니다.

> docker run \
 -p 80:10080 \
 -p 443:10080 \
 --name iamlive-test \
 -it unfor19/iamlive-docker \
 --mode proxy \
 --bind-addr 0.0.0.0:10080 \
 --force-wildcard-resource \
 --output-file "/app/iamlive.log"

처음 실행 하는 거기 때문에 이미지를 다운로드 받고 실행이 됩니다. 실행이 됐을 때 별도로 메세지가 표시되지는 않기 때문에 에러 없이 대기 상태에 있다면 정상적으로 실행된 것입니다.

만약 iamlive 컨테이너를 실행 중에 ctrl+c를 눌러서 종료하면, 다음에 실행하고 싶을 때 docker start iamlive-test를 입력하면 됩니다. 그리고 docker attach iamlive-test를 입력하면 실행 중인 컨테이너에 접속할 수 있습니다.

이제 별도로 터미널을 한 개 더 열고 다음 명령어를 실행합니다.

> docker cp iamlive-test:/home/appuser/.iamlive ~/

proxy 모드로 실행되는 iamlive에 접속하기 위한 키 파일을 프로필 루트 디렉토리로 복사했습니다. 다음 명령을 통해서 제대로 복사되었는지 확인할 수 있습니다.

> ls ./.iamlive
ca.key ca.pem

iamlive을 통해 권한 확인하기

원문에서 권장하는 방법은 권한이 하나도 없는 사용자를 만들고, 계속 명령어를 실행하면서 꼭 필요한 권한만 하나씩 복사하는 방식입니다. 그런데 이렇게 하면 필요한 권한이 많은 수록 여러번 명령을 반복적으로 실행하면서 권한을 하나씩 확인하고, 하나씩 추가해야 합니다. 꽤나 번거로운 작업이죠. 그래서 저는 그냥 어드민 권한이 있는 계정으로 테스트해서 전체 권한을 확인하고, 필요한 권한을 한 번에 할당하는 방식으로 진행하겠습니다.

앞서 작성한 코드를 대상으로 terraform apply를 실행하여 인프라를 배포합니다. 그리고 iamlive가 실행 중인 터미널을 잘 살펴보세요. 그러면 뭐가 막 지나가는 데 마지막 줄이 핵심입니다. 마지막 줄에는 다음과 같은 권한이 표시됩니다.

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action": [
 "sts:GetCallerIdentity",
 "ec2:CreateSecurityGroup",
 "ec2:DescribeSecurityGroups",
 "ec2:DescribeNetworkInterfaces",
 "ec2:DeleteSecurityGroup",
 "ec2:RevokeSecurityGroupEgress",
 "ec2:AuthorizeSecurityGroupIngress",
 "ec2:RunInstances",
 "ec2:DescribeInstances",
 "ec2:DescribeInstanceTypes",
 "ec2:DescribeTags",
 "ec2:DescribeVpcs",
 "ec2:DescribeInstanceAttribute",
 "ec2:DescribeVolumes",
 "ec2:DescribeInstanceCreditSpecifications"
 ],
 "Resource": "*"
 }
 ]
}

즉, 현재까지 작성된 terraform 코드를 실행해서 인프라를 구성하기 위해서는 이런 권한이 모두 필요하다는 거죠! 그럼 tf destroy도 바로 이어서 한 번 해볼까요? 그러면 최종적으로 이런 권한이 필요하다고 합니다.

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action": [
 "sts:GetCallerIdentity",
 "ec2:CreateSecurityGroup",
 "ec2:DescribeSecurityGroups",
 "ec2:DescribeNetworkInterfaces",
 "ec2:DeleteSecurityGroup",
 "ec2:RevokeSecurityGroupEgress",
 "ec2:AuthorizeSecurityGroupIngress",
 "ec2:RunInstances",
 "ec2:DescribeInstances",
 "ec2:DescribeInstanceTypes",
 "ec2:DescribeTags",
 "ec2:DescribeVpcs",
 "ec2:DescribeInstanceAttribute",
 "ec2:DescribeVolumes",
 "ec2:DescribeInstanceCreditSpecifications",
 "ec2:ModifyInstanceAttribute",
 "ec2:TerminateInstances"
 ],
 "Resource": "*"
 }
 ]
}

이렇게 이쁘게 표시되지는 않습니다만… JSON Formatter등의 사이트를 통해 이쁘게 변환하시면 됩니다!

네, 그럼 새로운 사용자를 만들어서 이 권한을 부여하겠습니다. 앞서 계정을 생성했던 것과 동일한 절차로 사용자 계정을 새로 생성합니다. 사용자 이름과 그룹 이름은 terraform-user로 설정하고, 그룹에는 아무런 권한을 주지 않습니다!

다시 한번 말씀드리면 그룹에는 아무런 권한을 주지 마세요!

혹시 잊으실까봐 그러는데, 액세스 키와 비밀 액세스 키는 따로 저장해두셔야 합니다.

자 그럼 그룹 설정에서 권한탭을 확인합니다. 현재 아무런 권한이 없는데요, 여기서 권한 추가 -> 인라인 정책 생성을 선택합니다.

그리고 권한 지정 페이지에서 JSON탭을 선택하고, 앞서 iamlive에서 확인한 권한을 복사해서 붙여넣습니다.

그리고 다음을 선택하고,

정책 이름을 terraform-user로 설정하고, 정책 생성을 선택합니다. 정책 생성 또는 변경 사항 저장(수정할 때)을 꼭 눌러주셔야만 반영됩니다.

자 그러면 새로 만든 유저로 동일한 코드를 실행해볼까요?

설정 파일(~/.zshrc)을 열어서 다음 내용을 새 유저의 액세스 키와 비밀 액세스 키로 변경합니다.

# 기존 유저 액세스 키
# export AWS_ACCESS_KEY_ID=...
# export AWS_SECRET_ACCESS_KEY=...
# 새 유저 액세스 키
export AWS_ACCESS_KEY_ID=...
export AWS_SECRET_ACCESS_KEY=...

그리고 변경된 설정 파일을 꼭 적용해주셔야 합니다.

> source ~/.zshrc

자 그리고 다시 apply 해봅시다!

> tf apply
...
aws_instance.example: Creating...
╷
│ Error: creating EC2 Instance: UnauthorizedOperation: You are not authorized to perform this operation. User: arn:aws:iam::246181472423:user/terraform-user is not authorized to perform: ec2:CreateTags on resource: arn:aws:ec2:ap-northeast-2:246181472423:instance/* because no identity-based policy allows the ec2:CreateTags action. Encoded authorization failure message: -Ebof-TaMnw5iPJ_dVKP00sOBTScilmv_M3-TgALYm6r48Fi4oAIxOOMWghh0LZkPXrH1yqS5XIR9dsIgCLrHl2lua-CgXDXXWc0uq-QBmKupfCnhtGx2Sdu0-IqDwlImA5bmNOIlktmOj0WUUak8G4OtphB2zL0Yi7WnfDAruVd_CHJdYrkTEIW1are7RDvgX753V5h96s9_8zn7A8KVR479FT5qLrMy3lFAN1sfauVatYkbl8EztWa9qBC7zQ7goAq682lc-A0IbGrgQ3whJMqGaLwvK3Q5kL7QyvkJ-VXe5dq58YpZnMlvsc5uH76QVKiie_tdjMy28xpQ2EmRI3nqa9-1uvGIO6-1MKhwBbAeHQdz7kgmcp2aTI2BjBurhyDxQKWUKJqQCrY7-FTx4d2xdxyBaDM-LCujL2O-oFx2NBNYYBsRKO1E22gxcSakpwNqjg8omJ8-7X-8JhBGebfT6WM4ociL1T8OxIr6JG8dEnJWRzma4feKGZVCmkLxJbHPQW0IPF3FGtGbTFyir9YALbQDPX9yUwz4_w09slZdG7y-8aWBrlrCHccmcOmm8hpsthiNJbgtjTPxjZdHNWglMiUJ8PmiazOK04QcBLv5N71icCWdogluVBsCxmehFnPNWYq3BzWSdEhLtdQIK5sokmMEY2KFsJQ32cnBg
│ status code: 403, request id: 88a0f4a9-c313-47b6-9677-7862747f9fb9
│
│ with aws_instance.example,
│ on main.tf line 7, in resource "aws_instance" "example":
│ 7: resource "aws_instance" "example" {

그런데 오류가 발생하네요..! iamlive가 ec2:CreateTags 권한을 제대로 캐치를 하지 못해서 그렇습니다. 이 권한을 계정에 추가해주고 다시 확인해보면 생성과 삭제 모두 문제 없이 진행되는 걸 확인할 수 있습니다. 물론 저 권한을 하나씩 확인하면서 추가했다면 꽤나 복잡했겠죠? 그러다가 아 ** 안해하게 됩니다. 하하하하하….개발이 다 그렇죠 뭐…

참고자료

License

저작자표시-비영리-변경금지 2.0 대한민국 (CC BY-NC-ND 2.0 KR)