[Terraform] 프로바이더, State, 워크스페이스

💡cloudNet@ 팀의 가시다 님이 진행하는 Terraform 101 Study 4기 4주차 내용으로,
[테라폼으로 시작하는 IaC] 도서를 참조하였습니다. 감사합니다..

 

1. 프로바이더

테라폼은 terraform 바이너리 파일을 시작으로 로컬 환경이나 배포 서버와 같은 원격 환경에서 원하는 대상을 호출하는 방식으로 실행된다. 이때 ‘원하는 대상’은 호출하는 방식이 서로 다르지만 대상의 공급자 즉, 프로바이더가 제공하는 API를 호출해 상호작용 한다.

 

여기서 테라폼이 대상과의 상호작용을 할 수 있도록 하는 것이 프로바이더이다.

각 프로바이더의 API 구현은 서로 다르지만 이전 포스팅에서 살펴본 테라폼의 고유 문법으로 동일한 동작을 수행하도록 구현되어 있다.

 

프로바이더는 플러그인 형태로 테라폼에 결합되어 대상이 되는 클라우드, SaaS, 기타 서비스 API를 사용해 동작을 수행한다. 각 프로바이더는 테라폼이 관리하는 리소스 유형과 데이터 소스를 사용할 수 있도록 연결한다.

 

즉, 테라폼은 프로바이더 없이는 어떤 종류의 인프라나 서비스도 관리할 수 없다.

대부분의 프로바이더는 대상 인프라 환경이나 서비스 환경에 대해 리소스를 관리하므로, 프로바이더를 구성할 때는 대상과의 연결과 인증에 필요한 정보가 제공되어야 한다.

 

일부 프로바이더는 유틸리티적인 측면으로 로컬에서 동작한다.

 

각 프로바이더는 테라폼 실행 파일과는 별도로 자체 관리되고 게시된다. 테라폼 레지스트리 사이트에서 주요 프로바이더와 관련 문서를 확인할 수 있다.

https://registry.terraform.io/browse/providers

 

1.1 프로바이더 구성

프로바이더 구성에 대한 요구사항은 공식 레지스트리 사이트에 공개되어 있는 각 프로바이더 구성 방식을 참고하는 것이 정석이다.

local 프로바이더처럼 프로바이더를 위한 별도 구성이 필요하지 않은 경우도 있지만, AWS와 같은 클라우드 프로바이더의 경우는 AWS 자격증명 정보와 리전 이름 등을 정의하기도 한다.

사진-1

 

각 프로바이더에 user provider 버튼을 선택하여 버전에 맞는 정의 방법을 확인할 수 있다.

 

로컬 이름과 프로바이더 지정

terraform 블록에 required_providers 블록 내에 <로컬 이름> = { } 으로 여러 개의 프로바이더를 정의할 수 있다. 여기서 사용되는 로컬 이름은 테라폼 모듈 내에서 고유해야 한다.

로컬 이름과 리소스 접두사는 독립적으로 선언되며, 각 프로바이더의 소스 경로가 지정되면 프로바이더의 고유 접두사가 제공된다. 만일 동일한 접두사를 사용하는 프로바이더가 선언되는 경우 로컬 이름을 달리하여 관련 리소스에서 어떤 프로바이더를 사용하는지 명시적으로 지정할 수 있다.

 

예를 들어 다음의 main.tf에서처럼 동일한 http 이름을 사용하는 다수의 프로바이더가 있는 경우 각 프로바이더에 고유한 이름을 부여하고 리소스와 데이터 소스에 어떤 프로바이더를 사용할지 provider 인수에 명시한다. 단, 동일한 source에 대해 다수의 정의는 불가능하다.

 

다음은 동일한 http 접두사를 사용하는 다수의 프로바이더 사용의 정의이다.

terraform {
  **required_providers** {
    architech-http = {
      source = "architect-team/**http**"
      version = "~> 3.0"
    }
    http = {
      source = "hashicorp/**http**"
    }
    **aws-http** = {
      source = "terraform-aws-modules/**http**"
    }
  }
}

