8주차 1편 EKS IaC - Terraform, HCL

Terraform

Terraform 소개

• 테라폼(terraform)은 인프라스트럭처를 코드로 관리하고 자동화하기 위한 오픈 소스 도구입니다. 이를 통해 클라우드 서비스의 인프라스트럭처를 프로그래밍 방식으로 정의하고 배포할 수 있습니다.
• 테라폼을 사용하면 가상 머신, 컨테이너, 네트워크, 스토리지 등과 같은 다양한 클라우드 리소스를 쉽게 관리할 수 있습니다.
• 테라폼은 인프라스트럭처의 상태를 추적하고 변경사항을 관리하여 인프라를 일관되고 안정적으로 유지할 수 있도록 도와줍니다. 이는 개발자나 시스템 관리자가 손쉽게 인프라를 관리하고 확장할 수 있게 해줍니다.

https://developer.hashicorp.com/terraform/intro

 

실습 환경 준비

• 테라폼 설치 및 확인

wget -O- https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt update && sudo apt install terraform

# 테라폼 버전 정보 확인
terraform version

• AWSCLI 설치 → aws configure 로 자격증명 설정

curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install

# AWSCLI 버전 정보 확인
aws --version

• EKSCTL 설치

ARCH=amd64
PLATFORM=$(uname -s)_$ARCH
curl -sLO "https://github.com/eksctl-io/eksctl/releases/latest/download/eksctl_$PLATFORM.tar.gz"
tar -xzf eksctl_$PLATFORM.tar.gz -C /tmp && rm eksctl_$PLATFORM.tar.gz
sudo mv /tmp/eksctl /usr/local/bin

# EKSCTL 버전 정보 확인
eksctl version

• KUBECTL 설치

curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/1.29.3/2024-04-19/bin/linux/amd64/kubectl
chmod +x ./kubectl
mkdir -p $HOME/bin && cp ./kubectl $HOME/bin/kubectl && export PATH=$HOME/bin:$PATH

# KUBECTL 버전 정보 확인
kubectl version --client

• HELM 설치

curl https://baltocdn.com/helm/signing.asc | gpg --dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null
sudo apt-get install apt-transport-https --yes
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/helm.gpg] https://baltocdn.com/helm/stable/debian/ all main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list
sudo apt-get update
sudo apt-get install helm

# Helm 버전 정보 확인
helm version

• 실습에 편리한 툴 : watch, jq, tree 등

# Linux
sudo apt install -y tree jq

• Visual Studio Code 설치 → Extentions (확장) 설치
  • HashiCorp HCL : syntax highlighting for HCL files
  • HashiCorp Terraform : Highlighting syntax from Terraform

 

AWS에서 빠른 시작

기본 환경 준비

mkdir learn-terraform
cd learn-terraform
touch main.tf

• Amazon Linux 2 최신 ami id 찾기

# Amazon Linux 2 최신 ami id
aws ec2 describe-images --owners amazon --filters "Name=name,Values=amzn2-ami-hvm-2.0.*-x86_64-gp2" "Name=state,Values=available" --query 'Images|sort_by(@, &CreationDate)[-1].[ImageId]' --output text

AL2ID=`aws ec2 describe-images --owners amazon --filters "Name=name,Values=amzn2-ami-hvm-2.0.*-x86_64-gp2" "Name=state,Values=available" --query 'Images|sort_by(@, &CreationDate)[-1].[ImageId]' --output text`
echo $AL2ID

 

 

테라폼 코드 파일 작성

• HCL(Hashicorp Configuration Language) 코드 파일 생성, Block로 구성
  • provider : Terraform으로 정의할 Infrastructure Provider를 의미
  • resource : 실제로 생성할 인프라 자원을 의미

resource “<PROVIDER>_<TYPE>” “<NAME>” {
  [CONFIG ...]
}

- PROVIDER : ‘aws’ 같은 공급자의 이름
- TYPE : ‘security_group’ 같은 리소스의 유형
- NAME : 리소스의 이름
- CONFIG : 한개 이상 arguments

