✅ State를 관리하는 논리적인 가상공간을 워크스페이스라 한다. (쿠버네티스의 네임스페이스와 유사함)
✅ 테라폼 구성 파일은 동일하지만 작업자는 서로 다른 경우 State를 갖는 실제 대상을 프로비저닝 할수 있다.
✅ 기본은 default로 정의 되며, 로컬 작업 환경에서 작업할 경우 기본 default 워크스페이스를 사용한다.
terraform workspace list
* default
2. 테라폼 워크스페이스 실습
✅ 간단하게 가상머신 1개를 배포 해본다.
✅ 워크스페이스를 바꿔가면서 동일한 tf 파일을 활용해 가상머신을 3개까지 배포해보며 ec2 describe-instance를 통해 확인해본다.
resource "aws_instance" "mysrv1" {
ami = "ami-0ea4d4b8dc1e46212"
instance_type = "t2.micro"
tags = {
Name = "t101-week4"
}
}
✅ 분할 터미널을 통해 ec2의 퍼블릭 IP를 조회
# [분할/터미널1] 모니터링
export AWS_PAGER=""
while true; do aws ec2 describe-instances --query "Reservations[*].Instances[*].{PublicIPAdd:PublicIpAddress,InstanceName:Tags[?Key=='Name']|[0].Value,Status:State.Name}" --filters Name=instance-state-name,Values=running --output text ; echo "------------------------------" ; sleep 1; done
#
terraform init && terraform apply -auto-approve
terraform state list
#
cat terraform.tfstate | jq -r '.resources[0].instances[0].attributes.public_ip'
cat terraform.tfstate | jq -r '.resources[0].instances[0].attributes.private_ip'
# terraform.tfstate에 private 담긴 내용은?
cat terraform.tfstate | jq -r '.resources[0].instances[0].private' | base64 -d | jq
# 워크스페이스 확인
terraform workspace list
# graph 확인
terraform graph > graph.dot
✅ 배포 완료 되면 퍼블릭 ip 조회 (3.39.237.57)
✅ 워크스페이스를 생성하고 동일한 tf 파일을 통해 apply
# 새 작업공간 workspace 생성 (mywork1)
terraform workspace new mywork1
terraform workspace show
##### 현재 위치한 워크스페이스 확인
# plan 시 어떤 결과 내용이 출력되나요?
terraform plan
# apply 해보자!
terraform apply -auto-approve
# 워크스페이스 확인
terraform workspace list
# tfstate파일 확인
cat terraform.tfstate | jq -r '.resources[0].instances[0].attributes.public_ip'
cat terraform.tfstate.d/mywork1/terraform.tfstate | jq -r '.resources[0].instances[0].attributes.public_ip'
✅ 워크스페이스를 생성한 뒤 동일한 리소스를 반복해서 만들수 있음을 확인
✅ 워크스페이스를 생성한 뒤 동일한 리소스를 반복해서 만들수 있음을 확인
✅ 확인 후 삭제
# 새 작업 공간 workspace 생성 : mywork1
terraform workspace new mywork1
terraform workspace show
# 서브 디렉터리 확인
tree terraform.tfstate.d
terraform.tfstate.d
└── mywork1
# plan 시 어떤 결과 내용이 출력되나요?
terraform plan
# apply 해보자!
terraform apply -auto-approve
# 워크스페이스 확인
terraform workspace list
#
cat terraform.tfstate | jq -r '.resources[0].instances[0].attributes.public_ip'
cat terraform.tfstate.d/mywork1/terraform.tfstate | jq -r '.resources[0].instances[0].attributes.public_ip'
# graph 확인
terraform graph > graph.dot
# 새 작업 공간 workspace 생성 : mywork2
terraform workspace new mywork2
# 서브 디렉터리 확인
tree terraform.tfstate.d
...
# plan & apply
terraform plan && terraform apply -auto-approve
cat terraform.tfstate | jq -r '.resources[0].instances[0].attributes.public_ip'
cat terraform.tfstate.d/mywork1/terraform.tfstate | jq -r '.resources[0].instances[0].attributes.public_ip'
cat terraform.tfstate.d/mywork2/terraform.tfstate | jq -r '.resources[0].instances[0].attributes.public_ip'
# workspace 정보 확인
terraform workspace show
terraform workspace list
# 실습 리소스 삭제
terraform workspace select default
terraform destroy -auto-approve
terraform workspace select mywork1
terraform destroy -auto-approve
terraform workspace select mywork2
terraform destroy -auto-approve
3. 정리
✅ 장점
하나의 루트 모듈에서 다른 환경을 위한 리소스를 반복적으로 프로비저닝 하고 관리할수 있음
기존 프로비저닝 된 환경에 영향을 주지 않고 변경 사항 실험 가능
깃의 브런치 전략 처럼 동일한 구성에서 서로 다른 리소스 결과 관리
❌ 단점
State가 동일한 저장소( 로컬 또는 백엔드)에 저장 되어 State 접근 권한 관리가 불가능
모든 환경이 동일한 리소스를 요구 하지 않을수 있으므로 테라폼 구성에 분기 처리가 다수 발생 가능
프로비저닝 대상에 대한 인증요소를 완벽히 분리하기 어려움
❌ 가장 큰 단점은 완벽한 격리가 불가능
해결하기 위해서 루트 모듈을 별도로 구성하는 디렉터리 기반의 레이아웃을 사용
테라폼 Cloud, Enterprise 버전 사용자는 해당 환경의 워크스페이스를 활용하면 된다.
