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

GSP752

개요

Terraform은 관리형 인프라 및 구성에 대한 상태를 저장해야 합니다. 이 상태는 Terraform에서 실제 리소스를 구성에 매핑하고, 메타데이터를 추적하고, 대규모 인프라의 성능을 개선하는 데 사용됩니다.

이 상태는 기본적으로 terraform.tfstate라는 로컬 파일에 저장되지만 팀 환경에서 더 원활하게 작동하도록 원격으로 저장할 수도 있습니다.

Terraform은 이 로컬 상태를 사용하여 계획을 세우고 인프라를 변경합니다. 작업 전에 Terraform은 새로고침을 수행하여 실제 인프라로 상태를 업데이트합니다.

Terraform 상태의 주요 목적은 원격 시스템의 객체와 구성에서 선언된 리소스 인스턴스 간의 바인딩을 저장하는 것입니다. 구성 변경에 대한 응답에서 원격 객체를 생성하는 경우, Terraform은 특정 리소스 인스턴스에 대해 해당 원격 객체의 ID를 기록한 다음 향후 구성 변경에 대한 응답에서 해당 객체를 업데이트하거나 삭제할 수 있습니다.

목표

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

• 로컬 백엔드 만들기
• Cloud Storage 백엔드 만들기
• Terraform 상태 새로고침
• Terraform 구성 가져오기
• Terraform으로 가져온 구성 관리

설정 및 요건

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

다음 안내를 확인하세요. 실습에는 시간 제한이 있으며 일시중지할 수 없습니다. 실습 시작을 클릭하면 타이머가 시작됩니다. 이 타이머는 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 활성화 를 클릭합니다.

2. 다음 창을 클릭합니다.

   • Cloud Shell 정보 창을 통해 계속 진행합니다.
   • 사용자 인증 정보를 사용하여 Google Cloud API를 호출할 수 있도록 Cloud Shell을 승인합니다.

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

Your Cloud Platform project in this session is set to {{{project_0.project_id | "PROJECT_ID"}}}

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

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

gcloud auth list

4. 승인을 클릭합니다.

출력:

ACTIVE: * ACCOUNT: {{{user_0.username | "ACCOUNT"}}} To set the active account, run: $ gcloud config set account `ACCOUNT`

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

gcloud config list project

출력:

[core] project = {{{project_0.project_id | "PROJECT_ID"}}} 참고: gcloud 전체 문서는 Google Cloud에서 gcloud CLI 개요 가이드를 참고하세요.

Terraform 상태의 목적

상태는 Terraform이 작동하기 위한 필수 요구사항입니다. 사람들은 가끔 Terraform이 상태 없이 작동할 수 있는지, 아니면 상태를 사용하지 않고 실행할 때마다 클라우드 리소스만 검사할 수 있는지 묻습니다. Terraform이 상태를 사용하지 않아도 되는 시나리오의 경우, 실제로 그렇게 하려면 엄청난 양의 복잡성을 한 곳(상태)에서 다른 곳(대체 개념)으로 옮겨야 합니다. 이 섹션에서는 Terraform 상태가 필요한 이유를 설명합니다.

실제 인프라로 매핑

Terraform 구성을 실제 인프라로 매핑하려면 일종의 데이터베이스가 필요합니다. 구성에 resource resource "google_compute_instance" "foo"가 포함된 경우, Terraform은 이 맵을 사용하여 인스턴스 i-abcd1234가 해당 리소스로 표시되는지 확인합니다.

Terraform은 각 원격 객체가 하나의 리소스 인스턴스에만 바인딩될 것으로 예상하며, 이는 Terraform이 객체를 생성하고 상태에 객체의 ID를 기록하는 역할을 수행하기 때문에 일반적으로 보장됩니다. 대신 Terraform 외부에서 생성된 객체를 가져오는 경우, 각각의 개별 객체를 하나의 리소스 인스턴스로만 가져오는지 확인해야 합니다.

하나의 원격 객체가 둘 이상의 리소스 인스턴스에 바인딩되어 있는 경우, 구성에서 원격 객체 상태로의 매핑이 불분명해져서 해당 객체에 대해 예기치 않은 작업이 발생할 수 있습니다.

메타데이터

Terraform은 리소스와 원격 객체 간의 매핑 외에도 리소스 종속 항목과 같은 메타데이터도 추적해야 합니다.

Terraform은 일반적으로 구성을 사용하여 종속 항목 순서를 결정합니다. 그러나 Terraform 구성에서 리소스를 제거할 때 Terraform은 해당 리소스를 삭제하는 방법을 알고 있어야 합니다. Terraform은 구성 파일에 없는 리소스에 대한 매핑이 존재하는 것을 확인하고 폐기할 계획을 세울 수 있습니다. 그러나 리소스가 더 이상 존재하지 않기 때문에 구성만으로는 순서를 결정할 수 없습니다.

Terraform은 올바른 작업을 보장하기 위해 상태 내에서 가장 최근 종속 항목 세트의 사본을 보관합니다. 이제 Terraform은 구성에서 하나 이상의 항목을 삭제할 때 상태로부터 올바른 폐기 순서를 결정할 수 있습니다.

Terraform이 리소스 유형 간의 필수 순서를 알고 있다면 이 문제를 피할 수 있습니다. 예를 들어, Terraform은 서버가 속한 서브넷이 삭제되기 전에 서버를 삭제해야 한다는 것을 알 수 있습니다. 그러나 이러한 접근 방식이 관리가 불가능할 정도로 복잡해지는 이유는 Terraform이 모든 클라우드에 대한 모든 리소스의 순서 시맨틱스를 이해하는 것 외에도 제공업체 전반의 순서도 이해해야 하기 때문입니다.

