✔️ Overview
Terraform으로 인프라를 관리함에 따라 점점 더 복잡한 구성이 생성됩니다. 단일 Terraform 구성 파일 또는 디렉토리의 복잡성에는 본질적인 제한이 없으므로 단일 디렉토리에서 구성 파일을 계속 작성하고 업데이트할 수 있습니다. 그러나 그렇게 하면 다음 문제 중 하나 이상이 발생할 수 있습니다.
- 구성 파일을 이해하고 탐색하는 것이 점점 더 어려워질 것입니다.
- 한 블록을 업데이트하면 구성의 다른 블록에 의도하지 않은 결과가 발생할 수 있으므로 구성 업데이트는 더 위험해집니다.
- 예를 들어, 별도의 개발/스테이징/프로덕션 환경을 구성할 때 유사한 구성 블록의 중복이 증가할 수 있으며, 이는 구성의 해당 부분을 업데이트할 때 부담을 증가시킵니다.
- 프로젝트와 팀 간에 구성의 일부를 공유하려는 경우 프로젝트 간에 구성 블록을 잘라내어 붙여넣는 것은 오류가 발생하기 쉽고 유지 관리하기 어려울 수 있습니다.
이 실습에서는 모듈이 이러한 문제를 해결할 수 있는 방법, Terraform 모듈의 구조, 모듈을 사용 및 생성할 때의 모범 사례를 배웁니다.
✔️ What are modules for?
모듈이 위에 나열된 문제를 해결하는 데 도움이 되는 몇 가지 방법은 다음과 같습니다.
- Organize configuration : 모듈을 사용하면 구성의 관련 부분을 함께 유지하여 구성을 보다 쉽게 탐색, 이해 및 업데이트할 수 있습니다. 적당히 복잡한 인프라라도 구현하려면 수백 또는 수천 줄의 구성이 필요할 수 있습니다. 모듈을 사용하여 구성을 논리적 구성 요소로 구성할 수 있습니다.
- Encapsulation configuration : 모듈 사용의 또 다른 이점은 구성을 별개의 논리적 구성 요소로 캡슐화하는 것입니다. 캡슐화를 사용하면 구성의 한 부분이 변경되어 우발적으로 다른 인프라가 변경되는 것과 같은 의도하지 않은 결과를 방지하고 두 개의 다른 리소스에 동일한 이름을 사용하는 것과 같은 단순한 오류의 가능성을 줄일 수 있습니다.
- Re-use configuration : 기존 코드를 사용하지 않고 모든 구성을 작성하면 시간이 많이 걸리고 오류가 발생하기 쉽습니다. 모듈을 사용하면 자신, 팀의 다른 구성원 또는 사용할 모듈을 게시한 다른 Terraform 실무자가 작성한 구성을 재사용하여 시간을 절약하고 비용이 많이 드는 오류를 줄일 수 있습니다. 또한 작성한 모듈을 팀이나 일반 대중과 공유하여 노력의 이점을 얻을 수 있습니다.
- Provide consistency and ensure best practices : 모듈은 또한 구성의 일관성을 제공하는 데 도움이 됩니다. 일관성을 통해 복잡한 구성을 더 쉽게 이해할 수 있으며 모범 사례를 모든 구성에 적용할 수 있습니다. 예를 들어, 클라우드 공급자는 Amazon S3(Simple Storage Service) 또는 Google의 Cloud Storage 버킷과 같은 객체 스토리지 서비스를 구성하기 위한 다양한 옵션을 제공합니다. 세간의 이목을 끄는 많은 보안 사고에는 잘못 보안된 개체 저장소가 관련되어 있으며 관련된 복잡한 구성 옵션이 많기 때문에 이러한 서비스를 실수로 잘못 구성하기 쉽습니다.
모듈을 사용하면 이러한 오류를 줄이는 데 도움이 될 수 있습니다. 예를 들어 조직의 모든 공개 웹 사이트 버킷이 구성되는 방법을 설명하는 모듈과 로깅 애플리케이션에 사용되는 비공개 버킷에 대한 또 다른 모듈을 만들 수 있습니다. 또한 리소스 유형에 대한 구성을 업데이트해야 하는 경우 모듈을 사용하면 한 곳에서 해당 업데이트를 수행하고 해당 모듈을 사용하는 모든 경우에 적용할 수 있습니다.
✔️ 실습 목표
이 실습에서는 다음 작업을 수행하는 방법을 배웁니다.
- 레지스트리의 모듈 사용
- 모듈 빌드
✔️ What is a Terraform module?
Terraform 모듈은 단일 디렉토리에 있는 Terraform 구성 파일 세트입니다. 하나 이상의 .tf 파일이 있는 단일 디렉토리로 구성된 간단한 구성도 모듈입니다. 이러한 디렉토리에서 직접 Terraform 명령을 실행하면 루트 모듈로 간주됩니다. 따라서 이러한 의미에서 모든 Terraform 구성은 모듈의 일부입니다. 다음과 같은 간단한 Terraform 구성 파일 세트가 있을 수 있습니다.
$ tree minimal-module/
.
├── LICENSE
├── README.md
├── main.tf
├── variables.tf
├── outputs.tf
이 경우 최소 모듈 디렉토리 내에서 Terraform 명령을 실행하면 해당 디렉토리의 내용이 루트 모듈로 간주됩니다.
✔️ Calling modules
Terraform 명령은 일반적으로 현재 작업 디렉토리인 한 디렉토리의 구성 파일만 직접 사용합니다.
그러나 구성에서 모듈 블록을 사용하여 다른 디렉토리의 모듈을 호출할 수 있습니다. Terraform은 모듈 블록을 만나면 해당 모듈의 구성 파일을 로드하고 처리합니다.
다른 구성에서 호출되는 모듈을 해당 구성의 "하위 모듈"이라고 하는 경우가 있습니다.
✔️ Local and remote modules
모듈은 로컬 파일 시스템이나 원격 소스에서 로드할 수 있습니다. Terraform은 Terraform 레지스트리, 대부분의 버전 제어 시스템, HTTP URL, Terraform Cloud 또는 Terraform Enterprise 개인 모듈 레지스트리를 포함한 다양한 원격 소스를 지원합니다.
✔️ Module best practices
여러 면에서 Terraform 모듈은 대부분의 프로그래밍 언어에서 볼 수 있는 라이브러리, 패키지 또는 모듈의 개념과 유사하며 많은 동일한 이점을 제공합니다. 거의 모든 중요하지 않은 컴퓨터 프로그램과 마찬가지로 실제 Terraform 구성은 위에서 언급한 이점을 제공하기 위해 거의 항상 모듈을 사용해야 합니다.
모든 Terraform 실무자는 다음 모범 사례에 따라 모듈을 사용하는 것이 좋습니다.
모듈 계획으로 구성 작성을 시작하십시오. 한 사람이 관리하는 약간 복잡한 Terraform 구성의 경우에도 모듈 사용의 이점은 모듈을 올바르게 사용하는 데 걸리는 시간보다 큽니다.
로컬 모듈을 사용하여 코드를 구성하고 캡슐화합니다. 원격 모듈을 사용하거나 게시하지 않더라도 처음부터 모듈 측면에서 구성을 구성하면 인프라가 복잡해짐에 따라 구성을 유지 관리하고 업데이트하는 부담을 크게 줄일 수 있습니다.
공개 Terraform 레지스트리를 사용하여 유용한 모듈을 찾으십시오. 이렇게 하면 다른 사람의 작업에 의존하여 구성을 빠르고 자신 있게 구현할 수 있습니다.
모듈을 게시하고 팀과 공유하십시오. 대부분의 인프라는 사람들로 구성된 팀에 의해 관리되며 모듈은 팀이 인프라를 만들고 유지 관리하는 데 사용할 수 있는 중요한 도구입니다. 앞서 언급했듯이 공개 또는 비공개로 모듈을 게시할 수 있습니다. 이 시리즈의 이후 실습에서 이 작업을 수행하는 방법을 볼 수 있습니다.
✔️ Task 1. Use modules from the Registry
이 섹션에서는 Terraform Registry의 모듈을 사용하여 GCP에서 예시 환경을 프로비저닝합니다. 여기에서 사용하는 개념은 모든 소스의 모든 모듈에 적용됩니다.
새 브라우저 탭 또는 창에서 Terraform 네트워크 모듈에 대한 Terraform 레지스트리 페이지를 엽니다. 페이지는 다음과 같습니다.
이 페이지에는 모듈에 대한 정보와 소스 리포지토리에 대한 링크가 포함되어 있습니다. 페이지 오른쪽에는 모듈 버전을 선택하기 위한 드롭다운 인터페이스와 인프라를 프로비저닝하기 위해 모듈을 사용하기 위한 지침이 포함되어 있습니다.
모듈을 호출할 때 소스 인수가 필요합니다. 이 예에서 Terraform은 주어진 문자열과 일치하는 Terraform 레지스트리의 모듈을 검색합니다. 모듈 소스에 대한 URL 또는 로컬 파일 경로를 사용할 수도 있습니다. 가능한 모듈 소스 목록은 Terraform 설명서를 참조하십시오.
여기에 표시된 다른 인수는 버전입니다. 지원되는 소스의 경우 버전을 통해 로드할 모듈 버전을 정의할 수 있습니다. 이 실습에서는 사용하는 모듈의 정확한 버전 번호를 지정합니다. 모듈 문서에서 버전을 지정하는 더 많은 방법에 대해 읽을 수 있습니다.
모듈 블록에 대한 다른 인수는 모듈에 대한 입력 변수로 처리됩니다.
✔️ Create a Terraform configuration
1. 시작하려면 Cloud Shell에서 다음 명령어를 실행하여 Google Terraform 모듈 GitHub 리포지토리에서 예제 단순 프로젝트를 복제하고 v3.3.0 분기로 전환합니다.
이렇게 하면 올바른 버전 번호를 사용하고 있는지 확인할 수 있습니다.
2. Cloud Shell 도구 모음에서 편집기 열기를 클릭합니다. Cloud Shell과 코드 편집기 간에 전환하려면 필요에 따라 편집기 열기 또는 터미널 열기를 클릭하거나 새 창에서 열기를 클릭하여 편집기를 별도의 탭에 열어 둡니다.
3. 편집기에서 terraform-google-network/examples/simple_project로 이동하고 main.tf 파일을 엽니다. main.tf 구성은 다음과 같습니다.
이 구성에는 몇 가지 중요한 블록이 포함됩니다.
- provider "google"은 공급자를 정의합니다.
- locals는 세 서브넷의 이름입니다. 로컬 값은 표현식에 이름을 할당하므로 표현식을 반복하지 않고 모듈 내에서 여러 번 사용할 수 있습니다.
- "test-vpc-module" 모듈은 나머지 인프라에 네트워킹 서비스를 제공하는 Virtual Private Cloud(VPC)를 정의합니다.
✔️ Set values for module input variables
일부 입력 변수가 필요합니다. 이는 모듈이 기본값을 제공하지 않음을 의미합니다. Terraform이 올바르게 실행되려면 명시적 값을 제공해야 합니다.
1. 모듈 "test-vpc-module" 블록 내에서 설정 중인 입력 변수를 검토합니다. 이러한 각 입력 변수는 Terraform 레지스트리에 문서화되어 있습니다. 이 모듈에 필요한 입력은 다음과 같습니다.
- network_name: 생성 중인 네트워크의 이름
- project_id: 이 VPC가 생성될 프로젝트의 ID
- 서브넷: 생성 중인 서브넷 목록
대부분의 모듈을 사용하려면 입력 변수를 모듈 구성에 전달해야 합니다. 모듈을 호출하는 구성은 모듈 블록에 인수로 전달되는 입력 값 설정을 담당합니다. 소스 및 버전을 제외하고 모듈 블록에 대한 대부분의 인수는 변수 값을 설정합니다.
GCP 네트워크 모듈의 Terraform 레지스트리 페이지에서 입력 탭은 모듈이 지원하는 모든 입력 변수를 설명합니다.
✔️ Define root input variables
모듈과 함께 입력 변수를 사용하는 것은 모든 Terraform 구성에서 변수를 사용하는 방법과 매우 유사합니다. 일반적인 패턴은 미래에 변경하려는 모듈 입력 변수를 식별한 다음 적절한 기본값을 사용하여 구성의 variables.tf 파일에 일치하는 변수를 만드는 것입니다. 그런 다음 해당 변수를 모듈 블록에 인수로 전달할 수 있습니다.
1. 프로젝트 ID를 검색하려면 Cloud Shell에서 다음 명령어를 실행하세요.
gcloud config list --format 'value(core.project)'
2. Editor에서 여전히 같은 디렉토리에 있는 variables.tf로 이동합니다.
3. 이전 명령의 출력으로 변수 project_id를 채우십시오. 아래 형식을 따라야 하며 변수의 기본값을 설정해야 합니다.
variable "project_id" {
description = "The project ID to host the network in"
default = "FILL IN YOUR PROJECT ID HERE"
}
4. variables.tf에서 network_name 변수를 입력합니다. example-vpc라는 이름이나 원하는 다른 이름을 사용할 수 있습니다. 아래 형식을 따라야 하며 변수의 기본값을 설정해야 합니다.
variable "network_name" {
description = "The name of the VPC network being created"
default = "example-vpc"
}
✔️ Define root output values
모듈에는 output 키워드를 사용하여 모듈 내에서 정의된 출력 값도 있습니다. module.<MODULE NAME>.<OUTPUT NAME>을 참조하여 액세스할 수 있습니다. 입력 변수와 마찬가지로 모듈 출력은 Terraform 레지스트리의 출력 탭 아래에 나열됩니다.
모듈 출력은 일반적으로 구성의 다른 부분으로 전달되거나 루트 모듈의 출력으로 정의됩니다. 이 실습에서는 두 가지 용도를 모두 볼 수 있습니다.
1. 구성 디렉토리에 있는 output.tf 파일로 이동합니다. 파일에 다음이 포함되어 있는지 확인합니다.
✔️ Provision infrastructure
1. Cloud Shell에서 simple_project 디렉터리로 이동합니다.
cd ~/terraform-google-network/examples/simple_project
2. Terraform 구성을 초기화합니다.
terraform init
3. VPC 생성:
terraform apply
4. 변경 사항을 적용하고 계속하려면 프롬프트에 yes로 응답하십시오.
엄청난! 첫 번째 모듈을 사용했습니다. 구성의 출력은 다음과 같아야 합니다.
✔️ Understand how modules work
새 모듈을 처음 사용하는 경우 terraform init 또는 terraform get을 실행하여 모듈을 설치해야 합니다. 이러한 명령 중 하나가 실행되면 Terraform은 구성의 작업 디렉토리 내의 .terraform/modules 디렉토리에 모든 새 모듈을 설치합니다. 로컬 모듈의 경우 Terraform은 모듈 디렉토리에 대한 심볼릭 링크를 생성합니다. 이 때문에 terraform get을 다시 실행할 필요 없이 로컬 모듈에 대한 모든 변경 사항이 즉시 적용됩니다.
✔️ Clean up your infrastructure
이제 Terraform 레지스트리에서 모듈을 사용하는 방법, 입력 변수로 해당 모듈을 구성하는 방법, 해당 모듈에서 출력 값을 가져오는 방법을 살펴보았습니다.
1. 생성한 인프라를 파괴합니다.
terraform destroy
2. 프롬프트에 yes로 응답합니다. Terraform은 귀하가 만든 인프라를 파괴합니다.
✔️ Task 2. Build a module
마지막 작업에서는 Terraform Registry의 모듈을 사용하여 GCP에 VPC 네트워크를 만들었습니다. 기존 Terraform 모듈을 올바르게 사용하는 것이 중요한 기술이지만 모든 Terraform 실무자는 모듈을 만드는 방법을 배우는 것도 도움이 될 것입니다. 모든 Terraform 구성을 모듈로 사용할 수 있다는 가정 하에 생성하는 것이 좋습니다. 이렇게 하면 구성을 유연하고 재사용 가능하며 구성할 수 있도록 설계하는 데 도움이 되기 때문입니다.
이미 알고 계시겠지만 Terraform은 모든 구성을 모듈로 취급합니다. Terraform 명령을 실행하거나 Terraform Cloud 또는 Terraform Enterprise를 사용하여 원격으로 Terraform을 실행할 때 Terraform 구성이 포함된 대상 디렉토리는 루트 모듈로 처리됩니다.
이 작업에서는 정적 웹 사이트를 호스팅하는 데 사용되는 Compute Storage 버킷을 관리하는 모듈을 생성합니다.
✔️ Module structure
Terraform은 모듈 블록의 소스 인수에서 참조하는 모든 로컬 디렉토리를 모듈로 취급합니다. 새 모듈의 일반적인 파일 구조는 다음과 같습니다.
$ tree minimal-module/
.
├── LICENSE
├── README.md
├── main.tf
├── variables.tf
├── outputs.tf
이러한 파일 중 어느 것도 필요하지 않거나 모듈을 사용할 때 Terraform에 특별한 의미가 없습니다.
단일 .tf 파일로 모듈을 생성하거나 원하는 다른 파일 구조를 사용할 수 있습니다.
이러한 각 파일은 다음과 같은 용도로 사용됩니다.
- LICENSE에는 모듈이 배포되는 라이센스가 포함됩니다. 모듈을 공유할 때 LICENSE 파일을 사용하는 사람들이 모듈을 사용할 수 있게 된 조건을 알 수 있습니다. Terraform 자체는 이 파일을 사용하지 않습니다.
- README.md에는 모듈 사용 방법을 설명하는 마크다운 형식의 문서가 포함되어 있습니다. Terraform은 이 파일을 사용하지 않지만 Terraform Registry 및 GitHub와 같은 서비스는 이 파일의 내용을 모듈의 Terraform Registry 또는 GitHub 페이지 방문자에게 표시합니다.
- main.tf에는 모듈의 기본 구성 세트가 포함되어 있습니다. 다른 구성 파일을 만들고 프로젝트에 적합한 방식으로 구성할 수도 있습니다.
- variables.tf는 모듈에 대한 변수 정의를 포함합니다. 다른 사람이 귀하의 모듈을 사용하는 경우 변수는 모듈 블록의 인수로 구성됩니다. 모든 Terraform 값을 정의해야 하므로 기본값이 없는 변수는 필수 인수가 됩니다. 기본값이 있는 변수를 모듈 인수로 제공하여 기본값을 재정의할 수도 있습니다.
- output.tf는 모듈에 대한 출력 정의를 포함합니다. 모듈 출력은 모듈을 사용하는 구성에서 사용할 수 있으므로 모듈에서 정의한 인프라 부분에 대한 정보를 구성의 다른 부분으로 전달하는 데 자주 사용됩니다.
다음 파일에 유의하고 모듈의 일부로 배포하지 않도록 합니다.
- terraform.tfstate 및 terraform.tfstate.backup 파일에는 Terraform 상태가 포함되어 있으며 Terraform이 구성과 이에 의해 프로비저닝된 인프라 간의 관계를 추적하는 방법입니다.
- .terraform 디렉토리에는 인프라를 프로비저닝하는 데 사용되는 모듈과 플러그인이 포함되어 있습니다. 이러한 파일은 .tf 파일에 정의된 인프라 구성이 아니라 인프라를 프로비저닝할 때 Terraform의 개별 인스턴스에만 해당됩니다.
- *.tfvarsfile은 모듈 입력 변수가 구성의 모듈 블록에 대한 인수를 통해 설정되기 때문에 독립형 Terraform 구성으로도 사용하지 않는 한 모듈과 함께 배포할 필요가 없습니다.
Git과 같은 버전 제어 시스템에서 모듈의 변경 사항을 추적하는 경우 이러한 파일을 무시하도록 버전 제어 시스템을 구성할 수 있습니다. 예를 들어 GitHub의 이 .gitignore 파일을 참조하세요.
Git과 같은 버전 제어 시스템에서 모듈의 변경 사항을 추적하는 경우 이러한 파일을 무시하도록 버전 제어 시스템을 구성할 수 있습니다. 예를 들어 GitHub의 이 .gitignore 파일을 참조하세요.
✔️ Create a module
홈 디렉토리로 이동하고 새 main.tf 구성 파일을 구성하여 루트 모듈을 만듭니다. 그런 다음 gcs-static-website-bucket이라는 다른 폴더가 포함된 모듈이라는 디렉터리를 만듭니다. gcs-static-website-bucket 디렉토리 내에서 세 가지 Terraform 구성 파일(website.tf, variables.tf 및 output.tf)로 작업합니다.
1. 새 모듈의 디렉터리를 만듭니다.
cd ~
touch main.tf
mkdir -p modules/gcs-static-website-bucket
2. 모듈 디렉토리로 이동하고 다음 명령을 실행하여 세 개의 빈 파일을 만듭니다.
cd modules/gcs-static-website-bucket
touch website.tf
touch variables.tf
touch outputs.tf
3. gcs-static-website-bucket 디렉토리 내에서 다음 내용으로 README.md라는 파일을 만듭니다.
# GCS static website bucket
This module provisions Cloud Storage buckets configured for static website hosting.
모듈에 대한 올바른 라이선스를 선택하는 것은 이 실습의 범위를 벗어납니다. 이 실습에서는 Apache 2.0 오픈 소스 라이선스를 사용합니다.
4. 다음 내용으로 LICENSE라는 다른 파일을 만듭니다.
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
이러한 파일 중 어느 것도 Terraform에서 필요하거나 사용하지 않습니다. 다른 사람과 공유할 수 있는 모듈에 대한 모범 사례입니다.
현재 모듈 디렉토리 구조는 이제 다음과 같아야 합니다.
modules/
└── gcs-static-website-bucket
├── LICENSE
├── README.md
├── website.tf
├── outputs.tf
└── variables.tf
5. 이 Cloud Storage 버킷 리소스를 modules/gcs-static-website-bucket 디렉터리의 website.tf 파일에 추가합니다.
resource "google_storage_bucket" "bucket" {
name = var.name
project = var.project_id
location = var.location
storage_class = var.storage_class
labels = var.labels
force_destroy = var.force_destroy
uniform_bucket_level_access = true
versioning {
enabled = var.versioning
}
dynamic "retention_policy" {
for_each = var.retention_policy == null ? [] : [var.retention_policy]
content {
is_locked = var.retention_policy.is_locked
retention_period = var.retention_policy.retention_period
}
}
dynamic "encryption" {
for_each = var.encryption == null ? [] : [var.encryption]
content {
default_kms_key_name = var.encryption.default_kms_key_name
}
}
dynamic "lifecycle_rule" {
for_each = var.lifecycle_rules
content {
action {
type = lifecycle_rule.value.action.type
storage_class = lookup(lifecycle_rule.value.action, "storage_class", null)
}
condition {
age = lookup(lifecycle_rule.value.condition, "age", null)
created_before = lookup(lifecycle_rule.value.condition, "created_before", null)
with_state = lookup(lifecycle_rule.value.condition, "with_state", null)
matches_storage_class = lookup(lifecycle_rule.value.condition, "matches_storage_class", null)
num_newer_versions = lookup(lifecycle_rule.value.condition, "num_newer_versions", null)
}
}
}
}
6. 모듈의 variables.tf 파일로 이동하여 다음 코드를 추가합니다.
variable "name" {
description = "The name of the bucket."
type = string
}
variable "project_id" {
description = "The ID of the project to create the bucket in."
type = string
}
variable "location" {
description = "The location of the bucket."
type = string
}
variable "storage_class" {
description = "The Storage Class of the new bucket."
type = string
default = null
}
variable "labels" {
description = "A set of key/value label pairs to assign to the bucket."
type = map(string)
default = null
}
variable "bucket_policy_only" {
description = "Enables Bucket Policy Only access to a bucket."
type = bool
default = true
}
variable "versioning" {
description = "While set to true, versioning is fully enabled for this bucket."
type = bool
default = true
}
variable "force_destroy" {
description = "When deleting a bucket, this boolean option will delete all contained objects. If false, Terraform will fail to delete buckets which contain objects."
type = bool
default = true
}
variable "iam_members" {
description = "The list of IAM members to grant permissions on the bucket."
type = list(object({
role = string
member = string
}))
default = []
}
variable "retention_policy" {
description = "Configuration of the bucket's data retention policy for how long objects in the bucket should be retained."
type = object({
is_locked = bool
retention_period = number
})
default = null
}
variable "encryption" {
description = "A Cloud KMS key that will be used to encrypt objects inserted into this bucket"
type = object({
default_kms_key_name = string
})
default = null
}
variable "lifecycle_rules" {
description = "The bucket's Lifecycle Rules configuration."
type = list(object({
# Object with keys:
# - type - The type of the action of this Lifecycle Rule. Supported values: Delete and SetStorageClass.
# - storage_class - (Required if action type is SetStorageClass) The target Storage Class of objects affected by this Lifecycle Rule.
action = any
# Object with keys:
# - age - (Optional) Minimum age of an object in days to satisfy this condition.
# - created_before - (Optional) Creation date of an object in RFC 3339 (e.g. 2017-06-13) to satisfy this condition.
# - with_state - (Optional) Match to live and/or archived objects. Supported values include: "LIVE", "ARCHIVED", "ANY".
# - matches_storage_class - (Optional) Storage Class of objects to satisfy this condition. Supported values include: MULTI_REGIONAL, REGIONAL, NEARLINE, COLDLINE, STANDARD, DURABLE_REDUCED_AVAILABILITY.
# - num_newer_versions - (Optional) Relevant only for versioned objects. The number of newer versions of an object to satisfy this condition.
condition = any
}))
default = []
}
7. 모듈 내부의 output.tf 파일에서 모듈에 출력을 추가합니다.
output "bucket" {
description = "The created storage bucket"
value = google_storage_bucket.bucket
}
변수와 마찬가지로 모듈의 출력은 루트 모듈에서 수행하는 것과 동일한 기능을 수행하지만 다른 방식으로 액세스합니다. 모듈의 출력은 모듈을 호출하는 구성 내에서 사용할 수 있는 모듈 개체의 읽기 전용 속성으로 액세스할 수 있습니다.
8. 루트 디렉토리의 main.tf로 돌아가서 새 모듈에 대한 참조를 추가하십시오.
module "gcs-static-website-bucket" {
source = "./modules/gcs-static-website-bucket"
name = var.name
project_id = var.project_id
location = "us-east1"
lifecycle_rules = [{
action = {
type = "Delete"
}
condition = {
age = 365
with_state = "ANY"
}
}]
}
9. 루트 모듈에 대한 output.tf 파일을 만듭니다.
cd ~
touch outputs.tf
10. output.tf 파일에 다음 코드를 추가합니다.
output "bucket-name" {
description = "Bucket names."
value = "module.gcs-static-website-bucket.bucket"
}
11. variables.tf 파일을 만듭니다.
touch variables.tf
12. variables.tf 파일에 다음 코드를 추가하고 변수 project_id 및 name을 정의합니다.
variable "project_id" {
description = "The ID of the project in which to provision resources."
type = string
default = "FILL IN YOUR PROJECT ID HERE"
}
variable "name" {
description = "Name of the buckets to create."
type = string
default = "FILL IN YOUR (UNIQUE) BUCKET NAME HERE"
}
참고 스토리지 버킷의 이름은 전역적으로 고유해야 합니다. 이름과 날짜를 사용하는 것은 일반적으로 고유한 버킷 이름을 만드는 좋은 방법입니다. 프로젝트 ID를 사용할 수도 있습니다.
✔️ Install the local module
구성에 새 모듈을 추가할 때마다 Terraform은 모듈을 사용하기 전에 먼저 설치해야 합니다. terraform get 및 terraform init 명령은 모두 모듈을 설치하고 업데이트합니다. terraform init 명령은 백엔드도 초기화하고 플러그인을 설치합니다.
1. 모듈 설치하기
terraform init
2. bucket 준비하기
terraform apply
3. 프롬프트에 예라고 응답합니다. 버킷 및 기타 리소스가 프로비저닝됩니다.
✔️ Upload files to the bucket
이제 고유한 모듈을 구성하고 사용하여 정적 웹 사이트를 만들었습니다. 이 정적 웹 사이트를 방문하고 싶을 수 있습니다. 지금은 버킷 내부에 아무것도 없으므로 웹사이트에서 볼 수 있는 것이 없습니다. 콘텐츠를 보려면 버킷에 객체를 업로드해야 합니다. GitHub 리포지토리에서 www 디렉터리의 콘텐츠를 업로드할 수 있습니다.
1. 샘플 콘텐츠를 홈 디렉토리에 다운로드합니다.
cd ~
curl https://raw.githubusercontent.com/hashicorp/learn-terraform-modules/master/modules/aws-s3-static-website-bucket/www/index.html > index.html
curl https://raw.githubusercontent.com/hashicorp/learn-terraform-modules/blob/master/modules/aws-s3-static-website-bucket/www/error.html > error.html
2. 파일을 버킷에 복사하고 YOUR-BUCKET-NAME을 스토리지 버킷의 이름으로 바꿉니다.
gsutil cp *.html gs://YOUR-BUCKET-NAME
3. 브라우저의 새 탭에서 웹사이트 https://storage.cloud.google.com/YOUR-BUCKET-NAME/index.html로 이동하여 YOUR-BUCKET-NAME을 스토리지 버킷의 이름으로 바꿉니다.
✔️ Clean up the website and infrastructure
마지막으로 방금 만든 인프라를 파괴하여 프로젝트를 정리합니다.
1. Terraform 리소스를 삭제합니다.
terraform destroy
프롬프트에 yes로 응답하면 Terraform은 이 실습을 따라 생성한 모든 리소스를 삭제합니다.
이 실습에서는 Terraform 모듈의 기초와 레지스트리의 기존 모듈을 사용하는 방법을 배웠습니다. 그런 다음 자체 모듈을 빌드하여 Cloud Storage 버킷에서 호스팅되는 정적 웹사이트를 만들었습니다. 이를 통해 구성 파일에 대한 입력, 출력 및 변수를 정의하고 모듈 구축을 위한 모범 사례를 배웠습니다.
'Study > Study Jam' 카테고리의 다른 글
[Study Jam] Multiple VPC Networks - 2 (0) | 2022.03.29 |
---|---|
[Study Jam] Multiple VPC Networks - 1 (0) | 2022.03.29 |
[Study Jam] Infrastructure as Code with Terraform (0) | 2022.03.27 |
[Study Jam] Terraform Fundamentals (0) | 2022.03.27 |
[Study Jam] Continuous Delivery with Jenkins in Kubernetes Engine - 2 (0) | 2022.03.25 |
영차영차 성장 블로그
포스팅이 좋았다면 "좋아요❤️" 또는 "구독👍🏻" 해주세요!