Terraform cloud workspace 관리

Terraform Workspace에 대한 내용 중 읽고 넘어가면 좋을 부분들 정리

 

Terraform을 로컬머신에서 실행할 경우 Terraform은 인프라 관련 구성들을 로컬에서 관리하게 된다. 하지만 Terraform Cloud를 사용하면 Workspace에서 모든 인프라 관련 구성들을 관리하게 된다.

Terraform Cloud의 Workspace를 사용하느냐 Terraform 로컬 디렉토리를 사용하느냐에 따라서 데이터 관리 방식이 달라지는데 그 차이는 아래와 같다.

 

요소	Local Terraform	Terraform Cloud
테라폼 구성	로컬 디스크	VCS 또는 API/CLi를 통해 주기적 업로드
변수 값	.tfvars 파일, CLI 인수, Shell 환경	Workspace > Variavles 탭
상태	로컬 디스크 또는 Remote Backend	Workspace > States 탭
자격 증명 및 Secret	Shell 또는 Prompt	Workspace > Variables 탭

Terraform의 경우 상태 파일(.tfstate 파일) 백업 유지를 위해 backend 구성으로 원격 스토리지를 지정해야 하지만 Terraform Cloud를 사용하면 Terraform Cloud에서 상태 파일을 관리해주기 때문에 별도로 backend 구성을 할 필요가 없다.

Workspace 구성

Terraform Cloud에서는 Monolithic 구성 보다는 더 작은 구성요소로 나눌 것을 권장하고 있다. 예를 들어 프로덕션 환경의 인프라를 관리하는 코드를 작성한다고 하면,

• networking-prod
• app1-prod
• monitoring-prod

위와 같이 Workspace를 생성하고 각 Workspace 별로 별도의 관리팀을 할당 할 수 있다.

Workspace 생성

Workspace는 Terraform Cloud UI, API, CLI를 사용해서 생성할 수 있다.

API 사용

https://www.terraform.io/cloud-docs/api-docs/workspaces#create-a-workspace

위 API를 사용하면 만들 수 있다. 중요한 점은 Workspace 관리 권한이 있는 팀이나 조직의 Token을 사용해야 한다는 것이다.

UI 사용

팀에 Workspace 관리 권한이 있다면 생성 가능하며, 생성 방법은 아래 절차르 따르면 된다.

1. Workspace 목록으로 이동해서 우측 상단의 New Workspace 클릭
2. 첫 화면에서 workflow를 선택 할 수 있음.
   1. Version control workflow는 Github같은 VCS를 연결해서 관리
   2. CLI-driven workflow는 로컬 머신에서 CLI를 사용해 관리 (plan, apply만 원격으로 실행)
   3. API-driven workflow는 API를 사용해서 관리
3. VCS를 선택했다면 VCS 선택 → Repository 선택 (CLI, API 선택 시 건너뜀)
4. Workspace 이름 지정
   1. Workspace 이름은 조직 내에서 고유해야함.
   2. 문자, 숫자, 대시(-), 밑줄(_) 포함 가능.
   3. Terraform에서 추천하는 네이밍 룰 - https://www.terraform.io/cloud-docs/workspaces/naming

첫 화면에서 어떤 workflow를 선택하더라도 나중에 Workspace 설정에서 전부 변경 가능하다. 또한 Version control workflow와 CLI-driven workflow는 같이 사용 가능하며, VCS 연결 후 로컬 머신에서 Cloud Block를 구성해주기만 하면 된다.

VCS 설정 했을 경우 수동으로 한 번 이상 apply 해주어야 VCS 웹훅 트리거가 된다.

Workspace 네이밍

Workspace의 이름은 90자 이하여야 하고 문자, 숫자, 하이픈(-), 언더바(_)만 포함시킬 수 있다. Terraform에서 추천하는 네이밍 방식은 <COMPONENT>-<ENVIRONMENT>-<REGION> 이다.

COMPONENT : networking, monitoring, app 등

ENVIRONMENT : dev, staging, prod 등

REGION : us-east, ap-northeast-2 등

위 규칙을 따르면 아래처럼 Workspace를 생성하게 된다.

• networking-prod-ap-northeast-2
• monitoring-prod-us-east