cat <<EOT > main.tf
provider "aws" {
  region = "ap-northeast-2"
}

resource "aws_instance" "example" {
  ami           = "$AL2ID"
  instance_type = "t2.micro"
}
EOT

 

배포 실행

• terraform init → plan → apply

# 초기화
terraform init
ls -al
tree .terraform

# plan 확인
terraform plan

# apply 실행
terraform apply
 Enter a value: yes 입력

• ec2 생성 확인

# ec2 생성 확인 : aws 웹 관리 콘솔에서도 확인 - 서울 리전 선택
export AWS_PAGER=""
aws ec2 describe-instances --output table

# 테라폼 정보 확인
terraform state list
terraform show
terraform show aws_instance.example

 

코드 파일 수정 후 배포 실행

• EC2 태그 정보 수정

cat <<EOT > main.tf
provider "aws" {
  region = "ap-northeast-2"
}

resource "aws_instance" "example" {
  ami           = "$AL2ID"
  instance_type = "t2.micro"

  tags = {
    Name = "aews-study"
  }

}
EOT

• 배포 실행

# plan 실행 시 아래와 같은 정보가 출력
terraform plan
# aws_instance.example will be updated in-place
  ~ resource "aws_instance" "example" {
        id                                   = "ami-0a0064415cdedc552"
      ~ tags                                 = {
          + "Name" = "t101-study"
        }
      ~ tags_all                             = {
          + "Name" = "t101-study"
        }
        # (29 unchanged attributes hidden)

        # (7 unchanged blocks hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

# apply 실행
terraform apply
 Enter a value: yes 입력

 

HCL 이란

• HashiCorp configuration language은 하시코프사에서 IaC와 구성 정보를 명시하기 위해 개발된 오픈 소스 도구입니다.
• IaC는 수동 프로세스가 아닌 코드를 통해 인프라를 관리하고 프로비저닝 하는 것을 의미합니다.
• 테라폼에서 HCL이 코드의 영역을 담당하고 있습니다. HCL은 쉽게 읽을 수 있고 빠르게 배울 수 있는 언어의 특징을 가지고 있습니다.
• 인프라가 코드로 표현되고, 이 코드는 곧 인프라이기 때문에 선언적 특성을 갖게 되고 Turing-complete 특성을 갖게 됩니다.
• 즉, 일반적인 프로그래밍 언어의 조건문 처리 같은 동작이 가능합니다. 자동화와 더불어, 쉽게 버저닝해 히스토리를 관리하고 함께 작업 할 수 있는 기반을 제공합니다.

HCL을 이용한 테라폼 구성	JSON을 이용한 CloudFormation 구성
resource "local_file" "abc" {   content = "abc!"   filename = "${path.module}/abc.txt" }	{   "resource": [     {       "local_file": [         {           "abc": [             {               "content":"abc!",               "filenale":"${path.module}/abc.txt"             }           ]         }       ]     }   ] }

• HCL에서 변수와 문자열 값을 함께 사용하는 인터폴레이션 interpolation 표현 방식을, JSON을 사용하는 다른 IaC 도구와 비교

HCL을 이용한 테라폼 구성	JSON을 이용한 CloudFormation 구성
name = “{$var.PilotServerName}-vm”	“name”:”{”Fn::Join”:[”-”,[PilotServerName,vm]]}”

• HCL을 사용하면 동일한 내용을 JSON으로 표현하는 것보다 더 간결하고 읽기 쉽게 작성할 수 있습니다.

 

HCL 표현식

// 한줄 주석 방법1
# 한줄 주석 방법2

/*
라인
주석
*/

locals {
  key1     = "value1"     # = 를 기준으로 키와 값이 구분되며
  myStr    = "TF ♡ UTF-8" # UTF-8 문자를 지원합니다.
  multiStr = <<EOF
  Multi
  Line
  String
  with anytext
EOF

  boolean1    = true   # boolean true
  boolean2    = false  # boolean false
  deciaml     = 123    # 기본적으로 숫자는 10진수
  octal       = 0123   # 0으로 시작하는 숫자는 8진수
  hexadecimal = "0xD5" # 0x 값을 포함하는 스트링은 16진수
  scientific  = 1e10   # 과학표기 법도 지원

  # funtion 호출 예
  myprojectname = format("%s is myproject name", var.project)

  # 3항 연산자 조건문을 지원
  credentials = var.credentials == "" ? file(var.credentials_file) : var.credentials
}

• HCL 표현식에서는 코드에서 사용되는 주석 표기부터 변수 정의 등을 포함하고 프로그래밍적인 연산과 구성 편의성을 높이기 위한 function도 제공합니다.
• 테라폼으로 인프라를 구성하기 위한 선언 블록도 다수 존재합니다. ex) terraform, resource, data, variable, local, output

 

