W poprzednim wpisie pokazałem jak można wykorzystać Docker i docker-compose do budowania środowisk rozwojowych. Udało się uruchomić i skonfigurować kontener z zainstalowaną bazą PostgreSQL i wgranym schematem pochodzącym z dystrybucji Camunda BPM. W bieżącym wpisie pójdziemy krok dalej i do środowiska dodamy kolejny kontener z preinstalowaną platformą Camunda BPM.
Camunda BPM
Camunda dostarcza kompletną platformę BPM w wersjach na kilka preinstalowanych serwerów aplikacyjnych. Jedną z form dystrybucji są oficjalne obrazy kontenerów docker’a dostępne w publicznym repozytorium. Jest to bardzo wygodne, bo jeśli chcemy poznać szybko uruchomić demo lub nawet dewelopować procesy na platformie to nie musimy niczego instalować na swojej maszynie. Plan na dziś: do środowiska z poprzedniego wpisu dodać kontener z platformą BPM oraz uruchomić na nim przykładowy projekt z procesem BPM.
Przykładowy projekt
Zamiast tworzyć nowy projekt, wykorzystamy gotowy przykład dostarczany w ramach dokumentacji wraz z platformą. Źródła projektu znajdują się na github‘ie. Jest to projekt pokazujący jak można tworzyć aplikację BPM z formularzami wykorzystując zasadniczo standardowe komponenty EJB oraz JSF, czyli technologie ze stosu JEE. A skoro tak, to do uruchomienia projektu wykorzystamy Camundę preinstalowaną na serwerze aplikacyjnym Wildfly. Gotowy obraz można pobrać z publicznego repozytorium docker’a. Jest tutaj dostępnych kilka wersji różniących się serwerem aplikacyjnym, nas będzie interesować obraz o nazwie camunda/camunda-bpm-platform:wildfly-7.4.0. Jeśli przyjrzymy się dokładnie dokumentacji obrazu, dowiemy się że jest skonfigurowany z wbudowaną bazą danych H2, ale za pomocą zmiennych środowiskowych możemy wskazać inną bazę pod warunkiem że jest wspierana przez Camundę. Dysponujemy gotowym kontenerem PostgreSQL, więc wykorzystamy go w naszym przykładzie.
Kontener
Zabieramy się za skonfigurowanie kontenera z Camundą. W tym celu wykorzystamy docker-compose.yml z poprzedniej części i dodamy definicję nowego kontenera. Docelowy plik będzie miał postać:
db: image: postgres:9.4 environment: - POSTGRES_PASSWORD=camunda - POSTGRES_USER=camunda ports: - "5432:5432" volumes: - ./src/sql/postgres_engine_7.4.0.sql:/docker-entrypoint-initdb.d/postgres_engine_7.4.0.sql - ./src/sql/postgres_identity_7.4.0.sql:/docker-entrypoint-initdb.d/postgres_identity_7.4.0.sql bpm: image: camunda/camunda-bpm-platform:wildfly-7.4.0 environment: - DB_DRIVER=postgresql - DB_URL=jdbc:postgresql://db:5432/camunda - DB_USERNAME=camunda - DB_PASSWORD=camunda - TZ=Europe/Warsaw links: - db:db ports: - "8080:8080"
Nowy kontener nazywa się bpm i jest oparty o gotowy obraz, zmienne środowiskowe definiują parametry połączenia do bazy danych i strefę czasową. Port 8080 kontenera jest mapowany na taki sam port maszyny hostującej. Na uwagę zasługują 2 rzeczy: najpierw sekcja links wiąże ze sobą kontenery i sprawia, że kontener db staje się widoczny dla kontenera bpm jako host o nazwie db, potem zmienna środowiskowa DB_URL wskazuje na ten host w adresie jdbc. Sprawdźmy, czy możemy odpalić w ten sposób kontenery:
$ docker-compose up
Projekt
Skoro kontenery są gotowe i opisane w docker-compose.yml pozostało zrobić już tylko jedno: zbudować projekt oraz wynikowy WAR z przykładowym procesem dodać w odpowiednim miejscu kontenera camundy. Pierwsze jest banalne, bo wystarczy wywołać polecenie:
$ mvn install
drugie też nie jest trudne, wymaga dodania sekcji volumes do kontenera Camundy. Wpisy w tej sekcji pozwalają zamapować lokalny plik lub katalog z odpowiednikiem wewnątrz kontenera. Skoro w projekcie w katalogu target pojawia się plik pizza-order.war to mapujemy go do wewnątrz kontenera w katalogu /camunda/standalone/deployments/, bo z tego miejsca zostanie automatycznie zainstalowany przez wildfly. Wynikowy docker-compose.yml wygląda tak:
db: image: postgres:9.4 environment: - POSTGRES_PASSWORD=camunda - POSTGRES_USER=camunda ports: - "5432:5432" volumes: - ./src/sql/postgres_engine_7.4.0.sql:/docker-entrypoint-initdb.d/postgres_engine_7.4.0.sql - ./src/sql/postgres_identity_7.4.0.sql:/docker-entrypoint-initdb.d/postgres_identity_7.4.0.sql bpm: image: camunda/camunda-bpm-platform:wildfly-7.4.0 environment: - DB_DRIVER=postgresql - DB_URL=jdbc:postgresql://db:5432/camunda - DB_USERNAME=camunda - DB_PASSWORD=camunda - TZ=Europe/Warsaw links: - db:db ports: - "8080:8080" volumes: - ./target/pizza-order.war:/camunda/standalone/deployments/pizza-order.war
Sprawdzimy teraz czy wszystko działa jak należy:
Kontenery się uruchamiają, aplikacja się instaluje w kontenerze, czas jeszcze sprawdzić w przeglądarce czy wszystko gra. Camunda dostarcza przeglądarkowej aplikacji do zarządzania, http://localhost:8080/camunda/app/cockpit/ sprawdzić czy pizza-order jest zainstalowany. Przypomnę, że aplikacja jest dostępna na lokalnym adresie dzięki mapowaniu portów w docker-compose.yml. Załączony zrzut ekranu prezentuje zainstalowany proces:
Udało się zatem bez instalowania bazy danych i serwera widfly z zainstalowaną platformą na lokalnej maszynie stworzyć i uruchomić lokalne środowisko rozwojowe dla przykładowego projektu. Jest to bardzo wygodne ponieważ nie musimy więcej martwić się o instalowanie odpowiednich narzędzi.
W następnej części pokażę jak możemy pójść jeszcze dalej i wykorzystać docker’a w celu dostarczenia aplikacji na docelowe środowiska testowe i produkcyjne.
