📌 Notice

본 블로깅은 아래의 24단계 실습으로 정복하는 쿠버네티스 책을 기준하여 정리하였습니다.

출처 - 한빛출판네트워크

CloudNetaStudy 그룹에서 스터디한 내용입니다.
Hashicorp korea 유형욱님과 함께 스터디 하고 있습니다. 🙏
유형욱님과 윤서율님께 다시한번 🙇 감사드립니다.

📌 Summary

• IaC와 테라폼을 이해하고 스터디에 필요한 실습 환경을 구성합니다.

• 테라폼 기본 명령 사용법을 알아봅니다.

• HCL을 이해하고 기본 활용 방법을 학습합니다.

• 샘플코드 작성 및 배포를 실습합니다.

📌 Study

👉 Step 01. 5장 State

✅ 5.1 State의 목적과 의미

테라폼은 Stateful 애플리케이션. 프로비저닝 결과 State를 저장하고 추적에 활용

개인 1인 : 로컬 환경으로 terraform.tfstate 파일에 JSON 형태로 저장

팀이나 조직 : 공동 관리를 위해 원격 저장소에 저장해 공유 - 링크

State에는 작업자가 정의한 코드와 실제 반영된 프로비저닝 결과를 저장하고, 이 정보를 토대로 이후의 리소스 생성, 수정, 삭제에 대한 동작 판단 작업을 수행

State 역할

• State에는 테라폼 구성과 실제를 동기화하고 각 리소스에 고유한 아이디(리소스 주소)로 맵핑
• 리소스 종속성과 같은 메타데이터를 저장하고 추적
• 테라폼 구성으로 프로비저닝 결과를 캐싱하는 역할을 수행

테라폼에서는 JSON 형태로 작성된 State를 통해 속성과 인수를 읽고 확인할 수 있다.

테라폼에서는 type과 name으로 고유한 리소스를 분류하며, 해당 리소스의 속성과 인수를 구성과 비교해 대상 리소스를 생성, 수정, 삭제한다.

State는 테라폼만을 위한 API로 정의할 수도 있다. Plan을 실행하면 암묵적으로 refresh 동작을 수행하면서 리소스 생성의 대상(클라우드 등)과 State를 기준으로 비교하는 과정을 거친다.

이 작업은 프로비저닝 대상의 응답 속도와 기존 작성된 State의 리소스 양에 따라 속도 차이가 발생한다.

대량의 리소스를 관리해야 하는 경우 Plan 명령에서 -refresh=false 플래그를 사용해 State를 기준으로 실행 계획을 생성하고, 이를 실행에 활용해 대상 환경과의 동기화 과정을 생략할 수 있다.

# 실행 계획 생성 시 저장되어 있는 State와 실제 형상을 비교하는 기본 실행
time terraform plan

# 실행 계획 생성 시 실제 형상과 비교하지 않고 실행 계획을 생성하는 -refresh=false 옵션
time terraform plan -refresh=false

✅ 5.2 State 동기화

테라폼 구성 파일은 기존 State와 구성을 비교해 실행 계획에서 생성, 수정, 삭제 여부를 결정한다.

테라폼 구성과 State 흐름 : Plan 과 Apply 중 각 리소스에 발생할 수 있는 네 가지 사항, 아래 실행 계획 출력 기호와 의미

Replace 동작은 기본값을 삭제 후 생성하지만 lifecycle의 create_before_destroy 옵션을 통해 생성 후 삭제 설정 가능

✅ 5.3 워크스페이스

State를 관리하는 논리적인 가상 공간을 워크스페이스라고 한다.

테라폼 구성 파일은 동일하지만 작업자는 서로 다른 State를 갖는 실제 대상을 프로비저닝할 수 있다.

워크스페이스는 기본 default로 정의된다.

로컬 작업 환경의 워크스페이스 관리를 위한 CLI 명령어로 workspace가 있다.

terraform workspace list
* default

장점

• 하나의 루트 모듈에서 다른 환경을 위한 리소스를 동일한 테라폼 구성으로 프로비저닝하고 관리
• 기존 프로비저닝된 환경에 영향을 주지 않고 변경 사항 실험 가능
• 깃의 브랜치 전략처럼 동일한 구성에서 서로 다른 리소스 결과 관리 - [참고 : 화해 - Git 브랜치 전략 수립을 위한 전문가의 조언들]

