You are currently viewing Terraform cloud 소개, 기본 설정, 사용 방법

Terraform cloud 소개, 기본 설정, 사용 방법

TL;DR

  1. 테라폼 클라우드> Hashicorp에서 공식적으로 지원하는, 팀단위 테라폼 협업 지원 어플리케이션(웹 콘솔?)
  2. 테라폼 클라우드의 특징 및 기능, 설정 과정 소개
  3. Web UI를 통한 기본 사용 방법

1. Intro & Overview

신규 팀원으로 DevOps 팀에 합류하면서, ‘어떻게 테라폼을 팀 수준에서 잘 쓸 수 있을까?’라는 고민을 하게 되었다. AWS의 인프라를 프로비저닝하고 관리하는데 있어서, 기존에는 Github를 사용한 버전 관리와, AWS S3 버킷에 state 파일을 올려 원격으로 관리하는 Remote State 기능 정도가 활용되고 있었다.

Version control과 Remote state 외에도, 협업을 위해 추가할 수 있는 기능들을 찾아보면 DynamoDB를 사용한 State Lock, Code Review등과 같은 절차들이 권장된다. 그 외에 고려할 도구 / 기능은 없는걸까? 하고 찾아보던 도중 Terraform Cloud(이하 테클)을 발견하였다.

테클은 테라폼의 개발사인 Hashicorp가 제공하는 관리형 서비스 어플리케이션이다. 기존의 Remote state / State Lock 등의 기능 또한 제공하며, 그 외에도 Health check, Cost estimation 같은 추가적인 기능들 또한 제공한다.(but 유료)

이번 글에서는 테클에 대한 소개와 기본 설정, 그리고 Web UI에서의 사용 방법을 정리해보고자 한다.

2. What is the Terraform?

주된 이야기는 테클이긴 하지만, 그래도 테라폼을 언급 안하고 넘어갈 수는 없다.

정의

테라폼(Terraform)은 HashiCorp가 개발한 오픈 소스 코드형 인프라스트럭처이다. 사용자는 HCL(HashiCorp Configuration Language)이라는 선언형 구성 언어나 선택적으로 JSON을 사용하여 데이터 센터 인프라스트럭처를 정의하고 제공한다.

Wikipedia, 테라폼(소프트웨어)

테라폼은 IaC(Infrastructure as Code) 도구이다. Hashicorp가 제작한 오픈소스 도구이고, HCL(Hashicorp Configuration Language) 문법을 사용해서 생성 / 구성 / 제거가 필요한 Infrastructure 리소스를 코드 기반으로 관리할 수 있도록 지원한다. 코드 기반으로 작동하기 때문에, AWS, Azure, Google Cloud, nCloud 같은 퍼블릭 클라우드 뿐만 아니라 IDC와 같은 온프렘의 리소스 또한 관리할 수 있다. (물론 Provider 별 코드 구성 내용간 차이는 다소 존재한다.)

2.1. 기존의 어떤 문제를 해결하는가?

새로운 도구 / 기술 / 방법론에 대한 도입을 고민할 때 보통은 ‘새로운 것이 얼마나 좋은가?’에 많은 관심을 갖는다. 얼마나 어-썸한 기능이 있어? 무겁지는 않아? 사용이 어렵지는 않고? 그에 대한 수치화된 비교 자료가 있어?와 같이 말이다. 그렇지만 그에 못지않게, (개인적으로는 그보다 더) 관심가져야 하는 부분은 기존에는 어떤 문제점이 있었고, 그것을 어떤 방식으로 해결하였는가?가 중요하다고 생각한다. 암만 유명하고/저렴하고/가볍고/이쁘고/안정적 이여도 기존의 프로세스에 특별한 문제점이 없다면 굳이 도입할 이유가 없지 않겠는가?

