Software Development

Docker dla programistów – budowa środowiska rozwojowego. Część II

27 grudnia, 2021 0
Podziel się:

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:

camunda pizza order 002 2 1024x444 - Docker dla programistów – budowa środowiska rozwojowego. Część II

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.

Dawid Szulist
Autor: 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 :)

    Imię i nazwisko (wymagane)

    Adres email (wymagane)

    Temat

    Treść wiadomości

    Zostaw komentarz