Installer Build Tools dans un conteneur

Vous pouvez installer Visual Studio Build Tools dans un conteneur Windows pour prendre en charge les flux de travail d’intégration continue (CI) et de livraison continue(CD). Cet article vous explique comment procéder aux modifications nécessaires de la configuration Docker, et vous donne les charges de travail et composants que vous pouvez installer dans un conteneur.

Les conteneurs sont un excellent moyen d’empaqueter un système de génération cohérent, que vous pouvez utiliser non seulement dans un environnement serveur CI/CD, mais également dans un environnement de développement. Par exemple, vous pouvez monter du code source dans un conteneur pour qu’il soit généré par un environnement personnalisé, tout en continuant à utiliser Visual Studio ou d’autres outils pour écrire votre code. Si votre flux de travail CI/CD utilise la même image de conteneur, vous avez la garantie que votre code est généré de manière cohérente. Vous pouvez également utiliser des conteneurs à des fins de cohérence d’exécution, ce qui est courant pour les microservices qui utilisent plusieurs conteneurs avec un système d’orchestration. Toutefois, cela dépasse le cadre de cet article.

Si Visual Studio Build Tools n’a pas ce dont vous avez besoin pour générer votre code source, vous pouvez utiliser ces étapes pour d’autres produits Visual Studio. Notez, toutefois, que les conteneurs Windows ne prennent pas en charge les interfaces utilisateur interactives, et que toutes les commandes doivent être automatisées.

Avant de commencer

Il est utile d’acquérir des connaissances sur Docker pour ce qui suit. Si vous n’êtes pas déjà familiarisé avec l’exécution de Docker sur Windows, découvrez comment installer et configurer le moteur Docker sur Windows.

L’image de base ci-dessous est un exemple et peut ne pas fonctionner pour votre système. Lisez compatibilité des versions du conteneur Windows pour déterminer quelle image de base utiliser pour votre environnement.

Créer et générer le fichier Dockerfile

Enregistrez l’exemple Dockerfile suivant dans un nouveau fichier sur votre disque. Si le fichier se nomme simplement « Dockerfile », il est reconnu par défaut.

1. Ouvrez une invite de commandes.

2. Créez un répertoire (recommandé) :

   mkdir C:\BuildTools
   

3. Remplacez les répertoires par ce nouveau répertoire :

   cd C:\BuildTools
   

