이 실습은 Google Cloud의 파트너인 HashiCorp와 공동 개발한 것으로 계정 프로필에서 제품 업데이트, 공지사항, 혜택을 수신하는 데 동의하신 경우 귀하의 개인 정보가 실습 스폰서인 HashiCorp에 공유될 수 있습니다.

GSP751

개요

Terraform으로 인프라를 관리할수록 점점 더 복잡한 구성이 만들어집니다. 단일 Terraform 구성 파일 또는 디렉터리의 복잡성에는 기본 제한이 없으므로 단일 디렉터리에 구성 파일을 계속 작성하고 업데이트할 수 있습니다. 그러나 그렇게 할 경우 다음 문제 중 하나 이상이 발생할 수 있습니다.

• 구성 파일을 이해하고 탐색하는 것이 점점 더 어려워질 것입니다.
• 한 블록을 업데이트하면 구성의 다른 블록에 의도하지 않은 결과를 초래할 수 있으므로 구성 업데이트가 더 위험해집니다.
• 예를 들어 개발/스테이징/프로덕션 환경을 별도로 구성하는 경우 유사한 구성 블록의 중복이 증가하여 해당 구성 부분을 업데이트할 때 부담이 커질 수 있습니다.
• 프로젝트와 팀 간에 구성의 일부를 공유하려는 경우, 프로젝트 간에 구성 블록을 잘라서 붙여넣으면 오류가 발생하기 쉽고 유지 관리가 어려울 수 있습니다.

이 실습에서는 모듈로 이러한 문제를 해결하는 방법, Terraform 모듈의 구조, 모듈 사용 및 생성 시 권장사항에 대해 알아봅니다.

모듈의 용도는 무엇인가요?

모듈이 위에 나열된 문제를 해결하는 데 도움이 되는 몇 가지 방법을 소개합니다.

• 구성 정리: 모듈을 사용하면 구성의 관련 부분을 함께 보관하여 구성을 더 쉽게 탐색하고, 이해하고, 업데이트할 수 있습니다. 다소 복잡한 인프라라도 구현하려면 수백, 수천 줄의 구성을 구현해야 할 수 있습니다. 모듈을 사용하면 구성을 논리적 구성요소로 정리할 수 있습니다.

• 구성 캡슐화: 모듈 사용의 또 다른 이점은 구성을 별개의 논리적 구성요소로 캡슐화할 수 있다는 점입니다. 캡슐화는 구성의 한 부분을 변경하여 실수로 다른 인프라가 변경되는 등의 의도치 않은 결과를 방지하고, 서로 다른 두 리소스에 동일한 이름을 사용하는 것과 같은 단순한 오류의 가능성을 줄이는 데 도움이 될 수 있습니다.

• 구성 재사용: 기존 코드를 사용하지 않고 모든 구성을 작성하면 시간이 많이 걸리고 오류가 발생하기 쉽습니다. 모듈을 사용하면 본인이나 다른 팀원 또는 여러분이 사용할 수 있도록 모듈을 게시한 다른 Terraform 실무자가 작성한 구성을 재사용하여 시간을 절약하고 비용이 많이 드는 오류를 줄일 수 있습니다. 또한 작성한 모듈을 팀이나 일반 대중과 공유하여 여러분이 열심히 만든 혜택을 제공할 수도 있습니다.

• 일관성 제공 및 권장사항 보장: 모듈은 구성에 일관성을 제공하는 데도 도움이 됩니다. 일관성을 유지하면 복잡한 구성을 더 쉽게 이해할 수 있으며, 모든 구성에 권장사항이 적용되도록 하는 데도 도움이 됩니다. 예를 들어, 클라우드 제공업체는 Amazon S3(Simple Storage Service) 또는 Google의 Cloud Storage 버킷과 같은 객체 스토리지 서비스를 구성할 수 있는 다양한 옵션을 제공합니다. 인지도 높은 많은 보안 사고는 보안이 잘못 설정된 객체 스토리지와 관련이 있으며, 복잡한 구성 옵션의 수 때문에 실수로 이러한 서비스를 잘못 구성하기 쉽습니다.

모듈을 사용하면 이러한 오류를 줄일 수 있습니다. 예를 들어, 조직의 모든 공개 웹사이트 버킷을 구성하는 방법을 설명하는 모듈과 로깅 애플리케이션에 사용되는 비공개 버킷을 위한 또 다른 모듈을 만들 수 있습니다. 또한 리소스 유형에 대한 구성을 업데이트해야 하는 경우 모듈을 사용하면 한곳에서 업데이트하고 해당 모듈을 사용하는 모든 사례에 적용할 수 있습니다.