data "**http**" "example" {
  **provider = aws-http**
  url = "https://checkpoint-api.hashicorp.com/v1/check/terraform"

  request_headers = {
    Accept = "application/json"
  }
}

 

 

단일 프로바이더의 다중 정의

동일한 프로바이더를 사용하지만 다른 조건을 갖는 경우, 사용되는 리소스마다 별도로 선언된 프로바이더를 지정해야 하는 경우가 있다.

예를 들면 AWS 프로바이더를 사용하는데 서로 다른 권한의 IAM을 갖는 Access ID 또는 대상 리전을 지정해야 하는 경우이다. 이 때는 프로바이더 선언에서 alias를 명시하고 사용하는 리소스와 데이터 소스에서는 provider 메타인수를 사용해 특정 프로바이더를 지정할 수 있다.

provider 메타인수에 지정되지 않은 경우 alias가 없는 프로바이더가 기본 프로바이더로 동작한다.

아래 예제는 리전을 다르게 구성한 AWS 푸로바이더를 aws_instance에 지정하는 방법이다.

 

단일 프로바이더의 다중 정의 시 리소스에서 특정 프로바이더를 정의하는 방법

provider "**aws**" {
  region = "ap-southeast-1"
}

provider "**aws**" {
  **alias = "seoul"**
  region = "ap-northeast-2"
}

resource "**aws**_instance" "app_server1" {
  ami           = "ami-06b79cf2aee0d5c92"
  instance_type = "t2.micro"
}

resource "**aws**_instance" "app_server2" {
  **provider      = aws.seoul**
  ami           = "ami-0ea4d4b8dc1e46212"
  instance_type = "t2.micro"
}

실행 결과. 각 서울리전과 싱가폴 리전에 생성되었다.

사진-2

사진-3

사진-4

 

 

프로바이더 요구사항 정의

테라폼 실행 시 요구되는 프로바이더 요구사항은 terraform 블록의 required_providers 블록에 여러 개를 정의할 수 있다. source에는 프로바이더 다운로드 경로를 지정하고 version은 버전 제약을 명시한다.

다음은 프로바이더 요구사항 정의 블록이다.

terraform {
  required_providers {
    <프로바이더 로컬 이름> = {
      source = [<호스트 주소>/]<네임스페이스>/<유형>
      version = <버전 제약>
    }
    ...
  }
}

• 호스트 주소 : 프로바이더를 배포하는 주소로서 기본값은 registry.terraform.io
• 네임스페이스 : 지정된 레지스트리 내에서 구분하는 네임스페이스로, 공개된 레지스트리 및 Terraform Cloud의 비공개 레지스트리의 프로바이더를 게시하는 조직을 의미
• 유형 : 프로바이더에서 관리되는 플랫폼이나 서비스 이름으로 일반적으로 접두사와 일치하나 일부 예외가 있을 수 있음

 

프로바이더는 기능이나 조건이 시간이 지남에 따라 변경될 수 있다. 이 같은 변경에 특정 버전을 명시하거나 버전 호환성을 정의할 때, version에 명시할 수 있다. 이 값이 생략되는 경우 terraform init을 하는 당시의 가장 최신 버전으로 선택된다.

 

 

프로바이더 설치

테라폼을 실행하기 전 terraform init 명령을 통해 정의된 프로바이더를 다운로드, 복사, 캐시에서 읽어오게 된다. 항상 지정된 구성에 대해 동일한 프로바이더를 설치하도록 하려면 테라폼 구성에 사용되는 프로바이더에 대해 명시적으로 terraform 블록에 정의하거나 .terraform.lock.hcl 잠금 파일을 코드 저장소에 공유하는 방안이 요구된다.

 

이전에 살펴본 것처럼 required_providers에 지정된 프로바이더가 있는 경우 코드상 구성에서 사용 여부에 관계없이 프로바이더를 다운로드하게 되고, required_providers에 지정하지 않더라고 테라폼 구성 코드사에서 사용된 프로바이더를 테라폼에서 추론해 최신 버전의 프로바이더를 다운로드 한다.

 

프로바이더 간 전환 여부

클라우드를 대상으로 테라폼을 사용하는 경우 다른 클라우드 프로바이더로 전환이 가능할까? 불가능하다.

