Terraform Module 정리 & 해석

Terraform Tutorial - Modules 정리 및 해석 

 

1. 모듈 요약

모듈은 왜 필요할까?

• Configuration을 구성하기 위해서 - 모듈은 연관된 설정들을 묶어둠으로써 환경 구성(configuration)을 찾고, 이해하고, 업데이트하는 과정을 훨씬 쉽게 바꾼다. 구조가 복잡한 인프라는 수백, 수천 줄의 configuration을 적용해야 할 때가 있다. 모듈을 통해 환경 구성들을 논리적으로 유지할 수 있다.
• Configuration 캡슐화 - 모듈의 또 다른 장점은 환경 구성을 개별적인 논리 구성 요소로 캡슐화할 수 있다는 것이다. 캡슐화는 의도하지 않았던 실수로 다른 인프라가 변경되는 등의 결과를 방지할 수 있으며, 두 개의 서로 다른 리소스에 동일한 이름을 사용하는 것과 같은 단순한 오류가 발생할 가능성을 줄일 수 있다.
• Configuration 재사용 - 모든 환경구성을 처음부터 작성하는 건 시간 낭비일뿐만 아니라 에러가 발생하기 딱! 좋은 행동이다. 본인, 아니면 팀원들, 그리고 테라폼 관계자들이 만들어 둔 모듈을 사용하면 시간을 절약하고, 에러를 방지할 수 있다. 그리고 내가 작성한 모듈을 다른 사람들과 공유하며 스스로의 멋진 작업에 credit을 줄 수 있다.⭐️
• 일관성 제공 & best practice(뭐라고 번역해야할지..🤔) - 모듈은 당신의 환경구성에 일관성을 제공한다. 일관성은 복잡한 환경구성을 이해하기 쉽게 할 뿐만 아니라, 모든 구성에 모범적인 적용을 할 수 있도록 한다. 예를 들어, 클라우드 제공 업체들은 Amazon S3나 Google Cloud Storage buckets 같은 storage 서비스들을 구성하는데 굉장히 많은 옵션을 제공한다. 잘못된 보안 스토리지와 관련하여 많은 보안 문제가 발생했고, 복잡한 환경 구성 때문에 이러한 서비스를 실수로 잘못 구성하기 쉽다. 

 

그럼 Terraform 모듈은 뭘까?

 

테라폼에서의 모듈은 하나의 프로젝트 다렉토리에 있는 Terraform confgiuration 파일을 모두 뜻한다. 하나 이상의 .tf 파일을 가지고 있다면 간단하든 복잡하든 이것들은 모두 configuration이다. 만약 테라폼 명령어들을 바로 전체 프로젝트 폴더에서 적용한다면, 그 폴더는 root module로 간주된다. 이런 맥락에서 모든 테라폼 환경 구성 파일들은 '모듈'의 구성원이 되는 셈이다. 

 

~/terraform_test
.
├── README.md
├── main.tf
├── variables.tf
├── outputs.tf

 

이 예시에서는 terraform_test이라는 폴더가 root_modlue이 되는것이다.

 

모듈 호출

 

Terraform 명령은 일반적으로 현재 작업 디렉토리에 있는 구성 파일만 직접 사용한다. 그러나 환경 구성에서는 모듈 블록을 사용하여 다른 디렉토리의 모듈을 호출할 수 있다!(뭔가 파이썬 같기도~) Terraform은 모듈 블록을 만나면 해당 모듈의 구성 파일을 로드하고 처리한다.
다른 구성에 의해 호출되는 모듈을 해당 구성의 "하위 모듈"이라고 부른다.

 

로컬 & 원격 모듈

 

모듈은 로컬이나 원격에서 가져올 수 있다. Terraform은  Terraform Registry, 버전 컨트롤 시스템, HTTP URLs, Terraform Cloud나 Terraform Enterprise 개인 모듈 registires등 다양한 원격 source를 지원한다.

 

 

모듈 best practices

 

테라폼 모듈은 대부분의 프로그래밍 언어에서 찾을 수 있는 라이브러리, 패키지 또는 모듈의 개념과 유사하며, 비슷한 장점을 제공한다. 대부분의 컴퓨터 프로그램과 마찬가지로, 실제 Terraform 구성들은 위에서 언급한 이점을 제공하기 위해 거의 항상 모듈을 사용해야 한다.(그냥 항상 모듈 쓰라는 거 같은)

