Utilisation de la technologie des conteneurs Docker avec les produits et services F5

L'évolution des besoins informatiques et l'avènement des stratégies de développement et de déploiement agiles ont conduit à l'émergence de la « conteneurisation », une alternative à la virtualisation complète des machines dans laquelle une application est encapsulée dans un conteneur avec son propre environnement d'exploitation. La conteneurisation est une solution intéressante qui permet aux développeurs d’itérer plus rapidement. Il offre également des avantages supplémentaires qui répondent aux frais généraux associés aux machines virtuelles, permettant une meilleure utilisation des ressources dans le centre de données défini par logiciel (SDDC).

Bien que la conteneurisation ne soit pas un concept nouveau, Docker, développé par Docker, Inc. , a été largement cité comme l'implémentation de choix en raison de son large support industriel, de sa standardisation et de son large éventail de capacités. Selon les termes de l'entreprise, Docker est « une plate-forme ouverte pour la création, l'expédition et l'exécution d'applications distribuées ». « Il offre aux programmeurs, aux équipes de développement et aux ingénieurs d'exploitation la boîte à outils commune dont ils ont besoin pour tirer parti de la nature distribuée et en réseau des applications modernes. » Ainsi, Docker simplifie la gestion du cycle de vie des applications, du développement au déploiement, et permet la portabilité des applications. Cette simplification est essentielle pour les entreprises, étant donné qu’il existe plusieurs options d’hébergement pour une application, que ce soit dans le cloud public ou dans une infrastructure de cloud privé.

Ce document décrit l'orientation de F5 concernant l'utilisation des conteneurs au sein de la technologie F5 et la prise en charge de Docker pour la livraison et la sécurité des applications. Avant d’aborder cette stratégie, il est important de reconnaître les points faibles des centres de données et pourquoi ces technologies sont essentielles pour la fourniture d’applications d’entreprise de nouvelle génération.

Note: Ce document est destiné aux décideurs informatiques, aux architectes et aux développeurs. Il est supposé que le lecteur possède une connaissance préalable de la technologie de virtualisation, du développement logiciel et du processus de cycle de vie des versions.

Plusieurs études récentes sur les points faibles de l’infrastructure des centres de données ont identifié un ensemble cohérent de besoins pour faire évoluer le centre de données :

• Méthodes de déploiement d'applications plus rapides
• Un processus de gestion du flux de travail amélioré
• Augmentation de la disponibilité et de l'utilisation des ressources informatiques
• Agilité améliorée pour déplacer les charges de travail selon les besoins

À mesure que de nouvelles tendances émergent dans le développement d’applications, les entreprises clientes modifient leur vision du modèle de gestion du cycle de vie des applications vers les points suivants :

• Les applications de nouvelle génération sont de plus en plus conçues pour « le cloud d'abord ».
• Linux est devenu le système d'exploitation (OS) de facto pour le développement du cloud.
• Applications cloud de nouvelle génération :
  • Ils sont conçus pour être sans état et utilisent une architecture de microservices faiblement couplée.
  • Utilisez des frameworks qui permettent de créer des services de manière indépendante, sans dépendances en termes de version de logiciel ou de service.
• Les entreprises adoptent de plus en plus l’automatisation en utilisant des outils de gestion de configuration (tels que Puppet, Chef et Ansible) et l’orchestration DevOps pour augmenter l’agilité de publication des logiciels.
• À mesure que les entreprises développent de nouvelles applications et migrent des applications existantes vers des clouds publics, la portabilité est essentielle pour éviter le verrouillage des fournisseurs. Bien que la technologie de machine virtuelle (VM) offre un niveau d’abstraction, chaque hyperviseur implémente son environnement différemment et n’est donc pas entièrement portable.

Docker tente de relever ces défis et est donc devenu une technologie de pointe et convaincante pour la virtualisation de l'infrastructure.

