[Terraform] Terraform Cloud Workflow (2) - CLI-driven Runs

개요

Terraform CLI를 사용해서 Terraform Cloud Workspace에 로컬 코드를 plan하거나 apply 할 수 있다. 이 방식은 Terraform CLI를 기존에 사용했다면 굉장히 쉽게 적용할 수 있는 workflow이며, 기존의 CI/CD 파이프라인이 존재하더라도 같이 사용할 수 있고 Sentinel 정책도 준수할 수 있다.

이 방식이 장점은 로컬의 있는 코드를 Terraform Cloud에서 실행할 수 있다는 점인데, Terraform Cloud의 환경(운영환경)을 그대로 사용해 테스트(plan만 사용) 할 수 있기 때문에 로컬 환경과 운영 환경 사이의 간극을 없애주는 역할을 하게 된다.

여기서 Terraform Cloud 직접 실행하는 명령어는 아래처럼 두 가지가 존재한다.

• terraform plan
• terraform apply

나머지 명령어는 원격에서 실행할 필요가 없는 명령어이기 때문에 저 두 가지만 Terraform Cloud에 영향을 주게 된다. 여기서 terraform plan을 사용하면 VCS 워크플로우와 좋은 시너지를 낼 수 있게 되는데, VCS만 사용할 경우 실제 환경에서 어떻게 반영되는지 확인하려면 해당 VCS 분기에 PR을 보내야했지만 CLI를 같이 사용하면 PR을 보내기 전에 로컬에서 확인이 가능하므로 VCS에 잘못된 코드가 올라갈 확률이 줄어든다.

만약에 VCS 워크플로우를 사용하고 있지 않다면 apply를 사용해 전통적인 워크플로우를 사용할 수 있다. apply는 로컬 코드를 Terraform Cloud에서 실행시켜버리기 때문에 VCS와 같이 사용할 수 없으며, VCS없이 Terraform을 협업하고 싶을 때 사용할 수 있는 방법이다. 

 

구성

로컬에서 자격증명 구성한다. login을 사용하지 않고 수동으로 인증파일을 구성해도 된다.

$ terraform login

terraform 구성에 cloud 블록 추가한다.

참고로 workspaces 인자로 name을 사용할 경우 하나의 workspace만을 지정하게 되고 tags를 사용하면 여러 workspace들을 지정 할 수 있게 된다. 여러 workspace들을 지정하면 plan이나 apply시 지정된 workspace에 동시 반영된다.

* cloud 블록은 Terraform 1.1.0 이상 버전에서만 지원된다.

terraform {
  cloud {
    organization = "vntg"
    workspaces {
      name = "sap-terraform-aws-test"
    }
  }
}

cloud 블록에 보면 인증을 위한 토큰을 입력할 수 있는 인자를 제공해주긴 하는데, 보안상에 문제가 발생할 여지가 크니 terraform login이나 수동으로 인증파일을 구성하는 것이 좋다.

그 다음 terraform init을 실행하면 세팅이 완료 된다.

$ terraform init

만약 cloud 블록 구성에 존재하지 않는 workspace를 지정 후 init을 하게 되면 자동으로 해당 이름의 workspace가 생성된다. name으로 직접 지정하면 바로 생성되고 tags 같은 것으로 지정하면 새로운 workspace명을 입력하라고 출력된다.

그리고 이렇게 workspace를 생성했다면 아래와 같은 사항을 유의해야 한다.

• 자동으로 생성되는 workspace는 기본적으로 변수들을 자동 생성하지 않는다. 그렇기 때문에 AWS 리소스를 생성하기 위한 액세스 키나 시크릿 키 같은 필수적인 변수들은 직접 UI로 접속해서 등록해주어야 한다. 참고로 workspace가 속한 조직 레벨에서 설정한 전역 변수는 따로 등록해주지 않아도 되며 *.auto.tfvars 파일이 있다면 이를 사용한다.
• 코드는 기본적으로 Terraform Cloud에서 실행된다.
• VCS에 자동으로 연결되지 않고 작업 디렉토리도 지정되지 않는다.
• Workspace의 Terraform 버전은 작업 공간이 생성되는 시점에서의 최신 Terraform 버전으로 설정된다.

Terraform Cloud에서 사용되는 변수

CLI를 사용해서 코드를 Terraform Cloud에서 plan하거나 apply 할 때는 다음과 같은 변수들을 사용한다.