모든 Terraform 이용자는 다음과 같은 모범 사례(best practices)를 따라 모듈을 사용할 것을 권장한다.

1. provider의 이름을 terraform-<PROVIDER>-<NAME>로 지정한다. Terraform Cloud 또는 Terraform Enterprise 모듈 registires에 모듈을 등록하려면 이 규칙을 따라야 한다.
2. 모듈을 염두에 두고!! 환경 구성 작성을 시작하자. 개인이 관리하는 복잡한 Terraform 구성에서도 모듈을 사용하는 것이 모듈을 올바르게 사용하는 것보다 훨씬 시간이 적게 걸릴 것이다. 
3. 로컬 모듈을 사용하여 코드를 구성하고 캡슐화하자. 원격 모듈을 사용하지 않거나, 게시하지 않더라도 처음부터 모듈 측면에서 환경 구성을 만들면 인프라가 복잡해져도 유지 보수하고 업데이트해야 하는 부담을 크게 줄일 수 있다.
4. 공용 Terraform Registry(https://registry.terraform.io/)를 사용하여 유용한 모듈을 찾자. 이렇게 하면 일반적인 인프라 시나리오를 구현하기 위해 다른 사람의 작업에 의존하여 구성을 보다 빠르고 확실하게 구현할 수 있다.
5. 모듈을 게시하고 팀과 공유하자. 대부분의 인프라는 한 팀의 많은 사람들에 의해 관리되며, 모듈은 팀이 함께 협력하여 인프라를 만들고 유지할 수 있는 중요한 방법이다. 앞에서 언급한 바와 같이 모듈을 공개 또는 비공개로 게시할 수 있다. 

 

 

2. Registry에서 모듈 사용해보기

사전 요구사항

 

해당 튜토리얼을 따라하기 위해 사전에 준비해야하는 것들

• AWS 계정
• Terrafrom CLI

 

Terraform Registry 사용하기

 

Terraform Registry page for the VPC module 링크로 접속!

 

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "2.21.0"
  # insert the 8 required variables here
}

 

모듈을 호출할 때는 source 가 필요하다. 이 튜토리얼에서 Terraform은 Terraform Registry에서 주어진 문자열(source 값)과 일치하는 모듈을 검색할 것이다. 모듈의 원본에 대한 URL 또는 로컬 파일 경로를 사용할 수도 있다. 가능한 모듈 소스 목록은 Terraform 설명서를 참조하자.
source 외에 필요한 인수는 version이다. 버전을 통해 로드할 모듈의 버전을 정의할 수 있다. 이 튜토리얼에서는 사용하는 모듈의 정확한 버전 번호를 지정한다. 모듈 설명서에서 버전을 지정하는 방법에 대한 자세한 내용을 볼 수 있다.

모듈 블록에 대한 다른 인수들은 모듈에 대한 입력 변수로 처리된다.

 

Terraform Configuration 생성하기

 

이 튜토리얼에서는 우리는 모듈을 이용해서 Virtual Private Cloud(VPC)와 2개의 EC2 인스턴스가 있는 AWS 환경을 만들어 볼 것이다!

 

1. 깃헙 레포 클론, ~/learn-terraform-modules-use 폴더로 이동

git clone https://github.com/hashicorp/learn-terraform-modules-use.git
cd learn-terraform-modules-use

 

2. main.tf에서 환경 구성을 나에게 맞게 바꾸어준다

 

region을 바꿔주고, ami 값도 아래와 같이 바꿔준다(튜토리얼에 있는 ami 값은 우리 리전이랑 안 맞다). 인스턴스는 micro로 유지(돈이...없으니까..)

 

# Terraform configuration

terraform {
  required_providers {
    aws = {
      source = "hashicorp/aws"
    }
  }
}

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

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

  name = var.vpc_name
  cidr = var.vpc_cidr

  azs             = var.vpc_azs
  private_subnets = var.vpc_private_subnets
  public_subnets  = var.vpc_public_subnets

  enable_nat_gateway = var.vpc_enable_nat_gateway

  tags = var.vpc_tags
}

module "ec2_instances" {
  source  = "terraform-aws-modules/ec2-instance/aws"
  version = "2.12.0"

  name           = "my-ec2-cluster"
  instance_count = 2

