Stockage persistant dans les conteneurs

Vous pouvez rencontrer des cas où il est important qu’une application soit en mesure de conserver des données dans un conteneur, ou bien où vous souhaitiez afficher dans un conteneur des fichiers qui n’y étaient pas inclus au moment de sa génération. Le stockage persistant peut être donné aux conteneurs de deux façons :

• Lier des montages
• Volumes nommés

Docker a une vue d’ensemble de l’utilisation des volumes afin qu’il soit préférable de lire cela en premier. Le reste de cette page se concentre sur les différences entre Linux et Windows et fournit des exemples sur Windows.

Lier des montages

Les montages de liaison permettent à un conteneur de partager un répertoire avec l’hôte. Cela est utile si vous souhaitez stocker des fichiers sur l’ordinateur local qui sont disponibles si vous redémarrez un conteneur ou si vous souhaitez le partager avec plusieurs conteneurs. Si vous souhaitez que le conteneur s’exécute sur plusieurs ordinateurs avec un accès aux mêmes fichiers, alors un volume nommé ou un montage SMB doit être utilisé à la place.

Remarque

Le montage de liaison directement sur des volumes partagés de cluster (CSV) n’est pas pris en charge, les machines virtuelles agissant en tant qu’hôte de conteneur peuvent s’exécuter sur un volume CSV.

Autorisations

Le modèle d’autorisation utilisé pour les montages de liaison varie en fonction du niveau d’isolation de votre conteneur.

Les conteneurs utilisant Hyper-V isolation utilisent un modèle d’autorisation en lecture seule ou en lecture-écriture simple. Les fichiers sont accessibles sur l’hôte à l’aide du LocalSystem compte. Si vous obtenez un accès refusé dans le conteneur, assurez-vous LocalSystem d’avoir accès à ce répertoire sur l’hôte. Lorsque l’indicateur de lecture seule est utilisé, les modifications apportées au volume à l’intérieur du conteneur ne sont pas visibles ou conservées dans le répertoire sur l’hôte.

Les conteneurs Windows utilisant l’isolation des processus sont légèrement différents, car ils utilisent l’identité de processus dans le conteneur pour accéder aux données, ce qui signifie que les listes de contrôle d’accès des fichiers sont respectées. L’identité du processus en cours d’exécution dans le conteneur (« ContainerAdministrator » sur Windows Server Core et « ContainerUser » sur les conteneurs Nano Server, par défaut) sera utilisée pour accéder aux fichiers et répertoires dans le volume monté au lieu de LocalSystem, et devra disposer d’un accès pour utiliser les données.

Étant donné que ces identités existent uniquement dans le contexte du conteneur, pas sur l’hôte où les fichiers sont stockés, vous devez utiliser un groupe de sécurité connu, comme Authenticated Users lors de la configuration des listes de contrôle d’accès pour accorder l’accès aux conteneurs.

Avertissement

Ne pas lier de répertoires sensibles tels que C:\ dans un conteneur non approuvé. Cela lui permettrait de modifier des fichiers sur l’hôte auquel il n’aurait normalement pas accès et pourrait créer une violation de sécurité.

Exemple d’utilisation :

• docker run -v c:\ContainerData:c:\data:RO pour l’accès en lecture seule
• docker run -v c:\ContainerData:c:\data:RW pour l’accès en lecture-écriture
• docker run -v c:\ContainerData:c:\data pour l’accès en lecture-écriture (par défaut)

Symlinks

Les liens symboliques sont résolus dans le conteneur. Si vous montez un chemin d’accès hôte à un conteneur qui est un lien symbolique ou contient des liens symboliques, le conteneur ne pourra pas y accéder.

Montages SMB

Sur Windows Server version 1709 et ultérieure, la fonctionnalité appelée « Mappage global SMB » permet de monter un partage SMB sur l’hôte, puis de passer des répertoires sur ce partage dans un conteneur. Le conteneur n’a pas besoin d’être configuré avec un serveur, un partage, un nom d’utilisateur ou un mot de passe spécifique, qui est géré sur l’hôte à la place. Le conteneur fonctionnera de la même façon que s’il disposait d’un stockage local.