단점

• State가 동일한 저장소(로컬 또는 백엔드)에 저장되어 State 접근 권한 관리가 불가능(어려움)
• 모든 환경이 동일한 리소스를 요구하지 않을 수 있으므로 테라폼 구성에 분기 처리가 다수 발생 가능
• 프로비저닝 대상에 대한 인증 요소를 완벽히 분리하기 어려움
  → 가장 큰 단점은 완벽한 격리가 불가능
  ⇒ 해결방안 1. 해결하기 위해 루트 모듈을 별도로 구성하는 디렉터리 기반의 레이아웃을 사용할 수 있다.
  ⇒ 해결방안 2. Terraform Cloud 환경의 워크스페이스를 활용

👉 Step 02. 6장 Module

테라폼으로 인프라와 서비스를 관리하면 시간이 지날수록 구성이 복잡해지고 관리하는 리소스가 늘어나게 된다.

테라폼의 구성 파일과 디렉터리 구성에는 제약이 없기 때문에 단일 파일 구조상에서 지속적으로 업데이트할 수 있지만, 다음과 같은 문제가 발생한다.

• 테라폼 구성에서 원하는 항목을 찾고 수정하는 것이 점점 어려워짐
• 리소스들 간의 연관 관계가 복잡해 질수록 변경 작업의 영향도를 분석하기 위한 노력이 늘어남
• 개발/스테이징/프로덕션 환경으로 구분된 경우 비슷한 형태의 구성이 반복되어 업무 효율이 줄어듦
• 새로운 프로젝트를 구성하는 경우 기존 구성에서 취해야 할 리소스 구성과 종속성 파악이 어려움

모듈은 루트 모듈과 자식 모듈로 구분된다.

• 루트 모듈 Root Module : 테라폼을 실행하고 프로비저닝하는 최상위 모듈
• 자식 모듈 Child Module : 루트 모듈의 구성에서 호출되는 외부 구성 집합

모듈은 테라폼 구성의 집합이다.

테라폼으로 관리하는 대상의 규모가 커지고 복잡해져 생긴 문제를 보완하고 관리 작업을 수월하게 하기 위한 방안으로 활용

• 관리성 : 모듈은 서로 연관 있은 구성의 묶음이다. 원하는 구성요소를 단위별로 쉽게 찾고 업데이트할 수 있다. 모듈은 다른 구성에서 쉽게 하나의 덩어리로 추가하거나 삭제할 수 있다. 또한 모듈이 업데이트되면 이 모듈을 사용하는 모든 구성에서 일관된 변경 작업을 진행할 수 있다.
• 캡슐화 : 테라폼 구성 내에서 각 모듈은 논리적으로 묶여져 독립적으로 프로비저닝 및 관리되며, 그 결과는 은닉성을 갖춰 필요한 항목만을 외부에 노출시킨다.
• 재사용성 : 구성을 처음부터 작성하는 것에는 시간과 노력이 필요하고 작성 중간에 디버깅과 오류를 수정하는 반복 작업이 발생한다. 테라폼 구성을 모듈화하면 이후에 비슷한 프로비저닝에 이미 검증된 구성을 바로 사용할 수 있다.
• 일관성과 표준화 : 테라폼 구성 시 모듈을 활용하는 워크플로는 구성의 일관성을 제공하고 서로 다른 환경과 프로젝트에도 이미 검증한 모듈을 적용해 복잡한 구성과 보안 사고를 방지할 수 있다.

✅ 6.1 모듈 작성 기본 원칙

기본 원칙 : 모듈은 대부분의 프로그래밍 언어에서 쓰이는 라이브러리나 패키지와 역할이 비슷하다

아래와 같은 기본 작성 원칙을 제안함

모듈 디렉터리 형식을 terraform-<프로바이더 이름>-<모듈 이름> 형식을 제안한다.

이 형식은 Terraform Cloud, Terraform Enterprise에서도 사용되는 방식으로

1) 디렉터리 또는 레지스트리 이름이 테라폼을 위한 것이고, 2) 어떤 프로바이더의 리소스를 포함하고 있으며, 3) 부여된 이름이 무엇인지 판별할 수 있도록 한다.

