테라폼 개인 프로젝트 - Terraform workflow 구성하기

Terraform Cloud + Github

 

Terraform을 사용하는데 협업하여 사용하는데 있어서 가장 중요한 것 중 하나는 Terraform state 관리입니다.

 

 

GitLab의 경우에는 Terraform Steate 파일을 따로 관리할 수 있는 managed service를 제공하고 있지만, Github의 경우에는 그렇지 않기에, 따로 관리를 해주어야 합니다.

 

 

보통은 Terraform state 관리를 위해 AWS S3 + DynamoDB를 Terraform backend로 활용하지만, 이번에는 좀더 빠르고 쉽게 구성해보기 위해 Terraform Cloud를 이용하여 Terraform의 관리를 해보려고 합니다.

 

 

Terraform Cloud 설정

 

Terraform Cloud에 접속하여, 회원이 아니라면 회원가입을, 회원이라면 로그인을 진행합니다.

 

https://app.terraform.io/session

https://app.terraform.io/session

 

github 레포지토리 생성 및 테라폼 코드 push

 

프로젝트 구조 및 코드

├── dev
│   ├── main.tf
│   └── variables.tf
└── prod
    ├── main.tf
    └── variables.tf

 

dev/main.tf

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

provider "aws" {
    region = var.region
}

resource "aws_s3_bucket" "example" {
  bucket = "wath1457-tf-example-bucket"
  tags = {
    Name = "dev"
  }
}

resource "aws_s3_bucket_ownership_controls" "example" { # acl 제어를 위해 요구됨
  bucket = aws_s3_bucket.example.id
  rule {
    object_ownership = "BucketOwnerPreferred"
  }
}

resource "aws_s3_bucket_acl" "example" {
  depends_on = [aws_s3_bucket_ownership_controls.example]

  bucket = aws_s3_bucket.example.id
  acl    = "private"
}

 

dev/variables.tf

variable "region" {
    type = string
    description = "AWS region"
    default = "ap-northeast-2"
}

 

prod/main.tf

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

provider "aws" {
    region = var.region
}

resource "aws_s3_bucket" "example" {
  bucket = "wath1457-tf-example-bucket"
  tags = {
    Name = "prod"
  }
}

resource "aws_s3_bucket_ownership_controls" "example" { # acl 제어를 위해 요구됨
  bucket = aws_s3_bucket.example.id
  rule {
    object_ownership = "BucketOwnerPreferred"
  }
}

resource "aws_s3_bucket_acl" "example" {
  depends_on = [aws_s3_bucket_ownership_controls.example]

  bucket = aws_s3_bucket.example.id
  acl    = "private"
}

 

prod/variables.tf

variable "region" {
    type = string
    description = "AWS region"
    default = "ap-northeast-2"
}

 

 

Create organization

팀과 함께 공유되어 사용되는 공간 / workspace 관리

 

 

Create workspace

테라폼 작업공간 / 하나의 organization에 여러 개의 workspace가 존재할 수 있습니다.

 

 

github 레포지토리에 저장된 코드와 통합할 것이므로, Version Control Workflow를 선택합니다.

 

terraform cloud와 연동할 레포지토리를 선택합니다.

 

workspace settings

마지막으로 workspace 설정을 진행합니다.

 

다음은 주요 설정입니다.

Terraform working directory : terraform 명령어가 실행될 디렉토리. 즉, 루트 디렉토리를 의미합니다.

Auto-apply : terraform apply 명령어의 --auto-approve 역할을 하는 옵션
└── Auto-apply run triggers : source workspace에서 apply가 성공하면, 다른 workspace의 plan-apply를 실행하는 옵션
예시) 워크스페이스 A: 네트워크 구성 변경 (예: VPC 또는 Subnet을 추가)
워크스페이스 B: 네트워크 변경을 사용하는 애플리케이션 배포 (예: EC2 인스턴스나 RDS 배포)
-> 의존성 있는 workspace

Automatic Run triggering : 항상 terraform 명령어를 실행할 것인지, 레포지토리의 특정 path가 변경되는 경우에만 실행할 것인지

Automatic speculative plans : Pull Requests시에, terraform plan 명령 실행 여부

Include submodules on clone : Terraform이 레포지토리를 clone할때, 서브모듈까지 포함하여 clone할 것인지 여부
* Git 서브모듈은 하위 리포지토리 를 메인 프로젝트 리포지토리의 하위 디렉토리로 포함시킬 수 있는 Git의 기능입니다.

 

위 사진과 설명을 참고하여 dev 환경에 대한 설정과 prod 환경에 대한 workspace 생성을 진행합니다.

 

 

Configure variables

테라폼 코드 내에서 변수를 관리하는 것이 아닌, Terraform cloud에서 변수를 관리할 수 있는 기능을 제공합니다. gitlab을 사용해보신 분이라면 아실 수 있는 CI Variables와 유사한 기능이라고 생각하시면 될 것 같습니다.

 

