📌 Notice

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

출처 - 한빛출판네트워크

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

📌 달성하고자 하는 목적은 무엇인가요?
DevOps 엔지니어로서 업무에서 활발하게 사용하고 있는 테라폼에 대해서 놓쳤던 부분이나 기초를 다시한번 다듬으며, 업무 역량을 늘리고자 합니다.

📌 Summary

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

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

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

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

📌 Study

👉 Step 01. 1장 IaC와 테라폼

테라폼이란?
하시코프사에서 공개한 IaC 도구
‘하시코프의 철학 - 링크’ 중 3가지를 담아서 테라폼을 설계 : 워크플로우에 집중, 코드형 인프라, 실용주의

테라폼 제공 유형

1. On-premise : Terraform이라 불리는 형태로, 사용자의 컴퓨팅 환경에 오픈소스 바이너리툴인 테라폼을 통해 사용
2. Hosted SaaS : Terraform Cloud로 불리는 SaaS로 제공되는 구성 환경으로 하시코프가 관리하는 서버 환경이 제공
3. Private Install : Terraform Enterprise로 불리는 서버 설치형 구성 환경으로, 기업의 사내 정책에 따라 프로비저닝 관리가 외부 네트워크와 격리 - 링크

👉 Step 02. 2장 실행 환경 구성

✅ 2.1 테라폼 환경 구성

실행 환경 구성(3가지) :

• 미리 빌드된 바이너리(실행) 파일 다운로드
• 테라폼 소스 코드 다운로드 후 빌드
• OS 패키지 관리자 활용

버전 선택 : 가장 최선 버전 권장 - 하위 버전 호환, 기능 개선, 버그 수정

• 빌드된 바이너리 네이밍 규칙 : terraform_<버전>_<OS>_<CPU>.zip

PATH 설정 : 리눅스/macOS , 윈도우

• 리눅스 : /usr/bin
• 윈도우 : C:\\windows\\system32

참고 : BSL 라이센스 적용은 Terraform 1.5.x 이후부터 적용됩니다. (일반 사용자는 제한되지 않으니 염려하지 않고 사용하셔도 됩니다❗️)

✅ 2.2 IDE 구성

통합 개발 환경 IDE는 비주얼 스튜디오 코드 Visual Studio Code (VS Code)를 설치 후 실습에 사용 - 링크

• Extentions (확장) 설치
  • HashiCorp HCL : syntax highlighting for HCL files - 링크
  • HashiCorp Terraform : Highlighting syntax from Terraform 등 - 링크