테라폼은 인프라에 대한 단일 프로비저닝 도구로 사용되지만 대상이 되는 환경은 서로 다른 API로 구현된 프로바이더가 제공된다. 예를 들어 AWS 구성을 Azure로, Azure의 구성을 GCP로 전환하는게 불가능하지만 IaC로서의 테라폼의 특성이 작업 효율을 높혀준다.

 

프로바이더 간 대응되는 리소스 예시

사진-5

 

 

1.2 프로바이더 에코시스템

테라폼의 에코시스템은 사용자가 사용하는 방식과 구조에 테라폼을 적용할 수 있도록 설계된다. 에코시스템을 위한 테라폼 통합은 워크플로 파트너와 인프라 파트너로 나뉜다.

워크플로 파트너는 테라폼 실행 및 Terraform Cloud/Enterprise와 연계하여 동작하는 기능을 제공하는 항목으로 이루어져 있다.

 

대표적으로 테라폼 구성을 관리하기 위한 VCS를 제공하는 깃허브, GitLab, Bitbucket, Azure Devops가 항목에 해당한다.

 

프로바이더의 경우 인프라 파트너에 해당된다. 인프라 파트너는 사용자가 테라폼으로 대상 플랫폼의 API로 상호작용 가능한 리소스를 관리할 수 있도록 한다.

인프라 파트너의 분류와 프로바이더 대상은 다음과 같다.

**퍼블릭 클라우드**

- IaaS, SaaS 및 PaaS를 포함한 다양한 서비스를 제공하는 대규모 글로벌 클라우드 제공

**컨테이너 오케스트레이션**

- 컨테이너 프로비저닝 및 배포를 지원

**IaaS(Infrastructure-as-a-Service)**

- 스토리지, 네트워킹 및 가상화와 같은 솔루션을 제공하는 인프라 및 IaaS 제공

**보안 및 인증**

- 인증 및 보안 모니터링 플랫폼

**자산 관리**

- 소프트웨어 라이선스, 하드웨어 자산 및 클라우드 리소스를 비롯한 주요 조직 및 IT 리소스의 자산 관리를 제공

**CI/CD**

- 지속적인 통합 및 지속적인 제공/배포

**로깅 및 모니터링**

- 로거, 측정 도구 및 모니터링 서비스와 같은 서비스를 구성하고 관리하는 기능

**유틸리티**

- 임의 값 생성, 파일 생성, http 상호 작용 및 시간 기반 리소스와 같은 도우미 기능

**클라우드 자동화**

- 구성 관리와 같은 전문화된 클라우드 인프라 자동화 관리 기능

**데이터 관리**

- 데이터 센터 스토리지, 백업 및 복구 솔루션

**네트워킹**

- 라우팅, 스위칭, 방화벽 및 SD-WAN 솔루션과 같은 네트워크별 하드웨어 및 가상화된 제품과 통합

**VCS(버전 제어 시스템)**

- Terraform 내에서 VCS(버전 제어 시스템) 프로젝트, 팀 및 리포지토리에 중점

**통신 및 메시징**

- 통신, 이메일 및 메시징 플랫폼과 통합

**데이터베이스**

- 데이터베이스 리소스를 프로비저닝 및 구성하는 기능

**PaaS(Platform-as-a-Service)**

- 다양한 하드웨어, 소프트웨어 및 애플리케이션 개발 도구를 제공하는 플랫폼 및 PaaS

**웹 서비스**

- 웹 호스팅, 웹 성능, CDN 및 DNS 서비스

 

사진-6

 

퍼블릭 클라우드 프로바이더

테라폼을 접하는 경로 중 퍼블릭 클라우드 환경을 프로비저닝 하려는 경우가 많다. 테라폼 뿐만 아닌 많은 IaC 도구가 클라우드 프로비저닝에 활용된다.

퍼블릭 클라우드는 설계 단계에서 대부분의 리소스 구성에 대해 API 기반을 고려하기 때문에 테라폼으로 풍부한 리소스 구성이 가능하다.

 

컨테이너 오케스트레이터