region variable은 다음과 같이 생성합니다.

 

 

AWS 관련 secret과 같이 민감정보는 아래와 같이 생성합니다.

 

위와 같이 variables를 직접 생성해 주어도 되고, Terraform cloud에서는 worksapce에 종속적인 변수뿐만 아니라, organization 전체, 혹은 특정 workspace가 공유하는 variable sets을 생성할 수 있습니다.

 

우선 workspace 레벨로 다시 돌아가서, 좌측 패널의 Settings - variable sets - Add Variable을 통해 위와 동일한 방법으로 variable을 추가하여 variable sets를 생성합니다.

 

저는 아래와 같이 생성하였습니다.

 

 

만약 먼저 동일한 key를 가진 variable을 vairable sets가 적용된 workspace에 생성하셨다면, 다음과 같이 overwritten이 되었다는 것을 보실 수 있습니다.

 

이는 동일한 key를 가진 varialbe에 대한 우선순위가 존재하기 때문입니다.

 

 

우선순위는 아래의 공식문서를 참고하시길 바랍니다.

https://developer.hashicorp.com/terraform/cloud-docs/workspaces/variables#3-priority-workspace-scoped-variable-sets

Workspace variables in HCP Terraform | Terraform | HashiCorp Developer

 

Variable sets의 Variable을 생성하였을때, Prioritize the variables in this set 옵션을 체크해주지 않았기 때문에, 저희가 생성한 variables set의 variables가 workspace의 variable에 overwritten된 것입니다.

 

따라서, 기존 variable을 생성하였다면, 지워주시길 바랍니다.

 

모든 variables setting을 마친 결과는 다음과 같을 것입니다.

 

 

terraform apply

workspace ui에서 수동으로 terraform apply를 수행할 수 있습니다.

 

 

혹은 workspace 설정에서 VCS(Version Control System)에 대한 설정을 Branch-based로 설정하였기에, VCS branch로 설정한 branch의 변경사항이 발생하면, terraform apply가 실행됩니다.

 

 

VSC branch로 설정한 main(default branch)에 변경사항이 발생하였기에, terraform apply가 실행된 것을 확인할 수 있습니다.

(terraform apply 실행 전, terraform plan이 진행된 모습)

 

아직 해당 Run이 완료되지 않은 상태에서, ui에서 수동으로 추가 Run을 실행하려고 하면, terraform state가 lock이 걸려있는 상태이므로, 후속 Run은 Pending상태에 빠지게 됩니다.

 

 

Runs 상세 정보에서 해당 커밋, 레포지토리 정보 및 plan을 통해 어떤 리소스가 생성될지 보기 쉬운 ui에서 확인하실 수 있습니다.

 

Maintainer가 confirm후 apply를 진행시킬 수 있습니다.

 

이전 Run이 완료되었으므로, ui에서 실행시킨 중복된 Run이 실행되지만, 변경 사항이 없으므로 Plan 이후에 Apply가 진행되지 않습니다.

 

AWS 콘솔에서 테라폼 코드처럼 ap-northeast-1 (도쿄) 리전에 s3 버킷이 생성된 것을 확인할 수 있습니다.

 

terraform destroy

terraform destroy 역시 terraform cloud ui에서 실행 가능하며, workspace - settings - Destruction and Deletion 탭에서 가능합니다.

Queue destroy plan 버튼을 통해 manual하게 destroy를 진행해 보겠습니다.

 

 

Destroy전에 한번 더 확인하기 위해 workspace 이름을 입력하여야 terraform destroy가 실행됩니다.

 

 

Runs 목록에 destroy run이 올라가게 되고, apply를 진행했던 동일한 방법으로 destroy plan 이후 실제 리소스를 지우는 terraform destroy를 실행할 수 있습니다.

 

 

apply와 동일한 방법으로 confirm 후에 destroy apply가 실행되며, apply 진행중에는 취소가 가능합니다.

 

 

마지막으로 destroy가 진행되어 실제 리소스가 제거되었는지 확인합니다.

 

---

 

이번 포스팅에서는 terraform cloud를 이용하여 terraform state 관리 및 ui를 활용한 terraform 워크플로우 구축 + github를 이용한 코드 버전관리를 진행해 보았습니다.

 

terraform cloud가 생각보다 강력한 통합 기능 및 편의성을 제공하기에 쉽게 terraform 관리 워크플로우 구성 및 통합이 가능했습니다.

또한, Hashicorp사에서 제공하는 솔루션인만큼, 공식 문서가 잘 되어있고, 강력한 통합 기능을 제공한다는 장점이 있습니다.

 

빠르게 팀에서 terraform을 구성하거나 state관리 및 상태 추적이 필요한 경우, terraform cloud를 사용하는 것을 추천드릴 수 있을 것 같습니다.