Share via

GitOps(Flux v2)를 사용한 CI/CD 워크플로

  • 아티클

최신 Kubernetes 배포에는 여러 애플리케이션, 클러스터 및 환경이 포함됩니다. GitOps를 사용하여 이러한 복잡한 설정을 보다 쉽게 관리할 수 있으며 Git를 사용하여 Kubernetes 환경의 원하는 상태를 선언적으로 추적할 수 있습니다. 일반적인 Git 도구를 사용하여 클러스터 상태를 선언하면 책임을 늘리고, 오류 조사를 용이하게 하고, 자동화를 통해 환경을 관리할 수 있습니다.

이 문서에서는 Azure Arc, Azure Repos 및 Azure Pipelines를 사용하여 GitOps가 전체 애플리케이션 변경 수명 주기에 어떻게 잘 맞는지 설명합니다. 또한 GitOps 제어 Kubernetes 환경에 대한 단일 애플리케이션 변경의 예도 제공합니다.

아키텍처

이 다이어그램은 하나 이상의 Kubernetes 환경에 배포된 애플리케이션에 대한 CI/CD 워크플로를 보여 줍니다.

GitOps CI/CD 아키텍처를 보여 주는 다이어그램

애플리케이션 코드 리포지토리

애플리케이션 리포지토리에는 개발자가 내부 루프 중에 작업하는 애플리케이션 코드가 포함되어 있습니다. 애플리케이션의 배포 템플릿은 Helm 또는 Kustomize와 같은 일반 형식으로 이 리포지토리에 상주합니다. 환경별 값은 리포지토리에 저장되지 않습니다.

이 리포지토리의 변경 내용은 배포 프로세스를 시작하는 PR 또는 CI 파이프라인을 호출합니다.

컨테이너 레지스트리

컨테이너 레지스트리는 Kubernetes 환경에 사용되는 모든 자사 및 타사 이미지를 보관합니다. 사용자가 읽을 수 있는 태그 및 이미지를 빌드하는 데 사용되는 Git 커밋을 사용하여 자사 애플리케이션 이미지에 태그를 적용합니다. 타사 이미지는 보안, 속도 및 복원력에 도움이 되도록 캐시될 수 있습니다. 적시에 테스트하고 보안 업데이트를 통합하기 위한 계획을 설정합니다.

자세한 내용은 Azure Container Registry 작업을 사용하여 퍼블릭 콘텐츠를 사용하고 유지 관리하는 방법을 참조하세요.

PR 파이프라인

애플리케이션 리포지토리에 대한 개발자의 끌어오기 요청은 PR 파이프라인의 성공적인 실행에 따라 결정됩니다. 이 파이프라인은 애플리케이션 코드에 대한 린팅 및 단위 테스트와 같은 기본 품질 게이트를 실행합니다. 파이프라인은 Kubernetes 환경에 배포하는 데 사용되는 애플리케이션 및 lint Dockerfile 및 Helm 템플릿을 테스트합니다. Docker 이미지를 빌드하고 테스트해야 하지만 푸시하지는 않습니다. 신속하게 반복할 수 있도록 파이프라인 기간을 비교적 짧게 유지합니다.

CI 파이프라인

애플리케이션 CI 파이프라인은 모든 PR 파이프라인 단계를 실행하여 테스트 및 배포 확인을 확장합니다. 파이프라인은 기본에 대한 각 커밋에 대해 실행되거나 커밋 그룹과 함께 정기적인 주기로 실행될 수 있습니다.

이 단계에서 PR 파이프라인에서 수행하기에는 너무 소모적인 다음과 같은 애플리케이션 테스트가 수행될 수 있습니다.

  • 컨테이너 레지스트리에 이미지 푸시
  • 이미지 빌드, 린팅 및 테스트
  • 원시 YAML 파일의 템플릿 생성

CI 빌드가 끝나면 아티팩트가 생성됩니다. 이러한 아티팩트는 배포 준비의 CD 단계에서 사용할 수 있습니다.

Flux 클러스터 확장

Flux는 각 클러스터에서 클러스터 확장으로 실행되는 에이전트입니다. 이 Flux 클러스터 확장은 원하는 상태를 유지하는 역할을 담당합니다. 에이전트는 사용자 정의 간격으로 GitOps 리포지토리를 폴링한 다음, Git 리포지토리에 선언된 상태로 클러스터 상태를 조정합니다.

자세한 내용은 자습서: Flux v2에서 GitOps를 사용하여 애플리케이션 배포를 참조하세요.

CD 파이프라인

성공적인 CI 빌드에 의해 CD 파이프라인이 자동으로 트리거됩니다. 이 파이프라인 환경에서 환경별 값은 이전에 게시된 템플릿으로 대체되고 이러한 값을 사용하여 GitOps 리포지토리에 대해 새 끌어오기 요청이 발생합니다. 이 끌어오기 요청에는 하나 이상의 Kubernetes 클러스터의 원하는 상태에 대한 제안된 변경 내용이 포함되어 있습니다. 클러스터 관리자는 끌어오기 요청을 검토하고 GitOps 리포지토리에 대한 병합을 승인합니다. 파이프라인은 끌어오기 요청이 병합될 때까지 기다린 후 Flux가 상태 변경을 동기화하고 적용합니다.

GitOps 리포지토리

