Terraform 알아보기

앱 개발을 하다가 백엔드 개발자로서 일을 시작하고 가장 크게 벽을 느꼈던 부분이 인프라에 대한 것들이다.

 

API 개발이야, 결국 요청을 받아서 처리한 후 결과를 반환하는 일련의 과정이니 그동안 해왔던 이벤트 기반의 프로그래밍과 별반 다를 것 없다고 생각했고, 실제로도 크게 어려움을 느끼는 부분은 아니다. 오히려 이쪽은 익숙하지 않은 언어적인 부분이 신경쓰이지...

 

그렇지만 인프라- 이 영역은 프로그래밍과는 또 다른 분야라고 생각된다. 최근 몇 개월동안 어찌어찌 간단한 서비스를 운영할 수 있을 정도로는 인프라에 대해 알게 된 것 같지만, 배포는 간신히 되게만 만들어 놓은 상태, 모니터링은 아예 손도 못대봤고 인스턴스나 RDS같은 Managed service는 쓸 줄만 알지 제대로 이해하고 있다고 보기는 어려운 것 같다.

 

실무를 하면서 이런 부분에 대해 갈증을 느끼고 있던 터라, 공부하는 내용을 나름대로 정리해 쌓아두면 도움이 될 것이라 생각해 글을 작성해본다.

 

Terraform

첫 번째 주제는 Terraform이다. 테라폼은 코드로 인프라를 관리할 수 있는(Infrastructure as Code) 서비스로, 서비스 운영에 필요한 환경을 코드로 구축/관리할 수 있는 도구이다.

 

AWS 콘솔을 사용하면서 항상 불편한 점이, 내가 원하는 어떤 리소스의 상태에 도달하기 위해서 복잡하고 어려운 절차를 거쳐야 한다는 점이었다. 물론 익숙해지면 리소스를 조작하는 다양한 기능들이 편하게 느껴지겠지만, 내가 전문적인 인프라 엔지니어가 되고자 하는 것도 아니고, 서비스를 운영할 때 기본적으로 갖추어야하는 것들에 대해 파악하는 것 정도면 충분하기 때문에 부담스럽게 느껴졌다.

 

테라폼에 대해 잘 알지는 못하지만, 간단하게 살펴봤을 때 선언적으로 리소스를 정의하고 관리할 수 있다는 점이 마음에 들었다. 선언적 프로그래밍은 이미 익숙한 개념이었고, 인프라를 그렇게 다룰 수 있다면 세부 디테일에 크게 신경쓰지 않고 내가 원하는 환경을 구축할 수 있을거라는 생각이다.

 

Terraform 설치

사용을 위해서는 설치를 해야할텐데, 가장 간단한 방법으로 Homebrew를 사용해 설치를 하기로 했다. Mac의 경우 아래 명령어를 입력하면 간단하게 테라폼을 내려받을 수 있다. Mac 이외의 설치 방법은 공식 사이트를 참고.

$ brew install terraform

 

테라폼도 nvm, pyenv와 같은 버전 관리 도구가 있다. tfenv를 사용하면 프로젝트마다 여러 버전의 테라폼을 사용할 수 있는데, 나로서는 크게 중요하다고 느껴지진 않아서 위의 간단한 방법을 사용하려고 한다. tfenv가 궁금한 사람들은 44bits의 관련 글을 참고하길 바란다.

 

Terraform 기본 개념

테라폼에서 사용하는 몇 가지 용어와 개념들을 한 번 정리해보았다.

 

프로바이더 (Provider)

테라폼과 외부 서비스를 연결해주는 플러그인. 테라폼은 프로비저닝 도구 - 즉 리소스를 선언하고 계획하는 도구이기 때문에, 프로비저닝을 하고 적용할 때 어떤 방식으로든 실제 리소스가 생성, 변경 및 삭제될 외부 서비스가 필요하다. 대표적으로 AWS, GCP, Azure 등이 대표적이고, 쿠버네티스나 깃허브, 그라파나 같은 다양한 프로바이더들이 존재한다.

 

AWS같은 범용 클라우드 서비스가 제공하는 리소스가 어떤 것들이 있을지는 명확한데, GitHub같은 프로바이더는 어떤 리소스를 제공하고 어떻게 사용되는지 궁금해서 잠깐 찾아봤다.

 

HashiCorp 블로그에 올라온 Managing GitHub with Terraform 글을 보면 GitHub 프로바이더를 어떻게 활용하는지 알 수 있다. 간단하게 정리해보자면,

 

새로운 직원이 회사에 들어왔을 때 해당 직원의 정보를 테라폼 설정에 추가하기만 하면,
다음 번 테라폼을 실행했을 때 필요한 권한이나 멤버 등을 따로 직접 관리하지 않아도 된다.

 

회사를 운영하는 입장에서 온보딩 절차를 이런 식으로 관리하면 확실히 유용할 것 같기는 한데, 잘 구성하기는 쉽지 않을 것 같다. 단순히 인프라 관리를 용이하게 하는 정도만 예상했는데, 생각보다 활용 범위가 넓다.

 

리소스 (Resource)

