F5 et la conteneurisation

Les organisations luttent constamment entre l’adoption des changements technologiques pour ouvrir de nouvelles opportunités commerciales et la protection de l’entreprise contre de nouveaux défis et risques. Dans cet article, nous examinerons la conteneurisation et la manière dont l’adoption de cette technologie dans les produits F5 affecte les professionnels de l’informatique, les architectes et les décideurs commerciaux.

Au cours des 20 dernières années, la virtualisation a transformé l’informatique serveur, permettant à plusieurs systèmes d’exploitation distincts de fonctionner sur une seule plate-forme matérielle. Une approche plus moderne est la conteneurisation (ou virtualisation du système d’exploitation), qui permet à plusieurs applications de s’exécuter sur une seule instance d’un système d’exploitation hôte. Chaque instance d’application partage ensuite les binaires et les bibliothèques installés dans l’instance unique du système d’exploitation. La figure 1 compare ces approches.

Contrairement aux machines virtuelles (VM), les conteneurs peuvent partager le même système d’exploitation, en virtualisant au niveau du système d’exploitation plutôt qu’au niveau de l’hyperviseur.

Sans surprise, les développeurs aiment les conteneurs car ils rendent le développement et le déploiement d’applications et la création de microservices rapides et faciles. La conteneurisation permet également une plus grande portabilité, car les applications dans les conteneurs sont plus faciles à déployer sur différents systèmes d'exploitation, plates-formes matérielles et services cloud. Les conteneurs utilisent moins de ressources que les applications exécutées directement sur des systèmes d’exploitation hébergés sur du matériel nu ou sur des machines virtuelles.

En général, la plupart des discussions (et de la documentation) sur les conteneurs se concentrent sur la perspective de programmation ou DevOps. En tant que professionnel de l'informatique, architecte système ou décideur d'entreprise, même si vous appréciez la flexibilité que la conteneurisation peut apporter, vous pouvez avoir de réelles inquiétudes quant à la manière dont ce changement affectera l'administration, la gestion et la surveillance des applications et des services au sein de votre environnement. Vous souhaitez également vous assurer que la conteneurisation n’affecte pas négativement la sécurité du réseau et des applications.

Dans un marché de plus en plus concurrentiel, les systèmes informatiques modernes doivent offrir des avantages commerciaux réalisables. Pour répondre à cette exigence, il est essentiel que les services informatiques puissent accroître leur capital applicatif, en concevant et en créant des architectures qui proposent non seulement davantage d’applications, mais également des applications dotées de plus de fonctionnalités, d’une convivialité améliorée et d’une intégration plus facile.

Le défi pour les directeurs informatiques est que leurs services doivent offrir davantage de fonctionnalités sans augmenter leurs effectifs. Les améliorations de productivité ne proviennent plus désormais de l’embauche de plus de personnes, mais des avancées technologiques et de l’automatisation qui permettent d’augmenter le nombre d’applications disponibles pour les clients, gérées par une équipe de même taille.

La facilité de déploiement des conteneurs présente un défi supplémentaire. Les développeurs ont besoin de formation et de conseils pour s’assurer qu’ils prennent en compte à la fois l’évolutivité et la sécurité lors de la création d’applications et les professionnels de l’informatique peuvent les aider à atteindre ces résultats. Ici, vous devez réfléchir à l’impact sur la production des plateformes de conteneurs telles que Kubernetes et Docker, et à la manière dont la nécessité d’être agile ne doit pas entraîner de résultats indésirables dus à de mauvaises pratiques de sécurité ou à l’absence de prise en compte des charges de production. 

Un facteur clé pour offrir des avantages commerciaux réalisables est de minimiser le délai de rentabilisation. De plus en plus, des facteurs tels que les performances et la latence passent au second plan par rapport à la facilité d’insertion. Par conséquent, si vous avez deux composants, tous deux dotés de fonctionnalités presque identiques, mais dont l’un a des performances supérieures tandis que l’autre est plus facile à intégrer, les organisations ont tendance à choisir le composant le plus facile à intégrer à l’environnement actuel. À mesure que la complexité environnementale augmente, ce biais risque de perdurer.

Lorsque vous cherchez à mettre en œuvre une technologie telle que la conteneurisation, vous avez besoin d’un moyen de mesurer la valeur qu’apporte cette nouvelle approche. Les facteurs qui affectent la valeur comprennent généralement l’adéquation, la capacité, l’effort et le coût. L’équation suivante donne un exemple de la manière d’attribuer une valeur relative en fonction de ces facteurs.

Les unités que vous utilisez dans l’équation ne sont pas pertinentes ; ce qui est important, c’est qu’elles soient les mêmes pour chaque élément que vous évaluez.