Étapes de configuration

1. Sur l’hôte de conteneur, mappez globalement le partage SMB distant :

   $creds = Get-Credential
   New-SmbGlobalMapping -RemotePath \\contosofileserver\share1 -Credential $creds -LocalPath G:
   

   Cette commande utilise les informations d’identification pour s’authentifier auprès du serveur SMB distant. Ensuite, mappez le chemin d’accès du partage à distance à la lettre de lecteur G: (il peut s’agir de toute autre lettre de lecteur disponible). Les conteneurs créés sur cet hôte de conteneur peuvent désormais avoir leurs volumes de données mappés à un chemin d’accès sur le lecteur G : .

   Remarque

   Lorsque vous utilisez le mappage global SMB pour les conteneurs, tous les utilisateurs sur l’hôte de conteneur peuvent accéder au partage distant. Toute application s’exécutant sur l’hôte de conteneur aura également accès au partage distant mappé.

2. Créer des conteneurs avec des volumes de données mappés à un partage SMB monté à l’échelle mondiale, exécutez docker -it --name demo -v g :\ContainerData :c :\AppData1 mcr.microsoft.com/windows/servercore:ltsc2019 cmd.exe

   Dans le conteneur, c :\AppData1 sera ensuite mappé au répertoire « ContainerData » du partage distant. Toutes les données stockées sur le partage distant mappé à l’échelle mondiale seront disponibles pour les applications à l’intérieur du conteneur. Plusieurs conteneurs peuvent obtenir un accès en lecture/écriture à ces données partagées avec la même commande.

Cette prise en charge du mappage global SMB est une fonctionnalité côté client SMB qui peut fonctionner sur n’importe quel serveur SMB compatible, notamment :

• Serveur de fichiers scaleout sur les espaces de stockage direct (S2D) ou un SAN traditionnel
• Azure Files (partage SMB)
• Serveur de fichiers traditionnel
• Implémentation tierce du protocole SMB (ex : appliances NAS)

Remarque

Le mappage global SMB ne prend pas en charge les dossiers DFS Namespaces (DFSN). Par exemple, si vous mappez un partage racine DFSN avec New-SmbGlobalMapping -LocalPath Z: -RemotePath \\contoso.com\share1', la lecture des cibles de dossier de cette racine renvoie l’erreur « Impossible d’atteindre l’emplacement réseau ».

Volumes nommés

Les volumes nommés vous permettent de créer un volume par nom, de l’affecter à un conteneur et de le réutiliser ultérieurement par le même nom. Vous n'avez pas besoin de connaître le chemin exact où il a été créé, seulement le nom. Le moteur Docker sur Windows dispose d’un plug-in de volume nommé intégré qui peut créer des volumes sur l’ordinateur local. Un plug-in supplémentaire est requis si vous souhaitez utiliser des volumes nommés sur plusieurs ordinateurs.

Exemples d’étapes :

1. docker volume create unwound - Créer un volume nommé « unwound »
2. docker run -v unwound:c:\data microsoft/windowsservercore - Démarrer un conteneur avec le volume mappé à c :\data
3. Écrire certains fichiers dans c :\data dans le conteneur, puis arrêter le conteneur
4. docker run -v unwound:c:\data microsoft/windowsservercore - Démarrer un nouveau conteneur
5. Exécuter dir c:\data dans le nouveau conteneur : les fichiers sont toujours là

Remarque

Windows Server convertit les chemins d’accès cibles (chemin d’accès à l’intérieur du conteneur) en minuscules ; par exemple, -v unwound:c:\MyDataou -v unwound:/app/MyData dans les conteneurs Linux, entraîne un répertoire à l’intérieur du conteneur c:\mydata, ou /app/mydata dans des conteneurs Linux, mappé (et créé, s’il n’existe pas).