[Terraform] Module (모듈 작성 및 호출, 모듈 소스 관리)

💡cloudNet@ 팀의 가시다 님이 진행하는 Terraform 101 Study 4기 5주차 내용으로,
[테라폼으로 시작하는 IaC] 도서를 참조하였습니다. 감사합니다..

 

Module

테라폼으로 인프라와 서비스를 관리하면 시간이 지날수록 구성이 복잡해지고 관리하는 리소스가 늘어나게 된다. 테라폼의 구성 파일과 디렉터리 구성에는 제약이 없기 때문에 단일 파일 구조상에서 지속적으로 업데이트 할 수 있지만 다음과 같은 문제가 발생한다.

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

 

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

 

1. 모듈 작성 기본 원칙

모듈은 대부분의 프로그래밍 언어에서 쓰는 라이브러리나 패키지와 역할이 비슷하다. 모듈 작성 방식은 사용자마다 다를 수 있지만 다음과 같은 기본 작성 원칙을 제안한다.

• 모듈 디렉터리 형식을 terraform-<프로바이더 이름>-<모듈 이름> 형식을 제안한다.
• 테라폼 구성은 궁극적으로 모듈화가 가능한 구조로 작성할 것을 제안한다.
  (처음부터 모듈화를 가정하고 구성파일을 작성하면 단일 루트 모듈이라도 후에 다른 모듈이 호출할 것을 예상하고 구조화할 수 있다.)
• 각각의 모듈을 독립적으로 관리하기를 제안한다.
• 공개된 테라폼 레지스트리의 모듈을 참고한다. 물론 그대로 가져다 사용하는 것보다는 프로비저닝하려는 상황에 맞게 참고하는 것을 권장한다.

모듈을 독립적으로 관리하기 위해 디렉터리 구조를 생성할 때 모듈을 위한 별도 공간을 생성하는 방식으로 진행한다. 특정 루트 모듈 하위에 자식 모듈을 구성하는 경우 단순히 복잡한 코드를 분리하는 요도로 명시되며 종속성이 발생하므로 루트 모듈 사이에 모듈 디렉터리를 지정한다.

사진-1

 

 

2. 모듈화해보기

모듈화 소개

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

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

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

모듈에서 필요한 값은 variable로 선언해 설정하고 모듈에서 생성된 값 중 외부 모듈에서 참조하고 싶은 값은 output으로 설정한다.

이전 기본 사용법 포스팅에서도 설명했듯, 자바 개발 시 getter, setter로 캡슐화된 클래스를 활용하는 것과 비슷하다.

 

 

모듈 작성 실습

하나의 프로비저닝에서 사용자와 패스워드를 여러 번 구성해야 하는 경우를 가상의 시나리오로 삼아 모듈화를 진행해보겠다.

• random_pet는 이름을 자동으로 생성하고, random_password는 사용자의 패스워드를 설정한다.
• random_password는 random 프로바이더 리소스로 난수 형태로 패스워드를 만들 수 있다.

 

자식 모듈 작성

다음과 같이 main.tf, variable.tf, output.tf 파일을 생성한다.

# **main.tf**
resource "random_pet" "name" {
  keepers = {
    ami_id = timestamp()
  }
}

resource "random_password" "password" {
  length           = var.isDB ? 16 : 10
  special          = var.isDB ? true : false
  override_special = "!#$%*?"
}

# **variable.tf**
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) 
}

 

 

테스트를 위해 terraform init를 수행하고 apply를 수행할 때 변수를 지정한다.

terraform init && terraform plan

# 테스트를 위해 apply 시 변수 지정
**terraform apply -auto-approve -var=isDB=true**

사진-2

사진-3

 

 

자식 모듈 호출 실습

다수의 리소스를 같은 목적으로 여러 번 반복해서 사용하려면 리소스 수만큼 반복해 구성 파일을 정의해야 하고 이름도 고유하게 설정해줘야 하는 부담이 있지만, 모듈을 활용하면 반복되는 리소스 묶음을 최소화할 수 있다.

다음과 같이 main.tf 파일을 다른 디렉터리에 생성한다.

module "mypw1" {
  source = "../modules/terraform-random-pwgen"
}

module "mypw2" {
  source = "../modules/terraform-random-pwgen"
  isDB   = true
}

output "mypw1" {
  value  = module.mypw1
}

output "mypw2" {
  value  = module.mypw2
}

 

 

