Terraform Associate (3)

클라우드/DevOps

Terraform Associate (3)

dayeonsheep 2025. 5. 16. 00:42

모듈 저장소

module "consul" {
  source  = "hashicorp/consul/aws"
  version = "0.1.0"
}

Q. where is this particular module stored?
-> public Terraform registry

"hashicorp/consul/aws" => 해당 모듈이 public terraform registry에 저장되어 있음을 나타냄

Modules on the public Terraform Registry can be referenced using a registry source address of the form //, with each module's information page on the registry site including the exact address to use.

✅ 1. Terraform 모듈의 저장 위치 구분: `source = "<namespace>/<name>/<provider>"`

이 구문은 공식 Terraform Registry에서 가져오는 형식이에요.

📌 기본 형식: `<namespace>/<name>/<provider>`

namespace: 모듈을 게시한 조직이나 사용자 이름
name: 모듈 이름
provider: 모듈이 사용하는 클라우드/시스템 환경 (예: aws, azurerm, google 등)

📘 예시 1:

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "4.0.2"
}

이 모듈은 다음 위치에서 불러옵니다:
🔗 https://registry.terraform.io/modules/terraform-aws-modules/vpc/aws
저장소: 공식 Terraform Registry
namespace: terraform-aws-modules
provider: aws

📘 예시 2:

module "gke" {
  source  = "terraform-google-modules/kubernetes-engine/google"
}

저장소 위치:
🔗 https://registry.terraform.io/modules/terraform-google-modules/kubernetes-engine/google
저장소: 공식 Registry
모듈 이름이 꼭 구문의 부분과 같을 필요는 없음, 구성 파일에서 참조하기 위핸 로컬 식별자

📘 예시 3: GitHub 같은 외부 저장소 사용

module "app" {
  source = "git::https://github.com/example-org/terraform-app-module.git"
}

저장소: GitHub
git:: 접두사를 보면 알 수 있음 → 공식 Registry가 아니라 Git 저장소
버전 지정은 태그나 ref로 관리해야 함 (?ref=v1.2.0 등)

📘 예시 4: 로컬 경로 사용

module "custom" {
  source = "./modules/my-custom-module"
}

저장소: 로컬 디렉터리
즉, 현재 프로젝트 내부에서 상대경로로 찾음

✅ 2. Provider는 어디에서 저장되는가?

🔹 대부분의 경우: 공식 Terraform Registry

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 4.0"
    }
  }
}

위 코드는 다음에서 provider를 다운로드:
🔗 https://registry.terraform.io/providers/hashicorp/aws
provider도 <namespace>/<name> 형식 사용
Terraform CLI가 자동으로 다운로드함

✅ 다른 provider 저장 위치 예외

terraform {
  required_providers {
    custom = {
      source = "mycorp/custom"
    }
  }
}

이 경우 Terraform은 mycorp라는 namespace를 Registry에서 찾거나,
terraform CLI가 provider_installation 설정을 통해 프라이빗 registry 또는 파일 경로에서도 설치 가능

🔑 핵심 요약

타입	예시 source	저장 위치
공개 모듈	`terraform-aws-modules/vpc/aws`	Terraform Registry
Git 모듈	`git::https://github.com/user/repo.git`	Git 저장소 (예: GitHub)
로컬 모듈	`./modules/webserver`	로컬 파일 시스템
Provider	`hashicorp/aws` (기본)	Terraform Registry
커스텀 Provider	`mycorp/internal` + `provider_installation` 설정	프라이빗 registry 또는 로컬

state file error

✅ 문제에서 확인하고자 하는 핵심 개념

❓ 질문 요지:

Jeff는 특정 VMware VM을 삭제하고자 했고, terraform state rm 명령어로 state에서 해당 리소스를 제거했음.
그런데 terraform apply를 하자 다시 동일한 VM을 새로 생성하려고 함.

왜 Terraform은 VM을 삭제하지 않고, 새로 생성하려고 했을까?

✅ 정답 및 설명 요약:

정답:

Jeff는 리소스를 state 파일에서는 제거했지만, 구성 파일(.tf)에서는 여전히 해당 리소스가 존재함.
Terraform은 구성 파일에 존재하지만 상태에는 없는 리소스를 "새로 생성해야 할 리소스"로 간주함.

따라서 올바른 절차는:

구성 파일에서 리소스를 삭제하고
terraform plan → terraform apply를 실행해야 Terraform이 해당 리소스를 제거함.

⚙️ Terraform에서 state 관련 문제 유형 요약

상황	원인	Terraform의 반응	해결 방법
`terraform state rm`만 하고 `.tf`에 리소스 그대로 있음	상태 파일에서만 삭제되고, 구성에는 남아 있음	"이 리소스는 새로 만들어야겠군!" → 생성 시도	`.tf` 파일에서도 해당 리소스 블록 제거
리소스를 수동으로(VM 등에서) 삭제했지만 state에는 여전히 있음	상태 파일은 여전히 리소스를 추적함	"이 리소스 없어졌네?" → 재생성 시도	필요 없으면 `.tf`에서 제거하고 `terraform apply`로 삭제 적용
수동으로 state 파일을 편집함	파일 무결성 손상 가능	불안정한 상태, 충돌 발생 가능	절대 직접 편집하지 말고 공식 명령어(`state rm`, `state mv`, `state list`) 사용
구성 변경 후 `terraform apply` 안 함	상태 파일은 이전 상태를 추적 중	실제 인프라와 원하는 구성 간의 불일치 발생	변경 후 `plan`, `apply` 반드시 실행

🧠 기억할 개념 요약

Terraform은 구성 파일(.tf) + 상태 파일(terraform.tfstate) 두 가지를 바탕으로 동작함
상태 파일은 Terraform이 리소스를 추적하기 위한 핵심 정보
구성과 상태 간의 불일치가 생기면, Terraform은 "변경 필요!"라고 판단해서 생성/삭제/수정 시도함
수정을 원한다면 항상 .tf 파일에서 먼저 수정하고 plan → apply 실행

Provider credential

✅ 핵심 개념: Terraform Provider Credentials

Terraform은 클라우드 플랫폼이나 기타 인프라 API와 상호작용하기 위해 provider를 사용하며, 대부분의 경우 인증을 위한 **credentials (자격 증명)**이 필요합니다.

Terraform에 자격 증명을 제공하는 방법은 다음과 같은 대표적인 3가지가 있습니다:

✅ 1. 환경 변수 (Environment Variables)

