Les containers

1. Principe

L’isolation est une technique consistant à exécuter des applications dans leurs propres contextes, isolés des autres. C’est une forme de virtualisation. La première implémentation de ce type sous Unix date de 1979, avec chroot.

L’isolation d’un ou de plusieurs processus est assurée par le noyau Linux à l’aide des deux mécanismes : les espaces de noms ou namespaces, et les groupes de contrôle ou cgroups. Les namespaces sont apparus en 2002, et les cgroups en 2007. Tout noyau Linux intègre ces fonctionnalités par défaut. L’arrivée des espaces de noms utilisateurs ou users namespaces dans le noyau 3.8 en février 2013 a ouvert la voie au support complet des conteneurs ou containers.

Les namespaces regroupent des processus dans un espace isolé des autres. Ils permettent d’avoir :

Les cgroups contrôlent les ressources du système qu’un groupe de processsus peut utiliser, avec par exemple les contrôles suivants :

L’association de ces deux mécanismes est la base du principe du container.

2. Container et machine virtuelle

Les containers sont souvent comparés à des machines virtuelles, et s’il s’agit de deux types de technologies de virtualisation, le concept est différent.

Figure 1 : Hyperviseur et machines virtuelles

Les machines virtuelles fonctionnent sur des hyperviseurs. Qu’elles...

1. Installer Docker

Nous n’utiliserons pas la version diffusée par Ubuntu. Nous ajoutons un dépôt dans la configuration de apt.

Il faut d’abord installer quelques dépendances. Il s’agit ici d’installer la clé GPG du dépôt, puis d’ajouter le dépôt officiel de Docker et de mettre à jour apt.

Voici comment installer Docker :

$ sudo apt install apt-transport-https ca-certificates curl  
software-properties-common 
$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo  
apt-key add -  
$ sudo add-apt-repository "deb [arch=amd64]  
https://download.docker.com/linux/ubuntu focal stable" 
$ sudo apt update 
$ sudo apt install docker-ce docker-ce-cli 

Il faut vérifier si le service est démarré :

$ sudo systemctl status docker 
[sudo] password for seb: 
● docker.service - Docker Application Container Engine 
     Loaded: loaded (/lib/systemd/system/docker.service; enabled; 
vendor preset: enabled) 
     Active: active (running) since Sun 2021-01-24 18:45:43 CET; 
1min 5s ago 
TriggeredBy: ● docker.socket 
       Docs: https://docs.docker.com 
   Main PID: 791 (dockerd) 
      Tasks: 10 
     Memory: 123.6M 
     CGroup: /system.slice/docker.service 
             └─791 /usr/bin/dockerd -H fd:// --containerd= 
/run/containerd/containerd.sock 

Pour utiliser Docker en tant que simple utilisateur, comme la socket appartient au groupe docker en lecture et écriture, il faut ajouter les utilisateurs dans ce groupe.

Dans ce qui suit, un utilisateur est ajouté dans le groupe docker avec un usermod :

$ ls -l /run/docker.sock 
srw-rw---- 1 root docker 0 janv. 24 18:45 /run/docker.sock 
$ sudo usermod -a -G docker seb 
$ id seb 
uid=1000(seb) gid=1000(seb)  
groups=1000(seb),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev), ...

1. Adaptation du code

Contrairement à ce que racontent de nombreux articles de presse spécialisée, de blogs pour décideurs ou de pseudo-gourous du cloud, passer d’un modèle standalone ou on-premise à des containers, au cloud ou à Kubernetes ne résout pas magiquement tous les problèmes d’architecture, de montée en charge et de disponibilité d’une application. Sans une profonde réflexion et une nécessaire adaptation de l’architecture et du code, l’opération risque de causer plus d’ennuis que d’en supprimer.

Une image se construit à l’aide d’un fichier Dockerfile dans lequel on précise toutes les commandes nécessaires à l’installation et au démarrage du produit. Comme l’explique le chapitre Application standalone, il y a plusieurs étapes de construction pour avoir une application fonctionnelle :

Sachant qu’il n’y a pas besoin de tout l’environnement de construction (toutes les dépendances installées à la première étape), on ne va pas créer une image applicative avec tout ce contenu inutile. L’image finale ne doit contenir que le strict nécessaire pour démarrer l’application :

Le programme est modifié pour accepter des paramètres via des variables d’environnement. Lors de la construction du fichier eni-todo.war, nous avons précisé des valeurs statiques pour l’accès à la base de données MariaDB. Maintenant, vous pouvez les préciser au démarrage avec les variables suivantes :

1. MariaDB

MariaDB est une dépendance de l’application eni-todo. Pour le moment, nous laissons volontairement de côté la haute disponibilité de la base de données : nous verrons, dans la suite du fil rouge, et notamment dans le chapitre Déploiement avec Kubernetes et dans le chapitre Intégration finale, comment mettre en place une base de données sous forme de cluster. En attendant de disposer d’une version de MariaDB en haute disponibilité, nous pouvons :

Si vous réutilisez le service MariaDB existant, vous pouvez sauter cette section et passer directement à la section eni-todo.

$ sudo mkdir -p /opt/mysql