📌 Notice

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

출처 - 한빛출판네트워크

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

📌 Summary

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

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

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

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

📌 Study

👉 Step 01. 3장 기본 사용법

✅ 3.5 데이터 소스

데이터 소스는 테라폼으로 정의되지 않은 외부 리소스 또는 저장된 정보를 테라폼 내에서 참조할 때 사용합니다.

데이터 소스 구성

데이터 소스 블록은 data로 시작, 이후 ‘데이터 소스 유형’을 정의 ← Resource 블록 정의와 유사

데이터 소스 유형은 첫 번째 _를 기준으로 앞은 프로바이더 이름, 뒤는 프로바이더에서 제공하는 리소스 유형을 의미한다.

데이터 소스 유형을 선언한 뒤에는 고유한 이름을 붙인다. 리소스의 이름과 마찬가지로 이름은 동일한 유형에 대한 식별자 역할을 하므로 중복될 수 없다.

이름 뒤에는 데이터 소스 유형에 대한 구성 인수들은 { } 안에 선언한다. 인수가 필요하지 않은 유형도 있지만, 그때에도 { } 는 입력한다

data "local_file" "abc" {
  filename = "${path.module}/abc.txt"
}

데이터 소스를 정의할 때 사용 가능한 메타인수

• depends_on : 종속성을 선언하며, 선언된 구성요소와의 생성 시점에 대해 정의
• count : 선언된 개수에 따라 여러 리소스를 생성
• for_each : map 또는 set 타입의 데이터 배열의 값을 기준으로 여러 리소스를 생성
• lifecycle : 리소스의 수명주기 관리

데이터 소스 속성 참조
데이터 소스로 읽은 대상을 참조하는 방식은 리소스와 구별되게 data가 앞에 붙는다. 속성 값은 다음과 같이 접근할 수 있다.

# Terraform Code
data "<리소스 유형>" "<이름>" {
  <인수> = <값>
}

# 데이터 소스 참조
data.<리소스 유형>.<이름>.<속성>

✅ 3.6 입력 변수 Variable

입력 변수는 인프라를 구성하는 데 필요한 속성 값을 정의해 코드의 변경 없이 여러 인프라를 생성하는 데 목적이 있습니다.

테라폼에서는 이것을 입력 변수 Input Variables로 정의 할 수 있습니다.

변수 선언 방식

변수는 variable로 시작되는 블록으로 구성됩니다.

변수 블록 뒤의 이름 값은 동일 모듈 내 모든 변수 선언에서 고유해야 하며, 이 이름으로 다른 코드 내에서 참조할 수 있습니다.

# variable 블록 선언의 예
variable "<이름>" {
 <인수> = <값>
}

variable "image_id" {
 type = string
}

테라폼 예약 변수 이름으로 사용 불가능
source, version, providers, count, for_each, lifecycle, depends_on, locals

변수 정의 시 사용 가능한 메타인수

• default : 변수 값을 전달하는 여러 가지 방법을 지정하지 않으면 기본값이 전달됨, 기본값이 없으면 대화식으로 사용자에게 변수에 대한 정보를 물어봄
• type : 변수에 허용되는 값 유형 정의, string number bool list map set object tuple 와 유형을 지정하지 않으면 any 유형으로 간주
• description : 입력 변수의 설명
• validation : 변수 선언의 제약조건을 추가해 유효성 검사 규칙을 정의 - 링크
• sensitive : 민감한 변수 값임을 알리고 테라폼의 출력문에서 값 노출을 제한 (암호 등 민감 데이터의 경우) - 링크
• nullable : 변수에 값이 없어도 됨을 지정

변수 유형 : 지원되는 변수의 범주와 형태

기본 유형

• string : 글자 유형
• number : 숫자 유형
• bool : true 또는 false
• any : 명시적으로 모든 유형이 허용됨을 표시

집합 유형

• list (<유형>): 인덱스 기반 집합
• map (<유형>): 값 = 속성 기반 집합이며 키값 기준 정렬
• set (<유형>): 값 기반 집합이며 정렬 키값 기준 정렬
• object ({<인수 이름>=<유형>, …})
• tuple ([<유형>, …])
  • list와 set은 선언하는 형태가 비슷하지만 참조 방식이 인덱스와 키로 각각 차이가 있고, map와 set의 경우 선언된 값이 정렬되는 특징을 가진다.

유효성 검사 : 입력되는 변수 타입 지정 이외, 사용자 지정 유효성 검사가 가능

