AWS Elastik Beanstalk'ın diğer dağıtım stratejileri ile karşılaştırıldığında artıları ve eksileri nelerdir?

Genel olarak tüm Netflix OSS yığını ve dağıtımları için oldukça yeniyim. Mevcut bilgi seviyem için bir arka plan olarak, asıl görevim bir ön uç uygulama mühendisi olarak. Ancak, şeylerin operasyon tarafını seviyorum, bu yüzden yeni bir dağıtım stratejisi ve yeni bir proje için araçlar oluşturmaya çalışıyorum.

Hedeflerimiz

• Süper kolay dağıtımlar (üretimi güncellemek için bir düğmeye basmak istiyoruz)
• Test ortamlarını otomatik olarak dağıtır (Jenkins kullanarak)
• Bakım kolaylığı (yazmak için bir uygulamamız var, zamanımızı üretim sorunları ile uğraşmak istemiyoruz)
• Hizmet odaklı bir mimariyi (birçok küçük uygulama, çeşitli dil ve veri deposu) kullanabilme
• Yakında stratejileri değiştirmek zorunda kalmayacağımızdan emin olmak için yeterli esneklik (zaten RightScale'den uzaklaşmaya çalışıyoruz)

Gelecekte biraz baş ağrım kurtaracaksa, biraz daha başlangıç ​​kurulum süresi ile iyiyiz.

Bu nedenle, bu satırlarda, podcast dinledim, Ops görüşmelerini izledim ve tonlarca blog yayını okudum ve hedeflerimize ve en iyi uygulamaları oluşturan bazı şeylere dayanarak aldım, kullanarak bir plan oluşturmaya başladık. Asgard, paketimizi bir kavanoza ve bir AMI'ye yuvarlıyor.

Biz tüm planlanan vardı ve avantajları gibi bir Şef sunucu kullanarak ve anında örnekleri yakınlaştırma (avantajları gibi biz sınırlı zaman çizelgesi ve bir Şef sunucu iş akışı etrafında anlayış eksikliği göz önüne alındığında bu hata eğilimli olduğunu hissettim) vardı. Ancak, bir iş arkadaşı kendi başına biraz etrafa baktı ve Elastik Beanstalk'ın ihtiyaçlarımızı karşıladığını hissetti.

Ben içine baktım ve bir WAR dosyası ve ekli bir RDS veritabanı ile bir test ortamı açtım. İşler işe yarıyor gibi görünüyor ve Jenkins'i AWS API'sı kullanarak test ortamına otomatikleştirebileceğimize inanıyorum. Yeterince basit görünüyor ... belki de çok basit.

Merak ettiğim şey, yakalama nedir? Elastik Beanstalk çok basit ve etkili ise, neden daha fazla konuşulmuyor? İki farklı dağıtım stratejisi hakkında yeterli nesnel görüş ve gerçekleri bulmakta zorlanıyorum, bu yüzden etrafa soracağımı düşündüm.

Elastik Beanstalk kullanıyor musunuz? Eğer öyleyse, bu karara neden ve hangi faktörler yol açıyor? Ne seviyorsun ve ne sevmiyorsun?

Elastik Beanstalk kullanmıyorsanız ancak bunu düşündüyseniz, ne kullanıyorsunuz ve neden Elastik Beanstalk kullanmadınız?

Bir SOA için Elastik Beanstalk tabanlı dağıtım stratejisinin avantajları ve dezavantajları nelerdir? Yani, Beanstalk çalışmak için birbirine güvenen birçok küçük uygulama ile iyi çalışır mı?

El haddelenmiş AWS örneklerimizi geliştirmeye çalışırken, diğer AWS tekliflerine ek olarak Elastik Beanstalk'ı değerlendirdim. Kullanmamayı seçtiğim nedenler, mevcut başvurumu taşımayı içerecek ve teklifin kendisiyle değil komplikasyonlardan kaynaklanıyordu. Yakalama, sunucuların uygulama dağıtımı / yapılandırması hakkında çok fazla kontrole sahip olmamanızdır. Yeni bir uygulamaya başlıyorsanız, şu anda bu şeylerle uğraşmamak yararlı olabilir, mevcut bir uygulamanız varsa Beanstalk modeline uymak daha zordur.

Beanstalk, Heroku ve diğer PaaS satıcılarına benzer bir teklif sunar, ancak sadece uygulamalarını yapmaya odaklanmak isteyenler için pek bir fayda sağlamaz. En azından sanallaştırılmış kaynakları diğer PaaS satıcılarından daha yüksek bir dereceye kadar belirlersiniz.

Uygulamalarımda karşılaştığım sorunlar:

• Git tabanlı dağıtımlar - Onları seviyorum ama depomuz 1+ GB. Düzenli olarak itmek oldukça büyük. Bu repo ayrıca yaklaşık 40 uygulama içeriyor (ki bu gerçekten bölünmeli) ama biraz zaman alacaktı. Her türlü paketi yüklemek işe yarayabilir, ancak uygulamalarımızın çoğu bir pakete dönüştürmek için büyük miktarda çalışma gerektirir.

• Diğer hizmetlerle entegrasyon - Gördüğüm kadarıyla Beanstalk, bağlandığınız her şeyin tek bir hizmet olduğunu varsayar. Hizmetleriniz arkada ve ELB ise, ancak her uygulama sunucusunda çalışan HAProxy ile vurduğumuz ayrı düğümlerdeyse, bu iyi çalışır. Veri depolarınızı ve diğer hizmetlerinizi tek bir uç nokta olarak çalıştırıyorsanız, iyi olmalısınız.

Değerlendirmemde OpsWorks ve CloudFormation'ı da dahil ettim. OpsWorks, mevcut otomasyonun bu uygulamalar için nasıl çalıştığıyla benzer entegrasyon sorunlarına sahiptir. CloudFormation, bazı Python senaryolarının ve Şef'in bizim için zaten hallettiğinden daha fazlasını yapmadı.

Asgard tarafından sağlanan bazı otomasyonlar yerine AWS Otomatik Ölçeklendirme Gruplarını kullanmayı seçtim . Bu, mevcut yapılandırma / uygulama kodundaki en küçük değişiklikti ve aradığımız faydaları bize sağladı, AWS API'sı aracılığıyla kullanılabilen birden çok sunucunun basit yönetimi.

Elastik Beanstalk tarafından uygulamanıza getirilen kısıtlamalar çok faydalıdır. Başvurunuzun çoğunlukla vatansız olduğundan, bir hizmet için bir uç nokta sağladığından ve eyalet için diğer hizmetlere güvendiğinden emin olmanız gerekir. Beanstalk'ta birden fazla uygulamanın harika bir başlangıç ​​olduğu yeniden kullanılabilir bağımsız hizmetler yapmaya çalışıyorsanız.

Eğer daha fazla yapılandırma istemek istediğinizde / ne zaman giderseniz OpsWorks harika bir sonraki adımdır. Önceden tanımlanmış roller, geçişin başlamasını kolaylaştırmalıdır ve birden çok sunucunun sağlanmasını koordine etmeye yardımcı olmak için Chef çevresinde bir otomasyon çerçevesi sağlar.

Kontrol kaybı noktasını görüyorum, ama zorunlu olarak vatansızlığı görmüyorum. Tüm eb gerçekten yaptığı otomasyon dağıtmak, bu arada harika. Büyük bir deponun amacını görüyorum. Genel olarak, mantıksal uygulama işlevlerini ayrı fasulye uygulamalarına ayırmanın ve daha sonra "evreleme" ve "prod" ortamlarının gerçekten güzel olduğunu düşünüyorum. Yükleyici gibi modül ortamlarımız var, çok fazla bir şey yapmıyor ve teoride çok fazla maliyet ekliyor, ancak daha sonra u daha küçük örnekleri kullanıyor. Merkezi bir nginx çalıştırdık ve otomatik ölçek politikasındaki değişikliklerin ngnix'ini bildirmek için çok sayıda özel sns ileti tutamağı yazmak zorunda kaldık. Bir diğer büyük eb sorunu, ngnix kullandığımız için yük dengelerini kapatamama, neden? dir, web soketini desteklemez.