Dans un ordinateur classique, on trouve trois grands ensembles : le matériel, le système d’exploitation et les applications. Le rôle du système d’exploitation est primordial : il exploite le matériel et présente des capacités aux applications (via des interfaces de programmation, ou API), qui peuvent les utiliser pour proposer des services. Le principe ne change pas, quel que soit le type d’ordinateur ou le système.

Si ce système suffit dans la majorité des cas, il en existe de nombreux où cette organisation devient rébarbative. Exemple classique : vous développez une application sur un Mac et souhaitez en tester une variante Windows. En toute logique, vous vous tournez vers un ordinateur équipé du système de Microsoft pour y installer l’application et observer son comportement.

Autre problématique : le système d’exploitation. Tout éditeur d’une application doit viser une ou plusieurs versions d’un système, chacune avec des spécificités. La configuration peut largement varier d’une machine à une autre, même si les composants centraux sont normalement présents. Il faut notamment composer avec les dépendances de l’application, c’est-à-dire tous les composants dont elle a besoin pour fonctionner.

Pour s’affranchir de ces problèmes dans certains scénarios, beaucoup recourent aujourd’hui à une forme de virtualisation ou une autre. Commençons par les machines virtuelles, qui existent depuis longtemps.

Qu’est-ce qu’une machine virtuelle ?

Une machine virtuelle – ou VM – est une copie numérique d’une machine physique. Au sein d’un seul fichier, on trouve toutes les informations sur le matériel, le système d’exploitation et les applications qui y sont installées.

Cette pratique a été largement démocratisée par des projets libres comme VirtualBox et des sociétés telles que VMware et Parallels. Ses scénarios d’utilisation sont nombreux. Dans le cadre de tests par exemple, on peut installer un client de virtualisation (VirtualBox par exemple) et créer une machine virtuelle par système d’exploitation que l’on veut tester.

Cette pratique, longtemps limitée, a pris son essor avec la puissance toujours grandissante des ordinateurs, en particulier la multiplication des cœurs dans les processeurs et la baisse du coût de la RAM. Sur une machine contenant par exemple 16 Go de mémoire, il est simple de créer une machine virtuelle en contenant 4 ou 8 Go pour tester un environnement.

Tous les clients de virtualisation permettent de paramétrer plus ou moins finement les caractéristiques de la machine, comme le nombre de cœurs, la quantité de mémoire, l’espace de stockage, le type d’interface réseau, ou encore des options plus poussées comme le type de firmware, le chiffrement de la machine virtuelle, la gestion de l’énergie, etc.

Attention à ne pas confondre virtualisation et émulation. Cette dernière consiste à simuler la présence d’un matériel à l’architecture différente de la machine hôte. C’est ce que font par exemple les émulateurs de console. Cette opération est autrement gourmande en puissance de calcul.

L’hyperviseur tout-puissant

Outre le fait de pouvoir mettre en place rapidement un environnement de test, les machines virtuelles permettent de beaucoup mieux exploiter le matériel sur des configurations très musclées, comme peuvent l’être les serveurs.

Il est désormais courant qu’un serveur dispose de plusieurs machines virtuelles, par exemple pour créer des environnements spécialisés et isolés. Un même serveur peut ainsi présenter une multitude de machines de type Unix, Linux ou Windows, en fonction des besoins des clients. Ce type d’utilisation a explosé avec le cloud.

Mais qui orchestre ce grand ballet ? L’hyperviseur, un composant dont la mission est de créer et exécuter les machines virtuelles. Il leur attribue les ressources choisies, fait le lien avec l’hôte (le matériel) tout en l’isolant des machines virtuelles. Avec un hyperviseur, et selon la solution choisie, les ressources ne sont pas fixes et peuvent être allouées dynamiquement en fonction des conditions.

Point important, c’est toujours le matériel de la machine hôte qui exécutera les opérations. À charge pour l’hyperviseur de répartir les demandes de calculs en fonction des critères fixés par l’administrateur.

Petite précision enfin. Il existe deux types d’hyperviseur. Le type 1 désigne un hyperviseur s’exécutant directement sur le matériel, à la place du système d’exploitation. On le rencontre essentiellement dans les centres de données et autres environnements basés sur des serveurs. KVM sur Linux, Hyper-V sur Windows, Proxmox VE ou encore vSphere de VMware sont des hyperviseurs de type 1.  Le type 2 s’installe sur un système comme une application et se rencontre surtout sur des ordinateurs personnels. VirtualBox, VMware Workstation et Parallels Desktop (sur Mac) en sont des exemples.

Qu’est-ce qu’un conteneur ?

Un conteneur présente des similitudes avec une machine virtuelle, dans le sens où il s’agit d’un assemblage de paquets devant fonctionner de manière isolée. La ressemblance s’arrête ici, car si un hyperviseur peut prendre la place d’un système d’exploitation, le conteneur vise, lui, l’applicatif.

Un conteneur regroupe un ou plusieurs processus ainsi que toutes les dépendances nécessaires. Il ne tient compte de l’environnement d’exécution qu’en tant que plateforme générale, mais il offre un gros avantage : il ne tient presque pas compte de la version et de la configuration.

L’exemple le plus courant est le Snap, largement poussé par Canonical. Depuis le Store d’Ubuntu, de nombreuses applications sont présentées sous cette forme. À l’installation, le conteneur contient toutes les données nécessaires au bon fonctionnement de l’application. Cela permet aux éditeurs de créer un environnement « idéal », avec toutes les bonnes versions des composants. Le désavantage est connu : élargir ce fonctionnement à toutes les applications peut consommer beaucoup plus d’espace disque.

En d’autres termes, le conteneur virtualise le système d’exploitation, là où la VM virtualise le matériel. Dans les deux cas, on parle d’images.

Avantages, orchestration et déploiement

Au-delà de la simple isolation vis-à-vis du système d’exploitation, les conteneurs ont d’autres gros avantages, notamment en matière de déploiement.

La fin des grandes applications monolithiques et l’arrivée du cloud ont permis l’éclatement du code et le grand avènement des microservices. À la clé, une redondance améliorée et la possibilité de laisser un service accessible pendant des opérations de maintenance. Les conteneurs convenaient parfaitement aux microservices par leur souplesse.

L’arrivée de Docker a largement participé à en répandre l’usage. Cette plateforme simplifie la création de conteneurs en regroupant tout ce qui est nécessaire à une application pour fonctionner. D’autres solutions sont apparues par la suite, avec le même objectif, comme Buildah, Containerd ou Podman. Cette facilité n’est cependant qu’une étape, la souplesse recherchée pour le déploiement appelle d’autres outils.

C’est là qu’entrent en piste d’autres projets comme Kubernetes, Docker Swarm ou encore Apache Mesos. Ces outils prennent en charge le déploiement et l’exécution des conteneurs, leur coordination et leur planification. Les administrateurs peuvent ainsi définir précisément quel conteneur doit être déployé, où et quand, que faire en cas de mise à jour, de mise à niveau ou en cas de remplacement sans temps d’arrêt. Ces infrastructures surveillent également le fonctionnement général, l’état de santé des conteneurs, etc.