테라폼 구성은 궁극적으로

모듈화가 가능한 구조로 작성할 것을 제안한다.
처음부터 모듈화를 가정하고 구성파일을 작성하면 단일 루트 모듈이라도 후에 다른 모듈이 호출할 것을 예상하고 구조화할 수 있다. 또한 작성자는 의도한 리소스 묶음을 구상한 대로 논리적인 구조로 그룹화할 수 있다.

각각의 모듈을 독립적으로 관리하기를 제안한다.
리모트 모듈을 사용하지 않더라도 처음부터 모듈화가 진행된 구성들은 때로 루트 모듈의 하위 파일 시스템에 존재하는 경우가 있다. 하위 모듈 또한 독립적인 모듈이므로 루트 모듈 하위에 두기보다는 동일한 파일 시스템 레벨에 위치하거나 별도 모듈만을 위한 공간에서 불러오는 것을 권장한다. 이렇게 하면 VCS를 통해 관리하기가 더 수월하다.

공개된 테라폼 레지스트리의 모듈을 참고 하기를 제안한다.
대다수의 테라폼 모듈은 공개된 모듈이 존재하고 거의 모든 인수에 대한 변수 처리, 반복문 적용 리소스, 조건에 따른 리소스 활성/비활성 등을 모범 사례로 공개해두었다. 물론 그대로 가져다 사용하는 것보다는 프로비저닝하려는 상황에 맞게 참고하는 것을 권장한다.

작성된 모듈은 공개 또는 비공개로 게시해 팀 또는 커뮤니티와 공유하기를 제안한다.
모듈의 사용성을 높이고 피드백을 통해 더 발전된 모듈을 구성할 수 있는 자극이 된다.

✅ 6.2 모듈화 해보기

모듈의 기본적 구조는 테라폼 구성으로 입력 변수를 구성하고 결과를 출력하기 위한 구조로 구성한다.

‘모듈화’라는 용어는 이런 구조를 재활용하기 위한 템플릿 작업을 말한다.

애플리케이션 개발시에도 자주 사용되는 용어로 테라폼은 작성된 모듈을 다른 루트 모듈에서 가져다 사용하며 이를 통해 재사용성과 표준화 구조를 구성할 수 있다.

기존에 작성된 모듈은 다른 모듈에서 참조해 사용할 수 있다. 사용 방식은 리소스(Resource)와 비슷하다.

모듈에서 필요한 값은 variable로 선언해 설정하고, 모듈에서 생성된 값 중 외부 모듈에서 참조하고 싶은 값은 output으로 설정한다. 마치 자바 개발 시 getter, setter로 캡슐화된 클래스를 활용하는 것과 비슷하다.

✅ 6.3 모듈 사용 방식

모듈에서 사용되는 모든 리소스는 관련 프로바이더의 정의가 필요하다. 여기서 사용자는 프로바이더 정의를 모듈 안 or 밖 고민

유형 1. 자식 모듈에서 프로바이더 정의
모듈에서 사용하는 프로바이더 버전과 구성 상세를 자식 모듈에서 고정하는 방법이다.

프로바이더 버전과 구성에 민감하거나, 루트 모듈에서 프로바이더 정의 없이 자식 모듈이 독립적인 구조일 때 고려할 방법이다

하지만 동일한 프로바이더가 루트와 자식 양쪽에 또는 서로 다른 자식 모듈에 버전 조건 합의가 안 되면, 오류가 발생하고 모듈에 반복문을 사용할 수 없다는 단점이 있으므로 잘 사용하지 않는다.

유형 2. 루트 모듈에서 프로바이더 정의(실습)
자식 모듈은 루트 모듈의 프로바이더 구성에 종속되는 방식이다.

디렉터리 구조로는 분리되어 있지만 테라폼 실행 단계에서 동일 계층으로 해석되므로 프로바이더 버전과 구성은 루트 모듈의 설정이 적용된다.

프로바이더를 모듈 내 리소스와 데이터 소스에 일괄 적용하고, 자식 모듈에 대한 반복문 사용에 자유로운 것이 장점이다.

자식 모듈에 특정 프로바이더 구성의 종속성은 반영할 수 없으므로 자식 모듈을 프로바이더 조건에 대해 기록하고, 자식 모듈을 사용하는 루트 모듈에서 정의하는 프로바이더에 맞게 업데이트 해야 한다.

