Skutecznie wdrażaj wiele wystąpień tego samego WAR (różne konteksty, ten sam kontener)

Question

Mam jedną WAR (app.war) i jeden kontener (Tomcat, Jetty, Glassfish, cokolwiek). Moim celem jest wdrożenie na żądanie setek instancji tej samej aplikacji internetowej na kontenerze.

http://foo/app1 --> app.war 
http://foo/app2 --> app.war 
http://foo/app3 --> app.war 
... 
http://foo/appN --> app.war 

Niektóre oczywiste sposoby osiągnięcia tego celu:

• W Tomcat, tworzą jeden plik context.xml dla każdej aplikacji (o nazwie appN.xml), wszystko wskazuje na samej wojnie. Inne pojemniki mają podobne metody
  • problem z tym podejściem: Będzie wybuch wojny N razy, zajmując dużo miejsca na dysku
• Użyj dowiązania symboliczne do tworzenia webapp/{App1, App2, APPN} foldery wskazując na wybuchową wersję app.war. Zapobiega to eksplozji miejsca na dysku, ale JVM wciąż ładuje wiele duplikatów JAR do pamięci.
• Użyj współdzielonego folderu lib, aby zawierał większość słoików (i kombinację dwóch poprzednich opcji).

Zastanawiam się, czy istnieje lepsza metoda, aby to zrobić. W idealnej sytuacji utworzenie nowej instancji nie powinno zajmować więcej miejsca na dysku (poza marginalnymi plikami konfiguracyjnymi) i zajmować tylko pamięć związaną ze stosami wykonania wątków i innymi alokacjami środowiska wykonawczego.

Wszelkie pomysły?

Answer 1

Jetty dodał wsparcie dla tego, czego szukałeś przez jakiś czas, z tak zwanymi nakładkami.

http://wiki.eclipse.org/Jetty/Tutorial/Configuring_the_Jetty_Overlay_Deployer

Kopiowanie nieco od strony wiki:

• można zachować plik WAR niezmienne, nawet podpisana, więc oczywiste jest, która wersja zostały wdrożone.
• Wszystkie modyfikacje dokonane w celu dostosowania/skonfigurowania aplikacji internetowej są oddzielnymi WARami, a zatem można je łatwo zidentyfikować w celu przejrzenia i migracji do nowych wersji.
• Można utworzyć sparametryzowaną nakładkę szablonów, która zawiera typowe dostosowania i konfiguracje, które mają zastosowanie do wielu wystąpień aplikacji internetowej (na przykład w przypadku wdrożenia z wieloma dzierżawcami).
• Ponieważ rozmieszczenie warstwowe jednoznacznie identyfikuje komponenty wspólne i specyficzne dla danej instancji, Jetty może współużytkować moduły ładujące klasy i pamięci podręczne zasobów dla szablonu, znacznie zmniejszając ślad pamięci wielu instancji.

Answer 2

Można skonfigurować Apache na interfejsie użytkownika (mod_proxy/mod_proxy_ajp), aby wskazywać na nazwy wirtualnych hostów na pojedynczą operację WAR wdrożoną na serwerze Tomcat. Twoja aplikacja powinna być zaprojektowana/napisana w taki sposób, aby obsłużyć wszystkie żądania - na nazwę strony konkretna konfiguracja może być przechowywana w bazie danych lub jako plik konfiguracyjny w aplikacji - Twoja aplikacja będzie po prostu musiała sprawdzać nazwę domeny żądającej użytkownika upewnij się, że ustawienia są poprawne (raz na sesję). Ogólnie mówiąc, powinieneś być w stanie rozwiązać to za pomocą jednej aplikacji. Świetni programiści są LAZY.

Answer 3

Jeśli dotyczy to eksperymentu, każda z wymienionych metod może działać.

Jeśli jest to przeznaczone do produkcji, polecam od tego. Chociaż nie przetestowałem WSZYSTKICH pojemników, używane przeze mnie pojemniki sprawiły, że uważam, że jest o wiele bardziej odporne na proste dostarczanie bezgłowych maszyn wirtualnych z kontenerami. Maszyny wirtualne systemu Linux mogą być bardzo małe, a dzięki technologii VM można dodawać lub odejmować tyle instancji, ile potrzeba.

Jeśli naprawdę chcesz mieć dynamicznie rozwijające się rozwiązanie, powinieneś poszukać wyeliminowania pojedynczych punktów awarii, a następnie spróbować zjednoczyć cały świat w jeden.

Jeśli naprawdę potrzebujesz "do drugiego" rozszerzenia/kurczenia obciążenia, powinieneś spojrzeć na AWS lub CloundFoundry.

Answer 4

Jeśli korzystasz z Jetty, możesz programowo dodawać konteksty.

WebAppContext webapp = new WebAppContext(); 
webapp.setBaseResource(myBaseDirectory); 
webapp.setContextPath(myContextPath); 

Po prostu wykonaj to w pętli dla wszystkich kontekstów. Powinien mieć blisko zerowej przestrzeni dyskowej.

Jest prawdopodobnie podobny sposób na zrobienie tego w Tomcat.

Answer 5

Przepraszamy za bycie nieco nietypowym, ale moim zdaniem scenariusz krzyczy "multi-tenancy" aplikacji, tak, że masz jedną aplikację, która będzie obsługiwać wielu "najemców" (klientów).

W odniesieniu do konfiguracji multi-najmu, poniższe rozważania musiałby uznać:

• Klienci nie mogą uzyskać dostęp nawzajem danych (jeśli dane są przechowywane w tej samej bazie danych, sam schemat i za pomocą " dyskryminator "w celu oddzielenia danych). Można to osiągnąć za pomocą Spring Security z Access Control Lists
• Hibernate ma wbudowaną wersję support for multitenancy apps z wersji 4.0.
• Te dwa SO pytania mogą być przydatne także
  • Multiple Entity Manager issue in Spring when using more than one datasource (za korzystanie z różnych źródeł danych (różne bazy danych lub po prostu różne schematy na tej samej bazie danych za klienta).
  • Multi tenancy support in Java EE 6

Korzyści z wielodostępności:

• Współdzielony kod oznacza, że ​​błąd ustalony dla jednego klienta jest ustalony dla wszystkich (może to być również niekorzystne, jeśli różni klienci mają różne poglądy na temat tego, co stanowi błąd i co stanowi cechę).
• Instalacja klastrowa może dzielić obciążenie między klientami (należy jednak upewnić się, że maksymalna pojemność jest dostępna dla wszystkich klientów).

Wady:

• Kod będzie nieco bardziej złożone, jak kwerendy należy się upewnić, że „dyskryminacja” między klientami działa bez przypadkowym ruchom narażając klientów na każdym innym danych.