  ami                    = "ami-033a6a056910d1137"
  instance_type          = "t2.micro"
  vpc_security_group_ids = [module.vpc.default_security_group_id]
  subnet_id              = module.vpc.public_subnets[0]

  tags = {
    Terraform   = "true"
    Environment = "dev"
  }
}

 

• terraform 블록은 Terraform 자체를 구성한다. 이 블록은 Hashipcorp provider registry의 aws provider를 요구한다.
• provider "aws" 블록은 provider(제공자)를 정의한다. 본인이 선택한 인증 방법(https://registry.terraform.io/providers/hashicorp/aws/latest/docs#authentication)에 따라 공급자 블록에 추가 인수를 포함해야 할 수도 있다. (인증 방법도 다음번에 한 번 정리를 시도)
• module "vpc" 블록은 인프라에서 네트워킹 서비스를 제공할 Virtual Private Cloud(VPC)를 정의한다.
• module "ec2_instaces" 블록은 2개의 ec2를 정의하고 있다.(instance_count = 2)

 

 

모듈 input 변수 값 지정하기

 

대부분의 모듈을 사용하려면 모듈 구성에 입력 변수를 전달해야 한다. 모듈을 호출하는 환경 구성은 모듈 블록에서 인수로 전달되는 입력 값을 설정하는 역할을 한다. 모듈 블록에 대한 대부분의 인수는 소스와 버전을 제외하고 변수 값을 설정한다.

 

AWS VPC Terraform registry 페이지에 해당 모듈이 지원하는 모든 입력 변수를 설명하는 Inputs(입력) 탭이 있다.
일부 입력 변수는 모듈이 기본값을 제공하지 않기 때문에 직접 입력해야 할 필요가 있다. Terraform이 올바르게 실행되려면 이런 값을 잘 채워넣어야 한다. 

module "vpc" 블록 내 입력 변수를 검토해보자. Terraform registry에서 문서화된 각 입력 변수를 찾을 수 있으니 참고하자.

• name - AWS내 VPC이름
• cidr - VPC에서 사용되는 CIDR 블록 설명
• azs - VPC 서브넷이 사용할 가용 지역 설명
• private_subnets - 공용 IP 주소나 경로가 없는 리소스를 포함하는 VPC 내의 서브넷
• public_subnets - 공용 IP 주소나 경로가 있는 리소스를 포함하는 서브넷
• enable_nat_gateway - 만약 값이 true면, 모듈이 NAT 게이트웨이를 private 서브넷에 provisioning
  • 프로비저닝(Provisioning)이란?
    무엇인가 여럿 중에 최적인 것을 찾기 위해 필요한 지식을 미리 준비해 놓고 요청에 맞게 공급하는 절차 와 행위를 provisioning 라고 한다. 즉, 미리 정의된 정책이나 서비스를 사용자에게 내려 (지원, 서포트) 주는 것을 말한다. IT인프라 지원을 사용자 또는 비즈니스의 요구사항에 맞게 할당 ,배치,배포해서 시스템을 사용 할 수 있드록 만들어 놓는 것.
• tags - AWS에서 구성에서 프로비저닝한 각 리소스에 대한 태그를 지정

 

Root input 변수 정의하기

 

입력 변수를 모듈과 함께 사용하는 것은 모든 Terraform 구성에서 변수를 사용하는 방법과 매우! 비슷하다. 일반적인 사용 패턴은, 나중에 변경할/변경될 모듈 입력 변수를 체크해서 환경 구성 variables.tf 파일에 적합한 기본값으로 일치하는 변수를 만드는 것이다. 그런 다음 이러한 변수를 인수로 모듈 블록에 전달할 수 있다.

모든 모듈의 input 변수들이 본인의 환경 구성에 의해 정의 될 필요는 없다. 예를 들어, 프로비저닝하는 애플리케이션에는 NAT 게이트웨이가 필요하므로 이 VPC를 항상 사용하도록 설정할 수 있다. 이런 경우에는 변수를 사용하여 enable_nat_gateway를 설정하면 역효과가 발생한다.

 

이런 root input 변수를 사용하려면 환경 구성에서 이런 변수를 따로 정의해야 한다.

 

variables.tf:

# Input variable definitions

variable "vpc_name" {
  description = "Name of VPC"
  type        = string
  default     = "example-vpc"
}

variable "vpc_cidr" {
  description = "CIDR block for VPC"
  type        = string
  default     = "10.0.0.0/16"
}

variable "vpc_azs" {
  description = "Availability zones for VPC"
  type        = list(string)
  default     = ["ap-northeast-2a", "ap-northeast-2b", "ap-northeast-2c"]
  # 가용영역 리전에 맞게 바꾸기
}

variable "vpc_private_subnets" {
  description = "Private subnets for VPC"
  type        = list(string)
  default     = ["10.0.1.0/24", "10.0.2.0/24"]
}

variable "vpc_public_subnets" {
  description = "Public subnets for VPC"
  type        = list(string)
  default     = ["10.0.101.0/24", "10.0.102.0/24"]
}

variable "vpc_enable_nat_gateway" {
  description = "Enable NAT gateway for VPC"
  type        = bool
  default     = true
}

variable "vpc_tags" {
  description = "Tags to apply to resources created by VPC module"
  type        = map(string)
  default = {
    Terraform   = "true"
    Environment = "dev"
  }
}

코드를 보면 vpc_nmae, vpc_cidr, vpc_azs 등 다양한 변수를 정의했음을 알 수 있고,

main.tf 를 다시 보면 여기서 정의한 변수들을 var.vpc_azs 형태로 다시 블록 내에서 호출한다는 것을 알 수 있다.

 

Root Ouput 값 정의하기

 

모듈에는 출력값(Output 값)도 있다. 이 값에는 module.<MODULE 이름>.<OUTPUT 이름> 형태로 접근할 수 있다. 모듈 ouput은 Terraform registry에 output 탭에 서술되어 있으니 참고하자.

모듈 출력값은 환경 구성의 다른 부분으로 전달되거나, root 모듈의 출력값으로 정의된다. 우리는 두 가지 경우를 해당 튜토리얼을 통해 모두 확인할 것이다.

outputs.tf:

# Output variable definitions

output "vpc_public_subnets" {
  description = "IDs of the VPC's public subnets"
  value       = module.vpc.public_subnets
}

output "ec2_instance_public_ips" {
  description = "Public IP addresses of EC2 instances"
  value       = module.ec2_instances.public_ip
}

 

이 예시에서는 vpc_public_subnets의 값은 vpc라는 모듈의 public_subnets 출력값에서 나오게 될 것이고, ec2_instance_public_ips는 module.ec2_instance.public_ip으로 정의된다.

 

 

인프라 프로비저닝

이제 terraform init을 해보자!!

 

1. terraform init

1. 에러 발생

 

 

..그래서 버전을 바꿔봤다.

 

2. 버전 지정

main.tf에서

 

terraform {
  required_providers {
    aws = {
      source = "hashicorp/aws"
      version = "~> 3.27"
    }
  }
}

이렇게 버전을 바꿔줬다.

 

3. upgrade 하라는 에러

 

 

그래서 업그레이드 했습니다 넵.

 

 

4. 성공 ~

 

 

2. terraform apply

init을 통해 provider와 모듈을 설치했다.

이제 EC2 인스턴스와 VPC를 생성하자.

 

잘 생성되었다! AWS에서도 확인해보자.

 

둘 다 잘 생성되었다!

 

 

모듈이 어떻게 작동하는지 이해하기

새로운 모듈을 처음 사용할 때는 terraform init 이나 terraform get 명령을 통해 모듈을 설치해야한다. 이런 명령어를 입력하면, Terraform은 모든 새 모듈을 .terraform/modules 다렉토리에 저장한다. 로컬 모듈의 경우 Terraform이 모듈의 디렉토리에 대한 symblink을 생성하기 때문에, 로컬 모듈에 대한 변경 사항은 terraform get을 다시 실행할 필요 없이 즉시 적용된다.

 

튜토리얼을 잘 따라했다면 모듈 다렉토리에 이런 결과물이 저장되어 있다.

 

 

인프라 clean up

Terraform registry에서 모듈을 가져와 사용하는 방법을 알았고 테스트도 모두 했으니, 방금 생성한 인프라를 terraform destory로 없애준다. 

 

 

 

3. 로컬 모듈 만들고 사용하기

이 튜토리얼에서는 정적 웹 사이트를 호스팅하는 데 사용되는 AWS S3 버킷을 관리하는 모듈을 만들 수 있습니다. 아자아자~

모듈 구조

아까 앞서 만든 폴더에서 추가할 수 있는 내용들에 대해 더 적어보자.

 

terraform.tfstate 및 terraform.tfstate.backup: 이 파일에는 사용자의 Terraform 상태가 포함되어 있고, Terraform이 사용자의 구성과 Terraform에서 프로비저닝된 인프라 간의 관계를 추적하게 한다.

.vargetform: 이 디렉토리에는 인프라를 프로비저닝하는 데 사용되는 모듈 및 플러그인이 포함되어 있다. 이러한 파일은 .tf 파일에 정의된 인프라의 구성이 아니라 인프라를 프로비저닝할 때 특정 Terraform 인스턴스로 한정된다.(씁..  이게 무슨 말일까)

*.tfvars: 모듈 입력 변수는 구성 내 모듈 블록에 대한 인수를 통해 설정되므로 독립 실행형 Terraform 구성으로 사용하지 않는 한 *.tfvars 파일을 모듈과 함께 배포할 필요가 없다.

 

-> 이 세개의 파일들은 써보지 않아서 잘 모르겠다..! ㅠ.ㅠ 

 

 

모듈 생성하기

git clone, terraform init

git clone https://github.com/hashicorp/learn-terraform-modules-create.git

terraform init 전에 아까처럼 리전, ami, 가용영역 모두 바꿔줄 것

 

이 튜토리얼에서는 이미 존재하는 환경 구성 내에서 AWS S3 버킷을 사용하는 로컬 submodule을 만들 것이다. 만약 해당 레포를 클론했다면, modules 이라는 폴더가 이미 존재하지만 클론하지 않았다면 새로 하나 만들어준다.

mkdir -p modules/aws-s3-static-website-bucket

 

정적 웹 사이트를 S3로 호스팅하는 것은 상당히 일반적인 사용 사례다. 이런 방식으로 버킷을 프로비저닝하는 올바른 환경 구성을 찾는 것은 그렇게 어렵지 않지만,

모듈 내에서 이 구성을 캡슐화하면 모범 사례를 준수하는 정적 웹 사이트를 호스팅하는 데 사용할 수 있는 버킷을 쉽고 빠르게 만들 수 있다.

 

모듈을 사용할 때의 또 다른 이점은 모듈 이름이 해당 모듈을 사용하여 생성된 버킷의 용도를 정확하게 설명할 수 있다는 것이다. 이 예에서 aws-s3-static-website-bucket 모듈은 정적 웹 사이트를 호스팅하는 s3 버킷을 생성한다는 것을 알 수 있다.

 

 

모듈 configuration 추가하기

modules/aws-s3-static-website-bucket 다렉토리로 들어가면 또 다시 main.tf outputs.tf 등과 같은 파일들이 존재함을 확인할 수 있다.

우리는 여기 있는 main.tf에 S3 버킷 리소스를 추가할 것이다.

 

# Terraform configuration

resource "aws_s3_bucket" "s3_bucket" {
  bucket = var.bucket_name

  tags = var.tags
}

resource "aws_s3_bucket_website_configuration" "s3_bucket" {
  bucket = aws_s3_bucket.s3_bucket.id

  index_document {
    suffix = "index.html"
  }

  error_document {
    key = "error.html"
  }
}

resource "aws_s3_bucket_acl" "s3_bucket" {
  bucket = aws_s3_bucket.s3_bucket.id

  acl = "public-read"
}

resource "aws_s3_bucket_policy" "s3_bucket" {
  bucket = aws_s3_bucket.s3_bucket.id

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid       = "PublicReadGetObject"
        Effect    = "Allow"
        Principal = "*"
        Action    = "s3:GetObject"
        Resource = [
          aws_s3_bucket.s3_bucket.arn,
          "${aws_s3_bucket.s3_bucket.arn}/*",
        ]
      },
    ]
  })
}

 