Block

• 테라폼 버전이나 프로바이더 버전과 같은 값들은 자동으로 설정되지만, 함께 작업할 때는 버전을 명시적으로 선언하고 필요한 조건을 입력하여 실행 오류를 최소화 할 것을 권장합니다.

terraform {
  # 테라폼 버전
  required_version = "~> 1.3.0"

  # 프로바이더 버전을 나열
  required_providers {
    random = {
      version = ">= 3.0.0, < 3.1.0"
    }
    aws = {
      version = "4.2.0"
    }
  }
  
  # Cloud/Enterprise 같은 원격 실행을 위한 정보
  cloud {
    organization = "<MY_ORG_NAME>"
    workspaces {
      name = "my-first-workspace"
    }
  }

  # state를 보관하는 위치를 지정
  backend "local" {
    path = "relative/path/to/terraform.tfstate"
  }
}

• 테라폼 내에서 버전이 명시되는 terraform, module에서 사용 가능하며 버전에 대한 제약을 둠으로써 테라폼, 프로바이더, 모듈이 항상 의도한 정의대로 실행되는 것을 목적으로 합니다.
• 버전 체계는 시맨틱 버전 관리 Semantic Versioning 방식을 따릅니다.

# version = Major.Minor.Patch
version = 1.3.4

• 시맨틱 버전 관리 방식
  • Major 버전 : 내부 동작의 API가 변경 또는 삭제되거나 하위 호환이 되지 않는 버전
  • Minor 버전 : 신규 기능이 추가되거나 개선되고 하위 호환이 가능한 버전
  • Patch 버전 : 버그 및 일부 기능이 개선된 하위 호환이 가능한 버전
• 버전 제약 구문은 다른 프로그램 언어에서의 종속성 관리 시스템과 흡사합니다.
  • = 또는 연산자 없음 : 지정된 버전만을 허용하고 다른 조건과 병기할 수 없음
  • != : 지정된 버전을 제외
  • , >=, <, <= : 지정된 버전과 비교해 조건에 맞는 경우 허용
    • ~> : 지정된 버전에서 가장 자리수가 낮은 구성요소만 증가하는 것을 허용
      • ~> x.y 인 경우 y 버전에 대해서만, ~> x.y.z인 경우 z 버전에 대해서만 보다 큰 버전을 허용
• 테라폼 버전 관리로 비유된 선언 방식의 의미

선언된 버전	의미	고려 사항
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 미만인 버전을 허용	주버전에 대한 업데이트를 방지

 

Version

• 테라폼 버전에 대한 변경 내역과 기존 버전 정보 확인

# 현재 버전 정보 확인
terraform version

• 코드 파일 수정 main.tf

terraform {
  required_version = "< 1.0.0"
}

resource "local_file" "abc" {
  content  = "abc!"
  filename = "${path.module}/abc.txt"
}

• init 실행

# 실행 결과는?
terraform init
...

• 코드 파일 수정

terraform {
  required_version = ">= 1.0.0"
}

resource "local_file" "abc" {
  content  = "abc!"
  filename = "${path.module}/abc.txt"
}

• init 실행

# 실행 결과는?
terraform init
...

 

프로바이더 버전

