Wyślij zapytanie Dołącz do Sii

W poprzednim wpisie pokazałem, jak można wykorzystać Dockera i Docker Compose do uruchomienia usługi bazy danych PostgreSQL lokalnie. W bieżącym artykule pójdziemy krok dalej: 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:

Ryc. 1 Proces instalacji artefaktu pizza-order.war
Ryc. 1 Proces instalacji artefaktu pizza-order.war

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.

Ocena:
Autor
Avatar
Dawid Szulist

Obecnie pracuje na stanowisku DevOps Engineer. Ma doświadczenie jako programista, administrator i lider. Odpowiada za tworzenie nowej infrastruktury opartej o RedHat OpenShift i Azure. Fan wszechobecnej automatyzacji, rozwiązań GitOps i Get Thing Done. Motywuje go dzielenie się wiedzą z innymi. Cechuje go spokój, szczególnie w trakcie sytuacji kryzysowych :) Prywatnie mąż, ojciec dwójki dzieci. Interesuje się kalisteniką i jest początkującym biegaczem :)

Twój adres e-mail nie zostanie opublikowany.

Może Cię również zainteresować

Pokaż więcej postów

Bądź na bieżąco

Zapisz się do naszego newslettera i otrzymuj najświeższe informacje ze świata Sii.

Otrzymaj ofertę

Jeśli chcesz dowiedzieć się więcej na temat oferty Sii, skontaktuj się z nami.

Wyślij zapytanie Wyślij zapytanie

Get an offer

Natalia Competency Center Director

Dołącz do Sii

Znajdź idealną pracę – zapoznaj się z naszą ofertą rekrutacyjną i aplikuj.

APLIKUJ APLIKUJ

Join Sii

Paweł Process Owner

ZATWIERDŹ

This content is available only in one language version.
You will be redirected to home page.

Are you sure you want to leave this page?