Terraform 구성

Terraform Cloud에서 코드를 실행(apply) 시키려면 Terraform Cloud가 새 구성 버전을 수신 받아야한다. 새 구성 버전을 전달하는 방법은 3가지가 존재하며 각 방법은 아래와 같다.

• Workspace와 VCS를 연결하여 VCS에 Commit 발생 시 웹훅으로 새 구성 버전 전달
• CLI로 로컬 머신에서 바로 새 구성 버전 전달
• API로 Workspace에 구성 버전 생성 후 해당 버전에 대한 소스코드 업로드

대부분 VCS는 Terraform과 쉽게 연동 할 수 있지만, 연동이 되지 않는 VCS나 다른 솔루션들을 사용하고 있다면 Terraform Cloud API를 사용해 Workspace와 통합 시킬 수 있다.

대부분의 조직은 Terraform을 Module화 해서 관리할 때 모듈 별로 Repository를 나눠서 관리하거나 한 Repository안에 모듈 별로 디렉터리를 나눠서 관리한다. 만약 단일 Repository를 사용할 경우 아래와 같이 구성하는 것을 권장한다.

• 각 모듈별로 Workspace를 생성 (Repository와 Workspace는 1:n)
• Workpsace마다 작업 디렉터리 설정 (작업 디렉터리로 각 모듈 디렉터리를 지정)

단일 Repository로 관리 할 경우 공유 모듈을 업데이트 시 해당 모듈을 사용하는 다른 모든 모듈을 같이 업데이트해야해서 느리다는 단점이 있다. 그래서 Terraform에서는 모듈별로 Repository를 나누고 각 모듈을 개인 모듈 레지스트리로 가져다 쓸 것을 권장하고 있다.

환경 구성

환경을 분리하기 위한 일반적인 접근 방식은 다음과 같다.

• 단일 Branch를 사용하고 변수로 환경을 분리
• 환경 별로 Branch를 나눠서 관리
• 각 환경 별로 공통적인 부분은 모듈로 관리. 그러면 남은 부분은 전부 다른 구성이기 때문에 환경 별로 별도의 Repository를 사용하면 됨.

구성 버전 보관

Terraform Cloud는 apply가 완료되면 공간 절약을 위해 업로드 된 Terraform 구성 파일을 삭제 할 수 있다. 이때 VCS를 연결해서 apply 했었다면 구성 파일을 삭제하더라도 언제든지 파일을 다시 가져올 수 있기 때문에 구성 버전은 자동으로 보관한다. 하지만 CLI나 API를 사용한 경우 구성 파일을 삭제해버리면 구성 버전을 보관하더라도 파일을 다시 가져올 수가 없어 구성 버전을 자동으로 보관하지 않는다. 하지만 API를 사용해서 구성 버전을 수동으로 보관 할 수 있다.

변수

Workspace의 변수를 사용해 변수 값을 지정해 줄 수 있다. 변수는 환경 변수와 Terraform 변수 중 선택해서 설정 할 수 있다. 또한 변수 세트 같은 것을 사용하면 모든 Workspace에 변수를 자동으로 적용 할 수 있다.

환경 변수

Terraform Cloud는 Linux기반의 일회용 VM에서 코드를 실행시킨다. 이때 변수로 환경 변수를 설정했다면, Terraform code 실행 전에 해당 환경 변수를 export 명령어를 사용해 전부 설정 한다. Terraform에서 지원되는 환경 변수들은 정해져 있으며 주로 사용되는 것들은 아래 문서를 참고하면 된다.

• https://www.terraform.io/cli/config/environment-variables
• AWS - https://registry.terraform.io/providers/hashicorp/aws/latest/docs
• GCP - https://registry.terraform.io/providers/hashicorp/google/latest/docs/guides/getting_started#adding-credentials
• Azure - https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs#argument-reference

Terraform은 코드를 실행 할 때 내부적으로 그래프를 빌드하는 방식을 사용한다. 이때 그래프에 대한 작업을 병렬로 처리하게 되는데, 각 그래프의 노드를 처리할 때 동시에 몇 개를 처리할 것인지에 대한 옵션으로 -parallelism 옵션을 지정 할 수 있다. 이 옵션은 기본 값이 10이며 1~256사이의 값을 지정해 줄 수 있다. 이것을 환경 변수로 지정하려면 TFE_PARALLELISM 환경변수를 지정해주면 된다.

