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

GSP752

개요

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

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

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

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

목표

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

• 로컬 백엔드 만들기
• Cloud Storage 백엔드 만들기
• 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 개요 가이드를 참조하세요.

Terraform 상태의 목적

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

현실 세계로 매핑

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

Terraform은 각 원격 객체가 하나의 리소스 인스턴스에만 바인딩될 것으로 예상하며, 이는 Terraform이 객체를 생성하고 상태의 아이덴티티를 기록할 책임이 있기 때문에 일반적으로 보장됩니다. 대신 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을 성공적으로 사용할 수 있습니다. 하지만 백엔드는 일정 규모에서 팀을 괴롭히는 문제점을 해결해 줍니다. 개인으로 작업하는 경우 백엔드를 사용하지 않고도 성공할 수 있습니다.

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

로컬 백엔드 추가

이 섹션에서는 로컬 백엔드를 구성합니다.

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

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

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

1. 새 Cloud Shell 창에서 main.tf 구성 파일을 만듭니다.

touch main.tf

2. 프로젝트 ID를 검색하려면 다음 명령어를 실행합니다.

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

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

4. Cloud Storage 버킷 리소스 코드를 main.tf 구성 파일에 복사하고 project 및 name 변수 정의를 프로젝트 ID로 바꿉니다.

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 }

Cloud Storage 리소스에 대한 자세한 내용은 Terraform 문서에서 확인하세요.

5. 로컬 백엔드를 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은 자동으로 초기화하지 않습니다.

6. Cloud Shell 툴바에서 터미널 열기를 클릭한 다음 Terraform을 초기화합니다.

terraform init

7. 변경사항을 적용합니다. 프롬프트에 yes를 입력하여 확인합니다.

terraform apply

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

8. 상태 파일을 확인합니다.

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 = "# REPLACE WITH YOUR 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 콘솔의 스토리지 버킷으로 돌아갑니다. 이름 옆의 체크박스를 선택합니다.

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

3. 라벨 추가를 클릭합니다. Key 1 = key 및 Value 1 = 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 파일에서 google_storage_bucket 리소스에 force_destroy = true 인수를 추가합니다. 버킷을 삭제할 때 이 부울 옵션은 포함된 모든 객체를 삭제합니다. 객체가 포함된 버킷을 삭제하려고 시도하면 Terraform은 해당 실행을 실패합니다. 리소스 구성은 다음과 비슷해야 합니다.

resource "google_storage_bucket" "test-bucket-for-state" { name = "qwiklabs-gcp-03-c26136e27648" location = "US" uniform_bucket_level_access = true force_destroy = true }

4. 변경사항을 적용합니다.

terraform apply

프롬프트에 yes를 입력하여 확인합니다.

5. 이제 성공적으로 인프라를 폐기할 수 있습니다:

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 참고: > 기호는 terraform show 명령어의 출력으로 docker.tf의 전체 내용을 변경합니다. 이 예제에서는 이 방법이 작동하지만 리소스를 이미 관리하고 있는 구성으로 리소스를 가져오려면 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은 구성으로 링크 인수를 설정할 수 있지만, 지원 중단되었으며 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 -f {{.RepoTags}}

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

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

3. 이미지 리소스를 상태로 만듭니다.

terraform apply

이제 Terraform에서 이미지에 대한 리소스를 생성했으므로 컨테이너의 구성에서 참조할 수 있습니다.

4. 새 이미지 리소스를 참조하도록 docker_container.web의 이미지 값을 변경합니다.

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" } }

5. 변경사항을 확인합니다.

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으로 백엔드 및 상태를 관리하는 방법을 배웠습니다. 상태 파일을 관리하기 위해 로컬 및 Cloud Storage 백엔드를 만들고, 상태를 새로 고치고, 구성을 Terraform으로 가져왔습니다. 그런 다음 구성을 업데이트하고 수동으로 편집하여 Terraform으로 Docker 컨테이너를 완전히 관리했습니다.

다음 단계/더 학습하기

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의 상표입니다. 기타 모든 회사명 및 제품명은 해당 업체의 상표일 수 있습니다.