Terraform + Atlantis로 Azure 인프라 GitOps 구현 가이드

Docker로 Atlantis를 배포하여 Terraform 기반 인프라 GitOps 워크플로우를 구현하는 가이드

2025. 9. 10.
5개 태그

🔍 개요

Infrastructure as Code(IaC)와 GitOps는 현대 클라우드 인프라 관리의 핵심 패러다임입니다.
이 가이드에서는 TerraformAtlantis를 활용하여 Azure 인프라를 GitOps 방식으로 관리하는 방법을 다룹니다.

Atlantis란?

Atlantis는 Terraform을 위한 Pull Request 자동화 도구입니다. GitHub PR에서 직접 terraform planapply를 실행할 수 있게 해주며, 인프라 변경사항을 코드 리뷰 과정에 자연스럽게 통합합니다.

Mermaid diagram

주요 특징

  • PR 중심 워크플로우: Pull Request에서 바로 terraform plan/apply 실행
  • 실시간 협업: 인프라 변경사항을 동료와 실시간으로 리뷰
  • 안전한 배포: 승인 프로세스를 통한 통제된 인프라 변경
  • 간편한 설정: 복잡한 CI/CD 파이프라인 없이 바로 사용 가능

실습 환경 아키텍처

Mermaid diagram
테스트 환경 구성

Atlantis 접근 시 HTTP 사용:

  • 설정 간소화: 도메인과 별도 인증서 없이 Azure VM 공용 IP로 직접 접근

Docker를 이용한 Atlantis 배포:

  • 환경 격리: 호스트 시스템에 영향 없는 격리된 실행 환경
  • 간편한 배포: 단일 명령어로 Atlantis 서버 실행 및 관리
  • 빠른 시작: Kubernetes 클러스터 설정 없이 빠르게 설치 가능
운영환경 배포 시 고려사항

실제 운영환경에서는 다음 방식을 권장합니다

  • 정식 도메인 + SSL 인증서: Let's Encrypt 또는 공인인증서 사용
  • 온프레미스 Git 서버: GitLab CE/EE, GitHub Enterprise 등 내부 호스팅 Git 플랫폼 권장
  • Kubernetes + Helm: Atlantis를 AKS 클러스터에 Helm 차트로 배포
  • LoadBalancer/Ingress: Azure Load Balancer 또는 Application Gateway 활용

1. GitOps 아키텍처 설계

GitOps 철학과 Atlantis 워크플로우

GitOps는 Git 저장소를 중심으로 인프라와 애플리케이션을 관리하는 방법론입니다.
Atlantis는 이 개념을 Terraform 환경에서 쉽게 구현할 수 있게 해줍니다.

Mermaid diagram

Multi-Environment 전략 비교

환경 분리 전략

Atlantis에서는 두 가지 주요 환경 분리 방법을 제공합니다. 각각의 장단점을 비교하여 프로젝트에 적합한 방식을 선택하세요.
이 가이드에서는 Directory 기반 방식을 채택합니다.

구분Directory 기반Workspace 기반
구조environments/dev/, environments/prod/단일 디렉토리 + workspace
관리 복잡도🟢 낮음🟡 중간
상태 격리🟢 완전 격리🟡 논리적 격리
코드 중복🔴 높음 (환경별 중복)🟢 낮음 (공통 코드)
실수 위험성🟢 낮음 (물리적 분리)🔴 높음 (workspace 혼동)
권장 용도중소규모 프로젝트대규모 엔터프라이즈

2. Atlantis 서버 구성

사전 준비사항

실습을 시작하기 전에 다음 준비사항을 완료해 주세요.

체크리스트

1. Azure

  • 활성화된 Azure 구독 및 소유자 권한
  • Entra ID에서 Service Principal 생성 권한 (App Registration)
  • Azure CLI, VS Code, Git 설치

2. GitHub 계정

  • 최소 2개의 GitHub 계정 (PR 작성자 + 승인자)
  • Terraform 코드를 저장할 저장소 (저장소 소유자 또는 Collaborator 권한)
  • Personal Access Token 발급 (저장소 소유자 계정에서)

실습 진행 순서