Terraform과 provider는 종종 환경 변수를 통해 자격 증명을 받을 수 있습니다.
예:
export AWS_ACCESS_KEY_ID="your-access-key" export AWS_SECRET_ACCESS_KEY="your-secret-key"
장점: 민감한 정보를 코드에 직접 작성하지 않아 보안에 유리함.
사용 예: AWS, Google Cloud, Azure 모두 지원

✅ 2. Provider block 내부에 직접 입력하거나 변수로 처리

provider "aws" {
  region     = "us-west-2"
  access_key = var.aws_access_key
  secret_key = var.aws_secret_key
}

variable로 받아서 credentials를 관리하면 민감 정보를 분리 가능
단점: 실수로 하드코딩하거나 버전 관리(Git 등)에 포함되면 보안 사고 가능

✅ 3. 플랫폼 통합 인증 방식 (Integrated Services)

클라우드에서 제공하는 관리형 인증 시스템을 이용해 인증을 처리할 수 있음:

AWS IAM Role (EC2에 연결된 역할 등)
Azure Managed Identity
GCP Default Application Credentials

이 경우 별도로 자격 증명을 입력하지 않아도 인스턴스 자체가 인증을 수행함

장점: 자격 증명을 코드나 환경 변수로 저장하지 않아 보안성이 높음
권장 상황: Terraform을 클라우드 상에서 실행할 때 (예: EC2, GCE VM, Azure VM)

❌ 잘못된 방법: Resource block에 credentials 입력

resource "aws_instance" "example" {
  # 여기에 credentials를 넣는 건 잘못된 방식입니다!
}

resource 블록은 실제 인프라를 정의하는 블록이고,
자격 증명 정보는 provider block이나 환경 변수로만 제공해야 함

📌 요약

방법	설명	보안성	추천 여부
환경 변수	환경에 설정해서 Terraform이 참조	높음	✅ 권장
provider block	하드코딩 or 변수 사용	중간~낮음	✅ 변수 사용 시 OK
통합 인증 서비스	IAM Role, MSI 등	매우 높음	✅ 클라우드 환경에서는 최우선
resource block	❌ 사용 불가	없음	❌ 절대 금지

Terraform의 상태(state) 파일이 없을 때 `terraform apply` 명령을 실행하면

🔍 문제 해석

"You have a Terraform configuration file defining resources to deploy on VMware, yet there is no related state file. You have successfully run terraform init already. What happens when you run a terraform apply?"

✅ 올바른 정답:

Terraform will scan the VMware infrastructure, create a new state file, and deploy the new resources as defined in the configuration file.

1. 🔧 Terraform의 상태 파일(state file)이란?

Terraform은 실제 인프라 리소스의 상태를 로컬 혹은 원격에 .tfstate 파일로 저장합니다.
이 파일은 Terraform이 현재 무엇을 관리하고 있는지를 기억하는 데 사용됩니다.
예: 어떤 리소스가 이미 만들어졌는지, 속성이 어떤지 등을 담고 있음.

👉 상태 파일이 없다면, Terraform은 아무것도 관리하고 있지 않다고 판단합니다.

2. 🛠️ `terraform apply`의 동작

terraform apply는 다음을 수행합니다:
1. 현재 상태 파일(terraform.tfstate)을 확인하거나 새로 생성함.
2. 현재 상태와 구성(configuration) (.tf 파일들)을 비교.
3. 차이가 있다면 리소스를 생성, 변경, 삭제함.
4. 최종적으로 상태 파일을 업데이트하여 최신 상태를 반영.

➡️ 따라서 초기 상태 파일이 없는 경우에는:

terraform apply는 리소스를 **"아무것도 없는 상태에서 새로 만든다"**고 판단.
구성에 정의된 리소스를 VMware에 생성하고,
새로운 상태 파일을 만들어 Terraform이 리소스를 추적할 수 있게 함.

3. ❌ 잘못된 선택지와 그 이유

"Terraform will produce an error since there is no state file"
❌ terraform apply는 상태 파일이 없다고 오류를 내지 않음. 오히려 최초 실행 시에는 당연히 상태 파일이 없기 때문에 새로 생성하는 것이 정상 흐름입니다.
"All existing infrastructure on VMware will be deleted..."
❌ Terraform은 VMware 인프라를 직접 스캔하여 모든 리소스를 파악하거나 삭제하지 않음. 상태 파일과 코드에 정의된 리소스만 인식합니다.
"Defined resources will not be created..."
❌ 상태 파일이 없어도 terraform apply는 구성 파일을 기준으로 리소스를 생성합니다. 상태 파일은 추적용일 뿐 리소스 생성을 막지 않습니다.

✅ 핵심 요약

개념	설명
State File (`terraform.tfstate`)	Terraform이 현재 인프라 상태를 추적하는 파일. 리소스를 "관리"하기 위한 핵심 정보 저장소
초기 apply 실행 시	상태 파일이 없으면 Terraform은 구성을 기준으로 리소스를 생성하고, 새로운 상태 파일을 만듬
Terraform의 실행 흐름	`init` → `plan` → `apply` → 상태 파일 생성/갱신

Terraform 공식 문서: State Purpose

provider alias

목적

using the same provider with different configurations for different resources

-> A provider alias is used to differentiate between multiple instances of the same provider within a Terraform configuration file.
= 동일한 provider를 서로 다른 설정으로 여러 리소스에서 사용하기 위해 alias를 사용함

-> This allows you to configure and use the same provider with different settings for different resources, ensuring flexibility and customization in your infrastructure deployment.

❌ to signify what resources should be deployed to a certain cloud provider
특정 클라우드 provider에 어떤 리소스를 배포할 것인지 나타내기 위해 alias를 사용한다

🔍 왜 틀렸는가?

기본 provider 선택 개념과 혼동되어 있습니다.
리소스 블록은 이미 provider 타입(예: aws, google, azurerm)을 기준으로 어떤 클라우드에 배포할지 결정합니다.
alias는 같은 provider 내에서 다른 설정(예: region, credentials) 등을 구분하는 용도이지, 클라우드 간 구분을 위한 도구가 아닙니다.

❌ to use as shorthand for resources to be deployed with the referenced provider
alias는 provider를 참조하는 리소스에 대해 일종의 축약어로 사용된다

🔍 왜 틀렸는가?

