Kubernetes 모범 사례, 제 2판

5장. 지속적 통합, 테스트 및 배포

이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: [e-mail]

이 장에서는 지속적인 통합/지속 배포(CI/CD) 파이프라인을 통합하여 애플리케이션을 배포하는 방법의 핵심 개념에 대해 살펴봅니다. 잘 통합된 파이프라인을 구축하면 애플리케이션을 프로덕션에 자신 있게 제공할 수 있으므로, 여기서는 사용자 환경에서 CI/CD를 활성화하는 방법, 도구 및 프로세스를 살펴봅니다. CI/CD의 목표는 개발자가 코드를 체크인하는 것부터 새 코드를 프로덕션에 롤아웃하는 것까지 완전히 자동화된 프로세스를 갖추는 것입니다. 오류가 발생하기 쉬우므로 Kubernetes에 배포된 앱의 업데이트를 수동으로 롤아웃하는 것은 피해야 합니다. Kubernetes에서 애플리케이션 업데이트를 수동으로 관리하면 구성 변동과 취약한 배포 업데이트로 이어지며 애플리케이션을 제공하는 전반적인 민첩성이 떨어집니다.

이 장에서는 다음 주제를 다룹니다:

• 버전 관리

• 지속적인 통합

• 테스트

• 컨테이너 빌드

• 컨테이너 이미지 태그 지정

• 지속적인 배포

• 배포 전략

• 프로덕션 환경에서의 테스트

• 카오스 테스트

또한 다음 작업으로 구성된 예제 CI/CD 파이프라인을 살펴봅니다:

• 코드 변경 사항을 Git 리포지토리에 푸시하기

• 애플리케이션 코드 빌드 실행

• 코드에 대한 테스트 실행

• 성공적인 테스트에서 컨테이너 이미지 빌드

• 컨테이너 이미지를 컨테이너 레지스트리에 푸시하기

• 애플리케이션을 Kubernetes에 배포하기

• 배포된 애플리케이션에 대한 테스트 실행

• 배포에서 롤링 업그레이드 수행하기

버전 관리

모든 CI/CD 파이프라인은 애플리케이션 및 구성 코드 변경의 실행 기록을 유지하는 버전 제어로 시작됩니다. Git은 소스 제어 관리 플랫폼으로서 업계 표준이 되었으며, 모든 Git 리포지토리에는 메인 브랜치( )가 포함됩니다. 메인 브랜치에는 프로덕션 코드가 포함되어 있습니다. 기능 및 개발 작업을 위한 다른 브랜치는 결국 메인 브랜치에 병합될 것입니다. 브랜치 전략을 설정하는 방법에는 여러 가지가 있으며, 조직 구조와 업무 분담에 따라 설정이 달라질 수 있습니다. 애플리케이션 코드와 구성 코드(예: Kubernetes 매니페스트 또는 Helm 차트)를 모두 포함하면 커뮤니케이션과 협업이라는 좋은 DevOps 원칙을 촉진하는 데 도움이 된다는 것을 알게 되었습니다. 애플리케이션 개발자와 운영 엔지니어가 모두 단일 리포지토리에서 협업하면 팀이 애플리케이션을 프로덕션에 제공할 수 있다는 자신감을 갖게 됩니다.

지속적 통합

CI는 코드 변경 사항을 버전 관리 리포지토리에 지속적으로 통합하는 프로세스입니다. 큰 변경 사항을 덜 자주 커밋하는 대신 작은 변경 사항을 더 자주 커밋합니다. 코드 변경 사항이 리포지토리에 커밋될 때마다 빌드가 시작됩니다. 이렇게 하면 실제로 문제가 발생했을 때 애플리케이션을 망가뜨린 원인에 대한 피드백 루프를 더 빨리 ...