Tutoriel : Premiers pas de développeur avec Docker, Azure et Visual Studio 3/3

Dans la partie 2 de ce tutoriel, nous avons déployé une application console ASP.Net 5 dans un conteneur linux sur Azure. Pour réaliser cela, il nous fallait une VM linux avec l’agent Docker, que nous avons créé depuis le portail Azure.

Cette fois, nous allons déployer la même application mais dans un conteneur Windows, tout cela – de la création de la VM au déploiement de l’app - directement depuis Visual Studio.

Il faudra prendre quelques précautions dans le projet Visual Studio, pour bien dissocier les paramètres spécifiques à la cible du déploiement linux/windows: nous verrons cela en temps voulu dans la suite de l’article.

Voici les grandes étapes de ce tutoriel:

• Créer la VM supportant les conteneurs Windows, depuis Visual Studio
• Retrouver la VM sur le portail Azure (ce n’est pas nécessaire, mais ça peut toujours servir !)
• Déployer l’application (et constater que le déploiement échoue)
• Modifier le fichier dockerfile
• Déployer l’application à nouveau
• Et si chez moi ça ne marche pas ?

Entre temps, une nouvelle version du package des outils Docker pour Visual Studio est sortie. N’hésitez pas à la mettre à jour avec la dernière en date si besoin. (voir la partie 2 de ce tutoriel pour les détails d’installation)

Créer la VM supportant les conteneurs Windows, depuis Visual Studio

Placez-vous dans Visual Studio, sur votre projet

Cliquez sur le bouton droit et sélectionnez “Publish”

Après avoir sélectionné “Docker Containers”, cliquez sur le bouton “New”

Remplissez les champs, avec notamment l’image de l’OS qui sera Windows Server 2016 Technical Preview with Containers.

Les certificats Docker seront générés automatiquement si besoin, dans le répertoire .docker du profil de l’utilisateur.

Lorsque vous validez, le script PowerShell suivant est lancé.

Deploy-DockerAzureResourceGroup.ps1' -ResourceGroupName 'stephetutodockerwin' -ResourceGroupLocation 'westeurope' -TemplateFile 'C:\stepheWin8\Projets\DockerConsoleApp\PublishScripts\Templates\DockerConsoleAppDockerVM.json' -TemplateParametersFile 'C:\stepheWin8\Projets\DockerConsoleApp\PublishScripts\Templates\DockerConsoleAppDockerVM.param.dev.json' -DockerCertsDirectory 'C:\Users\stephe\.docker' -AdminPassword 'XXXXXX'

Il utilise un template ARM nommé DockerConsoleAppDockerVM.json que vous retrouverez dans votre projet, tout comme le script PowerShell d’ailleurs:

Retrouver la VM sur le portail Azure

Si vous jetez un œil à votre portail Azure, vous verrez que la VM (de type ARM : Azure Resource Manager qui est le nouveau modèle de VM) est en cours en provisionnement

Si tout se passe bien, VS vous prévient dans la fenêtre d’Output que le déploiement du template s’est bien passé.

Déployer l’application

Refaites un clic droit sur le projet pour déployer à nouveau le projet

Si vous cliquez sur “Validate Connection”, vous verrez apparaitre le petit icône check vert qui indique que la connexion au Docker host a réussi.

Cliquez maintenant sur le bouton “Publish” : aïe, le déploiement se passe mal’

Impossible de trouver l’image docker/aspnet ? Je parie que vous voyez où je veux en venir.

Modifier le fichier dockerfile

En effet, le fichier dockerfile présent dans notre projet est resté le même depuis le déploiement sous linux. Or les images docker permettant de faire tourner l’application sur Windows sont différentes. Pour rappel, notre dockerfile part de l’image microsoft/aspnet qui se base sur Mono. Vous trouverez plus de détails sur le sujet dans le 2ème volet de cet article.

Visual Studio est capable de générer le dockerfile qui va bien en fonction de la cible du déploiement, mais pour cela, le fichier ne doit pas encore exister. Donc nous allons renommer le .dockerfile existant en .dockerfile.linux:

Redéployer l’application

On relance le déploiement et on remarque que VS nous informe qu’il va regénérer le fichier puisqu’il mentionne “autogenerate” (c’est grisé, il faut de bons yeux !)

