variable "isDB" {
type = bool
default = false
description = "패스워드 대상의 DB 여부"
}
output.tf 파일 작성
output "id" {
value = random_pet.name.id
}
output "pw" {
value = nonsensitive(random_password.password.result)
}
자식 모듈 동작 테스트
# 파일 확인 및 초기화
ls *.tf
terraform init && terraform plan
# 테스트를 위해 apply 시 변수 지정
terraform apply -auto-approve -var=isDB=true
# 리소스 목록 출력
terraform state list
# 특정 리소스의 상세 정보 출력
terraform state show random_pet.name
# 콘솔에서 특정 리소스의 속성 값을 조회
echo "random_pet.name.id" | terraform console
echo "random_pet.name.keepers" | terraform console
# 특정 리소스의 상세 정보 출력
terraform state show random_password.password
# 콘솔에서 특정 리소스의 속성 값을 조회
echo "random_password.password.length" | terraform console
echo "random_password.password.special" | terraform console
# state 파일에서 특정 정보를 추출
cat terraform.tfstate | grep result
cat terraform.tfstate | grep module
# Graph 확인
terraform graph > graph.dot
자식 모듈 호출 실습
다수의 리소스를 동일한 목적으로 여러 번 사용해야 하는 경우, 각 리소스를 개별적으로 정의하고 고유한 이름을 지정해야 하는 번거로움이 있습니다.
하지만 모듈을 활용하면 이러한 반복되는 리소스 묶음을 최소화할 수 있습니다.
디렉터리 생성 및 파일 생성
mkdir -p 06-module-traning/06-01-basic
cd 06-module-traning/06-01-basic
touch main.tf
# 초기화 및 적용
terraform init && terraform plan && terraform apply -auto-approve
# 리소스 목록 출력
terraform state list
# state 파일에서 특정 정보를 추출 : module
cat terraform.tfstate | grep module
# 디렉터리 구조를 트리 형식으로 출력 : modules.json 파일 확인
tree .terraform
# 모듈로 묶여진 리소스는 module 정의를 통해 쉽게 재활용하고 반복 사용할 수 있다.
# 모듈의 결과는 module.<모듈 이름>.<output 이름> 형식으로 참조하여 사용할 수 있다.
cat .terraform/modules/modules.json | jq
# Graph 확인
terraform graph > graph.dot
6.3 모듈 사용 방식
모듈과 프로바이더
모듈에서 사용되는 모든 리소스는 관련 프로바이더의 정의를 필요로 합니다. 여기서 프로바이더를 어디(자식 or 루트)에 정의할지에 대한 고민이 필요합니다.
[유형 1] 자식 모듈에서 프로바이더 정의
프로바이더 구성을 자식 모듈에서 직접 정의하는 방식입니다.
프로바이더 구성에 민감한 경우나 자식 모듈이 독립적인 구조를 가질 때 유용합니다.
그러나 루트 모듈과 자식 모듈 사이 혹은 서로 다른 자식 모듈 간의 프로바이더 버전이 일치하지 않으면 오류가 발생할 수 있고 반복문을 사용할 수 없다는 단점 때문에 이 방식은 일반적으로 권장되지 않습니다.
[유형 2] 루트 모듈에서 프로바이더 정의
루트 모듈에서 정의된 프로바이더 구성이 자식 모듈에게도 적용되는 방식입니다.
디렉터리가 분리되어 있어도 테라폼 실행 시 모든 모듈이 동일 계층으로 해석되므로 루트 모듈의 프로바이더 설정이 자식 모듈에도 적용됩니다.
이 구조는 리소스와 데이터 소스에 일관된 프로바이더를 적용하며, 자식 모듈을 반복적으로 사용할 때 유연성을 제공합니다.
자식 모듈은 특정 프로바이더 구성에 종속될 수 없기 때문에 자식 모듈의 프로바이더 요구사항을 문서화하고 루트 모듈에서 정의된 프로바이더 설정에 맞춰 자식 모듈을 업데이트해야 합니다.
동일한 모듈에 다양한 프로바이더 조건을 적용할 필요가 있을 때 각 모듈별로 프로바이더를 맵핑하는 방식을 사용할 수 있습니다.
리소스와 데이터 소스에 provider 메타인수를 지정하는 기존 방식과 비슷하지만 모듈에 여러 프로바이더가 사용될 가능성을 고려하여 map 타입으로 provider 를 정의합니다.
디렉터리 생성 및 파일 생성
mkdir -p 06-module-traning/modules/terraform-aws-ec2/
cd 06-module-traning/modules/terraform-aws-ec2/
touch main.tf variable.tf output.tf
output "module_output_singapore" {
value = module.ec2_singapore.private_ip
}
output "module_output_seoul" {
value = module.ec2_seoul.private_ip
}
실행 및 확인
# 초기화
terraform init
# 모듈의 세부 정보 출력
cat .terraform/modules/modules.json | jq
# 리소스 배포
terraform apply -auto-approve
# output.tf 파일에 정의된 모든 출력 변수의 값 출력
terraform output
# 리소스 목록 출력
terraform state list
# 특정 리소스의 상세 정보 출력
terraform state show module.ec2_seoul.data.aws_ami.default
terraform state show module.ec2_singapore.data.aws_ami.default
# state 파일에서 특정 정보를 추출 : module
cat terraform.tfstate | grep module
# Graph 확인
terraform graph > graph.dot
# CLI를 통한 EC2 인스턴스 확인
aws ec2 describe-instances --region ap-northeast-2 --query "Reservations[*].Instances[*].{PublicIPAdd:PublicIpAddress,InstanceName:Tags[?Key=='Name']|[0].Value,Status:State.Name}" --filters Name=instance-state-name,Values=running --output text
aws ec2 describe-instances --region ap-southeast-1 --query "Reservations[*].Instances[*].{PublicIPAdd:PublicIpAddress,InstanceName:Tags[?Key=='Name']|[0].Value,Status:State.Name}" --filters Name=instance-state-name,Values=running --output text
# 실습 완료 후 리소스 정리
terraform destroy -auto-approve
자식 모듈이 요구하는 프로바이더 버전이 루트 모듈에서 지정한 버전과 다를 경우, 호환성 문제로 오류가 발생할 수 있습니다.
모듈의 반복문
모듈도 리소스처럼 반복문을 사용하여 구성할 수 있습니다.
반복문을 사용함으로써 원하는 수량만큼 리소스 정의 묶음인 모듈을 프로비저닝할 수 있으며, 이는 모듈을 사용하지 않는 구성에 비해 리소스 종속성 관리와 유지 보수에서 큰 장점을 제공합니다.
리소스에서 사용하는 방식과 유사하게 모듈 블록 내에서 count를 선언하여 반복문을 사용합니다.
디렉터리생성 및 파일 생성
mkdir -p 06-module-traning/module_loop_count/
cd 06-module-traning/module_loop_count/
touch main.tf
# 초기화
terraform init
# 모듈의 세부 정보 출력
cat .terraform/modules/modules.json | jq
# 리소스 배포
terraform apply -auto-approve
# output.tf 파일에 정의된 모든 출력 변수의 값 출력
terraform output
# 리소스 목록 출력
terraform state list
# state 파일에서 특정 정보를 추출 : module
cat terraform.tfstate | grep module
# Graph 확인
terraform graph > graph.dot
# CLI를 통한 EC2 인스턴스 확인
aws ec2 describe-instances --region ap-northeast-2 --query "Reservations[*].Instances[*].{PublicIPAdd:PublicIpAddress,InstanceName:Tags[?Key=='Name']|[0].Value,Status:State.Name}" --filters Name=instance-state-name,Values=running --output text
# 실습 완료 후 리소스 정리
terraform destroy -auto-approve
위와 같이 모듈 묶음이 일관된 구성과 구조로 프로비저닝될 경우 count는 간편하게 사용할 수 있는 방안입니다.
하지만 동일한 모듈 구성에 필요한 인수 값이 다를 경우 for_each를 사용하는 것이 더 적합합니다.
예를 들어, 동일한 모듈을 사용하여 개발 환경과 상용 환경에 대한 입력 변수를 다르게 처리하는 실습을 통해 이 개념을 더 깊이 이해할 수 있습니다.
main.tf 파일 수정
locals {
env = {
dev = {
type = "t3.micro"
name = "dev_ec2"
}
prod = {
type = "t3.medium"
name = "prod_ec2"
}
}
}
module "ec2_seoul" {
for_each = local.env
source = "../modules/terraform-aws-ec2"
instance_type = each.value.type
instance_name = each.value.name
}
output "module_output" {
value = [
for k in module.ec2_seoul: k.private_ip
]
}
실행 및 확인
# 계획
terraform plan
# 리소스 배포
terraform apply -auto-approve
# output.tf 파일에 정의된 모든 출력 변수의 값 출력
terraform output
# 리소스 목록 출력
terraform state list
# state 파일에서 특정 정보를 추출 : module
cat terraform.tfstate | grep module
# Graph 확인
terraform graph > graph.dot
# CLI를 통한 EC2 인스턴스 확인
aws ec2 describe-instances --region ap-northeast-2 --query "Reservations[*].Instances[*].{PublicIPAdd:PublicIpAddress,InstanceName:Tags[?Key=='Name']|[0].Value,Status:State.Name}" --filters Name=instance-state-name,Values=running --output text
# 실습 완료 후 리소스 정리
terraform destroy -auto-approve
6.4 모듈 소스 관리
모듈 소스 관리
테라폼 init 명령어를 사용할 때 정의된 모듈 소스 위치를 바탕으로 필요한 모듈을 다운로드하게 됩니다. 모듈 소스를 지정하는 방법은 여러 가지가 있습니다
로컬 디렉터리 경로
테라폼 레지스트리
깃허브
비트버킷
깃
HTTP URLs
S3 Bucket
GCS Bucket
로컬 디렉터리 경로
테라폼 레지스트리와 구분하기 위해 하위 디렉터리는 ./로 시작하고, 상위 디렉터리는 ../로 시작합니다.
해당 모듈은 이미 같은 파일 시스템에 존재하기 때문에 별도의 다운로드 과정이 필요 없습니다.
모듈이 재사용 가능하도록 설계되었다면 상위 디렉터리에 모듈을 별도로 관리하는 것이 좋습니다. 반면 모듈이 특정 루트 모듈과 밀접하게 연관되어 동작해야 할 경우는 하위 디렉터리에 모듈을 배치하는 것이 바람직합니다.
# 초기화
terraform init
# 아래 디렉터리에 깃허브에 있던 파일이 다운로드 되어 있음을 확인
tree .terraform/modules
# 리소스 배포
terraform apply -auto-approve
# 리소스 목록 출력
terraform state list
# 실습 완료 후 리소스 정리
terraform destroy -auto-approve
