SASL-Authorisierung von PLAIN auf SCRAM-SHA-512 umgestellt

ACLs für AKHQ (andere UIs wahrscheinlich auch)

Die Adressen DOCKER und LOCALHOST über ACLs abgesichert

* Freifahrtschein für die Kommunikation über die BROKER-Adresse
* Realisiert über das Hinzufügen des Principals `User:ANONYMOUS` zu den
  `super.users` des Clusters -- dies funktioniert, da nur die Aufrufe, die
  über die BROKER-Adresse abgewickelt werden diesem Benutzer zugeordnet
  werden, da nur diese Adresse im `PLAINTEXT`-Modus betrieben wird.
* Für alle anderen Adressen hat der Principal einen abweichenden, über die
  _erfolgreiche Authorisierung_ vorgegebenen Principal.
* Wenn über diese Adressen _ohne erfolgreiche Authorisierung_ zugegriffen
  wird, werden die Zugriffe abgewährt!

Der Cruise-Control-Reporter berichtet über die BROKER-Adresse

Producer & Consumer greifen über abgesicherte Adresse zu

Die Cruise Control Reporter greifen über abgesicherte Adresse zu

AKHQ greift über abgesicherte Adresse zu

Connect greift über abgesicherte Adresse zu

Schema-Registry greift über abgesicherte Adresse zu

Beispiel: Schema erzeugen und abfragen

DOCKER und LOCALHOST erfordern Authentifizierung

Expliziten Listener für Broker eingeführt (BROKER: Broker, DOCKER: user)

AclAuthorizer aktiviert

Eigenes Kafka-Image von `cp-kafka` mit cruis-control-JAR abgeleitet

Dockerfile von Cruise Control für eigenes Kafka-Dockerimage kopiert

Dockerfile für Cruise Control in Unterverzeichnis verschoben

Cruise Control wird in einem Docker-Image gebaut

- Der Build ist so wesentlich einfacher reproduzierbar, so dass er auch
  von den Teilnehmern ausgeführt werden kann.
- Da noch nicht gelöst wrude, wie das für das Sammeln der Laufzeitdaten
  benötigte JAR `cruise-control-metrics-reporter.jar` in die Broker
  hereingereicht werden kann, wurde die entsprechende Konfiguration in
  den Brokern vorübergehend entfernt.

`README.sh` an Übung angepasst

Bootstrap-Server für den Cruise-Control-Reporter explizit gesetzt

Siehe https://github.com/linkedin/cruise-control/issues/583#issuecomment-489404389["Versteckte" Konfigurationsmöglichkeiten]

4. Broker hinzugefügt

UI für Cruise Control direkt mit in das Image eingebaut

CORS für die cruise-control-ui konfiguriert - _Hilft nicht :/_

* Siehe: https://github.com/linkedin/cruise-control-ui/wiki/CORS-Method
* Die Zugriffe werden weiter abgelehnt.
* _Grund:_ Die Vorgaben erlauben nur einen speziellen Header.
* Die Anfragen werden dann wegen Headern wie z.B. `Content-Type` abgelehnt.
* *Idee:* UI in das CC-Image einbauen - _müsste laut Parametern gehen!_

Service `cruise-control-ui` ergänzt: Scheitert noch an CORS

GIT-Repo für cruise-control-ui hinzugefügt

Docker-Image für Cruise Control gebaut & eingebunden

GIT-Repo von Cruise Control hinzugefügt!

Auf die Spring-Version des Simple Consumer umgestellt

Producer und Consumer-Group hinzugefügt

ZooNavigator in den Demo-Stack aufgenommen

`README.sh` bricht ab, wenn `setup` nicht erfolgreich ist!

Start von Service `setup` startet auch `cli`

Der Service `setup` wartet bereits auf den Cluster

Grace-Period für Broker und cli/setup gesetzt

Schönere YAML-Syntax für `setup`-Service

Services `schema-registry` und `connect` hinzugefügt

Hilfs-Services `setup` überarbeitet

Volumes für die Log-/Config-Daten und Zookeeper hinzugefügt

Setup zurück auf Confluent (Version 7.5.1) mit Zookeeper umestellt

AKHQ auf einen eindeutigeren Port verlegt

Automatisches entfernen von Orphans beim Start

Docker-Setup in das Unterverzeichnis `docker` verschoben

Docker-Setup auf `bitnami/kafka:3.4` aktualisiert und vereinfacht

* Die Konfiguration musste an (undokumentierte?!) Änderungen in der
  version 3.4 von `bitnami/kafka` angepasst werden.
* Die drei Broker spielen jetzt gleichzeitig Controller. D.h., der
  Service `kafka-0`, der explizit Controller gespielt hat, fällt weg.

Bedienbarkeit des Setups verbessert

* Setup starten mit `docker-compose up -t0 -d cli`
** Dabei wird _nicht_ automatisch das Topic `test` neu angelegt
** D.h., die Daten gehen nicht unbeabsichtigt verloren, wenn man mit
   `up -d` prüft, ob noc alles läuft!
* Das Topic `test` kan mit `docker-compose restart -t0 setup` explizit
  gelöscht und neu angelegt (aka geleert) werden.

`docker-compose up setup` startet auch die cli

AKHQ zu dem Basis-Setup hinzugefügt

Compose-Setup auf bitnami mit KRAFT umgestellt

* Setup aus Unterschied zu `spring-consumer--json--adder` übernommen.
* Auch das `README.sh` entsprechend angepasst.

Für ordering-Übung werden zwei Partitionen benötigt!

Setup mit 3 Broker und Topic-Erzeugung mit Setup für acks-Übung

Merge der Upgrades für Confluent/Spring-Boot (Branch 'first-contact')

Upgrade von Spring Boot und den Confluent-Kafka-Images

* Upgrade der Kafk-Images von Confluent 7.0.2 auf 7.1.3
** Unterstützt Kafka 3.1.x (siehe https://docs.confluent.io/platform/current/installation/versions-interoperability.html[Versions-Matrix])
* Upgrade für Spring Boot von 2.6.5 auf 2.7.2
** Enthält Kafka: 3.1.1
** Enthält Spring Kafka: 2.8.8

Setup aus der Intro-Übung übernommen

Setup "entkernt": Implementierungen entfernt

Upgrade der Images von Confluent 6.2.0 auf 7.0.2

README.sh verwendet den cli-Service für Kommandos

Fälschlich hartkodiertes Topic gegen Variable getauscht

Code reorganisiert, um Änderungen vergleichbarer zu machen

Upgrade für Spring Boot 2.6.0 -> 2.6.5

* Kafka: 3.0.1
* Spring Kafka: 2.8.4

First Contact: Simple Producer & Consumer