IaC(Infrastructure as Code)는 수동 작업 대비 일관성 유지, 재사용성, 자동화 측면을 개선 한다. 테라폼은 cloudformation, pulumi와 같은 IaC 방법론을 실현하는 도구 중 하나일 뿐이다. IaC 이전의 (클라우드 상의) 인프라 관리는 웹 콘솔이 주류로 사용되었을 것이다. 콘솔로도 작업은 가능할 것이다. 하지만 대규모 / 반복적 작업을 수행하는 경우는 어떨까?

가령 필요에 따라 dev 환경을 생성하고 제거한다는 일이 반복적으로 필요하다고 가정하자. 해당 dev VPC에는 각 3개의 퍼블릭/프라이빗 서브넷을 갖고, 퍼블릭엔 서비스 확인을 위한 접근용 ALB / 프라이빗엔 web서버 및 RDS가 구성되어야 하고, 각 ALB와 EC2에 대하여 쉬운 접근을 위해 Route53 도메인을 붙이는 것이 필요 조건이다.

해당 과정을 수동으로 진행한다면 리소스 tag 규칙등의 과정에서 입력 실수로 인해 누락락/오입력이 발생하고, 일관성이 훼손될 수 있다. 또한 생성한 뒤 qa가 끝나면 삭제하고, 다시 필요할때 재생성할 때, 이를 일일히 클릭-대기로 진행하면 시간도 오래 걸리고, 비효율적이다. 그러나 코드로 구성되어, 필요할때마다 복제하고 재생성 한다면 매우 효율적일것이다.

3. Then, What is the Terraform Cloud?

테라폼이 IaC 실현에 초점이 맞춰져 있다면, 테클은 실제 운영 환경에서 사용 시 관리 포인트를 줄여주는 보조 도구의 역할을 한다.

정의

테라폼 클라우드는 하시코프가 제공하는 관리형 서비스입니다. 실제 운영환경에서 테라폼을 사용하는 개인, 팀, 기관에 있어서, 불필요한 관리 도구 및 문서 작업의 필요성을 줄여줍니다. 테라폼 작동과정(workflow)에 최적화된 원격 환경에서 인프라를 구성합니다.

Hashicorp, Terraform Cloud

3.1. 주요 기능

기존) 로컬 머신에 설치된 테라폼 / 로컬 구성파일을 통해 실행

테클) Hashicorp의 VM에 설치된 테라폼 / 연동된 VC의 구성파일을 통해 실행

전체 기능의 목록과 설명은 관련 공식 문서를 참고하면 좋고, 여기에서는 관심 있게 본 & Free tier 에서 제공되는 기능 위주로 정리하였다.

3.1.1. 원격에서의 테라폼 실행

테클의 제일 큰 특징은 별도의 VM이 있어서, 사용자의 로컬 환경이 아닌 원격에서 plan & apply가 실행된다는 것이다.

Github Action도 그렇고, Travis도 그렇고, SaaS 서비스의 큰 특징 중 하나는 사용자의 환경이 아닌, 서비스 제공 회사의 별도 환경에서 작동되는 점인것 같다. 이런 트렌드를 지칭하는 멋진 말도 있을 것 같은데.. 그냥 SaaS의 공통점이려나.

별도의 원격 환경을 제공하는 제일 큰 이유는 사용자마다 동일한 사용 경험을 보장할 수 있다는 부분이라고 생각한다. 소위 ‘내 컴에서는 됐는데 니 컴에선 웨 안댐?’ 같은 문제는 발생하지 않겠지.

3.1.2. 팀 기반 권한 관리

인프라 코드에 대해서, 사내의 모든 사람이 접근할 순 있어도 실행(생성 또는 제거)에 대해서는 제어가 필요하지 않을까? > 테클이 해줍니다.

추후 예시에서도 나오겠지만, 테클을 적용하면 테클상에 등록되어 인증받은 사람만이(=토큰이 발급된) 해당 테라폼 구성 코드를 사용할 수 있도록 설정할 수 있다.
작업자별 / 작업영역별로 세분화된 권한관리는 유료 서비스의 영역.

