Terraform Associate 004 #6 모듈: 소스 지정, 버전 고정, 입출력 문법

인프라 Terraform IaC 자격증
4 분 소요

모듈 영역은 범위가 좁은 대신 문항 밀도가 높습니다. 소스 지정 문법, version이 되는 경우와 안 되는 경우, 출력 접근 문법이라는 세 덩어리가 반복해서 나옵니다. 기초 #8의 내용을 시험 각도로 압축하겠습니다.

정의: 모든 설정은 이미 모듈 안입니다 #

시험이 기대하는 정의는 이렇습니다. 모듈은 함께 쓰이는 리소스들을 담은 설정 파일의 컨테이너(디렉터리)이고, 테라폼을 실행하는 디렉터리가 루트 모듈, module 블록으로 불러오는 것이 자식 모듈입니다. “모듈을 쓰지 않는 설정"이라는 표현은 성립하지 않습니다. 어떤 설정이든 루트 모듈이기 때문입니다. 이 프레이밍(“모든 설정은 최소 하나의 모듈을 갖는다”)이 그대로 출제됩니다.

소스 지정: 세 가지 방식 #

module 블록의 source는 문자열 형식에 따라 위치가 해석됩니다.

main.tf 
# 1. 레지스트리: <네임스페이스>/<이름>/<프로바이더> 형식
module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "~> 6.0"
}

# 2. Git: 접두사로 판별, ref로 버전 지정
module "app" {
  source = "git::https://github.com/my-org/tf-app.git?ref=v1.2.0"
}

# 3. 로컬 경로: ./ 또는 ../ 로 시작
module "network" {
  source = "../modules/network"
}

시험 포인트는 version 인수가 동작하는 조건입니다. version은 레지스트리 소스에서만 유효합니다. Git 소스의 버전은 URL의 ref 쿼리로, 로컬 경로는 버전 개념 없이 그 시점의 파일로 결정됩니다. “로컬 모듈에 version을 지정한다"는 선택지는 오답이고, 레지스트리 모듈에 version을 생략하면 최신을 받아 재현성이 깨진다는 것(기초 #8의 “version 고정 필수”)이 정답 방향입니다. 그리고 모듈을 추가·변경하면 init이 필요하다는 것도 여기 묶이는 단골입니다.

입력과 출력: 모듈의 인터페이스 #

  • 입력: 자식 모듈이 선언한 variable에 module 블록의 인수로 값을 넣습니다.
  • 출력: 자식 모듈이 선언한 output만 module.<이름>.<출력이름>으로 읽을 수 있습니다.
main.tf 
module "network" {
  source   = "../modules/network"
  vpc_cidr = "10.0.0.0/16"          # 입력: 모듈의 variable로
}

resource "aws_instance" "web" {
  subnet_id = module.network.private_subnet_id   # 출력: module.이름.출력
}

여기서 시험이 노리는 원칙이 캡슐화입니다. 호출자는 자식 모듈 안의 리소스에 직접 접근할 수 없습니다. module.network.aws_subnet.private.id 같은 주소는 성립하지 않으며, 모듈이 output으로 내보낸 값만 읽을 수 있습니다. “모듈 안 값이 필요한데 output이 없다면?“의 답은 모듈에 output을 추가하는 것입니다. 반대 방향(모듈이 호출자의 값을 읽는 것)도 variable을 통해서만 가능합니다.

퍼블릭 레지스트리: 검증 표시와 문서 #

Terraform Registry의 퍼블릭 모듈 관련 출제 포인트는 가볍게 두 가지입니다. HashiCorp가 파트너를 검증한 모듈에는 verified 표시가 붙는다는 것, 그리고 레지스트리 페이지가 입력·출력·의존성 문서와 사용 예를 제공하므로 모듈 평가는 그 문서로 한다는 것입니다. “verified가 아닌 모듈은 사용할 수 없다"는 취지의 선택지는 오답입니다. 표시는 신뢰 참고 정보이지 사용 제한이 아닙니다.

모듈 설계 상식 문항 #

설계 원칙을 묻는 문항의 정답 방향도 기초 #8의 기준과 일치합니다. 함께 만들고 함께 사라지는 리소스 묶음을 모듈로 하고, 리소스 하나를 감싼 얇은 포장 모듈은 피하며, 입력은 필요한 만큼만 열어 인터페이스를 좁게 유지합니다. 트랙에서 실습한 실전 #9의 modules·envs 구조가 이 원칙들의 실물 예시라, 그 구조를 떠올리면 대부분의 설계 문항이 풀립니다.

정리 #

이번 글에서 다룬 내용입니다.

  • 실행 디렉터리가 루트 모듈, module 블록으로 부르는 것이 자식 모듈이며, 모든 설정은 최소 하나의 모듈입니다
  • 소스는 레지스트리 형식, git:: 접두사, ./·../ 로컬 경로로 판별됩니다
  • version 인수는 레지스트리 소스 전용입니다. Git은 ref, 로컬은 버전 개념이 없습니다. 모듈 변경 후에는 init입니다
  • 모듈은 캡슐화됩니다. 안의 리소스 직접 접근은 불가하고 output으로 내보낸 값만 module.이름.출력으로 읽습니다
  • verified 표시는 신뢰 참고이지 사용 제한이 아닙니다

다음 글(#7 설정 작성)에서는 변수와 출력, 함수와 표현식, 그리고 004에서 강화된 커스텀 조건(validation, precondition, postcondition)을 다룹니다. 트랙에서 얕게 지나간 부분의 보강이 있는 편입니다.

X