목표

이 실습에서는 다음 작업을 실행하는 방법을 알아봅니다.

• 레지스트리의 모듈 사용하기
• 모듈 빌드하기

설정 및 요건

실습 시작 버튼을 클릭하기 전에

다음 안내를 확인하세요. 실습에는 시간 제한이 있으며 일시중지할 수 없습니다. 실습 시작을 클릭하면 타이머가 시작됩니다. 이 타이머에는 Google Cloud 리소스를 사용할 수 있는 시간이 얼마나 남았는지 표시됩니다.

실무형 실습을 통해 시뮬레이션이나 데모 환경이 아닌 실제 클라우드 환경에서 직접 실습 활동을 진행할 수 있습니다. 실습 시간 동안 Google Cloud에 로그인하고 액세스하는 데 사용할 수 있는 새로운 임시 사용자 인증 정보가 제공됩니다.

이 실습을 완료하려면 다음을 준비해야 합니다.

• 표준 인터넷 브라우저 액세스 권한(Chrome 브라우저 권장)

참고: 이 실습을 실행하려면 시크릿 모드 또는 시크릿 브라우저 창을 사용하세요. 개인 계정과 학생 계정 간의 충돌로 개인 계정에 추가 요금이 발생하는 일을 방지해 줍니다.

• 실습을 완료하기에 충분한 시간---실습을 시작하고 나면 일시중지할 수 없습니다.

참고: 계정에 추가 요금이 발생하지 않도록 하려면 개인용 Google Cloud 계정이나 프로젝트가 이미 있어도 이 실습에서는 사용하지 마세요.

실습을 시작하고 Google Cloud 콘솔에 로그인하는 방법

1. 실습 시작 버튼을 클릭합니다. 실습 비용을 결제해야 하는 경우 결제 수단을 선택할 수 있는 팝업이 열립니다. 왼쪽에는 다음과 같은 항목이 포함된 실습 세부정보 패널이 있습니다.

   • Google Cloud 콘솔 열기 버튼
   • 남은 시간
   • 이 실습에 사용해야 하는 임시 사용자 인증 정보
   • 필요한 경우 실습 진행을 위한 기타 정보

2. Google Cloud 콘솔 열기를 클릭합니다(Chrome 브라우저를 실행 중인 경우 마우스 오른쪽 버튼으로 클릭하고 시크릿 창에서 링크 열기를 선택합니다).

   실습에서 리소스가 가동되면 다른 탭이 열리고 로그인 페이지가 표시됩니다.

   팁: 두 개의 탭을 각각 별도의 창으로 나란히 정렬하세요.

   참고: 계정 선택 대화상자가 표시되면 다른 계정 사용을 클릭합니다.

3. 필요한 경우 아래의 사용자 이름을 복사하여 로그인 대화상자에 붙여넣습니다.

   {{{user_0.username | "Username"}}}

   실습 세부정보 패널에서도 사용자 이름을 확인할 수 있습니다.

4. 다음을 클릭합니다.

5. 아래의 비밀번호를 복사하여 시작하기 대화상자에 붙여넣습니다.

   {{{user_0.password | "Password"}}}

   실습 세부정보 패널에서도 비밀번호를 확인할 수 있습니다.

6. 다음을 클릭합니다.

   중요: 실습에서 제공하는 사용자 인증 정보를 사용해야 합니다. Google Cloud 계정 사용자 인증 정보를 사용하지 마세요. 참고: 이 실습에 자신의 Google Cloud 계정을 사용하면 추가 요금이 발생할 수 있습니다.

7. 이후에 표시되는 페이지를 클릭하여 넘깁니다.

   • 이용약관에 동의합니다.
   • 임시 계정이므로 복구 옵션이나 2단계 인증을 추가하지 않습니다.
   • 무료 체험판을 신청하지 않습니다.

잠시 후 Google Cloud 콘솔이 이 탭에서 열립니다.

참고: Google Cloud 제품 및 서비스 목록이 있는 메뉴를 보려면 왼쪽 상단의 탐색 메뉴를 클릭합니다.

Cloud Shell 활성화

