GitOps는 애플리케이션 및 선언적 인프라 코드를 Git에 저장하여 자동화된 지속적인 업데이트의 단일 소스로 사용하는 클라우드 네이티브 애플리케이션의 운영 모델입니다. GitOps를 사용하면 사용자는 Git 리포지토리에서 원하는 전체 시스템의 상태를 설명하고 GitOps 운영자는 Kubernetes 클러스터인 사용자 환경에 배포할 수 있습니다. Azure의 Kubernetes용 GitOps에 대한 자세한 내용은 Azure Kubernetes Service용 GitOps 또는 Azure Arc 지원 Kubernetes를 사용하는 CI/CD 및 GitOps 분야를 참조하세요.
이 문서의 예제 시나리오는 컨테이너, 빌드용 CI(연속 통합), CD(연속 배포)용 GitOps를 사용하여 엔드투엔드 애플리케이션 개발을 현대화하려는 기업에 적용할 수 있습니다. 이 시나리오에서는 Flask 앱이 예제로 사용됩니다. 이 웹앱은 Python 및 Flask 프레임워크를 사용하여 작성된 프런트 엔드로 구성됩니다.
아키텍처
다음 옵션은 밀어넣기 기반 및 끌어오기 기반 CI/CD 접근 방식을 살펴봅니다.
옵션 1: 밀어넣기 기반 CI/CD
CI 및 CD용 GitHub Actions를 사용하는 밀어넣기 기반 아키텍처.
이 아키텍처의 Visio 파일을 다운로드합니다.
데이터 흐름
이 시나리오에서는 프런트 엔드 웹 구성 요소와 Redis를 사용하는 백 엔드가 있는 2계층 웹 애플리케이션의 밀어넣기 기반 DevOps 파이프라인을 다룹니다. 이 파이프라인은 빌드 및 배포에 GitHub Actions를 사용합니다. 시나리오를 통한 데이터 흐름은 다음과 같습니다.
- 앱 코드가 개발되었습니다.
- 앱 코드는 GitHub Git 리포지토리에 커밋됩니다.
- GitHub Actions는 앱 코드에서 컨테이너 이미지를 빌드하고 컨테이너 이미지를 Azure Container Registry에 밀어넣습니다.
- GitHub Actions 작업은 kubectl 또는 Kubernetes 클러스터에 배포 작업을 사용하여 매니페스트 파일에 설명된 대로 앱을 AKS(Azure Kubernetes Service) 클러스터에 배포하거나 푸시합니다.
옵션 2: 끌어오기 기반 CI/CD(GitOps)
CI용 GitHub Actions 및 CD용 Argo CD를 사용하는 끌어오기 기반 아키텍처.
이 아키텍처의 Visio 파일을 다운로드합니다.
데이터 흐름
이 시나리오에서는 프런트 엔드 웹 구성 요소와 Redis를 사용하는 백 엔드가 있는 2계층 웹 애플리케이션의 끌어오기 기반 DevOps 파이프라인을 다룹니다. 이 파이프라인은 빌드에 GitHub Actions를 사용합니다. 배포의 경우 Argo CD를 GitOps 운영자로 사용하여 앱을 끌어오고 동기화합니다. 시나리오를 통한 데이터 흐름은 다음과 같습니다.
- 앱 코드가 개발되었습니다.
- 앱 코드는 GitHub 리포지토리에 커밋됩니다.
- GitHub Actions는 앱 코드에서 컨테이너 이미지를 빌드하고 컨테이너 이미지를 Azure Container Registry에 밀어넣습니다.
- GitHub Actions는 Azure Container Registry에 있는 컨테이너 이미지의 버전 번호를 기준으로 Kubernetes 매니페스트 배포 파일을 현재 이미지 버전으로 업데이트합니다.
- Argo CD는 Git 리포지토리에서 끌어오거나 동기화됩니다.
- Argo CD는 AKS 클러스터에 앱을 배포합니다.
구성 요소
- GitHub Actions는 CI(연속 통합)용 Azure 서비스와 통합할 수 있는 자동화 솔루션입니다. 이 시나리오에서 GitHub Actions는 소스 제어에 대한 커밋에 따라 새 컨테이너 이미지를 만들도록 오케스트레이션하고, Azure Container Registry에 해당 이미지를 밀어넣은 다음, GitHub 리포지토리에서 Kubernetes 매니페스트 파일을 업데이트합니다.
- AKS(Azure Kubernetes Service)는 컨테이너 오케스트레이션에 대한 전문 지식이 없어도 컨테이너화된 애플리케이션을 배포하고 관리할 수 있는 관리형 Kubernetes 플랫폼입니다. 호스팅되는 Kubernetes 서비스인 Azure는 상태 모니터링 및 유지 관리 같은 중요 작업을 처리합니다.
- Azure Container Registry는 AKS 클러스터에서 사용되는 컨테이너 이미지를 저장하고 관리합니다. 이미지는 안전하게 저장되며, Azure 플랫폼을 통해 다른 지역으로 복제하여 배포 시간을 단축할 수 있습니다.
- GitHub는 Git에서 실행하는 웹 기반 소스 제어 시스템이며 개발자가 애플리케이션 코드를 저장하고 버전을 관리할 때 사용합니다. 이 시나리오에서는 GitHub를 사용하여 소스 코드를 Git 리포지토리에 저장한 다음, GitHub Actions를 사용하여 밀어넣기 기반 접근 방식으로 Azure Container Registry에 컨테이너 이미지를 빌드하고 밀어넣습니다.
- Argo CD는 GitHub 및 AKS와 통합되는 오픈 소스 GitOps 운영자입니다. Argo CD는 CD(연속 배포)를 지원합니다. Flux를 이러한 용도로 사용할 수도 있지만 Argo CD는 클러스터 운영자가 클러스터 관리에 동일한 도구를 사용하는 것과 비교하여 앱 팀이 특정 애플리케이션 수명 주기 문제에 대해 별도의 도구를 선택하는 방법을 보여줍니다.
- Azure Monitor는 성능을 추적하고 보안을 유지하며 추세를 파악하는 데 도움이 됩니다. Azure Monitor에서 얻은 메트릭은 Grafana와 같은 다른 리소스 및 도구에서 사용할 수 있습니다.
대안
- Azure Pipelines를 사용하면 모든 앱의 빌드, 테스트 및 배포 파이프라인을 구현할 수 있습니다.
- Jenkins는 CI/CD용 Azure 서비스와 통합할 수 있는 오픈 소스 자동화 서버입니다.
- Flux는 GitOps 운영자로 활용할 수 있습니다. Argo CD와 동일한 태스크를 수행할 수 있으며 AKS와 동일한 방식으로 작동합니다.
시나리오 정보
이 시나리오에서는 여러 기술을 사용하여 앱을 자동으로 빌드 및 배포합니다. 코드는 VS Code에서 개발되어 GitHub 리포지토리에 저장됩니다. GitHub Actions를 사용하여 앱을 컨테이너로 빌드한 다음 컨테이너 이미지를 Azure Container Registry에 밀어넣을 수 있습니다. GitHub Actions를 사용하여 Git 리포지토리에도 저장된 필수 Kubernetes 매니페스트 배포 파일을 업데이트할 수 있으며, GitOps 운영자 Argo CD는 해당 위치에서 Kubernetes 매니페스트 파일을 선택하고 AKS 클러스터에 앱을 배포합니다.
다른 예로는 자동화된 개발 환경 제공, 새 코드 커밋의 유효성 검사, 준비 또는 프로덕션 환경으로 새 배포 밀어넣기 등이 있습니다. 일반적으로 기업에서는 애플리케이션과 업데이트를 수동으로 빌드 및 컴파일하고, 대규모의 모놀리식 코드베이스를 유지해야 했습니다. CI 및 CD용 GitOps를 사용하는 애플리케이션 개발에 대한 최신 접근 방식으로 서비스를 빠르게 빌드, 테스트 및 배포할 수 있습니다. 이러한 현대적인 접근 방식을 통해 고객에게 애플리케이션과 업데이트를 더 빨리 릴리스하고, 변화하는 비즈니스 요구 사항에 더 민첩하게 대응할 수 있습니다.
회사는 AKS, Container Registry, GitHub, GitHub Actions와 같은 Azure 및 GitHub 서비스를 통해 최신 애플리케이션 개발 기술과 도구를 사용하여 고가용성 구현 프로세스를 간소화할 수 있습니다. 또한 회사는 Flux 또는 GitOps용 Argo CD와 같은 오픈 소스 기술을 사용하여 배포를 간소화하고 원하는 애플리케이션 상태를 적용합니다.
잠재적인 사용 사례
관련된 다른 사용 사례는 다음과 같습니다.
- 마이크로 서비스 컨테이너 기반 접근 방식을 채택하여 애플리케이션 개발 사례를 현대화합니다.
- 애플리케이션 개발 및 배포 수명 주기를 가속화합니다.
- 유효성 검사를 위해 테스트 또는 수용 환경에 배포를 자동화합니다.
- 구성 및 원하는 애플리케이션 상태를 확인합니다.
- 클러스터 수명 주기 관리를 자동화합니다.
CI/CD 옵션
이 문서에서는 CI/CD 파이프라인에서 연속 배포를 처리하는 최신 접근 방식에 GitOps를 사용하는 방법을 보여줍니다. 그러나 모든 조직은 각기 다릅니다. 자동화된 전송 파이프라인을 통해 Kubernetes 클러스터에 애플리케이션을 배포하는 경우 수행할 수 있는 다양한 방법을 파악해야 합니다.
AKS 클러스터에 애플리케이션을 배포하는 가장 일반적인 두 가지 CI/CD 옵션은 밀어넣기 기반과 끌어오기 기반입니다. 밀어넣기 옵션은 연속 배포에 GitHub Actions를 활용하고 끌어오기 옵션은 연속 배포에 GitOps를 활용합니다.
옵션 1: CI 및 CD용 GitHub Actions를 사용하는 밀어넣기 기반 아키텍처
이 접근 방식에서 코드는 Kubernetes 클러스터에 배포될 때 밀어넣은 변경 사항대로 작동하는 파이프라인의 CI 부분에서 시작합니다. 배포는 트리거에 기반합니다. 배포를 시작할 수 있는 트리거는 다양합니다(예: 리포지토리에 커밋 또는 다른 CI 파이프라인의 트리거). 이 접근 방식을 사용하면 파이프라인 시스템에서 Kubernetes 클러스터에 액세스할 수 있습니다. 밀어넣기 기반 모듈은 현재 CI/CD 도구에서 사용하는 가장 일반적인 모델입니다.
밀어넣기 기반 접근 방식을 사용하는 이유:
유연성: 현재 대부분의 GitOps 운영자는 Kubernetes에서만 실행됩니다. 조직에서 Kubernetes 이외의 환경에 애플리케이션을 배포하려면 GitHub Actions와 같은 다른 CI/CD 도구를 통해 해당 환경에 응애플리케이션을 밀어넣어야 합니다.
효율성: 클라우드 네이티브 및 기존 애플리케이션을 배포하는 표준화된 접근 방식이 더 효율적입니다. 현재 GitOps는 Kubernetes에서 실행되는 클라우드 네이티브 애플리케이션에 가장 적합합니다.
단순성: 밀어넣기 기반 CI/CD는 많은 조직의 엔지니어들 사이에서 가장 광범위하게 알려져 있습니다. 밀어넣기 기반 접근 방식은 밀어넣기 기반과 끌어오기 기반 CI/CD 접근 방식을 함께 사용하는 것보다 더 간단합니다.
구조: 현재 애플리케이션에 사용되는 리포지토리 구조가 GitOps에 적합하지 않을 수 있습니다. 즉, GitOps에 맞게 상당한 계획 및 재구성이 필요합니다.
옵션 2: CI용 GitHub Actions 및 CD용 GitOps 운영자 Argo CD를 사용하는 끌어오기 기반 아키텍처
이 접근 방식은 Kubernetes 클러스터 내부의 변경 사항을 적용하는 데 중점을 줍니다. Kubernetes 클러스터에는 Git 리포지토리를 검사하여 원하는 클러스터 상태를 확인하고 변경할 사항을 선택하여 적용하는 연산자가 있습니다. 이 모델에서 외부 클라이언트는 Kubernetes 클러스터에 대한 관리자 수준 자격 증명이 없습니다. 끌어오기 모델은 기존에 있었지만 CI/CD 도구에서 널리 사용되지 않았습니다. 최근 GitOps가 도입되면서 끌어오기 모델이 채택되고 있습니다. 많은 조직에서 CD/CD 파이프라인의 연속 배포를 지원하기 위해 GitOps를 활용하고 있습니다.
끌어오기 기반 접근 방식을 사용하는 이유:
일관성: GitOps를 사용하면 운영자가 Kubernetes 클러스터 상태를 Git 리포지토리의 원하는 구성 및 애플리케이션 상태와 비교합니다. 구성 또는 애플리케이션에 드리프트가 있는 경우 GitOps 운영자는 자동으로 Kubernetes 클러스터를 원하는 상태로 다시 가져옵니다.
보안: GitOps를 사용하는 CI/CD에 끌어오기 기반 접근 방식을 사용하면 보안 자격 증명을 Kubernetes 클러스터로 이동할 수 있으므로 외부 CI 도구에 자격 증명이 저장되지 않도록 제거하여 보안 및 위험 노출 영역을 줄일 수 있습니다. 허용되는 인바운드 연결을 줄이고 Kubernetes 클러스터에 대한 관리자 수준 액세스를 제한할 수도 있습니다.
버전 관리: GitOps는 Git 리포지토리를 단일 소스로 활용하므로 기본적으로 연속 배포에는 버전 관리, 롤백 및 감사 기능이 있습니다.
다중 테넌트: GitOps를 사용하는 끌어오기 기반 접근 방식은 분산 팀 및 다중 테넌트에 적합합니다. GitOps를 사용하면 별도의 Git 리포지토리와 별도의 액세스 권한을 활용하고, 여러 네임스페이스에 배포를 분산할 수 있습니다.
클라우드 네이티브: 점점 더 많은 애플리케이션이 현대화되거나 클라우드 네이티브로 빌드되고 있습니다. Kubernetes에서 대부분의 애플리케이션을 실행하는 조직의 경우 CI/CD에 기존 밀어넣기 기반 접근 방식보다 연속 배포용 GitOps 운영자를 활용하는 것이 더 간단하고 효율적입니다.
고려 사항
이러한 고려 사항은 워크로드의 품질을 향상시키는 데 사용할 수 있는 일단의 지침 원칙인 Azure Well-Architected Framework의 핵심 요소를 구현합니다. 자세한 내용은 Microsoft Azure Well-Architected Framework를 참조하세요.
안정성
안정성은 애플리케이션이 고객에 대한 약속을 충족할 수 있도록 합니다. 자세한 내용은 안정성 핵심 요소 개요를 참조하세요.
애플리케이션 성능을 모니터링하고 문제를 보고하기 위해 이 시나리오에서는 Azure Monitor를 활용합니다. 이렇게 하면 코드를 업데이트해야 하는 성능 문제를 모니터링하고 문제를 해결한 다음 CI/CD 파이프라인을 통해 배포할 수 있습니다.
AKS 클러스터의 일부인 부하 분산 장치는 애플리케이션을 실행하는 하나 이상의 컨테이너 또는 포드에 애플리케이션 트래픽을 분산합니다. Kubernetes에서 컨테이너화된 애플리케이션을 실행하는 이 접근 방식은 고객에게 고가용성 인프라를 제공합니다.
참고
이 문서에서는 CI/CD 파이프라인 고가용성을 직접적으로 다루지 않습니다. 자세한 내용은 GitHub Actions의 고가용성 및 Argo CD Declarative GitOps CD for Kubernetes(Kubernetes용 Argo CD 선언적 GitOps CD)를 참조하세요.
복원력 구성 요소는 Kubernetes에 기본 제공됩니다. 이러한 구성 요소는 문제가 있는 경우 컨테이너 또는 포드를 모니터링하고 다시 시작합니다. 여러 Kubernetes 노드가 결합되면 애플리케이션은 사용할 수 없는 포드 또는 노드를 허용할 수 있습니다.
복원력 있는 솔루션 설계에 대한 일반적인 지침은 안정적인 Azure 애플리케이션 디자인을 참조하세요.
보안
우수한 보안은 중요한 데이터 및 시스템에 대한 고의적인 공격과 악용을 방어합니다. 자세한 내용은 보안 요소의 개요를 참조하세요.
자격 증명과 권한을 분리하기 위해 이 시나리오에서는 전용 Microsoft Entra 서비스 주체를 사용합니다. 이 서비스 주체의 자격 증명은 스크립트 또는 빌드 파이프라인 내에서 직접 노출되거나 보이지 않도록 GitHub에서 보안 자격 증명 개체인 GitHub Actions Secrets로 저장됩니다.
AKS 클러스터의 애플리케이션 보안에 대한 일반적인 지침은 AKS(Azure Kubernetes Service)의 애플리케이션 및 클러스터에 대한 보안 개념을 참조하세요.
문제를 분리하기 위해 비즈니스 애플리케이션 및 GitOps 운영자를 Kubernetes 클러스터의 별도의 네임스페이스에서 실행하여 비즈니스 애플리케이션을 실행하는 컴퓨팅을 CD 에이전트 또는 GitOps 운영자와 분리해야 합니다. 문제를 추가로 분리하기 위해 GitOps 운영자는 비즈니스 애플리케이션을 실행하는 프로덕션 Kubernetes 클러스터와 별도로 GitOps 인스턴스의 전용 Kubernetes 클러스터에서 실행할 수 있습니다.
참고
이 문서에서는 CI/CD 파이프라인을 보호하는 방법을 직접적으로 다루지 않습니다.
성능 효율성
성능 효율성은 사용자가 배치된 요구 사항을 효율적인 방식으로 충족하기 위해 워크로드의 크기를 조정할 수 있는 기능입니다. 자세한 내용은 성능 효율성 핵심 요소 개요를 참조하세요.
AKS를 사용하면 애플리케이션의 요구 사항에 맞게 클러스터 노드 수를 조정할 수 있습니다. 애플리케이션 증가에 따라 서비스를 실행하는 Kubernetes 노드 수를 확장할 수 있습니다.
GitHub Actions를 통해 클라우드 공급자는 실행기 수를 자동으로 조정합니다. 자체 호스팅 실행기를 사용하는 경우 실행기의 호스트는 필요에 따라 수를 조정해야 합니다.
다른 확장성 항목은 성능 효율성 검사 목록을 참조하세요.
시나리오 배포
AKS-baseline-automation reference implementation(AKS 기준 자동화 참조 구현)의 단계에 따라 시나리오를 배포합니다. 참조 구현 리포지토리에는 push-based CI/CD(밀어넣기 기반 CI/CD) 시나리오와 pull-based CI/CD (GitOps)(끌어오기 기반 CI/CD(GitOps)) 시나리오의 단계별 지침이 모두 있습니다.
참가자
Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.
주요 작성자:
- Steve Buchanan | 주 프로그램 관리자
기타 기여자:
- Ayobami Ayodeji | 선임 프로그램 관리자
- Bahram Rushenas | 선임 설계자
비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인하세요.
다음 단계
이 시나리오에서는 Azure Container Registry와 AKS를 사용하여 컨테이너 기반 애플리케이션을 저장하고 실행했습니다. Azure Container Apps 또는 Azure Container Instances를 사용하여 오케스트레이션 구성 요소를 프로비전하지 않고 컨테이너 기반 애플리케이션을 실행할 수도 있습니다. 자세한 내용은 Azure Container Instances 개요 및 Azure Container Apps 개요를 참조하세요.
제품 설명서:
- Azure Kubernetes Service
- Azure Monitor 개요
- Azure의 Linux 가상 머신
- Azure의 프라이빗 Docker 컨테이너 레지스트리
- AKS(Azure Kubernetes Service)의 애플리케이션 및 클러스터에 대한 보안 개념
- AKS 랜딩 존 가속기
Microsoft Learn 모듈:
- Docker를 사용하여 컨테이너화된 웹 애플리케이션 빌드
- Azure Kubernetes Service에 컨테이너화된 애플리케이션 배포
- Azure Kubernetes Service(AKS) 구현
- Azure Monitor를 사용하여 리소스의 사용량, 성능 및 가용성 모니터링