또한 Terraform은 이와 비슷한 이유로, 여러 개의 별칭이 지정된 제공업체가 존재하는 상황에서 리소스와 함께 가장 최근에 사용된 제공업체 구성에 대한 포인터와 같은 다른 메타데이터도 저장합니다.

성능

Terraform은 기본 매핑 외에도 상태의 모든 리소스에 대해 속성 값의 캐시를 저장합니다. 이 기능은 Terraform 상태의 선택사항이며 성능 개선 용도로만 사용됩니다.

terraform plan을 실행할 때 원하는 구성에 도달하는 데 필요한 변경사항을 효과적으로 결정하려면 Terraform이 현재 리소스 상태를 알고 있어야 합니다.

소규모 인프라의 경우, Terraform은 제공업체를 쿼리하고 모든 리소스에서 최신 속성을 동기화할 수 있습니다. 이는 Terraform의 기본 동작으로, Terraform은 plan과 apply를 실행할 때마다 상태의 모든 리소스를 동기화합니다.

대규모 인프라의 경우 모든 리소스를 쿼리하는 것은 너무 느립니다. 많은 클라우드 제공업체는 동시에 여러 리소스를 쿼리할 수 있는 API를 제공하지 않으며, 각 리소스에 대한 왕복 시간은 수백 밀리초에 달합니다. 또한 클라우드 제공업체는 거의 항상 API 비율 제한을 두기 때문에 Terraform은 일정 기간 동안 제한된 수의 리소스만 요청할 수 있습니다. Terraform의 대규모 사용자들은 이 문제를 해결하기 위해 -refresh=false 플래그와 -target 플래그를 모두 사용하는 경우가 많습니다. 이러한 시나리오에서는 캐시된 상태가 정보 기록으로 취급됩니다.

동기화

기본 구성에서 Terraform은 Terraform이 실행된 현재 작업 디렉터리의 파일에 상태를 저장합니다. 이 방법은 처음 시작할 때 유용하지만, 팀에서 Terraform을 사용할 때는 모든 사람이 동일한 상태로 작업하여 동일한 원격 객체에 작업이 적용되도록 하는 것이 중요합니다.

이 문제를 해결하려면 원격 상태를 사용하는 것이 좋습니다. 모든 기능을 갖춘 상태 백엔드가 있는 Terraform은 여러 사용자가 실수로 동시에 Terraform을 실행하는 것을 방지하는 수단으로 원격 잠금을 사용할 수 있으며, 이를 통해 각 Terraform 실행이 가장 최근에 업데이트된 상태로 시작되도록 보장합니다.

상태 잠금

백엔드에서 지원하는 경우, Terraform은 상태를 쓸 수 있는 모든 작업에 대해 상태를 잠급니다. 이렇게 하면 다른 사람이 잠금을 획득하여 상태를 손상시킬 가능성을 방지할 수 있습니다.

상태 잠금은 상태를 쓸 수 있는 모든 작업에서 자동으로 발생합니다. 상태 잠금이 발생하고 있다는 메시지는 표시되지 않습니다. 상태 잠금이 실패하면 Terraform은 계속 진행되지 않습니다. -lock 플래그를 사용하여 대부분의 명령어에 대해 상태 잠금을 중지할 수 있지만 권장하지는 않습니다.

잠금을 획득하는 데 예상보다 시간이 오래 걸리는 경우, Terraform은 상태 메시지를 출력합니다. Terraform이 메시지를 출력하지 않으면 상태 잠금이 여전히 발생하고 있는 것입니다.

모든 백엔드가 잠금을 지원하는 것은 아닙니다. 백엔드의 잠금 지원 여부에 대한 자세한 내용은 백엔드 유형 목록을 참조하세요.

작업공간

각 Terraform 구성에는 작업이 실행되는 방식과 Terraform 상태와 같은 영구 데이터가 저장되는 위치를 정의하는 연결된 백엔드가 있습니다.

백엔드에 저장된 영구 데이터는 작업공간에 속합니다. 처음에 백엔드에는 기본값이라고 하는 하나의 작업공간만 있으며, 따라서 해당 구성에는 하나의 Terraform 상태만 연결됩니다.

특정 백엔드는 이름이 지정된 여러 개의 작업공간을 지원하므로 여러 개의 상태를 단일 구성에 연결할 수 있습니다. 구성에는 여전히 하나의 백엔드만 있지만, 새 백엔드를 구성하거나 사용자 인증 정보를 변경하지 않고도 해당 구성의 여러 개별 인스턴스를 배포할 수 있습니다.

작업 1. 백엔드 작업

Terraform의 백엔드는 상태가 로드되는 방식과 apply와 같은 작업이 실행되는 방식을 결정합니다. 이러한 추상화를 통해 비로컬 파일 상태 저장, 원격 실행 등이 가능합니다.

기본적으로 Terraform은 '로컬' 백엔드를 사용하며, 이는 사용자에게 익숙한 Terraform의 일반적인 동작입니다. 이는 이전 실습에서 호출되었던 백엔드입니다.

백엔드의 몇 가지 이점은 다음과 같습니다.

• 팀 작업: 백엔드는 상태를 원격으로 저장하고 잠금으로 상태를 보호하여 손상을 방지할 수 있습니다. Terraform Cloud와 같은 일부 백엔드는 모든 상태 버전 내역을 자동으로 저장하기도 합니다.
• 민감한 정보를 디스크에 보관하지 않음: 상태는 필요에 따라 백엔드에서 검색되며 메모리에만 저장됩니다.
• 원격 작업 수행: 대규모 인프라 또는 특정 변경사항의 경우 terraform apply는 시간이 오래 걸릴 수 있습니다. 일부 백엔드는 원격 작업을 지원하므로 원격으로 작업을 실행할 수 있습니다. 그런 다음 컴퓨터를 꺼도 작업이 완료됩니다. 위에서 설명한 원격 상태 저장 및 잠금과 더불어 원격 작업 수행 기능도 팀 환경에서 유용하게 사용할 수 있습니다.