이 실습은 다음 5단계 순서로 진행됩니다. 각 단계에서 생성된 정보를 다음 단계에서 바로 활용하므로 순서대로 따라해 주세요.

Mermaid diagram

1️⃣ Azure 인프라 구성

Atlantis 서버를 호스팅할 Azure VM을 생성하고 Docker를 설치합니다.

VM 생성

# 변수 선언
RESOURCE_GROUP="rg-atlantis-demo"
LOCATION="koreacentral"
VM_NAME="vm-atlantis"
VM_SIZE="Standard_B2s"
ADMIN_USERNAME="azureuser"

# 리소스 그룹 생성
az group create \
  --name "$RESOURCE_GROUP" \
  --location "$LOCATION"

# Ubuntu VM 생성 (password 인증)
az vm create \
  --resource-group "$RESOURCE_GROUP" \
  --name "$VM_NAME" \
  --image "Ubuntu2204" \
  --size "$VM_SIZE" \
  --admin-username "$ADMIN_USERNAME" \
  --authentication-type password \
  --admin-password "P@ssw0rd123!" \
  --public-ip-sku Standard

# HTTP/HTTPS 포트 열기 (Atlantis 웹 UI 및 GitHub 웹훅용)
az vm open-port \
  --resource-group "$RESOURCE_GROUP" \
  --name "$VM_NAME" \
  --port "4141"

# VM 공용 IP 주소 확인 (Atlantis 설정 및 GitHub 웹훅 URL에 사용)
az vm show \
  --resource-group "$RESOURCE_GROUP" \
  --name "$VM_NAME" \
  --show-details \
  --query "publicIps" \
  --output tsv

Docker 설치

VM에 SSH 접속 후 Docker를 설치합니다.

Docker 설치 스크립트
# 시스템 업데이트
sudo apt update && sudo apt upgrade -y
 
# Docker 설치를 위한 필수 패키지
sudo apt install -y apt-transport-https ca-certificates curl software-properties-common
 
# Docker GPG 키 추가
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
 
# Docker 저장소 추가
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
 
# Docker 설치
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io
 
# 현재 사용자를 docker 그룹에 추가
sudo usermod -aG docker $USER

2️⃣ Service Principal 및 GitHub 설정

Azure 인증을 위한 Service Principal과 GitHub 저장소를 설정합니다.

Service Principal 생성

Atlantis 서버가 Azure에 인증하여 리소스를 생성/수정/삭제할 수 있도록 Service Principal(서비스 계정)을 생성합니다.

왜 VM Managed Identity를 사용하지 않나요?

Atlantis는 Docker 컨테이너로 실행되며, 컨테이너 내부에서는 호스트 VM의 Managed Identity에 접근할 수 없습니다. 따라서 Service Principal을 생성하여 환경변수로 인증 정보를 전달해야 합니다.

# 변수 선언
SP_NAME="sp-atlantis-terraform"
SUBSCRIPTION_ID=$(az account show --query id -o tsv)

# 1단계: Service Principal 생성 (역할 할당 없이)
az ad sp create-for-rbac \
  --name "$SP_NAME" \
  --skip-assignment \
  --output json

# 출력된 정보를 저장해두세요 (appId, password, tenant 필요)

# 2단계: 구독에 대한 Contributor 역할 할당 (실패 시 아래 Portal 가이드 참고)
az role assignment create \
  --assignee $(az ad sp list --display-name "$SP_NAME" --query "[0].appId" -o tsv) \
  --role "Contributor" \
  --scope "/subscriptions/$SUBSCRIPTION_ID"

# 1단계 결과에서 다음 값들을 .env 파일에서 사용:
# - appId → ARM_CLIENT_ID
# - password → ARM_CLIENT_SECRET
# - subscriptionId → ARM_SUBSCRIPTION_ID
# - tenant → ARM_TENANT_ID
CLI로 역할 할당 실패 시 Portal 사용

위의 az role assignment create 명령어가 에러로 실패하는 경우, Azure Portal에서 수동으로 역할을 할당할 수 있습니다:

Portal에서 IAM 역할 할당 단계:

  1. Azure Portal구독 → 해당 구독 선택
  2. Access control (IAM)AddAdd role assignment
  3. Role: "Contributor" 선택 → Next
  4. Members: "User, group, or service principal" 선택
  5. Select members: 위에서 생성한 Service Principal 이름(sp-atlantis-terraform) 검색
  6. Review + assign 클릭하여 완료

