데보션앱 소개페이지 바로가기
로그인 선택

신고하기

CLOSE
신고사유 (대표 사유 1개)
상세내용 (선택)
0/200
  • 신고한 게시글은 더 이상 보이지 않습니다.
  • 이용약관과 운영정책에 따라 신고사유에 해당하는지 검토 후 조치됩니다.
  • 허위 신고인 경우, 신고자의 서비스 이용이 제한될 수 있으니 유의하시어 신중하게 신고해 주세요.
(이 회원이 작성한 모든 댓글과 커뮤니티 게시물이 보이지 않고, 알림도 오지 않습니다.)

미리보기

커뮤니티

      1,234

      badge 23.06.15

      글 등록

      카테고리를 선택해주세요.

      DEVOTEE를 활성화 시키면
      지금 작성한 커뮤니티 글에 대해 1개의 댓글을 달아줍니다.

      버튼을 누르면 글 수정 시 ChatGPT가 작성한 댓글이 수정됩니다.

      임시저장함에 저장되었습니다. 저장일시 : 2022.5.17 14:29:08

      임시저장함

      제목을 선택하시면 이어서 작성이 가능하며,
      최대 20건까지 저장합니다.
      컨텐츠 유형, 제목, 저장일시, 삭제로 이뤄진 임시저장 목록
      컨텐츠 유형 제목 저장일 삭제

      데보션 블로그 게재 요청

      CLOSE
      • *
      • *

      본인인증

      효율적인 데보션 서비스 이용 및
      고객님의 소중한 개인정보보호를 위해
      본인인증을 진행해주세요. 본인인증 미 진행 시 로그인이 제한됩니다.
      본인인증 실패

      본인인증 로그인에 실패하였습니다.
      회원이 아니시거나 본인인증 등록이
      완료되지 않은 사용자입니다.

      회원정보 연결

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

      SkyOps 25.09.16
      2,808 5 1
      DEVOTEE 요약
      이 가이드는 Infrastructure as Code(IaC)와 GitOps를 기반으로 Terraform 및 Atlantis를 활용해 Azure 인프라를 관리하는 방법을 설명합니다. 특히 이를 통해 자동화된 PR 워크플로우(코드 리뷰, 승인 과정을 통한 안전한 인프라 변경)를 구현하며, 디렉토리 기반 환경 분리 전략(dev/prod)와 GitHub 브랜치 보호 규칙 설정을 활용해 더욱 안정적인 실습 환경과 운영 환경을 확보합니다. 최종적으로, GitOps의 핵심 원칙인 PR → Plan → 승인 → Apply → Merge의 단계별 프로세스를 준수하며, 브랜치 보호 및 승인 체계를 통해 협업 효율성을 증대시킵니다.

      🔍 개요

      Infrastructure as Code(IaC)와 GitOps는 현대 클라우드 인프라 관리의 핵심 패러다임입니다.

      이 가이드에서는 Terraform과 Atlantis를 활용하여 Azure 인프라를 GitOps 방식으로 관리하는 방법을 다룹니다.

      Atlantis란?

      Atlantis는 Terraform을 위한 Pull Request 자동화 도구입니다.

      GitHub PR에서 직접 terraform plan과 apply를 실행할 수 있게 해주며, 인프라 변경사항을 코드 리뷰 과정에 자연스럽게 통합합니다.

      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를 설치합니다.

      # 시스템 업데이트
      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) → Add → Add 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에 SSH 접속
      ssh azureuser@your-vm-public-ip
       
      # .env 파일 생성
      vi .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 서버 실행

      # 환경변수 파일 권한 설정
      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 코드를 다운로드하고 개인 저장소에 업로드합니다.

      # 실습용 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/dev와 environments/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 설정 확인

      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.tf와 environments/prod/main.tf의 backend 설정을 앞서 생성한 스토리지 계정 정보로 수정합니다.

      백엔드 설정 예시:

      Terraform 백엔드 설정 예시


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

      # 변경사항 커밋
      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 확인 및 승인

      • 자동 Plan 실행: PR 생성 시 Atlantis가 자동으로 terraform plan 실행



      • Plan 결과 검토: PR 코멘트에서 생성될 리소스 확인



      1. 협업자 계정으로 Github 로그인 후 Approve 진행:

        • Files changed → Review changes → Approve



      5단계: Apply 실행 및 배포

      • Apply 실행: PR에 atlantis apply 코멘트 작성하여 배포 실행



      • 승인이 완료 되지 않았을 경우 apply가 실패하고 승인 필수 메시지가 표시됨



      • 승인 완료 후 apply 실행 및 배포 완료



      • Apply 성공 확인: 모든 리소스가 성공적으로 생성되었는지 확인



      • PR Merge: Apply 성공 후 브랜치 Merge 진행



      • 브랜치 정리: "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 저장소 → Settings → Branches

      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 태그 수정


      # 변경사항 확인
      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 실행 및 결과 코멘트 확인



      • 협업자 승인: 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 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

      DEVOTEE를 활성화 시키면
      지금 작성한 댓글에 AI가 댓글을 달아줍니다.

      SkyOps 님의 최신 블로그

      더보기
      동영상 기고하기