이 환경 구성 코드는 public S3 bucket이 호스팅하는, index.html과 error.html로 구성되어 있는 웹 사이트를 생성한다.

이 코드는 아까 전 튜토리얼에서 확인했던 main.tf와 달리 providers 라는 블록이 없다.

 

윗부분 main.tf의 providers:

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

Terraform이 모듈 블록을 처리할 때, 모듈 블록은 환경 구성 코드에서 provider를 상속한다. 이 때문에 모듈에는 공급자 블록을 포함하지 않는 것이 좋다.

 

(내가 이해한 바: 이미 모듈 외에 기본 환경 구성 코드 main.tf에 provider 가 있기 때문에 중복 상속 우려가 있어서 로컬 모듈 main.tf에는 provider를 포함하지 않는다)

구성의 루트 모듈과 마찬가지로 모듈도 변수를 정의하고 사용한다.

# Input variable definitions

variable "bucket_name" {
  description = "Name of the s3 bucket. Must be unique."
  type        = string
}

variable "tags" {
  description = "Tags to set on the bucket."
  type        = map(string)
  default     = {}
}

모듈 내 변수는 루트 모듈과 거의 동일한 방식으로 작동한다.

루트 환경 구성에서 Terraform 명령을 실행하면, 변수 값을 commandline에 전달하거나, .tfvars 파일을 사용하여 설정하는 등 다양한 방법이 있다.