GitHub 설정

GitHub Personal Access Token을 생성하고 Repository Webhook을 설정합니다.

Personal Access Token 생성

Atlantis가 GitHub API를 사용하기 위해 Personal Access Token이 필요합니다.

  1. GitHub Settings → Developer settings → Personal access tokens → Tokens (classic)
  2. "Generate new token" 클릭
  3. 다음 권한 선택:
    • repo (전체 저장소 액세스)
    • admin:repo_hook (웹훅 생성)
    • user (사용자 정보 읽기)
토큰 보안

생성된 토큰은 이후 Altalntis 환경변수로 사용됩니다. 외부에 노출되지 않도록 안전한 곳에 저장하시기 바랍니다.

GitHub Repository 생성

Terraform 코드를 저장하고 Atlantis와 연동할 GitHub 저장소를 생성합니다.

  1. GitHub 저장소 생성:

    • GitHub → 우측 상단 "+" 아이콘 → "New repository"
    • Repository name: terraform-atlantis-demo (또는 원하는 이름)
    • Description: "Terraform + Atlantis GitOps Demo"
    • Public 선택 (GitHub 무료 계정에서 Private 저장소는 브랜치 보호 규칙 제한으로 Atlantis 승인 워크플로우가 제약됨)
    • "Add a README file" off (나중에 실습용 코드 push 시 충돌 방지)
    • "Add .gitignore" No .gitignore (실습용 코드에 이미 포함되어 있음)
    • "Create repository" 클릭
  2. 저장소 초기 설정 확인:

    • 생성된 저장소의 URL 확인: https://github.com/your-username/terraform-atlantis-demo
    • 이 URL은 환경변수 ATLANTIS_REPO_ALLOWLIST에서 사용됩니다
  3. 협업자 초대 (PR 승인 워크플로우 테스트용):

    • Repository → Settings → Manage access → "Add people"
    • 두 번째 GitHub 계정을 Collaborator로 초대 (Write 권한)
    • 초대받은 계정에서 이메일 또는 GitHub 알림을 통해 초대 수락
Repository Webhook 설정

Atlantis 서버가 GitHub PR 이벤트를 받기 위해 Webhook을 설정합니다.

  1. Terraform 저장소 → Settings → Webhooks
  2. "Add webhook" 클릭
  3. 설정값:
    • Payload URL: http://your-vm-public-ip:4141/events
    • Content type: application/json
    • Secret: 임의의 안전한 문자열 생성 (예: webhook-secret-12345)
    • SSL verification: Disable (테스트 환경용)
    • Let me select individual events: "Pull requests", "Issue comments", "Pushes" 선택
SSL Verification 비활성화

테스트 환경에서는 HTTP를 사용하므로 "Disable SSL verification" 옵션을 체크해야 합니다.
운영환경에서는 반드시 HTTPS와 유효한 SSL 인증서를 사용하세요.

3️⃣ 환경변수 파일 구성

이제 Azure VM에 SSH로 접속하여 앞서 생성한 모든 설정 정보를 .env 파일로 통합합니다.

VM 접속 및 .env 파일 생성
# VM에 SSH 접속
ssh azureuser@your-vm-public-ip
 
# .env 파일 생성
vi .env

아래 환경변수들을 .env 파일에 입력하세요:

환경변수 (.env)
# GitHub 설정
ATLANTIS_GH_USER=your-github-username
ATLANTIS_GH_TOKEN=ghp_xxxxxxxxxxxxxxxxxxxx
ATLANTIS_GH_WEBHOOK_SECRET=webhook-secret-12345
 
