Master 15 - Enterprise Container Infrastructure Platform

Container, Datenbank, Storage und Security für Master 1 bis 14. Dieser Master macht die bisherigen Systeme konkret betreibbar und erklärt die Infrastruktur bewusst ausführlich.

Produktionsnahe Plattformreferenz

Helm, Kustomize, Security, Autoscaling, Secrets und PostgreSQL Operator.

14

konkretisierte Master-Runtime-Profile

14

kompakte SVG-Erklärbilder

Compose + K8s + OpenShift

je Master als Profilvorlage

Start

READMERuntime-MatrixGroße ErklärungDB & StorageSecurityRunbooksSVG-GaleriePrüfbericht

Master 1-14 konkretisiert

Master 1 RuntimeMaster 2 RuntimeMaster 3 RuntimeMaster 4 RuntimeMaster 5 RuntimeMaster 6 RuntimeMaster 7 RuntimeMaster 8 RuntimeMaster 9 RuntimeMaster 10 RuntimeMaster 11 RuntimeMaster 12 RuntimeMaster 13 RuntimeMaster 14 Runtime
Master Integration

Lehrbuch und Praxis

Was lerne ich hier?

Fachlicher Kern

Container Platform

Technischer Fokus

Wie alle Master auf konkrete Infrastrukturprofile abgebildet werden.

Warum wichtig?

Compose, Kubernetes, OpenShift, AWS, VM, Bare Metal, DB, Storage und Security.

Lernziel

Du erkennst Zweck, Ablauf, Modulgrenzen und Betriebsbezug dieses Masters.

Fachliches Mini-Szenario

Szenario: Ein Fachsystem startet im Container, nutzt PostgreSQL, legt Dokumente in Object Storage ab, liest Secrets aus der Plattform und wird über NetworkPolicies eingegrenzt.
?

Fachliche Frage

Welche Geschäftsentscheidung wird hier unterstützt und welche Daten müssen nachvollziehbar bleiben?

?

Technische Frage

Welche Module sind wirklich Fachkern und welche sind nur Adapter, Runtime oder Infrastruktur?

Fachliches und technisches SVG

Fachlicher AblaufContainerDBStorageSecretsNetzwerkBetrieb
Technischer AblaufREST/APIUse CaseDomainRepositoryOutbox/EventAdapter

Die zwei SVGs trennen bewusst Fachlichkeit und Technik. Dadurch sieht man, ob ein Thema wirklich fachlich ist oder nur eine technische Umsetzungsschicht darstellt.

Modulkarte

Platform
Security
Storage / DB
Deployment
Operations
Runbooks
Leseregel: Starte immer beim Fachmodell und gehe erst danach in Adapter, Runtime und Plattform. So bleibt die Architektur verständlich.

Start, Runtime und praktische Nutzung

Schnellstart

Öffne RUNNABLE.html oder nutze den Smoke-Start im jeweiligen Workspace.

Spring/Jakarta

Wo vorhanden, ergänzen Spring Boot oder Jakarta eine echte Runtime. Smoke bleibt der robuste Minimalstart.

Container

Bei Container-Mastern helfen Compose, Kubernetes und OpenShift-Profile beim Betriebsverständnis.

mvn -q -pl runnable-smoke -am package exec:java

Was ist Demo, was wäre Produktion?

  • Demo: lokale Startbarkeit, vereinfachte Adapter, nachvollziehbare Abläufe.
  • Produktionsnah: klare Modulgrenzen, dokumentierte Patterns, Container-/Runtime-Profile und Betriebsdenken.
  • Noch zu ergänzen für echte Produktion: echte Secrets, echte Infrastruktur, Security-Härtung, Lasttests und verbindliche Compliance-Vorgaben.

Weiter im Projekt

Diese Links führen aus dem Lehrbuch in die eigentliche Projektstruktur.

Final UI & Lehrbuch Upgrade · Kacheln, zwei SVG-Perspektiven, Mini-Szenario und bessere Leseführung.

Module und Quellcode

8 Module6 KategorienInhalte vollständig übernommen

Container 2

docker-jvm-imageContainer
Verantwortung

Definiert ein reproduzierbares JVM-Container-Image als gemeinsame Laufzeitbasis für die Enterprise-Anwendungen.

Entwurfsmuster und Architekturbausteine
  • Immutable Infrastructure: Das Image wird versioniert gebaut statt auf laufenden Systemen nachträglich verändert.
  • Layered Image: Laufzeit und Anwendung werden in klaren Image-Schichten getrennt.

Dockerfile öffnen

docker-compose-runtime-profileContainer
Verantwortung

Stellt für Master 1 bis 14 lokale Compose-Profile bereit und macht Abhängigkeiten, Ports und Laufzeitkonfiguration nachvollziehbar.