Les conteneurs permettent la virtualisation au niveau du système d’exploitation en isolant chaque application en tant que processus du système d’exploitation. Le concept existe sous de nombreuses formes dans les systèmes d'exploitation tels que BSD avec Jails, dans Oracle Solaris avec Zones et plus récemment dans Linux avec LXC. Docker s'appuie sur LXC et a ajouté le « bouton facile » pour permettre aux développeurs de créer, de packager et de déployer des applications sur l'infrastructure cloud sans avoir besoin d'un hyperviseur.

Les fonctionnalités suivantes différencient Docker des autres technologies de conteneurs :

• Une couche d'abstraction légère (le moteur Docker) au-dessus du système d'exploitation pour gérer l'isolation et la mise en réseau entre les applications.
• Une interface de programmation d'application (API) documentée pour simplifier le déploiement d'applications basées sur Linux.
• Le registre Docker pour partager des applications avec d'autres utilisateurs et développeurs.
• Portabilité des applications entre les hôtes compatibles Docker, qu'ils soient physiques, virtuels ou hébergés dans le cloud.
• Un système de fichiers syndical exposant un système de fichiers commun à tous les conteneurs Docker.
• Un écosystème d'entreprises partenaires fournissant des services et des logiciels à valeur ajoutée, permettant à Docker de bien s'intégrer dans une grande variété de styles de travail de développement.

Un système de fichiers d'union permet à chaque conteneur de fournir ses propres services spécifiques à ce conteneur, même si le chemin et le nom de fichier sous-jacents entrent en conflit avec un fichier sous-jacent. Par exemple, un conteneur peut avoir besoin de la version 2.6 d’une bibliothèque Python tandis qu’un autre peut nécessiter une version ultérieure. Le système de fichiers sous-jacent peut fournir la version 2.6, auquel cas un conteneur est satisfait. Cependant, le conteneur nécessitant la version ultérieure peut la fournir dans le cadre de son image de conteneur. Cela conduit à une empreinte plus faible pour les images de conteneurs puisqu'elles n'ont besoin de contenir que ce qui est strictement nécessaire à leur exécution.

Le diagramme de la figure 1 illustre les composants utilisés dans les déploiements d’applications VM et Docker. Notez que dans cet exemple, l’approche VM dispose de deux systèmes d’exploitation invités pour prendre en charge deux applications. En comparaison, Docker ne nécessite qu'un seul système d'exploitation hôte pour atteindre la même densité d'applications mais, bien sûr, il nécessite moins de ressources pour y parvenir.

Le tableau suivant montre la comparaison entre les capacités de VM et de Docker.

Comme mentionné précédemment, l’objectif principal de Docker est de simplifier la gestion du cycle de vie des applications. Bien que Docker sur bare metal soit certainement une option intéressante, l'exécution de Docker sur des hyperviseurs présente des avantages. Il s'agit notamment de la possibilité de prendre des instantanés et d'autoriser les migrations en direct d'un invité entier, deux éléments qui peuvent être des exigences clés pour la reprise après sinistre sans perdre l'état en cours.

Les principales solutions de gestion et d'orchestration d'infrastructures telles que VMware vRealize Suite, OpenStack et les clouds publics tels qu'AWS et Azure prennent tous en charge Docker sur une version donnée de l'hyperviseur, mais ils exposent un environnement commun au conteneur Docker, permettant la portabilité des applications quel que soit l'environnement. Ce type de modèle de déploiement hétérogène permet aux clients de commencer à utiliser Docker et de bénéficier des avantages d’une itération plus rapide sans avoir à modifier l’infrastructure sous-jacente.

En passant à une seule machine virtuelle et à un seul système d'exploitation par hôte, les clients peuvent également bénéficier d'avantages en termes de ressources puisque la machine virtuelle n'a pas à se battre pour les ressources. Cette augmentation d’efficacité est due au fait que la mémoire et le disque local peuvent être alloués à ce seul système d’exploitation tandis que l’hyperviseur n’a plus besoin d’arbitrer entre plusieurs systèmes d’exploitation.

