Uncategorized

Les enjeux des architectures conteneurisées

Les conteneurs aident les entreprises à moderniser leurs anciennes applications et à créer de nouvelles applications cloud natives à la fois évolutives et agiles. Les moteurs de conteneurs tels que Docker et les frameworks d’orchestration tels que Kubernetes, fournissent un moyen standardisé de packager les applications – y compris le code, le runtime et les bibliothèques – et de les exécuter de manière cohérente tout au long du cycle de vie du développement logiciel et indépendante de l’infrastructure sous-jacente (On premise, Cloud, Virtualisée, HyperConvergée…).

Cette standardisation des conteneurs mais aussi leur compacité en font un ingrédient naturel des architectures cloud. D’autant que chaque conteneur peut être instancié à l’usage en fonction des besoins métiers, son démarrage ultra rapide pénalisant peu ou pas l’exécution. Des caractéristiques particulièrement adaptées dans le cloud où la facturation est effectuée en fonction de la mémoire allouée, de la puissance utilisée et du stockage consommé. En outre, la portabilité des conteneurs rend le passage du développement à l’exploitation, d’un environnement cloud à l’autre, plus fiable, prédictible et reproductible.

En conclusion, avec les conteneurs, les architectures modernes adossées aux ressources du cloud ont trouvé leur nouvelle trajectoire, et la question n’est plus de savoir si la technologie de Conteneur va se déployer mais de savoir quand les conteneurs seront-ils plus largement utilisés que les infrastructures virtualisées ?

Selon un article récent de Forbes, l’adoption des conteneurs se développe plus rapidement que prévu en entreprise. Un nouveau rapport de Gartner le confirme: «D’ici 2023, plus de 70% des entreprises mondiales exécuteront plusieurs applications conteneurisées en production, contre moins de 20% en 2019.»

 On peut dès lors s’interroger sur les raisons qui poussent les entreprises sur la voie des conteneurs ?

La communauté et les logiciels de containerisation évoluent rapidement. Cependant, le paysage informatique des entreprises ne se transforme pas à la même vitesse, ce qui présente des défis à la fois techniques et culturels pour l’adoption et l’utilisation efficace de la technologie et des approches natives du cloud.

Une des raisons de cette croissance est due à la portabilité des conteneurs – un atout indéniable dans le monde du cloud hybride d’aujourd’hui. Les conteneurs permettent aux développeurs de déplacer les applications plus rapidement et plus facilement d’un environnement à l’autre. Par exemple, vous souhaiterez peut-être créer une application dans un cloud public, la déplacer vers un autre pour la tester, puis la transférer sur votre DataCenter pour la production.

 Un autre événement récent qui a contribué à accroître la popularité des conteneurs est la montée rapide de Kubernetes, La solution d’orchestration de conteneurs open source.

Au cours des dernières années, Kubernetes a rapidement remplacé un certain nombre d’autres orchestrateurs privés, devenant ainsi la plateforme de choix pour les conteneurs.

 Enfin les conteneurs et les architectures basées sur les microservices sont les technologies clefs parmi les approches et technologies de dernière génération qui permettent de moderniser l’organisation et le paysage SI de l’entreprise. La démarche remplace le développement d’applications monolithiques traditionnelles par un écosystème de développement moderne bati sur le cloud, des services d’API, les pipelines CI / CD et le stockage intelligent natif dans le cloud.

En revanche comment démarrer une implémentation de conteneur dans votre entreprise ?

 Avec la popularité croissante des conteneurs, chaque entreprise devrait développer et adopter une initiative de conteneur.

Identifier vos leviers et développer l’expertise technologique

Il est possible que certaines équipes utilisent déjà Docker et/ou Kubernetes, même si ces informations ne sont pas partagées avec l’équipe informatique centrale. Tout comme dans les années où le cloud public a commencé, le shadow IT était monnaie courante. La même chose se passe maintenant avec les conteneurs dans les entreprises.

 Si vous ne trouvez personne qui exploite déjà les conteneurs, créez une équipe pour le faire. Recherchez les collaborateurs au sein de votre société qui croient dans une stratégie de conteneur et sont désireuses d’apprendre.

 Une fois que vous les avez identifiés, encouragez-les et fournissez les ressources, en commençant petit avec un environnement autonome non connecté au paysage SI, ce qui leur permettra d’apprendre dans un environnement à faible risque.