GitOps 리포지토리는 클러스터 전반에 걸쳐 모든 환경의 현재 원하는 상태를 나타냅니다. 이 리포지토리에 대한 모든 변경 내용은 각 클러스터의 Flux 서비스에 의해 선택되어 배포됩니다. 클러스터의 원하는 상태에 대한 변경 내용은 끌어오기 요청으로 제시된 다음 검토되고 최종적으로 변경 승인 시 병합됩니다. 이러한 끌어오기 요청에는 배포 템플릿에 대한 변경 내용과 결과로 렌더링된 Kubernetes 매니페스트가 포함됩니다. 낮은 수준으로 렌더링된 매니페스트를 사용하면 일반적으로 템플릿 수준에서 보이지 않는 변경 내용 검사를 보다 신중하게 수행할 수 있습니다.

GitOps 커넥터

GitOps 커넥터는 Flux 에이전트와 GitOps 리포지토리/CD 파이프라인을 연결합니다. 클러스터에 변경 내용을 적용하는 동안 Flux는 수행된 모든 단계 변경 및 상태 확인을 GitOps 커넥터에 알립니다. 이 구성 요소는 어댑터 역할을 합니다. Git 리포지토리와 통신하는 방법을 이해하고 Git 커밋 상태를 업데이트하여 GitOps 리포지토리에서 동기화 진행률을 볼 수 있습니다. 배포가 완료되면(성공 여부에 관계없이) 커넥터는 파이프라인이 통합 테스트와 같은 배포 후 작업을 수행할 수 있도록 계속할 CD 파이프라인에 알립니다.

Kubernetes 클러스터

하나 이상의 Azure Arc 지원 Kubernetes 또는 AKS(Azure Kubernetes Service) 클러스터가 애플리케이션에 필요한 다양한 환경을 제공합니다. 예를 들어 단일 클러스터는 서로 다른 네임스페이스를 통해 개발 및 QA 환경을 모두 제공할 수 있습니다. 두 번째 클러스터는 환경을 보다 쉽게 분리하고 보다 세분화된 제어를 제공할 수 있습니다.

예시 워크플로

애플리케이션 개발자로서 Alice는 다음을 수행합니다.

  • 애플리케이션 코드를 작성합니다.
  • Docker 컨테이너에서 애플리케이션을 실행하는 방법을 결정합니다.
  • Kubernetes 클러스터에서 컨테이너 및 종속 서비스를 실행하는 템플릿을 정의합니다.

Alice는 애플리케이션을 여러 환경에서 실행하기 위한 기능이 있어야 한다는 것은 알고 있지만 각 환경에 대한 특정 설정은 알지 못합니다.

Alice가 애플리케이션 배포 템플릿에 사용되는 Docker 이미지를 변경하는 애플리케이션을 변경하려고 한다고 가정합니다.

  1. Alice는 배포 템플릿을 변경하고 이를 Application Repo의 alice라는 원격 분기로 푸시하고 main 분기에 대한 검토를 위해 끌어오기 요청을 엽니다.

  2. Alice는 팀에 변경 내용을 검토하도록 요청합니다.

    • PR 파이프라인은 유효성 검사를 실행합니다.
    • 성공적인 PR 파이프라인 실행 및 팀 승인 후 변경 내용이 병합됩니다.

  3. 그런 다음 CI 파이프라인이 시작되고 Alice의 변경 내용에 대한 유효성을 검사하고 성공적으로 완료됩니다.

    • 변경 내용은 클러스터에 배포해도 안전하며, 아티팩트는 CI 파이프라인 실행에 저장됩니다.

  4. 성공적인 CI 파이프라인 실행은 CD 파이프라인을 트리거합니다.

    • CD 파이프라인은 Alice의 CI 파이프라인 실행에 의해 저장된 아티팩트를 선택합니다.
    • CD 파이프라인은 템플릿을 환경 특정 값으로 대체하고, GitOps 리포지토리의 기존 클러스터 상태에 대한 모든 변경 내용을 스테이징합니다.
    • CD 파이프라인은 원하는 클러스터 상태 변경 내용을 포함하여 GitOps Repo의 프로덕션 분기에 대한 끌어오기 요청을 만듭니다.

  5. Alice의 팀은 끌어오기 요청을 검토하고 승인합니다.

    • 변경 내용은 환경에 해당하는 대상 분기로 병합됩니다.

  6. Flux는 몇 분 안에 GitOps 리포지토리의 변경 내용을 확인하고 Alice의 변경 내용을 가져옵니다.

    • Docker 이미지 변경으로 인해 애플리케이션 Pod에 업데이트가 필요합니다.
    • Flux는 클러스터에 변경 내용을 적용합니다.
    • Flux는 GitOps 커넥터를 통해 배포 상태를 GitOps 리포지토리에 다시 보고합니다.

  7. CD 파이프라인은 자동화된 테스트를 실행하여 새 배포가 성공적으로 완료되고 예상대로 작동하는지 확인합니다.

    참고 항목

    배포를 대상으로 하는 추가 환경의 경우 CD 파이프라인은 다음 환경에 대한 끌어오기 요청을 만들어 반복하고 4~7단계를 반복합니다. 이 프로세스에는 보안 관련 변경 또는 프로덕션 환경과 같은 위험한 배포 또는 환경에 대한 추가 승인이 필요할 수 있습니다.

  8. 모든 환경에서 성공적인 배포를 수신하면 파이프라인이 완료됩니다.

다음 단계