클라우드/DevOps

Terraform Associate (2)

dayeonsheep 2025. 5. 13. 01:00
  • dynamic block

: feature could you use to iterate over a list of required tcp ports to add to the new security group

-> Terraform에서 dynamic 블록을 사용하면 필수 TCP 포트 목록과 같은 항목 목록을 반복하고 해당 항목을 기반으로 동적으로 리소스를 생성할 수 있습니다. 이 기능은 여러 개의 유사한 리소스를 정의하는 데 필요한 코드 양을 줄여주므로, 최소한의 코드로 새 보안 그룹에 여러 TCP 포트를 추가하는 데 이상적입니다.

 

 

  • Workspaces provide similar functionality in the Community and HCP Terraform versions of Terraform.

: False.

While workspaces in the Community and HCP Terraform versions of Terraform serve the same purpose of managing multiple environments and configurations, there are differences in how they are implemented and accessed. HCP Terraform offers additional features and capabilities for managing workspaces, such as remote state management, collaboration tools, and version control integration, which are not available in the Community version.

 

Terraform의 커뮤니티 버전과 HCP Terraform 버전의 작업 공간은 여러 환경과 구성을 관리하는 동일한 목적을 수행하지만,

구현 및 액세스 방식에 차이가 있습니다.

HCP Terraform은 원격 상태 관리, 협업 도구, 버전 제어 통합 등 작업 공간 관리를 위한 추가 기능을 제공하는데,

이러한 기능은 커뮤니티 버전에서는 제공되지 않습니다.

 

Workspaces, managed with the terraform workspace command, isn't the same thing as HCP Terraform's workspaces. HCP Terraform workspaces act more like completely separate working directories.

CLI workspaces (Community) are just alternate state files.


 

  • In a parent module, outputs of child modules are available in expressions as module.<MODULE NAME>.<OUTPUT NAME>.
  • For example, if a child module named web_server declared an output named instance_ip_addr, you could access that value as module.web_server.instance_ip_addr.

 

 

  • a child module will have access to all variables set in the calling (parent) module.

False

설명

This choice is correct because,

by default, a child module in Terraform does not inherit all variables set in the calling (parent) module.

The parent module must explicitly pass variables to the child module by defining input variables in the child module's configuration.

This approach helps maintain clear boundaries between modules and prevents unintended variable leakage.

 

기본적으로, Terraform의 child module(자식 모듈)은 parent module(부모 모듈)에서 설정된 모든 변수에 자동으로 접근할 수 없습니다.
부모 모듈이 자식 모듈에 변수를 전달하려면, 자식 모듈에서 input variable을 정의하고, 모듈 블록에서 명시적으로 값을 전달해야 합니다.

이런 방식은 모듈 간 경계를 명확히 유지하고, 의도치 않은 변수 유출을 방지합니다.

 

Terraform에서는 하나의 모듈(보통 루트 모듈/root module)이 다른 모듈을 호출(module 호출)하여 그 리소스를 포함할 수 있습니다.
이렇게 다른 모듈을 호출한 경우, 호출된 모듈을 child module(자식 모듈)이라 부릅니다.

루트 모듈에서 변수를 선언했다면, CLI 옵션이나 환경 변수 등을 통해 값을 전달할 수 있지만,
자식 모듈의 변수는 반드시 module 블록 안에서 직접 값을 넘겨야 합니다.

 

 

  • Parent Module (부모 모듈): Terraform 실행이 시작되는 루트 모듈 또는 다른 모듈을 호출하는 모듈입니다.
  • Child Module (자식 모듈): parent module이 module 블록을 통해 호출한 모듈(호출된 모듈)로, source 속성을 통해 경로나 외부 모듈을 참조합니다.
    • source          = "./modules/server"
  • 핵심 원칙: 변수는 명시적으로 전달되어야 하며, 모듈 간은 독립적이고 캡슐화된 구조를 유지해야 합니다.

 

module "servers" {
  source = "./modules/app-cluster"

  servers = 5
}

 

  • 하위 모듈은 호출되는 쪽
  • 호출당하는 입장은 child module

모듈을 호출한다는 것은, 해당 모듈의 내용을 현재 구성(configuration) 안에 특정 입력값들과 함께 포함시킨다는 뜻입니다.
모듈은 module 블록을 통해 다른 모듈 안에서 호출됩니다.

  • 모듈 블록을 포함하고 있는 모듈이 호출 모듈(calling module)이고,
  • 참조된 모듈은 하위 모듈(child module)입니다.

module 키워드 바로 뒤에 오는 "servers" 같은 라벨은 이 모듈 인스턴스를 참조하기 위한 로컬 이름입니다.

 

 

  • In the terraform block, which configuration would be used to identify the specific version of a provider required
    • required_providers
terraform {
  required_providers {
    aws = {
      source = "hashicorp/aws"
      version = "3.57.0"
    }
  }
}

 

 

 

 

  • When configuring a remote backend in Terraform,
    it might be a good idea to purposely omit some of the required arguments to ensure secrets and other relevant data are not inadvertently shared with others.
    What alternatives are available to provide the remaining values to Terraform to initialize and communicate with the remote backend?
  • Terraform에서 remote backend를 설정할 때, 실수로 비밀 정보나 관련 데이터를 다른 사람들과 공유하지 않기 위해 일부 필수 인자를 의도적으로 생략하는 것이 좋습니다.
    Terraform이 remote backend와 통신할 수 있도록 나머지 값을 제공할 수 있는 방법 중 어떤 것이 가능한가요?

 

  1. ✅ HashiCorp Vault에서 직접 비밀값을 조회하기 (directly querying HashiCorp Vault for the secrets)
    1. 필요한 비밀값을 HashiCorp Vault에서 직접 가져오면, 민감한 정보를 중앙에서 안전하게 관리할 수 있습니다. Vault는 접근 권한을 제어하므로, 인증된 사용자만 필요한 데이터를 받을 수 있어 보안이 향상됩니다.
  2. ✅ 명령줄에서 인터랙티브하게 입력하기 (interactively on the command line)
    1. terraform init 시, 누락된 인자를 명령줄에서 실시간으로 직접 입력할 수 있습니다. 이 방법은 비밀번호 같은 민감 정보를 코드나 파일에 저장하지 않고 처리할 수 있어 비교적 안전합니다.
  3. ✅ -backend-config=PATH 플래그로 별도의 설정 파일 지정하기 (use the -backend-config=PATH flag to specify a separate config file)
    1. Terraform 실행 시 -backend-config 플래그를 사용해 별도 파일에서 민감 정보를 불러올 수 있습니다. 이 파일은 .gitignore 등에 등록하여 버전 관리에서 제외시킬 수 있습니다. 이는 비밀 노출 위험을 줄여줍니다.