Cette équation souligne que la technologie doit être transparente pour s’intégrer et que la familiarité (c’est-à-dire la facilité d’insertion) peut être plus importante que les meilleures fonctionnalités ou performances de sa catégorie. En conséquence, l’effort de déploiement a un effet d’équilibrage lorsqu’il s’agit des calculs de valeur globale, ce qui peut faire que des produits moins performants soient plus attrayants pour les clients en raison de leur facilité d’insertion.

Un exemple de cet effet pourrait être celui de deux solutions de surveillance concurrentes. Le produit A possède des spécifications fantastiques, avec les meilleures fonctionnalités de journalisation et de création de rapports de sa catégorie. Il intègre une sécurité de niveau militaire et est hautement gérable. Malheureusement, son interface de ligne de commande propriétaire, son faible support des normes ouvertes et son manque de fonctionnalités d'intégration rendent son installation difficile. Il est également plus cher que la plupart des autres produits sur le marché.

En comparaison, le produit B est loin d’avoir les capacités de son rival, bien qu’il fournisse des niveaux acceptables de surveillance et de sécurité. Cependant, il surpasse le produit concurrent en termes de coût et de facilité d'installation. La tabulation des scores pour chaque produit produit le tableau ci-dessous, avec des notes attribuées de 1 à 10 pour l'adéquation, la capacité et l'effort d'installation, 1 étant le plus bas et 10 le plus élevé.

En insérant ces chiffres dans l’équation ci-dessus, on obtient le score de valeur indiqué dans la ligne inférieure du tableau.

Vous pouvez constater comment le produit le moins adapté et le moins performant, cinq fois plus facile à installer à moitié prix, offre une valeur estimée trois fois supérieure à celle de son meilleur rival. De nombreuses organisations comprennent ces considérations et utilisent de plus en plus la facilité d’installation et d’intégration comme facteur clé lors de l’adoption et du déploiement de nouvelles technologies. Les approches basées sur des conteneurs peuvent réduire considérablement les efforts de déploiement et contrôler les coûts tout en maintenant à la fois l’adéquation et la capacité.

Les applications générant de plus en plus de valeur commerciale, la conteneurisation offre une solution logique aux défis des pratiques de mise en œuvre informatique centrées sur DevOps. Les conteneurs offrent une isolation par rapport à la plateforme sur laquelle ils s'exécutent et les uns par rapport aux autres sans la surcharge de gestion liée à l'exécution de machines virtuelles. Les développeurs peuvent facilement créer des environnements d'application contenant tous les binaires et bibliothèques dont ils ont besoin, avec les fonctionnalités de réseau et de gestion requises intégrées. La conteneurisation simplifie également les tests et le déploiement des applications.

Les environnements basés sur des conteneurs offrent une meilleure utilisation des ressources que les ordinateurs virtuels en augmentant considérablement le nombre d'instances d'application pouvant s'exécuter sur un serveur. Sans la surcharge des systèmes d’exploitation hôtes et invités, les environnements de conteneurs utilisent plus efficacement le temps processeur et l’espace mémoire en partageant le noyau du système d’exploitation. La conteneurisation offre également plus de flexibilité architecturale, car la plate-forme sous-jacente peut être soit une machine virtuelle, soit un serveur physique. Stratégie produit Red Hat¹ indique que près de la moitié des clients Kubernetes déployant des applications dans des conteneurs à l'avenir exécuteront le moteur de conteneur directement sur du bare metal.

La conteneurisation constitue la prochaine avancée sur la voie de l'informatique matérielle à la virtualisation et au multicloud, permettant une automatisation jusqu'à 100 %, des temps de création de services inférieurs à la seconde et des durées de vie de services mesurables en secondes. C'est ce provisionnement et ce déprovisionnement immédiats de services et de microservices au sein d'une architecture informatique moderne que permettent les environnements de conteneurs tels que Docker, OpenShift et Kubernetes.

Il est important de noter que la conteneurisation offre un avantage clé qui est vital dans le monde multiplateforme et multicloud d’aujourd’hui : la possibilité de porter des applications sur site vers le cloud, vers un autre fournisseur de cloud, puis de nouveau vers le site, le tout sans modifier le code sous-jacent. L'interopérabilité étant un facteur clé qui sous-tend les décisions architecturales, cette portabilité permet aux services informatiques d'atteindre des étapes clés pour les déploiements de services d'application et aide les équipes DevOps à atteindre les objectifs organisationnels. Un récent rapport d’IBM² souligne comment l'utilisation de conteneurs pour les déploiements d'applications permet également aux entreprises d'améliorer la qualité des applications, de réduire les défauts et de minimiser les temps d'arrêt des applications et les coûts associés.