3.1.3. 프로젝트 & 워크스페이스 > 세분화된 작업환경 관리

디렉토리별로 복잡하게 구분된 테라폼 구성 파일들을, 각 디렉토리(워크스페이스) / 프로젝트별로 시각화 해줘서 관리를 용이하게 한다.

테라폼 사용이 고도화 될수록 디렉토리 구조가 복잡해지고, 가시성이 떨어지게된다. 처음 사용할때는 하나의 디렉토리에 main.tf, variable.tf 를 두는 식으로 간단하게 구성할 것이다. 하지만 필요에따라 VPC / IAM / EC2 / RDS 등 각 리소스별, 또는 자체 Module 활용시 모듈별 디렉토리 구성등으로 세분화 되어 관리되는 순간, 각 디렉토리별 연관 관계는 복잡해진다.

테라폼 명령어를 사용할때, 테라폼은 현재 디렉토리(working directory)에 있는 구성파일(*.tf), state파일(*.tfstate 또는 remote state), 변수파일(variables.tf)들의 값을 가져와 변경이전과(state) 변경이후(구성+변수)를 생성한 뒤 차이점을 비교한다. 이 실행되는 개별 디렉토리를 테클에서는 workspace라고 부른다(CLI의 workspace랑은 조금 다른 느낌인듯함).

Terraform Cloud에서 Project내 Workspace 모습 – Coralogix, Terraform Quick Start Tutorial

3.1.4 원격 state 관리

원격으로 공유되는 state파일 및 apply 시점에 따른 각 state 기록, 비교 제공

로컬환경의 테라폼도 AWS S3 / DynamoDB와 연계하는 식으로 원격 state 관리가 가능했다. 하지만 테클에서는 자체 state 저장소/Lock 구현으로 별도의 추가 설정 없이 각 workspace에 자동적으로 붙여준다.

AWS S3에 저장하고, Versioning을 켜고, DynamoDB로 Lock을 거는거랑 다른것이 뭐가있어? 싶었다. 그러나 각 버킷, 테이블을 생성하고 입력하는 대신 Workspace만 생성되면 자동으로 구성해준다는점만으로도 장점인듯 하다.

추가적으로, Apply 시점별 state가 저장되어있어 매번 실행 후에, 이전버전에 비해 어떤 리소스가 추가되었고, 어떤 리소스가 사라졌는지 볼 수 있다.

3.1.5 버전관리 시스템과의 연동

Github등과 같은 버전관리 시스템과 연동하여, Pull Request 생성 시 비교결과를 첨부 해주거나, Main으로 merge되면 자동적으로 Plan & Apply를 돌려주는 등의 편의 기능을 제공한다.

PR 생성시 (예상) 변경 내역을 Plan하여 첨부된 모습

이는 팀원간 작업내용을 Review할 때, 단순히 코드만 보고 리뷰하는 것이 아닌 plan 결과 (무엇이 추가적으로 생성/변경/제거되는지) 또한 참조할 수 있어 도움이 된다.

3.1.6 알림 & 웹훅

개별 워크스페이스별로, run 상태 및 결과에 대해서 알림을 설정할 수 있다. 알림은 웹훅 방식으로 트리거되며, 슬랙등의 서비스에 시작/과정/결과 메세지를 보낼 수 있다.

기본적으로 연동설정된 알람 메시지 예시
(좌) 시작, Plan, Apply, 결과 모든 단계별 알람 허용시 / (우) 보기편하게 시작, 결과만 알람 설정 시

3.2. Plans

관리형 서비스인 만큼, 무료 요금제와 유료 요금제가 나뉘어져 있고 각 요금제마다 제공 기능이 다르다. 테클의 요금제는 공식 문서보다, 실제 테클 콘솔에서 보는게 제일 잘 정리 되어있다.