Cloud Shell은 다양한 개발 도구가 탑재된 가상 머신으로, 5GB의 영구 홈 디렉터리를 제공하며 Google Cloud에서 실행됩니다. Cloud Shell을 사용하면 명령줄을 통해 Google Cloud 리소스에 액세스할 수 있습니다.

1. Google Cloud 콘솔 상단에서 Cloud Shell 활성화 를 클릭합니다.

연결되면 사용자 인증이 이미 처리된 것이며 프로젝트가 PROJECT_ID로 설정됩니다. 출력에 이 세션의 PROJECT_ID를 선언하는 줄이 포함됩니다.

Your Cloud Platform project in this session is set to YOUR_PROJECT_ID

gcloud는 Google Cloud의 명령줄 도구입니다. Cloud Shell에 사전 설치되어 있으며 명령줄 자동 완성을 지원합니다.

2. (선택사항) 다음 명령어를 사용하여 활성 계정 이름 목록을 표시할 수 있습니다.

gcloud auth list

3. 승인을 클릭합니다.

4. 다음과 비슷한 결과가 출력됩니다.

출력:

ACTIVE: * ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net To set the active account, run: $ gcloud config set account `ACCOUNT`

5. (선택사항) 다음 명령어를 사용하여 프로젝트 ID 목록을 표시할 수 있습니다.

gcloud config list project

출력:

[core] project = <project_ID>

출력 예시:

[core] project = qwiklabs-gcp-44776a13dea667a6 참고: gcloud 전체 문서는 Google Cloud에서 gcloud CLI 개요 가이드를 참조하세요.

Terraform 모듈이란 무엇일까요?

Terraform 모듈은 단일 디렉터리에 있는 Terraform 구성 파일의 집합입니다. 하나 이상의 .tf 파일이 있는 단일 디렉터리로 구성된 간단한 구성도 모듈입니다. 이러한 디렉터리에서 직접 Terraform 명령어를 실행하면 해당 디렉터리는 루트 모듈로 간주됩니다. 이런 의미에서 모든 Terraform 구성은 모듈의 일부입니다. 다음과 같은 간단한 Terraform 구성 파일 세트가 있을 수 있습니다.

├── LICENSE ├── README.md ├── main.tf ├── variables.tf ├── outputs.tf

이 경우 minimal-module 디렉터리 내에서 Terraform 명령어를 실행하면 해당 디렉터리의 콘텐츠가 루트 모듈로 간주됩니다.

호출 모듈

Terraform 명령어는 일반적으로 현재 작업 디렉터리인 하나의 디렉터리에 있는 구성 파일만 직접 사용합니다. 그러나 구성에서 모듈 블록을 사용하여 다른 디렉터리에 있는 모듈을 호출할 수 있습니다. Terraform이 모듈 블록을 발견하면 해당 모듈의 구성 파일을 로드하고 처리합니다.

다른 구성에서 호출하는 모듈을 해당 구성의 '하위 모듈'이라고 부르기도 합니다.

로컬 및 원격 모듈

모듈은 로컬 파일 시스템 또는 원격 소스에서 로드할 수 있습니다. Terraform은 Terraform 레지스트리, 대부분의 버전 제어 시스템, HTTP URL, Terraform Cloud 또는 Terraform Enterprise 비공개 모듈 레지스트리를 비롯한 다양한 원격 소스를 지원합니다.

모듈 권장사항

여러 가지 면에서 Terraform 모듈은 대부분의 프로그래밍 언어에서 볼 수 있는 라이브러리, 패키지 또는 모듈의 개념과 유사하며, 동일한 이점을 많이 제공합니다. 중요한 컴퓨터 프로그램과 거의 마찬가지로, 실제 Terraform 구성은 위에서 언급한 이점을 제공하기 위해 거의 항상 모듈을 사용해야 합니다.

모든 Terraform 실무자는 다음 권장사항을 따라 모듈을 사용하는 것이 좋습니다.

• 모듈에 대한 계획으로 구성을 작성합니다. 한 사람이 관리하는 다소 복잡한 Terraform 구성의 경우에도 모듈 사용의 이점은 모듈을 제대로 사용하는 데 걸리는 시간에 비해 훨씬 큽니다.

• 로컬 모듈을 사용하여 코드를 정리하고 캡슐화합니다. 원격 모듈을 사용하거나 게시하지 않더라도 처음부터 모듈을 기준으로 구성을 갖추면 인프라가 복잡해져도 구성을 유지 관리하고 업데이트해야 하는 부담을 크게 줄일 수 있습니다.

