T101-6주차

복습) 테라폼 사용팁 정리

 

좋은 코드의 특징

• 잘 작동함
• 관리가 쉬움
• 읽기 쉬움
• 변경이 쉬움
• 모듈화됨
• 간결함 (명확함)
• 테스트 가능함
• 효율적임
• 보기 좋음 (우아함)

 

IaC 도입의 긍정적인 측면

• 속도와 효율성
• 버전 관리
• 협업
• 재사용성
• 기술의 자산화

 

IaC 도입의 우려되는 측면

• 코드 문법 학습
• 파이프라인 통합
• 대상 인프라에 대한 이해 필요

 

테라폼 IaC 버전 관리

• 시맨틱 버전 관리 방식
  • Major 버전 : 내부 동작의 API가 변경 또는 삭제되거나 하위 호환이 되지 않는 버전
  • Minor 버전 : 신규 기능이 추가되거나 개선되고 하위 호환이 가능한 버전
  • Patch 버전 : 버그 및 일부 기능이 개선된 하위 호환이 가능한 버전
• 샘플코드 링크
  • https://registry.terraform.io/browse/providers

선언된 버전	의미	고려 사항
1.0.0	테라폼 v1.0.0만을 허용한다	테라폼을 업그레이드하기 위해서는 선언된 버전을 변경해야만 한다
>= 1.0.0	테라폼 v1.0.0 이상의 모든 버전을 허용한다	v1.0.0 버전을 포함해 그 이상의 모든 버전을 허용해 실행된다
~> 1.0.0.	테라폼 v1.0.0을 폼한한 v1.0.x 버전을 허용하고 v1.x는 허용하지 않는다	부버전에 대한 업데이트는 무중단으로 이루어진다
>=1.0, < 2.0.0	테라폼 v1.0.0 이상 v2.0.0 미만인 버전을 허용한다.	주버전에 대한 업데이트를 방지한다

terraform {
  required_providers {
    aws = {
      source = "hashicorp/aws"
      version = "~> 4.2.0"
    }
    azurerm = {
      source = "hashicorp/azurerm"
      version = ">= 2.99.0"
    }
  }
}

반복문

list 형태의 값 목록이나 Key-Value 형태의 문자열 집합인 데이터가 있는 경우 동일한 내용에 대해 테라폼 구성 정의를 반복적으로 하지 않고 관리할 수 있다.

 

• count : 반복문, 정수 값만큼 리소스나 모듈을 생성

resource "local_file" "abc" {
  count    = 5
  content  = "abc${count.index}"
  filename = "${path.module}/abc${count.index}.txt"
}

output "fileid" {
  value = local_file.abc.*.id
}

output "filename" {
  value = local_file.abc.*.filename
}

output "filecontent" {
  value = local_file.abc.*.content
}

 

• for_each : 반복문, 선언된 key 값 개수만큼 리소스를 생성
  • 리소스 또는 모듈 블록에서 for_each에 입력된 데이터 형태가 map 또는 set이면, 선언된 key 값 개수만큼 리소스를 생성하게 된다
  • 특징: key 값은 count의 index와는 달리 고유하므로 중간에 값을 삭제한 후 다시 적용해도 삭제한 값에 대해서만 리소스를 삭제한다.

variable "names" {
  default = {
    a = "content a"
    b = "content b"
    c = "content c"
  }
}

resource "local_file" "abc" {
  for_each = var.names
  content  = each.value
  filename = "${path.module}/abc-${each.key}.txt"
}

resource "local_file" "def" {
  for_each = local_file.abc
  content  = each.value.content
  filename = "${path.module}/def-${each.key}.txt"
}

조건문

• 조건식은 ? 기호를 기준으로 왼쪽은 조건이며, 오른쪽은 : 기호를 기준으로 왼쪽이 조건에 대해 true가 반환되는 경우이고 오른쪽이 false가 반환되는 경우다.
• 다음의 예에서 var.a가 빈 문자열이 아니라면 var.a를 나타내지만, 비어 있을 때는 “default-a”를 반환한다

