다른 배포 전략과 비교하여 AWS Elastic Beanstalk의 장단점은 무엇입니까?

Netflix OSS 스택 전체와 배포에 익숙하지 않습니다. 현재 현명한 지식 수준에 대한 배경으로서, 제 주된 역할은 프론트 엔드 애플리케이션 엔지니어입니다. 그러나 저는 운영 측면이 즐겁기 때문에 새로운 배포 전략과 새 프로젝트를위한 도구를 설정하려고합니다.

우리의 목표

• 매우 손쉬운 배포 (버튼을 눌러 프로덕션 업데이트)
• 테스트 환경에 자동 배포 (Jenkins 사용)
• 손쉬운 유지 보수 (작성할 앱이 있으며 생산 문제를 처리하는 데 시간을 허비하고 싶지 않음)
• 서비스 지향 아키텍처 (많은 소규모 앱, 다양한 언어 및 데이터 저장소)를 처리하는 기능
• 조만간 전략을 변경할 필요가없는 충분한 유연성 (이미 RightScale에서 벗어나려고합니다)

이렇게하면 초기 설정 시간이 조금 더 길어질 경우 나중에 두통을 덜 수 있습니다.

따라서이 라인을 따라 팟 캐스트를 듣고 Ops 강의를보고 수많은 블로그 게시물을 읽었으며 목표와 모범 사례를 형성하기 위해 취한 사항을 바탕으로 다음과 같은 계획을 세우기 시작했습니다. 마찬가지로 패키지를 jar로 롤링하고 AMI로 롤링합니다.

우리는 이것을 모두 계획하고 Chef 서버를 사용하고 인스턴스를 즉석에서 수렴하는 것과 비교할 때의 이점을 좋아했습니다 (우리는 제한된 타임 라인과 Chef 서버 워크 플로에 대한 이해 부족으로 인해 오류가 발생하기 쉽다고 생각했습니다). 그러나 동료는 자신을 둘러 보았고 Elastic Beanstalk가 우리의 요구를 충족시키는 것처럼 느꼈습니다.

나는 그것을 조사하고 WAR 파일과 첨부 RDS 데이터베이스로 테스트 환경을 회전시켰다. 문제가없는 것 같고 AWS API를 통해 Jenkins를 사용하여 테스트 환경에 배포를 자동화 할 수 있다고 생각합니다. 충분히 간단 해 보인다 ... 아마도 너무 단순하다.

내가 궁금한 것은 캐치가 무엇입니까? Elastic Beanstalk가 매우 간단하고 효과적이라면 왜 더 이야기하지 않습니까? 두 가지 배포 전략에 대한 객관적인 의견과 사실을 찾는 데 어려움을 겪고 있습니다.

Elastic Beanstalk를 사용하십니까? 그렇다면 왜 그리고 어떤 요인들이 그 결정을 이끌어 냅니까? 무엇을 좋아하고 싫어합니까?

Elastic Beanstalk를 사용하지 않고 고려한 경우 무엇을 사용하고 왜 Elastic Beanstalk를 사용하지 않았습니까?

SOA를위한 Elastic Beanstalk 기반 배포 전략의 장단점은 무엇입니까? 즉, Elastic Beanstalk는 서로 의존하는 많은 소규모 응용 프로그램에서 제대로 작동합니까?

수동 롤링 AWS 인스턴스를 개선하는 동안 다른 AWS 제품 외에도 Elastic Beanstalk를 평가했습니다. 내가 사용하지 않기로 선택한 이유는 기존 애플리케이션을 제공하지 않고 기존 애플리케이션을 마이그레이션하는 데 따른 합병증 때문이었습니다. 중요한 것은 서버의 응용 프로그램 배포 / 구성에 대해 많은 제어 권한이 없다는 것입니다. 새 응용 프로그램을 시작하는 경우 지금 당장 그러한 것들을 다루지 않는 것이 도움이 될 수 있습니다. 기존 응용 프로그램이 있으면 Beanstalk 모델에 맞추기가 더 어려워집니다.