모듈을 사용할 때는, 모듈에 인수를 전달하여 변수를 설정한다. 루트 모듈의 main.tf에서 이 모듈을 호출할 때 이러한 변수 중 일부를 설정하게 된다.

기본값이 지정되지 않은 모듈에 선언된 변수는 필수이므로 모듈을 사용할 때마다 설정해야 한다.

모듈을 생성할 때 모듈 최종 사용자에게 입력 변수로 표시할 리소스 인수를 고려해야한다. 예를 들어, 웹 사이트를 호스트하기 위해 버킷의 ACL을 public-read으로 설정해야 하므로 색인 및 오류 문서를 변수로 이 모듈의 최종 사용자에게 표시하지만, ACL을 설정하는 변수를 선언하지 않을 수 있다.

ouput은 사용자가 모듈에 의해 구성된 리소스에 대한 정보를 얻을 수 있는 유일한 방법이기 때문에 출력으로 추가할 값을 고려해야 한다.

modules/aws-s3-static-static-module-module 디렉토리 내의 outputs.tf 파일에 출력을 모듈에 추가하자.

# Output variable definitions

output "arn" {
  description = "ARN of the bucket"
  value       = aws_s3_bucket.s3_bucket.arn
}

output "name" {
  description = "Name (id) of the bucket"
  value       = aws_s3_bucket.s3_bucket.id
}

