Terraform

기초

HashiCorp라는 회사에서 만든 솔루션이다.
이는 인프라를 구축,변경,버전관리를 하기 위한 도구로서 코드로 인프라를 관리할 수 있게 해준다.
코드가 곧 인프라가 되고, 인프라를 코드로 설명할 수 있어야 한다는 것이다.

Provisioning

Day0, Day1, Day2 이런 식으로 설명한다.

Day0
- 요구사항 분석, 어떤 아키텍쳐를 설계할지에 대한 트레이닝 과정
Day1
- 설계된 아키텍쳐의 구현
- 인프라, 네트워크 서비스 구현 등이 여기서 이루어진다.
Day2
- Day1에서 구성된 요소들을 관리하고, 유지보수하고, 새로운 요청이 있으면 새로운 아키텍쳐를 구성하는 등의 반복 작업을 여기서 수행해준다.

Day1을 통해서 인프라 구성 완료를 했다고 가정해 보자.
그리고 이후 Day2에서처럼 이를 발전해 나가려고 하면 Terraform에서는 이를 코드로 할 수 있다.
해당 내용을 IaC - Infrastructure as Code라고 한다.

Terraform Config

일련의 선언적으로 구성 파일을 구성하는 것을 Terraform Config라고 설명한다.
해당 내용에는 Day1에서 구성할 인프라에 대한 정의가(VPC는 어떻게 할건지, Security Group은 어떻게 할건지, VM의 경우는 몇 개를 만들지, LB는 어떤 식으로 구성할지 등등..) 코드로 작성된다.

이러한 TF config에 나와있는 모든 정보들은 real 환경과 동일한 하나의 set로 나타난다.

이제부터는 Terraform config가 어떤 식으로 구성되는지 알아본다.

Refresh

Terraform으로 만들어진 세상이 실제로 어떻게 생겼는지 확인한다.
테라폼의 view와 real을 비교한다.

Plan

현재 상태를 원하는 상태로 구성하는 단계이다.
Real쪽에 내가 원하는 Disired를 구현한다.

내가 이 코드로 정리한 내용을 통해 Infra에 구현하게 되면 어떤 구성 요소가 새로 생길지, 그리고 어떤 요소가 업데이트/삭제 될지를 파악할 수 있는 변경점을 예측해주는 역할을 한다.

Apply

Plan으로 만들어진 것을 Real환경에 적용하는 단계가 Apply이다.
즉 필요한게 무엇인지, 변경점이 어떻게 될지를 알면 해당 내용들에 대한 구성 요소를 바꾸어 가는 것이 Apply 단계이다.

이러한 적용 방식은 그래프 이론에 기반하고 있고, 프로비저닝 방식은 사용자가 각 자원의 선호 관계를 명시하지 않아도 알아서 순차로 진행할 작업과 병렬로 진행할 작업을 구분하기 때문에 안심하고 작업할 수 있다.

여기서 만약 기존에 구성된 LB에 추가로 들어갈 것이 있다고 가정해 보자
DNS, CDN등이 있을 수 있다.

이러한 것들을 TF config에 적용한 후에 동작하면, 이러한 구성 요소들이 실제 환경에 적용되고, 이것들을 바로 확인할 수 있는것이 IaC의 장점이라고 할 수 있다.

추가로 한가지 동작이 있는데, 이것이

Destroy

이다.

말 그대로 파괴하는 것인데, 지금까지 인프라에 관한 것들이 코드에 정의되어 있기 때문에 우리가 일일히 특정 인프라에 들어가서 이걸 지워야지~ 하는게 아니라, 생성되어 있는 Code-Based infra는 코드에 정의된 대로 거꾸로 없애는 작업도 같이 할 수 있다.

Plan -> Real

어떤걸 파괴할지 확인한 후에, 실제 서버에서 이를 없애주는 작업이다.

Providers

테라폼이 그럼 무엇을 통해 각 Provisining을 관리할 수 있을까?
Providers가 해당 역할을 수행한다.

provider이전에 terraform core에 대해 미리 알고 있어야 한다.
terraform core은 go언어로 작성된 Binary이다.
comfile된 binary는 terraform을 사용하는 CLI를 제공하고 빌드 환경에 따라 각 실행 플랫폼을 지원한다.

해당 core의 주요 역할은 IaC를 위한 구성 파일(TFConfig)같은 것들을 읽고 삽입하는 작업을 하거나, 각 자원에 대한 상태를 관리한다.

자원의 그래프처리 / 실행 계획 / 플러그인 관리 등등...

이러한 플러그인은 누구나 제작하거나, 혹은 제공되는 것들을 사용해서 바로바로 적용할 수 있다.
이런 플러그인을 Provider라고 부른다.

예를 들어, AWS, Azure, GCP등이 제공하는 환경이나
OpenStack, VMware등등
을 통해 IaaS의 제어가 가능하다.

혹은 Heroku, K8s, Lambda 등의 PaaS환경의 관리
Datadog, Fastly, Github 등의 SaaS환경의 관리가 가능하다.

이러한 인프라 플랫폼 서비스의 연계를 해줄수도 있다.

이러한 것을 통해 Day2의 인프라 삭제, 추가, 수정 등등이 가능하다.

Workflow

개인

Terraform을 local에서 사용하는 사람의 workflow는

Plan, Apply를 거치며 실제 Infra를 만들기 시작한다.
하나가 아니라 여러개의 코드 작성
인프라 작업이 일관되게 변화하기를 기대하며 새로운 사용자를 추가한다.(각 사용자는 각자의 코드 관리)
하지만 이런 코드들은 각자의 local에서 실행되기 때문에 provisioning이 겹치게 되는 문제가 발생한다.
이러한 코드의 중복(무결성 유지)를 위해 Git을 사용할 수 있다.

사용자가 Code 생성
Git 저장소에 해당 code저장
겹치지 않게끔 코드 관리
Terraform Enterprise에서는 이러한 것을 관리할 수 있는 VCS를 제공함.
이렇게 관리되는것은 local이 아니라 state로 적용
기업에서는 실제 코드를 정책에 따라 적용해야 할 것이다. (요구사항이 생긴다)
그래서 이러한 정책 기반 Apply를 위해 Sentinal을 사용한다. (ABAC등에서 쓰인다.)
또한 변수같은 것이 많이 필요한데, local에서 저장되게 된다.
기업 환경에서는 공통변수나 민감한 정보를 중앙에서 관리해야 한다.
나중에 Code Base Configration들을 module로 좀 더 편하게 작업할 수 있게 변화한다.
모듈을 관리할 수 있는 모듈 레지스트리도 제공한다.