La mise en réseau vous permet de créer des réseaux virtuels dans Docker Engine qui s'étendent sur plusieurs hôtes. Les conteneurs peuvent être attachés à ces réseaux où qu'ils se trouvent, offrant un contrôle complet sur la topologie du réseau et sur les conteneurs qui peuvent communiquer avec quels autres éléments du réseau. De plus, le système alimentant les réseaux peut être remplacé par un plug-in, ce qui vous permet de l'intégrer à n'importe quel système réseau souhaité sans avoir à modifier l'application.

Pour gérer des densités élevées de conteneurs sur un hôte donné, il est important de comprendre le mécanisme par lequel chaque conteneur rejoint le réseau. Prêt à l'emploi, Docker fournit à chaque conteneur une adresse privée accessible directement uniquement à partir d'un autre conteneur résidant sur le même hôte.

Pour que les services atteignent un conteneur à partir d'un autre hôte, ils doivent être acheminés via la fonction de traduction d'adresses réseau (NAT) basée sur iptables de Docker. Un exemple est présenté dans la figure 2.

L'interface hôte (Eth0) est exposée à l'aide d'une autre adresse (dans ce cas, une autre adresse RFC1918, 192.168.10.10). Chaque conteneur Docker se voit attribuer automatiquement une adresse dans l'espace 172.x.x/16 lors de son démarrage. Pour qu'un conteneur puisse communiquer avec des entités extérieures à son hôte de manière bidirectionnelle, un ensemble explicite de règles doit lui être attribué via iptables.

Dans l'exemple illustré dans la Figure 2, les règles ont été configurées de telle sorte que les conteneurs puissent communiquer via un mappage d'adresse IP et de port, exposant le conteneur A comme 192.168.10.10/port 80 et le conteneur B comme 192.168.10.10/port 81. Cependant, le conteneur C ne peut communiquer avec les deux autres conteneurs qu'en utilisant l'adressage 172.17.0.x.

Docker prend également en charge IPv6 et permet l'utilisation d'adresses entièrement routables. Cela permet aux conteneurs de communiquer avec d’autres sur différents hôtes sans avoir besoin de mappage d’adresses. Cependant, cela ne fonctionnera que pour IPv6, il se peut donc que son applicabilité soit limitée pour certains environnements.

De nombreux centres de données définis par logiciel utilisent le concept de réseau défini par logiciel (SDN) pour déployer de manière flexible leurs invités. SDN permet de configurer des tunnels réseau isolés pour des locataires indépendants sur le même matériel physique. Il peut également être utile de fournir une couche 2 tunnelisée à l'intérieur d'un centre de données cloud qui serait autrement entièrement routé. La mise en réseau Docker est construite autour du concept du pont Docker, qui peut être attaché à un Open vSwitch pour permettre l'interopérabilité avec des technologies telles que VXLAN ou GRE.

L'utilisation d'Open vSwitch de cette manière permet une ségrégation du réseau de couche 2 pour la multilocation ainsi que des options de connexion à d'autres environnements virtualisés. Par exemple, il est probable qu’un centre de données utilisant Docker continuera à utiliser des machines virtuelles pour les services clés pour lesquels des ressources dédiées connues doivent être réservées. Il peut s’agir de services de distribution d’applications ou de ressources hautes performances telles que des bases de données et des nœuds de traitement. Ces ressources peuvent être connectées au réseau via des technologies telles que VXLAN ou GRE afin que le trafic d’un locataire ne soit pas visible pour un autre.

La mise à l’échelle des applications dans ce type d’environnement nécessite des services ADC qui peuvent également participer nativement aux protocoles de tunneling. F5 offre des fonctionnalités VXLAN et GRE multi-locataires afin que des fonctions telles que l'équilibrage de charge, le déchargement SSL, le pare-feu, la sécurité des applications, les services NAT et DNS puissent être fournies aux clients du réseau via un tunnel. De plus, F5 offre une interopérabilité entre les types d’encapsulation de tunnel, y compris les VLAN 802.1Q.