output "domain" {
  description = "Domain name of the bucket"
  value       = aws_s3_bucket_website_configuration.s3_bucket.website_domain
}

 

변수와 마찬가지로 모듈 ouputs은 root 모듈과 같은 일을 하지만, 다른 방식으로 접근하게 된다. 모듈 ouputs은 read-only이며, access syntax 는 다음과 같다: module.<Moudle 이름>.<Ouput 이름>

 

이제 모듈 설정이 끝났으니 다시 root의 main.tf으로 돌아가서 모듈을 추가해보자.

 

이렇게 source를 보면 우리가 만든 로컬 module를 지정했다는 것을 다시 한 번 확인할 수 있다. 또한 bucket_name 도 unique하게 설정해주었다. 

 

지금 여기서 설정한 buckent_name과 tags 인자들을 모듈로 넘겨주게 되고, 우리가 만든 modules/aws-s3-static-website-bucket/variables.tf에 일치하는 변수에 대한 값을 제공하는 것과 같다.

 

 

로컬 모듈 설치하기

terraform get 명령어로 모듈을 설치하자.

 

버킷에 파일 업로드하기

이제 우리가 만든 static website을 방문하기 위해 파일을 업로드 해보자. 이것도 우리는 깃헙 레포를 클론했기 때문에... 딱히 index.html을 만들 필요 없이 모든게 www 라는 폴더에 준비 되어 있다(아싸)

 

다음 명령어로 버킷에 파일을 업로드해보자

 

aws s3 cp modules/aws-s3-static-website-bucket/www/ s3://$(terraform output -raw website_bucket_name)/ --recursive

 

 

이제 직접 웹사이트를 방문해보자.

예시: https://nayeon-tf-module-test.s3.ap-northeast-2.amazonaws.com/index.html

https://<버킷이름>.s3.<리전이름>/index.html

 

 

아주 잘 된다.

 

이제 모든걸 다 했으니! 다시 모든걸 destory 해주고 끝낸다.

 

끝끝~