완전히 선택사항인 백엔드: 백엔드를 배우거나 사용하지 않고도 Terraform을 성공적으로 사용할 수 있습니다. 하지만 백엔드는 일정 규모의 팀을 괴롭히는 문제점을 해결해 줍니다. 개인으로 작업하는 경우 백엔드를 사용하지 않고도 성공할 수 있습니다.

'로컬' 백엔드만 사용하려는 경우에도 백엔드에 대해 배우면 로컬 백엔드의 동작을 변경할 수 있으므로 유용합니다.

Cloud Shell IDE에서 Gemini Code Assist 사용 설정

Cloud Shell과 같은 통합 개발 환경(IDE)에서 Gemini Code Assist를 사용하여 코드에 대한 안내를 받거나 코드 문제를 해결할 수 있습니다. Gemini Code Assist를 사용하려면 먼저 사용 설정해야 합니다.

1. Cloud Shell에서 다음 명령어를 사용하여 Gemini for Google Cloud API를 사용 설정합니다.

gcloud services enable cloudaicompanion.googleapis.com

2. Cloud Shell 툴바에서 편집기 열기를 클릭합니다.

참고: Cloud Shell 편집기를 열려면 Cloud Shell 툴바에서 편집기 열기를 클릭합니다. 필요에 따라 편집기 열기 또는 터미널 열기를 클릭하여 Cloud Shell과 코드 편집기 간에 전환할 수 있습니다.

3. 왼쪽 창에서 설정 아이콘을 클릭한 다음 설정 뷰에서 Gemini Code Assist를 검색합니다.

4. Geminicodeassist: 사용 체크박스가 선택되어 있는지 확인하고 설정을 닫습니다.

5. 화면 하단의 상태 표시줄에서 Cloud Code - 프로젝트 없음을 클릭합니다.

6. 안내에 따라 플러그인을 승인합니다. 프로젝트가 자동으로 선택되지 않으면 Google Cloud 프로젝트 선택을 클릭하고 을(를) 선택합니다.

7. 상태 표시줄의 Cloud Code 상태 메시지에 Google Cloud 프로젝트()가 표시되는지 확인합니다.

로컬 백엔드 추가

이 섹션에서는 로컬 백엔드를 구성하는 방법을 살펴봅니다.

처음으로 백엔드를 구성할 때(정의된 백엔드가 없는 상태에서 명시적으로 백엔드를 구성하는 경우), Terraform은 상태를 새 백엔드로 마이그레이션할 수 있는 옵션을 제공합니다. 이를 통해 기존 상태를 유지하면서 백엔드를 채택할 수 있습니다.

특별히 주의하려면 항상 상태를 수동으로도 백업하는 것이 좋습니다. 백업은 terraform.tfstate 파일을 다른 위치로 복사하기만 하면 됩니다. 초기화 프로세스에서도 백업을 생성하지만, 안전을 위해 백업해 두는 것이 좋습니다.

백엔드를 처음 구성하는 것은 나중에 구성을 변경하는 것과 다르지 않습니다. 새 구성을 만들고 terraform init를 실행하면 됩니다. Terraform이 나머지 과정을 안내할 것입니다.

1. Cloud Shell 터미널에서 main.tf 구성 파일을 만듭니다.

touch main.tf

2. Cloud Shell 툴바에서 편집기 열기를 클릭합니다.

3. 다음 Cloud Storage 버킷 리소스 코드를 main.tf 구성 파일에 복사합니다.

provider "google" { project = "# REPLACE WITH YOUR PROJECT ID" region = "{{{project_0.default_region | REGION}}}" } resource "google_storage_bucket" "test-bucket-for-state" { name = "# REPLACE WITH YOUR PROJECT ID" location = "US" uniform_bucket_level_access = true }

4. 파일 > 저장을 클릭하되 파일을 닫지는 마세요.

Cloud Storage 리소스에 대한 자세한 내용은 Terraform 문서를 참조하세요.

5. main.tf 파일을 열고 IDE에서 Gemini Code Assist를 사용 설정한 상태에서 편집기 오른쪽 상단에 아이콘이 있는지 확인합니다.

6. 툴바에서 Gemini Code Assist: 스마트 작업 아이콘을 클릭합니다.

Gemini Code Assist의 AI 기반 기능을 사용하여 코드 편집기에서 직접 코드를 변경할 수 있습니다. 이 인스턴스에서는 Gemini Code Assist를 사용하여 main.tf 구성 파일의 콘텐츠를 수정합니다.

7. Gemini Code Assist에 main.tf 구성 파일 편집을 도와달라고 요청하려면 툴바에서 열리는 Gemini Code Assist 인라인 텍스트 입력란에 다음 프롬프트를 붙여넣습니다.

Update the main.tf configuration file with the following changes: * In the Google provider block, set the project to {{{project_0.project_id | PROJECT_ID}}}. * In the "test-bucket-for-state" resource block, update the name of the bucket to {{{project_0.project_id | BUCKET_NAME}}}.

8. Gemini Code Assist에 코드를 적절히 수정하도록 프롬프트를 입력하려면 Enter 키를 누릅니다.

9. Gemini Diff 뷰에 메시지가 표시되면 Accept(수락)를 클릭합니다.

이제 main.tf 구성 파일의 콘텐츠는 다음과 유사합니다.

provider "google" { project = "{{{project_0.project_id | PROJECT_ID}}}" region = "{{{project_0.default_region | REGION}}}" } resource "google_storage_bucket" "test-bucket-for-state" { name = "{{{project_0.project_id | BUCKET_NAME}}}" location = "US" uniform_bucket_level_access = true }

