Elastic Beanstalk는 엔터프라이즈 급 CD에 적합합니까?

Jenkins를 사용하여 마이크로 서비스를 Elastic Beanstalk에 빌드하고 배포하는 프로젝트로 작업하고 있습니다. 테스트 환경에 통합 브랜치를 배포하고 준비 환경에 브랜치를 릴리스 한 다음 최종 마스터 빌드를 프로덕션에 빌드합니다. 나는 이런 식으로 그것을하는 데 두 가지 우려를 가지고 있습니다. 첫째, 환경마다 프로젝트 당 하나의 빌드로 구성되어 노력이 중복됨을 의미합니다. 둘째, 스테이징에서 검증 된 프로덕션에 동일한 빌드 아티팩트를 배치하지 않음을 의미합니다.

Beanstalk를 포기하고 배포를 위해 Chef와 같은 것을 사용하여 일반 ASG로 이동하려고합니다. 그러면 프로젝트 당 하나의 빌드가 생성되어 빌드 아티팩트가 생성되며 스테이징에서 승인 된 프로덕션에 동일한 아티팩트를 배치 할 수 있습니다. 그러나 전환에는 별다른 선불 비용이 없습니다. 보다 안정적이고 관리하기 쉬운 CI / CD를 허용하는 Beanstalk를 더 잘 사용할 수있는 방법이 있습니까?

참고 : 동일한 빌드 아티팩트를 홍보하는 것은 정확히 내가하고 싶은 일이지만 문서에서는 분명히 할 수있는 방법이 없습니다. 앱 소스에서 EB에 배포하는 방법을 설명하지만, 바로 스크롤하지 않는 한 기존 버전을 다른 환경으로 승격시키는 방법은 설명하지 않습니다. EB 자체에서 사용할 수있는 경우 Jenkins EB 배포 플러그인에는 Jenkins에서 구체적으로 수행되지 못하게하는 제한이있을 수 있지만 전혀 할 수있는 방법을 보지 못했습니다.

IMO는 귀하의 문제가 해당 시나리오의 Elastic Beanstalk와 관련이 없으며 Jenkins 또는 적어도 사용 방법과 관련이 있다고 생각합니다. 그 물건이 무엇인지에 관계없이 "물건"을 한 번만 만드는 데 집중해야합니다.

전체 공개 : 나는 ThoughtWorks에서 일하고 있으며 GoCD에 엄청나게 편향되어 있습니다. 나는 내가 할 수있는 한 중립이라는 의미를 철자하려고 노력할 것이다. 도구의 문서를 예로 사용하지만 사람들이 자신의 시스템을 외삽 할 수 있기를 바랍니다.

파이프 라인 초기에 "아티팩트"를 작성하고 있습니다. 응용 프로그램의 전체 또는 일부를 나타내는 이진일 수도 있고 테스트 도구와 같은 여러 도구에서 출력 될 수도 있습니다. 이러한 아티팩트는 시스템에서 저장 해야하며 다시 빌드되지 않아야합니다. 그런 다음 시스템은 필요할 때 적절한 개정판에서 아티팩트를 가져와야합니다.

예를 들어 ...

1. .jar 파일을 빌드하고 기본 C / I 관련 요소 테스트를 수행합니다. 통과하면 해당 .jar 파일과 테스트 출력이 해당 특정 파이프 라인 작업에 업로드됩니다 .
2. 다음 파이프 라인은보다 복잡한 테스트 환경에 배포 할 수 있습니다. 빌드 한 정확한 작업 에서 정확한 jar를 가져와야합니다 . 그런 다음 Elastic Beanstalk를 실행하여 해당 jar을 올바른 환경에 배포합니다.
3. 다음 파이프 라인은 준비 배포입니다. 그것은 첫 번째 파이프 라인으로 돌아가서 그것을 만든 정확한 작업 에서 정확한 항아리를 가져옵니다 . 그런 다음 executus Elastic Beanstalk에서 해당 jar을 올바른 환경에 배포합니다.

이들은 각각 별도의 파이프 라인으로, 블로킹없이 더 많은 병렬 또는 주문형 으로 실행할 수 있습니다 .

Elastic Beanstalk, Chef, Puppet, Ansible, uDeploy 또는 기타 여러 도구를 사용하여 실제 배포를 수행 할 수 있습니다. 여기서 문제가 발생하지 않습니다. Continuous Integration 서버는이를 위해 원래 구축되지 않았습니다. 물론 선호하는 경우 동일한 장소에 도달하는 데 사용할 수있는 플러그인이 많이 있습니다.

GoCD , Chef Automate 및 ConcourseCI 와 같은 Continuous Delivery 서버는 이와 같은 문제를 해결하기 위해 특별히 제작되었습니다.