230212 기준, 5인 이상인 경우만 아니면 유료플랜을 사용할 이유가 있나?싶다. 5인 넘더라도 한 계정을 여러명이 돌려쓰면 1 계정?

Terraform Cloud 요금제 캡쳐 (230212 기준)

3.2.1. Free tier

  • 무료 / 최대 5인까지
  • 기본적인 기능들 지원
    • Workspace, Remote Plan & Apply 무제한 (이걸로 돈받아먹으면 사기꾼들이지)
    • Remote state / State Lock
    • GitHub와 같은 Version Control 서비스와의 연동 / API 제공
    • 알림 및 웹훅

3.2.2. Team tier

  • 인당 20달러
  • 팀 / 역할 관리
    • 등록된 팀원 그룹화 / 권한관리 (읽기만 or 실행까지 그런 느낌)

3.2.3. Team & Governance tier

  • 인당 70달러
  • Run tasks: 개별 Workspace 별로, plan 또는 Apply 이후 추가작업 트리거
  • Policy 관리: 실행에 대한 정책과 규칙 설정 (유효성 검증?)
    • 배포할 수 있는 인스턴스의 최대 유형 및 갯수 설정 등
  • Cost Estimation: 생성 또는 제거될 인프라에 대한 비용 예측
    • 위의 Policy와 연계하여, 지정된 예산 이상의 배포 제한 등의 사용 예시

3.2.4. Business tier

  • 별도 세일즈팀에게 연락필요 (짐작도 안감. 더 비싸려나?)
  • SSO
  • Agents: IDC 같은 폐쇄망에서 사용시 필요한 기능인듯함
  • Additional Run Concurrency: 기본 티어에서는 1개의 VM만 사용가능, 한번에 하나의 Plan&Apply만 수행 가능하기 때문에 대규모 작업시는 다소간 시간소요

4. Basic Usage

설명 주저리주저리하는것보다 데모 한번이 낫더라.

처음 계정 생성 시 주어지는 example 구성이 아닌, git repository의 구성파일들을 테클과 연동하고, plan/apply/destroy 까지의 과정을 정리해보았다. 아래 과정에서 사용한 레포의 주소는 https://github.com/nasir17git/logonme 이고, AWS 상에서 퍼블릭 서브넷을 생성하고, 간단한 http 응답을 하는 EC2 1대를 띄울 예정이다.

4.1. 웹 콘솔 상 설정

테클 작업환경을 구성하기 위해, 먼저 테클 웹 콘솔상의 환경 구성이 필요하다. 테라폼 클라우드 계정을 생성하고, 팀원들이 속할 조직(Organization)을 생성한뒤, 개별 작업 디렉토리 설정과(Workspace) Github repository와 연동할 것이다.

계정을 만들고 나면, Organization 생성과 Workspace는 tfe registry를 참고해서 코드로 관리할 수 있다. 하지만 최초 구성시에는 콘솔로 구성해보는 과정이 작동 방식을 이해하기에 유용할 것이다.

4.1.1. Account 생성

테클 웹 콘솔의 주소는 https://app.terraform.io/ 이다. 해당 주소에 접속하여 HCP(HashiCorP?)계정을 생성하도록 한다. (Github 연동으로 간단하게 생성 가능)

4.1.2. Organization

Setup workflow 설정

초기 접속화면

처음 접속하면 Workflow를 설정해야한다. example 구성을 안쓰고 자체 구성 과정을 정리하고 싶기 때문에, 이 중 가운데 Start from scratch를 선택해서 새로운 환경 구성을 시작한다.

New organization 생성

Organization 생성 화면

Organizatin 이름에는 사용할 조직이름을 적는다. 조직명은 생성 이후 수정도 가능. 하단 create organization 버튼을 누르면 조직 생성이 완료된다.

4.1.3. Workspace

Workspace type 선택

Workspace type 선택

조직 생성이 완료되면 콘솔의 대시보드로 들어오게된다. 좌측 하단에서 현재 선택된 조직명을 확인할 수 있다.

