Google Kubernetes Engine에 지속적 통합 및 배포를 위한 권장사항

이 가이드에서는 Google Kubernetes Engine(GKE)에 지속적 통합 및 지속적 배포(CI/CD)를 위한 권장사항을 설명합니다. 이러한 권장사항은 소스 제어부터 배포 전략에 이르기까지 폭넓은 주제를 다룹니다. 이러한 권장사항은 GKE에만 해당되며 일반적인 CI/CD 권장사항은 계속 적용 가능합니다. 자세한 내용은 DevOps 기술: 지속적 통합 및 DevOps 기술: 지속적 배포를 참조하세요.

지속적 통합

지속적 통합(CI)은 개발자가 모든 코드 변경사항을 주 브랜치에 가능한 한 자주 다시 통합하는 방식입니다. 이렇게 하면 문제를 최대한 일찍 노출하여 장애를 더 빠르게 처리할 수 있도록 해줍니다. CI 파이프라인은 일반적으로 개발자가 코드 변경사항을 푸시하는 경우에 트리거됩니다. 파이프라인에는 린트 작업, 테스트, 빌드와 같은 변경사항을 검증하는 단계가 포함됩니다. CI 파이프라인은 일반적으로 배포 프로세스의 후반 단계에서 배포할 수 있는 아티팩트를 생성합니다.

빠른 반복을 사용하는 파이프라인 만들기

개발자가 코드를 변경한 시점과 애플리케이션의 실행 버전 시점 간에 시간차가 최대한 짧아야 합니다. 이 속도는 특히 개발자가 빠르게 반복해야 하는 기능 브랜치를 개발할 때 중요합니다. CI 파이프라인은 10분 이내에 실행하는 것이 이상적입니다. 그렇게 할 수 없다면 두 가지 유형의 CI 파이프라인을 만듭니다.

  • 신속한 파이프라인: 이 파이프라인은 일반적으로 10분 이내에 실행됩니다. 이러한 파이프라인은 기능 브랜치용이며 종합적인 용도가 아닙니다. 신속한 파이프라인은 불안정한 아티팩트를 야기할 수 있습니다.

  • 전체 파이프라인: 이 파이프라인은 실행하는 데 10분 이상 소요될 수 있으며 보다 더 종합적인 테스트 및 검사를 실행합니다. 전체 파이프라인은 병합 또는 pull 요청에 따라 실행되고 주 브랜치에 커밋됩니다.

컨테이너 이미지 테스트

CI 파이프라인의 일환으로 코드 및 빌드 아티팩트에 필요한 모든 테스트를 실행해야 합니다. 이러한 테스트에는 단위, 기능, 통합, 부하 또는 성능 테스트가 포함되어야 합니다.

또한 빌드된 컨테이너 이미지의 구조를 테스트하는 것도 중요합니다. 구조를 테스트하면 모든 명령어가 컨테이너 내부에서 예상한 대로 실행되는지 확인할 수 있습니다. 또한 테스트를 통해 특정 파일이 올바른 위치에 있는지, 올바른 콘텐츠를 포함하고 있는지 확인할 수 있습니다.

컨테이너 이미지를 테스트하려면 컨테이너 구조 테스트 프레임워크를 사용하면 됩니다.

파이프라인 초기에 보안 설정

개발 수명 주기에서 최대한 초기에 보안 확인 및 균형을 확인합니다. 아티팩트를 빌드하거나 배포하기 전에 보안 위험을 찾아 이러한 위험을 해결하는 데 소요되는 시간과 비용을 줄일 수 있습니다.

