Container-Automat

Generierte Anwendungen ausführen

Service-Typen

Die Anwendung als Ganzes implementiert zur Laufzeit den zur Generierung verwendeten DEA. Die dazu gestarteten Services können in 2 Gruppen unterteilt werden:

Anwendungsspezifische Services
- Diese Services werden durch individuell generierte Java-Programme in Spring Boot implementiert.
- Für jeden Zustand des DEA wird ein eigener Service gestartet. Dabei handelt es sich immer um dasselbe Java-Programm, im Folgenden bezeichnet als State-Programm.
- Anfragen werden in Form von Eingabestrings für den DEA über eine REST-Schnittstelle entgegengenommen, die durch ein separates Java-Programm bereitgestellt wird, im Folgenden bezeichnet als Entry-Programm.
Allgemeine System-Services
- Diese Services werden durch individuell konfigurierte Anwendungen ausgewählter Anbieter bereitsgestellt.
- Über einen Message-Broker werden Command-Messages für Zustandsübergänge des DEA an die State-Programme gesendet, außerdem Event-Messages zur Protokollierung des Ablaufs der Verarbeitung.
- In einer Datenbank werden Informationen über die Anfragen und die Verarbeitungsschritte dauerhaft gespeichert.
- Optional verarbeiten weitere Services die oben genannten Event-Messages zur Protokollierung. ^[1]

Varianten zur Ausführung und Laufzeitumgebungen

Auf den folgenden Seiten werden drei Möglichkeiten beschrieben, wie Anwendungen, die mit der Container-Automat Factory generiert wurden, ausgeführt werden können:

alle Services mit Docker Compose
alle Services in einem Kubernetes-Cluster
Java-Programme lokal und die anderen Services in Docker-Containern

Dabei wird das Hauptaugenmerk auf die Ausführung mit Docker Compose gelegt, da hier keine weiteren Anforderungen erfüllt sein müssen. Lediglich Docker selbst muss zur Verfügung stehen.

Anmerkungen:

Zu Docker: Im Grunde gehe ich in der gesamten Dokumentation zu Container-Automat davon aus, dass Docker Desktop zur Verfügung steht. ^[2] Zumindest auf dem System, auf dem die Container-Automat Factory und damit generierte Anwendungen erstmalig ausprobiert werden. Daher stehen die Erläuterungen zur Verwendung mit Docker im Vordergrund. Auf Docker selbst wird jedoch nicht im Detail eingegangen. Einzelheiten entnehmen Sie bitte der Docker-Dokumentation oder einschlägiger Literatur. ^[3]

Zu Kubernetes: Bei Erläuterungen zur Ausführung mit Kubernetes gehe ich von einer lokal installierten Instanz von Kubernetes für Entwicklungs- oder Testzwecke aus. Unter Windows habe ich minikube verwendet ^[4] und unter Linux kind. ^[5] Auf Details von Kubernetes wird nicht näher eingegangen. Die generierten Anwendungen enthalten Scripte, die kubectl aufrufen.

Zu Java: Für die Ausführung mit Docker Compose oder Kubernetes werden Docker-Images der beiden Java-Programme der Anwendung benötigt. Für die Erstellung dieser Images ist allerdings kein JDK (Java Development Kit) erforderlich. Für den Fall, dass Sie die Java-Programme für die lokale Ausführung erstellen möchten, wird davon ausgegangen, dass die notwendigen Voraussetzungen erfüllt oder Kenntnisse für deren Herstellung vorhanden sind.

Datei- und Verzeichnisnamen in Anwendungsprojekten

Einige Datei- und Verzeichnisnamen werden basierend auf dem Anwendungsnamen erstellt, der bei der Generierung angegeben wurde. Wenn solche Namen auf den folgenden Seiten im Text erwähnt oder in Beispielen für Kommandos genannt werden, wird für den Namen der Anwendung der folgende Platzhalter verwendet:

{anwendungsname}

Davon abgesehen werden bei der Erläuterung von konkreten Kommandos oder Beispielen für Ausgaben häufig die Datei- und Verzeichnisnamen so angegeben, wie sie lauten, wenn Sie die Beispielanwendung für den Getränkeautomaten mit dem Namen BeverageVending erstellt haben, wie im Abschnitt Ein Service-Projekt auf Basis eines DEA erstellen beschrieben.

Beispiel 1: Verzeichnisnamen im Stammverzeichnis des Projektes

Unter Verwendung des Platzhalters {anwendungsname} enthält das Stammverzeichnis die folgenden Einträge:

{anwendungsname}-core  (Directory)
{anwendungsname}-entry (Directory)
{anwendungsname}-state (Directory)
dockerbuild            (Directory)
dockercompose          (Directory)
kubernetes             (Directory)
localrun               (Directory)
pom.xml
README.md

Im Falle der Beispielanwendung BeverageVending liegt konkret folgender Verzeichnisinhalt vor:

beveragevending-core  (Directory)
beveragevending-entry (Directory)
beveragevending-state (Directory)
dockerbuild           (Directory)
dockercompose         (Directory)
kubernetes            (Directory)
localrun              (Directory)
pom.xml
README.md

Beispiel 2: Script-Files zur Erstellung der Docker-Images der Anwendung

Im Unterverzeichnis dockerbuild befinden sich eine CMD-Datei für die Windows-Eingabeaufforderung und eine SH-Datei für die Linux-Shell, die aufgerufen werden können, um die Docker-Images der Anwendung zu erstellen. Unter Verwendung des Platzhalters {anwendungsname} lauten die Dateinamen folgendermaßen:

dockerbuild-{anwendungsname}.cmd
dockerbuild-{anwendungsname}.sh

Im Falle der Beispielanwendung BeverageVending lauten die Dateinamen konkret folgenermaßen:

dockerbuild-beveragevending.cmd
dockerbuild-beveragevending.sh

Nächste Schritte

Weiter mit Die Docker-Images der generierten Anwendung erstellen

1. Derzeit kann hierfür ein Konglomerat, bestehend aus Logstash, Elasticsearch und Kibana, bei der Anwendungsgenerierung hinzugefügt werden.

2. Informationen zu Docker Desktop finden Sie unter folgender URL: https://www.docker.com/products/docker-desktop/

3. Die Dokumentation der Docker Kommandos finden Sie unter folgender URL: https://docs.docker.com/reference/cli/docker/

4. Informationen zu minikube finden Sie unter folgender URL: https://minikube.sigs.k8s.io/docs/

5. Informationen zu kind finden Sie unter folgender URL: https://kind.sigs.k8s.io/