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

GSP750

개요

Terraform은 HashiCorp에서 제공하는 코드형 인프라로, 안전하고 반복 가능한 방식으로 인프라를 빌드, 변경, 관리할 수 있는 도구입니다. 운영자와 인프라팀은 Terraform을 사용해 인간이 읽을 수 있는 자동화된 배포를 위해 HashiCorp 구성 언어(HCL)라는 구성 언어로 환경을 관리할 수 있습니다.

코드형 인프라는 사용자 인터페이스에서 리소스를 수동으로 구성하는 대신 하나 이상의 파일로 인프라를 관리하는 프로세스입니다. 이 경우 리소스란 가상 머신, 보안 그룹, 네트워크 인터페이스 등 특정 환경의 모든 인프라를 의미합니다. 대략적으로 말하자면 Terraform은 운영자가 HCL을 사용하여 거의 모든 제공업체(AWS, Google Cloud, GitHub, Docker 등)에서 원하는 리소스의 정의가 포함된 파일을 작성하고 적용 시점에 해당 리소스의 생성을 자동화할 수 있도록 합니다.

배포를 위한 간단한 워크플로는 아래 단계에 따라 진행됩니다:

• 범위 지정 - 특정 프로젝트에 대해 어떤 리소스를 만들어야 하는지 확인합니다.
• 작성 - 범위가 지정된 매개변수를 기반으로 HCL에서 구성 파일을 생성합니다.
• 초기화 - 구성 파일이 있는 프로젝트 디렉터리에서 terraform init을 실행합니다. 그러면 프로젝트에 적합한 제공업체 플러그인이 다운로드됩니다.
• 계획 및 적용 - 생성 프로세스를 확인하기 위해 terraform plan을 실행한 다음, 배포 환경에 실제 존재하는 구성 파일의 향후 변경사항을 비교하는 상태 파일과 실제 리소스를 생성하기 위해 terraform apply를 실행합니다.

목표

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

• Terraform으로 인프라 빌드, 변경, 폐기하기
• Terraform으로 리소스 종속 항목 만들기
• Terraform으로 인프라 프로비저닝하기

설정 및 요건

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

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

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

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

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

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

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

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

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

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

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

2. Google 콘솔 열기를 클릭합니다. 실습에서 리소스가 가동된 후 로그인 페이지가 표시된 다른 탭이 열립니다.

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

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

3. 필요한 경우 실습 세부정보 패널에서 사용자 이름을 복사하여 로그인 대화상자에 붙여넣습니다. 다음을 클릭합니다.

4. 실습 세부정보 패널에서 비밀번호를 복사하여 시작 대화상자에 붙여넣습니다. 다음을 클릭합니다.

   중요: 왼쪽 패널에 표시된 사용자 인증 정보를 사용해야 합니다. Google Cloud Skills Boost 사용자 인증 정보를 사용하지 마세요. 참고: 이 실습에 자신의 Google Cloud 계정을 사용하면 추가 요금이 발생할 수 있습니다.

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

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

잠시 후 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 개요 가이드를 참조하세요.

작업 1. 인프라 빌드

Terraform은 Cloud Shell에 사전 설치된 상태로 제공됩니다. Terraform이 이미 설치되어 있으면 바로 시작하여 인프라를 만들 수 있습니다.

먼저 main.tf라는 파일에 구성 예시를 만듭니다. Terraform은 .tf 또는 .tf.json으로 끝나는 파일을 구성 파일로 인식하고 실행 시 해당 파일을 로드합니다.

1. main.tf 파일을 만듭니다.

touch main.tf

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

3. 편집기에서 main.tf 파일에 다음 콘텐츠를 추가합니다.

terraform { required_providers { google = { source = "hashicorp/google" version = "3.5.0" } } } provider "google" { project = "{{{project_0.project_id | PROJECT ID}}}" region = "{{{project_0.default_region | REGION}}}" zone = "{{{project_0.default_zone | ZONE}}}" } resource "google_compute_network" "vpc_network" { name = "terraform-network" } 참고: 이 스니펫을 Terraform 0.12에서 사용하려면 terraform {} 블록을 제거하세요.

Terraform 블록