지금은 생성된 프로젝트/워크스페이스가 없기 때문에 신규 Workspace(이하ws)를 생성하는 창이 열린다.

선택 가능한 워크플로우는 Version control, CLI-driven, API-driven이 있다. 그 중 첫번째 VC workflow를 선택한다. 생성 이후에도 변경이 가능하다.

  • VC Workflow
    • 해당 ws는 vc레포지토리와 연결되어, 해당 레포의 구성파일 기반으로 작동한다.
    • (중요) 로컬 터미널에서의 로컬 구성파일을 사용한 CLI 명령어 (apply등)의 사용이 불가능 해진다
    • 모든 Run은 레포에 커밋된 구성파일을 기반으로, 테클의 VM상에서 수행된다.
    • PR에 대한 체크기능 및 누가, 언제 plan/apply를 실행했는지, 그때의 결과와 state에 대한 기록이 남는다.
  • CLI-driven
    • 로컬 터미널에서의 CLI 명령어 사용이 가능하다
    • 테클은 단순히 원격 state 저장소로만 작동한다.
    • PR체크, Run 결과의 기록이 남지 않는다. (로컬에서 하니까 테클이 알 수 없을 듯)
  • API-driven
    • API Call에 의한 작업 수행이 가능하다.
    • API까진 안써봐서.. 전반적으로 VC와 가까운 설정이다.

VCS 연결

VCS Connection

연결할 Vercion control source를 선택한다. 기본적으로는 Github만 보이며, 하단의 Connect to a different VCS를 클릭하면 깃랩, 빗버킷, 애져데봅스 같은 다른 서비스와도 연동할 수 있다.

Repositoy 선택

Choose a repository

연결한 vcs 레포 중에서, 연동해야할 (테라폼 구성파일이 있는) 레포지토리를 선택한다.

Configuration settings

먼저 Advanced options를 클릭해서 추가 설정 메뉴를 활성화한 뒤, 변경이 필요한 부분을 변경한다. (생성 이후에도 변경 가능)

여기서 설정할 주요 항목은 Working directory, Apply Method, Run triggers이다. 설정할 내용을 한줄로 정리하면, 레포내의 여러 디렉토리 중 이 ws가 바라볼 경로를 설정하고, 해당 경로의 구성파일에 변경이 있으면 자동으로 apply 하는것이다.

  • Workspace name
    • 테클상에서 표시되는 ws의 이름이다. 기본값은 레포이름이지만 편의상 아래의 working dir과 비슷하게 작성한다.
  • Working Directory
    • 별도의 경로를 잡아주지 않으면, 레포지토리의 최상단(/)에서 필요한 명령어를 (terraform init/plan/appy) 수행한다
    • 최상단 경로에 구성파일이 없기 때문에, 구성파일이 있는 경로를 잡아준다
  • Apply Method
    • VC workflow이기 때문에, CLI 상의 terraform apply 같은 명령어는 사용할 수 없다.
    • Run은 1. 콘솔에서 수동 시작 / 2. PR후 Merge시 자동 시작 할 수 있다.
    • 해당 경우에, Plan 이후 사용자 확인을 거칠지, 바로 Apply를 할지 결정한다.
  • Run Triggers
    • 언제 해당 ws의 Run이 수행될지 설정한다.
      • Run = terraform plan && terraform apply
    • 한 레포에 한 개의 ws가 있으면 좋겠지만, 일반적으로는 여러 작업 환경이 섞여 있다.
    • 항상 런 시작(기본값)을 선택하면 다른 파일이 변경되어도 런이 수행된다.
    • working dir 내부의 변경이 감지 될 시에만 run이 수정되도록, 경로와 패턴을 입력한다.
  • VCS branch
    • 웹 콘솔로 수동으로 run 생성시 바라볼 branch 설정
    • 기본값은 메인/마스터 브랜치이다.
  • Pull Requests
    • speculative plans(추측 플랜) > PR생성시 해당 PR에 plan 결과를 check에 보여주는 기능이다.
    • 기본적으로는 활성화 되어있지만, 한번에 하나의 run 밖에 수행하지 못한다
    • 만약 많은 ws에서 변경사항이 있다면 모든 run 완료에 시간이 걸리기 때문에 끄는것을 추천