• 유용한 모듈을 찾으려면 공개 Terraform 레지스트리를 사용합니다. 이렇게 하면 다른 사람의 작업에 의존하여 빠르고 확실하게 구성을 구현할 수 있습니다.

• 모듈을 게시하고 팀과 공유합니다. 대부분의 인프라는 팀이 관리하며, 모듈은 팀이 인프라를 만들고 유지 관리하는 데 사용할 수 있는 중요한 도구입니다. 앞서 언급했듯이 모듈은 공개 또는 비공개로 게시할 수 있습니다. 이 시리즈의 후반부 실습에서 이 작업을 수행하는 방법을 알아보겠습니다.

작업 1. 레지스트리에서 모듈 사용하기

이 섹션에서는 Terraform 레지스트리의 모듈을 사용하여 Google Cloud에서 예시 환경을 프로비저닝합니다. 여기서 사용하는 개념은 모든 소스의 모든 모듈에 적용됩니다.

• 새 브라우저 탭 또는 창에서 Terraform 네트워크 모듈에 대한 Terraform 레지스트리 페이지를 엽니다. 페이지는 다음과 같이 표시됩니다.

이 페이지에는 모듈에 대한 정보와 소스 저장소에 대한 링크가 포함되어 있습니다. 페이지 오른쪽에는 모듈 버전을 선택할 수 있는 드롭다운 인터페이스와 모듈을 사용하여 인프라를 프로비저닝하는 방법에 대한 안내가 있습니다.

모듈을 호출할 때 source 인수는 필수입니다. 이 예시에서 Terraform은 주어진 문자열과 일치하는 Terraform 레지스트리에서 모듈을 검색합니다. 모듈의 소스로 URL 또는 로컬 파일 경로를 사용할 수도 있습니다. 가능한 모듈 소스 목록은 Terraform 문서를 참조하세요.

여기에 표시된 다른 인수는 version입니다. 지원되는 소스의 경우 버전을 통해 로드할 모듈의 버전을 정의할 수 있습니다. 이 실습에서는 사용하는 모듈의 정확한 버전 번호를 지정합니다. 버전을 지정하는 더 많은 방법은 모듈 문서에서 확인할 수 있습니다.

모듈 블록에 대한 다른 인수는 모듈에 대한 입력 변수로 취급됩니다.

Terraform 구성 만들기

1. 시작하려면 Cloud Shell에서 다음 명령어를 실행하여 Google Terraform 모듈 GitHub 저장소에서 간단한 프로젝트 예제를 복제하고 v6.0.1 브랜치로 전환합니다.

git clone https://github.com/terraform-google-modules/terraform-google-network cd terraform-google-network git checkout tags/v6.0.1 -b v6.0.1

이렇게 하면 올바른 버전 번호를 사용하고 있는지 확인할 수 있습니다.

2. Cloud Shell 툴바에서 편집기 열기를 클릭합니다. Cloud Shell과 코드 편집기 사이를 전환하려면 필요에 따라 편집기 열기 또는 터미널 열기를 클릭하거나, 새 창에서 열기를 클릭해 편집기를 별도의 탭에서 열면 됩니다.

3. 편집기에서 terraform-google-network/examples/simple_project로 이동하고 main.tf 파일을 엽니다. main.tf 구성은 다음과 같습니다.

module "test-vpc-module" { source = "terraform-google-modules/network/google" version = "~> 6.0" project_id = var.project_id # Replace this with your project ID network_name = "my-custom-mode-network" mtu = 1460 subnets = [ { subnet_name = "subnet-01" subnet_ip = "10.10.10.0/24" subnet_region = "us-west1" }, { subnet_name = "subnet-02" subnet_ip = "10.10.20.0/24" subnet_region = "us-west1" subnet_private_access = "true" subnet_flow_logs = "true" }, { subnet_name = "subnet-03" subnet_ip = "10.10.30.0/24" subnet_region = "us-west1" subnet_flow_logs = "true" subnet_flow_logs_interval = "INTERVAL_10_MIN" subnet_flow_logs_sampling = 0.7 subnet_flow_logs_metadata = "INCLUDE_ALL_METADATA" subnet_flow_logs_filter = "false" } ] }

이 구성에는 중요한 블록 하나가 포함되어 있습니다.

• module "test-vpc-module"은 나머지 인프라에 네트워킹 서비스를 제공할 가상 프라이빗 클라우드(VPC)를 정의합니다.

모듈 입력 변수에 대한 값 설정하기

일부 입력 변수가 필요하므로 모듈에서 기본값을 제공하지 않으며, Terraform이 올바르게 실행되려면 명시적인 값을 제공해야 합니다.

• 모듈 "test-vpc-module" 블록 내에서, 설정하고 있는 입력 변수를 검토합니다. 이러한 각 입력 변수는 Terraform 레지스트리에 문서화되어 있습니다. 이 모듈에 필요한 입력은 다음과 같습니다.

