Terraform 상태파일 격리

변재한·2023년 5월 11일

terraform

상태 파일 격리

개발 환경의 인프라, 운영 환경의 인프라

모든 환경을 하나의 테라폼 구성 세트(하나의 테라폼 파일, 같은 폴더에 들어있는 테라폼 파일 세트)로 정의하는 경우

하나의 환경에서 문제가 생기더라도 다른 환경에 영향을 주지 않도록 각 환경을 구분, 격리하는 방법은 2가지가 존재

1. 작업 공간을 통한 격리

Terraform Workspace 사용

테라폼은 작업 공간을 따로 지정하지 않으면 기본 작업 공간(default)을 사용한다.

작업 공간을 만들거나 작업 공간 전환 시 아래 명령어 사용.

$ terraform workspace

실습

S3, DynamoDB 설정을 마치고 아래 코드 apply

resource "aws_instance" "jaehan-example" {
  ami = "ami-04cebc8d6c4f297a3"
  instance_type = "t2.micro"
}

apply 후 현재 작업 공간 확인

default 확인

backend 확인

test1 작업 공간 생성

이후, plan 명령어를 실행하면 default 공간의 상태파일을 사용, 참조하지 않으므로 처음부터 생성하려고 함.

다음으로 아래의 명령어 수행

$ tf apply 
$ tf workspace new test2
$ tf apply
$ tf workspace list

S3 bucket 상황

default 작업공간은 workspace에

test1, test2 작업공간은 env:에

test1 폴더 속

더 나아가서..

작업공간을 이용해 아래와 같은 테라폼 코드도 짤 수 있다.

작업공간별로 instance_type 구분 적용.

resource "aws_instance" "jaehan-example" {
  ami = "ami-04cebc8d6c4f297a3"
  **instance_type = terraform.workspace == "default" ? "t2.medium" : "t2.micro"**
}

파일 레이아웃을 이용한 격리

레이아웃이란?

서비스도 개발과 운영으로 나누듯 인프라도 개발과 운영을 분리해서 관리한다.

인프라 환경을 구분하게 됨에 따라 테라폼 코드도 구조를 만들어서 관리해야 한다.

이 때, 구조를 레이아웃이라고 부른다.

파일 레이아웃 예제

이전에 했었던 ALB 실습을 사용하여 다음과 같이 간단하게 레이아웃을 구성하였다.

인프라 환경에 따른 구분 - develop, stage

global - s3 & dynamodb

이렇게 테라폼 코드를 레이아웃 즉 구조를 정립하여 구성하였을 시에 다음과 같은 장점이 있다!

코드를 쉽게 탐색 가능
각 환경에 어떤 구성 요소가 배포되었는지 정확하게 확인가능
환경 내 구성요소 간 적절한 격리로 인한 문제 발생시 전체 인프라에 영향 감소

But, 아래와 같은 단점도 존재한다!

한 번의 명령으로 모든 인프라 배포 불가
리소스 종속성을 사용하기 어려움
- 예를 들어, 위의 develop 폴더에 db라는 데이터베이스 코드가 담긴 폴더가 있는 경우 service 폴더에서 db의 리소스에 직접 액세스 불가!
  
  ⇒ terraform_remote_state로 해결가능!

terraform_remote_state

상태 작업 시 유용한 terraform_remote_state

⇒ 다른 테라폼 구성 세트에 읽기 전용 방식으로 저장된 테라폼 상태 파일 가져올 수 있음!

아래와 같이 data 블록으로 다른 상태정보저장소의 상태파일을 읽어올 수 있음!

data "terraform_remote_state" "db" {
  backend = "s3"

  config = {
    profile = "example"
    bucket = "terraform-jaehan-state"
    key = "development/db/terraform.tfstate"
    region = "ap-northeast-2"
   }
}