• 변수 블록 내에 validation 블록에서 조건인 condition에 지정되는 규칙이 true 또는 false를 반환해야 하며, error_message는 condition 값의 결과가 false 인 경우 출력되는 메시지를 정의한다.
• regex 함수는 대상의 문자열에 정규식을 적용하고 일치하는 문자열을 반환하는데, 여기에 can 함수를 함께 사용하면 정규식에 일치하지 않는 경우의 오류를 검출한다.
• validation 블록은 중복으로 선언할 수 있다.
• variable 유효성 검사의 예 - main.tf 코드 파일 내용 수정

민감한 변수 취급 : 입력 변수의 민감 여부 선언 가능

main.tf 코드 파일 내용 수정

• 기본값 추가로 입력 항목은 발생하지 않지만, 출력에서 참조되는 변수 값이(sensitive)로 감춰지는 것을 확인 할 수 있다

  variable "my_password" {
    default   = "password"
    **sensitive = true**
  }
  
  resource "local_file" "abc" {
    content  = var.my_password
    filename = "${path.module}/abc.txt"
  }

• 확인 : 민감한 변수로 지정해도 terraform.tfstate 파일에는 결과물이 평문으로 기록되므로 State 파일의 보안에 유의해야 한다. [참고 Docs - sensitive-variables , State 암호화]

# 출력부분에 내용 안보임!
terraform apply -auto-approve
terraform state show local_file.abc

# 결과물 파일 확인
cat abc.txt ; echo

# terraform.tfstate 파일 확인
cat terraform.tfstate | grep '"content":'
            "content": "password",

변수 입력 방식과 우선순위

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

[우선순위 수준]의 숫자가 작을수록 우선순위도 낮다.

✅ 3.7 local 지역 값

코드 내에서 사용자가 지정한 값 또는 속성 값을 가공해 참조 가능한 local (지역 값)은 외부에서 입력되지 않고, 코드 내에서만 가공되어 동작하는 값을 선언한다.

local은 입력 변수와 달리 선언된 모듈 내에서만 접근 가능하고, 변수처럼 실행 시에 입력받을 수 없다.

로컬은 사용자가 테라폼 코드를 구현할 때 값이나 표현식을 반복적으로 사용할 수 있는 편의를 제공한다.
하지만 빈번하게 여러 곳에서 사용되는 경우 실제 값에 대한 추적이 어려워져 유지 관리 측면에서 부담이 발생할 수 있으므로 주의해야 한다.

로컬이 선언되는 블록은 locals로 시작한다. 선언되는 인수에 표현되는 값은 상수만이 아닌 리소스의 속성, 변수의 값들도 조합해 정의할 수 있다.

동일한 tf 파일 내에서 여러 번 선언하는 것도 가능하고 여러 파일에 걸쳐 만드는 것도 가능하다.

다만 lcoals에 선언한 로컬 변수 이름은 전체 루트 모듈 내에서 유일해야 한다.

정의되는 속성 값은 지정된 값의 형태에 따라 다양한 유형으로 정의할 수 있다.

local 참조

• 선언된 local 값은 local.<이름>으로 참조할 수 있다.

• 테라폼 구성 파일을 여러 개 생성해 작업하는 경우 서로 다른 파일에 선언되어 있더라도 다른 파일에서 참조할 수 있다.

✅ 3.8 출력 output

출력 값은 주로 테라폼 코드의 프로비저닝 수행 후의 결과 속성 값을 확인하는 용도로 사용된다.

또한 프로그래밍 언어에서 코드 내 요소 간에 제한된 노출을 지원하듯, 테라폼 모듈 간, 워크스페이스 간 데이터 접근 요소로도 활용할 수 있다.

예를 들면 자바의 getter와 비슷한 역할이다.

출력 값의 용도는 다음과 같이 정의할 수 있다.

• 루트 모듈에서 사용자가 확인하고자 하는 특정 속성 출력

• 자식 모듈의 특정 값을 정의하고 루트 모듈에서 결과를 참조

• 서로 다른 루트 모듈의 결과를 원격으로 읽기 위한 접근 요소

모듈 내에서 생성되는 속성 값들은 output 블록에 정의된다

output "instance_ip_addr" {
  value = "http://${aws_instance.server.private_ip}"
}

출력되는 값은 value의 값이며 테라폼이 제공하는 조합과 프로그래밍적인 기능들에 의해 원하는 값을 출력할 수 있다.

주의할 점은 output 결과에서 리소스 생성 후 결정되는 속성 값은 프로비저닝이 완료되어야 최종적으로 결과를 확인할 수 있고 terraform plan 단계에서는 적용될 값이 출력하지 않는다는 것이다.