alias는 단순한 축약어가 아니라, 동일한 provider의 여러 설정을 구분하기 위한 키값입니다.
예: AWS provider를 IAM Role로 한 번, access key로 한 번 사용할 경우 각각을 alias로 나눔.
단순히 이름 줄이기용이 아니라 별도의 provider 설정을 지정하고, 특정 리소스가 어떤 설정을 쓸지를 지정하기 위한 목적입니다.

data

질문: Terraform에서 "data source"에 대해 가장 잘 설명한 것은 무엇인가?

✅ 정답: enables Terraform to fetch data for use elsewhere in the Terraform configuration
→ Terraform 구성 파일 내에서 다른 곳에서 사용할 데이터를 외부에서 가져올 수 있도록 해줍니다.

❌ 오답 해설:

provides required data for declared variables used within the Terraform configuration
→ 데이터 소스는 변수의 값을 직접 제공하지 않습니다.
변수는 기본값, CLI 입력, .tfvars 파일, 환경변수 등 다양한 방법으로 값을 받을 수 있지만, data source가 변수의 "입력값" 역할을 하진 않습니다.
maintains a list of strings to store the values of declared outputs in Terraform
→ Terraform의 output은 리소스 생성 결과 값을 외부로 노출하는 용도이며, data source와는 별개의 기능입니다.
a file that contains the current working version of Terraform
→ 이는 전혀 관련 없는 설명입니다. Terraform 버전 정보는 .terraform 디렉토리 등에서 관리되며, data source는 외부 정보 가져오기 용도입니다.

✅ Data Source란?

Terraform에서 data source는 외부 시스템에서 정보를 조회해서 Terraform 구성 파일 내에서 활용할 수 있도록 하는 기능입니다.
주로 기존 인프라 리소스의 정보를 가져오는 데 사용됩니다.
읽기 전용(읽기 전용 리소스 조회) 목적입니다. 생성(create) 하지 않습니다.

예시: AWS AMI 가져오기

data "aws_ami" "ubuntu" { # Ubuntu AMI 정보를 가져옴
  most_recent = true
  owners      = ["099720109477"] # Ubuntu 공식

  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-focal-20.04-amd64-server-*"]
  }
}

resource "aws_instance" "web" {
  ami           = data.aws_ami.ubuntu.id # 해당 AMI ID를 EC2 인스턴스 생성에 사용
  instance_type = "t2.micro"
}

📌 왜 사용하는가?

상황	이유
기존 리소스를 재사용해야 할 때	예: VPC, Subnet, AMI, IAM Role 등
외부 정보 기반으로 리소스를 만들고 싶을 때	예: 특정 태그가 붙은 인스턴스 ID 가져오기
리소스를 선언하지 않고 읽기만 하고 싶을 때	Data source는 읽기 전용

항목	`resource`	`data`
용도	리소스 생성/관리	리소스 조회(읽기 전용)
사용 예	`resource "aws_s3_bucket"`	`data "aws_ami"`
상태 저장	상태 파일에 저장 (생성됨)	상태 파일에 일부 저장 (읽기용)

🧠 기억할 개념 키워드

읽기 전용
외부 리소스의 정보 가져오기
구성 내 재사용 가능
선언된 리소스를 사용하지 않고도 정보 활용

✅ 문제 번역 및 정답 해설

❓문제

Terraform으로 리소스를 배포할 때 다음과 같은 data 블록을 설정했습니다.
이 data 블록이 사용될 경우 무슨 데이터를 반환하게 될까요?

data "aws_ami" "amzlinux2" {
  most_recent = true
  owners      = ["amazon"]

  filter {
    name   = "name"
    values = ["amzn2-ami-hvm-*-x86_64-ebs"]
  }
}

resource "aws_instance" "vault" {
  ami                         = data.aws_ami.amzlinux2.id
  instance_type               = "t3.micro"
  key_name                    = "vault-key"
  vpc_security_group_ids      = var.sg
  subnet_id                   = var.subnet
  associate_public_ip_address = "true"
  user_data                   = file("vault.sh")
 
  tags = {
    Name = "vault"
  }
}

✅ 정답

all possible data of a specific Amazon Machine Image (AMI) from AWS

🧠 해설

이 data 블록은 다음 조건에 맞는 가장 최신의 Amazon Linux 2 AMI 정보를 AWS에서 조회하여 반환합니다:

owners = ["amazon"]: 공식 AWS에서 배포한 것만 대상
filter: 이름이 "amzn2-ami-hvm-*-x86_64-ebs" 패턴에 일치하는 것
most_recent = true: 해당 조건을 만족하는 것 중 가장 최신의 이미지 선택

Terraform은 이 조건에 따라 해당 AMI에 대한 모든 메타데이터를 조회하고 사용할 수 있게 합니다.
예: id, name, architecture, root_device_type, virtualization_type 등등

ami = data.aws_ami.amzlinux2.id

위 코드는 data 블록에서 얻은 AMI ID만 사용하는 예시입니다.

❌ 오답 분석

✅ all possible data of a specific AMI	모든 관련 정보를 반환하며, 코드에서 원하는 속성 선택 가능	✅
❌ the latest AMI you have previously used	most_recent는 조건에 따라 가장 최신인 AMI를 조회, 사용 이력과는 무관	❌
❌ a custom AMI	owners = ["amazon"]은 AWS 공식 AMI만 대상으로 함 → custom 아님	❌
❌ the IP address of an EC2 instance	이 data 블록은 AMI에 대한 정보만 조회하며, EC2 인스턴스 정보는 아님	❌

📚 Terraform data 블록 핵심 개념 정리

Terraform에서 data 블록은 "읽기 전용" 외부 정보를 조회하는 데 사용됩니다.

🔹 언제 사용하는가?

이미 존재하는 리소스(예: 기존 VPC, AMI, 보안 그룹 등)를 참조할 때
리소스를 새로 만들지 않고, 기존 정보를 조회해서 재사용할 때

🔹 기본 구조

data "<provider>_<resource_type>" "<name>" {
  # 조건 및 필터
}

예: AWS AMI 정보 조회

data "aws_ami" "amzlinux2" {
  most_recent = true
  owners      = ["amazon"]

  filter {
    name   = "name"
    values = ["amzn2-ami-hvm-*-x86_64-ebs"]
  }
}

🔹 사용법 예시

resource "aws_instance" "web" {
  ami           = data.aws_ami.amzlinux2.id
  instance_type = "t2.micro"
}

data.aws_ami.amzlinux2.id: AMI ID
data.aws_ami.amzlinux2.name: AMI 이름
data.aws_ami.amzlinux2.architecture: CPU 아키텍처