10. 로컬 백엔드를 main.tf 파일에 추가합니다.

terraform { backend "local" { path = "terraform/state/terraform.tfstate" } }

이 코드는 terraform/state 디렉터리에 있는 terraform.tfstate 파일을 참조합니다. 다른 파일 경로를 지정하려면 path 변수를 변경합니다.

로컬 백엔드는 로컬 파일시스템에 상태를 저장하고, 시스템 API를 사용하여 해당 상태를 잠그며, 로컬에서 작업을 수행합니다.

Terraform은 사용하기 전에 구성된 모든 백엔드를 초기화해야 합니다. 이 작업을 위해 terraform init를 실행합니다. 첫 번째 단계로 Terraform 구성에서 팀원 중 아무나 terraform init 명령어를 실행해야 합니다. 이 명령어는 여러 번 실행해도 안전하며 백엔드 초기화를 포함하여 Terraform 환경에 필요한 모든 설정 작업을 수행합니다.

다음 상황에서 init 명령어가 호출되어야 합니다.

• 백엔드를 구성하는 모든 새로운 환경
• 백엔드 구성(백엔드 유형 포함)을 변경할 때
• 백엔드 구성을 완전히 삭제할 때

각 경우를 구체적으로 기억할 필요는 없습니다. Terraform은 초기화가 필요한 시점을 감지하고 해당 상황에서 오류 메시지를 표시합니다. 사용자의 추가 정보가 필요하거나 상태 마이그레이션 등을 수행해야 할 수 있으므로 Terraform은 자동으로 초기화하지 않습니다.

11. Cloud Shell 툴바에서 터미널 열기를 클릭한 다음, 다음 명령어를 실행하여 Terraform을 초기화합니다.

terraform init

12. 다음 명령어를 실행하여 변경사항을 적용하고 표시되는 메시지에서 yes를 입력하여 확인합니다.

terraform apply

이제 Cloud Shell 편집기는 terraform/state 디렉터리에 terraform.tfstate라는 상태 파일을 표시합니다.

13. 다음 명령어를 실행하여 상태 파일을 검사합니다.

terraform show

google_storage_bucket.test-bucket-for-state 리소스가 표시됩니다.

Cloud Storage 백엔드 추가

Cloud Storage 백엔드는 상태를 Cloud Storage의 지정된 버킷에서 구성 가능한 프리픽스에 객체로 저장합니다. 이 백엔드도 상태 잠금을 지원합니다. 이는 상태를 쓸 수 있는 모든 작업에 대해 상태를 잠급니다. 이렇게 하면 다른 사람이 잠금을 획득하여 상태를 손상시킬 가능성을 방지할 수 있습니다.

상태 잠금은 상태를 쓸 수 있는 모든 작업에서 자동으로 발생합니다. 상태 잠금이 발생하고 있다는 메시지는 표시되지 않습니다. 상태 잠금이 실패하면 Terraform은 계속 진행되지 않습니다. -lock 플래그를 사용하여 대부분의 명령어에 대해 상태 잠금을 중지할 수 있지만 권장하지는 않습니다.

1. 편집기에서 main.tf 파일로 다시 이동합니다. 이제 현재 로컬 백엔드를 gcs 백엔드로 변경해 보겠습니다.

2. 기존 로컬 백엔드 구성을 변경하려면 다음 구성을 파일에 복사하여 local 백엔드를 대체합니다.

terraform { backend "gcs" { bucket = "{{{project_0.project_id | BUCKET_NAME}}}" prefix = "terraform/state" } } 참고: bucket의 변수 정의를 업데이트해야 합니다. 구성을 변경하지 않은 경우 google_storage_bucket 리소스의 name입니다. 이 버킷은 상태 파일을 호스팅하는 데 사용됩니다.

3. 다음 명령어를 실행하여 이번에는 백엔드를 다시 초기화하고 상태를 자동으로 마이그레이션합니다.

terraform init -migrate-state

표시되는 메시지에 yes를 입력하여 확인합니다.

4. Cloud 콘솔의 탐색 메뉴에서 Cloud Storage > 버킷을 클릭합니다.

5. 버킷을 클릭하고 terraform/state/default.tfstate 파일로 이동합니다. 이제 상태 파일이 Cloud Storage 버킷에 있게 되었습니다.

참고: 더 이상 백엔드를 사용하지 않으려면 파일에서 구성을 제거하면 됩니다. Terraform은 다른 변경사항과 마찬가지로 이를 감지하고 다시 초기화하라는 메시지를 표시합니다.

다시 초기화하는 과정에서 Terraform은 상태를 일반 로컬 상태로 다시 마이그레이션할지 묻습니다. 이 작업이 완료되면 Terraform은 기본 동작으로 돌아갑니다.

상태 새로고침

terraform refresh 명령어는 (상태 파일을 통해) Terraform이 알고 있는 상태를 실제 인프라와 조정하는 데 사용됩니다. 이는 마지막으로 알려진 상태로부터 드리프트를 감지하고 상태 파일을 업데이트하는 데 사용할 수 있습니다.

이렇게 하면 인프라는 수정되지 않지만 상태 파일은 수정됩니다. 상태가 변경되면 다음 계획 또는 적용 시 변경사항이 발생할 수 있습니다.

1. Cloud 콘솔의 Cloud Storage 버킷으로 돌아갑니다. 버킷 이름 옆의 체크박스를 선택합니다.

2. 라벨 탭을 클릭합니다.

3. 라벨 추가를 클릭합니다. Key 2 = key 및 Value 2 = value로 설정합니다.

4. 저장을 클릭합니다.

5. Cloud Shell로 돌아가서 다음 명령어를 실행하여 상태 파일을 업데이트합니다.

terraform refresh

6. 다음 명령어를 실행하여 업데이트를 검사합니다.

