Guides Essentiels
Voir tous les articles de ce guide
Conseil
Cet article fait partie de notre guide: Le Grand Guide Windows Server 2016

Conteneurs Windows et stratégie de Disaster Recovery

Les conteneurs Windows se déplaçant facilement. Ils offrent une option robuste de reprise après désastre. Encore faut-il en comprendre les finesses et savoir quand et comment s'en servir.

Brien Posey
par
Publié le: 13 janv. 2017

Nouvelle fonctionnalité de Windows Server 2016, les conteneurs ont beaucoup attiré l'attention. Sur le modèle de Docker, ces conteneurs permettent de virtualiser les applications avec l'avantage supplémentaire de les rendre portables.

Il est possible de créer un conteneur Windows sur un ordinateur de bureau, de l'exécuter sur un serveur et de le faire migrer vers le Cloud sans programmation particulière. Option intéressante de reprise après désastre, les conteneurs, par leur portabilité, faciliteraient le transfert d'une application vers un Cloud public ou un autre datacenter.

Mais même si les conteneurs sont portables, en déplacer un à l'aveuglette d'un environnement à un autre peut entraîner des problèmes pour l'application qu'il contient. Ces problèmes trouvent leur source dans le mode de fonctionnement même des conteneurs.

Windows Server 2016 accepte la création de deux types de conteneurs différents : Windows Server et Hyper-V.

Dans les deux cas, le conteneur Windows est exécuté par un hôte, c'est-à-dire la machine physique ou virtuelle dans laquelle les conteneurs résident.

Il serait tentant d'assimiler un hôte de conteneurs à un hôte de virtualisation, mais il existe des différences substantielles. Une machine virtuelle (VM) vit en totale autonomie, avec son propre système d'exploitation, sa configuration matérielle, etc. À l'inverse, un conteneur ne dispose pas de son propre système d'exploitation.

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.

Pour approfondir sur Stockage de conteneurs