Wybrałem się dzisiaj na prezentacje zatytułowaną „Fabric8. Bycie devOpsem nie musi być złe” i przeprowadzoną przez Henryka Konsek w ramach spotkań Warszawskiej Grupy Użytkowników Javy (WJUG) i Warszawskiej Grupy Użytkowników serwera JBoss (WJBUG).

Tytuł okazał się nieco mylący, bo miałem oczekiwanie że wykład będzie ogólniejszy, natomiast dotyczył wyłącznie opisu produktu Fabric8, którego współautorem jest Henryk. Prezentacja była fajnie i precyzyjnie poprowadzona, w krokach omawiając działanie frameworku do deploymentu aplikacji w środowiskach klastrowych. Słuchając kolejnych cech już się cieszyłem na myśl jak ewentualnie mogłaby ona rozwiązać nasze różne problemy, szczególnie spodobał mi się koncept automatycznego pobierania zależności z repozytorium mavena, bez konieczności budowania całego EAR’a. Jednak jak usłyszałem że do propagacji konfiguracji używany jest ZooKeeper, z którym mieliśmy w ostatnim roku spore problemy i z trudem się go pozbywaliśmy, to mój entuzjazm nieco przygasł :-).

Historia produktu jest taka, że został napisany kilka lat temu przez firmę FuseSource, przejętą dwa lata temu przez RedHat i przemianowany na Fabric8. Integruje w sobie inne produkty open source: Apache Camel, Apache ActiveMQ, Apache ServiceMix i Apache CXF.

Opis tego co będzie deployowane i od czego zależy jest zawierany w profilach (trzymanych w GIT), a Fabric8 sobie to sam kompletuje, np. ściągając zależności z mavena i przesyła w docelowe miejsca oraz uruchamia, np. przy pomocy Tomcata albo Spring-boot, jeżeli jest to aplikacja korzystająca ze Springa, lub Vert.x. Jako docelowe kontenery uruchomieniowe obsługiwane są jeszcze: Docker, WildFly, Apache Karaf i OpenShift (rozwiązanie komercyjne RedHata do deploymentu aplikacji w chmurze).

Prowadzący pokazywał fajne rozwiązanie, polegające na oznaczeniu w aplikacji Spring annotacjami referencji do zmiennych środowiskowych, których wartości są pobierane w trakcie deploymentu (a może i uruchomienia – nie mam pewności) z konfiguracji w ZooKeeper, a następnie wstrzykiwane do aplikacji.

Monitoring, czyli prezentacja parametrów działającej aplikacji może być robiona z poziomu shella lub ciekawego narzędzia Hawt.io, które udostępnia atrakcyjny interfejs prezentujący nawet schematy zależności zdefiniowane w profilu.

Reasumując: narzędzie wygląda fajnie ale pewnie na razie nie będzie mi dane z niego korzystać. Jednak przy okazji pobieżnie poznałem kilka (jak nie kilkanaście…) narzędzi ze stajni Apache i RedHat raz okolic.