작년 HashiConf에서 원격 상태 관리를 무료로 제공하겠다고 발표한 뒤 지난달 Terraform Cloud Remote State Management가 공개되었다.

Terraform Cloud를 보면 현재 Terraform의 상태관리 기능을 지원하고 Plan/Apply도 지원할 예정이라고 나오고 있다. 원래 Terraform Enterprise가 기업용 솔루션이고 이런 기능도 모두 Terraform Enterprise에서 제공하던 기능이었는데 이 기능이 무료 사용자에게도 열린 것이다. 사이트를 보면 Terraform Enterprise와 Terraform Cloud가 혼용돼서 사용되는 느낌이 있다.

Terraform을 사용하면 상태를 관리하는 .tfstate 파일이 협업할 때 중요한데 이를 같이 사용할 수 있도록 S3 등에 원격으로 올려서 사용하는 것이 일반적이다. 이 기능을 Terraform 자체에서 무료로 제공한다고 보면 된다.

회원 가입

회원 가입을 하면 다른 팀에 합류하거나(관리자가 등록을 해주어야 한다) 새로운 조직을 만들어서 사용해야 한다.

처음에는 조직이 아예 없으므로 개인용 조직을 만들어서 사용하면 된다.

이제 만들어진 워크스페이스에 진입하는데 아래처럼 처음에는 아무것도 나타나지 않는다.

실제로 이 화면에서는 아무것도 할 수가 없다. 아직 웹서비스의 편의성은 부족한 부분이 보이는데 조직에 이메일로 새로운 사용자를 초대할 수 없다거나(팀원이 가입한 뒤 아이디를 알려주어야 한다) 처음 가입 시 기본 개인용 조직이 생기지 않다거나 여기서처럼 웹에서는 새로운 워크스페이스를 생성하는 기능 등이 없다.

환경 설정

이 워크스페이스를 이용하려면 Terraform v0.11.13 이상과 API를 사용하기 위한 엑세스 토큰이 필요하다. Terraform의 최신 버전이 0.12이고 0.11.x 에서는 크게 호환성 문제는 없으므로 사용하는 데 큰 문제는 없어 보이고 엑세스 토큰은 Settings > API Tokens에서 아래와 같이 생성할 수 있다.

이 토큰은 ~/.terraformrc 파일에 다음과 같이 설정하면 된다.

credentials "app.terraform.io" {
    token = "YOUR_ACCESS_TOKEN"
}

이제 Terraform 파일에서 S3가 아닌 테라폼 클라우드로 설정을 하면 된다.

terraform {
  backend "remote" {
    organization = "outsider"
    workspaces {
      name = "state-test"
    }
  }
}

여기서 organization는 앞에서 생성한 조직명을 넣어야 하고 workspaces.name은 이제 사용할 이름을 지정하면 된다. 뒤에서 보겠지만 여기서 지정하는 이름별로 워크스페이스가 생긴다. 즉, 이 이름별로 .tfstate를 관리하는 것이다. 그래서 이름 지정이 중요하긴 한데 약간 썼을 때는 작명 규칙은 불편하게 느껴졌다. 워크스페이스 이름이 URL 경로가 되기 때문에 URL 중간 경로로 사용할 수 있는 문자가 가능한 거로 보인다. 그래서 /등을 사용할 수 없다.

그래도 아래 S3보다 더 설정이 더 간단한 것을 알 수 있다.

terraform {
  backend "s3" {
    bucket     = "terraform.state"
    key        = "ec2/terraform.tfstate"
    region     = "ap-northeast-1"
    encrypt    = true
    lock_table = "TerraformStateLock"
    acl        = "bucket-owner-full-control"
  }
}

이제 terraform init을 하면 초기화되면서 원격 백엔드를 설정하는 것을 볼 수 있다.

$ terraform init

Initializing the backend...

Successfully configured the backend "remote"! Terraform will automatically
use this backend unless the backend configuration changes.

Initializing provider plugins...
- Checking for available provider plugins...
- Downloading plugin for provider "aws" (terraform-providers/aws) 2.16.0...

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

Terraform Enterprise에 접속하면 지정한 워크스페이스가 새로 생성된 것을 볼 수가 있다.

설정이 끝났으니 평소처럼 terraform plan/terraform apply를 사용하면 된다.

장점

실제로 좀 사용해 보니 S3를 쓸 때에 비해 장점이 좀 있다.

설정이 간단하다. HCL 코드 자체도 간단하지만 처음 Terraform을 설정할 때 나 같은 경우 S3 버킷을 생성하고(버저닝이나 Lock 설정을 포함해서) .tfstate 파일을 S3 버킷에 업로드하면서 사용하는데 이런 번거로운 작업 없이 원격 백엔드 지정만 하면 바로 사용할 수 있다.

변경사항을 쉽게 볼 수 있다. 실제로 작업을 하면서 .tfstate의 변경사항을 살펴보는 경우는 많지 않기는 하지만 Terraform의 특성상 코드가 master 브랜치에 들어오기 전에 인프라는 이미 적용되어 .tfstate는 변경되는 경우가 많다. Pull Request라도 올라와 있으면 좀 낫지만, 실수로라도 수정한 테라폼 코드를 공유하지 않았는데 변경사항이 생겼다면 누가 언제 변경했는지 봐야 하는 경우가 있는데 S3에서는 이게 정말 힘든데 Terraform Enterprise에서는 아주 쉽게 볼 수 있다.

그리고 보통 Terraform으로 관리하는 인프라와 아닌 인프라가 섞여 있는 경우가 많으므로 코드는 변경하지 않았지만, plan에서 변경사항이 생겼을 때 상태 파일에 누가 변경을 가한 것인지 AWS 콘솔에서 바꾸었는지 찾아볼 때도 편할 것으로 보인다. .tfstate가 Git 커밋 같은 것은 아니라서 상태 메시지는 위처럼 알 수 없게 나타나지만, 최소한 누가 언제 변경했는지는 알 수 있다.

각 변경사항을 눌러서 들어가면 상태 파일의 변경내역도 쉽게 확인할 수 있다.(.tfstate 파일은 보기에 좀 더 복잡하긴 하지만...)

사소하지만 다른 사람이 락을 건 경우에는 웹에서 확인할 수도 있다. 화면에 "Local execution"은 최종 실행이 어디서 되었는지 나오는 것 같은데 원래 Terraform Enterprise가 서비스 내에서도 apply를 할 수 있어서 나오는 것 같다. 무료로 쓸 때는 아직 그 기능이 없어서 항상 "Local execution"이라고 나온다. 웹 인터페이스에서 Lock을 걸 수도 있는데 언제 써야 할지는 잘 모르겠다.

TFE(Terraform Enterprise)에 장애가 생겼을 때가 걱정되지만 S3보다는 편해서 일단 HashiCorp를 믿고 TFE를 위주로 써보려고 한다. 조만간 plan/apply 기능도 제공한다고 하니 기대 중이다.