Beanstalk는 Heroku 및 기타 PaaS 공급 업체와 유사한 오퍼링을 제공하지만 애플리케이션 작성에만 집중하려는 사람들에게는 큰 이점이 없습니다. 최소한 다른 PaaS 공급 업체보다 가상화 된 리소스를 더 많이 결정해야합니다.

내 응용 프로그램에서 발생한 문제 :

• 힘내 기반 배포-나는 그들을 사랑하지만 우리의 저장소는 1 + GB입니다. 오히려 정기적으로 밀어 넣으십시오. 이 저장소에는 약 40 개의 응용 프로그램 (실제로 분할되어야 함)이 포함되어 있지만 시간이 다소 걸립니다. 모든 종류의 패키지를 업로드하면 작동하지만 대부분의 응용 프로그램은 패키지로 만들기 위해 많은 양의 작업이 필요합니다.

• 다른 서비스와의 통합-내가 본 것에서 Beanstalk는 연결하려는 모든 것이 단일 서비스라고 가정합니다. 서비스가 뒤쳐져 있고 ELB이지만 각 응용 프로그램 서버에서 HAProxy를 실행하는 별도의 노드 인 경우에는 잘 작동합니다. 데이터 저장소 및 기타 서비스를 단일 엔드 포인트로 실행중인 경우 문제가 없습니다.

내 평가에는 OpsWorks와 CloudFormation도 포함되었습니다. OpsWorks에는 기존 자동화가 이러한 응용 프로그램에서 작동하는 방식과 유사한 통합 문제가 있습니다. CloudFormation은 일부 Python 스크립트와 Chef가 이미 우리를 돌보는 것 이상을 수행하지 않았습니다.

Asgard에서 제공하는 일부 자동화 기능 대신 AWS Autoscaling Groups를 사용하기로 결정했습니다 . 이는 기존 구성 / 애플리케이션 코드에서 가장 작은 변화였으며 AWS API를 통해 사용 가능한 여러 서버를 간단하게 관리 할 수있는 이점을 제공했습니다.

애플리케이션에 대한 Elastic Beanstalk의 제한 사항은 매우 유용합니다. 애플리케이션이 대부분 상태 비 저장이고 서비스에 대한 엔드 포인트를 제공하며 상태에 대한 다른 서비스에 의존하는지 확인해야합니다. Beanstalk의 여러 애플리케이션이 재사용 가능한 독립형 서비스를 작성하려는 경우 훌륭한 시작입니다.

더 많은 구성을 원하는 시점에 도달하면 OpsWorks는 다음 단계입니다. 사전 정의 된 역할을 통해 전환을 쉽게 시작할 수 있으며 Chef를 중심으로 자동화 프레임 워크를 제공하여 여러 서버의 프로비저닝을 조정할 수 있습니다.

나는 통제력 상실의 지점을 보았지만 반드시 위임 된 무국적 상태를 볼 필요는 없습니다. 실제로 모든 것은 자동화를 배치하는 것입니다. 큰 저장소의 요점이 보입니다. 나는 일반적으로 논리적 앱 기능을 별도의 빈 앱으로 분리 한 다음 "스테이징"및 "prod"환경을 가지고 있다고 생각합니다. 업 로더와 같은 모듈 환경이 있지만 그다지 많지 않으며 이론적으로 많은 비용이 들지만 u는 더 작은 인스턴스를 사용하고 있습니다. 우리는 중앙 집중식 nginx를 실행했으며 ngnix에 자동 스케일 정책의 변경 사항을 알리기 위해 많은 사용자 정의 sns 메시지 핸들을 작성해야했습니다. 또 다른 큰 문제는 ngnix를 사용하기 때문에로드 밸런싱을 방해 할 수 없다는 것입니다. 왜 그렇습니까? elb는 웹 소켓을 지원하지 않습니다.