  • network_name: 만들고 있는 네트워크의 이름
  • project_id: 이 VPC를 만들 프로젝트의 ID
  • subnets: 만들고 있는 서브넷 목록

대부분의 모듈을 사용하려면 모듈 구성에 입력 변수를 전달해야 합니다. 모듈을 호출하는 구성은 모듈 블록에 인수로 전달되는 입력값을 설정하는 역할을 합니다. source 및 version을 제외하고 모듈 블록에 대한 대부분의 인수는 변수 값을 설정합니다.

Google Cloud 네트워크 모듈의 Terraform 레지스트리 페이지에 있는 입력 탭에는 모듈이 지원하는 모든 입력 변수가 설명되어 있습니다.

루트 입력 변수 정의하기

모듈에서 입력 변수를 사용하는 것은 모든 Terraform 구성에서 변수를 사용하는 방법과 매우 유사합니다. 일반적인 패턴은 향후 변경할 모듈 입력 변수를 식별한 다음, 적절한 기본값을 사용하여 구성의 variables.tf 파일에 일치하는 변수를 생성하는 것입니다. 그런 다음 해당 변수를 모듈 블록에 인수로 전달할 수 있습니다.

1. 프로젝트 ID를 검색하려면 Cloud Shell에서 다음 명령어를 실행합니다.

gcloud config list --format 'value(core.project)'

2. 여전히 같은 디렉터리에 있는 편집기에서 variables.tf로 이동합니다.

3. project_id 변수를 이전 명령어의 출력으로 채웁니다. 아래 형식을 따라 변수의 default 값을 설정해야 합니다.

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 또는 원하는 다른 이름을 사용할 수 있습니다. 아래 형식을 따라 변수의 default 값을 설정해야 합니다.

variable "network_name" { description = "The name of the VPC network being created" default = "example-vpc" }

5. main.tf 파일로 돌아가서 값을 var.network_name으로 설정하여 방금 정의한 변수를 사용하도록 network_name 매개변수를 업데이트합니다.

module "test-vpc-module" { ... project_id = var.project_id network_name = var.network_name ...

6. main.tf 파일에서, 35, 40, 47줄의 서브넷 리전을 us-west1에서 으로 업데이트합니다. 이렇게 하면 프로젝트의 허용된 지역에 서브넷이 생성됩니다. 다음과 유사한 모듈이 표시됩니다.

subnets = [ { subnet_name = "subnet-01" subnet_ip = "10.10.10.0/24" subnet_region = "{{{project_0.default_region | REGION}}}" }, { subnet_name = "subnet-02" subnet_ip = "10.10.20.0/24" subnet_region = "{{{project_0.default_region | REGION}}}" subnet_private_access = "true" subnet_flow_logs = "true" }, { subnet_name = "subnet-03" subnet_ip = "10.10.30.0/24" subnet_region = "{{{project_0.default_region | REGION}}}" ... .. }

루트 출력값 정의하기

모듈에는 output 키워드가 있는 모듈 내에서 정의되는 출력값도 있습니다. module.<MODULE NAME>.<OUTPUT NAME>을 참조하여 액세스할 수 있습니다. 입력 변수와 마찬가지로 모듈 출력은 Terraform 레지스트리의 outputs 탭 아래에 나열됩니다.

모듈 출력은 일반적으로 구성의 다른 부분으로 전달되거나 루트 모듈의 출력으로 정의됩니다. 이 실습에서는 두 가지 용도를 모두 살펴봅니다.

• 구성 디렉터리 안에서 outputs.tf 파일로 이동합니다. 파일에 다음 내용이 포함되어 있는지 확인합니다.

output "network_name" { value = module.test-vpc-module.network_name description = "The name of the VPC being created" } output "network_self_link" { value = module.test-vpc-module.network_self_link description = "The URI of the VPC being created" } output "project_id" { value = module.test-vpc-module.project_id description = "VPC project id" } output "subnets_names" { value = module.test-vpc-module.subnets_names description = "The names of the subnets being created" } output "subnets_ips" { value = module.test-vpc-module.subnets_ips description = "The IP and cidrs of the subnets being created" } output "subnets_regions" { value = module.test-vpc-module.subnets_regions description = "The region where subnets will be created" } output "subnets_private_access" { value = module.test-vpc-module.subnets_private_access description = "Whether the subnets will have access to Google API's without a public IP" } output "subnets_flow_logs" { value = module.test-vpc-module.subnets_flow_logs description = "Whether the subnets will have VPC flow logs enabled" } output "subnets_secondary_ranges" { value = module.test-vpc-module.subnets_secondary_ranges description = "The secondary ranges associated with these subnets" } output "route_names" { value = module.test-vpc-module.route_names description = "The routes associated with this VPC" }

인프라 프로비저닝하기

1. Cloud Shell에서 simple_project 디렉터리로 이동합니다.

cd ~/terraform-google-network/examples/simple_project

2. Terraform 구성을 초기화합니다.

terraform init

3. VPC를 만듭니다.

terraform apply

4. 변경사항을 적용하고 계속하려면 프롬프트에 예로 응답합니다.

수고하셨습니다. 방금 첫 번째 모듈을 사용하셨습니다. 구성의 출력은 다음과 같이 나타납니다.

Outputs: network_name = "example-vpc" network_self_link = "https://www.googleapis.com/compute/v1/projects/qwiklabs-gcp-01-a68489b0625b/global/networks/example-vpc" project_id = "" route_names = [] subnets_flow_logs = [ false, true, true, ] subnets_ips = [ "10.10.10.0/24", "10.10.20.0/24", "10.10.30.0/24", ] subnets_names = [ "subnet-01", "subnet-02", "subnet-03", ] .... ....

모듈의 작동 방식 이해하기

새 모듈을 처음 사용하는 경우, 모듈을 설치하려면 terraform init 또는 terraform get을 실행해야 합니다. 이 명령어 중 하나를 실행하면 Terraform은 구성의 작업 디렉터리 내 .terraform/modules 디렉터리에 새 모듈을 설치합니다. 로컬 모듈의 경우, Terraform은 모듈의 디렉터리에 대한 심볼릭 링크를 생성합니다. 따라서 로컬 모듈에 대한 변경사항은 terraform get을 다시 실행할 필요 없이 즉시 적용됩니다.

인프라 정리하기

지금까지 Terraform 레지스트리에서 모듈을 사용하는 방법, 입력 변수로 모듈을 구성하는 방법, 모듈에서 출력값을 얻는 방법에 대해 알아보았습니다.

1. 생성한 인프라 폐기하기:

terraform destroy

2. 프롬프트에 yes로 응답합니다. Terraform이 생성한 인프라를 폐기합니다.

3. 리소스를 폐기한 후에는 terraform-google-network 폴더를 삭제합니다.

cd ~ rm -rd terraform-google-network -f

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 인프라를 프로비저닝합니다.

작업 2. 모듈 빌드하기

지난 작업에서는 Terraform 레지스트리의 모듈을 사용하여 Google Cloud에서 VPC 네트워크를 만들었습니다. 기존 Terraform 모듈을 올바르게 사용하는 것도 중요한 기술이지만, 모든 Terraform 실무자는 모듈을 만드는 방법을 배우는 것도 도움이 됩니다. 유연하고 재사용 가능하며 구성 가능한 구성을 설계하는 데 도움이 되므로 모든 Terraform 구성을 모듈로 사용할 수 있다고 가정하고 생성하는 것이 좋습니다.

이미 알고 계시겠지만 Terraform은 모든 구성을 모듈로 취급합니다. terraform 명령어를 실행하거나 Terraform Cloud 또는 Terraform Enterprise를 사용하여 원격으로 Terraform을 실행할 때, Terraform 구성이 포함된 대상 디렉터리는 루트 모듈로 취급됩니다.

이 작업에서는 정적 웹사이트를 호스팅하는 데 사용되는 컴퓨팅 스토리지 버킷을 관리하는 모듈을 만듭니다.

모듈 구조

Terraform은 module 블록의 source 인수에 참조된 모든 로컬 디렉터리를 모듈로 취급합니다. 새 모듈의 일반적인 파일 구조는 다음과 같습니다.

├── LICENSE ├── README.md ├── main.tf ├── variables.tf ├── outputs.tf 참고: 이 파일 중 어느 것도 Terraform이 모듈을 사용할 때 필요하거나 특별한 의미를 갖지 않습니다. 단일 .tf 파일로 모듈을 만들거나 원하는 다른 파일 구조를 사용할 수 있습니다.

이러한 파일은 각각 목적에 따라 사용됩니다.

• LICENSE에는 모듈을 배포할 라이선스가 포함되어 있습니다. 모듈을 공유하면 LICENSE 파일을 통해 해당 모듈을 사용하는 사람들에게 해당 모듈을 사용할 수 있는 조건을 알릴 수 있습니다. Terraform 자체는 이 파일을 사용하지 않습니다.
• README.md에는 모듈 사용 방법을 설명하는 마크다운 형식의 문서가 포함되어 있습니다. Terraform은 이 파일을 사용하지 않지만, Terraform 레지스트리 및 GitHub와 같은 서비스에서는 모듈의 Terraform 레지스트리 또는 GitHub 페이지 방문자에게 이 파일의 내용을 표시합니다.
• main.tf에는 모듈의 주요 구성 집합이 포함되어 있습니다. 다른 구성 파일을 만들어 프로젝트에 적합한 방식으로 구성할 수도 있습니다.
• variables.tf에는 모듈에 대한 변수 정의가 포함되어 있습니다. 다른 사람이 내 모듈을 사용할 때 변수는 모듈 블록에서 인수로 구성됩니다. 모든 Terraform 값을 정의해야 하므로 기본값이 없는 변수는 모두 필수 인수가 됩니다. 기본값이 있는 변수를 모듈 인수로 제공하여 기본값을 재정의할 수도 있습니다.
• outputs.tf에는 모듈에 대한 출력 정의가 포함되어 있습니다. 모듈 출력은 모듈을 사용하는 구성에서 사용할 수 있으므로 모듈이 정의한 인프라의 일부에 대한 정보를 구성의 다른 부분으로 전달하는 데 자주 사용됩니다.

이러한 파일을 주의하여 모듈의 일부로 배포하지 않도록 합니다.

• terraform.tfstate 및 terraform.tfstate.backup 파일에는 Terraform 상태가 포함되어 있으며, Terraform이 구성과 이를 통해 프로비저닝된 인프라 간의 관계를 추적하는 방식을 나타냅니다.
• .terraform 디렉터리에는 인프라를 프로비저닝하는 데 사용되는 모듈과 플러그인이 포함되어 있습니다. 이러한 파일은 인프라를 프로비저닝할 때 Terraform의 개별 인스턴스에만 해당하며, .tf 파일에 정의된 인프라의 구성에는 해당하지 않습니다.
• 모듈 입력 변수는 구성의 모듈 블록에 대한 인수를 통해 설정되므로 독립형 Terraform 구성으로도 사용하지 않는 한 모듈과 함께 *.tfvars 파일을 배포할 필요가 없습니다.

참고: Git과 같은 버전 제어 시스템에서 모듈의 변경사항을 추적하는 경우 이러한 파일을 무시하도록 버전 제어 시스템을 구성하는 것이 좋습니다. 예시를 보려면 GitHub에서 이 .gitignore 파일을 참조하세요.

모듈 만들기

홈 디렉터리로 이동하여 새로운 main.tf 구성 파일을 작성하여 루트 모듈을 만듭니다. 그런 다음 모듈이라는 디렉터리를 만드는데, 이 디렉터리에는 gcs-static-website-bucket이라는 다른 폴더가 포함됩니다. gcs-static-website-bucket 디렉터리 내에서 website.tf, variables.tf, outputs.tf의 세 가지 Terraform 구성 파일로 작업하게 됩니다.

1. 새 모듈을 위한 디렉터리를 만듭니다.

cd ~ touch main.tf mkdir -p modules/gcs-static-website-bucket

2. 모듈 디렉터리로 이동하고 다음 명령어를 실행하여 빈 파일 세 개를 만듭니다.

cd modules/gcs-static-website-bucket touch website.tf variables.tf outputs.tf

3. gcs-static-website-bucket 디렉터리에서 다음 명령어를 실행하여 다음 내용이 포함된 README.md라는 파일을 만듭니다.

tee -a README.md <<EOF # GCS static website bucket This module provisions Cloud Storage buckets configured for static website hosting. EOF 참고: 모듈에 적합한 라이선스를 선택하는 것은 이 실습에서 다루지 않습니다. 이 실습에서는 Apache 2.0 오픈소스 라이선스를 사용합니다.

4. 다음 내용으로 LICENSE라는 파일을 하나 더 만듭니다.

tee -a LICENSE <<EOF 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. EOF 참고: 이러한 파일은 Terraform에 필요하지도, 사용되지도 않습니다. 다른 사람들과 공유할 수 있는 모듈의 경우 이 파일을 준비하는 것이 좋습니다.

이제 현재 모듈 디렉터리 구조는 다음과 같습니다.

main.tf 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) } } } }