Analyser votre paysage applicatif actuel

 Les conteneurs n’ont pas toujours été la solution idéale pour chaque type d’application. Les avantages des conteneurs étaient auparavant leurs limites pour les applications plus dynamiques. De par leur conception, les conteneurs n’étaient pas censés être persistants (ou avec état / statefull). C’est ce qui les rend mieux adaptés aux scénarios sans état (ou stateless) tels que les systèmes Web et les environnements de test DevOps

 Et si à l’origine, les conteneurs étaient sans état, ce qui convenait parfaitement à leur nature portable et flexible, au vu de la popularité croissante des conteneurs, des solutions de gestion pour les conteneurs statefull et stateless sont apparues. Aujourd’hui, la majeure partie du stockage des conteneurs est de type statefull et la question n’est plus de savoir s’il faut utiliser des conteneurs avec état, mais dans quel cas les employer.

 Avant de mettre en œuvre une stratégie de conteneur, vous devez avoir une bonne idée de vos applications actuelles et du type d’environnement pour lequel elles sont le mieux adaptées. Décidez si vous allez créer des applications nouvelles ou si vous allez les refactoriser. Si vous refactorisez d’anciennes applications, recherchez celles qui sont autonomes et ne nécessitent pas l’exécution d’autres applications. Ce sont les meilleurs candidats pour la conteneurisation.

Impact des conteneurs sur les organisations

Les conteneurs ne sont bien sûr qu’une technologie, mais c’est une technologie au centre des démarches et approche DevOps.

Bien évidemment, l’objectif n’est pas de créer une organisation complètement nouvelle qui adopte le DevOps, les principes Agile et la conteneurisation, mais plutôt d’adopter ces principes au sein de l’organisation existante. La plupart des organisations hésitent parce qu’il s’agit d’un travail long qui comporte certains risques, et il existe une résistance naturelle au changement, les processus et organisation existantes (ITIL) et d’autres obstacles doivent être modifiés pour ouvrir la voie à la conteneurisation.

La gestion des images de conteneurs est un domaine qui illustre bien ces impacts. La plupart des organisations essaient de rendre le Développement ou les Opérations responsables de ce qui se trouve à l’intérieur d’un conteneur. Malheureusement cette approche n’est pas efficace et contreproductive.

Le conteneur comprend le runtime de l’application plus le système d’exploitation de base (opérations) et l’application elle-même (développement). Les deux équipes doivent partager une responsabilité à part égales. Ce concept de responsabilité partagée n’existe pas vraiment dans les processus et les organisations en silo, il subsiste toujours une frontière claire entre le développement et les opérations.

 Étant donné que les images Docker sont composées de couches superposées, les opérations peuvent fournir des images de base (runtime du système d’exploitation) et les développeurs peuvent consommer ces images et superposer leur application. Cela permet aux deux groupes de travailler de manière indépendante mais de partager la responsabilité, la pierre angulaire de DevOps.

 C’est l’une des raisons pour lesquelles les conteneurs sont qualifiés de technologie permettant le DevOps, et même de s’orienter vers le DevSecOps.

Evaluer votre stockage de données

Un point très important à prendre en compte lors de la création d’une stratégie de conteneur est de comprendre où doivent se situer vos données. Vous aurez besoin à terme d’une solution ou d’une plate-forme de stockage de données qui gère à la fois les environnements avec état et sans état.

Les infrastructures de stockage héritées peuvent ne pas répondre à ces demandes.

De fait les conteneurs sont scalable en quelques secondes, ce qui signifie que vous pourriez avoir à gérer des milliers de conteneurs à tout moment. L’orchestrateur Kubernetes le gère parfaitement mais votre stockage doit être suffisamment intelligent pour interagir avec celui-ci et s’adapter instantanément.

De même l’intérêt des conteneurs repose sur leur capacité à s’exécuter dans des contextes très différents, du coup le stockage doit être capable de s’adapter et de suivre les conditions de fonctionnement de vos conteneurs.

La gestion du cycle de vie des conteneurs

Les conteneurs présentent un potentiel d’étalement encore plus important que celui des machines virtuelles. Cette complexité est souvent intensifiée par de nombreuses couches de services et d’outillage. La gestion du cycle de vie des conteneurs peut être automatisée grâce à un lien étroit avec des processus d’intégration continue / de livraison continue. Associés à des outils d’automatisation de la configuration continue, ils peuvent automatiser le déploiement de l’infrastructure et les tâches opérationnelles.

La planification doit organiser le déploiement des conteneurs sur les hôtes optimaux au niveau d’un cluster, conformément aux exigences de la couche d’orchestration.

Kubernetes est devenu la norme de facto pour la planification et l’orchestration de conteneurs, avec une communauté dynamique et le soutien de la plupart des principaux fournisseurs commerciaux. Les entreprises devront décider du bon modèle d’utilisation pour Kubernetes en évaluant soigneusement les compromis entre CaaS (conteneurs en tant que service) et PaaS (plate-forme en tant que service) ainsi qu’hybride ou cloud natif.

Pourquoi la mise en réseau conteneurisée est différente ?