🔹 주요 속성 (for aws_ami)

id: AMI ID
name: AMI 이름
description: 설명
architecture: x86_64, arm64 등
virtualization_type: hvm or paravirtual
root_device_type: ebs or instance-store

🔗 공식 문서 참고

HCP Terraform

✅ 문제 정답 및 해석

질문:
HCP Terraform(HCP = HashiCorp Cloud Platform Terraform)은 Terraform Community 버전에서는 사용할 수 없는 기능을 제공합니다.
HCP Terraform을 사용함으로써 추가적으로 제공되는 기능 세 가지를 고르시오.

🎯 정답:

✅ VCS connection
✅ remote runs
✅ private registry

❌ 오답 및 해설:

선택지	정답 여부	이유
providers	❌	Terraform의 provider는 Community 버전에서도 동일하게 사용 가능합니다. 이는 기본 기능입니다.
Terraform registry	❌	Terraform Registry는 오픈된 모듈 저장소로, Community와 HCP 모두 접근 가능합니다. 독점 기능이 아닙니다.

✅ 정답 선택지 해설

기능	설명
VCS connection	GitHub, GitLab, Bitbucket 등과 연동하여 코드가 푸시되면 자동으로 Terraform 실행(Plan/Apply)을 트리거할 수 있습니다. CI/CD 흐름을 지원합니다.
remote runs	Terraform Plan 및 Apply를 HCP의 원격 환경에서 실행합니다. 실행 환경 통제, 감사 로그, 역할 기반 액세스 제어 등이 가능합니다.
private registry	조직 내부 전용 모듈/프로바이더 저장소를 만들 수 있습니다. 보안과 모듈 재사용 측면에서 유리합니다. Community 버전에서는 불가능합니다.

📘 HCP Terraform vs Terraform Community

항목	Terraform Community	HCP Terraform
CLI 로컬 실행	✅ 지원	✅ 지원
원격 실행(Remote Run)	❌ 불가	✅ 가능
VCS 연동	❌ 수동 구성 필요	✅ GUI를 통한 연동
상태 파일 관리	직접 관리	✅ HCP에서 자동 관리 (백업, 잠금 등 포함)
RBAC(역할 기반 접근 제어)	❌ 없음	✅ 유료 플랜에서 가능
Private registry	❌ 없음	✅ 가능
감사 로그, 팀별 권한	❌ 없음	✅ 가능 (유료 플랜)

무료 HCP Terraform도 VCS 연동, 원격 실행, 상태 관리, private registry를 기본 제공합니다. (제한된 사용자 수)

Terraform Registry vs Private Registry

🌐 Terraform Registry (공개)

공식: registry.terraform.io
누구나 접근 가능
Community와 HCP 모두 사용 가능
공개된 모듈/프로바이더 저장소

🔒 Private Registry (HCP 전용 기능)

HCP Terraform 또는 Terraform Enterprise 사용 시 제공
조직 전용 모듈/프로바이더 저장소
RBAC 기반 권한 제어 가능
보안, 표준화된 인프라 코드 배포를 위한 필수 기능

🧠 요약

개념	설명
HCP Terraform	Terraform Cloud의 핵심 서비스로, VCS 연동, 원격 실행, 상태 관리, private registry 등을 제공
Terraform Community	오픈소스 CLI 중심, 상태 파일 직접 관리, 원격 실행 불가
Terraform Registry	전 세계 사용자가 공유하는 오픈 모듈/프로바이더 저장소
Private Registry	조직 내부에서만 사용하는 보안된 모듈 저장소 (HCP 전용)

Terraform plan이 Terraform apply 적용하기 전에 꼭 필요한 건 아니다. 권장사항.
main.tf가 꼭 필요한 거 아니다 -> .tf or .tf.json 파일 찾을거임
- As long as the Terraform code can locate and interpret the configuration files, the presence of a main.tf file is not mandatory.
remote backend configuration은 terraform 이용에 필수적인 거 아님. -> Remote Backends are completely optional

질문15

terraform init

✅ terraform init -upgrade 의 용도

📌 정답 해석

"update all previously installed plugins and modules to the newest version that complies with the configuration’s version constraints"

🧠 쉽게 말하면:

terraform init -upgrade 는 현재 디렉토리의 Terraform 설정 파일(.tf)에 명시된 **버전 제약 조건(version constraints)**에 맞는 최신 버전의 provider와 module을 다시 받아옵니다.

🔧 동작 방식 요약:

terraform init은 기본적으로 terraform.lock.hcl 파일에 기록된 provider/module 버전을 그대로 사용합니다.
-upgrade 플래그를 붙이면 이 기록을 무시하고, 버전 제약 조건에 맞는 가장 최신 버전을 받아옵니다.

예시:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 4.0"
    }
  }
}

이 설정에 대해 terraform init -upgrade를 실행하면:
- AWS provider는 4.0 이상 5.0 미만 중 가장 최신 버전으로 업그레이드됨
- 기존에 설치된 provider 버전은 무시하고 새로 설치됨
- terraform.lock.hcl도 업데이트됨

🧩 자주 출제되는 `terraform init` 관련 주요 플래그 정리

플래그	용도 요약	상세 설명
`-upgrade`	provider/module 업그레이드	버전 제약 조건 내에서 가장 최신 버전으로 설치, lock 파일 무시
`-backend-config="KEY=VALUE"`	백엔드 설정 커스터마이즈	원격 상태 파일 저장소의 속성을 설정 (예: S3 버킷명, 키 등)
`-reconfigure`	백엔드 재설정 강제	이전 설정 무시하고 backend를 다시 설정. 원격 백엔드 변경 시 필요
`-backend=false`	백엔드 사용 안 함	백엔드를 비활성화하고 로컬 상태 파일 사용 (주로 테스트 용도)
`-input=false`	사용자 입력 방지	초기화 중 변수 값 등을 물어보지 않음. 자동화된 환경에서 유용
`-lock=false`	상태 잠금 비활성화	원격 상태 파일에 대한 잠금(locking)을 하지 않음 (주의 필요)
`-plugin-dir=DIR`	로컬 plugin 경로 지정	provider plugin을 지정한 디렉터리에서 로드

✨ 기억해야 할 핵심 요점

terraform init은 Terraform 작업 디렉터리를 준비하는 명령어
- provider, module, backend 설정 등을 모두 처리
-upgrade는 lock 파일을 무시하고 최신 버전을 받는 것이 핵심
백엔드 관련된 설정 변경 시엔 -reconfigure 사용
자동화 시엔 -input=false 필수

