Conteneurs Windows et stratégie de Disaster Recovery

Composants de conteneur Windows : les obstacles à la portabilité

Une image d'OS de conteneur fonctionne comme un système d'exploitation commun pour chaque conteneur. Plusieurs conteneurs partagent couramment une même image. Cette approche présente un grand avantage : les ressources de l'hôte ne sont pas gaspillées. À l'inverse d'un hôte de virtualisation aux nombreuses VMs, une seule copie du système d'exploitation s'exécute. Comme l'image du système d'exploitation des conteneurs est mutualisée, elle est en lecture seule.

Le conteneur est constitué de deux principaux composants : une image de conteneur et un bac à sable (sandbox). L'image stocke habituellement une application virtualisée. Un conteneur peut par exemple stocker les fichiers binaires d'une application, les clés de registre, etc. L'image est en lecture seule. Les opérations d'écriture, comme les mises à jour du registre, sont écrites dans le bac à sable du conteneur.

Même si les conteneurs sont portables par conception, certains facteurs peuvent nuire à cette caractéristique : la dépendance envers l'image du système d'exploitation du conteneur en est un exemple.

Par exemple, vous créez un conteneur Windows Server avec une image du système d'exploitation basée sur Windows Server 2016. Suite à un incident, vous copiez le conteneur Windows vers un Cloud public, où il est hébergé dans un hôte de conteneurs Cloud. Mais vous ne pourriez pas faire fonctionner le conteneur sur un hôte Linux, même si Windows comme Linux prennent en charge les conteneurs Docker. En effet, le noyau sous-jacent est trop différent.

Pour la bonne exécution du conteneur, un hôte de conteneurs Cloud Windows Server aura besoin d'une copie de l'image de l'OS du conteneur et des images de toute autre dépendance.

La bonne nouvelle est qu'une image de système d'exploitation de conteneur est généralement standardisée. Dans un environnement Windows Server 2016, on peut installer un fournisseur de packages d'images de conteneurs et l'utiliser pour créer l'image du système d'exploitation des conteneurs.

Pour créer une image de système d'exploitation de base Windows Server Core, il suffit, si Docker est déjà installé et configuré, de saisir les trois commandes suivantes :

Install-PackageProvider ContainerImage -Force

Install-ContainerImage -Name WindowsServerCore

Restart-Service Docker

Prudence en cas de déplacement de volumes de données

Un des plus grands défis liés à la portabilité des conteneurs est de déplacer des volumes de données de conteneurs. Ces volumes permettent de créer un répertoire de données de conteneur ou d'ajouter un répertoire de données existant. Plusieurs conteneurs peuvent partager un même volume de données.

Il faut bien comprendre que ces volumes de données existent indépendamment du conteneur. Ils subsistent même après suppression du conteneur qui les utilise.

Lorsque le conteneur est en cours d'exécution ou en pause, tout déplacement implique généralement l'utilisation de la commande export (exporter) de Docker ; dans le cas contraire, on utilise la commande save (enregistrer) de Docker. Les deux commandes enregistrent le conteneur dans un fichier, qui peut être importé vers un autre hôte. Le problème est le suivant : puisque les volumes de données existent indépendamment des conteneurs, ils ne font pas partie des fichiers exportés.

À l'heure actuelle, la meilleure approche consiste à sauvegarder les volumes de données, puis à les restaurer après le déplacement du conteneur.

Un conteneur Windows est un bon outil dans le cadre d'une DR puisqu'il permet de porter des applications conteneurisées vers le Cloud ou un hôte de secours. Toutefois, il convient d'être prudent pour éviter de couper les liens avec les dépendances ou de perdre des volumes de données.