이제 init와 apply를 실행하여 자식 모듈을 호출해 반복 재사용하는 루트 모듈의 결과를 확인해보겠다.

사진-4

사진-5

 

 

terraform init를 실행 시 modules.json이 생성되는 것을 확인할 수 있다.

사진-6

 

 

모듈로 묶여진 리소스는 module이라는 정의를 통해 단순하게 재활용하고 반복 사용할 수 있다.
모듈의 결과 참조 형식은 module.<모듈 이름>.<output 이름>으로 정의된다.

사진-7

 

 

3. 모듈 사용 방식

모듈 사용 시 프로바이더 정의와 반복문 처리에 대해 확인해보겠다.

 

모듈과 프로바이더

모듈에서 사용되는 모든 리소스는 관련 프로바이더의 정의가 필요하다. 여기서 사용자는 프로바이더 정의를 모듈 안에 두어야 할지 밖에 두어야 할지 구성을 고민할 수 있다.

 

유형 1. 자식 모듈에서 프로바이더 정의

모듈에서 사용하는 프로바디어 버전과 구성 상세를 자식 모듈에서 고정한다.

• 프로바이더 버전과 구성에 민감하거나, 루트 모듈에서 프로바이더 정의 없이 자식 모듈이 독립적인 구조일 때 고려할 방법이다
• 하지만 동일한 프로바이더가 루트와 자식 양쪽에 또는 서로 다른 자식 모듈에 버전 조건 합의가 안 되면, 오류가 발생하고 모듈에 반복문을 사용할 수 없다는 단점이 있으므로 잘 사용하지 않는다.

 

유형 2. 루트 모듈에서 프로바이더 정의

자식 모듈은 루트 모듈의 프로바이더 구성에 종속되는 방식이다.

• 디렉터리 구조로는 분리되어 있지만 테라폼 실행 단계에서 동일 계층으로 해석되므로 프로바이더 버전과 구성은 루트 모듈의 설정이 적용된다.
• 자식 모듈을 프로바이더 조건에 대해 기록하고, 자식 모듈을 사용하는 루트 모듈에서 정의하는 프로바이더에 맞게 업데이트 해야 한다.

 

실습을 위해 다음과 같이 파일을 작성한다.

# **main.tf**
terraform {
  required_providers {
    aws = {
      source = "hashicorp/aws"
    }
  }
}

resource "aws_default_vpc" "default" {}

data "aws_ami" "default" {
  most_recent = true
  owners      = ["amazon"]

  filter {
    name   = "owner-alias"
    values = ["amazon"]
  }

  filter {
    name   = "name"
    values = ["amzn2-ami-hvm*"]
  }
}

resource "aws_instance" "default" {
  depends_on    = [aws_default_vpc.default]
  ami           = data.aws_ami.default.id
  instance_type = var.instance_type

  tags = {
    Name = var.instance_name
  }
}

**# variable.tf**
variable "instance_type" {
  description = "vm 인스턴스 타입 정의"
  default     = "t2.micro"
}

variable "instance_name" {
  description = "vm 인스턴스 이름 정의"
  default     = "my_ec2"
}

# **output.tf**
output "private_ip" {
  value = aws_instance.default.private_ip
}

 

 

 

작성된 모듈을 사용할 루트(부모) 모듈 파일 작성

**# main.tf**
provider "aws" {
  region = "ap-southeast-1"  
}

provider "aws" {
  alias  = "seoul"
  region = "ap-northeast-2"  
}

module "ec2_singapore" {
  source = "../modules/terraform-aws-ec2"
}

module "ec2_seoul" {
  source = "../modules/terraform-aws-ec2"
  providers = {
    aws = aws.seoul
  }
  instance_type = "t3.small"
}

**# output.tf**
output "module_output_singapore" {
  value = module.ec2_singapore.private_ip
}

output "module_output_seoul" {
  value = module.ec2_seoul.private_ip
}

 

 

모듈마다 다른 프로바이더 설정을 진행했었지만 정상적으로 동작한다.

사진-8

사진-9

 

 

apply 실행 결과

사진-10

 

 

모듈의 반복문

모듈 또한 리소스에서 반복문을 사용하듯 구성할 수 있다. 모듈이라는 리소스 정의 묶음을 원하는 수량으로 프로비저닝할 수 있으므로 모듈 없이 구성하는 것과 대비해 리소스 종속성 관리와 유지 보수에 장점이 있다

실습을 위해 다음과 같이 파일을 생성 후 apply를 진행한다.

