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}"
}
}
이와 같이 다수의 워크스페이스를 사용하면 장단점이 존재하기 마련이다.
단점에 관한 부분을 실제 운영 업무를 수행중인 프로젝트에서 어떤 식으로 보완하여 구축되어있는지, 따로 정리하여 포스팅하려고 한다.
다음 포스팅에서는 모듈에 관해 알아보도록 하자.
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}"
}
}
이와 같이 다수의 워크스페이스를 사용하면 장단점이 존재하기 마련이다.
단점에 관한 부분을 실제 운영 업무를 수행중인 프로젝트에서 어떤 식으로 보완하여 구축되어있는지, 따로 정리하여 포스팅하려고 한다.
다음 포스팅에서는 모듈에 관해 알아보도록 하자.
