[Terraform] 스터디 4주차. (2) State

Terraform 기초 실습 스터디를 진행하고 있으며, 커리큘럼 4주차에 해당하는 내용입니다.

* [테라폼으로 시작하는 IaC] 도서 참조

 

---

 

이전 포스팅에서 테라폼의 프로바이더에 대해 살펴보았다.

이번 포스팅에서는 책 내용의 CHAPTER 5. State 에 대해 알아보도록 하겠다.

 

 

 

---

테라폼은 Stateful (상태가 있는) 애플리케이션이다.

프로비저닝 결과에 따른 State (상태) 를 저장하고 프로비저닝한 모든 내용을 저장된 상태로 추적한다.

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

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

 

 

State 의 목적과 의미

테라폼은 State 를 사용해 대상 환경에서 어떤 리소스가 테라폼으로 관리되는 리소스인지 판별하고 결과를 기록한다.

State 의 역할은 다음과 같다.

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

위의 테라폼 코드를 apply 하여 생성되는 terraform.tfstate 를 확인해보자.

 

{
  "version": 4,
  "terraform_version": "1.9.5",
  "serial": 3,
  "lineage": "64aedf01-9085-ddfe-825b-e02fd08135f7",
  "outputs": {},
  "resources": [
    {
      "mode": "managed",
      "type": "random_password",
      "name": "password",
      "provider": "provider[\"registry.terraform.io/hashicorp/random\"]",
      "instances": [
        {
          "schema_version": 3,
          "attributes": {
            "bcrypt_hash": "$2a$10$JK92WdCvP7Ey8Hr4klpAO.wklhOPbmsKe5pBypW6Sv3b1Yd.Uw3I6",
            "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": "BZi0ZviKp0NoGd7W",
            "special": true,
            "upper": true
          },
          "sensitive_attributes": [
            [
              {
                "type": "get_attr",
                "value": "result"
              }
            ],
            [
              {
                "type": "get_attr",
                "value": "bcrypt_hash"
              }
            ]
          ]
        }
      ]
    }
  ],
  "check_results": null
}

 

테라폼은 이와 같이 JSON 형태로 작성된 State 를 통해 type 과 name 으로 고유한 리소스를 분류하며, 해당 리소스의 속성과 인수를 실제 리소스와 비교해 생성, 수정, 삭제한다.

 

 

State 동기화

테라폼 구성 파일은 기존 State 와 구성을 비교해 실행 계획(plan) 에서 생성, 수정, 삭제 여부를 결정한다.

다음은 plan 과 apply 동작 중 각 리소스에 발생할 수 있는 다섯가지 유형이다.(replace 동작은 기본값을 삭제 -> 생성하지만, lifecycle 의 create_before_destroy 옵션을 통해 생성 -> 삭제 순으로 동작하도록 설정 가능)

 

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

 

 

워크스페이스

State 를 관리하는 논리적인 가상 공간을 워크스페이스 라고 한다.

테라폼 구성 파일은 동일하지만 작업자는 서로 다른 State 를 갖는 실제 대상을 프로비저닝 할 수 있다.

워크스페이스는 기본 default 로 정의된다.

 

 

동일한 테라폼 구성 파일로 다중 워크스페이스를 구성하여 실제 대상 인프라에 적용할 수 있다.

예를 들어 실제 업무 환경에서 DEV/STG/PRD 환경으로 업무 환경을 분리하여 프로비저닝할 때 사용할 수 있다.

 

 

아래 명령어로 새로운 워크스페이스를 생성하여 관리한다.

$ terraform workspace new <워크스페이스이름>

 

 

워크스페이스 이름을 조건으로 하여 동일한 코드 구성으로 다른 조건의 리소스를 생성하는 예시이다.

resource "aws_instance" "web" {
    count = "${terraform.workspace == "default" ? 5:1}"
    ami = "ami-8dfha8er23y78yha"
    instance_type = "t3.micro"

    tags = {
        Name = "HelloWorld - ${terraform.workspace}"
    }
}

 

 

이와 같이 다수의 워크스페이스를 사용하면 장단점이 존재하기 마련이다.

단점에 관한 부분을 실제 운영 업무를 수행중인 프로젝트에서 어떤 식으로 보완하여 구축되어있는지, 따로 정리하여 포스팅하려고 한다.

 

 

 

 

다음 포스팅에서는 모듈에 관해 알아보도록 하자.