조기 감지를 위해서는 파이프라인에서 다음 보안 조치를 구현할 수 있습니다.

  • 주제 전문가에게 프로덕션 저장소에 통합된 코드 검토를 요청합니다.

  • 파이프라인 초기에 린트 작업 및 정적 코드 분석을 구현합니다. 이 테스트는 입력 이스케이프 미처리, SQL 쿼리용 원시 입력 데이터 허용, 코드의 취약점 같은 약점을 찾는 데 도움이 됩니다.

  • 취약점 스캔을 사용하여 빌드된 컨테이너 이미지의 취약점을 검사합니다.

  • Binary Authorization을 사용하여 취약점이 포함된 이미지가 클러스터에 배포되는 것을 차단합니다. Binary Authorization을 사용하려면 GKE Enterprise 구독이 필요합니다. 생성된 이미지에 더 높은 신뢰도를 제공하기 위해 Binary Authorization을 사용하면 다른 항목 또는 시스템에서 제공하는 증명을 요구할 수도 있습니다. 예를 들어 이러한 증명에는 다음이 포함될 수 있습니다.

    • 취약점 스캔 통과
    • QA 테스트 통과
    • 제품 소유자 확인

지속적 배포

지속적 배포(CD)를 사용하면 언제든지 코드를 출시할 수 있습니다. CD는 CI 파이프라인에서 생성된 아티팩트에서 작동합니다. 특히 블루-그린 배포와 같이 보다 정교한 배포 전략을 사용하는 경우 CD 파이프라인이 CI 파이프라인보다 훨씬 오래 실행될 수 있습니다.

GitOps 방법 사용

GitOps는 Git 저장소 및 CI/CD 도구에 저장된 선언적 인프라 개념으로 그러한 인프라를 환경에 배포합니다. GitOps 방법을 사용하는 경우 애플리케이션 및 클러스터의 모든 변경사항이 소스 저장소에 저장되고 항상 액세스 가능하도록 합니다.

GitOps 방법을 사용하면 다음과 같은 이점이 있습니다.

  • 병합 또는 pull 요청을 통해 변경사항을 배포하기 전에 검토할 수 있습니다.
  • 어느 시점이든지 애플리케이션과 클러스터의 상태를 다시 참조하는 데 사용할 수 있는 단일 위치가 있습니다.
  • 클러스터 및 애플리케이션의 스냅샷을 사용하면 장애 시 쉽게 복구할 수 있습니다.

GitOps 방법과 소스 저장소에서 활용할 수 있는 다양한 패턴에 대한 자세한 내용은 GitOps 개념을 참조하세요.

선언적 인프라에 사용되는 몇 가지 일반적인 도구는 Hashicorp의 Terraform과 Google Cloud의 Config Connector입니다. GitOps 및 기타 도구로 인프라 관리를 실습해보려면 Terraform, Cloud Build, GitOps를 사용하여 인프라를 코드로 관리 튜토리얼을 참조하세요. GitOps 스타일로 애플리케이션을 관리하는 방법을 알아보려면 Cloud Build로 GitOps 스타일의 지속적 배포를 사용해 보세요.

컨테이너 이미지를 재빌드하는 대신 승격

컨테이너 이미지가 CI/CD 파이프라인의 각기 다른 단계를 통과할 때 재빌드되어서는 안 됩니다. 재빌드로 인해 코드 브랜치 전반에서 사소한 차이가 발생할 수 있으며, 이러한 차이로 인해 애플리케이션이 프로덕션에서 장애를 일으키거나 프로덕션 컨테이너 이미지에 테스트되지 않은 코드가 실수로 추가될 수 있습니다. 테스트한 컨테이너 이미지가 배포 컨테이너 이미지라는 것을 확실히 하려면 1회 빌드하여 환경에 따라 승격하는 것이 가장 좋습니다. 이 권장사항은 환경별 구성을 패키지와 별도로 유지한다고 가정합니다.

고급 배포 및 테스트 패턴 사용 고려

GKE는 여러 패턴을 사용하여 애플리케이션을 배포하고 테스트할 수 있는 유연성을 제공합니다. 배포 패턴의 선택은 주로 비즈니스 목표에 따라 달라집니다. 예를 들어 다운타임 없이 변경사항을 배포하거나 기능을 일반 안정화 버전으로 출시하기 전에 특정 환경 또는 일부 사용자에게만 변경사항을 배포해야 할 수 있습니다.