4. Enregistrez le contenu suivant dans C:\BuildTools\Dockerfile.

   # escape=`
   
   # Use the latest Windows Server Core 2019 image.
   FROM mcr.microsoft.com/windows/servercore:ltsc2019
   
   # Restore the default Windows shell for correct batch processing.
   SHELL ["cmd", "/S", "/C"]
   
   RUN `
       # Download the Build Tools bootstrapper.
       curl -SL --output vs_buildtools.exe https://aka.ms/vs/16/release/vs_buildtools.exe `
       `
       # Install Build Tools with the Microsoft.VisualStudio.Workload.AzureBuildTools workload, excluding workloads and components with known issues.
       && (start /w vs_buildtools.exe --quiet --wait --norestart --nocache `
           --installPath "%ProgramFiles(x86)%\Microsoft Visual Studio\2019\BuildTools" `
           --add Microsoft.VisualStudio.Workload.AzureBuildTools `
           --remove Microsoft.VisualStudio.Component.Windows10SDK.10240 `
           --remove Microsoft.VisualStudio.Component.Windows10SDK.10586 `
           --remove Microsoft.VisualStudio.Component.Windows10SDK.14393 `
           --remove Microsoft.VisualStudio.Component.Windows81SDK `
           || IF "%ERRORLEVEL%"=="3010" EXIT 0) `
       `
       # Cleanup
       && del /q vs_buildtools.exe
   
   # Define the entry point for the docker container.
   # This entry point starts the developer command prompt and launches the PowerShell shell.
   ENTRYPOINT ["C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\BuildTools\\Common7\\Tools\\VsDevCmd.bat", "&&", "powershell.exe", "-NoLogo", "-ExecutionPolicy", "Bypass"]
   

   Conseil

   Pour cibler la version 64 bits, spécifiez l’option -arch=amd64 dans la commande ENTRYPOINT pour démarrer l’Invite de commandes développeur pour Visual Studio (VSDevCmd.bat).

   Par exemple : ENTRYPOINT ["C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\BuildTools\\Common7\\Tools\\VsDevCmd.bat", "-arch=amd64", "&&", "powershell.exe", "-NoLogo", "-ExecutionPolicy", "Bypass"]

   Avertissement

   Si vous basez votre image directement sur microsoft/windowsservercore, l’installation du .NET Framework risque de ne pas s’effectuer correctement et aucune erreur d’installation ne sera signalée. Le code managé risque de ne pas s’exécuter une fois l’installation terminée. Basez plutôt votre image sur microsoft/dotnet-framework:4.8 ou une version ultérieure. Notez également que les images marquées avec la version 4.8 ou ultérieure sont susceptibles d’utiliser PowerShell comme SHELL par défaut, ce qui provoque l’échec des instructions RUN et ENTRYPOINT.

   Consultez la page Compatibilité des versions de conteneur Windows pour voir quelles versions de conteneur du système d’exploitation sont prises en charge sur les versions de système d’exploitation hôte, et la page Dépannage lié aux conteneurs Windows et Build Tools pour voir les problèmes connus.

   # escape=`
   
   # Use the latest Windows Server Core 2022 image.
   FROM mcr.microsoft.com/windows/servercore:ltsc2022
   
   # Restore the default Windows shell for correct batch processing.
   SHELL ["cmd", "/S", "/C"]
   
   RUN `
       # Download the Build Tools bootstrapper.
       curl -SL --output vs_buildtools.exe https://aka.ms/vs/17/release/vs_buildtools.exe `
       `
       # Install Build Tools with the Microsoft.VisualStudio.Workload.AzureBuildTools workload, excluding workloads and components with known issues.
       && (start /w vs_buildtools.exe --quiet --wait --norestart --nocache `
           --installPath "%ProgramFiles(x86)%\Microsoft Visual Studio\2022\BuildTools" `
           --add Microsoft.VisualStudio.Workload.AzureBuildTools `
           --remove Microsoft.VisualStudio.Component.Windows10SDK.10240 `
           --remove Microsoft.VisualStudio.Component.Windows10SDK.10586 `
           --remove Microsoft.VisualStudio.Component.Windows10SDK.14393 `
           --remove Microsoft.VisualStudio.Component.Windows81SDK `
           || IF "%ERRORLEVEL%"=="3010" EXIT 0) `
       `
       # Cleanup
       && del /q vs_buildtools.exe
   
   # Define the entry point for the docker container.
   # This entry point starts the developer command prompt and launches the PowerShell shell.
   ENTRYPOINT ["C:\\Program Files (x86)\\Microsoft Visual Studio\\2022\\BuildTools\\Common7\\Tools\\VsDevCmd.bat", "&&", "powershell.exe", "-NoLogo", "-ExecutionPolicy", "Bypass"]
   

   Conseil

   Pour cibler la version 64 bits, spécifiez l’option -arch=amd64 dans la commande ENTRYPOINT pour démarrer l’Invite de commandes développeur pour Visual Studio (VSDevCmd.bat).

   Par exemple : ENTRYPOINT ["C:\\Program Files (x86)\\Microsoft Visual Studio\\2022\\BuildTools\\Common7\\Tools\\VsDevCmd.bat", "-arch=amd64", "&&", "powershell.exe", "-NoLogo", "-ExecutionPolicy", "Bypass"]

   Avertissement

   Si vous basez votre image directement sur microsoft/windowsservercore, l’installation du .NET Framework risque de ne pas s’effectuer correctement et aucune erreur d’installation ne sera signalée. Le code managé risque de ne pas s’exécuter une fois l’installation terminée. Basez plutôt votre image sur microsoft/dotnet-framework:4.8 ou une version ultérieure. Notez également que les images marquées avec la version 4.8 ou ultérieure sont susceptibles d’utiliser PowerShell comme SHELL par défaut, ce qui provoque l’échec des instructions RUN et ENTRYPOINT.

   Consultez la page Compatibilité des versions de conteneur Windows pour voir quelles versions de conteneur du système d’exploitation sont prises en charge sur les versions de système d’exploitation hôte, et la page Dépannage lié aux conteneurs Windows et Build Tools pour voir les problèmes connus.

   Remarque

   Le code d’erreur 3010 est utilisé pour indiquer la réussite d’un redémarrage obligatoire. Pour plus d’informations, consultez Messages d’erreur de MsiExec.exe.