📝 예시 문제 스타일

Q. What does the -reconfigure flag do when passed to terraform init?
A. It forces Terraform to reinitialize the backend, ignoring any saved configuration. ✅

workspace ⭐️⭐

🧩 문제 해석 및 정답 요약

Both Terraform Community/CLI and HCP Terraform offer a feature called "workspaces."
Which of the following statements are true regarding workspaces? (select three)

✅ 정답 1:

HCP Terraform manages infrastructure collections with a workspace whereas CLI manages collections of infrastructure resources with a persistent working directory

해석:
HCP Terraform은 각 workspace를 통해 인프라 집합을 관리하고,
Terraform CLI에서는 같은 디렉터리에서 여러 workspace를 생성하지만, 실제로는 서로 다른 상태 파일(state) 을 통해 자원을 분리 관리함.

❌ 오답 1:

Run history is logged in a file underneath the working directory of a CLI workspace

해석:
CLI에서는 실행 기록(run history)이 작업 디렉토리 내부 파일에 자동 저장되지는 않음.
실행 기록은 terraform apply 시 상태 파일(.tfstate)에 일부 저장되긴 하지만, HCP Terraform처럼 전체 run 기록(누가, 언제, 어떤 변화)을 추적하지는 않음.

❌ 오답 2:

Each CLI workspace coincides with a different VCS repo

해석:
CLI의 각 workspace는 동일한 작업 디렉토리 내에서 다른 상태 파일을 사용하는 구조일 뿐, 별도의 Git 리포지토리와 연동되지는 않음.
VCS 연동은 주로 HCP Terraform에서 사용하는 기능임.

✅ 정답 2:

CLI workspaces are alternative state files in the same working directory

해석:
정확한 설명. CLI에서 workspace를 만들면 동일한 .tf 코드에 대해, 다른 이름의 상태 파일을 만들어 환경(예: dev, staging, prod)을 분리할 수 있음.
예: terraform workspace new dev → terraform.tfstate.d/dev/terraform.tfstate

✅ 정답 3:

HCP Terraform maintains the state version and run history for each workspace

해석:
HCP Terraform은 각 workspace마다:
- 상태 파일의 버전 관리
- 실행 이력(run history)
- 변경 내용 추적 등을 자동으로 수행함.

📚 Workspace 정리: CLI vs HCP Terraform

구분	CLI Workspace	HCP Terraform Workspace
목적	동일한 코드에서 다른 상태(state) 관리 (예: dev, prod)	각 workspace가 하나의 프로젝트/인프라 단위
위치	로컬 작업 디렉토리	Terraform Cloud/HCP
상태 저장	로컬 또는 원격 백엔드	HCP 내 자동 저장
실행 기록	기본적으로 없음 (상태 파일에 일부 정보만)	전체 run history 추적 가능
VCS 연동	직접 수동 설정	자동 또는 GUI로 연동 가능 (GitHub, GitLab 등)
주요 명령어	`terraform workspace` 관련 명령어	HCP UI 또는 API 사용

📝 Terraform CLI에서 자주 쓰는 Workspace 명령어

terraform workspace list              # 모든 workspace 목록 보기
terraform workspace new <name>       # 새 workspace 생성
terraform workspace select <name>    # 해당 workspace로 전환
terraform workspace delete <name>    # workspace 삭제
terraform workspace show             # 현재 workspace 이름 표시

💡 시험 대비 포인트 요약

Terraform CLI의 workspace는 상태 파일(state) 을 분리하는 용도임 (terraform.tfstate.d/<workspace> 구조)
HCP Terraform은 workspace마다 별도 상태 관리 + VCS 연동 + 실행 이력(run history) 관리
CLI workspace는 Git repo와 직접적으로 매칭되지 않음
HCP workspace는 Git 연동이 기본 기능으로 제공됨
HCP에서 workspace = 하나의 인프라 배포 단위라고 이해하면 좋음
CLI에서 workspace를 쓰면 환경(dev/prod 등)을 손쉽게 나눌 수 있음

✅ 문제 번역 및 해설

❓문제 (원문 요약)

Pam은 Azure에 Terraform 구성을 성공적으로 배포했습니다.
그 후 새로운 workspace로 전환한 다음 점심을 먹으러 갔고, 돌아와서 비용 절감을 위해 다음 명령어를 실행했습니다:

와 이걸 대충읽었네 전환한 다음 밥먹으러 갔구나 팸 녀석

$ terraform destroy

하지만 출력 결과는 다음과 같이 나타났습니다:

Plan: 0 to add, 0 to change, 0 to destroy.

왜 아무 리소스도 삭제되지 않았을까요?

✅ 정답

There is no Terraform state in the current workspace she is working in
(Pam이 현재 작업 중인 workspace에는 Terraform 상태 파일이 존재하지 않기 때문입니다.)

🔍 해설 요약

Terraform은 workspace별로 상태(state)를 분리해서 관리합니다.
Pam이 리소스를 만든 후 다른 workspace로 전환했기 때문에,
현재 workspace에는 리소스 상태 정보가 없고, 따라서 삭제할 대상도 없는 것입니다.

❗즉, Terraform은 현재 workspace의 state 파일을 기준으로 리소스를 파악하고 관리합니다.
workspace를 바꾸면 해당 state를 참조하지 않기 때문에 terraform destroy는 삭제할 리소스를 찾지 못합니다.

❌ 오답 해설

보기 정답 여부 해설

Terraform reached the maximum timeout while Pam was away from lunch, therefore the resources were automatically destroyed	❌	Terraform은 자동으로 리소스를 삭제하지 않습니다. 반드시 사용자가 terraform destroy를 직접 실행해야만 삭제됩니다.
The Terraform state was deleted when she created the new workspace	❌	workspace를 새로 만든다고 기존 state가 "삭제"되지는 않습니다. 단지 새로운 빈 state가 생성될 뿐입니다. 기존 workspace에 가면 여전히 state는 존재합니다.
An Azure administrator manually deleted the resources	❌	관리자에 의해 리소스가 삭제되었다면, state 파일과 실제 리소스 간 불일치가 발생하고, 이 경우 terraform destroy는 여전히 state에 기록된 리소스를 삭제하려고 시도합니다. 하지만 이 경우는 "Plan: 0 to destroy"가 아닌 에러나 변경 필요 메시지를 반환할 수 있습니다.

📘 이 문제를 풀기 위해 꼭 알아야 할 Terraform 개념