사용 가능한 여러 가지 배포 패턴에는 다음이 포함됩니다.

  • 배포 다시 만들기: 새 애플리케이션 버전을 확장하기 전에 기존 애플리케이션 버전을 완전히 축소합니다.

  • 순차적 업데이트 배포: 실행 중인 모든 애플리케이션 인스턴스를 한 번에 업데이트하는 대신, 실행 중인 애플리케이션 인스턴스의 하위 집합을 업데이트합니다. 그런 다음 실행 중인 애플리케이션 인스턴스가 모두 업데이트될 때까지 점진적으로 업데이트합니다.

  • 블루-그린 배포: 애플리케이션의 업그레이드된 버전이 있는 기존 프로덕션 인스턴스에 추가 인스턴스 집합을 동시에 배포합니다. 배포할 준비가 되면 트래픽을 새 인스턴스로 전환합니다.

환경별로 클러스터 분리

환경 분리는 모든 배포 대상에서 중요한 고려 사항입니다. 이상적으로는 다음과 같은 환경마다 별도의 클러스터가 있어야 합니다.

  • 개발 환경: 이 환경에는 개발자가 테스트 및 실험용 애플리케이션을 배포합니다. 이러한 배포를 위해서는 애플리케이션 또는 시스템의 다른 부분(예: 데이터베이스)과 통합된 환경이 필요합니다. 이 환경의 클러스터는 일반적으로 게이트가 적으며 개발자는 클러스터 구성을 더 세밀하게 제어할 수 있습니다.

  • 사전 프로덕션 환경(스테이징 또는 QA): 이 환경은 프로덕션 환경과 최대한 유사해야 합니다. 이러한 환경은 통합, 로드, 성능, 회귀 테스트와 같은 대규모 변경사항 테스트를 수행하는 데 사용됩니다.

  • 프로덕션 환경: 이 환경은 프로덕션 워크로드와 사용자 대상 애플리케이션 및 서비스가 실행되는 환경입니다.

이러한 환경에 대한 자세한 내용은 Kubernetes 및 지속적 소프트웨어 배포 과제의 환경 섹션을 참조하세요.

사전 프로덕션 환경을 프로덕션 환경과 흡사하게 유지

이상적으로는 사전 프로덕션 클러스터는 프로덕션 클러스터와 동일하지만, 비용 효율성 측면에서 사전 프로덕션 클러스터는 축소된 복제본일 수 있습니다. 클러스터를 유사한 상태로 유지하면 프로덕션의 상태와 동일하거나 유사한 조건에서 모든 테스트가 수행됩니다. 또한 사전 프로덕션 클러스터와 프로덕션 클러스터 간의 패리티는 프로덕션에 배포할 때 환경 차이로 인해 예기치 않은 오류가 발생할 가능성을 줄여줍니다.

선언형 인프라와 GitOps를 사용하면 기본 클러스터의 구성을 더 쉽게 복제할 수 있으므로 프로덕션 환경에 더 가깝게 만들 수 있습니다. 환경에 정책 및 구성 조건이 유사한지 확인하려면 구성 동기화와 같은 도구를 사용하면 됩니다.

프로덕션 환경의 오류 발생 대비

아무리 많은 테스트를 수행해도 프로덕션에서 애플리케이션의 올바른 동작을 보장할 수는 없습니다. 오류는 고려 대상이 아닌 데이터를 사용하는 특이 사례 또는 테스트되지 않은 사용자의 액세스 패턴에 의해 발생할 수 있습니다. 프로덕션에서 애플리케이션을 모니터링하고 버그 또는 장애 조치에 빠르게 대처하고 배포할 수 있도록 자동화된 롤백 및 배포 메커니즘을 포함하는 것이 중요합니다. 보다 강력한 배포 전략을 사용하면 프로덕션에서 문제가 발생할 때 충격을 줄이고 최종 사용자에게 미치는 영향을 줄일 수 있습니다.

체크리스트 요약

다음 표에는 GKE에서 CI/CD 파이프라인을 사용할 때 권장되는 작업이 요약되어 있습니다.

지역 할 일 목록
지속적 통합
지속적 배포

다음 단계