# Atlantis 서버 설정
ATLANTIS_ATLANTIS_URL=http://your-vm-public-ip:4141
ATLANTIS_REPO_ALLOWLIST=github.com/your-org/*
 
# Terraform 설정
ATLANTIS_DEFAULT_TF_VERSION=v1.12.2
TF_VAR_admin_password=P@ssw0rd123!
 
# Azure 인증 정보
ARM_CLIENT_ID=your-service-principal-app-id
ARM_CLIENT_SECRET=your-service-principal-password
ARM_SUBSCRIPTION_ID=your-azure-subscription-id
ARM_TENANT_ID=your-azure-tenant-id
 
# PR 승인 정책 (Apply 실행 조건 설정)
ATLANTIS_REPO_CONFIG_JSON={"repos":[{"id":"/.*/","apply_requirements":["approved","mergeable","undiverged"],"allowed_overrides":["apply_requirements","workflow"],"allow_custom_workflows":true}]}
환경변수 주의사항

변수명은 반드시 위와 동일하게 사용해야 합니다. 변수명 변경 시 Atlantis가 인식하지 못합니다.

VM 패스워드 관련: TF_VAR_admin_password처럼 TF_VAR_ 접두사가 붙은 환경변수는 Terraform에서 자동으로 변수로 인식됩니다.
테스트 환경에서 Github Public 저장소를 사용하므로 패스워드를 terraform.tfvars 파일에 저장하면 외부로 노출됩니다.
따라서 위와 같이 Atlantis에서 환경변수로 정의합니다.

4️⃣ Atlantis 서버 실행

Atlantis 서버 시작
# 환경변수 파일 권한 설정
chmod 600 .env
 
# Atlantis 데이터 디렉토리 생성 및 권한 설정
mkdir -p ~/atlantis-data
chmod 777 ~/atlantis-data
 
# Docker run으로 Atlantis 시작
docker run -d \
  --name atlantis \
  -p 4141:4141 \
  --env-file .env \
  -v ~/atlantis-data:/atlantis-data \
  -e ATLANTIS_DATA_DIR=/atlantis-data \
  -e ATLANTIS_PORT=4141 \
  --restart unless-stopped \
  ghcr.io/runatlantis/atlantis:latest
 
# 컨테이너 상태 확인
docker ps | grep atlantis
 
# 로그 확인 (실시간)
docker logs -f atlantis
 
# 헬스체크 확인
curl -f http://localhost:4141/healthz
 
# Atlantis 웹 UI 접속 확인
curl -s http://localhost:4141 | grep -i "atlantis"

5️⃣ Terraform State 저장소 생성

Terraform State 파일을 저장할 Azure Storage Account를 미리 생성합니다.
이는 Bootstrap 단계로, Terraform 자체로는 순환 참조 문제가 발생하므로 Azure CLI로 수행합니다.

왜 Azure CLI로 생성하는가?

순환 참조 문제 해결: Terraform State를 저장할 Storage Account를 Terraform으로 생성하면, 그 Terraform 코드의 State는 어디에 저장할까요? 이런 Bootstrap 리소스는 Azure CLI로 미리 생성하는 것이 모범 사례입니다.

# 변수 선언 (1단계에서 생성한 리소스 그룹 재사용)
RESOURCE_GROUP="rg-atlantis-demo"
LOCATION="koreacentral"
STORAGE_ACCOUNT="satfstate$(openssl rand -hex 4)"
CONTAINER_NAME="tfstate"

# Storage Account 생성 (보안 설정 포함)
az storage account create \
  --name "$STORAGE_ACCOUNT" \
  --resource-group "$RESOURCE_GROUP" \
  --location "$LOCATION" \
  --sku "Standard_LRS" \
  --min-tls-version "TLS1_2" \
  --allow-blob-public-access false

# tfstate 전용 컨테이너 생성
az storage container create \
  --name "$CONTAINER_NAME" \
  --account-name "$STORAGE_ACCOUNT" \
  --public-access off

# Service Principal에 Storage 권한 부여 (Terraform State 파일 접근용)
SP_OBJECT_ID=$(az ad sp list --display-name "sp-atlantis-terraform" --query "[0].id" -o tsv)
az role assignment create \
  --assignee "$SP_OBJECT_ID" \
  --role "Storage Blob Data Contributor" \
  --scope "/subscriptions/$(az account show --query id -o tsv)/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.Storage/storageAccounts/$STORAGE_ACCOUNT"

# 생성된 정보 출력 (Terraform backend 설정에서 사용)
echo "리소스 그룹: $RESOURCE_GROUP"
echo "Storage Account: $STORAGE_ACCOUNT"
echo "컨테이너: $CONTAINER_NAME"
State Lock 자동 지원