Le même rapport répertorie également les applications particulièrement adaptées aux environnements basés sur des conteneurs, notamment l’analyse de données, les services Web et les bases de données. Ici, le facteur clé est la performance, mais d’autres facteurs pertinents à prendre en compte sont de savoir si les applications sont susceptibles de s’exécuter dans plusieurs environnements et si elles utilisent des microservices pour prendre en charge plusieurs équipes DevOps travaillant en parallèle. Avec les conteneurs, vous pouvez résoudre les problèmes de performances en créant simplement davantage d'instances d'une application, à condition que vous implémentiez une conception d'architecture sans état et que vous fournissiez des services d'application à grande échelle.

Les conteneurs ne sont pas totalement exempts de défis de déploiement et la technologie encore jeune n’a pas encore atteint le niveau de maturité de la virtualisation. La section suivante met en évidence certains des défis posés par les conteneurs.

1. Gestion des clés – La gestion des clés entre les conteneurs peut être problématique, notamment parce que l’un des principaux avantages des conteneurs est la portabilité. Votre environnement de gestion des clés doit être capable de gérer le mouvement des conteneurs entre les hôtes sur site, ainsi que vers le cloud et inversement.
2. Mise en réseau – Les conteneurs remettent en question les modèles de mise en réseau traditionnels en raison de la vitesse à laquelle ils peuvent tourner de manière dynamique. Par conséquent, les adresses réseau statiques seraient impraticables dans un tel environnement. Et bien que les mécanismes d'adressage tels que le protocole DHCP (Dynamic Host Configuration Protocol) fonctionnent correctement avec les hôtes physiques et les machines virtuelles, les charges de travail des conteneurs peuvent apparaître et disparaître avant que l'adresse IP du conteneur ne puisse l'enregistrer et que le conteneur lui-même ne devienne détectable. La séparation du matériel réseau physique à l’aide d’un réseau défini par logiciel (SDN) basé sur des conteneurs est essentielle pour que vous puissiez migrer des topologies de conteneurs entières des environnements locaux vers des environnements de cloud privé et public. La plupart des environnements de conteneurs implémentent une certaine forme d'interface réseau de conteneur (CNI) pour exécuter cette fonction.
3. Plusieurs technologies de conteneurs – Votre organisation dispose peut-être déjà de plusieurs technologies de conteneurs différentes implémentées dans votre environnement. Même avec ces implémentations, il est probable que votre personnel manque de compréhension technique approfondie de tous ces environnements. La formation est importante, tout comme le fait de donner à votre équipe le temps de se familiariser avec ces différentes implémentations de conteneurs. La gestion de ces multiples technologies de conteneurs est également plus coûteuse. Cependant, les améliorations en matière de facilité de gestion, en particulier dans la dernière version de Kubernetes, ont tendance à amener les organisations à se standardiser sur l’environnement le plus simple et le plus utilisé.
4. Risques de configuration par défaut – Comme les applications sont développées dans des conteneurs, le risque de conteneurs mal configurés augmente. Un exemple est le déploiement de conteneurs dans leur configuration par défaut. Unité 42 de renseignement sur les menaces mondiales à Palo Alto³ nous avons récemment identifié plus de 40 000 périphériques conteneurs uniques dotés des paramètres de configuration par défaut. Bien sûr, tous ces cas ne sont pas vulnérables à l’exploitation, mais cela montre que les pratiques de configuration erronée de base sont répandues et font de ces organisations des cibles pour une exploitation supplémentaire.

Un critère de conception essentiel avec la conteneurisation est l’équilibre entre les trois vecteurs de performance, de densité et de fiabilité, comme le montre la figure 2.

L’approche F5 consiste à se concentrer sur la conteneurisation au niveau des composants plutôt qu’au niveau du système. Cette approche apporte plusieurs avantages, parmi lesquels :

• Réduction de l’empreinte mémoire de chaque conteneur en n’attribuant pas de mémoire aux fonctions réseau inutilisées.
• Minimiser la dépendance au CNI hôte, évitant ainsi les problèmes de performances réseau.
• Implémentation de composants petits et légers, qui ramènent le domaine de défaillance au niveau de l'abonné/utilisateur.

La conteneurisation au niveau des composants nous permet d’atteindre cet équilibre à trois via la désagrégation, la planification et l’orchestration. Les produits F5 qui implémentent des conteneurs utiliseront ensuite ces fonctionnalités pour maximiser les avantages de la conteneurisation.