변수 정의 시 사용 가능한 메타인수는 다음과 같다.

• description : 출력 값 설명
• sensitive : 민감한 출력 값임을 알리고 테라폼의 출력문에서 값 노출을 제한
• depends_on : value에 담길 값이 특정 구성에 종속성이 있는 경우 생성되는 순서를 임의로 조정
• precondition : 출력 전에 지정된 조건을 검증

✅ 3.9 반복문

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

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

• 리소스 또는 모듈 블록에 count 값이 정수인 인수가 포함된 경우 선언된 정수 값만큼 리소스나 모듈을 생성하게 된다.

• count에서 생성되는 참조 값은 count.index이며, 반복하는 경우 0부터 1씩 증가해 인덱스가 부여된다.

때때로 여러 리소스나 모듈의 count로 지정되는 수량이 동일해야 하는 상황이 있다. 이 경우 count에 부여되는 정수 값을 외부 변수에 식별되도록 구성할 수 있다.

for_each : 반복문, 선언된 key 값 개수만큼 리소스를 생성
리소스 또는 모듈 블록에서 for_each에 입력된 데이터 형태가 map 또는 set이면, 선언된 key 값 개수만큼 리소스를 생성하게 된다.

for_each가 설정된 블록에서는 each 속성을 사용해 구성을 수정할 수 있다

• each.key : 이 인스턴스에 해당하는 map 타입의 key 값

• each.value : 이 인스턴스에 해당하는 map의 value 값

생성되는 리소스의 경우 <리소스 타입>.<이름>, 모듈의 경우 module.<모듈 이름>로 해당 리소스의 값을 참조한다.

이 참조 방식을 통해 리소스 간 종속성을 정의하기도 하고 변수로 다른 리소스에서 사용하거나 출력을 위한 결과 값으로 사용한다.

for : 복합 형식 값의 형태를 변환하는 데 사용. - for_each와 다름

예를 들어 list 값의 포맷을 변경하거나 특정 접두사 prefix를 추가할 수도 있고, output에 원하는 형태로 반복적인 결과를 표현할 수 도 있다.

• list 타입의 경우 값 또는 인덱스와 값을 반환
• map 타입의 경우 키 또는 키와 값에 대해 반환
• set 타입의 경우 키 값에 대해 반환

for 구문을 사용하는 몇 가지 규칙은 다음과 같다.

1. list 유형의 경우 반환 받는 값이 하나로 되어 있으면 값을, 두 개의 경우 앞의 인수가 인덱스를 반환하고 뒤의 인수가 값을 반환 - 관용적으로 인덱스는 i, 값은 v로 표현

2. map 유형의 경우 반환 받는 값이 하나로 되어 있으면 키를, 두 개의 경우 앞의 인수가 키를 반환하고 뒤의 인수가 값을 반환 - 관용적으로 키는 k, 값은 v로 표현

3. 결과 값은 for 문을 묶는 기호가 [ ]인 경우 tuple로 반환되고 { }인 경우 object 형태로 반환

4. object 형태의 경우 키와 값에 대한 쌍은 ⇒ 기호로 구분
   { } 형식을 사용해 object 형태로 결과를 반환하는 경우 키 값은 고유해야 하므로 값 뒤에 그룹화 모드 심볼(…)를 붙여서 키의 중복을 방지(SQL의 group by 문 또는 Java의 MultiValueMap과 같은 개념)
   if 구문을 추가해 조건 부여 가능

dynamic : 리소스 내부 속성 블록을 동적인 블록으로 생성

count 나 for_each 구문을 사용한 리소스 전체를 여러 개 생성하는 것 이외도 리소스 내에 선언되는 구성 블록을 다중으로 작성해야 하는 경우가 있다.

예를 들면 AWS Security Group 리소스 구성에 ingress, egress 요소가 리소스 선언 내부에서 블록 형태로 여러 번 정의되는 경우다.

리소스 내의 블록 속성(Attributes as Blocks)은 리소스 자체의 반복 선언이 아닌 내부 속성 요소 중 블록으로 표현되는 부분에 대해서만 반복 구문을 사용해야 하므로, 이때 dynamic 블록을 사용해 동적인 블록을 생성 할 수 있다.

dynamic 블록을 작성하려면, 기존 블록의 속성 이름을 dynamic 블록의 이름으로 선언하고 기존 블록 속성에 정의되는 내용을 content 블록에 작성한다.

반복 선언에 사용되는 반복문 구문은 for_each를 사용한다. 기존 for_each 적용 시 each 속성에 key, value가 적용되었다면 dynamic에서는 dynamic에 지정한 이름에 대해 속성이 부여된다.

