Openstack Queens a été publié et c’est « Totalement Conteneur »

2018-04-10

Machine-translated from English. Read the English original

Le nombre de projets Openstack liés aux technologies de conteneurs augmente rapidement, tout comme la confusion entourant leurs cas d’utilisation différents. J’espère que cet article aidera à clarifier quand et pourquoi utiliser ces projets.

Premièrement, cependant, pourquoi les conteneurs ? Quel est l’enjeu ? Ne s’agit-il pas juste d’une autre « mode du moment » pilotée par les développeurs ? Si vous n’avez pas encore lu d’articles sur les conteneurs ou si vous ne les avez pas utilisés en développement/production, il est fort probable que vous travailliez pour une entreprise qui utilise encore des applications monolithiques traditionnelles et des méthodes de déploiement qui peuvent se trouver soit dans des centres de données privés, soit dans un cloud public.

Contexte

Au cours des 5 dernières années, une entreprise de conteneurs, Docker, a publié des logiciels et des ensembles d’outils portant le même nom (bien que le projet open source ait récemment été renommé de manière confuse en Moby), ce qui a considérablement simplifié l’utilisation du mécanisme d’isolation des processus et de leurs ressources au sein d’un système d’exploitation par rapport aux autres processus. Ces mécanismes (espaces de noms réseau, cgroups, etc.) existent depuis de nombreuses années, mais il fallait être un scientifique de la fusée (je ne plaisante pas) pour comprendre les appels système nécessaires pour invoquer l’isolation. Docker a enveloppé ces appels système dans une API très facile à utiliser, ce qui a facilité l’adoption massive des conteneurs – des personnes comme moi se sont soudainement retrouvées habilitées à le faire.

Initialement, Linux était le seul système d’exploitation hôte pris en charge, mais au cours des deux dernières années, Microsoft s’est pleinement employé à « imiter » l’expérience des conteneurs sur Windows – c’est encore un peu rugueux mais cela s’améliore rapidement. Il peut également être exécuté sur certains mainframes désormais.

Cependant, Docker ne s’est pas arrêté là ; ils ont très intelligemment mis en place un référentiel mondial gratuit qui peut être utilisé pour stocker des images de conteneurs (fichiers yaml). L’industrie du logiciel a rapidement adopté cette nouvelle technologie ainsi que le référentiel https://hub.docker.com, le remplissant rapidement avec des distributions de leurs offres logicielles emballées sous forme de conteneurs prêts à l’emploi.
Nous disposons désormais d’un moteur de conteneurs avec une bibliothèque fantastique d’applications qui peuvent être déployées simplement et, plus important encore, de manière cohérente à l’aide d’un ensemble standard de commandes.

En raison de ce référentiel et d’une excellente API, Docker est devenu la norme « de facto » pour les moteurs de conteneurs – bien que, heureusement, nous ayons l’Open Container Initiative [OCI] à laquelle Docker adhère, ce qui devrait garantir que nous pourrions changer de moteur de conteneurs si nécessaire avec un effort minimal.
Cette révolution, et je la considère comme une révolution et non une évolution, a à la fois habilité et frustré la communauté des développeurs. La frustration des développeurs survient lorsqu’ils tentent de déployer leurs applications basées sur des conteneurs dans des environnements de production non conteneurisés. Ils se retrouvent avec de longs délais pour la mise en place des environnements, ce qui entraîne des cycles d’application longs. Les projets Openstack suivants aideront probablement à résoudre bon nombre de ces défis.

Alors, pourquoi utiliser des conteneurs ?

• Une meilleure utilisation des serveurs, ce qui se traduit par une réduction des coûts de licence OS. C’est similaire à la révolution des machines virtuelles au cours de la dernière décennie, où nous avons virtualisé (P2V) de nombreux serveurs physiques en serveurs virtuels, réduisant ainsi le nombre de serveurs physiques requis. Cependant, chaque machine virtuelle nécessitait toujours son propre système d’exploitation (OS), alors que les conteneurs peuvent, et le font, partager un seul OS hôte.
  Il est possible de lancer de nombreux conteneurs au sein d’un seul OS hôte – nous obtenons ainsi encore une amélioration d’un ordre de grandeur tant en termes d’utilisation des ressources que des exigences de licence OS.

• Modernisation des applications traditionnelles. Veuillez ne pas confondre cela avec les transformations d’applications. Il s’agit ici de construire votre application monolithique (généralement avec état) à l’intérieur de conteneurs.
  Elles souffrent toujours des mêmes contraintes d’applications traditionnelles – elles nécessitent généralement des services/solutions tiers coûteux pour gérer leur état d’un point de vue de la haute disponibilité.
  Cependant, vous bénéficiez des avantages de l’abstraction IaaS (même expérience que vous soyez déployé dans un cloud privé ou public) et de déploiements cohérents et codifiés. Vous jouez effectivement désormais dans l’espace des Conteneurs en tant que Service (CaaS) avec des applications traditionnelles.
• Développement d’applications Cloud Native. Ces applications ont tendance à utiliser intensivement les modèles de micro-services aujourd’hui, et les micro-services enveloppés dans des conteneurs constituent une combinaison très puissante et complémentaire.
• Déploiements dans les pipelines DevOps. Pensez à l’intégration continue et au déploiement continu. En standardisant les conteneurs comme meilleure pratique de déploiement de vos applications, vous abstrayez efficacement les complexités inutiles de l’infrastructure sous-jacente. Les développeurs peuvent s’assurer de la même expérience de déploiement, qu’ils ciblent leur propre ordinateur portable, un serveur de développement ou même le K5 de Fujitsu, le cloud public AWS d’Amazon ou le cloud public Azure de Microsoft. Ces trois derniers clouds publics sont tous soutenus par des technologies d’infrastructure et des API très différentes, mais cela ne nous importe plus ! Ces environnements ont simplement besoin de la capacité d’exécuter le même moteur de conteneurs.