• 테라폼 0.13 버전 이전에는 provider 블록에 함께 버전을 명시했지만 해당 버전 이후 프로바이더 버전은 terraform 블록에서 required_providers에 정의합니다.

v0.13 이전	v0.13 부터 적용
provider "aws" {   version = "~> 4.2.0" region = "ap-northeast-2" } provider "azurerm" {   version = ">= 2.99.0"   features {} }	terraform {   required_providers {     aws = {       source = "hashicorp/aws"       version = "~> 4.2.0"     }     azurerm = {       source = "hashicorp/azurerm"       version = ">= 2.99.0"     }   } }

• 각 프로바이더의 이름에 소스 경로와 버전을 명시하며, 테라폼 레지스트리 공식 페이지에서 원하는 프로바이더를 선택한 다음 화면에서 우측 상단의 [USE PROVIDER]를 클릭하면 테라폼 코드에 해당 버전을 사용하는 샘플 코드가 표기됩니다.

https://registry.terraform.io/providers/hashicorp/aws/latest

• 코드 파일 수정 : 프로바이더 버전을 과하게 높게 설정

terraform {
  required_version = ">= 1.0.0"
  required_providers {
    local = {
      source  = "hashicorp/local"
      version = ">=10000.0.0"
    }
  }
}

resource "local_file" "abc" {
  content  = "123!"
  filename = "${path.module}/abc.txt"
}

• init 실행

# 실행 결과는?
terraform init -upgrade

• 코드 파일 수정 : local 프로바이더 버전을 >= 2.0.0으로 수정

terraform {
  required_version = ">= 1.0.0"
  required_providers {
    local = {
      source  = "hashicorp/local"
      version = ">= 2.0.0"
    }
  }
}

resource "local_file" "abc" {
  content  = "123!"
  filename = "${path.module}/abc.txt"
}

• init 실행

# 실행 결과는?
terraform init -upgrade

 

리소스 구성

• resource : 리소스 블록은 선언된 항목을 생성하는 동작을 수행
• 리소스 블록은 resource로 시작한다. 이후 리소스 블록이 생성할 ‘리소스 유형’을 정의합니다.
• 리소스 선언 : 리소스 유형(프로바이더이름_제공리소스유형), 동일한 유형에 대한 식별자 역할로 고유한 이름, 구성 인수들이 이름 뒤에 중괄호 내에 선언

resource "<리소스 유형>" "<이름>" {
  <인수> = <값>
}

resource "local_file" "abc" {
  content  = "123"
  filename = "${path.module}/abc.txt"
}

• 리소스에서 사용되는 유형들은 프로바이더에 종속성을 갖습니다. 특정 프로바이더의 유형만 추가해도 init 수행 시 해당 프로바이더를 설치합니다.

resource "local_file" "abc" {
  content  = "123"
  filename = "${path.module}/abc.txt"
}

resource "aws_instance" "web" {
  ami = "ami-a1b2c3d4"
  instance_type = "t2.micro"  
}

• init 실행

# init 시 프로바이더 선언 없이도 리소스 추가로 자동 인식된 프로바이더 요구사항과 초기화
terraform init
tree .terraform

• 리소스 동작 보조 추가 메타인수를 정의 할 수 있습니다 → 뒤에서 자세히 설명
  • depends_on : 종속성을 선언하며, 선언된 구성요소와의 생성 시점에 대해 정의
  • count : 선언된 개수에 따라 여러 리소스를 생성
  • for_each : map 또는 set 타입의 데이터 배열의 값을 기준으로 여러 리소스를 생성
  • provider : 동일한 프로바이더가 다수 정의되어 있는 경우 지정
  • lifecycle : 리소스의 수명주기 관리
  • provisioner : 리소스 생성 후 추가 작업 정의
  • timeouts : 프로바이더에서 정의한 일부 리소스 유형에서는 create, update, delete에 대한 허용 시간 정의 가능

 

종속성