provider "aws" {
  region = "ap-northeast-2"  
}

module "ec2_seoul" {
  **count  = 2**
  source = "../modules/terraform-aws-ec2"
  instance_type = "t3.small"
}

output "module_output" {
  value  = module.ec2_seoul[*].private_ip   
}

사진-11

 

 

모듈 묶음에 일관된 구성과 구조로 프로비저닝이 되는 경우라면 count가 간편한 방안이지만, 동일한 모듈 구성에 필요한 인수 값이 다르다면 for_each를 활용한다.

 

다음은 동일한 모듈에 개발과 상용에 대한 입력 변수를 다르게 처리하는 방식을 확인해보겠다.

**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
  ]
}

 

 

apply 및 tfstate에 모듈 정보 확인

사진-12

사진-13

 

 

4. 모듈 소스 관리

Module 블록에 정의된 소스 구성으로 모듈의 코드 위치를 정의한다. terraform init를 수행할 때 지정된 모듈을 다운로드해 사용한다.

모듈 소스의 유형은 다음과 같다.

• 로컬 디렉터리 경로
• 테라폼 레지스트리 Terraform Registry
• 깃허브 Github
• 비트버킷 Bitbucket
• 깃 Generic Git Repository
• HTTP URLs
• S3 Bucket
• GCS Bucket google cloud storage

테라폼 공식 문서 안내와 같이 루트 경로에 모듈을 배치하는 것 외에 패키지 하위 디렉터리 경로를 참조하는 것도 하나의 방안이다.

 

로컬 디렉터리 경로

로컬 경로를 지정할 때는 테라폼 레지스트리와 구분하기 위해 하위 디렉터리는 ./로, 상위 디렉터리는 ../로 시작한다.

대상 모듈은 이미 같은 로컬 파일 시스템에 존재하므로 다운로드 없이 바로 사용한다. 앞서 언급한 대로 재사용성이 고려된다면 상위 디렉터리에 별도 관리하는 것을 권장하고, 항상 루트 모듈과 함께 동작해야 하는 경우 하위 디렉터리에 모듈을 정의한다.

작업 환경을 기준으로 하는 로컬 경로 상위에 위치한 모듈 경로 선언

module "local_module" {
  source = "../modules/my_local_module"
}

 

테라폼 레지스트리

테라폼 모듈 레지스트리는 테라폼의 프로토콜을 사용해 모듈을 사용하는 방식이다.

공개된 테라폼 모듈을 사용하거나 Terraform Cloud, Terraform Enterprise에서 제공되는 비공개 테라폼 모듈을 사용할 때 설정하는 소스 지정 방식이다.

공개된 모듈은 다음 링크에서 확인할 수 있다.

https://registry.terraform.io/modules/terraform-aws-modules/vpc/aws/latest

Terraform Registry

 

 

공개된 테라폼 모듈을 source에 선언할 때는 <네임스페이스>/<이름>/<프로바이더> 형태로 설정한다.

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "3.14.2"
}

 

깃허브

깃의 원격 저장소로 널리 알려진 깃허브는 테라폼 구성에 대한 CI를 위한 용도로 사용할 수 있고, 여기에 저장된 구성을 테라폼 모듈의 소스로 선언할 수도 있다.

테라폼 소스를 깃허브에 업로드하는 과정

1. 깃허브에 로그인
2. 새로운 깃허브 저장소 생성 [New repository]
   • Owner : 원하는 소유자 선택
   • Repository name : 예시) terraform-module-repo
   • Public 선택
   • Add .gitignore의 드롭박스에서 [Terraform]을 선택
3. 맨 아래 [Create repository] 클릭
4. 해당 저장소에 예시) ‘terraform-aws-ec2’ 디렉터리 생성 후 main.tf , variable.tf, output.tf 추가 후 업로드

 

깃허브 경로를 지정해보겠다. 다음과 같이 tf파일을 작성한다.

# main.tf
provider "aws" {
  region = "ap-southeast-1"  
}

module "ec2_seoul" {
  source = "github.com/chanW-pack***/terraform-module-repo/terraform-aws-ec2***"
  instance_type = "t3.small"
}

사진-14

 

 

다음과 같이 깃허브에 있던 파일이 다운로드된 것을 확인할 수 있다.

사진-15

 

다음은 terraform을 관리하는 runner이자 workflow인 아틀란티스로 자원 배포를 진행해보겠다.