제공업체 문서는 GitHub에 있습니다.

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. 모듈 내부의 outputs.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 = "{{{project_0.default_region | REGION}}}" lifecycle_rules = [{ action = { type = "Delete" } condition = { age = 365 with_state = "ANY" } }] }

9. 루트 디렉터리에서 루트 모듈에 대한 outputs.tf 파일을 만듭니다.

cd ~ touch outputs.tf

10. outputs.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을 프로젝트 ID()에 기본값으로 설정합니다.

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 A (UNIQUE) BUCKET NAME HERE" } 참고: 스토리지 버킷의 이름은 전역적으로 고유해야 합니다. 일반적으로 이름과 날짜를 사용하면 고유한 버킷 이름을 만들 수 있습니다. 프로젝트 ID를 사용할 수도 있습니다.

로컬 모듈 설치하기

구성에 새 모듈을 추가할 때마다 Terraform은 해당 모듈을 설치해야 사용할 수 있습니다. terraform get 및 terraform init 명령어는 모두 모듈을 설치하고 업데이트합니다. 또한 terraform init 명령어는 백엔드를 초기화하고 플러그인을 설치합니다.

1. 모듈을 설치합니다.

terraform init

2. 버킷을 프로비저닝합니다.

terraform apply

3. 프롬프트가 표시되면 yes라고 응답합니다. 버킷 및 기타 리소스가 프로비저닝됩니다.

