Conteneurs : faut-il déployer en production ?

Dans cet article

1. Qu’est-ce que la conteneurisation et pourquoi devient-elle aussi populaire ?
2. Dans quels environnements technologiques la conteneurisation est-elle la meilleure solution ?
3. Qui sont les principaux acteurs de la conteneurisation ?
4. Quels sont les freins à l’adoption de Docker en environnement de production ?
5. Comment résoudre les problèmes de sécurité lors de l'utilisation de la conteneurisation ?
6. Déployez vos containers avec DROPS !

L’adoption de la conteneurisation est désormais un enjeu prioritaire pour la majorité des entreprises. Parmi celles qui l’ont déjà adoptée, 47% prévoient un déploiement de conteneurs en environnements de production, et 12% l’ont déjà fait (source Diamanti).

Le concept initial de conteneurisation a vu le jour en 1979, lors du développement d’Unix V7, avec l’introduction du « chroot system » (source Aqua). Son objectif principal est la portabilité : « construire une fois, déployer partout ».
La conteneurisation permet en effet d’isoler une application dans une sorte de prison, si l’on fait référence aux « Jails » de BSD. Il s’agit d’un système de ressources uniquement visible par le processus qui ne nécessite pas d’installer un nouvel OS puisqu’il utilise le noyau du système hôte qui gère les ressources.
Les conteneurs s’exécutent donc en natif sur leur OS, qu’ils partagent entre eux. Les applications ou services restent donc plus légers (quelques Mo en moyenne contre plusieurs Go pour les VM), et permettent une exécution beaucoup plus rapide.

La création de Docker en 2013 a popularisé le concept car il rend la conteneurisation beaucoup plus facile à utiliser et offre un écosystème complet de gestion de conteneur.
- Docker s’intègre en effet parfaitement au concept DevOps, notamment grâce au versioning : les parties développement et production s’effectuent dans le même conteneur. Donc si l’application fonctionne côté Dev, elle fonctionnera également côté Ops. Contrairement à une VM ou un applicatif traditionnel, il n’y aura aucun effet de bord dû à l’installation ou à du spécifique de configuration imposé par la production.
- Le coût en ressources explique également la popularité de la conteneurisation. A puissance égale, une machine capable de faire tourner 50 VM sera capable d’intégrer 1 000 conteneurs.
- La rapidité de démarrage d’un conteneur est également intéressante, puisqu’il n’embarque pas d’OS : seulement quelques secondes, contre plus d’une minute pour une VM.
- Enfin, l’apparition d’orchestrateurs tels que Mesos DC/OS ou Kubernetes, qui permettent d'automatiser le déploiement, la montée en charge et la gestion des applications conteneurisées. Très réactif et offrant beaucoup d’élasticité, cet ordonnanceur peut gérer les montées en charge dues à des nécessités business, comme le Black Friday par exemple, tout cela dans la minute.

La conteneurisation peut être adaptée dans tous types d’environnements, mais elle est idéale pour la gestion des applications web, surtout sous environnement Linux.
Elle est aussi très utilisée pour la partie Front-end et Middleware, mais très peu pour la partie Back-end.
En effet, les bases de données sont optimisées pour agir directement sur le matériel. La conteneurisation n’apporterait donc aucun gain de performance.
La conteneurisation est également adaptée aux « Canary Deployments », un modèle de déploiement de versions à un sous-ensemble d'utilisateurs ou de serveurs. L’objectif est d'abord de déployer le changement sur un petit sous-ensemble de serveurs, de le tester, d’en mesurer les éventuels impacts, puis de déployer le changement sur le reste des serveurs.
Kubernetes, projet offert par Google à la communauté, implémente ces déploiements de manière standard ou avancée à travers des outils comme Itsio, et permet de gérer et sécuriser les microservices.

Même si le concept de conteneurisation s’est inspiré de solutions comme Chroot, FreeBSD Jails ou LXC (Linux Containers), d’autres acteurs dominent aujourd’hui le marché. On peut citer parmi eux Docker, présenté plus haut, leader incontesté de la conteneurisation, mais également Rocket Core OS (récemment racheté par Red Hat et réputé pour sa sécurité), Canonical LXD ou Virtuozzo OpenVZ, la plus ancienne des plateformes de conteneurs.
D’autres outils fonctionnent avec ces plateformes, comme les orchestrateurs Kubernetes, Swarm (l’orchestrateur de Docker) ou encore Mesos DC/OS.

Pour les petites structures, les compétences manquent très souvent sur Docker et ses implications, mais également sur les connaissances nécessaires pour gérer les orchestrateurs.
Lorsque l’on utilise Docker, les applicatifs sont de type « stateless » du fait des microservices, alors que la plupart des applicatifs, même n-tier, sont de type « stateful ». Un travail sur l’architecture logicielle est donc nécessaire avant d’utiliser Docker en production.
Et cela implique un autre changement : l’applicatif n’est plus contrôlé de la même façon. L’utilisation de Docker engendre un nuage d’applicatifs dans lequel il faut comprendre le lien entre chaque service.
C’est donc un nouveau paradigme aussi bien pour les AdminSys que pour les développeurs : cela nécessite un nouvel outillage pour pouvoir comprendre « en live » comment ces communications se réalisent, afin d’être en mesure de résoudre les éventuels bugs. La résolution de ces problèmes est donc beaucoup plus complexe.
L’architecture logicielle est impactée, tout comme l’architecture matérielle, qui doit être en mesure de gérer de très gros volumes de logs afin d’y parvenir.

Les solutions comme Docker ont pour objectif principal d’exécuter et de gérer des conteneurs, mais ils sont rarement déployés tels quels en production. La plupart du temps, cette partie est gérée par des orchestrateurs, capables de gérer de multiples machines.
Ils proposent également des services spécifiques qui vont adresser directement les conteneurs créés sous Docker.
La sécurité est elle aussi directement gérée par ces orchestrateurs avec notamment des PKI pour la gestion des certificats, ou des CNI pour la gestion des réseaux.
L’orchestrateur propose aussi de la haute disponibilité, une gestion des données sensibles, tout en garantissant une isolation des conteneurs.
Ces outils sont donc très complexes et requièrent des niveaux techniques importants. C’est la raison pour laquelle très peu d’entre eux sont déployés On-premise.

En tant que solution d’orchestration, Drops peut, comme d’autres solutions, interagir avec un cluster Kubernetes afin d’envoyer les différentes images produites en développement vers un registry de production, qu’il soit OnPremise ou de type Cloud, comme AWS, Azure ou encore IBM Cloud.

Mais son principal atout réside dans le fait qu’il permet l’orchestration de tous types de déploiements dans un environnement hétérogène.

Drops fonctionne sur tous les types d’orchestrateurs, puisqu’il utilise les fonctionnalités mêmes de l’outil. Sans contrainte, il ne nécessite aucune installation de plugin, puisqu’il utilise des Token de communication.

Drops assure donc le déploiement, les mises à jour et le rollback des applications Legacy, OnPremise, Cloud ou conteneurs dans un même environnement.

Grâce à Drops, le déploiement s’effectue de manière globale et cohérente sur l’ensemble des applications, quelle que soit la plateforme, tout en s’appuyant sur l’infrastructure et les outils de l’orchestrateur.