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 et de livraison continue (CI/CD). Cet article vous guide tout au long des modifications de configuration Docker requises, ainsi que les charges de travail et les composants que vous pouvez installer dans un conteneur.

Les conteneurs constituent un excellent moyen de empaqueter un système de génération cohérent que vous pouvez utiliser, non seulement dans un environnement serveur CI/CD, mais également pour les environnements de développement. Par exemple, vous pouvez monter votre code source dans un conteneur à générer par un environnement personnalisé pendant que vous continuez à utiliser Visual Studio ou d’autres outils pour écrire votre code. Si votre flux de travail CI/CD utilise la même image conteneur, vous pouvez être assuré que votre code est généré de manière cohérente. Vous pouvez également utiliser des conteneurs pour la cohérence du runtime, ce qui est courant pour les microservices utilisant plusieurs conteneurs avec un système d’orchestration ; toutefois, cela dépasse la portée de cet article.

Si Visual Studio Build Tools n’a pas ce dont vous avez besoin pour générer votre code source, ces mêmes étapes peuvent être utilisées pour d’autres produits Visual Studio. Notez toutefois que les conteneurs Windows ne prennent pas en charge une interface utilisateur interactive afin que toutes les commandes doivent être automatisées.

Avant de commencer

Certaines connaissances de Docker sont supposées. Si vous ne le connaissez pas, découvrez comment installer et configurer le moteur Docker sur Windows.

L’image de base suivante est un exemple et peut ne pas fonctionner pour votre système. Lisez la compatibilité des versions de conteneur Windows pour déterminer l’image de base que vous devez utiliser pour votre environnement.

Créer et construire le Dockerfile

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

1. Ouvrez une invite de commandes.

2. Créez un nouveau 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 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 / Astuce

   Pour cibler la version 64 bits, spécifiez l’option -arch=amd64 dans la ENTRYPOINT commande 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, le .NET Framework risque de ne pas s’installer correctement et aucune erreur d’installation n’est indiquée. Le code managé peut ne pas s’exécuter une fois l’installation terminée. Au lieu de cela, basez votre image sur microsoft/dotnet-framework :4.8 ou version ultérieure. Notez également que les images étiquetées version 4.8 ou ultérieure peuvent utiliser PowerShell par défautSHELL, ce qui entraîne l’échec des instructions RUN et ENTRYPOINT.

   Pour savoir quelles versions du système d’exploitation conteneur sont prises en charge sur les versions de système d’exploitation hôte, consultez la compatibilité des versions de conteneur Windows. Consultez la résolution des problèmes liés aux conteneurs Windows et Build Tools pour vérifier les problèmes connus.

   Note

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

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

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

   Cette commande génère le fichier Dockerfile dans le répertoire actif à l’aide de 2 Go de mémoire. La valeur par défaut de 1 Go n’est pas suffisante lorsque certaines charges de travail sont installées ; Toutefois, vous pouvez être en mesure de générer avec seulement 1 Go de mémoire en fonction de vos besoins de build.

   L’image finale est étiquetée buildtools :latest afin de pouvoir l’exécuter facilement dans un conteneur en tant que buildtools , car la dernière balise est la valeur par défaut si aucune balise n’est spécifiée. Si vous souhaitez utiliser une version spécifique de Visual Studio Build Tools dans un scénario plus avancé, vous pouvez plutôt étiqueter le conteneur avec un numéro de build Visual Studio spécifique, ainsi que la dernière version afin que les conteneurs puissent utiliser une version spécifique de manière cohérente.

Utiliser l’image générée

Maintenant que vous avez créé une image, vous pouvez l’exécuter dans un conteneur pour effectuer des builds interactives et automatisées. L’exemple utilise l’invite de commandes développeur, de sorte que la configuration de votre chemin d’accès et des variables d'environnement système est déjà effectuée.

1. Ouvrez une invite de commandes.

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

   docker run -it buildtools
   

Pour utiliser cette image pour votre flux de travail CI/CD, vous pouvez la publier sur votre propre registre Azure Container Registry ou un autre registre Docker interne afin que les serveurs n’ont besoin que de l’extraire.

Résolution des problèmes liés aux conteneurs Windows et Build Tools

Il existe quelques problèmes lors de l’installation de Visual Studio dans un conteneur Docker.

Résoudre les problèmes liés aux conteneurs Windows

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

• Passer -m 2GB (ou plus) lors de la construction de l’image. Certaines charges de travail nécessitent plus de mémoire que les 1 Go par défaut quand elles sont installées.

• Configurez Docker pour utiliser des disques supérieurs à 20 Go par défaut.

• Passez --norestart dans la ligne de commande. À partir de cette écriture, la tentative de redémarrage d’un conteneur Windows à partir du conteneur retourne ERROR_TOO_MANY_OPEN_FILES à l’hôte.

• Si vous basez votre image directement sur mcr.microsoft.com/windows/servercore, le .NET Framework peut ne pas s’installer correctement et aucune erreur d’installation n’est indiquée. Le code managé peut ne pas s’exécuter une fois l’installation terminée. Au lieu de cela, basez votre image sur microsoft/dotnet-framework :4.7.1 ou version ultérieure. Par exemple, vous pouvez voir une erreur lors de la génération avec MSBuild semblable à ce qui suit :

  C :\BuildTools\MSBuild\15.0\bin\Roslyn\Microsoft.CSharp.Core.targets(84,5) : erreur MSB6003 : l’exécutable de tâche spécifié «csc.exe» n’a pas pu être exécuté. 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é.

Résoudre les problèmes liés aux conteneurs Build Tools

Les problèmes connus suivants peuvent se produire lorsque vous utilisez un conteneur Build Tools. Pour déterminer si des problèmes ont été résolus ou s’il existe d’autres problèmes connus, visitez la Communauté des développeurs.

• IntelliTrace peut ne pas fonctionner dans certains scénarios au sein d’un conteneur.
• Sur les versions antérieures de Docker pour Windows, la taille d’image conteneur par défaut est de 20 Go et ne correspond pas aux outils de génération. Suivez les instructions pour modifier la taille de l’image en 127 Go ou plus. Pour confirmer un problème d’espace disque, consultez les fichiers journaux pour plus d’informations. Votre vslogs\dd_setup_<timestamp>_errors.log fichier inclut les éléments suivants si vous n’avez plus d’espace disque :

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
• Répertoire du composant Visual Studio Build Tools