Seite 3: Client-Konfiguration

Zum Konfigurieren des Clients lassen sich nun der Client-Private-Key und das CA-Zertifikat auf den lokalen Rechner in das Verzeichnis ~/.docker/ installieren – beispielsweise durch Kopieren vom Docker Host per SCP. Dabei sind die erreichbare IP-Adresse beziehungsweise der Hostname des Docker-Hosts anzugeben:

# On the local machine
DOCKER_SERVER=...
mkdir -p ~/.docker/
scp ubuntu@$DOCKER_SERVER:/etc/docker/certs/{ca,key,cert}.pem ~/.docker/

Damit der Docker-Client weiß, welchen Docker-Host er ansprechen soll, ist in der Run Configuration je nach verwendeter Shell in ~/.zshrc oder ~/.bashrc noch die Umgebungsvariable DOCKER_HOST zu setzen. Zudem muss DOCKER_TLS_VERIFY signalisieren, dass TLS zum Einsatz kommt:

# Replace $DOCKER_SERVER with the hostname or IP address of the server
export DOCKER_HOST=tcp://$DOCKER_SERVER:2376 
export DOCKER_TLS_VERIFY=1
export DOCKER_CERT_PATH=$HOME/.docker/

Anschließend lassen sich einem neuen Terminal-Fenster sämtliche docker-Befehle an den Docker-Server weiterreichen:

$ docker system info

...
Operating System: Ubuntu 20.04.1 LTS
OSType: linux
...

Verwenden des entfernten Docker-Hosts in Testcontainers

Testcontainers beziehungsweise das genutzte docker-java erkennen automatisch die Umgebungsvariable DOCKER_HOST – zusätzliche Konfigurationsschritte sind daher nicht notwendig. Zu prüfen ist jedoch, dass in den Tests die Container-Dienste nicht über localhost konfiguriert sind, sondern über die von den Testcontainern bereitgestellten Methoden.

Listing 3 zeigt ein Spring-Boot-Beispiel zum Verwenden eines MongoDB-Testcontainers, der die korrekte ReplicaSet-URL liefert:

static MongoDBContainer mongoDBContainer = new MongoDBContainer("mongo:4.2");

static {
  mongoDBContainer.start();
}

@DynamicPropertySource
static void testcontainerProperties(DynamicPropertyRegistry registry) {
  registry.add("spring.data.mongodb.uri", mongoDBContainer::getReplicaSetUrl);
}

Listing 3: MongoDB-Testcontainer

Geschwindigkeitsvergleich

Um einen Eindruck von den erzielbaren Geschwindigkeitsvorteilen zu erhalten, dient ein realitätsnahes Spring-Boot-Projekt mit 224 Tests als Basis für einen Vergleich. Die Testkonfiguration für JUnit-Tests in einer Spring-Boot-Anwendung mit mehreren Spring Contexts enthält Testcontainer für MongoDB, Kafka und MockServer. Die verwendeten Server sind mit vier CPU-Kernen und acht GByte RAM ausgestattet. Der Vergleich liefert die jeweilige Testdurchführungsdauer für einen Docker-Host auf einem MacBook Pro (13 Zoll), einem Server im gleichen Netzwerk und einer Cloud-Instanz. Um dabei sicherzustellen, dass alle Docker-Images lokal gecacht vorliegen, erfolgten sämtliche Testdurchläufe mehrfach.

Tabelle 1: Testlaufzeiten im Vergleich

Der Geschwindigkeitsvorteil des lokalen Servers gegenüber dem Arbeitsplatzrechner beträgt zwei Minuten, was sich im täglichen Gebrauch enorm positiv auswirkt. Auf einen typischen Arbeitstag hochgerechnet können schnell 30 Minuten oder mehr zusammenkommen.

Das überraschend schlechte Abschneiden der EC2-Cloud-Instanz lässt sich vermutlich auf eine zu geringe Bandbreite und höhere Netzwerklatenz zurückführen, da sowohl die Tests wie auch die Anwendung intensiv mit den Infrastrukturdiensten interagieren.