Terraform - Workflow

이 포스팅은 CloudNet@ 팀이 진행하는 테라폼 기초 입문 스터디에 참여하며 ‘테라폼으로 시작하는 IaC’ 책을 기준하여 정리한 글입니다.

 

---

Workflow

테라폼 워크플로는 단계별로 다음과 같이 구분한다.

• Write: 코드를 작성
• Plan: 적용하기 위한 실행 계획을 통해 리뷰
• Apply: 코드로 인프라를 프로비저닝

규모에 따른 워크플로

개인의 워크플로

개인이 테라폼으로 일하는 방식

• Write : 프로비저닝하려는 목적에 따라 테라폼 코드를 작성
  • 개인 작업이더라도 반복적인 사용성을 고려하자.
  • 인수에 할당되는 값을 입력 변수화하고 반복적인 구조가 발생하는 경우 리소스 단위별로 반복문을 사용할지 다수의 리소스를 모듈화할지 결정한다.
• Plan : 적용하기 위한 실행 계획을 통해 리뷰
  • 테라폼의 Plan뿐 아니라, terraform fmt를 통해 코드 형태를 포멧팅하고 변경되는 리소스를 리뷰한다.
  • 또한 테라폼과 함께 동작하는 tfsec이나 terrascan 같은 보안 취약성 점검 툴 등을 활용하는 것도 좋은 방안이다.
• Apply : 코드로 실제 인프라를 프로비저닝
  • 실행 계획상으로는 정상이지만 실제 프로비저닝하는 단계에서 인수 값, 생성 순서, 종속성에 따라 오류가 발생할 수 있다.
  • 성공적인 완료를 위해 Write > Plan > Apply 단계를 반복하고 성공하는 경우 코드 관리를 위해 VCS에 코드를 병합한다.

다중 작업자 워크플로

• Write
  • 여러 작업자의 테라폼 코드가 충돌하지 않도록 VCS와 같은 형상관리 도구에 익숙해져야 한다.
  • 작업자는 작업 전에 미리 원격 저장소의 코드를 받고 깃에서는 브랜치를 활용해 개별적으로 작업한다.
  • 개인의 워크플로에서 고려한 변수화와 더불어 패스워드와 인증서 같은 민감 데이터가 포함되지 않도록 코드를 설계한다.
  • 또한 개인 작업 환경에서만 사용되는 변수는 공유하지 않는다.
  • 깃을 사용한다면 작업자 개인의 변수는 terraform.tfvars 에 선언하고 .gitignore에 추가해 개별적으로 테스트할 수 있는 환경을 구성할 수 있다
  • 이 단계에서 개별 작업자는 **작은 단위의 개별 워크플로(**Write > Plan > Apply)를 반복해야 한다.
  • 개별 작업 환경과 별개로 병합되는 코드가 실제 운영 중인 인프라에 즉시 반영되면 실행 후 발생할 오류 예측이 어려워 부담이 될 수 있다.
  • 이를 보완하기 위해 프로비저닝 대상의 환경을 검증과 운영, 또는 그 이상의 환경으로 구성 가능하도록 구조화한다.
  • 이때 사용하는 방식은 디렉터리 기반 격리와 깃 기반의 브랜치 격리다.
• Plan
  • 둘 이상의 작업자는 프로비저닝 이전에 팀원 간 리뷰를 거쳐 변경된 내역을 확인하고 공통 저장소에 병합해야 한다.
  • 리뷰 단계에서는 추가, 삭제, 수정된 내역을 관련 작업자가 검증, 질의, 배움의 단계를 거쳐 복기함으로써 코드 상태를 개선 유지하고 작업자 간에 의도를 공유한다.
  • 코드 자체 외에도 테라폼의 Plan 결과를 풀 리퀘스트 단계에 같이 제공하면 영향을 받는 리소스와 서비스 중단에 대한 예측이 더 쉬워진다.
  • CI 툴과 연계하거나 Terraform Cloud/Enterprise의 VCS 통합 기능으로 자동화할 수 있다.
• Apply
  • 코드가 최종 병합되면 인프라 변경이 수행됨을 알리고 변경되는 대상 환경의 중요도에 따라 승인이 필요할 수 있다.
  • 또한 변경하는 코드가 특정 기능, 버그 픽스, 최종 릴리즈를 위한 병합인가에 따라 이 단계에 추가로 코드 병합이 발생할 수 있다.
  • 관리하는 단위를 나누는 기준은 조직 R&R, 서비스, 인프라 종류 등으로 구분된다.

다수 팀의 워크플로

R&R이 분리된 다수 팀 또는 조직의 경우 테라폼의 프로비저닝 대상은 하나이지만 관리하는 리소스가 분리된다. 따라서, 단일 팀의 워크플로가 유지되고 그 결과에 대해 공유해야 하는 핵심 워크플로가 필요하다.

• Write
  • 대상 리소스가 하나의 모듈에서 관리되지 않고 R&R에 의해 워크스페이스가 분리된다.
  • 서로 다른 워크스페이스에서 구성된 리소스 데이터를 권한이 다른 팀에게 공유하기 위해, 저장된 State 접근 권한을 제공하고 output을 통해 공유 대상 데이터를 노출한다.
  • 테라폼 코드 작성 시 다른 워크스페이스에서의 변경 사항을 데이터 소스로 받아 오는 terraform_remote_state 또는 별도 KV-store를 활용하는 코드 구성이 요구된다.
  • 또한 관리 주체가 다른 곳에서 생긴 변경 사항의 영향을 최소화하도록 리모트 데이터 소스의 기본값을 정의하거나 코드적인 보상 로직을 구현하는 작업이 필요하다.
