Własna dystrybucja Karaf

We wcześniejszym wpisie o ServiceMix napisałem, że warto jest budować swoją własną dystrybucję zamiast opierać się na gotowym ServiceMix. Powodów jest kilka, ale według mnie najważniejszy z nich jest taki, że własna dystrybucja może być znacznie lżejsza lub lepiej dopasowana do aplikacji, którą zamierzamy uruchomić. Ważne jest też to, że gotowa dystrybucja z preinstalowaną aplikacją pozwala oszczędzić czas na pisanie instrukcji instalacji dla administratorów i jest w zasadzie samo-wystarczalna: wszystkie zależności powinny (teoretycznie) znaleźć się wewnątrz dystrybucji.

W przykładzie posłużę się najnowszą w chwili obecnej wersją Apache Karaf 3.0.1. Ale na początek, warto wspomnieć, co tak naprawdę wchodzi w skład dystrybucji Apache Karaf.

Struktura dystrybucji

W zasadzie każda dystrybucja Apache Karaf (niezależnie czy jest to właśnie czysty Karaf czy ServiceMix) wygląda identycznie. Po rozpakowaniu archiwum z dystrybucją dostajemy kilka katalogów jak w przykładzie:

Katalog bin zawiera skrypty uruchomieniowe dla unix/windows, katalog data zawiera cache, logi i inne pliki generowane w trakcie działania kontenera, deploy jest to katalog skanowany na obecność artefaktów, które mogą być automatycznie instalowane, etc zawiera konfigurację kontenera, lib podstawowe biblioteki OSGI i najważniejszy w każdej dystrybucji: system zawiera lokalne repozytorium maven, skąd mogą być instalowane kolejne bundle i feature'y. I to właśnie system jest tym, co nas najbardziej interesuje, bo przygotowując dystrybucję decydujemy które bundle i feature'y będą umieszczone w repozytorium system, oraz które z nich będą automatycznie uruchamiane. A wszystko to dzieje się z wykorzystaniem karaf-maven-plugin. Ale zanim dojdziemy do jego użycia, pokażę wykorzystywaną przeze mnie strukturę projektu Maven.

Struktura projektu

Jak to zwykle w korporacjach, obowiązującym standardem jest Maven wykorzystywany do budowania wielomodułowych projektów. Konkretna struktura projektu wygląda mniej więcej tak:

Projekt główny podzielony jest zwykle na 2 moduły: assembly, który zawiera kolejne moduły związane z budowaniem dystrybucji oraz services, który zawiera konkretne usługi wchodzące w skład dystrybucji. W omawianym przykładzie services zawiera tylko jeden projekt z prostym użyciem Apache Camel, które ma na celu tylko i wyłącznie pokazać, że się zainstalowało i działa.

Przykładowy przepływ będzie co wskazany interwał logował na konsolę. A teraz najważniejsze, czyli jak spakować to w gotową dystrybucję.

Budowa dystrybucji

Dystrybucję buduje się w dwóch etapach: pierwszy polega na zebraniu wszystkich naszych usług w grupę feature, drugi polega na przyłączeniu naszego feature do budowanej dystrybucji.

Pierwszy etap, zebranie usług w grupy realizuje się przez utworzenie modułu budującego feature lub KAR (KAR to jest archiwum jar zawierające spakowane bundle opisane przez feature - rzecz specyficzna dla Karaf). Ja zwykle stosuję metodę budującą archiwum KAR, gdyż po drodze i tak powstaje feature, a dostaję jeszcze automatycznie archiwum KAR, które przydaje się czasem przy innych sposobach deploymentu.

W przykładowym projekcie, moduł assembly/custom-feature realizuje funkcję grupującą usługi. Jest to projekt wygenerowany z archetypu karaf-kar-archetype i jego pom.xml wygląda mniej więcej tak:

Na uwagę zasługują 2 szczegóły: typ projektu określony na kar oraz wykorzystanie pluginu karaf-maven-plugin, który obsługuje generowanie pliku feature.xml i archiwum KAR.

Jedynym elementem źródłowym tego projektu jest plik src/main/feature/feature.xml, w którym opisana jest przykładowa usługa wraz z jej zależnościami (w tym przypadku jest to camel-blueprint):

Drugi etap, najciekawszy z tego wszystkiego, realizowany jest w module assembly/custom-distro, a wygenerowany z wykorzystaniem archetypu karaf-assembly-archetype. Jego pom.xml wygląda następująco:

Jest to projekt typu karaf-assembly obsługiwany przez karaf-maven-plugin do budowania dystrybucji. Zależności tego modułu zawierają przede wszystkim odniesienia do plików feature.xml, z których chcemy preinstalować paczki wchodzące w skład naszej dystrybucji:

Na liście zależności znajduje się podstawowy kar ze szkieletem Karafa (framework) oraz pliki feature.xml pochodzące z Karafa, Camela i naszego modułu custom-feature.
Dalej pozostaje tylko wybrać, które konkretne features mają zostać preinstalowane. Dzieje się to w konfiguracji karaf-maven-plugin:

Jeśli wszystko jest gotowe, można zbudować projekt (mvn install) i poszukać w custom-distro/target archiwum z dystrybucją, w naszym przypadku będzie to plik ./assembly/custom-distro/target/custom-distro-1.0.0-SNAPSHOT.tar.gz. Po rozpakowaniu i uruchomieniu powinniśmy móc sprawdzić jakie features i bundle zostały automatycznie uruchomione:

Jak widać, custom-feature jest na liście features, Sample-Service jest na liście aktywnych bundli, w logach można spodziewać się wpisów z aktywności usługi.

Wnioski

Dla mnie najważniejszy wniosek (i zarazem zaleta) budowania własnej dystrybucji jest taki, że dzięki temu możemy dostarczać gotowe rozwiązanie, którego nie trzeba instalować w pustym kontenerze. Koniec z pisaniem mozolnych instrukcji instalacji, możemy ograniczyć się do kilku słów instruktażu związanego z rozpakowaniem archiwum i uruchomieniem skryptu startowego. To skutkuje większą powtarzalnością procesu instalacyjnego i pozwala uniknąć nieprzyjemnych sytuacji podczas wdrożeń na produkcję, gdzie zawsze coś może pójść nie tak, jak byśmy chcieli.

Budowanie tego rodzaju własnych dystrybucji jest małym kroczkiem w kierunku immutable deployments, o którym być może kiedyś coś napiszę. A następnym razem, pokażę jeszcze inny sposób przygotowania własnego distro oparty o Docker i obrazy kontenerów :)

Źródła przykładowego projektu znajdują się na githubie.

Komercyjne wsparcie dla serwerów JEE

Przy okazji kolejnej oferty dla klienta musiałem wybrać serwer aplikacyjny. Oczywiście taki serwer musi być bezpieczny, zgodny i certyfikowany z JEE 7 no i ... ewentualnie komercyjnie wspierany ? Do tego dochodzi fakt, że jeśli klient nie nalega to nie oferuję totalnie komercyjnych rozwiązań z zamkniętymi źródłami, częściej wybieram platformę open-source z ewentualnym wsparciem w postaci jakiejś subskrypcji. No to mając takie wymagania wybór w zasadzie może paść na tylko na Glassfish lub Wildfly (jestem świadom faktu, że istnieją jeszcze inne serwery typu Tomee, Jonas czy Geronimo, ale nie wspierają jeszcze JEE 7).

No więc, co tu wybrać? Glassfish czy Wildfly? W zasadzie oba serwery oferują to samo, oba są open-source i pozbawione jakiegokolwiek wsparcia poza typowym dla OS community. Szukając kolejnych informacji do porównania natknąłem się na dość stary już news, że Oracle wycofuje wsparcie komercyjne dla Glassfish. I nagle wszyscy na blogach piszą, że Glassfish umarł. Arun Gupta (jeszcze niedawno promotor Glassfish) proponuje przejście na Wildfly lub JBoss EAP bo są lepsze i komercyjnie wspierane. Ale czy na pewno ? Wildfly 8.x jest oczywiście zgodny z JEE 7, ale nikt nie daje na niego żadnego wsparcia. Kiedyś będzie z niego być może JBoss EAP 7, ale to pieśń przyszłości. Obecny w tej chwili JBoss EAP 6.x jest wspierany, ale znów zgodny tylko z JEE 6.

Mój wniosek jest więc taki: zarówno RedHat jak i Oracle mają w ofercie serwery zgodne z JEE 7, ale pozbawione wsparcia, oraz serwery ze wsparciem zgodne tylko z JEE 6: Oracle Weblogic 12 i JBoss EAP 6. Eh, odrobina marketingu i zamieszanie gotowe :) Jedyna zaleta Wildfly jaką widzę, to że migracja z Wildfly 8 na JBoss EAP 7 będzie potencjalnie łatwiejsza niż z Glassfish na Weblogic. Więc pewnie wybiorę Wildfly.

