Ich hatte mich bereits for Einsatz von Traefik im Heimlabor für die Möglichkeit interessiert, mehrere virtualisierte Container den gleichen Dienst auf dem gleichen Port anbieten zu lassen und eine Art Applikationsrouter über den Namen, den der Client zum Verbindungsaufbau nutzt die Verbindung zur jeweiligen Instanz "routen" zu lassen...

Tatsächlich war die Idee, von der alles ihren Ausgenag nahm folgende: Man stelle mehrere Datenbank-Instanzen als Docker-Container bereit. Die unterschiedlichen Entwicklungsteams bekommen je eine Instanz zugeteilt. In einem normalen Dockerumfeld ohne zusätzliche Maßnahmen würden die Datenbank-Server alle den Standardport anbieten und Docker würde jede Instanz auf einen anderen Port mappen.

Jedes Team oder abstrakter: jeder Client müsste sich dann zum selben Host (dem Dockerhost), aber auf einen anderen Port verbinden. Nun weiß ich auch, dass man die Datenbank-Instanzen auch zu einem High-Availability-Cluster mit Replikation zusammenschalten und jedem Client sein eigenes Schema geben könnte - aber ich möchte hier verdeutlichen, wie die Idee antstand - und außerdem könnte es ja sein, dass die einzelnen Clients spezifische Versionen der Datenbanklösung benötigen. Dieses Szenario wäre mit einem HA-Cluster nicht mehr abzubilden.

Nachdem wir diese Idee einige Zeit besprochen und durchdacht hatten, kam ein Kollege mit der Inspiration Traefik. Leider stellte sich schnell heraus, dass Traefik zwar ideal für genau dieses Szenario war - aber nur wenn die Protokolle HTTP oder HTTPS zur Kommunikation zum Einsatz kamen.

Die neue Version 2.0 von Traefik änderte das - die Werbung versprach nun auch jedwede TCP-Kommunikation routen zu können. In den Zeiten der Quarantäne spare ich viel Zeit, die sonst mit Pendeln draufgeht, vor einiger Zeit hatte ich die Migration zu Traefik 2.2 bereits vollzogen und so hatte ich Muße, die alte Idee nochmals im Kontext von Traefik 2.x zu durchdenken.

Leider kam ich damit auch nicht weiter - denn die Voraussetzung für TCP-Routing in Traefik 2.0 heißt Transport Layer Security: Es wurde ein neues Konzept eingeführt, das SNI heißt: beim Aufbau verschlüsselter Verbindungen ist es mit Server Name Indication - dafür steht SNI nämlich - möglich, dass der Client, die Information darüber, mit welchem Host er eine Verbindung wünscht, unverschlüsselt überträgt.

Das heißt, dass der Server eine TLS-Schnittstelle anbieten muss, die der Client zur Verbindung benutzt und gleichzeitig muss der Client SNI unterstützen. Es lassen sich im Netz diverse Darstellungen finden, dass andere bereits das hier geschilderte Datenbank-Szenario probiert haben und an der fehlenden Unterstützung an der einen oder anderen Stelle gescheitert sind...

Ich habe hier trotz allem nochmals einige Links zusammengefasst, die mir bei der Recherche geholfen haben...

Links

Artikel, die hierher verlinken