• 로컬 머신의 Shell에서 TF_VAR 접두사가 붙은 환경 변수
• workspace에 설정된 변수들
• 조직 단위로 설정된 전역 변수
• *.auto.tfvars 구성에 포함된 모든 파일 Terraform 변수

작업 디렉토리

Terraform Cloud의 workspace에서 작업 디렉토리를 지정하면 로컬에서 실행(plan, apply)시 해당 작업 디렉토리 설정이 자동으로 반영된다. 자세한 내용은 아래 참고.

1. Terraform Cloud에서 작업 디렉토리로 workd라는 폴더 설정(작업 디렉토리는 루트 디렉토리에서 상대경로로 지정)
2. 로컬 머신의 루트 디렉토리에서 plan또는 apply (작업 디렉토리로 이동 x)
3. Terraform Cloud에서는 작업 디렉토리로 지정한 폴더(workd)의 Terraform 코드를 실행

파일 제외하기

Terraform 0.12.11 버전부터 .terraformignore를 지원하기 시작했다. 이 파일의 용도는 .gitignore와 같다. VCS를 사용해서 코드를 실행하면 VCS에서 파일을 걸러낸 후 실행하게 되니 별 문제가 없지만 CLI로 코드를 실행할 경우 로컬 구성을 Terraform Cloud로 다이렉트로 올려서 실행시키기 때문에 이와 같은 파일이 필요하다. 문법은 .gitignore와 같으며 다른 점은 .terraformignore의 경우 루트에 있는 .terraformignore 파일만 적용된다.

 

plan과 apply

코드 실행을 원격에서 한다는 점만 제외하면 로컬에서 작업하던 방식과 동일하다. 어떻게 적용되는지 확인하고 싶다면 plan, 코드를, 실행하고 싶다면 apply를 하면 된다.

• plan을 실행하려면 plan을 대기열에 넣을 수 있는 권한이 있어야 한다. 만약 대상 workspace가 여러개라면 권한이 있는 workspace에서만 plan이 실행된다.
• plan을 실행하면 Terraform Cloud UI에서 로그를 확인할 수 있도록 URL을 띄워준다. 하지만 꼭 링크로 접속하지 않아도 로컬 명령줄에도 똑같이 로그가 출력된다.
• apply를 실행하려면 workspace가 VCS에 연결되어 있지 않아야 하고 apply에 대한 권한이 있어야 한다.

Sentinel Policy

Sentinel이란 Terraform Enterprise에서 제공하는 기능으로 정책을 코드로 관리 할 수 있게 하는 기능이다. 예를 들어 AWS 인프라를 구성한다고 하면 아래와 같은 정책을 지정 할 수 있다.

• 리소스들에 필수 태그 적용
• 데이터 소스 소유자 제한
• EC2 인스턴스 가용 영역 제한
• EC2 인스턴스 유형 제한

예시로 몇 가지 적었는데 코드로 관리하기 때문에 훨씬 세부적인 정책 조정이 가능하다. 이런 정책은 단계도 지정 가능한데 정책 별로 3가지 단계 중 하나를 지정해 줄 수 있다.

• hard-mandatory → 엄격한 제한으로 이 정책을 통과하지 못하면 배포가 불가능하다.
• soft-mandatory → 정잭을 override 할 수 있는 권한을 가지고 있다면 이 정책을 통과하지 못하더라도 수동으로 통과 시킬 수 있다.
• advisory → 경고 표시로 실행에 영향을 미치지는 않는다.

이렇게 단계와 정책을 아래 처럼 연결 할 수 있다.

• 리소스들에 필수 태그 적용 → hard-mandatory
• 데이터 소스 소유자 제한 → hard-mandatory
• EC2 인스턴스 가용 영역 제한 → soft-mandatory
• EC2 인스턴스 유형 제한 → advisory

더 자세한 내용은 아래 두 문서 참고하면 된다.

• Sentinel 개요
• Policy as Code Wuth Terraform and Sentinel 영상 

Terraform CLI 에서는 위 기능을 그대로 이용할 수 있으며 정책 체크 결과도 명령줄에 표시된다. 만약 soft-mandatory처럼 override가 필요한 정책(통과 못했을 때)의 경우 명령줄에 override 할 것인지 여부를 묻는 메세지가 표시된다.

 

 

이렇게 CLI를 사용하는 workflow도 정리해 보았다. 다음에는 API 기반 workflow를 정리해보도록 하겠다.