Dans l’exemple illustré dans la Figure 3, les niveaux d’application principaux tels qu’une base de données peuvent être situés dans une partie différente du centre de données que les ressources utilisées pour héberger les instances Docker. Dans un tel cas, le réseau locataire peut utiliser GRE ou VXLAN pour isoler et joindre les deux sous-réseaux physiquement distincts.

Une solution BIG-IP peut être insérée de manière transparente dans le réseau au niveau du locataire en créant un point de terminaison de tunnel VXLAN (VTEP) sur l'instance BIG-IP. Il fait alors partie du réseau des locataires avec une connectivité aux instances Docker et de la machine virtuelle.

À partir de la version 1.7, Docker a commencé à proposer certaines fonctionnalités expérimentales qui étendent les capacités de base du réseau Docker avec les concepts SDN. L'architecture du plug-in offre une opportunité intéressante de permettre l'insertion de services de distribution d'applications et de réseau F5 pour une variété de nouveaux cas d'utilisation, y compris le pare-feu de nouvelle génération avec des conteneurs fluides en termes d'application, l'analyse du flux de conteneurs et l'application des politiques, ainsi que la gestion du trafic par flux.

F5 propose une gamme de produits permettant la virtualisation. En tant que leader du marché ADC avec le portefeuille le plus large de services de sécurité et de fourniture d'applications L4-L7 du secteur, F5 explore en permanence des technologies innovantes et étend ces technologies sur les plateformes BIG-IP, car elles partagent toutes un cadre sous-jacent commun. La figure 4 présente la gamme des offres de produits de F5, du matériel personnalisé aux offres complètes en tant que service basées sur le cloud pour les services L4-L7. La plateforme BIG-IP est bien positionnée pour prendre en charge les applications exécutées sur des conteneurs Docker.

Comme mentionné ci-dessus, F5 reconnaît les avantages de Docker dans différents cas d'utilisation. Cependant, le déploiement dans une infrastructure conteneurisée est encore naissant et plusieurs options existent pour la découverte de services (telles que Consul, etcd et Mesos-DNS), l'orchestration et la gestion du cycle de vie des services de conteneurs (qui incluent Mesos, OpenStack, Kubernetes, Docker et Cloud Foundry). Bien que les services réseau constituent un aspect essentiel de cet écosystème, il est important d’avoir une intégration étroite avec l’environnement d’orchestration pour garantir un déploiement transparent. Une telle intégration est également essentielle pour rendre les services L4-L7 disponibles et transparents pour les utilisateurs déployant des applications basées sur des microservices dans une infrastructure conteneurisée. L’approche F5 vise à fournir une expérience cohérente dans les services ainsi qu’une visualisation dans les déploiements bare metal, virtualisés ou conteneurisés.

La première partie de la résolution du problème consiste à fournir des services de mise en réseau pour le trafic nord-sud (N-S) (c’est-à-dire le trafic pour les « microservices côté client »). La plupart des principales plates-formes d’orchestration gèrent le déploiement, la mise à l’échelle et l’exposition de la connectivité des services conteneurisés au monde extérieur. En permettant une intégration étroite avec les principales plateformes d'orchestration de conteneurs, F5 garantit que les microservices N-S peuvent être automatiquement découverts par les systèmes BIG-IP, qui peuvent ensuite gérer le trafic pour ces services. Par exemple, Mesosphere Marathon et Kubernetes offrent la possibilité d’« étiqueter » les services. Ces étiquettes peuvent être utilisées pour découvrir les services côté client (mise en service, suppression ou mise à l'échelle) et peuvent être automatiquement ajoutées en tant que membres du pool au système BIG-IP.

L'utilisation de l'approche ci-dessus avec le matériel BIG-IP ou les éditions virtuelles (VE) permet la centralisation des fonctions critiques avec accélération matérielle telles que :