# <조건 정의> ? <옳은 경우> : <틀린 경우>
var.a != "" ? var.a : "default-a"

명시적인 형태 작성을 권장

# 조건식 형태 권장 사항 
var.example ? 12 : "hello"            # 비권장
var.example ? "12" : "hello"          # 권장
var.example ? tostring(12) : "hello"  # 권장

 

함수

테라폼은 프로그래밍 언어적인 특성을 가지고 있어서, 값의 유형을 변경하거나 조합할 수 있는 내장 함수를 사용 할 수 있다

https://developer.hashicorp.com/terraform/language/functions

 

 

State 동기화

refresh false는 2번 과정을 생략 할 수 있다.
Plan을 하게 되면, 기본값으로 refresh 동작을 수행하면서,
리소스 생성 대상(클라우드 등)과 State를 기준으로 비교하는 과정을 거친다.
이 과정에서 State 리소스 양에 따라 속도 차이가 발생한다.
이를 실행해 빠르게 배포하고, 동기화 과정을 생략할때 사용할 수 있다.

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

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

 

• 변수 입력 방식과 우선순위
  • variable의 목적은 코드 내용을 수정하지 않고 테라폼의 모듈적 특성을 통해 입력되는 변수로 재사용성을 높이는 데 있다.
  • 특히 입력 변수라는 명칭에 맞게 사용자는 프로비저닝 실행 시에 원하는 값으로 변수에 정의할 수 있다.
  • 선언되는 방식에 따라 변수의 우선순위가 있으므로, 이를 적절히 사용해 로컬 환경과 빌드 서버 환경에서의 정의를 다르게 하거나, 프로비저닝 파이프라인을 구성하는 경우 외부 값을 변수에 지정할 수 있다.
  • https://spacelift.io/blog/terraform-tfvars

 

gitignore 정의

• .terraform 디렉터리 : init 실행 시 작성되므로 제외
• .tfstate 파일 : 프로비저닝 결과 데이터 소스 정보, 민감 데이터가 포함
  • 백엔드 사용 필요
• tfvars 파일 : 프로비저닝 시 적용할 변수 값을 보관하는 파일로, 작업자 마다 별도 변수 사용
• 시크릿 파일 : 인프라 구성에 필요한 시크릿 정보 파일
• terraformrc 파일 : 작업자의 CLI 설정 파일
• 사이트
  • https://www.toptal.com/developers/gitignore

 

워크플로

개인 워크플로

• Write : 프로비저닝하려는 목적에 따라 테라폼 코드를 작성
  • 개인 작업이더라도 반복적인 사용성을 고려
  • 복잡하게 작성하여 가독성을 줄이는 행위는 지
• Plan : 적용하기 위한 실행 계획을 통해 리뷰
  • 테라폼의 Plan뿐 아니라, terraform fmt를 통해 코드 형태를 포멧팅하고 변경되는 리소스를 리뷰한다.
  • 또한 테라폼과 함께 동작하는 tfsec이나 terrascan 같은 보안 취약성 점검 툴 등을 활용하는 것도 좋은 방안이다.
• Apply : 코드로 실제 인프라를 프로비저닝
  • 실행 계획상으로는 정상이지만 실제 프로비저닝하는 단계에서 인수 값, 생성 순서, 종속성에 따라 오류가 발생할 수 있다.
  • 성공적인 완료를 위해 Write > Plan > Apply 단계를 반복하고 성공하는 경우 코드 관리를 위해 VCS에 코드를 병합한다.

 

다중 작업자 워크플로

