Terraform Workspace

· Infra, Terraform, IaC

사실 테라폼 클라우드와 워크스페이스에 대해 알게 된지 시간이 좀 흘렀지만, 글로 남기는게 좋을 것 같아 뒤늦게 글을 씁니다.

테라폼에서 환경을 나누는 여러 방법들

테라폼에서 개발, 프로덕션 등의 환경을 분리하는데는 여러 방법이 있다.

  1. 아예 별도의 프로젝트로 운영하기: 제일 속 편한 방법일 수 있다. 하지만 각 환경들이 서로 관련성과 유사성이 높기 때문에 계속해서 코드의 중복이 발생할 수 밖에 없다. 따라서 이 방법은 대부분의 상황에서 좋은 방법이 아닐 것이다.

  2. 동일 프로젝트 내에서 디렉토리로 분리: 하나의 config 설정을 공유하며, 공통 모듈, 공통 리소스는 공통 디렉토리에서 관리하는 방법이다. 나 또한 이 방법과 비슷한 방법을 사용해 회사의 리소스들을 관리했었다. 워크스페이스의 존재를 모를 때에는 이 방법이 가장 좋은 방법일 것이라고 생각했었다.

  3. 테라폼 워크스페이스 활용하기: 테라폼 워크스페이스를 활용하면 각각의 환경을 별도의 tfstate로 만들 수 있고, 각 환경 별로 배포를 진행할 수 있다.

├── dev.tfvars
├── main.tf
├── prod.tfvars
├── terraform.tfstate.d
│   ├── dev
│   │   └── terraform.tfstate
│   └── prod
│       └── terraform.tfstate
└── variables.tf

Terraform Workspace는 더 나은 방법인가?

과거의 나는 Workspace의 존재를 몰랐다. 그래서 조건문, 반복문, 모듈 등을 활용해서 각 환경 별 변수 정보를 저장할 객체를 만들어서 각 환경 별로 적용하는 방식을 채택했다.
그 당시에는 이게 어떤 단점이 있는지 체감할 수 없었다. 일단 잘 동작했고, 나름대로 tf 파일 코드 레벨에서 변수로 환경 분리도 잘하고 있다고 생각했기 때문이다. 하지만 이 방식은 하나의 tfstate를 생성하게 되는데, 이는 환경 별로 tfstate를 각각 배포할 수 없음을 뜻한다. tfstate를 apply하게 되면 모든 환경에 배포 작업을 하게 된다.
반면 Workspace를 분리해 작업을 하게 되면, 각 Workspace마다 tfstate가 하나씩 생성된다. 즉 각 환경 별로 배포 작업을 수행할 수 있다는 의미다. 필요에 따라 하나의 환경만 배포할 수 있는 선택권이 생긴다는 것은 분명한 장점이고, 대부분의 회사에서는 Workspace를 분리하는 방식이 Best Practice에 가까운 방식인 것은 확실한 것 같다.

레퍼런스