Entwurfsmuster und Architekturbausteine
  • Infrastructure as Code: Die lokale Laufzeit wird deklarativ und wiederholbar beschrieben.
  • Environment Parity: Die Profile nähern lokale Entwicklung und spätere Plattformlaufzeit aneinander an.

OTC-Compose öffnen

Orchestrierung 2

kubernetes-workloadsOrchestrierung
Verantwortung

Enthält deklarative Kubernetes-Workloads für die Master-Systeme und bündelt Deployment-, Service- und Betriebsparameter.

Entwurfsmuster und Architekturbausteine
  • Declarative Configuration: Der gewünschte Plattformzustand steht vollständig in YAML.
  • Self-Healing Runtime: Kubernetes gleicht den tatsächlichen Zustand mit der Deklaration ab.

Telco-Manifest öffnen

openshift-routesOrchestrierung
Verantwortung

Ergänzt die Kubernetes-Workloads um OpenShift-Routen und macht die Anwendungen über die Plattform erreichbar.

Entwurfsmuster und Architekturbausteine
  • Platform Adapter: OpenShift-spezifische Ressourcen bleiben von den fachlichen Anwendungen getrennt.
  • Edge Routing: Externe Zugriffe werden an einer klaren Plattformgrenze terminiert und weitergeleitet.

Telco-Route öffnen

Paketierung 1

helm-otc-referencePaketierung
Verantwortung

Paketiert die Order-to-Cash-Referenz als Helm Chart und trennt wiederverwendbare Templates von umgebungsspezifischen Werten.

Entwurfsmuster und Architekturbausteine
  • Configuration Template: Chart und Values erzeugen reproduzierbare Plattformressourcen.
  • Externalized Configuration: Umgebungswerte werden außerhalb des Anwendungsartefakts gehalten.

Chart öffnen · Values öffnen

Daten & Storage 1

postgres-backup-restoreDaten & Storage
Verantwortung

Bündelt ausführbare PostgreSQL-Skripte für Sicherung und Wiederherstellung und macht den betrieblichen Datenpfad sichtbar.

Entwurfsmuster und Architekturbausteine
  • Backup and Restore: Sicherung und Rücksicherung werden als zusammengehöriger Betriebsvertrag behandelt.
  • Operational Runbook: Wiederholbare Shell-Abläufe reduzieren manuelle Fehler im Betrieb.

Backup öffnen · Restore öffnen

Security 1

network-and-secret-securitySecurity
Verantwortung

Zeigt Netzwerksegmentierung und externe Secret-Konfiguration als getrennte Sicherheitsbausteine der Plattform.

Entwurfsmuster und Architekturbausteine
  • Least Privilege: NetworkPolicies begrenzen erlaubte Kommunikationswege.
  • Secret Externalization: Sensible Werte werden nicht in Anwendungscode oder Images eingebettet.

NetworkPolicy öffnen · Env-Beispiel öffnen

Runtime 1

vm-systemd-serviceRuntime
Verantwortung

Stellt eine klassische VM-/Bare-Metal-Laufzeit über systemd als Alternative zur Containerplattform bereit.

Entwurfsmuster und Architekturbausteine
  • Process Supervisor: systemd übernimmt Start, Neustart und Lebenszyklus des Prozesses.
  • Runtime Adapter: Die Anwendung bleibt gleich, während die Betriebsumgebung austauschbar bleibt.

Service-Datei öffnen

Projektübersicht · Master 15 - Enterprise Container Infrastructure Platform

Master 15 - Enterprise Container Infrastructure Platform

Dieser Master konkretisiert Master 1 bis 14 für verteilte Container-Infrastruktur: Docker/Podman, Compose, Kubernetes, OpenShift, AWS EKS/ECS, VM, Bare Metal und Dedicated Hosting.

Wichtigste Dateien

  • index.html - zentrale Startseite
  • MASTER_RUNTIME_MATRIX.html - konkrete Matrix für alle Master 1-14
  • docs/container-platform-guide.html - große Erklärung
  • docs/db-storage-deep-dive.html - Datenbank und Storage
  • docs/security-configuration.html - Security-Konfiguration
  • docs/runbooks.html - Betrieb und Fehleranalyse
  • docs/svg-gallery.html - alle SVGs
  • platform/docker-compose/master-XX/compose.yaml - Compose-Profil je Master
  • platform/kubernetes/master-XX/app.yaml - Kubernetes-Profil je Master
  • platform/openshift/master-XX/app-route.yaml - OpenShift-Profil je Master

Öffnung

ZIP entpacken und index.html öffnen. Danach zuerst die Runtime-Matrix und dann die Container-Platform-Erklärung lesen.

Start und Runtime · RUNNABLE - Master 15

RUNNABLE - Master 15

Master 15 ist primaer ein Container-, DB-, Storage- und Security-Plattform-Master. Die Profile sind als Compose-, Kubernetes- und OpenShift-Beispiele gedacht.

open index.html
open MASTER_RUNTIME_MATRIX.html
⌂ Cockpit