Tout d’abord un environnement de conteneurs peut devoir interagir avec plusieurs milliers de conteneurs et du coup ne peut pas être traité efficacement avec des politiques réseaux classiques.

En effet les attributions statiques ne sont pas compatibles avec les volumes et une allocation dynamique standard (DHCP) qui prend quelques secondes voire minutes ne peut répondre aux exigences de délai et de réactivité nécessaire dans un environnement conteneurisé en constante évolution.

Par ailleurs dans un environnement conteneurisé, rien n’est statique. La configuration change constamment à mesure que les conteneurs sont initialisés puis détruits. De fait la gestion des listes de contrôle d’accès sont particulièrement difficiles à appliquer dans un environnement où rien n’est statique.

Tous ces défis ont des solutions. Les réseaux de superposition (Overlay), la découverte de services, les identifiants et les étiquettes permettent d’acheminer le trafic à travers des réseaux conteneurisés sans s’appuyer sur un réseau IP traditionnel.

Appréhender les problèmes de sécurité avec les applications conteneurisées à grande échelle

La sécurité est une préoccupation majeure pour de nombreuses organisations qui lancent une stratégie de conteneur. Dans une enquête menée auprès de 400 professionnels de l’informatique, 34% ont noté que la sécurité n’était pas correctement prise en compte dans leurs stratégies de conteneur.

De par leur conception, les conteneurs favorisent la sécurité des applications en isolant leurs composants et en appliquant le principe du «moindre privilège». Mais vous devrez prendre des mesures supplémentaires pour éviter les attaques par «élévation de privilèges» à plus grande échelle.

Assurez-vous que la sécurité des conteneurs est une responsabilité partagée, entre vos équipes DevOps et Sécurité.

Protégez les applications conteneurisées avec une reprise après sinistre et des sauvegardes adaptées.

Tant que cela est possible, configurez les applications de conteneur pour qu’elles s’exécutent avec un niveau d’accès «sans privilège».

Afin de protéger davantage les données sensibles, gardez-le hors des conteneurs et optez pour un accès via API.

Mettez en œuvre une solution de surveillance en temps réel avec des analyses avancées des journaux afin de pouvoir exécuter une meilleure investigation des tentatives d’attaques. En effet la durée de vie potentiellement très courte des conteneurs peut rendre difficile la détection ou l’analyse d’une attaque.

La sécurisation d’une infrastructure à base de container doit couvrir un spectre qui s’étend de la sécurisation des données, au durcissement des clusters et des hotes, en passant par la sécurisation du Runtime (contrôle de l’activité et blocage des anomalies du comportement) ou la signature des images.

 Compte tenu de la nature dynamique des environnements de conteneurs – et des nombreuses surfaces des conteneurs, des hôtes et du réseau susceptibles d’être attaquées – les pratiques standards telles que l’analyse des vulnérabilités et le renforcement des surfaces d’attaque ne sont souvent pas suffisantes pour obtenir une protection complète.

Surveillance et journalisation

En raison de leur nature éphémère, les conteneurs sont plutôt complexes et plus difficiles à surveiller que les applications traditionnelles exécutées sur des serveurs virtuels ou bare metal. Pourtant, la surveillance est une étape critique pour garantir les performances optimales des conteneurs s’exécutant dans différents environnements.

La surveillance des conteneurs n’est pas si différente des applications traditionnelles car dans les deux cas, vous aviez besoin de métriques, de journaux, de découverte de services et de vérifications de l’état. Cependant, il est plus complexe en raison de leur nature dynamique et multicouche.

La surveillance des performances des conteneurs doit prendre en compte les métriques de base telles que l’utilisation de la mémoire et l’utilisation du processeur, ainsi que des mesures spécifiques au conteneur telles que la limite du processeur et la limite de la mémoire, mais également l’infrastructure des conteneurs et des clusters.

Cependant, en plus de la couche infrastructure, il y a aussi la couche application qui entre en considération pour la stratégie d’orchestration des containers. Par contre vous ne pouvez pas collecter ces métriques à partir du runtime du conteneur, ces informations devront donc être collecter par ailleurs et pousser vers le système de surveillance.

Heureusement différentes solutions et approches se développent pour répondre à cet enjeu, cependant attention de ne pas sous-estimer la quantité de données générées par les agents de surveillance et les différents journaux. Une manière courante de résoudre ce problème consiste à limiter la conservation des données. Une autre approche utilisée est de réduire la granularité des métriques et de réduire la précision, ou l’échantillonnage. En conséquence, les équipes disposent d’informations moins précises avec moins de temps pour analyser les problèmes et une visibilité limitée pour les problèmes ponctuels ou récurrents.

Leave a Reply

Your email address will not be published.