W poprzednim wpisie pokazałem, jak można wykorzystać Dockera i Docker Compose do uruchomienia usługi bazy danych PostgreSQL lokalnie. W bieżącym wpisie pójdziemy krok dalej i do środowiska rozwojowego dodamy kolejny kontener z preinstalowaną platformą Camunda BPM.
Camunda BPM
Camunda dostarcza kompletną platformę BPM (ang. Business Process Management) w wersjach na kilka preinstalowanych serwerów aplikacyjnych. Jedną z form dystrybucji są oficjalne obrazy kontenerów Dockera dostępne w publicznym repozytorium. Jest to bardzo wygodne, ponieważ nie musimy niczego instalować na swojej maszynie, gdy chcemy szybko uruchomić demo lub nawet programować procesy na platformie.
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 GitHubie. Jest to projekt pokazujący jak można stworzyć 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 – całość oczywiście w postaci obrazu kontenera 🙂
Pobieramy wspomniany projekt i przechodzimy do niego:
git clone https://github.com/camunda/camunda-get-started-javaee.git
cd camunda-get-started-javaee/
Kontener
Gotowy obraz można pobrać z publicznego repozytorium Dockera. 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.16.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ę.
Takim systemem jest PostgreSQL, którym już dysponujemy, więc wykorzystamy go w naszym przykładzie.
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 tworzymy w katalogu z projektem:
version: "3.8"
services:
db:
container_name: db
image: postgres:9.4
environment:
- POSTGRES_PASSWORD=camunda
- POSTGRES_USER=camunda
ports:
- "5432:5432"
bpm:
container_name: bpm
image: camunda/camunda-bpm-platform:wildfly-7.16.0
environment:
- DB_DRIVER=postgresql
- DB_URL=jdbc:postgresql://db:5432/camunda
- DB_USERNAME=camunda
- DB_PASSWORD=camunda
- TZ=Europe/Warsaw
ports:
- "8080:8080"
Nowy kontener nazywa się bpm i jest oparty o gotowy obraz, a 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ługuje zmienna środowiskowa DB_URL, która zawiera adres jdbc z hostem db do kontenera bazy danych.
Dodatkowo, dla uproszczenia w poprzednim artykule konfiguracja docker-compose nie zawierała sekcji services i określenia wersji formatu. Deklarując wprost wersję, wymuszamy kompatybilność składni wspieraną przez daną edycję docker-compose.
Sprawdźmy, czy możemy odpalić w ten sposób kontenery:
$ docker-compose up -d
$ docker ps --format="{{ .Names }} \t {{ .Status }}"
Ostatnie polecenie powinno zwrócić:
bpm Up 29 seconds
db Up 29 seconds
czyli nazwy kontenerów bazy danych i aplikacji BPM oraz ich statusy.
Budowanie projektu
Skoro kontenery są gotowe i opisane w docker-compose.yml, pozostało zrobić już tylko jedno: zbudować projekt oraz dodać w odpowiednim miejscu kontenera Comundy wynikowy WAR z przykładowym procesem.
Do budowy potrzebujemy:
- zainstalowanej Javy w wersji 8,
- narzędzia Maven.
Instalacja jest w obu przypadkach prosta, dlatego nie będę jej w tym artykule opisywał.
Do zbudowania projektu potrzebne jest polecenie:
$ mvn install
Dodanie pliku WAR wymaga dołączenia sekcji volumes do kontenera Camundy. Wpisy w tej sekcji pozwalają zmapować lokalny plik lub katalog z odpowiednikiem wewnątrz kontenera.
Po zbudowaniu projektu w katalogu target pojawia się plik pizza-order.war. Mapujemy go do wnętrza kontenera w katalogu /camunda/standalone/deployments/. Z tego miejsca zostanie automatycznie zainstalowany przez wildfly. Wynikowy docker-compose.yml wygląda tak:
version: "3.8"
services:
db:
container_name: db
image: postgres:9.4
environment:
- POSTGRES_PASSWORD=camunda
- POSTGRES_USER=camunda
ports:
- "5432:5432"
bpm:
container_name: bpm
image: camunda/camunda-bpm-platform:wildfly-7.16.0
environment:
- DB_DRIVER=postgresql
- DB_URL=jdbc:postgresql://db:5432/camunda
- DB_USERNAME=camunda
- DB_PASSWORD=camunda
- TZ=Europe/Warsaw
ports:
- "8080:8080"
volumes:
- ./target/pizza-order.war:/camunda/standalone/deployments/pizza-order.war
Sprawdzimy teraz, czy wszystko działa jak należy:
$ docker-compose up -d --force-recreate
W poleceniu został dodany parametr –force-recreate, który powoduje ponowne zbudowanie kontenerów z nową konfiguracją. Jeśli wszystko poszło poprawnie, to w logach kontenera bpm powinny być poniższe informacje:
$ docker logs bpm
…
15:39:48,206 INFO [org.jboss.as.server] (ServerService Thread Pool -- 47) WFLYSRV0010: Deployed "pizza-order.war" (runtime-name : "pizza-order.war")
…
15:39:48,255 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 23.0.2.Final (WildFly Core 15.0.1.Final) started in 10390ms - Started 942 of 1128 services (375 services are lazy, passive or on-demand)
15:39:48,257 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://0.0.0.0:9990/management
15:39:48,257 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://0.0.0.0:9990
Camunda dostarcza przeglądarkowej aplikacji do zarządzania. Można sprawdzić czy artefakt pizza-order.war jest zainstalowany. Domyślny login i hasło to „demo”.
Na załączonym zrzucie ekranu zaprezentowałem zainstalowany proces:
Podsumowanie
Udało się zatem uruchomić bazę danych i serwer wildfly z platformą zainstalowaną na lokalnej maszynie. Sposób uruchomienia jest zadeklarowany w postaci jednego pliku – docker-compose.yml 🙂 Lokalne środowisko rozwojowe dla przykładowego projektu jest gotowe do pracy.
W następnej części pokażę, jak możemy pójść jeszcze dalej i wykorzystać Dockera w celu dostarczenia aplikacji na docelowe środowiska testowe i produkcyjne.
***
Zaktualizowane w 2021 i 2022 artykuły nt. Dockera
Zostaw komentarz