버킷에 파일 업로드하기

이제 자체 모듈을 구성하고 사용하여 정적 웹사이트를 만들었습니다. 이 정적 웹사이트를 방문할 수 있습니다. 지금은 버킷 안에 아무것도 없으므로 웹사이트에서 볼 수 있는 것이 없습니다. 콘텐츠를 보려면 버킷에 객체를 업로드해야 합니다. 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을 스토리지 버킷의 이름으로 바꿉니다.

표시할 항목이 없음이라는 기본 HTML 웹페이지가 표시되어야 합니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 모듈을 빌드합니다.

웹사이트 및 인프라 정리하기

마지막으로 방금 만든 인프라를 폐기하여 프로젝트를 정리합니다.

1. Terraform 리소스를 폐기합니다.

terraform destroy

프롬프트에 yes라고 응답하면 이 실습을 따라 만든 모든 리소스가 Terraform에 의해 폐기됩니다.

수고하셨습니다

이 실습에서는 Terraform 모듈의 기초와 레지스트리에서 기존 모듈을 사용하는 방법을 배웠습니다. 그런 다음 자체 모듈을 빌드하여 Cloud Storage 버킷에서 호스팅되는 정적 웹사이트를 만들었습니다. 이를 통해 구성 파일의 입력, 출력, 변수를 정의하고 모듈 빌드를 위한 권장사항을 배웠습니다.

다음 단계/더 학습하기

다음 링크에서 Terraform에 대한 더 많은 실습을 확인할 수 있습니다.

• Google Cloud Marketplace 기반 HashiCorp
• HashiCorp Learn
• Terraform 커뮤니티
• Terraform Google 예시

Google Cloud 교육 및 자격증

Google Cloud 기술을 최대한 활용하는 데 도움이 됩니다. Google 강의에는 빠른 습득과 지속적인 학습을 지원하는 기술적인 지식과 권장사항이 포함되어 있습니다. 기초에서 고급까지 수준별 학습을 제공하며 바쁜 일정에 알맞은 주문형, 실시간, 가상 옵션이 포함되어 있습니다. 인증은 Google Cloud 기술에 대한 역량과 전문성을 검증하고 입증하는 데 도움이 됩니다.

설명서 최종 업데이트: 2024년 1월 26일

실습 최종 테스트: 2023년 12월 11일

Copyright 2024 Google LLC All rights reserved. Google 및 Google 로고는 Google LLC의 상표입니다. 기타 모든 회사명 및 제품명은 해당 업체의 상표일 수 있습니다.