• Déchargement SSL avec gestion centralisée des certificats.
• Accélération telle que la compression, l'optimisation TCP et SPDY/HTTP2.
• Pare-feu sophistiqué avec protection DoS.
• Maîtrise des applications pour contrecarrer les attaques de la couche applicative.
• Visibilité sur toutes les connexions réseau entrantes et sortantes.
• Débogage grandement amélioré grâce à la journalisation intelligente et à la détection des anomalies.

Les solutions F5 offrent la possibilité de faire évoluer les applications conteneurisées ainsi que d'effectuer la traduction IPv4 vers IPv6 et DNS entre l'infrastructure Docker et le réseau externe. Pour utiliser une infrastructure de conteneurs Docker entièrement routable, les organisations auront besoin non seulement d'une fonction réseau IPv4 vers IPv6 efficace, mais également d'une prise en charge de la traduction des requêtes DNS. L'infrastructure du conteneur Docker peut fonctionner uniquement en IPv6, complètement isolée d'IPv4 et pourtant, en même temps, maintenir un chemin transparent vers la connectivité IPv4.

Dans l’exemple illustré dans la Figure 5, les services NAT64 et DNS64 ont été provisionnés (là encore, sous n’importe quelle forme, physique ou virtuelle). Le conteneur Docker tente une connexion à www.example.com, pour lequel, dans cet exemple, aucune adresse IPv6 n'existe.

Le système BIG-IP est configuré pour être le résolveur DNS pour l'installation de la plateforme Docker. Il est configuré avec une adresse IPv6 pour le résolveur DNS lui-même ainsi qu'une adresse de préfixe IPv6 spéciale (affichée en rouge) pour la traduction IPv4 vers IPv6.

Une fois que le périphérique BIG-IP a reçu la requête DNS IPv6, il effectue d’abord une opération récursive pour voir si une adresse IPv6 est disponible. Cependant, dans cet exemple, le serveur DNS faisant autorité pour www.example.com répond avec un enregistrement vide pour la requête AAAA. Le périphérique BIG-IP exécute ensuite une requête IPv4, pour laquelle il reçoit un enregistrement DNS A. Il ajoute l'adresse de préfixe spéciale à l'adresse IPv4 et la renvoie au client Docker.

Le client Docker a maintenant son adresse résolue et initie une connexion TCP. Étant donné que Docker utilise le préfixe spécial, la fonction NAT64 reconnaît que la traduction IPv6 vers IPv4 est requise.

La fonction NAT64 crée une liaison pour la connexion entre l'adresse IPv6 Docker, l'adresse NAT64 spécialement préfixée pour ce serveur IPv4 et le serveur IPv4. La demande de connexion est envoyée au serveur IPv4. Toutes les réponses de ce serveur, qui répond via IPv4, sont traduites par la fonction NAT64 pour la connectivité entre le conteneur Docker et le serveur IPv4.

