You are currently viewing Terraform cloud를 사용한 GitOps 구현

Terraform cloud를 사용한 GitOps 구현

TL;DR

  1. GitOps에 대한 간단한 소개
  2. CLI가 아닌, Git PR-Merge를 통한 terraform 명령어 실행 과정
  3. github 연동, 동일한 작업환경, 권한 관리, 에러 로깅 등이 장점, 다른 지원도구(AWS S3,등) 대비 특출난 기능이 없는건 단점

1. Intro & Overview

지난글에서는 기본적인 Terraform Cloud(이하 테클)의 개념과, Web 콘솔에서의 기본적인 사용법에 대하여 다루었다.

이번글에서는, 테클을 VCS(Version Control Source)인 GitHub와 연동하여 사용하는 GitOps Workflow와, 기본편에서 다루지 못했던 심화 설정들을 다루고자 한다. 또한 테클을 공부하면서 생각했던 장/단점을 이야기 해보고자 한다.

2. GitOps?

GitOps 또한 DevOps에서 파생된 많고 많은 *Ops 개념 중 하나이다.

“누가 인프라의 현황을 묻거든 고개를 들어 Git을 보게하라”

Git+DevOps의 합성어이며, IaC 사용 시 Git 레포지토리를 단일 진실 공급원(Single Source of Truth, SSOT)으로 연동하고, 레포에 등록된 구성 파일만 실행될 수 있도록 제한하는 것이다.

DevOps팀에서 IaC를 사용한다 하여도, 각자의 환경에서 각자의 구성 파일로 인프라를 관리한다면 현재 인프라에 대한 가시성이 저하된다.

“temp_ec2_03 인스턴스 만든 사람? 이거 지금 쓰고 있어?”

위와 같은 시나리오는 클라우드 운영을 담당하다보면 심심치 않게 마주할 수 있을 것이다. 누가, 언제, 무슨 의도로 리소스를 만들었는지 AWS 콘솔은 알려주지 않는다…

대신, 인프라 관리를 코드화 하고, 이를 Git repository를 통해 merge된 구성 코드만 실행되도록 하면 이러한 문제를 많이 줄일 수 있다. Commit history를 통해 누가, 언제, 무슨 의도로 어떤 리소스를 만들었는지 알 수 있다.

개인의 로컬 분산된 작업환경 대신, 구성 파일이 깃 레포에 중앙집중되고, 깃 레포만이 실제 반영된 인프라라는 확신(SSOT)이 된다면 인프라의 가시성 확보에 큰 도움이 될 것이다.

일반적으로 GitOps는 CI/CD 파이프라인 중 CD단계에서, ArgoCD를 사용하여 선언적인 pod-컨테이너 관리 사례로 자주 언급된다. 그러나 테라폼 또한 선언적인 인프라 관리를 지원하기 때문에, 인프라 관리에서의 GitOps를 구현할 수 있다.

자세한 GitOps에 대한 설명은 Redhat 문서와 삼성 SDS 인사이트 리포트를 참고할 것

3. Demo

글보다는 예시가 궁금한 당신을 위하여

3.1. 로컬 터미널 상 설정

테클의 웹콘솔의 설정을 마치고나면, 실제 테라폼 구성파일이 테클의 ws를 바라볼 수 있도록 구성파일을 업데이트하고, 터미널에서 테클을 사용할 수 있도록 인증을 수행하여야 한다.

3.1.1. 구성 파일(*.tf) 수정

terraform {
  cloud {
    organization = "logonme"
    workspaces {
      name = "terraform-init"
    }
  }

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "4.10.0"
    }
  }
}

테라폼 구성파일에서, 테클과 조직, ws를 바라볼 수 있도록 terraform 블럭을 추가해주어야한다. 구성 파일과 같은 디렉토리내에 있으면 구문의 위치는 중요하지 않다.

3.1.2. terraform login

CLI의 상태가..?!

구성파일을 변경하고, 테라폼 명령어(init/plan/apply)를 사용하려고 하면 사용할 수가 없다. 이는 테클의 조직/ws에서 작업을 수행하려면 인증된 사람이라고 토큰을 받아야하기 때문이다.

terraform login

터미널에 해당 명령어를 입력하면, 위와 같은 창이 지나간 후 토큰 로그인을 할 수 있다.

https://app.terraform.io/app/settings/tokens?source=terraform-login 에서 토큰을 생성한 뒤 입력하면 되며,
/home/ec2-user/.terraform.d/credentials.tfrc.json 경로에 저장된다.

terraform plan
terraform apply

이후 terraform plan / apply 명령어 사용시 다음과 같은 화면을 볼 수 있다.

plan의 경우 실질적으로는 테클의 vm을 통해서 수행되고, 그 결과가 사용자의 터미널로 복사되어서 출력된다. 중간의 링크를 클릭하면 웹 콘솔 상에서도 plan 결과를 볼 수 있다.

apply의 경우 더이상 로컬 구성파일 / 터미널을 통한 실행이 불가능하다. git에 등록된 구성파일만이 실제 사용중인 state와 일치하도록 강력히 제한되고있는것이다.

3.2. Run (via Git PR)

3.2.1. Pull Request 생성

PR Check

PR과 Merge를 통한 방법이다. 브랜치를 따서 일련의 변경사항을 생성한 뒤, PR을 생성하면 이번 PR로 인해서 무엇이 바뀌는지 Check해줘서 확인할 수 있다. > 코드리뷰랑 협업시 유용하게 쓰고있음

3.3. Run

해당 PR을 머지하면, ws에 lock이 걸리고 자동으로 apply가 도는 모습을 확인할 수 있다.

이를 통해서, 테클을 통해 관리되는 모든 IaC 인프라의 상태가 Git 레포지토리의 구성파일의 상태와 동일하다는 것을 보장할 수 있다.

3.1.2.에서 보았던 바와 같이, git pr-merge를 통하지 않고 로컬에서 소스 코드에 변경을 가해도, git repository로 commit 하지 않으면 실행이 불가능 하기 떄문이다.

4. 추가 설정

4.1. Workflow 간 변경 (VCS <> CLI)

3. Demo와 같이 cli 설정을 제한할 수 있지만, 이를 변경하고 싶다면 변경할 수 있다. 워크스페이스 내 좌측 Version Control에서 Change source를 선택하면 처음부터 설정 할 수 있다.

다만 해당 방식으로 변경시 다른 설정값도 초기화되는 것이 불편했다. 구체적으로 무엇이 차이가 있나 보았을때 General의 Execution mode가 Remote / Local 설정인지가 큰 차이인듯 하다. 따라서 설정을 Local로 변경하면 CLI의 사용이 가능하다.

다만, 이전글에서 언급하였듯 CLI모드에서는 단순 state 저장 및 Locking만을 제공하므로, PR Check등의 기능은 작동하지 않는다. 팀에 적절한 사용 방식은 선택은 사용자의 몫!

4.2. 출력 방식 변경 (Console UI)

테클에서 제공하는 Structured Run Output이 심미적으로 예쁘기는 하지만.. 친숙한 터미널의 출력을 보고싶다면 터미널 방식으로 볼 수 있도록 설정할 수도 있다.

Workspace settings > General > 하단의 User Interface를 Structured Run Output에서 Console UI로 변경하면 출력 형식의 변경이 가능하다.

Structured Run Output 예시
Console UI 설정 예시

5. Outro

최종적으로, 개인적으로 느낀 테클을 사용한 협업 환경의 장점과 단점은 아래와 같다.

5.1. 장점

5.1.1. GitOps

Github와 연동되어 마지막으로 작동한 코드의 조회 및 변경 시 사유의 조회 가능

PR 생성시 변경 예정 사항에 대해 Plan결과를 첨부해주기 때문에 리뷰시 용이함

5.1.2. 동일한 작업 환경 + 에러 로그 보존

같은 구성파일이더라고 떄떄로 어떤사람의 환경에서는 실행되고, 다른 사람의 환경에서는 실행되지 않는 경우가 있었다.

+ 작업중 에러메세지가 발생하고 해결했을때, 이후 어떤 에러가 발생했고 어떻게 대처했는지 보는게 쉽지않았음. 해당 상황에 대한 기록이 남아있어서 상태 공유에도 편리함

5.1.3. 권한 관리 + 작업 로그

‘혹시나 누가 고의/실수로 인프라 설정을 망가뜨리면 어떡하지’

> 조직에 등록되고, 토큰 발급 받은 사용자만 작업가능

+ 오류로 인한 장애가 발생하더라도, 어떤 작업을 했기 때문인지, 어떻게 진행되었는지 바로 공유가능

5.2. 단점

5.2.1. 이름 좀 바꿔라

Amazon이 왜 Amazon cloud라고 안하고 AWS라고 이름을 지었을까? 왜 Microsoft가 MS cloud가 아닌 Azure로 이름을 지었을까? 왜 Google cloud platform이 GCP라고 줄여서 사용할까?

기존의 서비스가 있다면 검색어 중복등이나 실수없도록 다른 이름을 지어야 할것

terraform cloud 정보 좀 얻으려고 검색할때마다 terraform으로 cloud구성하기 / cloud 환경에서 terraform 사용이 중요한 이유와 같은 글들이 나와서 정보찾기가 너무 힘듬

5.2.2. 특별한 기능 부재

hashicorp에서 공식적으로 지원하길래, 뭔가.. 뭔가 좀더 있는듯함

뭔가 없는듯

별도로 버킷만들고, 테이블만들고, 키 값 넣어주는것보다는 자동으로 붙여주는게 좋긴하지만,

5.2.3. 사용 권한에 대한 강력한 제어

사용자 선택이겠지만, VC Workflow만큼 강력히 제어하는게 맞나? 맞는것 같기도 하면서도.. 하는 의문이 듦.

Tags: , , ,

Leave a Reply