✍ Posted by Immersive Builder Seong
1. Terraform Enterprise
출시 배경
소규모의 팀 또는 조직이 아닌 2개 이상의 팀 또는 조직 등 기업 단위에서 사용하고 관리하기 편리하도록 상용화한 제품이 HCP(Terraform Cloud, SaaS)와 Terraform Enterprise(TFE, 설치형) 입니다.
주요 특징
▢ 코드 기반 인프라 구성 및 관리 통합
▶ 모든 인프라 환경의 리소스를 코드 기반으로 관리
▶ HCL을 사용한 인프라 리소스 프로비저닝, 종속성 제거
▢ GitOps 환경 구축
▶ IT 운영자/개발자를 포함하여 코드 기반의 인프라 구성 협업
▶ 재사용이 가능한 코드
▢ 표준화, 자동화되고 일관된 워크플로우
▶ 효율적이고 반복 가능하며 예측 가능하고 표준화된 배포
▶ 규정 준수 배포 보장 및 시행
▢ 셀프 서비스 가속화
▶ VCS, ITSM, CI/CD와 통합되는 인프라 자동화
▶ 코드 기반 셀프 서비스 인프라로 조직의 모든 팀으로 확장
주요 기능
- VCS Connection : 주요 VCS들과 연동하여 구성 파일의 자동 버전 관리 및 실행을 허용하여 GitOps를 실현함
- Secure Varibales Storage : 배포에 필요한 인프라의 ID/PW/변수 값을 중앙저장소에 저장 및 선언하고, 암호화하여 안전하게 관리함
- Sentinel Policy : 보안 정책을 코드로 정의하여(PaC) 인프라가 프로비저닝될 때 사용자가 원하는 거버넌스를 시행할 수 있음
- Audit Logging : TFE로 프로비저닝한 모든 프로바이더와 서비스에 대해 수행된 모든 API 호출을 추적하며 저장함
- Team Management : 특정 워크스페이스에 접근할 수 있는 역할과 팀/사용자를 정의하여(RBAC) 고도화된 보안 환경을 구축함
- Private Module Registry : 조직에서만 사용하던 안정적인 코드를 모듈화하여 공유함으로써 다른 팀/구성원이 효과적으로 재사용이 가능함
- Cost Estimation : 퍼블릭 클라우드(AWS/Azure/GCP)에 배포 시 자원에 대한 비용 정보를 보여주며 비용 예측 사용량을 확인 가능함
- Drift Detection : 인프라와 테라폼에 정의된 구성 간에 편차를 감지하고 알림 및 복구 조치를 수행함
Terraform Open Source vs Terraform Enterprise
| Terraform Open Source(OSS) | Terraform Enterprise(TFE) |
| 자체 Terraform 환경 및 협업 프로세스 구축 및 관리 필요 | State File 관리, 팀/조직 관리, 모듈화, 배포 및 변경 이력 등 통합 관리 제공 |
| 클라우드 크리덴셜, 중요 시크릿 정보가 코드 및 State File에 노출 | Variable로 시크릿 저장/관리, 코드 및 State File에 암호화, 유출 방지 |
| 조직의 보안 규정, 거버넌스 기준 내에서 배포 통제 어려움 | 코드로 보안 규정 및 거버넌스 통제 |
| 사용자/팀 확대 시 높은 운영 비용과 위험 요소 급증 | 사용자/팀 확대 운영 편의성, 엔터프라이즈 수준의 가용성 제공 |
2. VCS-driven Workflow
Workflow 방식
IaC 환경 구성 시 중요한 부분은 단순한 시스템/인프라 환경이 아닌 인프라 환경을 배포/실행하는 워크플로우입니다.
기업/조직의 IaC 표준화 이후 사용 환경을 확대할 시, 다양한 워크플로우 방식이 고려되어야 하며 시스템 환경은 단순화 및 중앙화되어야 합니다.
| Workflow | IaC 시스템 분리 구성 | IaC 시스템 단일 구성 |
| CLI-Driven | - IaC 코드를 개별 IaC 시스템에 복제 후 각각 CLI 로컬 환경에서 배포 및 상태 파일을 관리 | - IaC 코드를 개별 IaC 시스템에 복제 후 실행 시 IaC 시스템으로 배포 및 상태파일/로그/이력 등을 전송하고 중앙 관리 |
| API-Driven | - 미지원 | - 전체 기능 지원 - GUI에서 사용할 수 있는 모든 기능에 API 호출이 가능하며 다른 솔루션과 연계하여 실행 지원 |
| UI-Driven | - 미지원 | - IaC 코드 변경 이벤트 발생 시 수동/자동 실행 지원 |
| VCS-Driven | - 미지원 - 3rd Party 연동 필요 |
- VCS와 Terraform Workspace 연동 - Git Commit/PR 코드 변경 시 자동 실행 지원 |
| SDK-Driven | - 미지원 | - Golang, Python 및 .NET에서 API 실행 방식 지원 |
VCS-driven Workflow
VCS(Git Repository)와 TFE 워크스페이스를 연동하여 변경 사항이 발생할 시 자동으로 감지하고 실행을 트리거하도록 워크플로우를 구성합니다. VCS-driven 워크플로우는 팀/조직 간에 레포지토리를 공유함으로써 코드 리뷰/승인/배포/병합/릴리즈 등 협업을 유연하게 가능하게 합니다.
Step1. Git Repo 생성
Step2. Cloud 블록 추가
TFE 조직 및 워크스페이스 연동을 위한 cloud 블록을 추가 작성합니다.
HCP의 호스트네임은 "app.terraform.io" 이고, TFE의 호스트네임은 설치한 서버에 적용한 서비스 도메인입니다.
(Step6 단계에서 VCS 연동을 확인한 이후에는 cloud 블록을 주석 처리 또는 삭제하여도 무방합니다.)
Step3. OAuth Apps 설정
TFE 워크스페이스를 새로운 앱으로 등록하고 인증 처리를 위한 Client ID/Secret을 발급합니다.
Step4. TFE 워크스페이스와 VCS 통합 연동
Step5. AWS 연동
- AWS_ACCESS_KEY_ID : IAM User ACCESS KEY
- AWS_SECRET_ACCESS_KEY : IAM User SECRET KEY
Step6. VCS 연동 확인
TFE 워크스페이스와 VCS 연동이 완료되면 구성 파일에 대한 실행 계획이 자동으로 생성됩니다.
그리고 실행이 완료되기 전까지 워크스페이스는 잠금 상태(Locked)가 됩니다.
실행을 완료하여 워크스페이스를 잠금 해제(unlock) 합니다.
Step7. Pull Request & Merge PR
모듈의 인스턴스 타입을 "t2.micro", CPU 아키텍처를 "amd64"로 변경하고 적용하기 위해 별도의 변수 파일(terraform.auto.tfvars)을 생성합니다.
그리고 작업 브랜치를 Git 레포지토리로 업데이트한 후 PR을 생성하여 워크플로우의 변화를 모니터링합니다.
- terraform.auto.ftvars
$ git checkout -b use_auto_vars_file
Switched to a new branch 'use_auto_vars_file'
$ git add . && git commit -m "Add auto.tfvars file" && git push -u origin use_auto_vars_file
PR을 생성하자마자 변경 사항에 대한 실행 계획이 자동으로 실행됩니다.
하지만 작업 브랜치(use_auto_vars_file)에서 요청한 PR의 실행 계획과 메인 브랜치(main)의 구성 파일이 다르기 때문에 병합(merge)이 수행되기 전까지 변경 사항을 반영(apply)할 수 없습니다. 따라서 팀 구성원들은 PR을 승인하고 병합하기 전에 충분히 검토를 수행할 수 있으며, 이 과정을 통해 인프라 변경 사항에 대한 팀간 협업이 가능해집니다.
(물론 필요에 따라 Auto-apply 옵션을 활성화하여 디폴트 브랜치에 push 이벤트를 통한 실행 계획의 결과가 성공할 시 자동으로 변경 사항을 반영하도록 설정할 수도 있습니다.)
그리고 PR이 열려있는 상태에서 작업 브랜치에서 commit/push하면 Run List에 새로운 실행 계획이 추가됩니다.
PR을 승인하고 브랜치를 병합합니다.
마지막으로 인프라 변경 사항을 배포하여 리소스에 반영합니다.
리소스 반영 이후 상태 파일은 워크스페이스의 States에 보관됩니다.
🤔 여기서 잠깐 !!
만약 플랜은 정상적으로 실행이 되는데 "Error fetching plan data" 에러로 플랜의 실행 결과가 출력되지 않는다면 어떻게 해결할까요 ?
워크스페이스의 "User Interface" 설정을 'Structured Run Output'에서 'Console UI'로 변경하여 트러블슈팅합니다.
그리고 플랜을 재실행하면 다음과 같이 콘솔 화면과 동일한 실행 결과가 출력됩니다.
이번 예시는 data 블록의 특정 리소스 속성 값을 불러오지 못해서 발생한 에러로 부득이하게 플랜의 실행 결과를 확인하기 위해 사용한 방법입니다.
워크스페이스의 기본 설정은 'Structured Run Output'으로 설정할 것을 권장합니다.
Step8. TFE 워크스페이스 삭제
TFE vs Atlantis
| Terraform Enterprise(TFE) | Atlantis |
| 인프라 관리 자동화를 위한 테라폼 워크플로우 도구 | |
| 상용 | 오픈소스 |
| Merge → Apply | Apply → Merge |
| 브랜치 병합 이후에 배포하도록 강제함으로써 리소스와 코드 간 일관성 유지 |
배포하지 않아도 브랜치 병합이 가능하며 병합 이후에는 배포가 불가능함 따라서 리소스와 코드 간 불일치 발생 가능성 존재 |
| VCS 통합 연동 및 관리가 쉬움 | VCS 통합 환경 구축 및 유지보수를 직접 관리할 필요성 |
| 플랫폼 비용 발생 | IaaS 유지비용 발생 |
[출처]
1) HashiCorp, IaC 기반의 안전한 인프라 현대화 방안
2) https://developer.hashicorp.com/terraform/cloud-docs/vcs
Connecting VCS Providers - HCP Terraform | Terraform | HashiCorp Developer
Learn how to connect a version control system (VCS) to your organization to integrate HCP Terraform into your development workflow and access additional features.
developer.hashicorp.com
3) https://developer.hashicorp.com/terraform/tutorials/cloud-get-started/cloud-vcs-change
Use VCS-driven workflow | Terraform | HashiCorp Developer
Update a workspace to use the version control system-driven workflow with GitHub. Queue a speculative plan by opening a pull request.
developer.hashicorp.com
'IaC > Terraform' 카테고리의 다른 글
| [Terraform] 8-1. What is OpenTofu ? (0) | 2024.08.04 |
|---|---|
| [Terraform] 7-1. Karpenter controller를 EKS Fargate로 실행하기 (0) | 2024.07.28 |
| [Terraform] 5-1. GitHub와 Atlantis를 연동하여 Terraform 자동화 환경 구축하기 (1) | 2024.07.14 |
| [Terraform] 4-2. 다중 리전에서 동작하는 S3 버킷 구성하기 (0) | 2024.07.07 |
| [Terraform] 4-1. AWS S3와 DynamoDB를 활용하여 백엔드 구성하기 (0) | 2024.07.07 |
