Katıştırılmış kapsayıcıyla çalıştırılabilir jar ile savaş dosyalarını dağıtma önerileri


89

Java alanında, java web uygulamalarını bir savaş dosyası (veya kulak dosyası) biçiminde bir java servlet konteynerine (veya uygulama sunucusuna) dağıtmaktan uzaklaşmak ve bunun yerine uygulamayı çalıştırılabilir bir jar olarak paketlemek için mevcut bir eğilim var gibi görünüyor. iskele gibi gömülü bir sunucu uygulaması / HTTP sunucusu. Ve bunu, uygulamaların son kullanıcılara nasıl teslim edildiğinden ziyade, yeni çerçevelerin yeni uygulamaların nasıl geliştirildiğini ve dağıtıldığını etkilemesi açısından daha çok demek istiyorum (çünkü örneğin, Jenkins'in neden gömülü bir kapsayıcı kullandığını anlıyorum, yakalanması çok kolay ). Çalıştırılabilir jar seçeneğini benimseyen çerçevelere örnekler: Dropwizard , Spring Boot ve Play (bir servlet konteyneri üzerinde çalışmaz, ancak HTTP sunucusu gömülüdür).

Sorum şu, uygulamalarımızı (bu noktaya kadar çoğunlukla Struts2) tek bir tomcat uygulama sunucusuna dağıttığımız bir ortamdan geliyorsa, gömülü bir konteyner yaklaşımını kullanmayı planlıyorsak hangi değişikliklerin, en iyi uygulamaların veya dikkate alınması gereken hususlar ? Şu anda, tek bir tomcat sunucusunda çalışan yaklaşık 10 evde büyüyen uygulamamız var ve bu küçük uygulamalar için kaynakları paylaşma ve tek bir sunucuda yönetilme yeteneği güzel. Uygulamalarımızın, ortamlarında çalışması için son kullanıcılara dağıtılması amaçlanmamıştır. Ancak, daha yeni bir java çerçevesinden yararlanmaya karar verirsek, bu yaklaşım değişmeli mi? Yürütülebilir kavanozlara geçiş, bulut dağıtımlarının artan kullanımı (örneğin, Heroku) tarafından teşvik edildi mi?

Tek bir uygulama sunucusunda geleneksel savaş dosyası dağıtımına karşı Play dağıtım stilinde birden fazla uygulamayı yönetme deneyiminiz olduysa, lütfen görüşlerinizi paylaşın.

Yanıtlar:


82

İlginç bir soru. Bu sadece konuyla ilgili görüşüm, bu yüzden her şeyi bir miktar tuzla alın. Zaman zaman uygulamaları hem servlet kapsayıcılarını hem de yerleşik sunucuları kullanarak konuşlandırdım ve yönettim. Eminim servlet kapları kullanmak için hala birçok iyi neden vardır, ancak bugün neden daha az popüler olduklarına odaklanmaya çalışacağım.

Kısa sürüm: Servlet kapsayıcıları, tek bir ana bilgisayarda birden çok uygulamayı yönetmek için harikadır, ancak tek bir uygulamayı yönetmek için pek kullanışlı görünmemektedir. Bulut ortamlarında, sanal makine başına tek bir uygulama tercih edilir ve daha yaygın görünür. Modern çerçeveler bulut uyumlu olmak istiyor, bu nedenle gömülü sunuculara geçiş.


Bu yüzden bulut hizmetlerinin servlet konteynerlerini terk etmenin ana nedeni olduğunu düşünüyorum. Tıpkı servlet konteynerlerinin uygulamaları yönetmenize izin verdiği gibi, bulut hizmetleri de sanal makineleri, örnekleri, veri depolamayı ve çok daha fazlasını yönetmenize olanak tanır. Bu kulağa daha karmaşık geliyor, ancak bulut ortamlarında tek uygulama makinelerine geçiş oldu. İşte bu gibi sık sık tüm makineyi davranabilirsiniz anlamına uygulaması. Her uygulama uygun büyüklükteki bir makinede çalışır. Bulut örnekleri, herhangi bir zamanda açılıp kaybolabilir, bu da ölçeklendirme için harikadır. Bir uygulama daha fazla kaynağa ihtiyaç duyarsa, daha fazla örnek oluşturursunuz.

Öte yandan, özel sunucular genellikle güçlüdür ancak sabit boyuttadır, bu nedenle kaynakların kullanımını en üst düzeye çıkarmak için tek bir makinede birden çok uygulama çalıştırırsınız. Düzinelerce uygulamayı - her biri kendi konfigürasyonlarına, web sunucularına, rotalarına ve bağlantılarına sahip - yönetmek eğlenceli değildir, bu nedenle bir servlet konteyneri kullanmak her şeyi yönetilebilir ve aklı başında tutmanıza yardımcı olur. Yine de ölçeklendirmek daha zordur. Buluttaki sunucu kapsayıcıları pek kullanışlı görünmüyor. Yalnızca tek bir uygulamayı yönettikleri için çok fazla değer sağlamadan her küçük örnek için kurulmaları gerekirdi.

Ayrıca, bulutlar havalıdır ve bulut olmayan şeyler sıkıcıdır (eğer hala aldatmacaya inanıyorsak). Birçok çerçeve varsayılan olarak ölçeklenebilir olmaya çalışır, böylece bulutlara kolayca dağıtılabilirler. Gömülü sunucular hızlı kurulur ve çalışır, bu nedenle makul bir çözüm gibi görünürler. Servlet kapsayıcıları genellikle hala desteklenir ancak daha karmaşık bir kurulum gerektirir.

Diğer bazı noktalar:

  • Gömülü sunucu olabilir çerçevesi için optimize edilebilir veya daha iyisi (örneğin oyun konsolu gibi) çerçeveler kalıp ile entegre edilmiştir.
  • Tüm bulut ortamları özelleştirilebilir makine görüntülerine sahip değildir. Servlet kapsayıcılarını indirmek ve kurmak için başlatma komut dosyaları yazmak yerine, bulut uygulama dağıtımları için özel yazılım kullanmak çok daha basittir.
  • Uygulamanızın her birkaç yeniden dağıtımında bir kalıcı alan alanı hatasıyla sizi karşılamayan bir Tomcat kurulumu henüz bulamadım . Herhangi bir kesinti olmadan aşamalı ve üretim örnekleri arasında neredeyse anında geçiş yapabildiğiniz zaman, yerleşik sunucuları (yeniden) başlatmak için biraz daha uzun sürmek sorun olmaz.
  • Soruda daha önce de belirtildiği gibi, son kullanıcının uygulamayı çalıştırması çok uygundur.
  • Gömülü sunucular taşınabilir ve geliştirme için uygundur. Bugün her şey hızlı , prototiplerin ve MVP'lerin olabildiğince hızlı oluşturulması ve teslim edilmesi gerekiyor. Hiç kimse her geliştirici için bir ortam oluşturmak için çok fazla zaman harcamak istemez.

1
Cevap verdiğin için teşekkürler, bazı iyi puanlar verdin Bulut, itici faktördür! Bizim durumumuzda, yalnızca bir uygulamayı Google App Engine (Hizmet Olarak Platform) dağıtmaktansa Amazon Web Hizmetleri modelinde (Hizmet olarak Altyapı) bir bulut sunucusuna sahip olmak kendimi daha rahat hissederdim, ancak sanırım bu eski düşünce okulu. Sonuç olarak, bir hizmet yolu olarak bir platformda bulutu kullanmayı planlamadığımız sürece, tek bir sunucuda birden fazla bağımsız java web uygulamasını yönetmek yerine savaş dağıtımları gidecek yoldur. Girişiniz için tekrar teşekkürler.
Brice Roncace

3
Yalnızca 2cc: proxy olarak hafif HTTP sunucusu olan tek bir makinede birden fazla jar uygulaması çalıştırabilirsiniz , yani: nginx, özel CDN, yük dengeleyici, güvenlik duvarı vb. Gibi tipik web trafiği için ek olarak kullanılabilir. Bu nedenle dikkate alınması mantıklıdır. büyük trafiği planlarken kullanmak (daha iyi performansa sahiptir, ardından her bir isteği yerine getirir - ana uygulamanız aracılığıyla statik kaynaklar için bile).
biesior
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.