BLOG
데이터는 애플리케이션의 영혼입니다. 컨테이너를 사용하면 애플리케이션을 보다 빠르게 패키징하고 배치할 수 있으므로 테스트는 소프트웨어의 안정적인 전달에서 훨씬 중요한 역할을 합니다. 모든 애플리케이션에는 데이터가 있으므로 개발 팀은 실제 응용 프로그램 데이터 또는 때로는 모호한 데이터를 사용하여 안정적으로 제어, 이동 및 테스트 할 수 있는 방법을 원합니다.
많은 팀에서 CI / CD 파이프 라인을 통해 애플리케이션 데이터를 이동하면서 컴플라이언스를 존중하고 관심사의 분리를 유지하는 작업은 규모가 조정되지 않는 수동 작업이었습니다. 기껏해야, 이는 몇 가지 응용 프로그램에만 국한되며 다른 환경끼리 이식할 수 없습니다. 목표는 추적 가능한 컨테이너 (작업이 추적되는 데이터베이스 및 메시지 버스는 무상태인 경우처럼 웹 프론트 엔드를 사용하는 경우처럼)를 실행하고 테스트하는 것입니다.
테스트 시나리오에서 State가 중요한 이유는 무엇입니까? 한 가지 이유는 코드가 실제 데이터에 대해 테스트 될 때만 많은 버그가 나타나기 때문입니다. 예를 들어, 데이터베이스 스키마 업그레이드를 테스트하기를 원할 수도 있지만, 작은 합성 데이터 세트는 복잡한 비즈니스 로직에서 중요하고 세밀한 코너 사례를 실행하지 않습니다. 진정한 엔드 투 엔드 테스트를 원한다면 우리는 데이터 나 상태를 쉽게 관리 할 수 있어야 합니다.
이 블로그 게시물에서는 응용 프로그램 간의 데이터 이동을 자동화 할 수 있는 CI / CD 파이프 라인 참조 아키텍처를 정의합니다. 또한 CI / CD 파이프 라인을 구성하기 위한 단계를 제공합니다.
추적 가능한 Pipeline: 휴대용 공간 필요함
지속적인 통합, 테스트 및 배치의 일환으로 프로덕션 환경에서 발견된 버그를 준비 설정에 따라 재현해야 할 수 있습니다. 여기서 호스팅 환경은 Kubernetes를 스케줄러로 사용하는 클러스터와 영구 볼륨을 사용하는 Portworx로 구성됩니다. 테스트 워크플로우는 AWS CodeCommit, AWS CodePipeline 및 AWS CodeBuild에 의해 자동화됩니다.
Portworx는 AWS 환경과 파이프 라인간에 영구 볼륨을 이식 할 수 있는 Kubernetes 스토리지를 제공합니다. Kubernetes 참조 아키텍처용 AWS 개발자 도구 연속배치 과정에 Portworx를 추가하면 Kubernetes 클러스터에 영구 저장 장치 및 저장 조정 기능이 추가됩니다. 이 예제는 MongoDB를 상태 저장 응용 프로그램의 데모로 사용합니다. 실제로 워크플로는 Cassandra, MySQL, Kafka 및 Elasticsearch와 같은 컨테이너 화 된 응용 프로그램에 적용됩니다.
개발자는 참조 아키텍처를 사용하여 CodePipeline을 호출하여 실행중인 프로덕션 MongoDB 데이터베이스의 스냅 샷을 트리거합니다. 그런 다음 Portworx는 MongoDB 볼륨에 대한 블록 기반의 쓰기 가능한 스냅 샷을 생성합니다. 그 사이에, 생산 MongoDB 데이타베이스는 최종 사용자에게 지속 서비스되며 중단되지 않습니다.
Portworx 통합이 없으면 수동 프로세스에서 CI / CD 프로세스 외부에 있는 데이터베이스 인스턴스의 응용 프로그램 수준 백업이 필요합니다. 대용량 데이터베이스의 경우 시간이 걸리고 생산에 영향을 줄 수 있습니다. 블록 기반 스냅 샷의 사용은 탄력적이고 무중단 백업을 위한 모범 사례를 따릅니다.
워크플로우의 일부로 CodePipeline은 Kubernetes 클러스터에 스테이징을위한 새로운 MongoDB 인스턴스를 배포하고 프로덕션의 데이터가 있는 두 번째 Portworx 볼륨을 마운트합니다. CodePipeline은 여기에 표시된대로 AWS 람다 함수를 통해 Portworx 볼륨의 스냅 샷을 트리거합니다.
Kubernetes를 사용한 AWS 개발자 도구 : Portworx로 통합된 워크플로우
다음 워크 플로우에서는 개발자가 MongoDB를 호출하는 컨테이너화된 애플리케이션의 변경 사항을 테스트하고 있습니다. 테스트는 MongoDB의 스테이징 인스턴스에 대해 수행됩니다. 변경 사항이 서버 측에 있는 경우에도 동일한 워크 플로우가 적용됩니다. 원래 프로덕션 배치는 Kubernetes 배치 개체로 예약되고 영구 볼륨의 저장소로 Portworx를 사용합니다.
지속적인 파이프 라인은 다음과 같이 실행됩니다.
- 개발자는 버그 수정 내용을 CodeCommit 마스터 분기에 병합되는 주요 개발 분기에 통합합니다.
- 코드가 AWS CodeCommit 저장소의 마스터 분기에 병합되면 Amazon CloudWatch가 파이프 라인을 트리거합니다.
- AWS CodePipeline은 빌드 ID가있는 Docker 컨테이너 이미지를 작성하는 AWS CodeBuild에 새 버전을 보냅니다.
- AWS CodeBuild는 빌드 ID로 태그 지정된 새 Docker 컨테이너 이미지를 Amazon ECR 레지스트리로 푸시합니다.
- Kubernetes는 Amazon ECR에서 새 컨테이너 (데이터베이스 클라이언트용)를 다운로드하고 응용 프로그램을 (포드로) 배포하고 MongoDB 인스턴스를 배포 객체로 준비합니다.
- AWS CodePipeline은 Lambda 함수를 통해 Portworx를 호출하여 프로덕션 MongoDB를 스냅하고 MongoDB의 스테이징 인스턴스를 배포합니다. Portworx는 프로덕션 인스턴스의 스냅 샷을 스테이징 MongoDB의 영구 저장소로 제공합니다
- MongoDB 인스턴스는 스냅 샷을 마운트합니다.
이 시점에서 Setup 과정은 프로덕션 환경을 모방합니다. 하지만 프로덕션 작업 부하에 영향을 주지 않고 파트너 도구를 사용하여 통합 및 end-to-end 간 테스트를 실행할 수 있습니다. 전체 파이프 라인은 아래와 같이 표시됩니다.
결론
이 참조 아키텍처는 개발 팀이 테스트 목적으로 프로덕션과 준비간에 데이터를 쉽게 이동할 수 있는 방법을 보여줍니다. 응용 프로그램 별 수동 단계를 수행하는 대신 이 CodePipeline 아키텍처의 모든 작업은 CI / CD 프로세스의 일부로 자동화되고 추적됩니다.
이 통합된 경험은 추적 가능한 컨테이너를 비저장상태와 같은 상태로 간단히 만들 수 있는 일 부분입니다. CI/ CD 프로세스 용 AWS CodePipeline을 통해 개발자는 Portworx 스토리지를 통해 Kubernetes 클러스터에 상태 보존 형 컨테이너를 쉽게 배치하고 프로세스 내에서 데이터 이동을 자동화 할 수 있습니다.
참조 아키텍처 및 코드는 GitHub에서 사용할 수 있습니다.
- 레퍼런스 아키텍쳐: https://github.com/portworx/aws-kube-codesuite
- Portworx 추가를 위한 람다 기능 소스 코드 : https://github.com/portworx/aws-kube-codesuite/blob/master/src/kube-lambda.py
컨테이너의 영구 저장소에 대한 자세한 내용은 Portworx 웹 사이트를 방문하십시오. 코드 파이프 라인에 대한 자세한 내용은 AWS CodePipeline User Guide를 참조하세요
원문 URL: https://aws.amazon.com/ko/blogs/devops/cicd-with-data-enabling-data-portability-in-a-software-delivery-pipeline-with-aws-developer-tools-kubernetes-and-portworx/
** 메가존 TechBlog는 AWS BLOG 영문 게재글중에서 한국 사용자들에게 유용한 정보 및 콘텐츠를 우선적으로 번역하여 내부 엔지니어 검수를 받아서, 정기적으로 게재하고 있습니다. 추가로 번역및 게재를 희망하는 글에 대해서 관리자에게 메일 또는 SNS페이지에 댓글을 남겨주시면, 우선적으로 번역해서 전달해드리도록 하겠습니다.