Koniec przygody z ServiceMix ?

Jak to koniec z ServiceMix ?

Kolejny klient, kolejna platforma integracyjna do wdrożenia. Niejako wyspecjalizowałem się co nieco w integracji opartej o rozwiązania open-source (jakoś tak już mam, że nie lubię płacić za soft), a w szczególności rodzinę Apache ServiceMix, Camel, ActiveMQ i tak dalej. Zwykle moje projekty oparte były o którąś konkretną wersję ServiceMix, na którym instalowałem swoje paczki/bundle i ewentualne brakujące zależności. W ostatnim czasie dotarło do mnie, że ServiceMix to nic innego jak specyficzna dystrybucja Apache Karaf z preinstalowanymi: ActiveMQ, CXF, Camel i ostatnio Activiti. Cała reszta w zasadzie już wyleciała, mam tu na myśli wsparcie dla JBI (ktoś jeszcze używa?) i NMR, którego w wersji 5 już chyba nie ma. Więc w zasadzie, ServiceMix daje mi całkiem mało. Do tego dochodzi cykl wydawniczy, który jest z lekka opóźniony w stosunku do całej reszty. Jak się chce użyć nowszego Camel’a, to trzeba czekać X czasu aż pojawi się nowe wydanie ServiceMix. W zasadzie wystarczyłoby mi już powodów, aby odejść od używania ServiceMix, ale pojawił się jeszcze RedHat, który kupił FuseSource, zrobiło się zamieszanie i skończyło się wsparcie dla ServiceMix wydawanego przez FuseSource (pod nazwą FuseESB). Pojawił się oczywiście JBossFuse, ale to nie zupełnie to samo. Więć kończę z ServiceMix, pewnie na zawsze.

Więc może Fabric8 ?

Skoro nie ServiceMix, to może coś nowego? Pojawił się Fabric8, projekt open-source sponsorowany przez RedHat, rozwijany przez tą samą ekipę co Camel, ActiveMQ i kiedyś ServiceMix. Brzmi interesująco, centralny rejestr konfiguracji w ZooKeeperze, instalowanie kontenerów przez SSH w sieciach lokalnych i w chmurze, jest też wsparcie dla Docker i nowiutka konsola oparta o Hawtio. Sęk w tym, że to już nie jest tylko kontener OSGI z preinstalowanymi bundlami Camela i CXF. Pojawia się właśnie ZooKeeper, pojawia się ConfigAdmin, który korzysta z Git'a, są rozbudowane profile kontenerów, Karaf jest już tylko jedną z opcji - bo można uruchamiać też gołe aplikacje Javy, SpringBoot, Tomcata i WildFly. Ma to związek z microservices - bo ponoć uberjar SpringBoot jest bardziej micro od usługi na OSGI :) Niee, to nie dla mnie. Integracja sama w sobie jest tak skomplikowana, że dorzucanie tak złożonej machiny raczej nie poprawi sytuacji. Integrację należy upraszczać ! Fabric8 jak dla mnie jest zbyt skomplikowany.

Własne distro ?

I tu pojawia się pytanie: Co dalej? Skoro ServiceMix nic mi nie daje, a Fabric8 przytłacza złożonością, jakie są dalsze opcje? Okazuje się, że własna dystrybucja Karaf'a jest odpowiedzią! Karaf daje wszystko co jest potrzebne aby taką dystrybucję wykonać: jest karaf-maven-plugin, są przykłady, nic nie stoi na przeszkodzie, aby wykroić dokładnie taki runtime jaki jest nam potrzebny. Żadnych brakujących ani nadmiarowych zależności, możliwość preinstalowania własnych paczek z integracją i usługami, żyć nie umierać! Jest to bardzo wygodne, bo można totalnie pominąć proces deploymentu aplikacji w kontenerze: build maven kończy się po prostu wygenerowaniem preinstalowanej dystrybucji ze wszystkim co jest potrzebne. Nic nie stoi na przeszkodzie, by nawet w ramach jednego projektu generować kilka dystrybucji podzielonych w/g wymagań funkcjonalnych.

Jak mi sił wystarczy, to następnym razem opiszę jak taką dystrybucję przygotować. Howgh !