Genel olarak tüm Netflix OSS yığını ve dağıtımlarında oldukça yeniyim. Operasyonel olarak şu anki bilgi seviyemin arka planı olarak, ana rolüm bir ön uç uygulama mühendisi olmaktır. Ancak, işlerin operasyon tarafını seviyorum, bu yüzden yeni bir proje için yeni bir dağıtım stratejisi ve araçları kurmaya çalışıyorum.

Hedeflerimiz

  • Süper kolay dağıtımlar (üretimi güncellemek için bir düğmeye basmak istiyoruz)
  • Ortamları test etmek için otomatik dağıtımlar (Jenkins kullanarak)
  • Bakım kolaylığı (yazacak bir uygulamamız var, zamanımızı üretim sorunlarıyla uğraşmak istemiyoruz)
  • Hizmet odaklı bir mimariyi idare edebilme (birçok küçük uygulama, çeşitli diller ve veri depoları)
  • Yakında herhangi bir zamanda stratejileri değiştirmek zorunda kalmamamızı sağlayacak kadar esneklik (zaten RightScale'den uzaklaşmaya çalışıyoruz)

Biraz daha başlangıç ​​kurulum süresi için sorun yok, eğer bunu yapmak gelecekte başımızı ağrıtacaksa.

Bu satırlar boyunca, podcast'leri dinledim, operasyon konuşmalarını izledim ve tonlarca blog yazısı okudum ve hedeflerimize ve en iyi uygulamalar olarak kabul ettiğim şeylere dayanarak, aşağıdakileri kullanarak bir plan oluşturmaya başladık. Asgard, paketimizi bir kavanoza ve onu bir AMI'ye yuvarlayarak.

Tüm bunları planladık ve bir Chef sunucusu kullanmaya ve anında yakınsak örneklere kıyasla sürecin avantajlarını beğendik (sınırlı zaman çizelgemiz ve bir Chef sunucusu iş akışını anlama konusundaki eksikliğimiz nedeniyle bunun hataya açık olduğunu hissettik). Ancak, bir iş arkadaşı kendi başına biraz etrafa baktı ve Elastic Beanstalk'ın ihtiyaçlarımızı karşıladığını hissetti.

Bunu araştırdım ve bir WAR dosyası ve ekli bir RDS veritabanı ile bir test ortamı oluşturdum. İşler yolunda görünüyor ve AWS API aracılığıyla Jenkins kullanarak bir test ortamına dağıtımları otomatikleştirebileceğimize inanıyorum. Yeterince basit görünüyor... belki de çok basit.

Merak ettiğim şey, ne var? Elastik Fasulye Sırığı bu kadar basit ve etkiliyse neden daha fazla konuşulmuyor? İki farklı dağıtım stratejisi hakkında yeterince nesnel görüş ve gerçek bulmakta zorlanıyorum, bu yüzden etrafa sorayım dedim.

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

Elastik Fasulye Sırığı kullanmıyorsanız ama bunu düşünüyorsanız, ne kullanıyorsunuz ve neden Elastic Beanstalk kullanmadınız?

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

answer

Elle haddelenmiş AWS bulut sunucularımızı iyileştirmeye çalışırken diğer AWS tekliflerine ek olarak Elastic Beanstalk'ı da değerlendirdim. Bunu kullanmamayı seçmemin nedenleri, teklifin kendisiyle değil, mevcut uygulamamı taşırken ortaya çıkabilecek komplikasyonlardı. Buradaki sorun, sunucuların uygulama dağıtımı / yapılandırması hakkında çok fazla kontrolünüz olmamasıdır. Yeni bir uygulama başlatıyorsanız, o zaman şu anda bunlarla uğraşmamanız yararlı olabilir, mevcut bir uygulamanız varsa, o zaman Beanstalk modeline uymak daha zordur.

Beanstalk, Heroku ve diğer PaaS satıcılarına benzer bir teklif sunar, ancak yalnızca uygulamalarını yapmaya odaklanmak isteyenler için pek bir faydası yoktur. En azından sanallaştırılmış kaynakları diğer PaaS satıcılarından daha büyük bir dereceye kadar belirlersiniz.

Uygulama(lar)ımda karşılaştığım sorunlar:

  • Git tabanlı dağıtımlar - Onları seviyorum ama depomuz 1+ GB. Düzenli olarak itmek için oldukça büyük. Bu depo aynı zamanda yaklaşık 40 uygulama içeriyor (ki gerçekten de bölünmesi gerekiyor), ancak bu biraz zaman alacaktı. Herhangi bir tür paketi yüklemek işe yarayabilir, ancak uygulamalarımızın çoğu, onu bir paket haline getirmek için büyük miktarda çalışma gerektirecektir.

  • Diğer hizmetlerle entegrasyon - Gördüğüm kadarıyla Beanstalk, bağlandığınız her şeyin tek bir hizmet olduğunu varsayıyor. Bu, hizmetleriniz gerideyse ve ELB'deyse, ancak her uygulama sunucusunda çalışan HAProxy aracılığıyla vurduğumuz ayrı düğümlerimizse işe yarar. Veri depolarınızı ve diğer hizmetlerinizi tek bir uç nokta olarak çalıştırıyorsanız, sorun değil.

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

Asgard tarafından sağlanan bazı otomasyonlar yerine AWS Autoscaling Groups kullanmayı tercih ettim . Bu, mevcut yapılandırma/uygulama kodunda yapılan en küçük değişiklikti ve bize aradığımız avantajları, AWS API aracılığıyla kullanılabilen birden çok sunucunun basit yönetimini sağladı.

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

Daha fazla yapılandırma isteme noktasına geldiğinizde OpsWorks, bir sonraki harika adımdır. Önceden tanımlanmış roller, geçişin başlamasını kolaylaştırmalı ve birden fazla sunucunun sağlanmasını koordine etmeye yardımcı olmak için Chef'in etrafında bir otomasyon çerçevesi sağlamalıdır.

Kontrol kaybı noktasını görüyorum, ancak zorunlu vatansızlığı görmüyorum. eb'nin gerçekten yaptığı tek şey, bu arada harika olan otomasyonu dağıtmaktır. 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 ardından "hazırlama" ve "ürün" ortamlarına sahip olmanın gerçekten güzel olduğunu düşünüyorum. Uploader gibi modül ortamlarımız var, pek bir şey yapmıyor ve teoride çok fazla maliyet ekliyor, ancak daha sonra daha küçük örnekleri sadece daha fazlasını kullanıyorsunuz. Merkezi bir nginx çalıştırıyoruz ve otomatik ölçeklendirme ilkesindeki değişiklikleri ngnix'e bildirmek için çok sayıda özel sns ileti tanıtıcısı yazmak zorunda kaldık. Bir başka büyük eb sorunu, ngnix kullandığımız için yük dengelerini kapatamama, neden? elb websocket'i desteklemiyor.