terraform show

"key" = "value" 키-값 쌍이 구성의 라벨 특성에 표시됩니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 백엔드 작업

작업공간 정리

다음 작업을 계속하기 전에 프로비저닝된 인프라를 폐기해야 합니다.

1. 먼저, 스토리지 버킷을 삭제할 수 있도록 백엔드를 local로 되돌립니다. 다음을 복사하여 gcs 구성을 대체합니다.

terraform { backend "local" { path = "terraform/state/terraform.tfstate" } }

2. 다음 명령어를 실행하여 local 백엔드를 다시 초기화합니다.

terraform init -migrate-state

표시되는 메시지에 yes를 입력하여 확인합니다.

3. main.tf 파일을 열고 편집기의 오른쪽 상단에 아이콘이 있는지 확인합니다.

다음으로 Gemini Code Assist를 사용하여 Terraform 구성을 수정합니다. 즉, Cloud Storage 버킷 리소스를 폐기하는 데 사용되는 코드에 인수를 추가합니다.

4. 툴바에서 Gemini Code Assist: 스마트 작업 아이콘을 클릭합니다.

5. Gemini Code Assist가 main.tf 구성 파일을 수정하도록 하려면 다음 프롬프트를 툴바에서 열리는 Gemini Code Assist 인라인 텍스트 입력란에 붙여넣습니다.

Update the google_storage_bucket resource named "test-bucket-for-state" in the main.tf file. Add the force_destroy = true argument to its configuration.

버킷을 삭제할 때 이 불리언 옵션은 포함된 모든 객체를 삭제하는 데 사용됩니다. 객체가 포함된 버킷을 삭제하려고 시도하면 Terraform은 해당 실행을 실패합니다.

6. Gemini Code Assist에 코드를 적절히 수정하도록 프롬프트를 입력하려면 Enter 키를 누릅니다.

7. Gemini Diff 뷰에 메시지가 표시되면 Accept(수락)를 클릭합니다.

이제 main.tf 구성 파일의 콘텐츠는 다음과 유사합니다.

resource "google_storage_bucket" "test-bucket-for-state" { name = "{{{project_0.project_id | BUCKET_NAME}}}" location = "US" uniform_bucket_level_access = true force_destroy = true }

8. 다음 명령어를 실행하여 변경사항을 적용합니다.

terraform apply

표시되는 메시지에 yes를 입력하여 확인합니다.

9. 이제 성공적으로 인프라를 폐기할 수 있습니다: 다음 명령어를 실행합니다.

terraform destroy

표시되는 메시지에 yes를 입력하여 확인합니다.

작업 2. Terraform 구성 가져오기

이 섹션에서는 기존 Docker 컨테이너와 이미지를 빈 Terraform 작업공간으로 가져옵니다. 이를 통해 실제 인프라를 Terraform으로 가져오기 위한 전략과 고려사항을 배우게 됩니다.

기본 Terraform 워크플로에는 Terraform을 사용하여 전체적으로 인프라를 생성하고 관리하는 것이 포함됩니다.

• 만들고자 하는 인프라를 정의하는 Terraform 구성을 작성합니다.

• Terraform 계획을 검토하여 구성에서 예상되는 상태와 인프라가 생성되는지 확인합니다.

• 구성을 적용하여 Terraform 상태 및 인프라를 생성합니다.

Terraform으로 인프라를 생성한 후에는 구성을 업데이트하고 해당 변경사항을 계획하고 적용할 수 있습니다. 결국 Terraform을 사용하여 더 이상 필요하지 않은 인프라를 폐기하게 됩니다. 이 워크플로에서는 Terraform이 완전히 새로운 인프라를 생성한다고 가정합니다.

하지만 Terraform에서 생성하지 않은 인프라를 관리해야 할 수도 있습니다. Terraform 가져오기는 지원되는 리소스를 Terraform 작업공간의 상태로 로드하여 이 문제를 해결합니다.

하지만 가져오기 명령어가 인프라 관리를 위한 구성을 자동으로 생성하지는 않습니다. 따라서 기존 인프라를 Terraform으로 가져오려면 여러 단계의 프로세스를 거쳐야 합니다.

기존 인프라를 Terraform에서 제어하려면 크게 5가지 단계가 필요합니다.

• 가져올 기존 인프라를 확인합니다.
• 인프라를 Terraform 상태로 가져옵니다.
• 해당 인프라와 일치하는 Terraform 구성을 작성합니다.
• Terraform 계획을 검토하여 구성이 예상되는 상태 및 인프라와 일치하는지 확인합니다.
• 구성을 적용하여 Terraform 상태를 업데이트합니다.

이 섹션에서는 먼저 Docker CLI를 사용하여 Docker 컨테이너를 생성한 다음 새 Terraform 작업공간으로 가져옵니다. 그런 다음 Terraform을 사용하여 컨테이너의 구성을 업데이트한 후 완료되면 최종적으로 컨테이너를 폐기합니다.

경고: 인프라를 가져오면 기존 Terraform 프로젝트가 유효하지 않은 상태로 유지될 수 있는 방식으로 Terraform 상태가 조작됩니다. 실제 Terraform 프로젝트에서 Terraform 가져오기를 사용하기 전에 terraform.tfstate 파일과 .terraform 디렉터리를 백업하여 안전하게 보관하세요.

Docker 컨테이너 만들기

1. 다음 명령어를 실행하여 Docker Hub의 최신 NGINX 이미지를 사용하는 hashicorp-learn이라는 이름의 컨테이너를 생성하고 포트 80(HTTP)을 통해 Cloud Shell 가상 머신에서 컨테이너를 미리 봅니다.

docker run --name hashicorp-learn --detach --publish 8080:80 nginx:latest

2. 다음 명령어를 실행하여 컨테이너가 실행 중인지 확인합니다.