4.2.5. AWS Credential 설정

AWS Credentials

AWS 상의 리소스를 생성할 예정이기 때문에, AWS Key를 전달해주어야 한다. 키 값을 환경변수로 설정하여 넘겨줄것이다.

좌측의 Manage > Settings > Variable sets를 클릭하여 키 값을 입력해준다

  • Variable set name > 변경 가능하므로 적당히 적는다. AWS_Credentials 로 입력함
  • Workspaces > 해당 변수세트가 사용될 범위를 정한다. 모든 ws에 적용이 필요한 키값이므로 Apply to all workspaces in this organization 선택
  • Variables
    • 하단의 Add variable을 클릭하여 하나씩 입력한다.
    • 입력시 변수로는 terraform variable / env variable이 있다. terraform var는 구성파일에서 사용하기 위한 변수값이고, env var는 실행환경에 대한 환경변수이다. 키값은 환경변수로 먹여줘야하므로 env 클릭.
    • Sensitive 옵션을 선택하면 최초 입력 이후 값의 사용만 가능하고 조회 또는 수정이 불가능해진다.(read only)
    • AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY 에 필요한 값을 지정한다.
    • 해당 환경변수의 이름은 어디서 왔나 했는데, AWS CLI 문서에 있었다.

4.3. Run (via Web UI)

Run은 terraform plan과 apply를 합친 일련의 과정이다. 우측 상단의 Actions > Start new run을 클릭하여 시작할 수 있다.

Actions > Start new run의 위치와, workspace가 잠겨있지 않은 상태.

새로운 Run을 실행하면, 아래와 같이 해당 workspace에 lock이 걸리는 것을 확인할 수 있다. 해당 Lock이 걸려있는 동안은 동일 ws에 대해 다른사람이 추가변경을 진행할 수 없다.

또한 Latest Run에 새로운 Run이 생성되고, Apply 되는것을 볼 수 있다.

Workspace에 Lock이 걸린 모습
Run 수행 내역

4.4. Destroy (via Web UI)

destroy는 구성된 인프라를 삭제하는, 사용에 주의가 필요한 중요 명령어이다. 따라서 상단의 actions가 아닌, settings 안에 숨겨져 있다.

방금 run으로 만들어진 리소스를 삭제하기 위해서, 좌측 Settings > Destruction and Deletion 항목으로 이동한다. 이곳에서 리소스 및 워크스페이스 삭제와 관련된 명령을 수행할 수 있다.

Workspace 내 Destruction and Deletion 영역

Allow destory plans: CLI를 포함하여, 해당 워크스페이스에 대한 destory 명령어 활성화 여부를 결정한다. 비활성화 시, destroy할 수 없다.

Queue destoy plan: 현재 ws의 모든 리소스를 삭제한다. 위의 토글 옵션을 끈다면 비활성화된다.

4.5. 이력 조회, State 비교

사용자의 로컬 터미널이 아닌 테클의 VM에서 모든 작업이 수행되기 때문에 적용된 모든 작업 내용에 대한 기록이 남는다.

Workspace에서, 좌측의 Run을 클릭하면 지금까지 수행되었던 기록을 볼 수 있다.

또한, 에러가 났을 경우, 에러났던 로그가 남아있기 때문에 재현 및 리뷰할 때 편리했다.

좌측의 State를 클릭하면, plan을 제외한, 실제 apply 시 해당 시점의 state가 남아있다. 이를 통해 매번 apply간 무엇이 추가되고, 무엇이 삭제되었는지 볼 수 있다.

Tags: , ,

Leave a Reply