Pour aider les organisations à adopter des technologies basées sur des conteneurs, F5 propose F5® Container Ingress Services , une intégration de conteneurs open source. Container Ingress Services fournit des services d'automatisation, d'orchestration et de mise en réseau tels que le routage, le déchargement SSL, le routage HTTP et une sécurité robuste. Il intègre notamment notre gamme de services BIG-IP avec des environnements de conteneurs natifs, tels que Kubernetes et Red Hat OpenShift.

D'un point de vue architectural, Container Ingress Services occupe la position suivante par rapport à vos applications conteneurisées, en ajoutant des services de contrôleur Ingress de porte d'entrée et en permettant la visibilité et l'analyse via BIG-IP.

Container Ingress Services répond à deux des problèmes clés identifiés précédemment dans ce document : l’évolutivité et la sécurité. Vous pouvez faire évoluer les applications pour répondre aux charges de travail des conteneurs et protéger les données des conteneurs en activant les services de sécurité. Avec l'intégration de la plateforme BIG-IP, vous pouvez mettre en œuvre des performances d'applications en libre-service au sein de votre environnement d'orchestration. L’utilisation de Container Ingress Services réduit également la probabilité que les développeurs implémentent des conteneurs Kubernetes avec des paramètres par défaut en utilisant des graphiques Helm pour les déploiements et les mises à niveau basés sur des modèles.

De plus, Container Ingress Services permet la sécurité grâce à une protection avancée contre les attaques d'applications de conteneurs et à des services de contrôle d'accès. Pour les développeurs d'applications et les professionnels DevOps qui ne sont pas familiarisés avec les configurations, les services d'application F5 offrent des politiques prêtes à l'emploi et un contrôle d'accès basé sur les rôles (RBAC) avec un support de niveau entreprise, en plus des communautés clients et open source DevCentral.

Les défis associés à Kubernetes natif sont liés au développement et à la mise à l’échelle d’applications de conteneurs modernes sans complexité accrue. Il peut y avoir des contraintes en termes de performances et de fiabilité, et les services qui fournissent une porte d'entrée aux conteneurs Kubernetes peuvent être implémentés de manière incohérente, nécessitant un effort d'intégration plus important pour le déploiement et la configuration.

La solution à ces défis est NGINX Kubernetes Ingress Controller , qui améliore l’environnement Kubernetes de base en fournissant des services de livraison pour les applications Kubernetes. En règle générale, les pods Kubernetes ne peuvent communiquer qu’avec d’autres pods du même cluster. La figure 4 montre le contrôleur d'entrée Kubernetes fournissant l'accès depuis le réseau externe aux pods Kubernetes, régi à l'aide de règles de ressources Ingress qui contrôlent des facteurs tels que le chemin d'accès URI (Universal Resource Identifier), le nom du service de sauvegarde et d'autres informations de configuration. Les services disponibles dépendent de votre utilisation de NGINX ou NGINX Plus. 

Les entreprises utilisant NGINX bénéficient de fonctionnalités telles que l’équilibrage de charge, la terminaison du cryptage SSL ou TLS, la réécriture d’URI et le cryptage SSL ou TLS en amont. NGINX Plus apporte des fonctionnalités supplémentaires, telles que la persistance de session pour les applications avec état et l'authentification API JSON Web Token (JWT).

À mesure que les organisations adoptent des microservices pour libérer l’agilité des développeurs et l’évolutivité native du cloud, elles sont confrontées à une courbe d’apprentissage pendant que les capacités organisationnelles rattrapent la technologie. Ces organisations souhaitent exploiter rapidement les avantages des microservices tout en préservant la stabilité qui sous-tend leur expérience client.

Aspen Mesh est une version entièrement prise en charge du service mesh open source Istio qui aide les entreprises à adopter les microservices et Kubernetes à grande échelle et à gagner en observabilité, en contrôle et en sécurité des architectures de microservices. Aspen Mesh ajoute des fonctionnalités d'entreprise clés en matière de maillage de services, notamment une interface utilisateur qui facilite la visualisation et la compréhension de l'état et de la santé de vos services, un RBAC précis et des capacités de politique et de configuration qui facilitent la conduite d'un comportement souhaité dans vos applications conteneurisées.

Aspen Mesh fournit une implémentation native Kubernetes, qui est déployée dans votre cluster Kubernetes et peut s'exécuter sur votre cloud privé ou public, ou sur site. Il est important de noter qu’il peut fonctionner en coopération avec un mécanisme d’entrée basé sur F5, en utilisant les services d’entrée de conteneurs pour provisionner des capacités de couche 7 plus approfondies.

D'un point de vue architectural, Aspen Mesh s'appuie sur un modèle de proxy side-car pour ajouter des niveaux de fonctionnalité et de sécurité aux applications conteneurisées, comme le montre la figure 5.