✅ 1. Terraform State 파일이란?

Terraform이 관리하는 리소스들의 현재 상태를 기록하는 파일
보통 terraform.tfstate라는 이름으로 저장
리소스의 이름, 속성, ID 등 모든 정보 포함
이 파일이 없으면 Terraform은 무엇을 삭제하거나 수정해야 할지 모름

✅ 2. Workspace란?

Terraform의 상태 파일을 분리해서 여러 환경(예: dev, prod 등)을 독립적으로 운영할 수 있도록 함
각 workspace는 자기만의 state 파일을 가짐
기본 workspace는 default

terraform workspace new dev
terraform workspace select default

✅ 3. 현재 문제의 원인 요약

Pam은 리소스를 배포한 후 새로운 workspace로 전환함 → 새 workspace는 state가 없음
이후 terraform destroy 명령을 실행했으나 현 workspace에는 리소스가 없다고 판단 → 아무것도 삭제하지 않음

✅ 해결 방법

terraform workspace select <기존 workspace 이름> 명령으로 원래 workspace로 돌아간 후
다시 terraform destroy 실행하면 해당 리소스들을 삭제할 수 있음

🔗 참고 문서

Q. 내부 엔지니어와 아키텍트만 Terraform 모듈을 생성하고 배포할 수 있도록 제한하는 기능이 무엇인지

✅ 정답: Private Registry

✔ 해석 및 요약

Private Registry는 조직 내부에서만 접근 가능한 Terraform 모듈 저장소입니다.
엔지니어와 아키텍트만 모듈을 생성, 공유, 사용할 수 있도록 권한을 제한할 수 있습니다.
조직의 보안 유지 및 표준화된 인프라 코드 재사용에 적합합니다.

❌ 오답 설명 요약

옵션 설명 왜 오답인가?