Azure Storage Account는 Terraform에서 자동으로 Blob Lease 기반 State Lock을 제공합니다.
별도 설정 없이도 동시 terraform apply 실행이 차단됩니다.

참고 문서: Microsoft Learn - Azure Storage에 Terraform 상태 저장에서 자세한 내용을 확인할 수 있습니다.

3. 실습용 Terraform 코드 준비

GitHub Repository Clone

실습을 위한 완성된 Terraform 코드를 다운로드하고 개인 저장소에 업로드합니다.

실습 저장소 Clone 및 Remote 설정
# 실습용 Terraform 코드 다운로드
git clone https://github.com/Seunghwan-You/atlantis_azure.git
cd atlantis_azure
 
# 저장소 구조 확인 (Windows)
tree /F
 
# 저장소 구조 확인 (Bash)
tree -L 3
 
# 원본 remote 제거 및 개인 저장소로 변경
git remote remove origin
git remote add origin https://github.com/your-username/terraform-atlantis-demo.git
 
# 코드를 개인 저장소에 push
git push -u origin main
실습 환경별 설정 안내

이 저장소에는 environments/devenvironments/prod 두 개의 환경이 구성되어 있습니다.

Dev 환경 (environments/dev/):

  • 모든 리소스 생성 코드가 활성화되어 실제 리소스를 생성합니다
  • 실습과 테스트 목적으로 사용하세요

Prod 환경 (environments/prod/):

  • 원활한 실습을 위해 main.tf에서 리소스 생성 코드가 주석 처리되어 있습니다

본 가이드는 Dev 환경을 기준으로 진행하며, Prod 환경은 실습 완료 후 개별적으로 테스트하시기 바랍니다.

저장소 구조

프로젝트 구조
atlantis_azure/
│  .gitignore              
│  atlantis.yaml               # Atlantis 설정 파일  
│  README.md                   # 프로젝트 설명

├─environments/                # 환경별 설정
│  ├─dev/                      # 개발 환경
│  │      main.tf              # 메인 Terraform 설정
│  │      terraform.tfvars     # 환경별 변수
│  │      variables.tf         # 변수 정의
│  │
│  └─prod/                     # 운영 환경
│          main.tf
│          terraform.tfvars
│          variables.tf

└─modules/                     # 재사용 가능한 모듈
    ├─networking/              # VNet/Subnet 모듈
    │      main.tf
    │      outputs.tf
    │      variables.tf

    └─vm/                      # VM 생성 모듈
            main.tf
            outputs.tf
            variables.tf

주요 구성 요소

모듈 설계:

  • VM 모듈: Ubuntu 22.04 기반 VM 생성
  • 네트워킹 모듈: VNet, Subnet, NSG 구성
  • 환경별 분리: dev/prod 독립 관리

Backend 구성:

  • Azure Storage Account 기반 State 관리
  • 환경별 별도 State 파일 (dev.tfstate, prod.tfstate)
  • State Lock 자동 지원

atlantis.yaml 설정 확인

atlantis.yaml
version: 3
projects:
  - name: dev
    dir: environments/dev    
    apply_requirements: [approved]
    autoplan:
      when_modified: ["**/*.tf", "**/*.tfvars", "../../modules/**/*.tf"]      
      enabled: true    
  - name: prod
    apply_requirements: [approved]
    dir: environments/prod    
    autoplan:
      when_modified: ["**/*.tf", "**/*.tfvars", "../../modules/**/*.tf"]
      enabled: true  
  • 프로젝트 분리: dev/prod 환경을 개별 프로젝트로 관리
  • Auto Plan: .tf, .tfvars 파일이나 모듈 변경 시 자동으로 terraform plan 실행
  • 승인 필수: apply 실행 전 Pull Request 승인 필요
  • 모듈 감지: modules/ 디렉토리 변경 시 연관된 환경에서 AutoPlan 실행

4. 초기 인프라 배포

첫 번째 배포 준비

Atlantis는 GitOps 도구이므로 모든 배포가 Pull Request를 통해 이루어집니다.

초기 배포