❌ TFVARS 파일을 Git에 커밋하여 사용하는 것

.tfvars 파일에 비밀값을 넣고 이를 Git에 커밋하면, 협업 시 비밀번호 등 민감한 정보가 노출될 수 있어 매우 위험한 방법입니다. Git을 통해 비밀이 유출될 수 있으므로 사용하지 않아야 합니다.

 

 

개념 정리: Terraform Remote Backend와 민감 정보 관리

  • Remote Backend란?
    • Terraform이 상태 파일(Terraform state)을 로컬이 아닌 원격 저장소(S3, Azure Blob, Terraform Cloud 등)에 저장하도록 설정하는 기능입니다. 협업 시 필수적입니다.
  • 문제점
    • Remote backend 설정에는 비밀값(AWS Access Key, Storage 계정 키 등)이 필요합니다.
      이를 .tf 파일에 직접 작성하면 버전 관리(Git)에 노출될 위험이 있습니다.
  • 안전한 해결 방법
    • terraform init 시 명령줄에서 직접 입력
    • -backend-config 플래그로 별도 보안 설정 파일 사용
    • Vault, 환경 변수 등 보안 비밀 관리 시스템 연동

 

 

  • Terraform offers several advantages over using a provider's native tooling for deploying resources in multi-cloud environments, including:
  1. Multi-cloud support: Terraform은 AWS, Azure, Google Cloud 등 여러 클라우드 공급자를 아우르는 인프라 리소스 관리를 위한 일관된 인터페이스를 제공합니다. 이를 통해 조직은 여러 공급자별 도구를 따로 배울 필요 없이 하나의 도구로 전체 다중 클라우드 환경을 관리할 수 있습니다.
  2. Standardized configuration: Terraform은 선언형 구성 언어(declarative configuration language) 를 사용하여 인프라 리소스를 정의합니다. 이를 통해 여러 공급자에 걸친 리소스를 표준화된 방식으로 정의할 수 있어 구성의 일관성을 유지할 수 있으며, 공급자별 세부 지식을 줄일 수 있습니다.
  3. 멱등 실행 (Idempotent execution): Terraform은 원하는 상태와 현재 상태가 다를 경우에만 인프라 리소스를 변경합니다. 즉, 여러 번 실행해도 의도치 않은 변경 없이 안전하게 사용할 수 있습니다. 이는 구성의 일관성을 유지하고 드리프트(drift)를 줄이는 데 도움이 됩니다.
  4. Plan preview: Terraform은 인프라 리소스에 적용할 변경 사항을 사전에 보여주는 계획(plan)을 생성할 수 있습니다. 이를 통해 변경 사항에 대한 가시성을 확보하고 예기치 않은 결과를 방지할 수 있습니다.
  5. Collaboration and version control:  Terraform 구성은 버전 관리 시스템에 저장할 수 있어 여러 팀원이 인프라 변경 작업에 공동으로 참여할 수 있습니다. 이를 통해 문서화, 변경 이력, 이슈 추적 등의 중앙 집중화가 가능해져 인프라 관리를 더욱 효율적으로 할 수 있습니다.

 

  • When using variables in HCP Terraform, what level of scope can the variable be applied to?
  • 변수 적용 범위
    • Multiple workspaces using a variable set
    • A specific Terraform run in a single workspace
    • All current and future workspaces in a project using a variable set

Variables are typically scoped within a project or workspace to maintain organization and control over configuration settings.

Variable sets are constrained to a single organization.

You can't create variable sets that can be used across multiple HCP Terraform organizations. 안된다~

 

 

  • terraform console [options]
    • this command can be used to get an interactive console to evaluate expressions in your Terraform code.
    • an interactive command-line console for evaluating and experimenting with expressions.

✅ 간단한 설명

terraform console 명령어는 Terraform 설정이나 상태 파일을 기반으로 표현식(expression)을 테스트하거나 값(value)을 확인할 수 있는 대화형 콘솔 환경을 제공합니다.
리소스를 생성하지 않고도 변수, 출력값, 함수 결과 등을 실시간으로 확인할 수 있어 디버깅이나 학습에 유용합니다.

✅ 예시

$ terraform console
> 5 + 3
8

> upper("aws")
"AWS"

> var.project_name
"my-app"

※ 위 예시에서는 숫자 계산, 문자열 함수, 변수 참조 등을 실행하고 결과를 바로 확인하고 있습니다.

 

원하는 변수나 리소스 값을 미리 테스트해볼 때 자주 사용합니다.
Terraform 코드를 적용하지 않고도 안전하게 결과를 실험해볼 수 있어요.

 

 

  • state locking
    • is a critical feature of remote state storage that prevents multiple engineers from deploying infrastructure using the same state file simultaneously. 
    • It ensures that only one engineer can make changes to the state at a time, preventing conflicts and potential corruption of the state file.
    • State locking happens automatically on all operations that could write state. 
    • You won't see any message that it is happening. 
    • If state locking fails, Terraform will not continue. You can disable state locking for most commands with the -lock flag but it is not recommended.

 

  • Published modules via the Terraform Registry 
    • Public modules are managed via Git and GitHub.
    • Publishing a module takes only a few minutes.
    • Once a module is published, you can release a new version of a module by simply pushing a properly formed Git tag.
    • The module must be on GitHub and must be a public repo.
    • This is only a requirement for the public registry.
    • If you're using a private registry, you may ignore this requirement.

The key here is that HashiCorp uses GitHub for published modules.

 

✅ Terraform Registry란?

Terraform Registry는 HashiCorp가 운영하는 플랫폼으로,

Terraform 모듈(module) 및 프로바이더(provider)를 검색, 배포, 재사용할 수 있게 해주는 공식 저장소입니다.

여기서 모듈은 재사용 가능한 인프라 구성 단위입니다.

 

✅ Terraform Registry에 Published Module을 올리면 생기는 주요 이점 (요약)

  • ✅ 버전 관리 지원 (support versioning)
  • ✅ 버전 히스토리 열람 가능 (browse version histories)
  • ✅ 예제 및 README 표시 (examples and READMEs)
  • ✅ 자동 문서화 제공 (automatically generated docs)

모든 내용은 GitHub에 공개된 Public Repository를 기반으로 작동하며, Git 태그를 활용해 버전을 관리합니다.

 