terraform {} 블록을 통해 Terraform은 Terraform 레지스트리에서 어떤 제공업체를 다운로드할지 알게 됩니다. 위의 구성에서 google 제공업체의 소스는 registry.terraform.io/hashicorp/google의 약식 표기인 hashicorp/google로 정의되어 있습니다.

required_providers 블록에 정의된 각 제공업체에 버전을 할당할 수도 있습니다. version 인수는 선택 사항이지만 권장되며 브레이킹 체인지를 포함할 수 있는 새 제공업체를 다운로드하지 못하도록 제공업체를 특정 버전 또는 버전 범위로 제한하는 데 사용됩니다. 버전이 지정되지 않은 경우, Terraform은 초기화 중에 가장 최신의 제공업체를 자동으로 다운로드합니다.

자세한 내용은 HashiCorp Terraform 웹사이트에서 제공업체 요구사항을 참조하세요.

제공업체

provider 블록은 이름이 지정된 제공업체(이 경우 google)를 구성하는 데 사용됩니다. 제공업체는 리소스를 만들고 관리할 책임이 있습니다. Terraform 구성에서 여러 제공업체의 리소스를 관리하는 경우 여러 개의 제공업체 블록이 존재할 수 있습니다.

초기화

구성을 새로 만들거나 버전 제어에서 기존 구성을 확인한 후 실행할 첫 번째 명령어는 terraform init으로, 후속 명령어에서 사용할 다양한 로컬 설정과 데이터를 초기화합니다.

• main.tf 파일과 동일한 디렉터리에서 terraform init 명령어를 실행하여 새 Terraform 구성을 초기화합니다.

terraform init

리소스 만들기

1. terraform apply 명령어를 실행하여 지금 구성을 적용합니다.

terraform apply

출력에는 리소스 "google_compute_network" "vpc_network" 옆에 +가 있는데, 이는 Terraform에서 이 리소스를 생성한다는 의미입니다. 그 아래에는 설정할 속성이 표시됩니다. 표시된 값이 (known after apply)이면 리소스가 생성될 때까지 값을 알 수 없다는 것을 의미합니다.

계획이 성공적으로 만들어졌다면 이제 Terraform이 일시중지되고 계속 진행하기 전에 승인을 기다립니다. 계획에서 어떤 것이 잘못되었거나 위험하다고 생각되면 인프라를 변경하지 않고 여기서 중단하는 것이 안전합니다.

오류로 인해 terraform apply가 실패한 경우 오류 메시지를 읽고 발생한 오류를 수정하세요.

2. 계획에 이상이 없어 보이므로 확인 프롬프트에 yes를 입력해 계속 진행합니다.

네트워크가 성공적으로 생성될 때까지 Terraform이 대기하므로 계획 실행에 몇 분 정도 걸립니다.

# ... Enter a value: yes google_compute_network.vpc_network: Creating... google_compute_network.vpc_network: Still creating... [10s elapsed] google_compute_network.vpc_network: Still creating... [20s elapsed] google_compute_network.vpc_network: Still creating... [30s elapsed] google_compute_network.vpc_network: Still creating... [40s elapsed] google_compute_network.vpc_network: Still creating... [50s elapsed] google_compute_network.vpc_network: Creation complete after 58s [id=terraform-network] Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

이후에 Terraform 작업이 모두 완료됩니다. Cloud 콘솔로 이동하여 프로비저닝한 네트워크를 확인할 수 있습니다.

3. 콘솔의 탐색 메뉴에서 VPC 네트워크로 이동합니다. terraform-network가 프로비저닝된 것을 확인할 수 있습니다.

4. Cloud Shell에서 terraform show 명령어를 실행하여 현재 상태를 검사합니다.

terraform show

이러한 값은 다른 리소스나 출력을 구성하는 데 참조할 수 있으며, 이 실습의 뒷부분에서 다룰 것입니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. terraform에서 리소스 만들기

작업 2 인프라 변경

이전 섹션에서는 Terraform으로 기본 인프라, 즉 VPC 네트워크를 만들었습니다. 이 섹션에서는 구성을 수정하고 Terraform이 어떻게 변경되는지 살펴봅니다.