Remarquez que le Dockerfile contient maintenant:

FROM windowsservercore
ADD . /app
WORKDIR /app/approot
ENTRYPOINT DockerConsoleApp.cmd

Cette fois on part de WindowsServerCore qui correspond à l’image d’un conteneur de  Windows Server 2016 (Tech preview).

Au démarrage du conteneur, c’est le paramètre ENTRYPOINT qui sera utilisé pour démarrer l’application, à savoir le fichier de commande DockerConsoleApp.cmd.

Vous trouverez ce fichier dans un répertoire temporaire du profil de l’utilisateur : C:\Users\stephe\AppData\Local\Temp\PublishTemp\DockerConsoleApp82\approot

Si vous mettez le compilateur en mode verbose dans Visual Studio

Vous verrez apparaître le chemin utilisé pour la génération du package de déploiement et du .cmd (Menu Tools/Options):

Voici son contenu:

@echo off
SET DNX_FOLDER=dnx-coreclr-win-x64.1.0.0-rc1-final
SET "LOCAL_DNX=%~dp0runtimes\%DNX_FOLDER%\bin\dnx.exe"
IF EXIST %LOCAL_DNX% (
SET "DNX_PATH=%LOCAL_DNX%"
)
for %%a in (%DNX_HOME%) do (
IF EXIST %%a\runtimes\%DNX_FOLDER%\bin\dnx.exe (
SET "HOME_DNX=%%a\runtimes\%DNX_FOLDER%\bin\dnx.exe"
goto :continue
)
)

:continue
IF "%HOME_DNX%" NEQ "" (
SET "DNX_PATH=%HOME_DNX%"
)
IF "%DNX_PATH%" == "" (
SET "DNX_PATH=dnx.exe"
)
@"%DNX_PATH%" --project "%~dp0src\DockerConsoleApp" --configuration Debug DockerConsoleApp %*

On voit que l’on utilise en fait dnx.exe qui est le host natif capable de prendre en charge l’exécution notre application console. Pour comprendre comment cela fonctionne, je vous suggère la lecture suivante, et notamment l’architecture ci-dessous:

Une fois le déploiement terminé, Visual Studio vous indique comment accéder à l’output de l’application:

Si vous copiez-collez cette ligne de commande dans un prompt, vous devriez voir le résultat suivant:

Et voilà….

Pour terminer, il vous suffit de renommer le dockerfile en dockerfile.Windows et de bien spécifier celui-ci dans le boite de dialogue servant au déploiement de l’application sur Windows. Il faudra faire de même avec le profil permettant de déployer sur Linux.

Visual Studio est aussi capable de suffixer le dockerfile tout seul lorsqu’il le génère : notamment si vous avez déjà un autre dockerfile suffixé dans votre projet : dans mon cas, à la génération du dockerfile, il l’a directement nommé dockerfile.Windows !

Et si chez moi ça marche pas ?

Si vous rencontrez ce genre de souci lors du déploiement de l’application:

Cela signifie qu’il vous manque certaines versions du runtime sur votre machine cliente. Pour les installer, il vous suffit d’utiliser l’outil dnvm en ligne de commande:

Pour voir les runtimes installés :

> dnvm –list

Pour installer dnx-coreclr version 1.0.0-rc1-final pour Windows avec l’architecture x64:

> dnvm install 1.0.0-rc1-final –r coreclr –arch x64

Veillez également à installer les dernières versions du SDK Azure et des outils Web pour Visual Studio, accessibles via le menu “Tools/Extensions & Updates”

Et après ?

Nous venons de découvrir comment déployer une application dans un conteneur Linux ou Windows, sur Azure, ce qui vous a permis de comprendre comment fonctionne Docker et comment il s’interface avec Azure et les outils de développement..

Mais se pose rapidement la question de la scalabilité et de l’orchestration, nécessaires dans la vraie vie c’est à dire dans un contexte de mise en production. Pour cela, il existe Azure Container Service qui est un service de plus haut niveau, qui vous permettra notamment de piloter des clusters, à travers des technologies comme Swarm ou Mesos.

N’hésitez pas à suivre les explications et le tutoriel de Julien Create a Docker Swarm cluster using Azure Container Service.