✅ "Published Module"과 "Public Module" 차이?

  • 🔹 Published Module: Terraform Registry에 등록(Published) 되어 사용 가능한 모듈입니다. 공개든 비공개든 상관없습니다.
  • 🔹 Public Module: 누구나 접근할 수 있는 공개된 모듈로, Terraform 공식 퍼블릭 레지스트리(https://registry.terraform.io)에 등록된 모듈입니다.

즉,

용어 의미

Published Module Registry에 업로드된 모듈 (공개/비공개 모두 포함)
Public Module 공개 접근 가능한 모듈 (Terraform Public Registry에서 제공)

 

 

 

  • Stephen is writing brand new code and needs to ensure it is syntactically valid and internally consistent. Stephen doesn't want to wait for Terraform to access any remote services while making sure his code is valid. What command can he use to accomplish this?
  • => terraform validate

✅ 1. terraform show

📌 설명
Terraform이 관리하는 현재 인프라 상태(state)를 출력합니다. 코드 유효성 검사는 하지 않습니다.

📌 예시 실행

terraform show

📌 출력 예시

# aws_instance.web_server
resource "aws_instance" "web_server" {
    ami                         = "ami-0c55b159cbfafe1f0"
    instance_type               = "t2.micro"
    availability_zone           = "us-west-2a"
    tags = {
        Name = "WebServerInstance"
    }
}

 

✅ 2. terraform validate

📌 설명
Terraform 설정 파일의 문법적 오류와 내부 일관성을 확인합니다. 외부 서비스는 접근하지 않습니다.

📌 예시 실행

terraform validate

📌 출력 예시 (성공 시)

Success! The configuration is valid.

📌 출력 예시 (오류 시)

Error: Unsupported block type

  on main.tf line 10, in resource "aws_instance" "web_server":
  10: invalid_block {
      │
      ╰─ Unsupported block type "invalid_block" (did you mean "connection"?)

 

 

✅ 3. terraform apply -refresh-only

📌 설명
현재 상태 파일(state)을 실제 인프라 상태와 동기화(refresh)합니다. 리소스 변경은 없음.

📌 예시 실행

terraform apply -refresh-only

📌 출력 예시

Terraform will perform the following actions:

  # aws_instance.web_server will be read during refresh
  # (provider-generated changes will be reflected in state)

No changes. Your infrastructure matches the configuration.

Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

 

 

  • The prefix of the terraform plan
    • -/+ means that Terraform will destroy and recreate the resource, rather than updating it in-place.
    • Some attributes and resources can be updated in-place and are shown with the ~ prefix.
      • the resource will be updated in place

 

 

  • Before a new provider can be used, it must be ______ and _______. 
    • declared or used in a configuration file(설정 파일에 선언 또는 사용)
      • → provider 블록이나 특정 provider의 리소스를 사용할 경우, 해당 provider가 Terraform 설정 파일에 나타나야 Terraform이 이를 인식하고 사용합니다.
    • initialized
      • → 새로운 provider를 사용하기 위해선 반드시 terraform init 명령을 실행하여 provider 플러그인을 다운로드하고 초기화해야 합니다.

 

  • ❌ uploaded to source control (소스 제어에 업로드)
    → Terraform provider를 소스 제어(Git 등)에 업로드하는 것은 필수가 아닙니다. 협업에 도움이 될 수는 있지만, provider 사용 조건은 아닙니다.
  • ❌ approved by HashiCorp (HashiCorp의 승인을 받음)
    → Terraform에서 provider를 사용하기 위해 HashiCorp의 승인은 필요하지 않습니다. 공식 Registry 또는 사용자 정의 소스에서도 자유롭게 provider를 가져올 수 있습니다.

+ In Terraform, a plugin is a binary executable that implements a specific provider. 

+ A provider is a plugin that allows Terraform to manage a specific cloud provider or service.

+ definition : a plugin that Terraform uses to translate the API interactions with the service or provider

 

  • Which of the following Terraform files should be ignored by Git when committing code to a repo?
    • terraform.tfvars
      • The `terraform.tfvars` file contains variable values that are specific to a particular environment or deployment. 
      • It should be excluded from version control to prevent accidental exposure of sensitive information and to allow different environments to have their own variable values.
    • terraform.tfstate
      • The `terraform.tfstate` file stores the current state of the infrastructure managed by Terraform.
      • It should not be committed to version control as it contains sensitive information and can be dynamically updated during Terraform operations.

 

Terraform을 Git과 함께 사용할 때는 민감하거나 불필요한 정보를 저장소에 커밋하지 않도록 특정 파일들을 무시하는 것이 일반적으로 권장됩니다.
무시해야 할 파일은 프로젝트와 구성에 따라 다를 수 있지만, 일반적인 규칙은 다음과 같습니다:

  • .terraform 디렉토리: 이 디렉토리는 로컬 Terraform 상태 파일 등을 포함하며, 저장소에 커밋해서는 안 됩니다.
  • terraform.tfstate 및 terraform.tfstate.backup: 현재 인프라 상태를 포함하고 있어, 커밋 시 민감한 정보가 노출될 수 있으므로 제외해야 합니다.
  • .tfvars 파일: 비밀번호나 API 키와 같은 민감한 정보가 포함되어 있을 수 있어 버전 관리에서 제외해야 합니다. 대신 환경 변수 등 안전한 방식으로 Terraform에 정보를 전달하세요.
  • *.tfplan 파일: Terraform이 인프라 변경 시 생성하는 실행 계획으로, 리소스 ID 등의 민감 정보가 포함될 수 있습니다. 이 파일도 저장소에 포함해서는 안 됩니다.

 

Terraform은 인프라 상태와 민감 정보를 로컬 파일로 관리하기 때문에, 이를 그대로 Git에 커밋할 경우 보안 문제가 발생할 수 있습니다.

특히 terraform.tfstate 파일은 내부에 리소스 이름, 위치, 비밀번호, 토큰 등의 정보가 포함되어 있을 수 있으므로 공유 저장소에 올리는 것을 반드시 피해야 합니다.

보안 강화를 위해서는 다음과 같은 방법도 고려해보세요:

  • 원격 상태 저장소(예: S3, Terraform Cloud)를 사용하여 tfstate 파일을 안전하게 관리
  • .tfvars 파일 대신 환경 변수를 사용
  • 팀 전체에 .gitignore 설정을 적용하여 실수 방지
.terraform/
*.tfstate
*.tfstate.backup
*.tfvars
*.tfplan

 

 

  • Terraform Registry 
    • You found a module on the Terraform Registry that will provision the resources you need. 
    • What information can you find on the Terraform Registry to help you quickly use this module?
  • Dependencies to use the Module
  • A list of Outputs
  • Required Input Variables

Every page on the registry has a search field for finding modules. 

Enter any type of module you're looking for (examples: "vault," "vpc," "database"), 

and the resulting modules will be listed. 

The search query will look at the module name, provider, and description to match your search terms. 

On the results page, filters can be used to further refine search results.

 

 

  • In regards to Terraform state file, select all the statements below which are correct

❌ state file은 항상 암호화되어 저장된다 (the state file is always encrypted at rest)
설명: 로컬에 저장되는 상태 파일은 기본적으로 암호화되지 않습니다. 원격 저장소를 사용할 경우에도, 별도 설정이 없으면 암호화되지 않을 수 있습니다.

 

❌ sensitive = true를 사용하면 상태 파일에서 민감한 데이터가 마스킹된다 (using the sensitive = true feature, you can instruct Terraform to mask sensitive data in the state file)
설명: sensitive = true 속성은 Terraform 출력값을 CLI에 표시하지 않도록 마스킹하는 기능이지만, 상태 파일에는 여전히 민감한 정보가 평문으로 저장됩니다. 따라서 상태 파일을 읽을 수 있는 사람은 해당 민감한 정보도 확인할 수 있습니다.

 

✅ HCP Terraform은 상태 파일을 항상 암호화하여 저장한다 (HCP Terraform always encrypts state at rest)
설명: HashiCorp에서 제공하는 HCP Terraform(매니지드 서비스)은 상태 파일을 항상 암호화하여 저장합니다. 이를 통해 저장된 데이터의 기밀성과 무결성이 보장됩니다.

 

✅ Terraform 상태 파일에는 민감한 데이터가 포함될 수 있으므로, 무단 접근으로부터 보호되어야 한다 (the Terraform state can contain sensitive data, therefore the state file should be protected from unauthorized access)
설명: 상태 파일에는 비밀번호, API 키, 리소스 ID 등의 민감한 정보가 포함될 수 있어, 보안상 반드시 접근 통제가 필요합니다.

 

✅ 로컬 상태 사용 시 상태 파일은 일반 텍스트로 저장된다 (when using local state, the state file is stored in plain-text)
설명: 로컬 상태 파일(terraform.tfstate)은 JSON 형식으로 저장되며, 기본적으로 암호화되지 않기 때문에 민감한 정보가 노출될 수 있습니다.

When utilizing local state storage in Terraform, the state file is typically stored in plain-text format on the local machine. This can expose sensitive data to anyone with access to the file, highlighting the importance of securing the state file.

When using local state, state is stored in plain-text JSON files.

 

✅ 상태를 원격으로 저장하면 보안이 향상될 수 있다 (storing state remotely can provide better security)
설명: 클라우드 스토리지나 Terraform Cloud 같은 원격 저장소를 이용하면 암호화, 접근 제어, 감사 로그 등의 기능을 통해 보안을 강화할 수 있습니다.

Terraform 상태 파일은 어떤 정보를 포함하나요?

  • 상태 파일에는 리소스의 현재 상태, 속성 값, 참조 ID 등이 포함됩니다.
  • 예를 들어, 데이터베이스 리소스를 생성할 경우 초기 비밀번호 같은 정보도 저장됩니다.
  • 출력 값 중 민감하다고 설정한 값도 여전히 상태 파일에는 평문으로 기록됩니다.

sensitive = true가 해주는 일:

  • terraform apply나 terraform output 명령어 출력 시 터미널 상에서 마스킹해줍니다.
  • 하지만 terraform.tfstate 파일 안에는 여전히 노출됩니다 → 접근 권한 관리가 중요합니다.

보안 강화 방법:

  1. 로컬 저장소 대신 원격 저장소 사용:
    예: AWS S3 + DynamoDB (잠금 기능), Terraform Cloud, HCP Terraform 등
  2. 원격 저장소의 암호화 옵션 활성화:
    S3의 서버 측 암호화, GCS의 암호화 설정 등 활용
  3. .gitignore로 상태 파일 무시:
    상태 파일을 Git에 올리지 않도록 .gitignore에 반드시 추가
  4. IAM/ACL을 통해 접근 제어:
    상태 파일 접근 권한을 최소한의 사용자에게만 부여

출처: Terraform 공식 문서 - 상태 파일과 민감한 데이터

 

 

  • Terraform 상태(Terraform state)의 기능 중 일부로 올바른 것 (features of Terraform state)

 

✅ 리소스를 제거할 올바른 순서를 결정
Terraform 상태는 리소스 간의 종속성(dependencies)을 추적하여, 리소스를 제거(destroy)할 때 올바른 순서로 실행되도록 도와줍니다. 이를 통해 삭제 중 오류를 방지할 수 있습니다.

 

✅ 성능 향상
Terraform 상태는 현재 인프라 리소스의 상태를 저장함으로써 성능을 향상시킵니다. 이는 Terraform이 클라우드 제공자의 API를 매번 호출하지 않고도 변경 사항을 효율적으로 추적하고 리소스를 관리할 수 있도록 해줍니다.

 

✅ 구성(configuration)과 실제 리소스 간 매핑
Terraform 상태는 Terraform 파일에 정의된 구성과 실제 클라우드 인프라 리소스 간의 매핑 정보를 저장합니다. 이를 통해 Terraform이 실제 리소스를 정확하게 관리하고 업데이트할 수 있습니다.

 

❌ 클라우드 리소스 검사 (inspection of cloud resources)
Terraform 상태는 클라우드 리소스를 직접 검사하는 기능은 없습니다. 상태 파일은 리소스를 추적하고 관리하는 데 사용되지만, 클라우드 환경에서 실시간으로 리소스를 조회하거나 검사하는 기능은 제공하지 않습니다.

📘 공식 문서 기반 추가 설명

(출처: Terraform Docs - State Purpose)

Terraform의 상태 파일(terraform.tfstate)은 Terraform이 리소스를 관리할 수 있도록 하는 핵심 메커니즘입니다.

주요 목적은 다음과 같습니다:

🔹 1. 리소스 추적(Resource Mapping)

Terraform은 상태 파일을 사용해 선언된 리소스(aws_instance.example)와 실제 인프라 리소스(AWS의 EC2 인스턴스 등)를 연결합니다. 이를 통해 Terraform은 기존 리소스를 재사용하거나 변경할 수 있습니다.

🔹 2. 종속성 관리 및 변경 순서 결정

Terraform은 리소스 간 종속성을 상태 파일에서 파악하고, 이를 기반으로 create, update, destroy 순서를 결정합니다. 예를 들어, VPC를 삭제하기 전에 해당 VPC에 속한 인스턴스를 먼저 삭제해야 한다는 순서를 자동으로 파악합니다.

🔹 3. 성능 최적화

상태 파일을 통해 Terraform은 클라우드 API를 매번 호출하지 않아도 인프라 상태를 빠르게 파악할 수 있습니다. 이는 대규모 인프라 관리 시 큰 성능 향상을 가져옵니다.

📝 요약

기능 상태 파일의 역할

리소스 매핑 Terraform 구성 ↔ 실제 클라우드 리소스 간 연결 유지
종속성 관리 및 순서 결정 리소스 생성/삭제 시 순서 자동 조정
성능 향상 상태 캐시로 클라우드 API 반복 호출 없이 빠르게 인프라 상태 파악
보안 고려사항 상태 파일은 민감 정보를 포함할 수 있으므로 접근 통제와 암호화 필요

 

 

 

 

  • terraform state list / terraform state show
  • terraform state list
    • 기능: 현재 상태 파일에 저장된 모든 리소스의 목록을 보여줍니다.
    • 용도: 리소스가 몇 개나 있는지, 어떤 리소스가 추적되고 있는지 확인할 때 사용
  • terraform state show <리소스 이름>
    • 기능: 특정 리소스의 상세 속성 정보(state 내용)를 출력합니다.
    • 용도: 해당 리소스가 어떤 속성/값을 가지는지 확인할 때 사용
      • $ terraform state show aws_instance.web
      • # aws_instance.web:
        resource "aws_instance" "web" {
          ami                          = "ami-0abc1234"
          instance_type               = "t2.micro"
          availability_zone           = "us-west-2a"
          private_ip                  = "10.0.0.1"
          public_ip                   = "54.123.45.67"
          ...
        }
  • terraform output / terraform show

terraform output

  • 기능: Terraform에서 output 블록으로 정의된 출력 변수 값만 보여줍니다.
  • 용도: 인프라 구축 후 외부에 전달하거나 사용할 값(예: IP 주소, URL 등)을 확인할 때 사용
  • 출력 정보: 사용자가 명시적으로 output "변수명" 으로 정의한 값들

예시 명령어:

terraform output

예시 출력:

instance_ip = "54.123.45.67"
bucket_name = "my-terraform-bucket"

 

terraform show

  • 기능: 현재 terraform.tfstate에 저장된 전체 인프라 상태 정보를 보여줍니다.
  • 용도: 현재 구축된 리소스들의 전체 속성/구성 확인
  • 출력 정보: 리소스별 속성 (모든 값 포함, 민감 정보도 포함될 수 있음)

예시 명령어:

terraform show

예시 출력:

# aws_instance.web:
resource "aws_instance" "web" {
  ami           = "ami-0abc1234"
  instance_type = "t2.micro"
  public_ip     = "54.123.45.67"
  ...
}

# aws_s3_bucket.my_bucket:
resource "aws_s3_bucket" "my_bucket" {
  bucket = "my-terraform-bucket"
  ...
}

 

명령어 설명 주요 용도 포함 정보
terraform output output 블록으로 정의한 값 출력 배포 후 외부 전달 정보 확인 사용자 정의 출력 값만 표시
terraform show 상태 파일 전체 리소스 및 속성 출력 현재 인프라 상태 상세 확인 모든 리소스 속성 전체 포함
  • terraform output은 사람이나 다른 시스템에 필요한 정보만 골라내는 목적
  • terraform show는 상태 파일 전체를 들여다보는 도구

 

Terraform Expressions 핵심 요약

Terraform의 Expressions(표현식)은 변수, 리소스 속성, 연산자 등을 결합해 값을 계산하는 방식입니다. 

1. 표현식(Expression)의 목적

  • Terraform 설정에서 값을 계산하거나 조건부 로직을 작성하는 데 사용됨.
  • 예: 변수 참조, 문자열 결합, 조건문 등
name = var.project_name
size = length(var.subnet_ids)
enabled = var.env == "prod" ? true : false

 

2. 지원하는 주요 표현식 타입

  • Literal values: 문자열, 숫자, 불리언 등 ("hello", 42, true)
  • References: 변수, 리소스, 모듈 참조 (var.name, aws_instance.web.id)
  • Function calls: 내장 함수 사용 (length(list), lower(string))
  • Operations: 연산자 (+, -, ==, &&, ||, ? :)
  • Collections: 리스트, 맵, 집합 등 구조적 데이터

3. List 타입

  • list(<TYPE>): 동일한 타입의 값들을 순서대로 갖는 컬렉션
  • 요소 접근: mylist[0]
  • 생성 예시:
list_of_names = ["alice", "bob", "carol"]
  • 리스트 길이: length(var.list_of_names)
  • 반복 처리: for_each, for 표현식에서 주로 사용

4. 예시 정리

# 변수 참조
project = var.project_name

# 조건부 표현식
is_enabled = var.env == "prod" ? true : false

# 리스트 생성 및 접근
ids = [1, 2, 3]
first_id = ids[0]

# 함수 사용
lowercase = lower("HELLO")

#🔹 예: map 타입 선언
variable "region_map" {
  type = map(string)
  default = {
    prod = "us-west-1"
    dev  = "us-east-1"
  }
}
# 이건 단순히 "문자열 값으로 구성된 key-value 쌍" 타입이라는 뜻이에요.

 

 

1. 🔁 for 표현식 (List/Map comprehension)

  • 리스트나 맵을 생성할 때 반복 처리에 사용.
  • 파이썬의 list comprehension과 유사.
# 리스트 comprehension
upper_names = [for name in var.names : upper(name)]

# 조건 필터링
even_numbers = [for n in var.numbers : n if n % 2 == 0]

# 맵 comprehension
name_map = { for name in var.names : name => upper(name) }

 

2. 🔁 for_each (리소스 반복 생성)

  • 리소스를 여러 개 생성할 때 사용.
  • 리스트나 맵의 각 요소에 대해 하나씩 리소스 생성.
resource "aws_instance" "web" {
  for_each = var.instances

  ami           = each.value.ami
  instance_type = each.value.instance_type
}
  • each.key, each.value로 반복 요소 접근

3. 🔧 dynamic 블록

  • 리소스 내에서 반복적으로 나오는 서브 블록을 유연하게 생성할 때 사용.
  • 예: security_group_rule처럼 반복 블록이 있는 경우
resource "aws_security_group" "example" {
  name = "example"

  dynamic "ingress" {
    for_each = var.rules
    content {
      from_port   = ingress.value.from_port
      to_port     = ingress.value.to_port
      protocol    = ingress.value.protocol
      cidr_blocks = ingress.value.cidr_blocks
    }
  }
}

 

4. 🧠 기타 자주 쓰이는 표현식들

📌 conditional (삼항 연산자)

instance_type = var.env == "prod" ? "t3.large" : "t3.micro"

📌 coalesce() - 첫 번째 non-null 값 반환

bucket_name = coalesce(var.override_name, var.default_name)

📌 merge() - 맵 병합

settings = merge(var.default_settings, var.override_settings)

📌 lookup() - 키 조회 with 기본값

region = lookup(var.region_map, var.env, "us-west-1")

📌 compact() - null 또는 빈 문자열 제거

filtered_list = compact(["a", "", null, "b"])

 

🔚 요약

표현식 유형 용도

for 리스트/맵 생성 (comprehension)
for_each 리소스 반복 생성
dynamic 반복 블록 유연하게 생성
조건부 ? : if-else
coalesce 첫 유효값 선택
lookup, merge 맵 처리
compact, length, contains 리스트 유틸리티

 

 

Terraform에서 provider의 required version을 선언하는 이유

terraform {
  required_providers {
    aws = {
      source = "hashicorp/aws"
      version = "3.57.0"
    }
  }
}

주요 이유들:

  1. Reproducibility (재현성):
    특정 provider 버전을 명시함으로써, Terraform 구성을 실행하는 사람들이 동일한 provider 버전을 사용하도록 할 수 있습니다.
    이렇게 하면 인프라 구성이 더 재현 가능해지고, 서로 다른 버전의 provider를 사용할 때 발생할 수 있는 문제를 피할 수 있습니다.
  2. Predictability (예측 가능성):
    특정 버전의 provider를 명시하면, 향후 버전에서 provider에 대한 변경 사항에 관계없이 인프라 구성이 예측 가능하게 유지됩니다. 이는 의도치 않은 결과를 줄이고, 예기치 않은 상황에 대한 리스크를 줄이는 데 도움이 됩니다.
  3. Compatibility (호환성):
    provider의 각 버전은 다른 API, 리소스 또는 동작을 가질 수 있습니다.
    새로운 버전으로 전환할 때 이 차이를 모르고 변경하면 문제가 발생할 수 있습니다.
    Terraform 구성 파일에서 required version을 명시함으로써, 테스트 및 검증된 특정 버전과 호환된 구성이 유지되도록 보장할 수 있습니다.
  4. Version locking (버전 잠금):
    Terraform 구성 파일에서 provider 버전을 명시하면, 해당 버전이 명시적으로 변경될 때까지 그 버전으로 잠금이 됩니다.
    이렇게 하면 잠재적으로 호환되지 않는 버전으로 인프라를 실행하는 문제를 예방할 수 있습니다.

추가 설명

Terraform에서 provider 버전을 명시하는 것은 인프라 구성의 예측 가능성, 재현 가능성, 호환성을 보장하는 중요한 방법입니다. 이를 통해 버전 차이로 인해 발생할 수 있는 문제를 줄이고, 인프라가 예상대로 동작하도록 할 수 있습니다.

왜 이것이 중요한가?

  • Provider version은 Terraform의 main program과 별도로 배포되기 때문에, 최신 버전이 breaking changes를 도입할 가능성이 있습니다.
    따라서 버전 충돌이나 호환성 문제를 방지하기 위해서는 정확한 버전을 명시하는 것이 중요합니다.
더보기

"breaking changes"는 소프트웨어나 시스템의 기존 기능이나 사용 방식이 더 이상 작동하지 않도록 바뀌는 변화를 말합니다.

Terraform에서 provider의 breaking change는 다음과 같은 경우에 해당합니다:

💥 breaking change 예시

변경 유형설명
❌ 속성 이름 변경 이전에는 instance_type이었는데 새 버전에서 vm_type으로 바뀌면, 기존 코드가 작동하지 않음
❌ 기본값 제거 이전에는 특정 속성이 생략 가능했는데, 새 버전에서는 필수가 되면 에러 발생
❌ 자원 제거 또는 구조 변경 특정 리소스 타입이 삭제되거나 하위 구조가 바뀌면 기존 구성 불가능
❌ 출력 형식 변경 출력 결과나 상태 데이터의 구조가 변경되면, 이를 참조하는 다른 코드에서 에러 발생

 

 

❌to remove older versions of the provider

설명:
Terraform 구성 파일에서 provider의 required version을 선언하는 것은 이전 버전의 provider를 제거하는 것이 아닙니다.

이는 구성에서 어떤 버전의 provider를 사용해야 하는지를 지정하는 역할을 합니다.

이전 버전의⭐️provider는 여전히 시스템에 존재할 수 있지만, 구성에서는 지정된 버전만 사용합니다.

 

❌to ensure that the provider version matches the version of Terraform you are using
설명:
provider의 버전은 사용 중인 Terraform 버전과 일치해야 할 필요가 있지만, 실제로는 그 자체가 중요한 것은 아닙니다.

구성 파일에서 provider의 required version을 선언하면 Terraform 버전과의 호환성 문제를 방지하는 것이 아니라,

지정된 provider 버전을 사용하여 구성이 원활하게 실행되도록 보장하는 것입니다.

 

❌to match the version number of your application being deployed via Terraform
설명:
Terraform 구성 파일에서 provider의 required version을 선언하는 이유는 애플리케이션 배포 버전과 일치시키기 위함이 아닙니다. provider 버전은 Terraform 구성과의 일관성 및 호환성을 보장하기 위해 지정되는 것이며,

배포되는 애플리케이션의 버전과는 관련이 없습니다.

 

✅ providers are released on a separate schedule from Terraform itself; therefore, a newer version could introduce breaking changes ⭐️
설명:
provider는 Terraform과 별도로 배포 일정이 관리되기 때문에,

최신 버전의 provider가 breaking changes를 도입할 수 있습니다.

이는 현재 구성과 호환되지 않을 수 있습니다.

따라서 필요한 버전을 명시함으로써 구성 파일이 특정 provider 버전에서 예상대로 작동하도록 보장하는 것이 중요합니다.

 

 

  • terraform import
  • You want to start managing resources that were not originally provisioned through infrastructure as code. Before you can import the resource's current state, what must you do before running the terraform import command?


✅ Terraform 구성 파일을 업데이트하여 가져오려는 리소스와 일치하는 새로운 리소스를 추가해야 합니다.

(update the Terraform configuration file to include the new resources that match the resources you want to import)

설명:
terraform import 명령어를 실행하기 전에, 가져오려는 리소스와 일치하는 새로운 리소스를 포함하도록 Terraform 구성 파일을 업데이트해야 합니다. 이 단계는 Terraform이 관리하려는 리소스를 인식할 수 있도록 하고, 해당 리소스의 현재 상태를 올바르게 가져올 수 있도록 보장합니다.

 

- Terraform 상태 파일을 수정하여 새 리소스를 추가하여 Terraform이 관리할 리소스에 대한 기록을 생성해야 한다. (modify the Terraform state file to add the new resources so Terraform will have a record of the resources to be managed)

설명:
terraform import 명령어를 실행하기 전에 Terraform 상태 파일을 수정하여 새 리소스를 추가하는 것은 올바른 접근 방식이 아닙니다. 상태 파일은 Terraform에 의해 관리되어야 하며, 이를 수동으로 수정하면 일관성이 떨어지고 리소스 관리에 문제가 발생할 수 있습니다.

 

- 가져오려는 리소스를 중지하거나 사용을 중지해야 하며, 변경 사항이 누락되지 않도록 해야 한다. (shut down or stop using the resources being imported so no changes are inadvertently missed)

설명:
리소스를 가져오기 전에 중지하거나 사용을 중지하는 것은 필요하지 않습니다. terraform import 과정은 리소스를 중지시키지 않고, 대신 리소스의 현재 상태를 Terraform의 관리하에 두는 데 중점을 둡니다.

 

- terraform apply -refresh-only 명령어를 실행하여 상태 파일에 최신 정보가 반영되었는지 확인해야 한다. (run terraform apply -refresh-only to ensure that the state file has the latest information for existing resources.)

설명:
terraform apply -refresh-only를 실행하는 것은 새 리소스를 가져오기 전에 필요한 과정이 아닙니다. terraform import 명령어는 이미 존재하는 리소스를 Terraform의 상태에 가져오는 데 사용되며, 상태 파일을 새로 고침하기 위한 refresh-only 명령어 실행은 이 과정에 필요하지 않습니다.

 

전반적인 설명:
참고: HashiCorp는 가져온 리소스를 위한 Terraform configuration을 자동으로 생성하는 기능을 출시했습니다.

그러나 시험 질문이 즉시 업데이트되지 않기 때문에, 시험에서는 여전히 구성 파일을 직접 생성해야 한다고 가정할 수 있습니다.

현재 terraform import의 구현은 리소스를 상태 파일에 가져오는 기능만 제공합니다. 구성은 생성되지 않습니다.

따라서 terraform import를 실행하기 전에, 가져온 리소스가 매핑될 리소스 구성 블록을 수동으로 작성해야 합니다.

 

먼저 구성 파일에 리소스를 추가하세요:

resource "aws_instance" "example" {
  # ...instance configuration...
}

 

그런 다음 다음 명령어를 실행하세요:

$ terraform import aws_instance.example i-abcd1234

 

 

  • API and CLI 

HCP Terraform can be managed from the CLI but requires __________?

an API token

설명

  • HCP Terraform can be managed from the CLI by using an API token.
  • The API token serves as a secure way to authenticate and authorize CLI access to HCP Terraform resources and operations.
  • API and CLI access are managed with API tokens, which can be generated in the HCP Terraform UI.
  • Each user can generate any number of personal API tokens, which allow access with their own identity and permissions.
  • Organizations and teams can also generate tokens for automating tasks that aren't tied to an individual user.

 

 

  • multiple provider를 single terraform configuration file에 선언했을 때, When executing Terraform commands, you can use the -target option to specify which provider you want to apply changes to.
  • For example, you could apply changes to the AWS provider by running terraform apply -target=aws.

 

 

  • In HCP Terraform, a workspace can be mapped to how many VCS repos?
    • => 1
    • 설명
      • In HCP Terraform, a workspace can be mapped to only one VCS (Version Control System) repository. 
      • This means that the workspace will be associated with a single repository where the Terraform configuration files are stored and managed.
      • A workspace can only be configured to a single VCS repo,
      • however, multiple workspaces can use the same repo, if needed.
      • A good explanation of how to configure your code repositories can be found here.

 

  • Which Terraform command will force a resource to be destroyed and recreated even if there are no configuration changes that would require it?

✅ 정답: terraform apply -replace=<address>

terraform apply -replace=<address> 명령어는 구성 변경이 없어도 특정 리소스를 강제로 삭제 후 재생성하도록 합니다.

이 명령어에 리소스 주소를 지정하면, Terraform은 해당 리소스를 최신 구성으로 다시 만들도록 강제로 처리합니다.

이는 외부에서 리소스가 손상되었거나 문제가 발생했을 때 유용하게 사용할 수 있습니다.

❌ terraform destroy

terraform destroy 명령어는 구성된 모든 리소스를 제거합니다. 특정 리소스를 선택적으로 재생성하는 기능은 없으며, 전체 인프라를 제거할 때 사용됩니다.

❌ terraform apply -refresh-only

terraform apply -refresh-only는 실제 인프라 상태를 기반으로 Terraform의 상태 파일을 최신 상태로 업데이트하지만, 리소스를 변경하지는 않습니다. 즉, 삭제나 재생성을 하지 않습니다.

 

전반적인 설명 번역

terraform apply -replace=<address> 명령어는 Terraform이 관리하는 특정 리소스를 명시적으로 대체(mark as replaced) 하도록 지정합니다. 구성에 변경이 없어도 해당 리소스는 삭제 후 재생성되며, 문제가 있는 리소스를 복구할 때 유용합니다.

⚠️ 중요 사항:
이 명령어는 이전의 terraform taint 명령어를 대체하며, 시험에서는 여전히 terraform taint가 등장할 수 있으므로 두 명령어 모두 숙지해야 합니다.

 

📌 명령어 요약

terraform apply -replace=... 지정한 리소스를 강제로 삭제 후 재생성
terraform destroy 모든 리소스를 삭제
terraform fmt 구성 파일을 포맷 정리
terraform apply -refresh-only 상태 파일을 최신 인프라 정보로 갱신, 리소스 변경 없음
terraform taint (구버전) 리소스를 taint 처리하여 apply 시 재생성 

 

 

  • HCP Terraform workspace

Similar to Terraform Community, you must use the CLI to switch between workspaces when using HCP Terraform workspaces.

Terraform Community와 마찬가지로, HCP Terraform에서 워크스페이스를 전환하려면 반드시 CLI를 사용해야 한다.

정답: False

 

설명:
False. HCP Terraform에서는 웹 인터페이스를 통해 직접 워크스페이스를 전환할 수 있으므로, 워크스페이스 관리를 위해 CLI를 사용할 필요가 없습니다.
HCP Terraform은 직관적인 웹 UI를 제공하여 사용자들이 CLI 없이도 워크스페이스를 효율적으로 전환하고 관리할 수 있게 합니다.

HCP Terraform에서 각 워크스페이스는 별도의 환경(예: 개발, 스테이징, 프로덕션)을 나타내며, 사용자는 웹 UI의 워크스페이스 스위처를 통해 쉽게 전환하고 해당 인프라를 관리할 수 있습니다.

Terraform CLI는 주로 로컬 개발 환경에서 Terraform 명령어를 실행하는 데 사용됩니다.

HCP Terraform을 사용할 경우, 보통은 웹 UI 또는 API를 통해 워크스페이스에 접근하고 관리합니다.

물론, CLI에서 terraform workspace 명령어를 통해 워크스페이스를 관리할 수도 있지만, 이는 로컬 backend 사용 시에 해당하며, HCP Terraform backend에서는 필요하지 않습니다.

 

HCP Terraform 워크스페이스 전환 방법 웹 UI에서 직접 전환 가능 — CLI 필요 없음
워크스페이스의 의미 각 워크스페이스는 별도 인프라 환경 (예: dev, prod 등)
CLI 사용 상황 로컬 backend 사용 시 terraform workspace 명령어 사용
HCP Terraform 사용 시 권장 방법 웹 UI 또는 API 기반 관리
Terraform CLI의 역할 로컬에서 Terraform 실행 및 테스트에 사용

 

 

워크스페이스(workspace)의 개념과 Local Backend vs HCP Terraform Backend 간의 워크스페이스 관리 방식의 차이

Terraform 워크스페이스(Workspace)란?

Terraform에서 워크스페이스는 동일한 구성(configuration)으로 여러 독립적인 인프라 상태(state)를 관리할 수 있도록 해주는 논리적인 분리 단위입니다.

예시

  • 하나의 main.tf 파일로 dev, stage, prod 환경을 각각 관리하고 싶을 때,
  • 워크스페이스를 dev, stage, prod로 만들면,
    • 각각 독립적인 terraform.tfstate를 갖게 되어
    • 같은 코드라도 다른 인프라를 만들 수 있습니다.

Local Backend vs HCP Terraform Backend의 워크스페이스 비교

항목  Local Backend  HCP Terraform Backend
워크스페이스 생성 및 전환 terraform workspace new/select 등의 CLI 명령어 필요 HCP 웹 UI에서 클릭 한 번으로 전환 가능
저장 위치 로컬 디렉토리 (terraform.tfstate.d/) HCP 서버에 원격 저장 (관리 자동화)
워크스페이스 관리 방식 CLI 기반 수동 관리 웹 UI 또는 API로 시각적 관리
워크스페이스 상태 파일 워크스페이스마다 별도 디렉토리에 terraform.tfstate 저장 HCP가 자동으로 분리된 상태 파일 저장 및 관리
협업 기능 수동으로 상태 파일 공유/관리 필요 팀 단위 협업 및 변경 기록 관리 내장
보안 및 버전 관리 별도 설정 필요 내장 보안, 버전 히스토리, 롤백 기능 제공
  • Local Backend는 로컬 컴퓨터에서 CLI로 워크스페이스를 관리하며, 상태 파일도 직접 관리해야 함.
  • HCP Backend는 워크스페이스 전환과 상태 관리를 웹 UI 또는 API로 자동화하여 협업과 보안성이 뛰어남.
  • 워크스페이스를 통해 하나의 Terraform 구성 파일로 여러 환경(dev, prod 등)을 분리된 상태로 관리할 수 있음.

 

  • Terraform 상태 파일(terraform.tfstate)의 저장 위치 및 관련 개념

Q. Terraform Community/CLI는 기본적으로 어디에 상태 파일을 저장하는가? (By default, where does Terraform Community/CLI store its state file?)

 

❌ remotely using HCP Terraform
Terraform Community/CLI는 기본적으로 상태 파일을 HCP Terraform 원격 저장소에 저장하지 않습니다.

HCP를 백엔드로 설정하면 가능하지만, 이는 기본 동작이 아닙니다.

 

✅ current working directory
정답입니다. Terraform Community/CLI는 기본적으로 상태 파일을 Terraform 구성 파일이 위치한 현재 작업 디렉토리에 저장합니다. 이를 통해 상태 파일에 쉽게 접근하고 관리할 수 있습니다.

 

❌ shared directory
Terraform Community/CLI는 기본적으로 상태 파일을 공유 디렉토리에 저장하지 않습니다. 공유 디렉토리에 저장하도록 설정은 가능하지만, 기본 동작은 아닙니다.

 

❌ Amazon S3 bucket
Amazon S3에 상태 파일을 저장하려면 사용자가 별도로 backend "s3" 설정을 추가해야 합니다. 이는 기본값이 아닙니다.

상태 파일 저장 위치의 기본 동작

Terraform은 인프라 상태를 추적하기 위해 상태 파일(terraform.tfstate)을 사용

  • 기본 위치 (Default):
    • 현재 디렉토리에 저장
    • CLI가 실행된 폴더 기준
    • 협업에는 적합하지 않음 (로컬 환경에 종속됨)
  • ./terraform.tfstate
  • 변경 가능 (Remote backends 설정 시):
    • S3, Azure Blob Storage, Google Cloud Storage
    • HCP Terraform (HashiCorp Cloud Platform)
    • Consul, etcd, PostgreSQL 등도 가능

예: 로컬 vs 원격 백엔드 설정

✅ 로컬 (기본값, 별도 설정 필요 없음)

terraform init
terraform apply
# terraform.tfstate 가 현재 디렉토리에 자동 생성됨

☁️ 원격 (예: S3 백엔드 사용)

terraform {
  backend "s3" {
    bucket = "my-terraform-state"
    key    = "global/s3/terraform.tfstate"
    region = "us-east-1"
  }
}
상태 파일 이름 terraform.tfstate
저장 위치 (기본) 현재 작업 디렉토리
원격 저장소 사용 시 backend 설정 필요 (예: S3, HCP 등)
협업 시 권장 원격 backend 사용 (동시성, 버전 관리, 잠금 기능 지원)

 

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