인프라는 지속적으로 진화하고 있으며, Terraform은 이러한 변화를 관리하고 적용할 수 있도록 빌드되었습니다. Terraform 구성을 변경하면 Terraform은 원하는 상태에 도달하는 데 필요한 부분만 수정하는 실행 계획을 빌드합니다.

Terraform을 사용하여 인프라를 변경하면 구성뿐만 아니라 상태도 버전 관리할 수 있으므로 시간이 지남에 따라 인프라가 어떻게 발전하는지 확인할 수 있습니다.

리소스 추가

새 리소스를 Terraform 구성에 추가하고 terraform apply를 실행하여 추가한 다음 해당 리소스를 프로비저닝할 수 있습니다.

1. 편집기에서 컴퓨팅 인스턴스 리소스를 main.tf에 추가합니다.

resource "google_compute_instance" "vm_instance" { name = "terraform-instance" machine_type = "e2-micro" boot_disk { initialize_params { image = "debian-cloud/debian-11" } } network_interface { network = google_compute_network.vpc_network.name access_config { } } }

이 리소스에는 몇 가지 추가 인수가 포함되어 있습니다. 이름과 머신 유형은 간단한 문자열이지만 boot_disk와 network_interface는 좀 더 복잡한 블록입니다. google_compute_instance documentation에서 사용 가능한 모든 옵션을 볼 수 있습니다.

이 예시에서는 컴퓨팅 인스턴스가 Debian 운영체제를 사용하며, 앞서 생성한 VPC 네트워크에 연결됩니다. 이 구성에서 google_compute_network.vpc_network.name을 사용하여 네트워크의 이름 속성을 참조하는 방법을 확인하세요. -- google_compute_network.vpc_network는 네트워크를 정의하는 블록의 값과 일치하는 ID이며, name은 해당 리소스의 속성입니다.

인수가 없어도 access_config 블록이 있으면 인터넷을 통해 인스턴스에 액세스할 수 있습니다.

2. 이제 terraform apply 명령어를 실행하여 컴퓨팅 인스턴스를 만듭니다.

terraform apply

3. 다시 한 번 확인 메시지가 표시되면 yes라고 답합니다.

이는 매우 간단한 변경으로, 구성에 "vm_instance"라는 이름의 "google_compute_instance" 리소스를 추가하고 Terraform이 Google Cloud에 리소스를 생성했습니다.

리소스 변경

Terraform은 리소스를 생성하는 것 외에도 해당 리소스를 변경할 수도 있습니다.

1. tags 인수를 "vm_instance"에 추가하면 다음과 같이 표시됩니다.

resource "google_compute_instance" "vm_instance" { name = "terraform-instance" machine_type = "e2-micro" tags = ["web", "dev"] # ... }

2. 다시 terraform apply를 실행하여 인스턴스를 업데이트합니다.

terraform apply

3. 프리픽스 ~는 Terraform이 리소스를 인플레이스 업데이트한다는 의미입니다. yes라고 응답하여 이 변경사항을 적용하면 Terraform이 인스턴스에 태그를 추가합니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 인프라 변경

파괴적 변경사항

파괴적 변경사항은 제공업체가 기존 리소스를 업데이트하는 것이 아니라 교체해야 하는 변경사항입니다. 이는 일반적으로 클라우드 제공업체가 구성에 설명된 방식으로 리소스 업데이트를 지원하지 않기 때문에 발생합니다.

인스턴스의 디스크 이미지를 변경하는 것은 파괴적 변경사항의 한 가지 예입니다.

1. 구성 파일에서 vm_instance 리소스 내부의 boot_disk 블록을 편집하여 다음과 같이 변경합니다.

boot_disk { initialize_params { image = "cos-cloud/cos-stable" } }

2. 이제 terraform apply를 다시 실행하여 이 변경사항이 기존 리소스에 어떻게 적용되는지 확인합니다.

terraform apply

프리픽스 -/+는 Terraform이 리소스를 인플레이스 업데이트하는 것이 아니라 폐기하고 다시 생성한다는 의미입니다. 일부 속성은 인플레이스 업데이트할 수 있지만(프리픽스 ~로 표시됨), 인스턴스의 부팅 디스크 이미지를 변경하려면 다시 만들어야 합니다. Terraform과 Google Cloud 제공업체가 이러한 세부정보를 처리하며, 실행 계획에는 Terraform이 수행할 작업이 명확하게 나와 있습니다.

또한 실행 계획에 따르면 디스크 이미지 변경으로 인해 인스턴스를 교체해야 하는 것으로 나타났습니다. 일부 상황에서 허용되지 않는 경우 이 정보를 사용하면 업데이트를 삭제/생성하지 않도록 변경사항을 조정할 수 있습니다.

3. 다시 한 번 Terraform은 진행하기 전에 실행 계획을 승인하라는 메시지를 표시합니다. yes라고 응답하고 계획된 단계를 실행합니다.

실행 계획에서 알 수 있듯이 Terraform은 먼저 기존 인스턴스를 폐기한 다음 그 자리에 새 인스턴스를 생성했습니다. 다시 terraform show를 사용하여 이 인스턴스와 연결된 새 값을 볼 수 있습니다.

인프라 폐기

이제까지 인프라를 빌드하고 변경하는 방법을 살펴보았습니다. 여러 리소스를 생성하고 리소스 종속성을 표시하는 방법으로 넘어가기 전에 Terraform 관리형 인프라를 완전히 폐기하는 방법을 알아보겠습니다.

프로덕션 환경에서는 인프라를 폐기하는 일이 드물게 발생합니다. 하지만 개발, 테스트, 스테이징과 같은 여러 환경을 가동하는 데 Terraform을 사용하는 경우에는 폐기하는 것이 유용한 작업일 수 있습니다.

terraform apply와 비슷하지만 모든 리소스가 구성에서 제거된 것처럼 동작하는 terraform destroy 명령어를 사용하여 리소스를 폐기할 수 있습니다.

• terraform destroy 명령어를 실행합니다. yes라고 응답하여 이 계획을 실행하고 인프라를 폐기합니다.

terraform destroy

프리픽스 -는 인스턴스와 네트워크가 폐기될 것임을 나타냅니다. apply와 마찬가지로 Terraform은 실행 계획을 표시하고 변경하기 전에 승인을 기다립니다.

terraform apply와 마찬가지로, Terraform은 폐기해야 하는 것들의 순서를 결정합니다. Google Cloud는 아직 리소스가 남아 있는 경우 VPC 네트워크의 삭제를 허용하지 않으므로 Terraform은 네트워크를 폐기하기 전에 인스턴스가 폐기될 때까지 기다립니다. 작업을 수행할 때 Terraform은 종속 항목 그래프를 생성하여 올바른 작업 순서를 결정합니다. 리소스가 여러 개여서 더 복잡한 경우, Terraform은 안전할 때 작업을 병렬로 수행합니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 파괴적 변경사항

작업 3. 리소스 종속 항목 만들기

이 섹션에서는 리소스 종속 항목에 대해 자세히 알아보고 리소스 매개변수를 사용하여 특정 리소스에 대한 정보를 다른 리소스와 공유하는 방법에 대해 설명합니다.

실제 인프라에는 다양한 리소스와 리소스 유형이 있습니다. Terraform 구성에는 여러 리소스, 여러 리소스 유형이 포함될 수 있으며, 이러한 유형은 여러 제공업체와 관련되어 있을 수 있습니다.

이 섹션에서는 여러 리소스를 구성하는 방법과 리소스 속성을 사용하여 다른 리소스를 구성하는 방법에 대한 기본 예시를 확인할 수 있습니다.

• 네트워크와 인스턴스를 다시 생성합니다. 메시지에 yes라고 응답하면 리소스가 생성됩니다.

terraform apply

고정 IP 주소 할당

1. 이제 main.tf에서 VM 인스턴스에 고정 IP를 할당하여 구성에 추가합니다.

resource "google_compute_address" "vm_static_ip" { name = "terraform-static-ip" }

이전 예시에서 VM 인스턴스 리소스를 추가하는 것과 비슷하지만 이번에는 "google_compute_address" 리소스 유형을 생성한다는 점이 다릅니다. 이 리소스 유형은 프로젝트에 예약된 IP 주소를 할당합니다.

2. 그런 다음 terraform plan을 실행합니다.

terraform plan

terraform plan으로 무엇이 생성되었는지 확인할 수 있습니다.

$ terraform plan Refreshing Terraform state in-memory prior to plan... The refreshed state will be used to calculate this plan, but will not be persisted to local or remote state storage. google_compute_network.vpc_network: Refreshing state... [id=terraform-network] google_compute_instance.vm_instance: Refreshing state... [id=terraform-instance] ------------------------------------------------------------------------ An execution plan has been generated and is shown below. Resource actions are indicated with the following symbols: + create Terraform will perform the following actions: # google_compute_address.vm_static_ip will be created + resource "google_compute_address" "vm_static_ip" { + address = (known after apply) + address_type = "EXTERNAL" + creation_timestamp = (known after apply) + id = (known after apply) + name = "terraform-static-ip" + network_tier = (known after apply) + project = (known after apply) + region = (known after apply) + self_link = (known after apply) + subnetwork = (known after apply) + users = (known after apply) } Plan: 1 to add, 0 to change, 0 to destroy. ------------------------------------------------------------------------ Note: You didn't specify an "-out" parameter to save this plan, so Terraform can't guarantee that exactly these actions will be performed if "terraform apply" is subsequently run.

terraform apply와 달리 plan 명령어는 변경될 내용만 표시하고 변경사항을 직접 적용하지 않습니다. 지금까지 변경한 것은 고정 IP를 추가한 것뿐입니다. 다음으로 인스턴스에 IP 주소를 연결해야 합니다.

3. 다음과 같이 인스턴스에 대한 network_interface 구성을 업데이트합니다.

network_interface { network = google_compute_network.vpc_network.self_link access_config { nat_ip = google_compute_address.vm_static_ip.address } }

access_config 블록에는 몇 가지 선택적 인수가 있으며, 이 경우 nat_ip를 고정 IP 주소로 설정합니다. Terraform에서 이 구성을 읽으면 다음 작업이 실행됩니다.

• vm_static_ip가 vm_instance보다 먼저 생성되었는지 확인
• 상태에 vm_static_ip의 속성 저장
• vm_static_ip.address 속성 값에 nat_ip 설정

4. terraform plan을 다시 실행하되 이번에는 계획을 저장합니다.

terraform plan -out static_ip

이러한 방식으로 계획을 저장하면 나중에 정확히 동일한 계획을 적용할 수 있습니다. 계획으로 생성된 파일을 적용하려고 하면 Terraform은 먼저 계획을 적용하기 전에 정확히 동일한 변경사항이 적용될 것인지 확인합니다.

이 경우, Terraform이 새로운 google_compute_address를 생성하고 이를 사용하도록 기존 VM을 업데이트하는 것을 볼 수 있습니다.

5. terraform apply "static_ip"를 실행하여 Terraform이 이 변경사항을 적용하도록 계획하는 방법을 확인합니다.

terraform apply "static_ip"

위와 같이, Terraform은 VM 인스턴스를 수정하기 전에 고정 IP를 생성했습니다. IP 주소를 인스턴스의 네트워크 인터페이스 구성에 전달하는 보간 표현식 덕분에 Terraform은 종속 항목을 추론할 수 있으며, 인스턴스를 업데이트하기 전에 고정 IP를 생성해야 한다는 것을 알고 있습니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 리소스 종속 항목 만들기

암시적 및 명시적 종속 항목

보간 표현식에 사용된 리소스 속성을 연구함으로써 Terraform은 한 리소스가 다른 리소스에 의존하는 시점을 자동으로 추론할 수 있습니다. 위의 예에서 google_compute_address.vm_static_ip.address에 대한 참조는 vm_static_ip라는 google_compute_address에 대한 암시적 종속 항목을 생성합니다.

Terraform은 이 종속 항목 정보를 사용하여 다양한 리소스를 생성하고 업데이트하는 올바른 순서를 결정합니다. 위의 예시에서 Terraform은 vm_static_ip를 사용하기 위해서는 vm_instance가 업데이트되기 전에 생성되어야 한다는 것을 알고 있습니다.

보간 표현식을 통한 암시적 종속 항목은 이러한 관계를 Terraform에 알리는 기본적인 방법이며, 가능하면 항상 사용해야 합니다.

때때로 Terraform에 표시되지 않는 리소스 간 종속 항목이 있을 수 있습니다. depends_on 인수는 모든 리소스에 추가할 수 있으며 명시적 종속 항목을 생성할 리소스 목록을 허용합니다.

예를 들어, 인스턴스에서 실행할 애플리케이션이 특정 Cloud Storage 버킷을 사용할 것으로 예상되지만 해당 종속 항목은 애플리케이션 코드 내부에 구성되어 있어 Terraform에 표시되지 않을 수 있습니다. 이 경우 depends_on을 사용하여 종속 항목을 명시적으로 선언할 수 있습니다.

1. main.tf에 다음을 추가하여 Cloud Storage 버킷과 버킷에 대한 명시적 종속 항목이 있는 인스턴스를 추가합니다.

# New resource for the storage bucket our application will use. resource "google_storage_bucket" "example_bucket" { name = "<UNIQUE-BUCKET-NAME>" location = "US" website { main_page_suffix = "index.html" not_found_page = "404.html" } } # Create a new instance that uses the bucket resource "google_compute_instance" "another_instance" { # Tells Terraform that this VM instance must be created only after the # storage bucket has been created. depends_on = [google_storage_bucket.example_bucket] name = "terraform-instance-2" machine_type = "e2-micro" boot_disk { initialize_params { image = "cos-cloud/cos-stable" } } network_interface { network = google_compute_network.vpc_network.self_link access_config { } } } 참고: Storage 버킷은 전역적으로 고유해야 합니다. 따라서 UNIQUE-BUCKET-NAME을 버킷에 사용할 고유하고 유효한 이름으로 바꿔야 합니다. 일반적으로 이름과 날짜를 사용하면 고유한 버킷 이름을 추측할 수 있습니다.

구성에서 이러한 리소스가 어디에 있어야 하는지 궁금할 수 있습니다. terraform 구성 파일에서 리소스가 정의되는 순서는 Terraform이 변경사항을 적용하는 방식에 영향을 미치지 않습니다. 자신과 팀에 가장 적합한 방식으로 구성 파일을 정리하세요.

2. 이제 이러한 변경사항이 실제로 적용되는지 확인하려면 terraform plan과 terraform apply를 실행합니다.

terraform plan terraform apply

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 버킷 종속 인스턴스 만들기

3. 계속 진행하기 전에 구성에서 이러한 새 리소스를 제거한 후 다시 한 번 terraform apply를 실행하여 폐기합니다. 이 실습에서는 버킷이나 두 번째 인스턴스를 더 이상 사용하지 않을 것입니다.

작업 4. 인프라 프로비저닝

이 시점에서 시작한 컴퓨팅 인스턴스는 제공된 Google 이미지를 기반으로 하지만 추가 소프트웨어가 설치되거나 구성이 적용되지 않았습니다.

Google Cloud를 사용하면 고객은 자신만의 커스텀 운영 체제 이미지를 관리할 수 있습니다. 이렇게 하면 Terraform으로 프로비저닝하는 인스턴스가 필요에 따라 미리 구성되도록 할 수 있습니다. Packer는 이를 위한 완벽한 도구로, Google Cloud용 빌더를 포함하고 있습니다.

Terraform은 프로비저닝 도구를 사용하여 파일을 업로드하거나 셸 스크립트를 실행하거나 구성 관리 도구와 같은 기타 소프트웨어를 설치 및 트리거합니다.

프로비저닝 도구 정의

1. 프로비저닝 도구를 정의하려면 구성에서 첫 번째 vm_instance를 정의하는 리소스 블록을 다음과 같이 수정합니다.

resource "google_compute_instance" "vm_instance" { name = "terraform-instance" machine_type = "e2-micro" tags = ["web", "dev"] provisioner "local-exec" { command = "echo ${google_compute_instance.vm_instance.name}: ${google_compute_instance.vm_instance.network_interface[0].access_config[0].nat_ip} >> ip_address.txt" } # ... }

이렇게 하면 provisioner 블록이 resource 블록 내에 추가됩니다. 여러 provisioner 블록을 추가하여 여러 프로비저닝 단계를 정의할 수 있습니다. Terraform은 다양한 프로비저닝 도구를 지원하지만, 이 예시에서는 local-exec 프로비저닝 도구를 사용합니다.

local-exec 프로비저닝 도구는 VM 인스턴스 자체가 아닌 Terraform을 실행하는 머신에서 로컬로 명령어를 실행합니다. 다른 프로비저닝 도구와 달리 이 프로비저닝 도구를 사용하고 있으므로 지금 당장 연결 정보를 지정하는 것에 대해 걱정할 필요가 없습니다.

이것은 또한 이전에 보았던 것보다 더 복잡한 문자열 보간의 예를 보여줍니다. 각 VM 인스턴스는 여러 개의 네트워크 인터페이스를 가질 수 있으므로 대부분의 프로그래밍 언어가 그러하듯이 0부터 카운트하는 network_interface[0]로 첫 번째 인터페이스를 참조합니다. 각 네트워크 인터페이스에는 여러 개의 access_config 블록을 가질 수도 있으므로 다시 한 번 첫 번째 블록을 지정합니다.

2. terraform apply를 실행합니다.

terraform apply

이 시점에서 출력이 처음에는 혼란스러울 수 있습니다.

Terraform은 아무것도 찾지 못했습니다. 확인해보면 로컬 머신에 ip_address.txt 파일이 없다는 것을 알 수 있습니다.

Terraform은 프로비저닝 도구를 다른 인수와 다르게 취급합니다. 프로비저닝 도구는 리소스가 생성될 때만 실행되지만, 프로비저닝 도구를 추가해도 해당 리소스가 강제로 폐기되었다가 다시 생성되도록 하지는 않습니다.

3. terraform taint를 사용하여 Terraform에 인스턴스를 다시 생성하도록 지시합니다.

terraform taint google_compute_instance.vm_instance

tainted로 표시된 리소스는 다음 apply 실행 시 폐기되고 다시 생성됩니다.

4. 이제 terraform apply를 실행합니다.

terraform apply

5. ip_address.txt 파일의 내용을 확인하여 모든 것이 정상적으로 작동하는지 확인합니다.

요청한 대로 IP 주소가 포함되어 있습니다.

실패한 프로비저닝 도구 및 tainted로 표시된 리소스

리소스가 성공적으로 생성되었지만 프로비저닝 단계에 실패한 경우, Terraform은 오류를 발생시키고 리소스를 tainted로 표시합니다. tainted로 표시된 리소스는 여전히 존재하지만 프로비저닝에 실패했기 때문에 사용하기에 안전한 것으로 간주해서는 안 됩니다.

다음 실행 계획을 생성할 때, Terraform은 tainted로 표시된 리소스를 제거하고 새 리소스를 생성하여 생성 후 다시 프로비저닝을 시도합니다.

폐기 프로비저닝 도구

폐기 작업 중에만 실행되도록 프로비저닝 도구를 정의할 수도 있습니다. 이는 시스템 정리, 데이터 추출 등을 수행할 때 유용합니다.

많은 리소스의 경우 가능하면 기본 제공 정리 메커니즘(예: init 스크립트)을 사용하는 것이 좋지만, 필요한 경우 프로비저닝 도구를 사용할 수도 있습니다.

이 실습에서는 폐기된 프로비저닝 도구 예시는 표시하지 않습니다. 폐기 프로비저닝 도구를 사용해야 하는 경우 프로비저닝 도구 문서를 참조하세요.

수고하셨습니다

이 실습에서는 Terraform으로 인프라를 빌드하고, 변경하고, 폐기하는 방법을 배웠습니다. 그런 다음 리소스 종속 항목을 만들고 Terraform 구성 파일로 기본 인프라를 프로비저닝했습니다.

다음 단계/더 학습하기

Terraform에 대한 더 많은 실습을 원한다면 다음 리소스를 확인하세요.

• Google Cloud Marketplace의 Hashicorp!
• Hashicorp Learn
• Terraform 커뮤니티
• Terraform Google 예시

Google Cloud 교육 및 자격증

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

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

실습 최종 테스트: 2023년 9월 25일

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