대표적으로 노마드, 쿠버네티스, 랜처, 탄주를 예롤 들 수 있는데, 최신 오케스트레이션 도구들은 저마다의 IaC 방식을 지원하지만 테라폼 같은 상태 기반 동작을 수행하지는 않는다.

그래서 테라폼이 제공하는 코드적인 기능과 함수 및 변수를 기반으로 기존 IaC 방식 대비 테라폼의 구성 방식을 활용할 수 있고, 배포 환경이 되는 클라우드와 IaaS 환경을 테라폼으로 구성한 후 애플리케이션을 배포할 수 있다.

 

SaaS 서비스

설치형과 달리 SaaS 서비스는 개별 계정 관리, 접근 관리, 네트워크 구성 등 각 SaaS 서비스마다 독립적으로 제공하는 리소스에 대해 관리가 필요하다.

 

기타 솔루션

인프라 환경의 네트워크 장비, 방화벽, 스토리지, 모니터링 도구 등 API를 제공하는 각 솔루션 또한 테라폼 프로바이더가 제공되어 솔루션에 대한 설정이 가능하다.

 

 

1.3 프로바이더 경험해보기

실습으로 2개의 리전에 Ubuntu EC2를 배포해보겠다.

다음과 같이 tf 파일을 생성한다. 리전 별 AMI ID 값이 다르므로, 필터를 활용한다.

ec2.tf
resource "aws_instance" "region_1" {
  **provider = aws.region_1**

  **ami           = data.aws_ami.ubuntu_region_1.id**
  instance_type = "t2.micro"
}

resource "aws_instance" "region_2" {
  **provider = aws.region_2**

  **ami           = data.aws_ami.ubuntu_region_2.id**
  instance_type = "t2.micro"
}

# provider_data.tf
provider "aws" {
  region = "ap-northeast-2"
  alias  = "region_1"
}

provider "aws" {
  region = "ap-southeast-1"
  alias  = "region_2"
}

data "aws_region" "region_1" {
  provider = aws.region_1
}

data "aws_region" "region_2" {
  provider = aws.region_2
}