docker ps

3. Cloud Shell 창에서 웹 미리보기를 클릭한 다음 포트 8080에서 미리보기를 클릭합니다.

Cloud Shell에서 프록시 서비스의 미리보기 URL이 새 브라우저 창에서 열리고 NGINX 기본 인덱스 페이지가 표시됩니다. 이제 작업공간으로 가져와서 Terraform으로 관리할 Docker 이미지와 컨테이너가 생겼습니다.

컨테이너를 Terraform으로 가져오기

1. 다음 명령어를 실행하여 예시 저장소를 클론합니다.

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

2. 다음 명령어를 실행하여 해당 디렉터리로 변경합니다.

cd learn-terraform-import

이 디렉터리에는 이 가이드의 뒷부분에서 사용할 구성을 구성하는 두 개의 Terraform 구성 파일이 포함되어 있습니다.

• main.tf 파일은 Docker 제공업체를 구성합니다.
• docker.tf 파일에는 이전 단계에서 만든 Docker 컨테이너를 관리하는 데 필요한 구성이 포함됩니다.

3. 다음 명령어를 실행하여 Terraform 작업공간을 초기화합니다.

terraform init 참고: 오류: 사용 가능한 제공업체 패키지를 쿼리하지 못했습니다와 같은 오류가 표시되는 경우 terraform init -upgrade 명령어를 실행합니다.

4. Cloud Shell 편집기에서 learn-terraform-import/main.tf로 이동합니다.

5. provider: docker 리소스를 찾아 host 인수를 주석 처리하거나 삭제합니다.