L’étape critique suivante pour créer une intégration étroite consiste à fournir des services pour le trafic est-ouest (E-W), c’est-à-dire les données transmises entre les microservices qui nécessitent des services ADC. Compte tenu de la nécessité de lancer des services en quelques secondes et de la nature éphémère des microservices, l’approche F5 consiste à permettre un ADC léger. (Pour les services avancés tels que l'authentification ou la protection au niveau de l'application L7, le trafic sera redirigé vers l'instance BIG-IP sur le bord N-S.)

Le nombre de services conteneurisés dans une architecture de microservices sera beaucoup plus élevé que dans une architecture traditionnelle, avec plusieurs chemins de communication entre les microservices. L’effet secondaire probable de cette architecture peut être la complexité, ce qui rend plus difficile la résolution des problèmes de performances. Par exemple, si une application affiche de mauvaises performances, il est important d’avoir une visibilité de bout en bout sur différents services, depuis la périphérie N-S. Par conséquent, une approche de visualisation centralisée capable de corréler les modèles de trafic entre le système BIG-IP dans le domaine N-S et l'ADC léger dans le domaine E-W est extrêmement critique pour le dépannage.

Des instances de solutions F5 BIG-IP peuvent également être insérées entre les applications pour fournir des services d'équilibrage de charge ou de sécurité, répondant ainsi aux problèmes de sécurité du trafic E-W. Par exemple, un hôte Docker peut être configuré pour diriger le trafic d’un conteneur afin de traverser un système BIG-IP pour analyse avant d’entrer dans un autre conteneur. Cela peut être réalisé à l'aide de BIG-IP Application Security Manager™ (ASM), qui est fluide sur le plan des applications et peut détecter si le conteneur en question est soumis à une attaque telle que l'exploitation d'une vulnérabilité.

De nombreux déploiements réussis par les clients F5 utilisent aujourd’hui la conteneurisation à grande échelle. Ces organisations couvrent de nombreux marchés verticaux, notamment les fournisseurs financiers, de télécommunications et SaaS. Le rôle des solutions F5 dans ces environnements consiste actuellement à fournir un service ADC dans ces environnements pour garantir des applications rapides, sécurisées et disponibles. Ces services peuvent être intégrés pour permettre le libre-service aux propriétaires d’applications ou à DevOps, ou pour orchestrer ces services via le système de gestion des conteneurs.

F5 prévoit d'étendre ces services à l'infrastructure conteneurisée elle-même pour répondre à la découverte de services, à la gestion du trafic E-W et à la sécurité. F5 prévoit également d'exploiter la conteneurisation au sein de sa gamme de produits, en tirant parti de la technologie sur les plateformes physiques, en proposant des services logiciels dans des conteneurs et en utilisant l'architecture conteneurisée au sein de la plateforme de services cloud F5 Silverline®.

Le tableau ci-dessous donne un aperçu des directions que F5 explore ou développe activement :

Docker présente des opportunités claires pour améliorer l’efficacité des centres de données, qu’ils soient physiques ou basés sur le cloud. Dans le même temps, les utilisateurs de Docker peuvent être plus sûrs que leurs applications sont portables dans de nouveaux environnements. Docker permet aux développeurs d’applications de devenir plus agiles et de mettre leurs applications sur le marché plus rapidement. Lors de l'évolution de leur DevOps vers le modèle Docker, les clients profitent souvent de l'occasion pour introduire de nouveaux workflows de libre-service basés sur des services standardisés plus petits sur lesquels les développeurs peuvent placer leurs applications.

Docker permet aux applications d'évoluer rapidement grâce à l'instanciation légère de conteneurs, et les produits de distribution d'applications F5 prennent entièrement en charge ces environnements. Grâce aux solutions F5 BIG-IP, les clients peuvent orchestrer le cycle de vie complet d’une application. Cela peut être réalisé via des API REST complètes pour les opérations critiques, telles que la création et la maintenance de VIP, la gestion centralisée des certificats SSL, les services de pare-feu et la sécurité des applications avec une haute disponibilité dans une architecture multi-locataire.

Docker peut être utilisé dans une variété de modèles, y compris les déploiements de cloud public et privé. F5 est à l'avant-garde en matière d'interopérabilité et de support pour ces environnements, offrant des fonctionnalités clés qui ciblent spécifiquement OpenStack, VMware et les principaux fournisseurs de cloud tels qu'Amazon AWS et Microsoft Azure.

Les clients qui migrent vers un modèle DevOps évolué dans lequel Docker est un composant majeur reconnaissent que les améliorations opérationnelles potentiellement obtenues dépendent d'une plateforme évolutive, sécurisée, hautement disponible et aussi agile que l'exigent les nouveaux flux de travail. Les produits et services F5 sont conçus pour fonctionner avec le plus large éventail de technologies et de partenaires technologiques du secteur afin de tenir la promesse de la vision Docker. L’engagement de F5 envers Docker est soutenu par des investissements solides dans la feuille de route et une amélioration continue des produits pour assurer le succès de ce qui deviendra l’un des modèles de déploiement dominants pour le centre de données défini par logiciel.