atlantis.yaml파일의 설정에 따라 인프라 배포시 협업자 승인이 필요합니다.

초기 배포 단계:

  1. 브랜치 생성 (예: feature/initial-deploy)
  2. Pull Request 생성
  3. Atlantis Plan 확인
  4. 협업자 승인 (GitHub PR Approve)
  5. atlantis apply 실행 (승인 후 배포)

초기 배포 단계별 가이드

1단계: 기능 브랜치 생성 및 Storage Account 정보 업데이트

기능 브랜치 생성
# 기능 브랜치 생성
git checkout -b feature/initial-deploy

다음으로 environments/dev/main.tfenvironments/prod/main.tf의 backend 설정을 앞서 생성한 스토리지 계정 정보로 수정합니다.

백엔드 설정 예시:

Terraform 백엔드 설정 예시

2단계: 변경사항 Push 및 PR 생성

변경사항 커밋 및 Push
# 변경사항 커밋
git add .
git commit -m "feat: Add initial infrastructure configuration"
 
# 원격 저장소에 push (업스트림 설정)
git push -u origin feature/initial-deploy

3단계: GitHub에서 Pull Request 생성

  1. GitHub 저장소 → "Pull requests" → "New pull request"
  2. base: main ← compare: feature/initial-deploy
  3. 제목: "Initial Infrastructure Deployment"
  4. "Create pull request" 클릭
  5. PR 생성 후 우측 상단에 "Reviewers" → 협업자 계정 선택 (승인자 지정)

4단계: Plan 확인 및 승인

  1. 자동 Plan 실행: PR 생성 시 Atlantis가 자동으로 terraform plan 실행
  1. Plan 결과 검토: PR 코멘트에서 생성될 리소스 확인
  1. 협업자 계정으로 Github 로그인 후 Approve 진행:
    • Files changedReview changesApprove

5단계: Apply 실행 및 배포

  1. Apply 실행: PR에 atlantis apply 코멘트 작성하여 배포 실행
  • 승인이 완료 되지 않았을 경우 apply가 실패하고 승인 필수 메시지가 표시됨
  • 승인 완료 후 apply 실행 및 배포 완료
  1. Apply 성공 확인: 모든 리소스가 성공적으로 생성되었는지 확인
  1. PR Merge: Apply 성공 후 브랜치 Merge 진행
  1. 브랜치 정리: "Delete branch" 버튼으로 feature/initial-deploy 브랜치 삭제
초기 인프라 배포 완료

첫 번째 GitOps 배포를 완료했습니다.

  • Azure 리소스 생성: VM, VNet, Storage Account 등이 생성됨
  • State 관리: Terraform State가 Azure Storage에 안전하게 저장됨
  • 협업 워크플로우: PR → Plan → 승인 → Apply → Merge
  • Git 히스토리: 모든 인프라 변경사항이 Git에 기록됨

이제 초기 인프라가 배포되었습니다. 다음 단계로 브랜치 보호를 강화하여 더욱 안전한 GitOps 환경을 구축해보겠습니다.

5. 브랜치 보호 강화

초기 배포가 완료된 후, 운영 환경의 안전성을 높이기 위해 GitHub 브랜치 보호 규칙을 설정합니다.

GitHub 브랜치 보호 규칙 설정

1단계: 보호 규칙 생성

  1. GitHub 저장소SettingsBranches
  2. "Add classic branch protection rule" 클릭
  1. Branch name pattern: main 입력

2단계: 보호 규칙 구성

다음 옵션들을 체크하세요:

브랜치 보호 규칙 설정
✅ Require a pull request before merging
  ✅ Require approvals (1명 이상)
  ✅ Dismiss stale PR approvals when new commits are pushed
  
✅ Require status checks to pass before merging  
  ✅ Require branches to be up to date before merging
  📋 Status Check 추가: 검색창에 "atlantis" 입력 → "atlantis/apply" 선택
  
✅ Do not allow bypassing the above settings

브랜치 규칙 설정 예시:

Atlantis Apply Status Check 설정
Status Check 효과

이제 atlantis apply가 성공적으로 완료되어야만 "Merge pull request" 버튼이 활성화됩니다. Apply 실패 시 Merge가 불가능하여 완전한 GitOps 보안이 보장됩니다.