리소스는 프로바이더가 제공하는 인프라의 최소 단위이다. 공식 문서에서는 Infrastructure Object라는 표현을 쓰는데, AWS를 예시로 들면 VPC, EC2 등, 앞서 이야기한 GitHub를 예시로 들면 organization, repository 등이 될 수 있겠다.

 

테라폼은 결국 리소스를 코드로 관리하는게 핵심이기 때문에, 리소스야말로 테라폼의 시작과 끝이라고 할 수 있다.

 

테라폼 언어 (Terraform Language)

테라폼에서 사용하는 언어. 테라폼 언어의 주 목적은 단순히 리소스를 정의하는 것이고, 기타 다른 기능들은 이 과정을 좀 더 편하게 해주기 위해 제공된다고 한다. (variables 같은 것들)

HCL과의 연관성

HCL은 HashiCorp Configuration Language의 약자로, HashiCorp의 제품들이 무언가 설정을 할 때 사용한다.

 

테라폼에서 리소스 명세를 작성하기 위해서 사용하는 언어가 바로 HCL인데, 이 HCL은 우리가 흔히 아는 프로그래밍 언어와는 다르게, JSON이나 YAML같은 일종의 문서 형식에 가깝다. 처음 HCL을 접했을 때 이 부분이 가장 혼란스러웠는데, 아래 예시를 보면 쉽게 이해할 수 있다.

 

왼쪽 - Vault 설정, 오른쪽 - Terraform 설정

동일한 문법을 가지고 있지만, 사용하는 블록이 서로 다르다. Vault는 데이터가 저장될 백엔드를 지정하기 위해 storage라는 블록을 사용하고, Terraform은 리소스를 정의하기 위해 resource라는 블록을 사용한다.

 

이 두 가지 코드는 당연히 서로 호환이 불가능하겠지만, 어찌됬건 그 구조나 형식은 동일하다. CI/CD 절차나 OpenAPI 스펙을 yaml로 작성해봤다면 쉽게 이해할 수 있겠다.

 

테라폼 실행 흐름

테라폼을 실행한다고 했을 때, 이는 테라폼 언어로 작성한 명세를 바탕으로, 실제 인프라 리소스들을 생성/수정/삭제해 원하는 상태에 도달하는 것을 의미한다.

테라폼은 나누어 이러한 작업을 수행하는데, 하나씩 알아보도록 하자.

 

계획 (Planning)

계획 단계에서는 선언한 리소스 명세와 실제 리소스의 상태를 비교해 그 차이를 알아내고, 선언한 리소스 명세에 맞게 상태를 변경하기 위해서 필요한 변경점들을 사용자에게 보여준다. 어디까지나 계획, 플랜을 짜는 단계이니만큼 이 과정에서 실제로 변경이 일어나는 것은 아니고, 이후 살펴볼 적용 단계에서 어떤 변경이 일어날지 미리 확인하는 단계라고 보면 된다.

 

사견을 조금 붙이자면, 아마 이 부분이 테라폼과 같이 상태 기반으로 동작하는 프로그램에서 가장 중요한 부분이라고 생각한다. 만약 이런 부분에서 문제가 발생한다면 필요한 리소스인데 불필요하다고 판단해 삭제해버린다던지 하는 일이 생길 수 있기 때문에...

 

terraform plan 명령을 통해 이 작업을 수행할 수 있다.

 

적용 (Applying)

적용 단계는 계획 단계에서 찾은 변경점들을 실제로 반영하는 단계이다. terraform apply 명령을 통해 이 작업을 수행할 수 있고, 실행 시 사용자에게 확인 여부를 한 번 더 묻는다.

 

제거 (Destroying)

테라폼을 사용하기 위해서 일반적으로 plan과 apply정도면 충분한데, 명세되어 있는 리소스들을 한 번에 정리하고 싶을 경우, terraform destroy를 사용해 리소스를 모두 삭제할 수 있다.

 

동작을 놓고 보면 명세를 모두 삭제한 후 적용을 한 것과 동일하지만, 명세를 건들 필요가 없기 때문에 이런 목적이라면 더 간편하다는 장점이 있다.

 

---

지금까지 이야기했던 내용을 간단히 정리하면, 다음과 같다.

 

• 프로바이더 - 테라폼과 외부 서비스를 연결한다.
• 리소스 - 프로바이더가 제공하는, 테라폼으로 관리할 수 있는 인프라 요소들.
• 테라폼 언어, HCL - 리소스 명세를 위해 사용하는 하시코프의 설정 언어.
• 실행 흐름 - 계획/적용을 통해 리소스를 조작한다.

이 개념들을 한 데 묶으면 테라폼을 어떻게 쓰는 것인지 알 수 있다.

프로바이더에서 필요한 리소스를 골라 HCL로 정의한다. 이렇게 작성한 계획을 plan을 통해서 검증하고 apply로 적용한다.

 

여기서 이야기한 내용들은 공식 문서에 보다 자세히 나와있으니, 각 주제에 대해서 좀 더 심도있게 알고싶은 사람은 공식 문서를 참조하면 좋을 것 같다.

 

기본적인 개념에 대한 소개는 여기서 마무리짓고, 다음 글에서는 이러한 흐름에 맞추어서 간단하게 실습을 해보고, 느낀 점을 서술해보려고 한다.

 

@turastory