Impossible d'extraire la nouvelle image de base Windows si le conteneur Hyper-V est en cours d'exécution · Édition n ° 3793 · docker / for-win · GitHub

Comportement prévisible

L'extraction de la dernière image Windows Server Core réussit sans erreur, quels que soient les conteneurs en cours d'exécution sur l'hôte.

Comportement actuel

Si un conteneur Windows Server Core d'isolation Windows Hyper-V est en cours d'exécution, essayez d'extraire
une nouvelle image de base ne parvient pas à "Le processus ne peut pas accéder au fichier car il est utilisé par un autre processus."

Information

Si le même conteneur est exécuté en mode d'isolation de processus, la même commande d'extraction réussit sans erreur.

J'ai rencontré cette erreur dans l'environnement Azure Service Fabric, mais j'ai pu la reproduire sur une machine virtuelle Azure vierge. Je m'attends à ce que ce soit un problème courant, pas seulement entre des versions spécifiques d'images Windows, les versions ci-dessous sont quelques exemples pour une reproduction simple.

Notre cas d'utilisation nécessite l'utilisation de conteneurs Hyper-V dans Azure Service Fabric et le fonctionnement continu des conteneurs. Il n'est pas acceptable que nous arrêtions tous les conteneurs, par exemple. 30 minutes par mois pour extraire la nouvelle image avec les dernières mises à jour de Windows. Pour des raisons de sécurité, nous ne pouvons pas utiliser l'isolation de processus. Donc, actuellement, cela bloque notre utilisation de la production.

Le problème est reproductible chaque fois au moins avec les versions ci-dessous. Je pense que cela est arrivé plus tôt avec d'autres versions d'image, mais je n'ai pas été en mesure de le réduire correctement jusqu'à présent.

Le fichier dans le message d'erreur varie si vous utilisez différentes versions, parfois c'est par exemple. msfs.sys ou cryptsp.dll. Cependant, il semble toujours que ce soit le même fichier avec les mêmes versions exactes.

Version de Windows: Windows Server 2016 (14393.2906)
Version Docker:
Client: Docker Engine – Enterprise
Version: 18.09.4
Version de l'API: 1.39
Go version: go1.10.8
Git commit: c3516c43ef
Année de construction: 27/03/2019 18:22:15
OS / Arch: windows / amd64
Expérimental: faux

Serveur: Docker Engine – Enterprise
Moteur:
Version: 18.09.4
Version de l'API: 1.39 (version minimale 1.24)
Go version: go1.10.8
Git commit: c3516c43ef
Année de construction: 27/03/2019 18:20:29
OS / Arch: windows / amd64
Expérimental: faux

Testé avec une machine virtuelle Azure (Windows Server 2016 avec des conteneurs). Com.docker.diagnose.exe n'est pas installé sur l'ordinateur, donc je ne sais pas comment je pourrais télécharger les diagnostics.

Désolé si cette publication a été effectuée au mauvais endroit, je n’ai pas pu comprendre tous les différents choix d’assistance liés à Docker.

Étapes pour reproduire le comportement

1. Extrayez une image Windows Server Core ou toute image basée sur celle-ci. Vous trouverez ci-dessous un exemple.
   docker pull mcr.microsoft.com/windows/servercore:10.0.14393.2848
2. Exécutez l'image en mode Hyper-V, la commande réelle ne semble pas avoir d'importance tant que le conteneur est en cours d'exécution
   exécution du menu fixe –isolation = hyperv mcr.microsoft.com/windows/servercore:10.0.14393.2848 ping -t www.google.com
3. Essayez de tirer une version différente de l'image Windows Server Core
   docker pull mcr.microsoft.com/windows/servercore:10.0.14393.2906

10.0.14393.2906: Extraire de Windows / Servercore
3889bb8d808b: existe déjà
ba2bcc6237ee: Extraction [==================================================>] 1,572 Go / 1,572 Go
n'a pas réussi à enregistrer la couche: erreur re-exec: état de sortie 1: sortie: supprimer ? C: ProgramData docker windowsfilter a023be6a753a7262c46411806a7262c4641180cb4b8efb10c62132517c739bfa1add6c686c UtilityVM Files Windows System32 negoextsend il est utilisé par un autre processus.