• Write
  • VCS와 같은 형상관리 도구에 익숙해져야 한다.
  • 작업자는 작업 전에 미리 원격 저장소의 코드를 받고(Pull) 깃에서는 브랜치를 활용해 개별적으로 작업한다.
  • 개인의 워크플로에서 고려한 변수화와 더불어 패스워드와 인증서 같은 민감 데이터가 포함되지 않도록 코드를 설계한다. 또한 개인 작업 환경에서만 사용되는 변수는 공유하지 않는다.
    • 작업자 개인의 변수는 terraform.tfvars 에 선언
    • .gitignore에 추가해 개별적으로 테스트할 수 있는 환경을 구성할 수 있다
  • 개별 작업 환경과 별개로 병합되는 코드가 실제 운영 중인 인프라에 즉시 반영되면 실행 후 발생할 오류 예측이 어려워 부담이 될 수 있다.
    • 이를 보완하기 위해 프로비저닝 대상의 환경을 검증과 운영, 또는 그 이상의 환경으로 구성 가능하도록 구조화한다.
    • 이때 사용하는 방식은 디렉터리 기반 격리와 깃 기반의 브랜치 격리다.
• Plan
  • 둘 이상의 작업자는 프로비저닝 이전에 팀원 간 리뷰를 거쳐 변경된 내역을 확인하고 공통 저장소에 병합해야 한다.
  • 리뷰 단계에서는 추가, 삭제, 수정된 내역을 관련 작업자가 검증, 질의, 배움의 단계를 거쳐 복기함으로써 코드 상태를 개선 유지하고 작업자 간에 의도를 공유한다.
  • 코드 자체 외에도 테라폼의 Plan 결과를 풀 리퀘스트 단계에 같이 제공하면 영향을 받는 리소스와 서비스 중단에 대한 예측이 더 쉬워진다.
  • CI 툴과 연계하거나 Terraform Cloud/Enterprise의 VCS 통합 기능으로 자동화할 수 있다.
• Apply
  • 코드가 최종 병합되면 인프라 변경이 수행됨을 알리고 변경되는 대상 환경의 중요도에 따라 승인이 필요할 수 있다.
  • 또한 변경하는 코드가 특정 기능, 버그 픽스, 최종 릴리즈를 위한 병합인가에 따라 이 단계에 추가로 코드 병합이 발생할 수 있다.
  • 관리하는 단위를 나누는 기준은 조직 R&R, 서비스, 인프라 종류 등으로 구분된다.

 

다수 팀의 워크플로

• Write
  • 대상 리소스가 하나의 모듈에서 관리되지 않고 R&R에 의해 워크스페이스가 분리된다.
  • 서로 다른 워크스페이스에서 구성된 리소스 데이터를 권한이 다른 팀에게 공유하기 위해, 저장된 State 접근 권한을 제공하고 output을 통해 공유 대상 데이터를 노출한다.
  • 테라폼 코드 작성 시 다른 워크스페이스에서의 변경 사항을 데이터 소스로 받아 오는 terraform_remote_state 또는 별도 KV-store를 활용하는 코드 구성이 요구된다.
  • 또한 관리 주체가 다른 곳에서 생긴 변경 사항의 영향을 최소화하도록 리모트 데이터 소스의 기본값을 정의하거나 코드적인 보상 로직을 구현하는 작업이 필요하다.
• Plan
  • 코드 기반으로 진행되는 리뷰는 반영되는 다른 팀의 인프라를 VCS상의 코드 리뷰만으로도 공유받고 영향도를 검토할 수 있다.
  • 병합을 승인하는 단계에 영향을 받는 다른 팀의 작업자도 참여해야 한다.
• Apply
  • 프로비저닝 실행과 결과에 대한 안내가 관련 팀에 알려져야 하므로 파이프라인 구조에서 자동화하는 것을 추천한다.
  • 실행 후의 영향도가 여러 팀이 관리하는 리소스에 전파될 수 있으므로 코드 롤백 훈련이 필요하다.
  • 생성된 결과에 다른 워크스페이스에서 참조되는 output 값의 업데이트된 내용을 다른 팀이 확인하는 권한 관리가 필요하다