TFE_PARALLELISM 환경 변수는 일반적으로 설정하는 변수는 아니며 꼭 설정해야 한다면 Hashicorp 지원팀에 먼저 문의 할 것을 권장한다.

Terraform 변수

Terraform 변수는 Terraform 구성에서 variables.tf에 구성되는 변수(input 변수)들을 말하며, 다음과 같은 범위를 가질 수 있다.

 

범위	설명	사용법
특정 실행	실행 시 한번만 적용되는 일회성 변수	• CLI로 -var 또는 -var-file 지정 • 접두사가 TF_VAR_인 로컬 환경 변수 생성 후 CLI 실행
작업 공간별	단일 Workspace에서 유지되는 변수	• Workspace에서 변수 생성 • .auto.tfvars 파일에서 변수 로드 • API를 사용해서 변수 생성
변수 집합	같은 조직 내에서 지정한 Workspace에 유지되는 변수	• 변수 세트 생성 • API를 사용해서 변수 세트 생성
글로벌 변수 세트	같은 조직 내에서 모든 Workspace에 유지되는 변수	• 변수 세트 생성 • API를 사용해서 변수 세트 생성

또한 이 변수들은 우선순위가 있기 때문에 변수명이 겹치더라도 높은 우선순위를 가진 변수가 낮은 변수를 덮어 쓴다. 우선순위는 아래와 같다.

1. 커맨드 라인의 변수 인자
2. 로컬 환경 변수
3. Workspace의 변수
4. 변수 집합 (non-global)
5. 변수 집합 (global)
6. auto.tfvars 변수 파일

우선순위 적용에 대한 예시는 이 문서를 확인 하면 된다.

변수 관리

변수를 관리하는 방법에는 3가지 방법이 있다.

• Terraform Cloud의 UI로 관리
• Terraform Cloud의 API로 관리
• tfe provider의 tfe_variable 리소스로 관리

어떤 방법으로 관리 하든 변수를 읽고 편집하려면 해당 **Workspace에 대한 읽기 및 쓰기 권한이 필요**하고, 변수 세트의 경우 Workspace 관리 권한이 필요하다.

UI로 변수를 관리 하려면 아래 내용을 참고

 

변수 종류	절차
변수 세트	1. Workspace 목록 화면 이동 2. Settings 이동 3. Variable sets 이동
Workspace 변수	1. Workspace 목록 화면 이동 2. 원하는 Workspace 이동 3. Variables 탭 이동

API로 변수를 관리 하려면 아래 내용을 참고

변수 종류	Reference
변수 세트	https://www.terraform.io/cloud-docs/api-docs/variable-sets
Workspace 변수	https://www.terraform.io/cloud-docs/api-docs/workspace-variables

tfe provider의 tfe_variable로 변수를 관리하려면 이 문서 참고

보안

Terraform Cloud는 모든 변수를 Vault를 사용해 암호화 하기 때문에 승인된 당사자가 아니라면 값을 읽을 수 없다. 하지만 Terraform 변수와 환경 변수는 잘 분리해서 지정해야 하는데 왜냐하면 Terraform 변수의 경우 Terraform 실행 시 Sensitive 변수를 포함한 모든 변수를 수신하기 때문이다. 때문에 자격증명 같은 경우는 Terraform 변수가 아닌 환경변수로 등록을 하는 것이 좋다.

Sensitive

변수 지정 시 Sensitive 설정을 할 수 있는데 이것을 설정하면 해당 변수는 쓰기 전용이 되어 UI나 API로 내용을 확인 할 수 없게 된다. 주로 자격증명 같은 변수를 Sensitive로 설정한다.

Workspace 설정

Workspace 생성 후 Settings로 이동하면 다양한 설정들을 확인하고 지정 할 수 있다.

• General - 기본 설정
• Locking - 새로운 계획 생성 방지
• Notifications - 실행 알림 구성
• Run Triggers - 실행 트리거 구성
• SSH Key - Git 기반 모듈 소스 사용 구성
• Version Control - VCS 통합 관리
• Team Access - Workspace 권한 관리
• Destruction and Deletion - Workspace 및 인프라 제거