• 테라폼 종속성은 resource, module 선언으로 프로비저인되는 각 요소의 생성 순서를 구분짓습니다.
• 기본적으로 다른 리소스에서 값을 참조해 불러올 경우 생성 선후 관계에 따라 작업자가 의도하지는 않았지만 자동으로 연관 관계가 정의되는 암시적 종속성을 갖게 되고, 강제로 리소스 간 명시적 종속성을 부여할 경우에는 메타인수인 depends_on을 활용합니다.
• 코드 파일 수정

resource "local_file" "abc" {
  content  = "123!"
  filename = "${path.module}/abc.txt"
}

resource "local_file" "def" {
  content  = "456!"
  filename = "${path.module}/def.txt"
}

• apply 실행 : 서로 선후 관계가 없는 동일한 수준으로, 병렬(동시) 실행
• VS Code 확장 graphviz 설치

# apply 실행
terraform apply -auto-approve
...


# 리소스 확인
ls *.txt
terraform state list


# graph 확인 > graph-1.dot 파일 선택 후 오른쪽 상단 DOT 클릭
terraform graph > graph-1.dot

• 리소스 참조값을 설정해 두 개의 리소스 간 암시적 종속성 부여

resource "local_file" "abc" {
  content  = "123!"
  filename = "${path.module}/abc.txt"
}

resource "local_file" "def" {
  content  = local_file.abc.content
  filename = "${path.module}/def.txt"
}

• apply 실행 : 커맨드 생성에 순서가 발생한 종속성 있는 두 개의 리소스

# apply 실행
terraform apply -auto-approve
...

# 리소스 확인
ls *.txt
terraform state list
diff abc.txt def.txt

# graph 확인 > graph-2.dot 파일 선택 후 오른쪽 상단 DOT 클릭
terraform graph > graph-2.dot

• 리소스의 속성을 주입하지 않아도 두 리소스 간에 종속성이 필요한 경우에, depends_on 선언으로 적용 가능

resource "local_file" "abc" {
  content  = "123!"
  filename = "${path.module}/abc.txt"
}

resource "local_file" "def" {
  depends_on = [
    local_file.abc
  ]

  content  = "456!"
  filename = "${path.module}/def.txt"
}

• apply 실행

# apply 실행
terraform apply -auto-approve
...

# graph 확인 > graph-3.dot 파일 선택 후 오른쪽 상단 DOT 클릭
terraform graph > graph-3.dot

 

리소스 속성 참조

• 리소스 구성에서 참조 가능한 값은 인수와 속성입니다.
  • 인수 : 리소스 생성 시 사용자가 선언하는 값
  • 속성 : 사용자가 설정하는 것은 불가능하지만 리소스 생성 이후 획득 가능한 리소스 고유 값
• 리소스 인수의 선언과 참조 가능한 인수 및 속성 패턴

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

# 리소스 참조
<리소스 유형>.<이름>.<인수>
<리소스 유형>.<이름>.<속성>

• 아래 코드는 쿠버네티스 프로바이더의 Namespace 리소스를 생성하고 이후 Secret을 해당 Namespace에 생성하는 종속성을 리소스 인수 값 값으로 생성하는 예입니다. Namespace의 이름만 변경해도, 해당 Namespace를 참조하는 모든 리소스가 업데이트되어 영향을 받습니다.

resource "kubernetes_namespace" "example" {
  metadata {
    annotations = {
      name = "example-annotation"
    }
    name = "terraform-example-namespace"
  }
}

resource "kubernetes_secret" "example" {
  metadata {
    namespace = kubernetes_namespace.example.metadata.0.name # namespace 리소스 인수 참조
    name      = "terraform-example"
  }
  data = {
    password = "P4ssw0rd"
  }
}

• 리소스가 생성될 때, 사용자가 입력한 ‘인수’를 받아 실제 리소스가 생성되면 일부 리소스는 자동으로 기본값이나 추가되는 ‘속성’이 부여됩니다.
• 각 리소스마다 문서를 확인해보면 인수는 Arguments로 표현되어 있으며, 리소스 생성 후 추가되는 속성 값으로 Attributes에 안내되어 있습니다.
• 리소스 속성을 참조하는 다른 리소스 또는 구성요소에서는 생성 후의 속성 값들도 인수로 가져올 수 있습니다.

 