5. Exécutez la commande suivante dans ce répertoire.

   docker build -t buildtools2019:latest -m 2GB .
   

   Cette commande permet de générer le fichier Dockerfile dans le répertoire actif, en utilisant 2 Go de mémoire. La valeur par défaut de 1 Go n’est pas suffisante quand certaines charges de travail sont installées ; la possibilité de générer avec seulement 1 Go de mémoire dépend cependant des exigences de votre build.

   L’image finale est étiquetée buildtools2019:latest pour que vous puissiez l’exécuter facilement dans un conteneur avec buildtools2019, car l’étiquette « latest » est la valeur par défaut si aucune étiquette n’est spécifiée. Si vous voulez utiliser une version spécifique de Visual Studio Build Tools 2019 dans un scénario avancé, étiquetez le conteneur avec un numéro de build Visual Studio spécifique et avec « latest », pour que les conteneurs puissent utiliser la même version.

   docker build -t buildtools:latest -m 2GB .
   

   Cette commande permet de générer le fichier Dockerfile dans le répertoire actif, en utilisant 2 Go de mémoire. La valeur par défaut de 1 Go n’est pas suffisante quand certaines charges de travail sont installées ; la possibilité de générer avec seulement 1 Go de mémoire dépend cependant des exigences de votre build.

   L’image finale est étiquetée « buildtools:latest » pour que vous puissiez l’exécuter facilement dans un conteneur avec « buildtools », car l’étiquette « latest » est la valeur par défaut si aucune étiquette n’est spécifiée. Si vous voulez utiliser une version spécifique de Visual Studio Build Tools dans un scénario plus avancé, étiquetez le conteneur avec un numéro de build Visual Studio spécifique et avec « latest », pour que les conteneurs puissent utiliser la même version.

Utilisation de l’image générée

Maintenant que vous avez créé une image, vous pouvez l’exécuter dans un conteneur pour effectuer des générations automatisées et interactives. L’exemple utilise l’invite de commandes développeur. Votre chemin (PATH) et autres variables d’environnement sont donc déjà configurés.

1. Ouvrez une invite de commandes.

2. Exécutez le conteneur pour démarrer un environnement PowerShell avec toutes les variables d’environnement développeur définies :

   docker run -it buildtools2019
   

   docker run -it buildtools
   

Pour utiliser cette image pour votre workflow CI/CD, vous pouvez la publier dans votre propre instance Azure Container Registry ou dans un autre registre Docker interne, pour que les serveurs doivent seulement l’extraire.

Dépannage lié aux conteneurs Windows et Build Tools

Quelques problèmes nous ont été signalés concernant l’installation de Visual Studio dans un conteneur Docker.

Dépannage lié aux conteneurs Windows

Les problèmes connus suivants se produisent quand vous installez Visual Studio Build Tools dans un conteneur Windows.

• Passez -m 2GB (ou plus) au moment de la génération de l’image. L’installation de certaines charges de travail nécessite plus de mémoire que la valeur par défaut (1 Go).

• Configurez Docker pour utiliser des disques ayant une capacité supérieure à la valeur par défaut (20 Go).

• Passez --norestart sur la ligne de commande. Au moment de la rédaction de cet article, le redémarrage d’un conteneur Windows au sein même de celui-ci retourne ERROR_TOO_MANY_OPEN_FILES à l’hôte.

• Si vous basez votre image directement sur mcr.microsoft.com/windows/servercore, le .NET Framework risque de ne pas s’installer correctement et aucune erreur d’installation ne sera signalée. Le code managé risque de ne pas s’exécuter une fois l’installation terminée. Basez plutôt votre image sur microsoft/dotnet-framework:4.7.1 ou une version ultérieure. Par exemple, vous pouvez voir une erreur lors de la génération avec MSBuild qui est similaire à ceci :

  C:\BuildTools\MSBuild\15.0\bin\Roslyn\Microsoft.CSharp.Core.targets(84,5) : erreur MSB6003: Impossible d’exécuter la tâche exécutable spécifiée "csc.exe". Impossible de charger le fichier ou l’assembly 'System.IO.FileSystem, Version=4.0.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a', ou l’une de ses dépendances. Le système ne peut pas trouver le fichier spécifié.

Dépannage lié aux conteneurs Build Tools

Les problèmes connus suivants peuvent se produire lorsque vous utilisez un conteneur Build Tools. Pour voir si des problèmes ont été résolus ou s’il existe d’autres problèmes connus, consultez Developer Community.

• L’utilisation d’IntelliTrace au sein d’un conteneur peut ne pas fonctionner dans certains scénarios.
• Dans les versions antérieures de Docker pour Windows, la taille des images du conteneur par défaut est de seulement 20 Go et n’ajuste pas Build Tools. Suivez instructions pour modifier la taille des images à 127 Go ou plus. Pour vérifier s’il s’agit bien d’un problème d’espace disque, consultez les fichiers journaux. Si vous êtes à court d’espace disque, votre fichier vslogs\dd_setup_<timestamp>_errors.log comporte les éléments suivants :

Pre-check verification: Visual Studio needs at least 91.99 GB of disk space. Try to free up space on C:\ or change your target drive.
Pre-check verification failed with error(s) :  SizePreCheckEvaluator.

Contenu connexe

• Exemple avancé pour les conteneurs
• ID de composant et de charge de travail de Visual Studio Build Tools