Container-Vernetzung mit Cloud Foundry

App Cloud

Container-Vernetzung mit Cloud Foundry

Das Container-to-Container Networking in der Swisscom Application Cloud ermöglicht eine sichere und schnelle direkte TCP- und UDP-Kommunikation zwischen deinen Anwendungen. Und dank der eingebauten Application Service Discovery können sich deine App-Container leicht gegenseitig finden.

Die Swisscom Application Cloud nutzt die Open-Source-Distribution von Cloud Foundry als Basis, um dir eine Plattform-as-a-Service zu bieten.
Seit der offiziellen Veröffentlichung unserer Plattform haben wir kontinuierlich neue Funktionen hinzugefügt und implementiert, darunter auch die Container-to-Container-Vernetzung.

Container Networking ermöglicht eine richtliniengesteuerte, direkte Kommunikation zwischen deinen Anwendungsinstanzen auf Cloud Foundry.

Basierend auf den Richtlinien, die du über die CF CLI festlegen kannst, haben deine Anwendungen jetzt eine direkte Verbindung zueinander, entweder über TCP oder UDP. Du hast die Wahl! Das bringt natürlich viele Vorteile mit sich, wie z. B. eine geringere Latenzzeit und einen höheren Durchsatz dank der direkten Kommunikation, anstatt über den GoRouter oder einen externen Load-Balancer zu gehen. Außerdem kannst du als Entwickler mit diesen App-to-App-Richtlinien fein abgestufte Zugriffskontrollen festlegen. Deine Apps werden sicherer, da sie direkt über die Container-IPs miteinander kommunizieren, anstatt eine öffentliche Route zu nutzen. Dadurch hast du auch die Möglichkeit, Anwendungen vor der Außenwelt zu verbergen und auf sie zuzugreifen, ohne eine Route zu ihnen hinzuzufügen.

Das Container-to-Container Networking verwendet intern ein Overlay-Netzwerk, um die Kommunikation zwischen deinen App-Instanzen zu verwalten und zu ermöglichen. Allen App-Containern wird eine eindeutige private Container-IP-Adresse zugewiesen, über die sie dann miteinander kommunizieren können.
Das Overlay-Netzwerk kann nicht nach außen geroutet werden, und der zwischen deinen Containern gesendete Datenverkehr verlässt das Overlay-Netzwerk nicht.

Einen detaillierten Blick auf die Architektur hinter den Kulissen kannst du hier auf GitHub werfen: https://github.com/cloudfoundry/cf-networking-release/blob/develop/docs/arch.md(öffnet ein neues Fenster)

Toll, wie kann ich das benutzen?

Um die Container-zu-Container-Vernetzung zu nutzen, musst du Netzwerkrichtlinien für deine Apps erstellen. Diese Richtlinien geben eine Quell-App, eine Ziel-App, ein Protokoll und einen Port an, damit die App-Instanzen direkt miteinander kommunizieren können, ohne den GoRouter, einen Load-Balancer oder eine Firewall zu passieren. Die Container-zu-Container-Vernetzung unterstützt sowohl TCP als auch UDP, und du kannst Richtlinien für mehrere Ports oder Portbereiche konfigurieren. Die Netzwerkrichtlinien werden sofort angewendet, ohne dass du deine App neu starten oder umstellen musst. Das folgende Diagramm zeigt, wie App-Instanzen in einer Bereitstellung mit aktiviertem Container-to-Container Networking und Netzwerkrichtlinien kommunizieren.
In diesem Beispiel hat der App-Entwickler Richtlinien erstellt, um den Verkehrsfluss zwischen App A, App B und App C zu regeln.

  • Datenverkehr von App A zu App B im TCP-Portbereich 7000-8000 zulassen
  • Datenverkehr von App A zu App C auf UDP-Port 5053 zulassen

Wenn der Verkehr und seine Richtung nicht ausdrücklich erlaubt sind, wird er standardmäßig verweigert. Zum Beispiel kann App B keinen Datenverkehr an App C senden.

Verwende die Befehle der CF CLI, um diese Netzwerkrichtlinien einzurichten:

Von diesen drei Apps ist nur App A der Außenwelt mit einer kartierten Route ausgesetzt:

Wir können die konfigurierten Richtlinien mit dem Befehl network-policies anzeigen:

Erstellen wir eine zusätzliche Richtlinie mit add-network-policy, um auch die direkte TCP-Kommunikation auf Port 4567 von App C zu App B zu ermöglichen (aber nicht umgekehrt!):

Wenn wir später feststellen, dass es ein Fehler war, App C Zugang zu App B zu gewähren, können wir die Netzwerkrichtlinie einfach wieder entfernen, indem wir remove-network-policy verwenden:

Jetzt hat App C keinen direkten Kommunikationszugang mehr zu App B wie zuvor.

Damit ist klar, wie du dein privates Containernetzwerk einrichtest, aber wie finden deine Apps die internen IP-Adressen der anderen heraus?

In der Vergangenheit musstest du eine eigene Service-Discovery wie Eureka einsetzen oder eine eigene schreiben, indem du z.B. eine Redis-Service-Instanz verwendet hast, an die jede App ihre Container-IP sendet. Ein Beispiel für diese Technik zwischen einer Frontend- und einer Backend-App ist hier auf GitHub zu sehen: c2cn_demo/redis_discovery(öffnet ein neues Fenster)

Aber seit Kurzem gibt es eine bessere und viel einfachere Möglichkeit, Dienste zu finden, die in die Plattform selbst integriert und standardmäßig für alle Apps verfügbar ist.

App Service Entdeckung

Die Swisscom Application Cloud unterstützt DNS-basierte Service Discovery, mit der deine Apps die internen IP-Adressen der anderen finden können. Zum Beispiel kann eine Frontend-App-Instanz den Service Discovery-Mechanismus nutzen, um die Kommunikation mit einer Backend-App-Instanz herzustellen.

Die Erkennung von Container-zu-Container-App-Diensten bietet keinen clientseitigen Lastausgleich oder Circuit-Breaking. Sie ermöglicht es deinen Apps lediglich, sich gegenseitig Service-Endpunkte zu übermitteln, ohne dass es zu einer Vermittlung kommt.

Mit der App Service Discovery können deine Apps, die in die Swisscom Application Cloud gepusht werden, eine direkte Container-zu-Container-Kommunikation über eine bekannte Route aufbauen, die von unserem internen DNS bedient wird. Die spezielle Domain "apps.internal" wurde dir zu diesem Zweck zur Verfügung gestellt.

Mit dieser Domain können deine Frontend-Apps alle Backend-Apps, die sie benötigen, leicht finden und sich mit ihnen verbinden.

Um eine Container-zu-Container-Kommunikation zwischen einer Frontend- und einer Backend-App herzustellen, musst du nur Folgendes tun:

  • Push deine Backend-App
  • Ordne ihr eine Route mit der speziellen apps.internal-Domäne zu, zum Beispiel backend-app.apps.internal
  • Die Frontend-App pushen

Die Frontend-App ist nun in der Lage, die Backend-App durch DNS-Auflösung von backend-app.apps.internal zu finden.

Die daraus resultierenden IPs sind die internen Overlay-IPs all deiner Backend-App-Container und können für die direkte Kommunikation verwendet werden.
 
Stell dir das folgendermaßen vor:

Ein Beispiel, das die App Service Discovery nutzt, findest du hier: Cats and Dogs with Service Discovery auf GitHub, das die Kommunikation zwischen Frontend- und Backend-Apps auf Cloud Foundry demonstriert.
 
Wenn du dem Beispiel folgst, wirst du auf eine ähnliche Situation stoßen wie diese:

Die Apps sind beide installiert und haben eine Netzwerkrichtlinie, die dem Frontend den Zugriff auf das Backend erlaubt, von dem 4 Instanzen laufen. Das Schlüsselelement ist die spezielle Route dogs-backend.apps.internal, die der Backend-App zugeordnet wurde:

Über diese Route kann das Frontend nun alle Container-IPs der Backend-App per DNS abfragen:

Fabio Berchtold

Fabio Berchtold

Senior Cloud Engineer

Mehr getIT-Beiträge

Bereit für Swisscom

Finde deinen Job oder die Karrierewelt, die zu dir passt. In der du mitgestalten und dich weiterentwickeln willst.

Was du draus machst, ist was uns ausmacht.

Zu den Karrierewelten

Zu den offenen Security Stellen