• VS Code에서 터미널 윈도우 추가(단축키: `Ctrl+``)

✅ 2.3 (참고) CLI 구성 파일 ← skip

• CLI 구성 파일로, 테라폼 동작 설정 가능 - 링크
  • 윈도우 : 사용자의 %APPDATA% 디렉터리의 terraform.rc 파일
  • 나머지 OS : 사용자 홈 디렉터리의 .terraformrc 파일
  • 파일 내에서 사용 가능한 설정 값
    • credentials: Terraform Cloud 또는 Terraform Enterprise와 연동을 위한 인증 정보 설정
    • credentials_helper: 테라폼에서 Terraform Cloud/Enterprise를 위한 자격증명을 얻기 위해 사용자 지정 방식을 사용하도록 선언 (예를 들어 macOS의 키체인에 저장)
    • disable_checkpoint: true로 설정하면 하시코프의 네트워크 서비스에서 업그레이드 및 보안 검사를 비활성화
    • disable_checkpoint_signature: true인 경우 하시코프의 네트워크 서비스에서 업그레이드 및 보안 검사는 수행하지만, 경고 메시지 중복 제거에 사용되는 익명 ID 사용을 비활성화
    • plugin_cache_dir: terraform init 수행 시 다운로드하는 플러그인의 캐싱을 활성화하고 지정된 디렉터리를 캐시 위치로 지정 → 활용 시 프로바이더의 다운로드 시간되 디스크 공간을 줄일 수 있음
      
    • provider_installation: 프로바이더 플러그인을 설치하는 terraform init 수행 시 동작을 재정의 → 활용 시 인터넷이 단절된 환경에서 프로바이더에 대한 로컬 위치를 지정할 수 있음 - 링크
      

👉 Step 03. 3장 기본 사용법

✅ 3.1 주요 커맨드

‘help’ 옵션(참고)

# 서브커맨드 help 지원
terraform console -help
terraform init -help

init 초기화

# 테라폼 실행을 위해 코드 파일이 있는 디렉터리로 이동
# (참고) 테라폼이 실행되는 디렉터리 = 모듈(테라폼 코드 파일과 변수 파일), 기본 작업디렉터리는 '루트 모듈', 호출 모듈은 '자식 모듈'
cd 03.start/

# plan 실행 시 에러 출력 > 에러 메시지의 의미는?
terraform plan
│ Error: Inconsistent dependency lock file
│
│ The following dependency selections recorded in the lock file are inconsistent with the current configuration:
│   - provider registry.terraform.io/hashicorp/local: required by this configuration but no version is selected
│
│ To make the initial dependency selections that will initialize the dependency lock file, run:
│   terraform init

# 초기화 : 코드 사용 구문 기반으로 필요한 프로바이더 플러그인을 찾고 설치, 추가로 '프로바이더/모듈/백엔드' 구성 설정/변경 시 수행 필요
terraform init
ls -al
tree .terraform  # VS Code에서 탐색기 확인

plan 계획 & apply 실행

• terraform plan 명령은 테라폼으로 적용할 인프라의 변경 사항에 관한 실행 계획을 생성하는 동작. 또한 출력되는 결과를 확인하여 어떤 변경이 적용될지 사용자가 미리 검토하고 이해하는데 도움을 줌.

• 변경 사항을 실제로 적용하지는 않으므로, 적용 전에 예상한 구성이 맞는지 검토

• terraform apply 는 plan 계획을 기반으로 작업을 실행.

# plan 실행 : 구성 내용을 바탕으로 어떤 리소스가 생성되는지 상세 내역 출력, 기본값 자동 입력 적용
terraform 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:

  # local_file.abc will be created
  + resource "local_file" "abc" {
      + content              = "abc!"
      + content_base64sha256 = (known after apply)
      + content_base64sha512 = (known after apply)
      + content_md5          = (known after apply)
      + content_sha1         = (known after apply)
      + content_sha256       = (known after apply)
      + content_sha512       = (known after apply)
      + directory_permission = "0777"
      + file_permission      = "0777"
      + filename             = "./abc.txt"
      + id                   = (known after apply)
    }

Plan: 1 to add, 0 to change, 0 to destroy. # 하나의 리소스가 추가되고, 변경되거나 삭제되는 것은 없을 예정

-detailed-exitcode : plan 추가 옵션으로, 파이프라인 설계에서 활용 가능, exitcode가 환경 변수로 구성됨

-auto-approve 자동 승인 기능 부여 옵션

# plan 결과를 시스템 코드로 출력
terraform plan -detailed-exitcode
...

# 코드 확인 : 0(변경 사항이 없는 성공), 1(오류가 있음), 2(변경 사항이 있는 성공)
echo $?
2

# (참고) apply 결과에 적용 시도
terraform apply -auto-approve -detailed-exitcode

apply

# apply 실행 : no 입력
terraform apply
...
Enter a value: no
...

# plan 결과를 지정된 파일(바이너리 형태) 이름으로 생성
terraform plan -out=tfplan
cat tfplan
file tfplan

# apply 실행 : 실행계획이 있으므로 즉시 적용됨
terraform apply tfplan
ls -al abc.txt

# apply 실행 : 어떻게 되나요?
# 테라폼은 선언적 구성 관리를 제공하는 언어로 멱등성 idempotence을 갖고, 상태를 관리하기 때문에 동일한 구성에 대해서는 다시 실행하거나 변경하는 작업을 수행하지 않음
terraform apply
...

terraform state list

코드 파일 수정

resource "local_file" "abc" {
content = "abc!"
filename = "${path.module}/abc.txt"
}

resource "local_file" "dev" {
  content  = "def!"
  filename = "${path.module}/def.txt"
}

실행

# apply 실행 : 변경(신규 추가) 부분만 반영 확인
terraform apply
...
# local_file.dev will be created
  + resource "local_file" "dev" {
...
Enter a value: yes

# 확인
terraform state list
tree
ls *.txt

# 변경 이전의 실행 계획 적용 시도 > 어떻게 될까요?
terraform apply tfplan
...

다시 추가 코드 내용을 삭제

resource "local_file" "abc" {
content = "abc!"
filename = "${path.module}/abc.txt"
}

실행
테라폼은 선언전으로 동작하기 때문에 현재의 코드 상태와 적용할 상태를 비교해 일치시키는 동작을 수행

# 실행 > 어떻게 되나요?
terraform apply
...
Enter a value: yes
...

# 확인
terraform state list
tree
ls *.txt

-replace : 프로비저닝이 완료 후 사용자에 필요에 의해 특정 리소스를 삭제 후 다시 생성. plan, apply 모두 적용 가능

destroy 제거 & fmt
테라폼 구성에서 관리하는 모든 개체를 제거하는 명령어 ← 일부 리소스만 제거하려면 어떻게 해야 될 까요?

#
terraform destroy
...
Enter a value: yes
...

# 확인
terraform state list
ls *.txt

fmt
format 또는 reformat 줄임 표시로 terraform tmt 명령어로 수행, 테라폼 구성 파일을 표준 형식과 표준 스타일로 적용. 코드 가독성 높임

# 적용 후 코드 파일 내용 확인 -> 들여쓰기 확인
terraform fmt

✅ 3.2 HCL

HCL HashiCorp Configuration Language은 하시코프사에서 IaC와 구성 정보를 명시하기 위해 개발된 오픈 소스 도구

HCL 특징

• IaC는 수동 프로세스가 아닌 코드를 통해 인프라를 관리하고 프로비저닝 하는 것을 말함
• 테라폼에서 HCL이 코드의 영역을 담당한다. HCL은 쉽게 읽을 수 있고 빠르게 배울 수 있는 언어의 특징을 가진다.
• 인프라가 코드로 표현되고, 이 코드는 곧 인프라이기 때문에 선언적(declarative) 특성을 갖게 되고 튜링 완전한 Turing-complete 언어적 특성을 갖는다. [참고: 튜링완전]
• 즉, 일반적인 프로그래밍 언어의 조건문 처리 같은 동작이 가능하다. 자동화와 더불어, 쉽게 버저닝해 히스토리를 관리하고 함께 작업 할 수 있는 기반을 제공.
• HCL에서 변수와 문자열 값을 함께 사용하는 인터폴레이션 interpolation 표현 방식을, JSON을 사용하는 다른 IaC 도구와 비교

HCL을 사용하는 이유

• JSON과 YAML 은 기계 친화적인 언어로 제작.
• HCL은 JSON으로 표현하는 것보다 더 간결하고 읽기 쉽게 작성할 수 있다. (JSON 대비 50~70% 간결하게 작성가능)
• JSON은 구문이 길어지고 주석이 지원되지 않는다는 단점이 있음.

✅ 3.3 테라폼 블록

테라폼 블록 : 테라폼 구성을 명시하는 데 사용

• 테라폼 버전이나 프로바이더 버전과 같은 값들은 자동으로 설정되지만, 함께 작업할 때는 버전을 명시적으로 선언하고 필요한 조건을 입력하여 실행 오류를 최소화 할 것을 권장한다. [Docs] [Docs 예제]
• 오늘 실행하던, 3년 후에 실행하던 동일한 결과를 얻을 수 있어야 한다! (Desired State + Immutable)

terraform {
  required_version = "~> 1.3.0" # 테라폼 버전

  required_providers { # 프로바이더 버전을 나열
    random = {
      version = ">= 3.0.0, < 3.1.0"
    }
    aws = {
      version = "4.2.0"
    }
  }

  cloud { # Cloud/Enterprise 같은 원격 실행을 위한 정보 [참고: Docs]
    organization = "<MY_ORG_NAME>"
    workspaces {
      name = "my-first-workspace"
    }
  }

  backend "local" { # state를 보관하는 위치를 지정 [참고: Docs, local, remote, s3]
    path = "relative/path/to/terraform.tfstate"
  }
}

• 테라폼 내에서 버전이 명시되는 terraform, module에서 사용 가능하며 버전에 대한 제약을 둠으로써 테라폼, 프로바이더, 모듈이 항상 의도한 정의대로 실행되는 것을 목적으로 한다.
• 버전 체계는 시맨틱 버전 관리 Semantic Versioning(SemVer) 방식을 따른다 [참고], [Kubernetes Release Versioning]

시맨틱 버전 관리 방식

• Major 버전 : 내부 동작의 API가 변경 또는 삭제되거나 하위 호환이 되지 않는 버전

• Minor 버전 : 신규 기능이 추가되거나 개선되고 하위 호환이 가능한 버전

• Patch 버전 : 버그 및 일부 기능이 개선된 하위 호환이 가능한 버전

• 버전 제약 구문은 다른 프로그램 언어에서의 종속성 관리 시스템과 흡사하다.
  • = 또는 연산자 없음 : 지정된 버전만을 허용하고 다른 조건과 병기할 수 없다.
  • != : 지정된 버전을 제외한다.
  • >, >=, <, <= : 지정된 버전과 비교해 조건(부등호)에 맞는 경우 허용한다.
    • ~> : 지정된 버전에서 가장 자리수가 낮은 구성요소만 증가하는 것을 허용한다.
      • ~> x.y 인 경우 y 버전에 대해서만, ~> x.y.z인 경우 z 버전에 대해서만 보다 큰 버전을 허용한다.

백엔드 블록

• 백엔드 블록의 구성은 테라폼 실행 시 저장되는 State(상태 파일)의 저장 위치를 선언한다. (기본: local)
• 주의할 점은 하나의 백엔드만 허용한다는 점이다.
• 테라폼은 State의 데이터를 사용해 코드로 관리된 리소스를 탐색하고 추적한다.
• 작업자 간의 협업을 고려한다면 테라폼으로 생성한 리소스의 상태 저장 파일을 공유할 수 있는 외부 백엔드 저장소가 필요하다.
• 그리고 State에는 외부로 노출되면 안 되는 패스워드 또는 인증서 정보 같은 민감한 데이터들이 포함될 수 있으므로 State의 접근 제어 및 안전한 관리방안 대책수립이 필요하다.

State 잠금 동작

• 기본적으로 활성화되는 백엔드는 local이다.
• 상태를 작업자의 로컬 환경에 저장하고 관리하는 방식이다.
• 이 밖의 다른 백엔드 구성은 동시에 여러 작업자가 접근해 사용할 수 있도록 공유 스토리지 같은 개념을 갖는다.
• 공유되는 백엔드에 State가 관리되면 테라폼이 실행되는 동안 .terraform.tfstate.lock.info 파일이 생성되면서 해당 State를 동시에 사용하지 못하도록 잠금 처리를 한다.
• 파일 생성을 확인하고 싶다면 terraform apply를 실행하고 생성되는 잠금 파일을 확인해보자. 잠금 파일 내의 정보는 다음과 같다.

🧩 Assignment

👉 AWS S3/DynamoDB 백엔드

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를 확인할 수 있습니다.

📌 Reference

• why hashicorp? - links
• terraform docs - links