Mise en réseau de conteneurs avec Cloud Foundry

La mise en réseau conteneur à conteneur dans le cloud d'application Swisscom permet une communication TCP et UDP directe, sûre et rapide entre tes applications. Et grâce à la découverte de services d'application intégrée, tes conteneurs d'application peuvent facilement se trouver les uns les autres.

Par Fabio Berchtold, Senior Cloud Engineer

7 mai 2018

Swisscom Application Cloud utilise la distribution open source de Cloud Foundry comme base pour te fournir une plateforme en tant que service.Depuis la publication officielle de notre plateforme, nous avons continuellement ajouté et implémenté de nouvelles fonctionnalités, dont l'interconnexion de conteneur à conteneur.

Container Networking permet une communication directe, contrôlée par des politiques, entre tes instances d'applications sur Cloud Foundry.

En se basant sur les politiques que tu peux définir via la CF CLI, tes applications ont maintenant une connexion directe entre elles, soit par TCP, soit par UDP. Tu as le choix ! Cela présente bien sûr de nombreux avantages, comme un temps de latence plus faible et un débit plus élevé grâce à la communication directe, au lieu de passer par le GoRouter ou un load-balancer externe. De plus, en tant que développeur, tu peux définir des contrôles d'accès très précis avec ces directives App-to-App. Tes apps sont plus sûres car elles communiquent directement entre elles via les IP des conteneurs au lieu d'utiliser une route publique. Cela te permet également de cacher les applications du monde extérieur et d'y accéder sans ajouter de route vers elles.

La mise en réseau conteneur à conteneur utilise en interne un réseau de superposition pour gérer et permettre la communication entre tes instances d'app. Une adresse IP de conteneur privée et unique est attribuée à tous les conteneurs d'application, ce qui leur permet de communiquer entre eux.Le réseau de superposition ne peut pas être acheminé vers l'extérieur, et le trafic envoyé entre tes conteneurs ne quitte pas le réseau de superposition.

Tu peux jeter un coup d'œil détaillé sur l'architecture en coulisses ici sur GitHub: https://github.com/cloudfoundry/cf-networking-release/blob/develop/docs/arch.md(ouvre une nouvelle fenêtre)

Super, comment puis-je l'utiliser?

Pour utiliser la mise en réseau de conteneur à conteneur, tu dois créer des politiques de réseau pour tes apps. Ces directives indiquent une application source, une application cible, un protocole et un port pour que les instances de l'application puissent communiquer directement entre elles sans passer par le GoRouter, un équilibreur de charge ou un pare-feu. La mise en réseau de conteneur à conteneur supporte à la fois TCP et UDP, et tu peux configurer des politiques pour plusieurs ports ou plages de ports. Les politiques de réseau sont appliquées immédiatement, sans que tu aies besoin de redémarrer ou de modifier ton app. Le diagramme suivant montre comment les instances d'app communiquent dans un déploiement avec une mise en réseau conteneur à conteneur activée et des politiques de réseau. Dans cet exemple, le développeur de l'app a créé des directives pour gérer le flux de trafic entre App A, App B und App C à régler.

Autoriser le trafic de données de l'app A vers l'app B dans la plage de ports TCP 7000-8000
Autoriser le trafic de données de l'app A vers l'app C sur le port UDP 5053

Si le trafic et sa direction ne sont pas explicitement autorisés, ils sont refusés par défaut. Par exemple, l'app B ne peut pas envoyer de trafic à l'app C.

Utilise les commandes de CF CLI pour configurer ces politiques de réseau:

Parmi ces trois apps, seule l'app A est exposée au monde extérieur avec un itinéraire cartographié:

Nous pouvons afficher les politiques configurées avec la commande network-policies:

Créons une politique supplémentaire avec add-network-policy pour permettre aussi la communication TCP directe sur le port 4567 de l'app C vers l'app B (mais pas l'inverse !):

Si nous nous rendons compte plus tard que c'était une erreur d'accorder à App C l'accès à App B, nous pouvons facilement supprimer la politique de réseau en utilisant remove-network-policy:

Maintenant, l'app C n'a plus d'accès direct à la communication avec l'app B comme avant.

Cela explique clairement comment tu configures ton réseau de conteneurs privés, mais comment tes applications découvrent-elles les adresses IP internes des autres?

Dans le passé, tu devais utiliser ta propre découverte de service comme Eureka ou en écrire une en utilisant par exemple une instance de service Redis à laquelle chaque app envoyait son IP de conteneur. Un exemple de cette technique entre une application frontale et une application dorsale est visible ici sur GitHub: c2cn_demo/redis_discovery(ouvre une nouvelle fenêtre)

Mais depuis peu, il existe un moyen meilleur et beaucoup plus simple de trouver des services, intégré à la plateforme elle-même et disponible par défaut pour toutes les applications.

Découverte du service App

Swisscom Application Cloud supporte la découverte de service basée sur le DNS, qui permet à tes applications de trouver les adresses IP internes des autres. Par exemple, une instance d'application frontale peut utiliser le mécanisme de découverte de service pour établir la communication avec une instance d'application dorsale.

La reconnaissance des services d'apps de conteneur à conteneur n'offre pas d'équilibrage de charge côté client ou de circuit breaking. Elle permet simplement à tes apps de se transmettre mutuellement des points finaux de service sans qu'il y ait de médiation.

Avec l'App Service Discovery, tes apps poussées dans le Swisscom Application Cloud peuvent établir une communication directe de conteneur à conteneur via une route connue, desservie par notre DNS interne. Le domaine spécial "apps.internal" a été mis à ta disposition à cet effet.

Avec ce domaine, tes applications frontales peuvent facilement trouver toutes les applications backend dont elles ont besoin et s'y connecter.

Pour établir une communication de conteneur à conteneur entre une application frontale et une application dorsale, il te suffit de faire ce qui suit:

Push ton application backend
Assigne-lui un itinéraire avec le domaine spécial apps.internal, par exemple backend-app.apps.internal
Pousser l'application frontale

L'application frontale est maintenant capable de trouver l'application dorsale en résolvant le DNS de backend-app.apps.internal.

Les IP qui en résultent sont les IP internes de superposition de tous tes conteneurs d'applications backend et peuvent être utilisées pour la communication directe.

Imagine cela comme suit

Tu trouveras ici un exemple qui utilise l'App Service Discovery : Cats and Dogs with Service Discovery sur GitHub, qui démontre la communication entre les applications frontales et backend sur Cloud Foundry.

Si tu suis cet exemple, tu rencontreras une situation similaire à celle-ci:

Les apps sont toutes deux installées et ont une politique de réseau qui permet au frontend d'accéder au backend dont 4 instances sont en cours d'exécution. L'élément clé est la route spéciale dogs-backend.apps.internal qui a été attribuée à l'application backend: