Rozmieszczanie aplikacji Java Server, które nie są .wars

Question

Czy istnieją dobrze zintegrowane stosy zarządzania aplikacjami, które umożliwiają tworzenie, wdrażanie i aktualizowanie aplikacji Java innych niż .war, które działają jako serwery? Na przykład wiadomości wiadomości, które są serwerami (ale nie serwerami WWW i nie mają serwletów) lub wykonywalne .jar s z osadzonym Jetty?

Budowa i wdrożenie .war S jest całkiem prosta: Maven ma archetyp wojennego, Jenkins ma kupę wtyczek do wdrażania .war plików do różnych serwerów aplikacji, które w większości akceptują wysyłanie nowych aplikacji internetowych w czasie wykonywania. Narzędzia takie jak Elastic Beanstalk upraszczają ten proces, wiążąc zarządzanie środowiskami serwerowymi.

W przeciwieństwie do rozmieszczania plików wykonywalnych .jar s wydaje się, jak ponowne wynalezienie koła. Trzeba opracować najlepszy sposób cieniowania zależności i tworzenia wykonywalnego artefaktu z mnóstwem wtyczek Mavena, gdzieś umieścić ten artefakt, a następnie znaleźć sposób na zainstalowanie go na docelowych serwerach i, jeśli to konieczne, zamienić go na nowy (pakiety Debiana byłby jednym ze sposobów robienia tego).

To wszystko wydaje mi się bardzo "ręczne" do tego stopnia, że ​​korzystne wydaje się wdrażanie aplikacji jako serwerów aplikacji, nawet jeśli nie są one naturalne, aby uzyskać korzyść z obsługi narzędzi.

Answer 1

Można to wdrożyć, wdrażając aplikacje w kontenerze osgi.

Można podłączyć się do cyklu życia osgi, aby uruchomić aplikację po uruchomieniu pakietu osgi. Następnie możesz zdalnie uruchomić i zatrzymać kontener (jeśli kontener obsługuje to).

Twoje aplikacje mogą określać ich zależności jako część manifestu osgi - ale cieniowanie słoików za pomocą wtyczki cienia nie jest trudne, gdy korzystasz z maven i myślę, że łatwiej byłoby zarządzać niż zajmować się setkami słoików w twoim pojemniku.

This question mówi o ciągłym wdrażaniu pakietów osgi przy użyciu jenkins.

Alternatywnym (i bardziej standardowym) sposobem byłoby pisanie skryptów automatyzujących wdrożenie - w miarę możliwości za pomocą specjalnie stworzonych narzędzi, takich jak puppet lub chef. Dla lalek istnieje maven plugin, która pozwala wyodrębnić artefakty z repozytorium maven do wykorzystania w twoich skryptach lalkowych.

Uruchamianie lalek lub Chef z jenkins jest trywialne, a jeśli chcesz, możesz zapewnić dostęp do buildów wdrażania nietechnicznym pracownikom, aby umożliwić im wdrażanie nowych kompilacji w środowisku za pomocą kliknięcia przycisku.

Tak, jak @bagheera sugeruje budowanie rpms aplikacji i uruchamianie ich jako usług, jest dobrym sposobem na zmniejszenie złożoności skryptów wdrażania.

Answer 2

Wygląda na to, że szukasz menedżera zależności do budowania samodzielnego pliku wykonywalnego jar i menedżera pakietów do wdrożenia. Poza narzędziami, o których wspomniałeś, możesz sprawdzić ant+ivy dla build + dependency mgmt i rpmbuild + rpm + yum dla zarządzania pakietami na Linux.