🧩 Assignment

👉 도전과제 1

목표 - T101 1기 노션 내용에 AWS DynamoDB/S3를 원격 저장소로 사용하는 실습을 따라해보세요!

Backend 구성을 통해 Terraform이 state 데이터 파일을 저장하는 위치를 정의 할수 있습니다.

테라폼은 tfstate를 이용하여 현재 선언한 리소스를 추적합니다.

tfstate에는 중요한 정보도 포함되기 때문에, Github 또는 외부로 노출되어있는 코드 저장소에 올라가지 않도록 주의하여야 합니다.

이를 위해 aws 서비스인 S3와 DynamoDB를 이용해서 백엔드를 구축할 수 있습니다.

🔥 S3 및 DynamoDB로 백엔드를 관리할때의 장점

• 완전 관리형 서비스이므로 운영 부담이 발생하지 않습니다.
• 현재 GitOps로 관리하고자 하는 인프라 역시 AWS 리소스를 주로 사용할 예정이므로 별도의 관리 포인트가 추가 되지 않습니다.

📕 Backend

별도의 워크스페이스를 생성하여 백엔드를 위한 리소스를 별로도 생성합니다.

# backend.tf

provider "aws" {
  region = "ap-northeast-2" # Please use the default region ID
}

# S3 버킷을 생성합니다.
resource "aws_s3_bucket" "for_tfstate" {
  bucket = "xgro-tfstate"
}

# S3 버킷의 버저닝 기능 활성화 선언한다.
resource "aws_s3_bucket_versioning" "tfstate" {
  bucket = aws_s3_bucket.for_tfstate.bucket

  versioning_configuration {
    status = "Enabled"
  }
}

# DynamoDB for terraform state lock
resource "aws_dynamodb_table" "terraform_state_lock" {
  name         = "terraform-lock"
  hash_key     = "LockID"
  billing_mode = "PAY_PER_REQUEST"

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

📘 Workspace

위에서 백엔드를 위한 S3, DynamoDB가 정상적으로 생성되었다면, 테스트를 위한 테라폼 프로젝트를 생성합니다.

# main.tf

# Required providers configuration
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 4.6.0"
    }
  }

  backend "s3" {
    bucket         = "xgro-tfstate"
    key            = "terraform.tfstate"
    region         = "ap-northeast-2"
    dynamodb_table = "terraform-lock"
    encrypt        = true
  }

  required_version = ">= 1.0.11"
}

data "aws_region" "current" {}
data "aws_caller_identity" "current" {}

테스트는 vpc 모듈을 이용해서 리소스의 이름 및 설정을 변경하며 진행하였습니다.

# vpc.tf

module "vpc" {
  source = "terraform-aws-modules/vpc/aws"

  name = "final_mon1-vpc"
  cidr = "10.0.0.0/16"

  azs             = ["ap-northeast-2a", "ap-northeast-2b"]
  private_subnets = ["10.0.101.0/24", "10.0.102.0/24"]
  public_subnets  = ["10.0.1.0/24"]

  enable_nat_gateway = false
  enable_vpn_gateway = false
  tags = {
    Terraform   = "true"
    Environment = "dev"
  }
}

terraform.tfstate 파일이 s3에 저장되는것을 확인할 수 있습니다.

테라폼으로 생성된 vpc를 확인할 수 있습니다.

👉 도전과제 2

목표 - 테라폼 레지스트리에 공개된 모듈을 사용하여 리소스를 배포해보세요!

VPC 모듈을 사용하여 리소스를 생성합니다.

module "vpc" {
  source = "terraform-aws-modules/vpc/aws"

  name = "t1013-xgro-vpc"
  cidr = "10.0.0.0/16"

  azs             = ["ap-northeast-2a", "ap-northeast-2b", "ap-northeast-2c"]
  private_subnets = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
  public_subnets  = ["10.0.101.0/24", "10.0.102.0/24", "10.0.103.0/24"]

  enable_nat_gateway = false
  enable_vpn_gateway = false

  tags = {
    Terraform = "true"
    Environment = "dev"
  }
}

결과

📌 Reference

• why hashicorp? - links
• terraform docs - links