• Plan
  • 코드 기반으로 진행되는 리뷰는 반영되는 다른 팀의 인프라를 VCS상의 코드 리뷰만으로도 공유받고 영향도를 검토할 수 있다.
  • 병합을 승인하는 단계에 영향을 받는 다른 팀의 작업자도 참여해야 한다.
• Apply
  • 프로비저닝 실행과 결과에 대한 안내가 관련 팀에 알려져야 하므로 파이프라인 구조에서 자동화하는 것을 추천한다.
  • 실행 후의 영향도가 여러 팀이 관리하는 리소스에 전파될 수 있으므로 코드 롤백 훈련이 필요하다.
  • 생성된 결과에 다른 워크스페이스에서 참조되는 output 값의 업데이트된 내용을 다른 팀이 확인하는 권한 관리가 필요하다

격리 구조

• 테라폼은 파일이나 하위 모듈로 구분하더라고 동작 기준은 실행하는 루트 모듈에서 코드를 통합하고 하나의 State로 관리한다.
• 애플리케이션 구조가 모놀리식(+아키텍처)에서 MSA로 변화하는 과정은 테라폼의 IaC 특성과도 결부된다.

루트 모듈 격리 - 파일/디렉토리

• 단일 작업자가 테라폼으로 프로비저닝을 하는 많은 경우에 관리 편의성 및 배포 단순화를 위해 하나의 루트 디렉터리에 파일로 리소스들을 구분하거나, 디렉터리를 생성하고 하위에 구성 파일 묶음을 위치시켜 루트 모듈에서 하위 디렉터리를 모듈로 읽는 구조를 사용한다.
• 작업자가 관리하는 영역 또는 프로비저닝되는 리소스 묶음의 독립적인 실행을 위해 단일 루트 모듈 내의 리소스를 다수의 루트 모듈로 분리하고 각 모듈의 State를 참조하도록 격리한다.
• 관리적인 측면으로는 작업자들의 관리 영역을 분리시키고 깃 기준의 리모트 저장소도 접근 권한을 관리할 수 있다.
• 협업과 관련해 작업자별로 특정 루트 모듈을 선정해 구성 작업을 진행해 코드 충돌을 최소화하는 환경을 구성하고 인수인계 과정에서 리뷰하는 영역을 최소화할 수 있다.

환경 격리 - 깃 브랜치

• 서비스의 테스트, 검증, 운영 배포를 위해 테라폼으로 관리하는 리소스가 환경별로 격리되어야 한다면 디렉터리 구조로 분리하는 방안을 고려할 수 있다.
• 디렉터리별로 각 환경을 나누는 것은 개인의 관리 편의성은 높지만, 환경의 아키텍처를 고정시키고 코드 수준의 승인 체계를 만들기 위해서는 최종 형상에 대한 환경별 브랜치를 구성하기를 권장한다.
• 디렉터리 구조만으로는 환경에 따라 사용자를 격리할 수 없다. 이때 깃의 브랜치 기능을 활용하면 환경별로 구별된 작업과 협업이 가능하다.

프로비저닝 파이프라인 설계 - 깃허브

실제 서비스가 실행되는 대상을 프로비저닝하면 테라폼의 Plan과 Apply 과정상에 추가로 코드 검증, 실행 계획 검증, 실행 후 결과 확인과 같은 추가 동작을 자동화에 연계할 필요성이 생긴다. 주로 쓰이는 도구로는 개발 환경에서도 많이 사용되는 젠킨스, 깃허브의 코드 관리와 함께 사용 가능한 Github Action, 테라폼 환경만으로 구성하는 Terraform Cloud/Enterprise 환경이 있다. 

• 도구 : 젠킨스, Github Action, TFC/TFE
• Github Action : 깃허브 환경에서 제공하는 CI/CD 자동화 도구 - 워크플로를 설계하고 다양한 라이브러리들을 이용해 다양한 작업 구성이 가능
• Github Action은 별도의 State 저장소를 제공하지 않기 때문에 테라폼 실행으로 생성되는 State가 항상 초기화되어 프로비저닝 결과를 유지할 수 없다.

Terraform Cloud(TFC)

TEC는 팀과 조직 수준에서 간소화된 워크플로 구성 환경을 제공한다. Github Action과 같은 도구에 비해 자유도는 낮지만 VSC 연동, 변수 구성, State 저장소, RBAC, 원격 실행환경 등의 기능을 활용해 보다 적은 노력으로 워크플로를 설계한다.

Terraform Cloud 추가기능

Cost Estimation

비용 추정기능은 AWS, 애저, GCP 환경에서 예상되는 추정 비용을 테라폼 실행계획 생성 후 산출한다.

Run Task

Run Task 기능은 외부 서비스와 연계해 워크플로를 설계할 수 있다. 사용할수 있는 서비스 카테고리는 다음과 같다.

• Cost Management: 프로비저닝 되는 대상 인프라의 비용을 관리
• Drift Detection: 프로비저닝 된 인프라의 변경을 추적 및 관리
• Infrastructure Management: 인프라 자신을 관리하는 도구
• No Code/Low Code Workflow: IaC 구성을 위한 수동작업을 최소화
• Policy: 프로비저닝에 정책을 부여하고 관리하는 도구
• Security & Authentication: 프로비저닝의 보안 설정 사항 검증과 취약점 관리

Sentinel

Sentinel은 HashiCorp Enterprise 제품군과 통합되는 IaC 정책 시행 언어다.

Notifications

TEC 워크플로 단계에서 사용자는 알림을 받을 수 있다.