provider "docker" { # host = "npipe:////.//pipe//docker_engine" } 참고: 이는 Docker 초기화 오류와 관련된 알려진 문제에 대한 현재 해결 방법입니다.

6. 다음으로 learn-terraform-import/docker.tf로 이동합니다.

7. 주석 처리된 코드 아래에서 docker.tf 파일에 빈 docker_container 리소스를 정의합니다. 이 리소스는 Terraform 리소스 ID가 docker_container.web인 Docker 컨테이너를 나타냅니다.

resource "docker_container" "web" {}

8. 가져오려는 컨테이너의 이름(이 경우 이전 단계에서 만든 컨테이너)을 찾습니다.

docker ps

9. 다음 terraform import 명령어를 실행하여 방금 생성한 docker_container.web 리소스에 기존 Docker 컨테이너를 연결합니다. Terraform 가져오기에는 이 Terraform 리소스 ID와 전체 Docker 컨테이너 ID가 필요합니다. docker inspect -f {{.ID}} hashicorp-learn 명령어는 전체 SHA256 컨테이너 ID를 반환합니다.

terraform import docker_container.web $(docker inspect -f {{.ID}} hashicorp-learn) 참고: terraform import가 허용하는 ID는 리소스 유형에 따라 다르며, Terraform으로 가져올 수 있는 모든 리소스에 대한 제공업체 문서에 설명되어 있습니다. 이 예시에서는 Docker 제공업체 문서를 참조하세요.

10. 다음 명령어를 실행하여 컨테이너를 Terraform 상태로 가져왔는지 확인합니다.

terraform show

이 상태에는 방금 가져온 Docker 컨테이너에 대해 Terraform이 알고 있는 모든 것이 포함되어 있습니다. 그러나 Terraform 가져오기는 리소스에 대한 구성을 생성하지 않습니다.

구성 만들기

Terraform을 사용해 이 컨테이너를 관리하려면 먼저 Terraform 구성을 만들어야 합니다.

1. 다음 코드를 실행합니다.

terraform plan 참고: Terraform은 누락된 필수 인수인 image와 name에 대한 오류를 표시합니다. Terraform은 필수 인수가 누락된 리소스에 대한 계획을 생성할 수 없습니다.

가져온 상태를 일치시키기 위해 docker.tf에서 구성을 업데이트하는 방법에는 두 가지가 있습니다. 리소스의 전체 현재 상태를 구성에 그대로 적용하거나 구성에 필요한 속성을 개별적으로 선택할 수 있습니다. 이러한 접근방식은 각각 다른 상황에서 유용할 수 있습니다.

• 현재 상태를 사용하는 것이 더 빠른 경우가 많지만, 구성에 포함할 필요가 있는지와 관계없이 모든 속성이 상태에 포함되므로 구성이 지나치게 장황해질 수 있습니다.

• 필요한 속성을 개별적으로 선택하면 구성을 더 쉽게 관리할 수 있지만, 구성에 어떤 속성을 설정해야 하는지 이해해야 합니다.

이 실습에서는 현재 상태를 리소스로 사용합니다.

2. Terraform 상태를 docker.tf 파일에 복사합니다.

terraform show -no-color > docker.tf 참고: > 기호는 docker.tf의 전체 내용을 terraform show 명령어의 출력으로 변경합니다. 이 예시에서는 이 방법이 작동하지만, 리소스를 이미 관리하고 있는 구성으로 리소스를 가져오려면 terraform show의 출력을 수정하여 구성을 완전히 바꾸고 싶지 않은 기존 리소스를 제거하고 새 리소스를 기존 구성에 병합해야 합니다.

3. docker.tf 파일을 검사하여 그 내용이 방금 실행한 terraform show 명령어의 출력으로 바뀌었는지 확인합니다.

4. 다음 코드를 실행합니다.

terraform plan

Terraform은 지원 중단된 인수('links')와 여러 읽기 전용 인수(ip_address, network_data, gateway, ip_prefix_length, id)에 대한 경고 및 오류를 표시합니다.

이러한 읽기 전용 인수는 Terraform이 Docker 컨테이너의 상태로 저장하지만, Docker가 내부적으로 관리하기 때문에 구성을 통해 설정할 수 없는 값입니다. Terraform은 구성으로 links 인수를 설정할 수 있지만, 지원 중단되었으며 Docker 제공업체의 추후 버전에서 지원되지 않을 수 있으므로 여전히 경고를 표시합니다.

여기에 표시된 접근방식은 Terraform 상태로 표시되는 모든 속성을 로드하기 때문에 구성에는 기본값과 값이 동일한 선택 속성이 포함됩니다. 선택 속성과 기본값은 제공업체마다 다르며 제공업체 문서에 나열되어 있습니다.

5. 이러한 선택 속성을 선택적으로 삭제할 수 있습니다. image, name, ports 필수 속성만 남겨두고 선택 속성을 모두 삭제합니다. 이러한 선택 속성을 삭제한 후 구성은 다음과 일치하게 됩니다.

출력:

resource "docker_container" "web" { image = "sha256:87a94228f133e2da99cb16d653cd1373c5b4e8689956386c1c12b60a20421a02" name = "hashicorp-learn" ports { external = 8080 internal = 80 ip = "0.0.0.0" protocol = "tcp" } }

실제 인프라를 가져올 때는 제공업체 문서를 참조하여 각 인수의 기능을 알아보세요. 이렇게 하면 계획 단계에서 발생하는 오류나 경고를 처리하는 방법을 결정하는 데 도움이 됩니다. 예를 들어 links 인수에 대한 문서는 Docker 제공업체 문서에 있습니다.

6. 다음을 실행하여 오류가 해결되었는지 확인합니다.

terraform plan

이제 계획이 성공적으로 실행됩니다. 계획에는 Terraform이 컨테이너를 업데이트하여 attach, logs, must_run, start 속성을 추가할 것이라고 나와 있습니다.

Terraform은 이러한 속성을 사용하여 Docker 컨테이너를 생성하지만, Docker는 이러한 속성을 저장하지 않습니다. 그 결과 terraform import가 해당 값을 상태로 로드하지 못했습니다. 구성을 계획하고 적용하면 Docker 제공업체가 이러한 속성의 기본값을 할당하고 상태에 저장하지만 실행 중인 컨테이너에는 영향을 미치지 않습니다.

7. 다음 명령어를 실행하여 변경사항을 적용하고 업데이트된 Terraform 구성 및 상태를 해당 구성 및 상태가 나타내는 Docker 컨테이너와 동기화하는 프로세스를 완료합니다. 표시되는 메시지에 yes를 입력하여 확인합니다.

terraform apply

이제 구성 파일, Terraform 상태, 컨테이너가 모두 동기화되었으며, 평소와 같이 Terraform을 사용하여 Terraform 컨테이너를 관리할 수 있습니다.

이미지 리소스 만들기

경우에 따라 terraform import 명령어를 사용하지 않고도 리소스를 Terraform의 제어하에 둘 수 있습니다. Docker 이미지와 같이 단일 고유 ID 또는 태그로 정의되는 리소스의 경우 이러한 경우가 많습니다.

docker.tf 파일에서 docker_container.web 리소스는 컨테이너를 만드는 데 사용된 이미지의 SHA256 해시 ID를 지정합니다. 이는 docker가 이미지 ID를 내부적으로 저장하는 방식이므로, terraform import는 이미지 ID를 상태에 직접 로드합니다. 그러나 이미지 ID는 이미지 태그나 이름과는 달리 인간이 읽을 수 있는 것이 아니며, 인텐트와 일치하지 않을 수 있습니다. 예를 들어 최신 버전의 'nginx' 이미지를 사용해야 하는 경우를 고려해 보겠습니다.

1. 이미지의 태그 이름을 찾으려면 다음 명령어를 실행합니다. 명령어의 <IMAGE-ID>는 docker.tf의 이미지 ID로 변경하세요.

docker image inspect <IMAGE-ID> -f {{.RepoTags}}

2. 다음 구성을 docker.tf 파일에 추가하여 이 이미지를 리소스로 표현합니다.

resource "docker_image" "nginx" { name = "nginx:latest" } 참고: docker_container.web 리소스에서 이미지 값을 아직 바꾸지 마세요. 그렇지 않으면 Terraform이 컨테이너를 폐기하고 다시 생성합니다. Terraform이 아직 docker_image.nginx 리소스를 상태로 로드하지 않았기 때문에 하드코딩된 이미지 ID와 비교할 이미지 ID가 없으므로 Terraform은 컨테이너를 교체해야 한다고 가정하게 됩니다. 이 문제를 해결하려면 이 실습에서 설명한 대로 먼저 이미지를 만든 다음 이미지를 사용하도록 컨테이너를 업데이트하세요.

3. 다음 명령어를 실행하여 상태에 이미지 리소스를 만듭니다. 표시되는 메시지에 yes를 입력하여 확인합니다.

terraform apply

이제 Terraform에서 이미지에 대한 리소스를 생성했으므로 컨테이너의 구성에서 참조할 수 있습니다. 이 작업을 수행하기 위해 Gemini Code Assist에 도움을 요청하겠습니다.

4. docker.tf 파일을 열고 편집기의 오른쪽 상단에 아이콘이 있는지 확인합니다.

5. 툴바에서 Gemini Code Assist: 스마트 작업 아이콘을 클릭합니다.

6. docker.tf 파일의 새 이미지 리소스를 참조하도록 docker_container.web의 이미지 값을 변경하려면 다음 프롬프트를 툴바에서 열리는 Gemini Code Assist 인라인 텍스트 입력란에 붙여넣습니다.

Update the image argument in the docker_container resource named web within the docker.tf file. Set its value to docker_image.nginx.image_id.

7. Gemini Code Assist에 코드를 적절히 수정하도록 프롬프트를 입력하려면 Enter 키를 누릅니다.

8. Gemini Diff 뷰에 메시지가 표시되면 Accept(수락)를 클릭합니다.

이제 docker.tf 구성 파일의 콘텐츠는 다음과 유사합니다.

resource "docker_container" "web" { image = docker_image.nginx.image_id name = "hashicorp-learn" ports { external = 8080 internal = 80 ip = "0.0.0.0" protocol = "tcp" } }

9. 다음 명령어를 실행하여 변경사항을 찾습니다. 표시되는 메시지에 yes를 입력하여 확인합니다.

terraform apply

docker_image.nginx.latest는 교체된 하드코딩된 이미지 ID와 일치하므로, 이 시점에서 terraform apply를 실행하면 변경사항이 표시되지 않습니다.

참고: Docker 컨테이너를 처음 생성한 시점과 이 명령어를 실행하는 시점 사이에 'nginx:latest' 태그의 이미지 ID가 변경된 경우, 컨테이너가 폐기되고 새 이미지로 다시 생성됩니다.

Terraform으로 컨테이너 관리

이제 Terraform이 Docker 컨테이너를 관리하므로 Terraform을 사용하여 구성을 변경할 수 있습니다.

1. docker.tf 파일에서 컨테이너의 외부 포트를 8080에서 8081로 변경합니다.

resource "docker_container" "web" { name = "hashicorp-learn" image = docker_image.nginx.image_id ports { external = 8081 internal = 80 ip = "0.0.0.0" protocol = "tcp" } }

2. 다음을 실행하여 변경사항을 적용합니다.

terraform apply

표시되는 메시지에 yes를 입력하여 확인합니다.

이렇게 하면 Terraform이 컨테이너를 폐기하고 새 포트 구성으로 다시 생성합니다.

3. 다음 명령어를 실행하여 컨테이너가 새 구성이 있는 새 컨테이너로 교체되었는지 확인합니다.

docker ps

컨테이너 ID가 변경된 것을 확인합니다. 포트 구성을 변경하려면 컨테이너를 폐기하고 다시 생성해야 했으므로 이것은 완전히 새로운 컨테이너입니다.

인프라 폐기

이제 Docker 컨테이너와 컨테이너를 생성하는 데 사용된 이미지를 Terraform으로 가져왔습니다.

1. 다음 명령어를 실행하여 컨테이너와 이미지를 폐기합니다.

terraform destroy

표시되는 메시지에 yes를 입력하여 확인합니다.

2. 다음을 실행하여 컨테이너가 폐기되었는지 확인합니다.

docker ps --filter "name=hashicorp-learn" 참고: Terraform 구성과 컨테이너 모두에 이미지를 추가했기 때문에 이미지가 Docker와 컨테이너 모두에서 삭제됩니다. 다른 컨테이너가 동일한 이미지를 사용하고 있으면 폐기 단계가 실패합니다. 리소스를 Terraform으로 가져오면 Terraform이 폐기를 포함한 리소스의 전체 수명 주기를 관리하게 된다는 의미임을 기억하세요.

제한사항 및 기타 고려사항

Terraform으로 리소스를 가져올 때 고려해야 할 몇 가지 중요한 사항은 다음과 같습니다.

Terraform 가져오기는 Terraform 제공업체가 보고한 인프라의 현재 상태만 알 수 있습니다. 다음 사항은 알 수 없습니다.

• 인프라의 정상 작동 여부
• 인프라의 인텐트
• Terraform에서 제어하지 않는 인프라에 대한 변경사항(예: Docker 컨테이너의 파일 시스템 상태)

가져오기에는 오류가 발생하기 쉬운 수동 단계가 포함되며, 특히 리소스를 가져오는 사람이 해당 리소스가 원래 생성된 방법과 이유에 대한 컨텍스트가 부족한 경우 오류가 발생하기 쉽습니다.

가져오기는 Terraform 상태 파일을 조작하므로 새 인프라를 가져오기 전에 백업을 생성하는 것이 좋습니다.

Terraform 가져오기는 인프라 간의 관계를 감지하거나 생성하지 않습니다.

Terraform은 구성에서 설정할 필요가 없는 기본 속성은 감지하지 않습니다.

모든 제공업체와 리소스가 Terraform 가져오기를 지원하는 것은 아닙니다.

Terraform으로 인프라를 가져온다고 해서 Terraform이 인프라를 폐기하고 다시 만들 수 있는 것은 아닙니다. 예를 들어 가져온 인프라는 관리되지 않는 다른 인프라나 구성을 사용할 수 있습니다.

변경 불가능한 인프라와 같은 코드형 인프라(IaC) 권장사항을 따르면 이러한 문제를 상당 부분 방지할 수 있지만, 수동으로 만든 인프라는 IaC 권장사항을 따르지 않을 가능성이 높습니다.

Terraformer와 같은 도구는 인프라 가져오기와 관련된 일부 수동 단계를 자동화할 수 있습니다. 그러나 이러한 도구는 Terraform의 일부가 아니며 HashiCorp가 보증하거나 지원하지 않습니다.

수고하셨습니다

이 실습에서는 Terraform과 Gemini Code Assist를 활용하여 백엔드와 상태를 관리하는 방법을 배웠습니다. 상태 파일을 관리하기 위해 로컬 및 Cloud Storage 백엔드를 만들고, 상태를 새로고침하고, 구성을 Terraform으로 가져왔습니다. 그런 다음 구성을 업데이트하고 수동으로 편집하여 Terraform으로 Docker 컨테이너를 완전히 관리했습니다.

다음 단계/더 학습하기

Terraform을 사용한 더 많은 실무형 실습을 원한다면 다음을 확인해 보세요.

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

Google Cloud 교육 및 자격증

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

설명서 최종 업데이트: 2025년 8월 25일

실습 최종 테스트: 2025년 8월 25일

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