data "aws_ami" "ubuntu_region_1" {
  provider = aws.region_1

  most_recent = true
  owners      = ["099720109477"] # Canonical

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

data "aws_ami" "ubuntu_region_2" {
  provider = aws.region_2

  most_recent = true
  owners      = ["099720109477"] # Canonical

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

 

실행 결과

사진-7

사진-8

사진-9

사진-10

 

2가지 주의 사항!!

1. Warning 1 : Multiregion is hard 프로덕션 수준의 멀티 리전은 어렵다
   • Active-Active 멀티 리전 서비스를 위해서 ‘지역간 지연 시간, 고유 ID, 최종 일관성’ 등 여러가지 고려사항이 많아서 쉽지 않다.
2. Warning 2 : Use aliases sparingly Alias 를 빈번하게 사용하지 말자
   • 별칭을 사용하여 두 리전에 배포하는 단일 테라폼 모듈은 한 리전이 다운 시, plan 과 apply 시도가 실패합니다
   • 프로덕션 환경은 멀티 리전의 별칭을 사용하는 것보다는, 3장에서 설명한 것 처럼 환경을 완전히 격리해야 합니다.
   • 이를 통해 영향도를 최소화 할 수 있습니다.

 

2. State

테라폼은 Stateful(상태가 있는) 애플리케이션이다. 프로비저닝 결과에 따른 State(상태)를 저장하고 프로비저닝한 모든 내용을 저장된 상태로 추적한다.

로컬 실행 환경에서는 terraform.tfstate 파일에 JSON 형태로 저장되고, 팀이나 조직에서의 공동 관리를 위해서는 원격 저장소에 저장해 공유하는 방식을 활용한다.

State에는 작업자가 정의한 코드와 실제 반영된 프로비저닝 결과를 저장하고 이 정보를 토대로 리소스 생성, 수정, 삭제에 대한 동작 판단 작업을 수행한다.

 

2.1 State의 목적과 의미

코드 변경 후 apply 명령을 실행하면 이전에 생성된 리소스와 비교해 생성, 수정, 삭제 동작이 수행되는 것을 확인했다. 테라폼은 state를 사용해 대상 환경에서 어떤 리소스가 테라폼으로 관리되는 리소스인지 판별하고 결과를 기록한다.

state의 역할은 다음과 같다.

• State에는 테라폼 구성과 실제를 동기화하고 각 리소스에 고유한 아이디(리소스 주소)로 맵핑
• 리소스 종속성과 같은 메타데이터를 저장하고 추적
• 테라폼 구성으로 프로비저닝 결과를 캐싱하는 역할을 수행

State 동작 확인을 진행해보겠다. 다음과 같이 random 프로바이더를 사용한다.

resource "random_password" "cwpass" {
  length           = 16
  special          = true
  override_special = "!#$%"
}

 

 

실행 결과

사진-11

 

 

생성된 terraform.tfstate 파일

{
  "version": 4,
  "terraform_version": "1.8.5",
  "serial": 1,
  "lineage": "9e0a46f9-e624-8325-dfc4-a23598c54f07",
  "outputs": {},
  "resources": [
    {
      "mode": "managed",
      "type": "random_password",
      "name": "cwpass",
      "provider": "provider[\"registry.terraform.io/hashicorp/random\"]",
      "instances": [
        {
          "schema_version": 3,
          "attributes": {
            "bcrypt_hash": "$2a$10$oftud8/FQL4lTJ2vKUtdhuJd4MyDKiaF1vxKUnp8Z6S6Eg385vq7a",
            "id": "none",
            "keepers": null,
            "length": 16,
            "lower": true,
            "min_lower": 0,
            "min_numeric": 0,
            "min_special": 0,
            "min_upper": 0,
            "number": true,
            "numeric": true,
            "override_special": "!#$%",
            "result": "y49WJijtbeoshyOC",
            "special": true,
            "upper": true
          },
          "sensitive_attributes": [
            [
              {
                "type": "get_attr",
                "value": "bcrypt_hash"
              }
            ],
            [
              {
                "type": "get_attr",
                "value": "result"
              }
            ]
          ]
        }
      ]
    }
  ],
  "check_results": null
}

테라폼에서는 이 JSON 형태로 작성된 State를 통해 속성과 인수를 읽고 확인할 수 있다. 테라폼에서는 type과 name으로 고유한 리소스를 분류하며 해당 리소스의 속성과 인수를 구성과 비교해 대상 리소스를 생성, 수정, 삭제한다.

 

! State는 테라폼만을 위한 API로 정의할 수도 있다.

plan을 실행하면 암묵적으로 refresh 동작을 수행하면서 리소스 생성의 대상(클라우드, SaaS 등) 과 State를 기준으로 비교하는 과정을 거친다. 이 작업은 프로비저닝 대상의 응답 속도와 기존 작성된 state의 리소스 양에 따라 속도 차이가 발생한다.

대량의 리소스를 관리해야 하는 경우 plan 명령에서 -refresh=false 플래그를 사용해 State를 기준으로 실행 계획을 생성하고, 이를 실행에 활용해 대상 환경과의 동기화 과정을 생략할 수 있다.

# 실행 계획 생성 시 저장되어 있는 State와 실제 형상을 비교하는 기본 실행
time terraform **plan**

# 실행 계획 생성 시 실제 형상과 비교하지 않고 실행 계획을 생성하는 -refresh=false 옵션
time terraform plan **-refresh=false**

 

상태 파일 확인 실습

다음과 같이 tf 파일을 생성한다.

# vpc.tf 
provider "aws" {
  region  = "ap-northeast-2"
}

resource "**aws_vpc**" "**myvpc**" {
  cidr_block       = "10.10.0.0/16"

  tags = {
    Name = "**t101-study**"
  }
}

사진-12

 

 

다음과 같이 tag를 수정하고 다시 실행해보겠다.

provider "aws" {
  region  = "ap-northeast-2"
}

resource "aws_vpc" "myvpc" {
  cidr_block       = "10.10.0.0/16"

  tags = {
    Name = "tf-state"
  }
}

다음과 같이 백업 파일이 생성된다. 백업 파일과 내용을 비교해보겠다.

사진-13

사진-14

 

2.2 State 동기화

테라폼 구성 파일은 기존 State와 구성을 비교해 실행 계획에서 생성, 수정, 삭제 여부를 결정한다고 이전에 설명했다.

사진-15

 

다음은 Plan과 Apply 중에 각 리소스에 발생할 수 있는 네 가지 사항이다. Replace 동작은 기본값을 삭제 후 생성하지만 lifecycle의 create_before_destory 옵션을 통해 생성 후 삭제를 수행하도록 설정할 수 있다.

 

기호	의미
+	Create
-	Destroy
-/+	Replace
~	Updated in-place

 

테라폼 구성에 추가된 리소스와 State에 따라 어떤 동작이 발생하는지 다음 실습으로 확인해보겠다.

 

유형	구성 리소스 정의(*.tf)	State 구성 데이터	실제 리소스	기본 예상 동작
1	있음			리소스 생성
2	있음	있음		리소스 생성
3	있음	있음	있음	동작 없음
4		있음	있음	리소스 삭제
5			있음	동작 없음

 

 

유형1 : 신규 리소스 정의 > Apply > 리소스 생성

다음과 같이 tf 파일을 생성하고 실행하겠다.

locals {
  name = "mytest"
}

resource "aws_iam_user" "myiamuser1" {
  name = "${local.name}1"
}

resource "aws_iam_user" "myiamuser2" {
  name = "${local.name}2"
}

사진-16

 

유형2 : 실제 리소스 수동 제거 > Apply > 리소스 생성

실제 리소스를 수동 제거하고 결과를 확인해보겠다.

다음과 같이 iam 유저를 수동 삭제한 후, 정상적으로 삭제된 것을 확인한다.

사진-17

 

 

그리고 plan을 실행한 결과와 refresh 단계를 생략한 결과를 비교해보겠다.

devcw@woos-dev-server:/mnt/c/Users/chanw/OneDrive/바탕 화면/terraform/5.2$ terraform plan
aws_iam_user.myiamuser1: Refreshing state... [id=mytest1]
aws_iam_user.myiamuser2: Refreshing state... [id=mytest2]
.
.
Plan: 2 to add, 0 to change, 0 to destroy.

devcw@woos-dev-server:/mnt/c/Users/chanw/OneDrive/바탕 화면/terraform/5.2$ terraform plan -refresh=false

No changes. Your infrastructure matches the configuration.

plan 실행 결과 리소스 정의와 State가 있지만 실재하는 대상이 없어 다시 생성하는 실행 계획이 나타난다.

그리고 두번쨰로 Refresh 단계를 생략할 경우 실행 계획에 변경이 없는 것을 확인할 수 있다.

다시 apply를 진행하고, iam 사용자를 확인한다.

사진-18

 

 

유형3 : Apply > Apply < 코드, State, 형상 모두 일치한 경우

테라폼 구성에 정의된 리소스로 생성된 프로비저닝 결과가 State에 있고 실제 리소스도 있는 경우라면 테라폼은 관련 리소스에 대한 변경 계획을 발생시키지 않는다.

위 유형 2에 다시 terraform apply를 수행해 프로비저닝 결과가 있는 경우 plan으로 실행 계획을 생성해도 변경 사항이 없다.

terraform apply -auto-approve
cat terraform.tfstate | jq .serial

terraform apply -auto-approve
cat terraform.tfstate | jq .serial

terraform apply -auto-approve
cat terraform.tfstate | jq .serial

 

 

유형4 : 코드에서 일부 리소스 삭제 > Apply

구성, State, 실제 리소스가 있는 상태에서 테라폼 구문을 삭제하면 사용자는 의도적으로 해당 리소스를 삭제하는 것이다.

테라폼은 구성 파일을 기준으로 State와 비교해 삭제된 구성을 실제 리소스에서 제거한다.

다음과 같이 tf 파일을 수정한다.

locals {
  name = "mytest"
}

resource "aws_iam_user" "myiamuser1" {
  name = "${local.name}1"
}

사진-19

 

유형5

이미 만들어진 리소스만 있다면 테라폼의 state에 없는 내용이므로 테라폼으로 관리되지 않는다.

따라서 해당 리소스에 대해서는 아무 작업도 수행할 수 없다.

• 처음부터 테라폼으로 관리되지 않은 리소스인 경우
• 테라폼으로 생성하고 구성과 State가 삭제된 경우

테라폼으로 관리되지 않은 리소스를 테라폼으로 관리하는 방법은 추후에 다뤄보겠다.

 

 

유형6 : 수로 tfstate 파일 삭제 > plan/apply

실수로 tfsate 파일을 삭제한 상황을 가정하여 확인해보겠다.

# 실수로 tfstate 파일 삭제
**terraform state list**
*aws_iam_user.myiamuser1*

rm -rf terraform.tfstate*

#
**terraform plan**
aws iam list-users | jq
**terraform plan -refresh=false

#
terraform apply -auto-approve**
terraform state list
**cat terraform.tfstate | jq**

# iam 사용자 리스트 확인
aws iam list-users | jq

위 상황에서 복구? 하는 방법은? import 등 방법이 있다.

Import Terraform configuration | Terraform | HashiCorp Developer

# iam 사용자 리스트 확인
aws iam list-users | jq

# import 도움말 : 빨간색 설명 출력...
terraform import

# ADDR은 리소스주소 , ID는 
# terraform [global options] import [options] ADDR ID
**terraform import aws_iam_user.myiamuser1 mytest1**
*aws_iam_user.myiamuser1: Importing from ID "mytest1"...
aws_iam_user.myiamuser1: Import prepared!
  Prepared aws_iam_user for import
aws_iam_user.myiamuser1: Refreshing state... [id=mytest1]

**Import successful!**

The resources that were imported are shown above. These resources are now in
your Terraform state and will henceforth be managed by Terraform.*

#
terraform state list
cat terraform.tfstate | jq
terraform apply -auto-approve

 

 

3. 워크스페이스

State를 관리하는 논리적인 가상 공간을 워크스페이스라고 한다. 테라폼 구성 파일은 동일하지만 작업자는 서로 다른 State를 갖는 실제 대상을 프로비저닝할 수 있다.

워크스페이스는 기본적으로 default로 정의된다. 로컬 작업 환경의 워크스페이스 관리를 위한 CLI 명령으로 workspace가 있다.

사진-20

 

사용 중인 워크스페이스 확인을 위해 terraform workspace list 명령으로 확인해보면 기본 default 외 다른 워크스페이스는 없고 사용중인 워크스페이스임을 나타내기 위해 앞에 * 기호가 붙어 있다.

사진-21

 

실습을 위해 다음과 같이 tf파일을 작성 후 실행한다.

resource "aws_instance" "mysrv1" {
  ami           = "ami-0ea4d4b8dc1e46212"
  instance_type = "t2.micro"
  tags = {
    Name = "t101-study"
  }
}

사진-22

 

 

다음과 같이 신규 워크스페이스를 생성하고 확인한다.

사진-23

 

 

terraform plan 결과 리소스가 새로 생성되는 것을 확인할 수 있다.

사진-24

 

 

apply를 실행하니, 각 워크스페이스 별 작업 리소스가 분리되어 실행되었다는 것을 확인할 수 있다.

사진-25

사진-26

 

• 장점
  • 하나의 루트 모듈에서 다른 환경을 위한 리소스를 동일한 테라폼 구성으로 프로비저닝하고 관리
  • 기존 프로비저닝된 환경에 영향을 주지 않고 변경 사항 실험 가능
  • 깃의 브랜치 전략처럼 동일한 구성에서 서로 다른 리소스 결과 관리
• 단점
  • State가 동일한 저장소(로컬 또는 백엔드)에 저장되어 State 접근 권한 관리가 불가능
  • 모든 환경이 동일한 리소스를 요구하지 않을 수 있으므로 테라폼 구성에 분기 처리가 다수 발생 가능
  • 프로비저닝 대상에 대한 인증 요소를 완벽히 분리하기 어려움

 

스터디 추가

→ 가장 큰 단점은 완벽한 격리가 불가능

⇒ 해결하기 위해 루트 모듈을 별도로 구성하는 디렉터리 기반의 레이아웃을 사용할 수 있다 or Terraform Cloud 환경의 워크스페이스를 활용