Execution Mode

기본 값은 Remote이며, 이 경우 코드의 실행을 Terraform Cloud가 하게되고 Sentinel, 비용, 알림, 버전 제어, 리뷰 등의 기능을 사용 할 수 있다. 만약 Execute Mode를 Local로 설정하게 되면 코드 실행은 로컬 머신에서 진행되며 Terraform Cloud에서는 상태만 저장하게 된다.

Terraform Cloud 문서에는 Execution Mode를 Local로 설정 할 경우 CLI-Driven Runs Workflow를 사용하게 된다고 설명되어 있다. 여기서 헷갈릴 수 있는게 Terraform Cloud의 CLI-Driven Runs Workflow의 문서는 원격 실행을 기준으로 작성되어 있기 때문에 Local로 설정하더라도 코드는 원격으로 실행된다고 생각 할 수 있다. 하지만 Execution Mode의 설정은 코드를 원격에서 실행하느냐, 로컬에서 실행하느냐의 차이일 뿐이라는 것이다.

Working Directory

Terraform이 실행될 디렉토리로 기본값은 루트 디렉토리이며, 루트 기준으로 상대경로를 지정하게 된다. Terraform Cloud는 설정한 Working Directory로 이동 후 Terraform 코드를 실행시키기 때문에 설정한 디렉토리가 존재하지 않으면 에러가 발생한다.

Working Directory는 설정된 Directory 내의 변경사항만 트리거 하게 되는데, 만약에 Working Directory로 module/elb를 설정했다면 module/의 변경사항은 무시하게 된다. 지정한 Working Directory외의 변경사항을 트리거 하려면 Run Triggers를 설정하면 되는데 이 기능은 한 Workspace의 apply를 트리거하여 실행시키는 설정이다. 이는 공통 모듈 개발 시 주로 사용된다.

Working Directory를 설정 할 경우 아래와 같은 규칙을 가지고 코드를 업로드한다. 이 규칙은 CLI-Driven Runs Workflow에만 해당되는 내용이며 VCS의 경우 자동으로 처리된다.

• 로컬에서 plan 및 apply 시 현재 디렉터리 위치가 Working Directory와 일치하지 않으면 Terraform은 현재 디렉토리를 루트 디렉토리로 인식하고 현재 디렉토리 전체를 업로드 한다.
• 만약 로컬에서 plan 및 apply 시 현재 디렉터리 위치가 Working Directory와 일치하면 현재 위치에서 상위 디렉터리를 같이 업로드한다. 만약에 module/elb가 Working Directory이고 elb에서 plan 및 apply를 실행했다면 업로드되는 코드는 module/ 전체가 된다.

Working Directory외에 다른 폴더까지 업로드 되는 이유는 Terraform 코드가 Working Directory 외부의 로컬 모듈을 사용하고 있을 수도 있기 때문이다.

Remote state sharing

Workspace의 output 값을 조직 내에 전체 공유하거나 특정 Workspace를 선택해 공유 할 수 있다.

Locking

Terraform 코드의 실행을 막기 위해 Workspace를 잠글 수 있다. 이렇게 하면 수동 실행, 자동 트리거, API 실행 등 모든 유형의 실행을 막을 수 있다. 만약 다시 실행을 허용하고 싶다면 잠금을 풀면된다.

기본적으로 다른 사람이 잠근 Workspace를 같은 권한이 있다고 해서 마음대로 풀 수 없다. 다른 사람이 잠근 Workspace를 풀기 위해서는 해당 Workspace에 대한 관리자 액세스 권한이 필요하다.

Terraform Cloud API로 Workspace 구성

Terraform Workspace를 API로 구성하고 싶다면 아래 API 문서를 참고하면 된다.

• https://www.terraform.io/cloud-docs/api-docs/workspaces#workspaces-api

tfe provider로 Workspace 구성

tfe provider를 사용한다면 Workspace를 UI로 구성하지 않고 코드로 관리 할 수 있게 된다. 사용 방법은 아래 문서를 참고하면 된다.

• https://registry.terraform.io/providers/hashicorp/tfe/latest/docs/resources/workspace