일반적인 블록 속성 반복 적용 시

  resource "provider_resource" "name" {
  name = "some_resource"

  some_setting {
    key = a_value
  }

  some_setting {
    key = b_value
  }

  some_setting {
    key = c_value
  }

  some_setting {
    key = d_value
  }
}

dynamic 블록 적용 시

resource "provider_resource" "name" {
  name = "some_resource"

  dynamic "some_setting" {
    for_each = {
      a_key = a_value
      b_key = b_value
      c_key = c_value
      d_key = d_value
    }

    content {
      key = some_setting.value
    }
  }
}

🧩 Assignment

👉 도전과제 1

목표 - 리전 내에서 사용 가능한 가용영역 목록 가져오기를 사용한 VPC 리소스 생성 실습 진행 - 링크 혹은 아무거나 데이터 소스를 사용한 실습 진행

VPC 목록 가져오기
data를 이용하여 특정 태그 값을 가진 VPC의 정보를 가져올 수 있습니다.

data "aws_vpcs" "foo" {
  tags = {
    Terraform = "true"
  }
}

output "foo" {
  value = data.aws_vpcs.foo.ids
}

결과

👉 도전과제 2

목표 - 위 3개 코드 파일 내용에 리소스의 이름(myvpc, mysubnet1 등)을 반드시! 꼭! 자신의 닉네임으로 변경해서 배포 실습해보세요!

my* 로 사용된 리소스의 이름은 변경하여 AWS에 배포합니다.

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

resource "aws_vpc" "xgro_vpc" {
  cidr_block       = "10.10.0.0/16"
  enable_dns_support   = true
  enable_dns_hostnames = true

  tags = {
    Name = "xgro-t1013-study"
  }
}

resource "aws_subnet" "xgro_subnet1" {
  vpc_id     = aws_vpc.xgro_vpc.id
  cidr_block = "10.10.1.0/24"

  availability_zone = "ap-northeast-2a"

  tags = {
    Name = "t101-subnet1"
  }
}

resource "aws_subnet" "xgro_subnet2" {
  vpc_id     = aws_vpc.xgro_vpc.id
  cidr_block = "10.10.2.0/24"

  availability_zone = "ap-northeast-2c"

  tags = {
    Name = "t101-subnet2"
  }
}


resource "aws_internet_gateway" "xgro_igw" {
  vpc_id = aws_vpc.xgro_vpc.id

  tags = {
    Name = "t101-igw"
  }
}

resource "aws_route_table" "xgro_rt" {
  vpc_id = aws_vpc.xgro_vpc.id

  tags = {
    Name = "t101-rt"
  }
}

resource "aws_route_table_association" "xgro_rtassociation1" {
  subnet_id      = aws_subnet.xgro_subnet1.id
  route_table_id = aws_route_table.xgro_rt.id
}

resource "aws_route_table_association" "xgro_rtassociation2" {
  subnet_id      = aws_subnet.xgro_subnet2.id
  route_table_id = aws_route_table.xgro_rt.id
}

resource "aws_route" "xgro_defaultroute" {
  route_table_id         = aws_route_table.xgro_rt.id
  destination_cidr_block = "0.0.0.0/0"
  gateway_id             = aws_internet_gateway.xgro_igw.id
}

output "aws_vpc_id" {
  value = aws_vpc.xgro_vpc.id
}

결과

VScode Console에서 apply가 정상적으로 완료된 것을 확인할 수 있습니다.

AWS Console에서 테라폼으로 실행한 VPC가 정상적으로 배포된것을 확인할 수 있습니다.

👉 도전과제 3

목표 - 입력변수를 활용해서 리소스(어떤 리소스든지 상관없음)를 배포해보고, 해당 코드를 정리해주세요!

입력 변수를 이용하여 도전과제 2에서 생성한 VPC_id를 이용하여 추가 서브넷을 생성합니다.

variable "vpc_id" {}

data "aws_vpc" "selected" {
  id = var.vpc_id
}

resource "aws_subnet" "example" {
  vpc_id            = data.aws_vpc.selected.id
  availability_zone = "ap-northeast-2a"
  cidr_block        = cidrsubnet(data.aws_vpc.selected.cidr_block, 4, 1)
}

결과
입력 변수로 vpc-0f6a753723217b6a2를 받아 해당하는 VPC에 서브넷을 추가로 생성하는 것을 확인할 수 있습니다.

📌 Reference

• why hashicorp? - links
• terraform docs - links