Quel rapport Openstack a-t-il avec les conteneurs ?

Les diverses initiatives de conteneurs d’Openstack sont là pour aider à résoudre le déploiement et la gestion des conteneurs en production sur des machines nues (baremetal) et des machines virtuelles qui ont été construites à l’aide de la suite logicielle Openstack. Les projets ciblent à la fois les opérateurs d’infrastructure qui peuvent eux-mêmes tirer parti des avantages des conteneurs pour leurs propres déploiements Openstack, mais les projets sont également conçus avec les développeurs en tête pour les aider à soulager leurs problèmes de déploiement de pipeline, s’assurant ainsi qu’ils peuvent avoir un processus cohérent, rapide et agile pour déplacer rapidement leurs applications en production.

Magnum
Il s’agit de l’API du moteur d’orchestration de conteneurs. Disons que vous souhaitez déployer et gérer un cluster Kubernetes ET/OU un cluster Docker Swarm ET/OU un cluster Apache Mesos, eh bien Openstack Magnum fournira une API cohérente qui peut envelopper ces différentes technologies et fournir une interface cohérente pour les opérateurs d’infrastructure. Cela signifie que les opérateurs devraient pouvoir utiliser le même processus et des appels d’API familiers pour déployer ces produits très différents.

Zun
D’après le site web du projet : « Zun (ex. Higgins) est le service de conteneurs OpenStack. Il vise à fournir un service API pour exécuter des conteneurs d’application sans avoir besoin de gérer des serveurs ou des clusters. » En gros, Zun pour les conteneurs, c’est ce que Nova est pour les machines virtuelles et Ironic pour les serveurs baremetal. Le service Nova-Docker était une tentative précoce de gérer les conteneurs via l’API de calcul Nova. Zun n’est pas lié à l’API Nova.

Kuryr
Encore une fois, le site web du projet fournit un bon résumé – « L’idée derrière Kuryr est de pouvoir tirer parti de l’abstraction et de tout le travail difficile qui a été fourni dans Neutron et ses plugins et services, et de l’utiliser pour fournir un réseau de qualité production pour les cas d’utilisation des conteneurs. Au lieu que chaque plugin Neutron indépendant ou solution essaie de trouver et de combler les lacunes, nous pouvons concentrer nos efforts et nous concentrer à un seul endroit – Kuryr. Kuryr vise à être le « pont d’intégration » entre les deux communautés, Docker (ou un autre moteur de conteneurs) et Neutron, et proposer et piloter les changements nécessaires dans Neutron (ou dans Docker) pour être en mesure de répondre aux cas d’utilisation spécifiques au réseau des conteneurs. Il est important de noter que Kuryr n’est PAS une solution de réseau en soi, ni ne tente de le devenir. L’effort Kuryr se concentre à être le coursier qui livre le réseau et les services Neutron à Docker. »

Kolla
Il s’agit de services OpenStack de qualité production livrés sous forme de conteneurs prêts à l’emploi. Tout développeur lisant ceci comprendra immédiatement à quel point cela est puissant – OpenStack déployé sous forme de conteneurs ! Pour quiconque comme moi, qui a traversé la douleur des grandes installations bash d’OpenStack dans les datacentres clients, comme le dit la chanson de D:ream, « Les choses ne peuvent qu’améliorer »… et elles l’ont fait. Les conteneurs sont bien l’avenir du déploiement d’applications. Ils fournissent un mécanisme cohérent, codifié et donc contrôlable pour des déploiements rapides (ou des retours arrière si cela est requis). Ces images de conteneurs Kolla seront utilisées en combinaison avec le projet/module LOCI.

LOCI
« L’objectif de LOCI est de fournir des images et des outils légers conformes à OCI, adaptés à la CI/CD, pour les services OpenStack. Vous pouvez construire des images LOCI dans un environnement isolé (air-gapped) sans aucune modification (en supposant que vous disposiez d’un miroir git, de packages et de pypi). » Le secteur des télécommunications, grand adopteur d’Openstack, envisage LOCI comme un composant vital pour impulser l’avenir d’Openstack dans l’espace du calcul en périphérie (Edge Computing). Imaginez votre routeur ou décodeur domestique BT, Virgin Media ou AT&T exécutant un conteneur. Cela donnerait à ces entreprises ET aux utilisateurs domestiques une agilité et une flexibilité beaucoup plus grandes. Vous pourriez potentiellement changer de fournisseur en quelques secondes sans avoir besoin de nouveau matériel – une victoire pour tous. Pour les petites entreprises et les datacentres en périphérie, cela peut également supprimer le besoin de matériel dédié à une seule tâche – l’IoT, le Big Data et la réglementation gouvernementale stimuleront rapidement la croissance dans l’espace du calcul en périphérie au cours des prochaines années.

De nombreuses autres améliorations significatives ont été apportées à Openstack dans cette version, en particulier autour de la virtualisation GPU, donc pour les détails complets, lisez https://www.openstack.org/software/queens/

Happy Stacking !

Graham

Originally published on allthingscloud.eu (2018-04-10).