데이터 소스 구성

• 데이터 소스는 테라폼으로 정의되지 않은 외부 리소스 또는 저장된 정보를 테라폼 내에서 참조할 때 사용합니다.
• 데이터 소스 블록은 data로 시작, 이후 ‘데이터 소스 유형’을 정의 → Resource 블록 정의와 유사
  • 데이터 소스 유형은 첫 번째 _를 기준으로 앞은 프로바이더 이름, 뒤는 프로바이더에서 제공하는 리소스 유형을 의미합니다.
  • 데이터 소스 유형을 선언한 뒤에는 고유한 이름을 붙인다. 리소스의 이름과 마찬가지로 이름은 동일한 유형에 대한 식별자 역할을 하므로 중복될 수 없습니다.
  • 이름 뒤에는 데이터 소스 유형에 대한 구성 인수들은 { } 안에 선언한다. 인수가 필요하지 않은 유형도 있지만, 그때에도 { } 는 입력합니다.

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

• 데이터 소스를 정의할 때 사용 가능한 메타인수는 다음과 같습니다.
  • depends_on : 종속성을 선언하며, 선언된 구성요소와의 생성 시점에 대해 정의
  • count : 선언된 개수에 따라 여러 리소스를 생성
  • for_each : map 또는 set 타입의 데이터 배열의 값을 기준으로 여러 리소스를 생성
  • lifecycle : 리소스의 수명주기 관리
• 실습 확인

# 실습 확인을 위해서 abc.txt 파일 생성
echo "t101 study - 2week" > abc.txt

# 
terraform init && terraform plan && terraform apply -auto-approve
terraform state list

# 테라폼 콘솔 : 데이터 소스 참조 확인
terraform console
> 
data.local_file.abc
...
data.local_file.abc.filename
data.local_file.abc.content
data.local_file.abc.id
exit

 

데이터 소스 속성 참조

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

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

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

• 데이터 소스를 활용해 AWS 가용영역 인수를 정의 → 리전 내에서 사용 가능한 가용영역 목록 가져오기

# Declare the data source
data "aws_availability_zones" "available" {
  state = "available"
}
resource "aws_subnet" "primary" {
  availability_zone = data.aws_availability_zones.available.names[0]
  # e.g. ap-northeast-2a
}
resource "aws_subnet" "secondary" {
  availability_zone = data.aws_availability_zones.available.names[1]
  # e.g. ap-northeast-2b
}

• 아래 문서에서 데이터 소스로 가져오기 위한 조건인 인수는 Argument로 표현되어 있고, 가져온 데이터 소스의 내용은 Attributes에 안내되어 있습니다.

Terraform Registry

 

• [실습] main.tf 파일 코드 수정

resource "local_file" "abc" {
  content  = "123!"
  filename = "${path.module}/abc.txt"
}

data "local_file" "abc" {
  filename = local_file.abc.filename
}

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

• 확인

#
terraform apply -auto-approve
terraform state list

# 파일 확인
ls *.txt
diff abc.txt def.txt

# graph 확인
terraform graph > graph.dot

# 테라폼 콘솔 : 데이터 소스 참조 확인
terraform console
> 
data.local_file.abc.content
...
exit

# 생성된 파일 권한이 다름??? 왜지???
ls -l

• [추가 실습] az.tf 파일 생성

data "aws_availability_zones" "available" {
  state = "available"
}

• 확인

#
terraform init -upgrade && terraform apply -auto-approve
terraform state list

#
terraform state show data.aws_availability_zones.available

# 
terraform console
>
-----------------
data.aws_availability_zones.available
data.aws_availability_zones.available.names
data.aws_availability_zones.available.names[0]
data.aws_availability_zones.available.names[1]
data.aws_availability_zones.available.zone_ids[0]
data.aws_availability_zones.available.zone_ids[1]
exit
-----------------