6. 실제 워크플로우 테스트

인프라 변경 프로세스

Mermaid diagram

실제 워크플로우 단계별 가이드

브랜치 보호 규칙 설정이 완료된 후, 실제 인프라 변경을 통해 전체 워크플로우를 테스트해보겠습니다.

1단계: 브랜치 생성 및 VM 태그 수정

기능 브랜치 생성
# 메인 브랜치에서 새 브랜치 생성
git checkout main
git pull origin main
git checkout -b feature/add-vm-tags

VM 태그 수정 예시:

VM 태그 수정
변경사항 커밋 및 Push
# 변경사항 확인
git status
git diff
 
# 커밋 및 푸시
git add .
git commit -m "feat: Add comprehensive tags to VM resources"
 
git push -u origin feature/add-vm-tags

2단계: PR 생성 및 승인자 지정

앞서 실습한 과정과 동일하게 진행합니다:

  1. PR 생성: "Compare & pull request" → 제목 및 설명 작성
  2. 승인자 지정: 우측 "Reviewers" → 협업자 계정 선택
  3. Auto Plan 실행: Atlantis가 자동으로 Plan 실행 및 결과 코멘트 확인
  1. 협업자 승인: Files changed → Review changes → Approve

3단계: 브랜치 보호 강화 효과 확인

Apply 실행 전 - Merge 버튼 비활성화:

승인이 완료되어도 atlantis apply를 실행하지 않으면 Merge 버튼이 비활성화됩니다.

Apply 실행 전 Merge 버튼 비활성화

Apply 실행:

PR 코멘트에 atlantis apply 명령어를 작성하여 배포를 실행합니다.

Apply 완료 후 - Merge 버튼 활성화:

atlantis apply가 성공적으로 완료되면 Merge 버튼이 활성화됩니다.

Apply 완료 후 Merge 버튼 활성화
브랜치 보호 강화

GitOps 보안 환경이 구축되었습니다:

  • 승인 후 Apply: PR 승인 완료 후에만 atlantis apply 실행 가능
  • Apply 후 Merge: atlantis apply 성공 후에만 브랜치 병합 가능
  • 완전 자동화: 모든 보안 검증이 자동으로 진행
  • 실수 방지: Apply 실패 시 Merge 자동 차단
운영환경 인프라 변경 시 주의사항
  • 배포 시간 제한: 업무시간 또는 점검 시간대로 제한
  • 모니터링 강화: 배포 후 즉시 시스템 상태 확인
  • 롤백 준비: 문제 발생 시 즉시 롤백할 수 있는 체계 구축
  • 변경 기록: 모든 운영환경 변경사항에 대한 상세한 로그 유지

주요 Atlantis 명령어

PR에서 사용할 수 있는 주요 명령어들입니다.

Atlantis 명령어 가이드
# 계획 실행 (자동으로도 실행되지만 수동 실행 가능)
atlantis plan
 
# 특정 환경에 대한 계획
atlantis plan -d environments/dev
 
# 적용 실행 (승인된 PR에서만 가능)
atlantis apply
 
# 특정 환경에 대한 적용
atlantis apply -d environments/dev
 
# 도움말 확인
atlantis help
 
# 계획 잠금 해제 (필요시)
atlantis unlock

✨ 결론

Docker 기반의 Atlantis 서버로 GitOps 워크플로우를 간단하게 구축해보았습니다.
PR 기반 인프라 변경 리뷰를 통해 안전한 협업이 가능하며, 환경별 격리와 모듈화된 Terraform 코드로 확장성 또한 확보하였습니다.

운영 환경에서는 HTTPS 인증서 적용, Azure Monitor를 통한 모니터링 강화, Key Vault 기반 시크릿 관리 등을 추가하여 enterprise급 GitOps 환경으로 발전시킬 수 있습니다.


이 포스트는 2025년 8월 기준 최신 Terraform v1.12.2 및 Atlantis 공식 문서를 바탕으로 작성되었습니다. 최신 정보는 Terraform 공식 문서, Atlantis 공식 문서, 그리고 Azure 공식 문서에서 확인하실 수 있습니다.

댓글

0/500
댓글을 불러오는 중...