Terraform Registry	공개 모듈 저장소 (https://registry.terraform.io)	누구나 접근 가능, 내부용 통제 불가
HashiCorp Sentinel	정책 코드로 보안·컴플라이언스 규칙 적용	모듈 배포 기능 없음
HCP Terraform Workspaces	작업 공간별 상태 관리, 협업 지원	모듈 생성·관리 기능은 없음

🔎 추가 요약: Private Registry란?

항목 내용

기능	조직 내부에서 모듈 생성, 버전 관리, 배포 가능
접근 통제	HCP 조직/팀 멤버만 접근 가능 (권한 기반)
장점	보안 강화, 표준 모듈 공유, 품질 관리 가능
플랫폼	HCP Terraform (Free 요금제 이상에서 사용 가능)

👉 공식 문서: Terraform Private Registry (HCP)

Terraform의 configuration 파일이 어떤 특성을 가질 수 있는지

❓ 문제

Aaron은 Terraform을 처음 사용하며, 배포 준비가 완료된 단일 설정 파일을 가지고 있습니다. 이 설정 파일에 대해 사실일 수 있는 것은 무엇인가요? (세 가지 선택)

✅ 올바른 선택지 (3개)

1️⃣ 그 설정 파일은 QA 및 Staging 애플리케이션 인프라를 모두 배포할 수 있다

해석: 하나의 설정 파일로 QA(품질 보증) 환경과 Staging(사전 배포) 환경을 모두 정의하고 배포할 수 있다.
설명: Terraform에서는 같은 설정 파일에서 변수나 워크스페이스 등을 활용하여 여러 환경(QA, Staging 등)을 관리할 수 있다.
👉 즉, 하나의 코드로 여러 환경을 다룰 수 있음.

2️⃣ Aaron의 설정 파일은 AWS와 GCP 모두에 애플리케이션을 배포할 수 있다

해석: 하나의 Terraform 설정 파일로 AWS와 GCP 양쪽 클라우드에 리소스를 생성할 수 있다.
설명: Terraform은 멀티 클라우드 배포를 지원하며, 같은 설정 내에서 provider를 각각 지정하면 AWS와 GCP 둘 다 관리 가능하다.
👉 멀티클라우드 인프라 관리가 가능하다는 의미.

3️⃣ 상태 파일은 Azure에 저장하면서 AWS에 애플리케이션을 배포할 수 있다

(the state file can be stored in Azure but provision applications in AWS)

해석: Terraform의 상태 파일(.tfstate)은 Azure에 저장해두고, 실제로는 AWS에 리소스를 생성할 수 있다.
설명: Terraform에서는 백엔드 설정(backend "azurerm" 등)을 통해 상태 파일 저장소를 분리할 수 있다. 예를 들어:
terraform { backend "azurerm" { ... } } provider "aws" { ... }
👉 상태 관리와 리소스 프로비저닝은 완전히 분리 가능.

❌ 잘못된 선택지

⛔ 멀티 클라우드 배포 시 민감한 데이터 공유를 막기 위해 the state를 비활성화할 수 있다

해석: 여러 클라우드에 배포할 때 민감 정보 보호를 위해 .tfstate 상태 파일을 아예 없앨 수 있다는 말.
설명: 틀림. 상태 파일은 Terraform에서 반드시 필요하며, 이를 통해 리소스의 현재 상태를 추적한다.
- 상태가 없으면 어떤 리소스를 생성/변경/삭제해야 할지 알 수 없음.
- 민감한 정보는 state encryption, remote backend with access control, Sensitive 변수 처리 등으로 보호해야 함.
👉 state 파일은 필수 요소이며, 비활성화할 수 없음.

📌 종합 요약

핵심 개념 설명

하나의 설정 파일	변수나 워크스페이스 등을 활용해 QA, Staging 등 다중 환경 구성 가능
멀티 클라우드	여러 provider 블록을 사용해 AWS, GCP 등 다양한 클라우드에 배포 가능
상태 파일 분리	상태 파일은 Azure 등 외부 스토리지에 저장하고, 리소스는 AWS 등에 생성 가능
상태 비활성화	불가. Terraform은 리소스 상태 추적을 위해 .tfstate 필수 사용

공식 문서 참고:
🔗 Terraform Use Cases – Multi-cloud Deployment

Terraform import

🧩 문제 해석 및 정리

❓ 문제

Michael은 Terraform을 사용해 AWS에 많은 리소스를 배포해왔고, 필요할 때마다 리소스를 업데이트하거나 제거할 수 있습니다.
한편, 새로 입사한 직원 Dwight는 애플리케이션 팀과 협력하여 AWS 콘솔을 통해 새 EC2 인스턴스를 배포했습니다.

Michael은 이 EC2 인스턴스를 Terraform으로 관리하고 싶어졌고, 터미널에 다음 명령어를 입력했습니다:

$ terraform import aws_instance.web_app_42 i-b54a26b28b8acv7233

그러나 다음과 같은 에러가 발생합니다:

Error: resource address "aws_instance.web_app_42" does not exist in the configuration.

✅ 올바른 질문:

Terraform이 새 EC2 인스턴스를 관리하려면 Michael이 가장 먼저 해야 할 일은 무엇인가요?

📌 정답:

✅ Terraform 설정 파일에 해당 리소스에 대한 구성을 먼저 작성해야 한다

resource "aws_instance" "web_app_42" {
  # (resource arguments는 생략 가능하지만, 존재해야 함)
}

🔍 해설

Terraform은 기존에 수동으로 만든 리소스라도 관리할 수 있음
단, terraform import 명령을 실행하기 전에 해당 리소스를 나타내는 구성 코드가 .tf 파일에 존재해야 함
Terraform은 단순히 AWS에서 리소스를 "불러오지" 않음 → 반드시 해당 리소스 구조를 코드로 선언해야 함
선언이 없으면 위와 같은 오류:
resource address "aws_instance.web_app_42" does not exist in the configuration.

❌ 오답 정리

Terraform은 수동으로 만든 리소스를 관리할 수 없다 (Terraform cannot manage resources that were provisioned manually)	틀림. 수동 리소스도 terraform import를 통해 관리 가능	❌
먼저 AWS에서 EC2 설정을 가져와야 한다 (import the configuration of the EC2 instance called web_app_42 from AWS first)	Terraform은 직접 설정을 가져오지 않음. 수동으로 코드 작성 필요	❌
EC2에 태그를 지정해서 Terraform이 인식하게 해야 한다 (configure the appropriate tags on the Amazon EC2 resource so Terraform knows that it should manage the resource moving forward)	태그는 관리 편의용. import와는 무관	❌

📚 관련 개념 요약

terraform import는 기존 리소스를 Terraform 상태(state)에 등록하는 도구
자동으로 코드 생성 X → .tf 파일에 리소스 정의가 먼저 있어야 함
구성만 있다고 해서 리소스를 생성하지 않음 → terraform import를 실행해야 연결됨

🔗 공식 문서

Terraform Import Command:
https://developer.hashicorp.com/terraform/cli/commands/import

input / output

✅ 문제 번역 및 해설

❓문제

아래의 Terraform 코드에서 servers = 4는 무엇을 의미하나요?

module "servers" {
  source = "./modules/aws-servers"
  servers = 4
}

✅ 정답

입력 변수(Input Variable)의 값

servers = 4

는 모듈 aws-servers 내부에서 정의된 입력 변수(input variable) servers에 값을 전달하는 것입니다.
즉, 이 모듈은 외부에서 몇 대의 서버를 생성할지를 변수로 받고 있으며, 여기서는 그 값을 4로 설정한 것입니다.

❌ 오답 해설

servers is not a valid configuration for a module	❌	servers = 4는 올바른 문법이며, input variable로 값을 전달하는 정상적인 구성입니다.
the output variable of the module	❌	servers = 4는 output이 아니라 input variable에 값을 주는 것입니다. output은 output 블록에서 선언되며 module 외부에서 사용됩니다.
the number of times the module will be executed	❌	모듈 반복 실행은 count나 for_each를 사용해야 하며, servers = 4는 단순한 입력값 설정일 뿐입니다.

📘 Terraform 모듈 사용 정리

Terraform 모듈을 사용할 때는 2가지 파일 구조를 이해해야 합니다:

🔹 1. 루트 모듈에서의 module 호출 형식

module "모듈_이름" {
  source  = "모듈_경로 또는 레지스트리"
  변수명1 = 값1
  변수명2 = 값2
}

예시:

module "servers" {
  source  = "./modules/aws-servers"
  servers = 4
  region  = "us-east-1"
}

source: 모듈의 경로 또는 Terraform Registry 주소
servers, region: 모듈에 정의된 input variable에 전달할 값

🔹 2. 모듈 내부에서 선언해야 할 것들

모듈 내부에는 다음과 같은 파일들이 포함될 수 있습니다:

main.tf	주요 리소스를 선언하는 곳 (EC2, S3 등)
variables.tf	외부에서 전달받을 input variable을 정의
outputs.tf	모듈 외부로 출력할 output 값을 정의
terraform.tfvars	(선택) 변수의 기본값을 지정

modules/
└── ec2-server/
    ├── main.tf         ← EC2 인스턴스 정의
    ├── variables.tf    ← 외부에서 받을 input 변수 선언
    ├── outputs.tf      ← 외부로 전달할 output 변수 선언

✅ 2-1. variables.tf 예시

variable "servers" {
  description = "Number of EC2 instances"
  type        = number
}

variable "region" {
  type    = string
  default = "us-west-2"
}

✅ 2-2. outputs.tf 예시

output "instance_ids" {
  value = aws_instance.web[*].id
}

output value로만 정의

output 변수(output variable)는 항상 value = ... 형식으로 값을 반환하도록 선언되며, 그 형식이 반드시 필요합니다.

✅ Output 변수 기본 형식

output "output_name" {
  value = <expression>
}

여기서 value는 반드시 포함되어야 하며, 이 블록이 output 변수임을 정의하는 핵심 요소입니다. output 블록에 value가 없다면 Terraform은 오류를 발생시킵니다.

🔹 예시 1: 단순 문자열 출력

output "instance_id" {
  value = aws_instance.web.id
}

→ 이 출력값은 실행 시 aws_instance.web.id 값을 외부에 노출합니다.

🔹 예시 2: 맵 형태 출력

output "db_info" {
  value = {
    username = var.db_user
    port     = var.db_port
  }
}

🔹 예시 3: 리스트 출력

output "subnet_ids" {
  value = aws_subnet.example[*].id
}

✅ 그 외의 선택적 속성들 (옵션)

description: 출력 변수 설명
sensitive: true로 설정 시 터미널에 출력되지 않음 (비밀번호 등)
depends_on: 특정 리소스에 의존성이 있을 때 사용

예시

output "db_password" {
  value     = var.db_password
  sensitive = true
}

❌ value 없이 output 선언? → 오류 발생

output "something" {
  # value 없이 선언하면 에러!
}

Terraform은 output 블록에서 무엇을 출력할지 명시적으로 정의해야 하므로 value는 필수 필드입니다.

✅ 요약

요소 필수 여부 설명

value	✅ 필수	어떤 값을 출력할지 정의
description	선택	출력 변수 설명
sensitive	선택	민감한 값 여부 지정
depends_on	선택	특정 리소스에 의존성 지정

output안에서도 depends_on 쓸 수 있다는 걸 모르고 있어서... 어디서만 쓰일 수 있나?

✅ depends_on이 쓰일 수 있는 위치

resource 블록	✅ 가능	한 리소스가 다른 리소스보다 나중에 생성되도록 명시할 때 사용
module 블록	✅ 가능	한 모듈이 다른 리소스/모듈보다 나중에 실행되도록
output 블록	✅ 가능	출력값이 특정 리소스나 모듈 이후에 계산되도록 보장
data 블록	❌ (직접 사용은 불가)	대신 리소스나 모듈을 통해 간접적으로 종속성 유도

✅ 예제: 각 블록에서의 depends_on 사용

1. resource 블록에서 사용

resource "aws_s3_bucket" "example" {
  bucket = "my-bucket"
}

resource "aws_s3_bucket_policy" "example_policy" {
  bucket = aws_s3_bucket.example.id

  policy = jsonencode({...})

  depends_on = [aws_s3_bucket.example]  # 명시적 의존
}

2. module 블록에서 사용

resource "aws_vpc" "main" {
  ...
}

module "subnets" {
  source = "./modules/subnet"
  vpc_id = aws_vpc.main.id

  depends_on = [aws_vpc.main]
}

3. output 블록에서 사용

output "s3_bucket_arn" {
  value      = aws_s3_bucket.example.arn
  depends_on = [aws_s3_bucket_policy.example_policy]  # 정책 생성 후 출력 보장
}

✅ 왜 depends_on이 필요한가?

Terraform은 암시적 의존성(예: resource_a.id를 사용하면 resource_a가 먼저 실행됨)을 자동으로 추적하지만,
명시적으로 의존성을 강제해야 할 때 depends_on을 사용합니다. 예:

참조는 없지만 리소스 생성 순서를 보장하고 싶을 때
Output 계산 전에 리소스가 완전히 생성되었는지 확실히 하고 싶을 때

✅ 요약

depends_on은 resource, module, output 블록에서 모두 사용 가능
output 전용 문법이 아니다
암시적 의존이 부족하거나, 명시적 순서를 지정하고 싶을 때 유용

✅ 2-3. main.tf 예시

resource "aws_instance" "web" {
  count         = var.servers
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"
}

🧠 핵심 요약

module "x"	다른 Terraform 코드 블록(모듈)을 재사용하기 위한 선언
source	모듈의 위치 (로컬 디렉토리, Git, Registry 등)
servers = 4	모듈에 정의된 input variable에 값을 전달하는 부분
variables.tf	외부에서 입력 받을 변수를 정의
outputs.tf	외부로 출력할 결과를 정의
반복 실행	count, for_each를 사용해야 하며, 변수 설정만으로 반복되지 않음

terraform agents

문제:
HCP Terraform 에이전트(HCP Terraform Agents)의 주요 기능은 무엇인가?

선택지 및 해설:

모니터링 및 문제 해결 (monitor and troubleshoot Terraform deployments)
→ 잘못된 답변. 모니터링과 문제 해결은 HCP Terraform 플랫폼의 다른 컴포넌트가 담당하며, 에이전트의 주 역할은 아님.
Terraform 상태 파일 저장 및 관리 (store and manage Terraform state files)
→ 잘못된 답변. 상태 파일 관리는 HCP Terraform의 백엔드 서비스가 담당. 에이전트는 상태 파일을 직접 관리하지 않음.
Terraform 작업공간 원격 접근 제공 (provide remote access to Terraform workspaces)
→ 잘못된 답변. 원격 접근 기능은 HCP Terraform 플랫폼이 제공하지만, 에이전트의 주 역할은 아님.
Terraform 플랜 실행 및 인프라 변경 적용 (execute Terraform plans and apply changes to infrastructure)
→ 정답. HCP Terraform 에이전트는 HCP Terraform 서비스에서 전달받은 Terraform 플랜을 타깃 인프라 환경에서 실행하고, 인프라를 원하는 상태로 변경하는 역할을 수행.

전반적인 설명

HCP Terraform 에이전트는 가볍고 경량화된 프로그램으로, 사용자의 인프라 환경(예: 사내 프라이빗 데이터센터, 클라우드 프라이빗 네트워크 등)에 배포됩니다.
에이전트는 Terraform Cloud (HCP Terraform) 와 인프라 사이의 다리 역할을 하며,
→ Terraform 작업을 원격으로 받으면, 이를 로컬 환경에서 실행하고 인프라에 변경 사항을 적용합니다.
이 구조 덕분에 인프라 환경을 인터넷에 직접 노출하지 않고도 Terraform Cloud와 안전하게 연동할 수 있습니다.

Terraform Agents에 대해 더 알아보기

1. 왜 Terraform Agent가 필요한가?

기존 Terraform Cloud/HCP Terraform은 인터넷을 통해 클라우드 인프라에 접근 가능.
그러나, 사내 데이터센터나 VPN 뒤, 방화벽 내부 등 직접적인 인터넷 접속이 어려운 환경에서는 Terraform Cloud가 인프라를 직접 관리하기 힘듦.
이때, Terraform Agent를 내부 환경에 배포해 에이전트가 직접 인프라에 접근하여 Terraform 작업을 수행하도록 함.

2. Terraform Agent 주요 기능

Terraform Plan 실행
Terraform Apply 실행
Terraform Destroy 실행
실행 결과 및 로그를 Terraform Cloud에 전달
네트워크 경계 내부에서 안전하게 동작

3. Agent 설치 및 구성

일반적으로 사용자 인프라 내 VM, 컨테이너 또는 서버에 설치
설치 후 Terraform Cloud와 인증 과정을 거쳐 연결
연결된 Terraform 작업공간(workspace)과 연동하여 작업 수행

4. Agent를 사용해야 하는 환경

온프레미스(사내) 인프라를 Terraform Cloud와 연동할 때
프라이빗 네트워크나 보안 요구사항으로 인터넷 노출이 불가능한 경우
멀티클라우드 환경에서 로컬 실행이 필요한 경우

5. 참고 링크

Terraform Cloud Agents 공식 문서
설치 및 운영 가이드, 보안 및 네트워크 구성 정보 포함

저작자표시 비영리 변경금지 (새창열림)