Fail to run a new ASP.NET Core solution with Docker in Visual Studio 2017

Sometimes you want to make a demo to a good friend of you about Docker support in Visual Studio 2017. So your start Visual Studio 2017, create a blank ASP.NET Core (Docker support enabled), press F5 to run the application but things are not really happening like your want. In my case, I had the following message :

The specified framework 'Microsoft.NETCore.App', version '1.1.2' was not found.
  - Check application dependencies and target a framework version installed at:
      /usr/share/dotnet/shared/Microsoft.NETCore.App
  - The following versions are installed:
      1.1.1
  - Alternatively, install the framework version '1.1.2'.

The issue comes from the fact that Visual Studio 2017 builds a project based on .NET Core 1.1.2 but your Docker image only supports .NET Core 1.1.1 '(see message). Why your image doesn’t support 1.1.2 ? Maybe simply because your image is outdated with no support for 1.1.2. So the trick is quite easy and it consists to execute the pull again the image to force Docker to update the base image :

docker pull microsoft/aspnetcore:1.1

This should solve your issue after several minutes of downloading the updated image layer.

Docker ASP.NET MVC image creation issue ‘GetFileAttributesEx : The system cannot find the path specified’

When using Visual Studio 2017 and trying to create a Docker image for your ASP.NET web app from the standard microsoft\aspnet image (or another image), you may have the following error message : GetFileAttributesEx bin\Release\PublishOutput : The system cannot find the path specified

image

This error is caused by the .dockerignore file generated by Visual Studio 2017 (more information on .dockerignore file : https://docs.docker.com/engine/reference/builder/#dockerignore-file).

How to solve the issue

  1. Open and edit the .dockerignore file located at the root of your Visual Studio project
  2. Remove the first line with the ‘*’ (this is the guilty line !)
  3. Save the modified .dockerignore file
  4. Re execute your docker build command (ex : docker build –t <your tag> .)

Original Visual Studio 2017 .dockerignore file :

image

The corrected .dockerignore file :

image

Check your web app to know if everything works fine

  1. First, you won’t be able to use the URL http://localhost, you need the IP address of the container. To find it, execute this command in Powershell :
  2. docker inspect -f "{{ .NetworkSettings.Networks.nat.IPAddress }}" ncit_liasse

  3. Open your favorite browser and enter the URL http//<your ip address> to show you web app shining

image

More documentation on the use of this image at https://hub.docker.com/r/microsoft/aspnet/

Useful documentation on how to migrate an ASP.NET MVC application to Docker : https://docs.microsoft.com/en-us/aspnet/mvc/overview/deployment/docker-aspnetmvc

Now enjoy migrating your ASP.NET MVC web apps to Docker containers !

Lancement de Visual Studio 2017 aux Afterworks@Noumea du 15 Mars

Pour le lancement de Visual Studio 2017 et les 20 ans de l’outil de prédilection de tous les développeurs .NET, il aura bien fallut un évènement spécial des Afterworks@Noumea des communautés MS.

Après une présentation d’un peu plus d’une heure ponctuée de démos sur l’outil et sur les différentes fonctionnalités, .NET Core, l’architecture en microservice avec Docker et la mobilité, nous avons pu enfin goûter au gâteau d’anniversaire :

P1040523

Retrouvez les slides de la session ici : https://fr.slideshare.net/neodante/visual-studio-2017-launch-keynote-afterworksnoumea

Au niveau des ressources sur .NET, n’hésitez pas à me suivre sur LinkedIn (https://www.linkedin.com/in/jchable)

Encore un grand merci à la CCI de Nouméa pour le prêt des locaux et leur temps.

Bonne journée

Lancement de Visual Studio 2017 à Nouméa

MSFT_16257_VS17_1000x750_Sharethrough_thumb[4]Suite au lancement officiel du 07 Mars, nous organisons un évènement local ce mercredi 15/03 à la CCI de Nouméa. Au programme, une introduction aux nouvelles fonctionnalités de Visual Studio 2017 et à la plateforme .NET. Pendant cette présentation d’un peu plus d’une heure, ponctuées de pas mal de démonstrations, nous partagerons avec les participants sur les sujets suivants :

- Les nouveautés de Visual Studio 2017

- Quoi de neuf dans .NET et .NET Core ?

- Le développement mobile multiplateforme avec Xamarin

- Microservice, Docker et DevOps

Soyez préparer à manger un morceau du gâteau des 20 ans de Visual Studio !

Nous avons également quelques goodies à faire gagner pendant la session !

A demain soir !

MSFT_16257_VS17_STD_SpecialDelivery_FB_final3_DN-MININT-07V2IBM_thumb[3]

SharePoint 2016 project templates missing on Visual Studio 2015

imageWhen you open Visual Studio 2015 (with Update 3) on a SharePoint 2016 developer machine, it may occurs that the SP 2016 templates are missing (it displays only SP 2010 and 2013 templates). In that case, don’t panic ! Just follow the following process :

  1. If you don't have a version of Office Developer Tools for Visual Studio 2015, download “Microsoft Office Developer Tools Preview 2 for Visual Studio 2015” with the following link : https://www.microsoft.com/en-us/download/details.aspx?id=51683  (don’t go to aka.ms/officedevtoolsforvs2015 , the link is broken)
  2. Install the Microsoft Office Developer Tools Preview 2 for Visual Studio 2015 on your machine
  3. Open Control Panel > Programs > Programs and Features
  4. Uninstall SharePoint Client Components (with the version number 16.0.xxx)
  5. Download the SharePoint Server 2016 Client Components SDK from www.microsoft.com/en-us/download/details.aspx?id=51679
  6. Start developing your successful SharePoint Addins !

Déployer un site ASP.NET Core dans un conteneur Nano Server

Avec l’arrivée de Windows Server 2016, les entreprises se voit maintenant dotées d’un nouveau type de conteneur : les conteneurs Windows (exécutant Windows Server Core et Nano Server). A l’instar des conteneurs Linux, les conteneurs Windows possèdent leurs propres images disponible sur le Docker Hub. L’agnosticité de Docker (peu importe le fournisseur ou la technologie sous-jacente) et les capacités multiplateforme de .NET Core vont nous permettre de migrer une application ASP.NET Core existante s’exécutant dans conteneur Linux (cf dernier post) vers Nano Server sous Windows Server 2016.

Migrer vers un conteneur Windows

Lors du dernier post sur le sujet, nous avions vu comment déployer une application ASP.NET MVC Core dans un conteneur Linux. Voici le Dockerfile (que j’ai nommé Dockerfile.nanoserver permettant d’avoir un Dockerfile par type de conteneur) permettant de déployer la même application dans un conteneur Windows :

FROM microsoft/dotnet:nanoserver
 
COPY . /app
WORKDIR /app
RUN ["dotnet", "restore"]
RUN ["dotnet", "build"]
 
EXPOSE 5000/tcp
ENTRYPOINT ["dotnet", "run", "--server.urls", http://*:5000]

Constat : la seule différence à ce fichier Dockerfile est l’image de base (microsoft/dotnet:nanoserver) qui spécifie que nous souhaitons utiliser l’image .NET Core sous Nano Server. C’est aussi simple que ça ! (pour une application .NET Core en tout cas).

En quelques étapes :

  • Exécuter la même commande de Build pour construire votre image : docker build –t <votre tag> –f Dockerfile.nanoserver .

image

  • Démarrer un conteneur avec la commande : docker run –d –p 5000:5000 <votre tag>
  • Ouvrez un navigateur web et naviguez vers votre conteneur : http://<ip de votre conteneur/serveur Windows Server 2016>:5000

Exécuter l’application dans un conteneur Hyper-V

Le conteneur Windows Hyper-V apporte une couche d’isolation et de sécurité supplémentaire à l’application. Le choix entre un conteneur Windows “simple” et un conteneur virtualisé Hyper-V se fera en fonction de vos besoins, ce dernier fournissant une isolation du kernel et une séparation entre le niveau/version des patchs de l’hôte et de l’application.

La ligne de commande est similaire, nous précisons simplement le niveau d’isolement :

  • Démarrer un conteneur avec la commande incluant le paramètres isolation : docker run –d –p 5000:5000 –isolation=hyperv <votre tag>
  • Ouvrez un navigateur web et naviguez vers votre conteneur : http://<ip de votre conteneur/serveur Windows Server 2016>:5000

Container everywhere !

L’introduction des conteneurs Windows avec l’arrivée de Windows Server 2016 annonce une adoption du conteneur encore plus importe que celle actuellement avec les conteneurs Linux : containarization d’applications anciennes ou déploiement d’applications IIS avec le .NET Framework (avec Windows Server Core), déploiement Apps/IIS/AD DS/Hyper-V/etc (avec Nano Server), etc. L’adage Docker “Build, Ship and Run any app, Everywhere” n’a jamais eu autant de sens !

Déployer un projet web ASP.NET Core 1.0 avec Docker sur Windows en 15 minutes

Venant tout juste de passer sous Windows 10 update November 2015 (prérequis pour Docker beta) et souhaitant tester la RC2 fraichement débarquée de .NET Core, je me suis dit qu’un petit post ne serait pas de trop pour prendre les (nouvelles) bonnes habitudes. Aussi voici comment faire court pour créer une application .NET Core :

Installation des prérequis

Pour créer un projet ASP.NET Core :

  • .NET Core SDK (en RC 2 lors de la rédaction de ce post) : https://go.microsoft.com/fwlink/?LinkID=798398
  • NodeJS et son gestionnaire de package NPM : https://nodejs.org
  • Docker pour Windows (si vous êtes sur Windows) ou Docker pour Mac (si vous êtes sur Mac) : https://beta.docker.com/ (l’utilisation de la Beta nécessite l’obtention d’une clef qui arrive au compte goutte en ce moment …). Vous devez également avoir une version de Windows 10 adéquate (avec Hyper-V installé … pourquoi ne l’auriez-vous pas installé d’ailleurs ?!?) et la mise à jour de Novembre 2015.

Création du projet ASP.NET Core

  1. Dans une invite de commande ou dans une console PowerShell :
    1. mkdir coreapp : création d’un répertoire racine pour le projet
    2. cd .\coreapp\
  2. Installation du générateur Yeoman ASP.NET pour créer une application ASP.NET Core (et non juste une application console avec la commande dotnet new)
    1. npm install –g yo : installation de Yeoman
    2. npm install –g generator-aspnet : installation du générateur ASP.NET Core de Yeoman
  3. Création du projet :
    1. yo aspnet : affiche un wizard pour créer un nouveau projet :
      image
  4. Dans le wizard :
    1. Sélectionnez Web Application > Boostrap
    2. Saisissez le nom de l’application
  5. Le générateur va se mettre au travail et récupérer pour vous toutes les dépendances du projet et les placer dans un répertoire du même nom que celui de votre projet.
  6. Nous avons un peu de modification à faire pour rendre notre application compatible avec Docker (et rendre accessible notre application  à l’extérieur du container).
    Ouvrez le fichier Program.cs dans votre éditeur préféré (Visual Studio Code ?)
    Modifiez le contenu pour avoir un contenu similaire à ce qui suit puis enregistrez vos modifications :

    using Microsoft.Extensions.Configuration;
    
    ...
    namespace AppCoreDocker
    {
     public class Program
     {
     public static void Main(string[] args)
     {
     var config = new ConfigurationBuilder()
     .AddEnvironmentVariables("")
     .Build();
     var url = config["ASPNETCORE_URLS"] ?? "http://*:5000";
     var env = config["ASPNETCORE_ENVIRONMENT"] ?? "Development";
     
     var host = new WebHostBuilder()
     .UseKestrel()
     .UseUrls(url)
     .UseEnvironment(env)
     .UseContentRoot(Directory.GetCurrentDirectory())
     .UseIISIntegration()
     .UseStartup&amp;lt;Startup&amp;gt;()
     .Build();
    
     host.Run();
     }
     }
    }
    

    Cette modification permet de spécifier à Kestrel d’écouter sur le port 5000 quel que soit l’adresse que nous lui fournissons (merci à Laurent qui m’a évité de perdre du temps). Vous remarquerez la nouveauté liée à la RC 2 de cette configuration.

  7. Une fois le projet générer, les étapes sont les mêmes que pour tout projet :
    1. cd <nom de votre projet>
    2. dotnet restore : restaure les packages Nuget de l’application
    3. dotnet build : compile le projet (se produira si vous faites un run également)
    4. dotnet ef database update : crée la base de données SQLite pour gérer l’authentification (démo uniquement)
    5. dotnet run : lance le serveur Kestrel sur l’URL http://localhost:5000

image

Ouvrez un navigateur web avec l'URL : http://localhost:5000

image

Déploiement avec Docker

Afin de pouvoir lancer votre application dans un container Docker, nous devons créé notre Dickerfile. Le générateur Yeoman vous a déjà généré ce fichier, néanmoins, pour le moment le template de Yeoman n'est pas à jour (notamment l’image de base qui n’est pas la bonne et les actions maintenant avec la commande dotnet au lieu de dnx - cela a été mis à jour dans Github mais pas dans les distributions npm lors de la rédaction de ce post) que vous devrez modifier afin d’avoir un Dockerfile similaire à :

FROM microsoft/dotnet

ENV ASPNETCORE_ENVIRONMENT= "Production"

COPY . /app
 WORKDIR /app
 RUN ["dotnet", "restore"]

EXPOSE 5000
ENTRYPOINT ["dotnet", "run"]

Une fois le fichier modifié, vous pouvez exécuter les commandes suivantes :

  1. docker build –t <votre tag> .
  2. docker run –d –p 5000:5000 <votre tag>

La première commande build crée l'image Docker en installant les dépendances. La commande run exécute un container avec l'image créée précédemment sur le port 5000.

Ouvrez un navigateur web avec l'URL suivante : http://docker:5000 (et non localhost)

image

 

Conclusion

Force est de constater que l’uniformisation de la chaîne de commandes .NET Core et la possibilité de réaliser ses containers Docker dans un environnement Windows (ou Mac) apporte un réel gain de temps et une uniformité des outils quelle que soit l'environnement de développement.

Néanmoins, je ne pourrais que trop vous conseiller de tester vos containers dans un environnement Docker Linux stable et ne pas oublier que pour le moment Docker for Windows est en Beta.

Renommage des framework .NET Core

C’est en pleine rédaction d’un post sur ASP.NET 5 (avant de redémarrer ceux sur Docker et Nano Server) que Scott Hanselman choisit de nous annoncer que les noms des frameworks .NET Core que nous connaissions changent (cela devrait signifier que la sortie de la RTM devrait se faire très prochainement).

Voici la liste des mises à jour :

  • ASP.NET 5 => ASP.NET Core 1.0
  • .NET Core 5 => .NET Core 1.0
  • Entity Framework 7 => Entity Framework Core 1.0 / EF Core 1.0

ASP.NET Core 1.0

Cela est beaucoup plus cohérent que précédemment, aussi bien pour les clients que pour l’évolution des deux frameworks afin d’éviter toutes confusions entre les frameworks. En espérant que les librairies tierces joueront également le jeu de ce renommage, notamment celle qui ne supporte que ASP.NET Core et non ASP.NET 4.6 par exemple).

Tour d’horizon de Nano Server (partie 2) : déployer un projet web ASP.NET 5

Dans le précédent post, nous avons créer notre première image Nano Server. Dans ce post nous allons créer une image Nano Server comprenant un serveur web IIS pleinement fonctionnel et y déployer un site ASP.NET 5.

IMPORTANT : ce post a été réalisé avec la CTP 4 de Windows Server 2016. Il sera mis à jour ultérieurement.

IMPORTANT : Le site ASP.NET 5 s’exécute directement sur Nano Server (VM ou physique) mais pas dans un container. Dans un prochain post, nous verrons comment faire tourner un projet web ASP.NET 5 dans un container (déploiement qui sera certainement privilégiée par Microsoft). Attention, la différence de procédure peut-être importance, que vous soyez ou non dans un container.

Voici l’état de la documentation d’aujourd’hui sur http://aspnetmvc.readthedocs.org :

image

Alors prenez ce guide en attendant que la documentation soit complétée pour déployer et exécuter une application ASP.NET 5 sur Nano Server.

Création de l’image NanoServer avec IIS

Nous avons deux options pour installer IIS sur un Nano Server : hors ligne (Nano Server est éteint) ou en ligne (Nano Server est en cours d’exécution). Dans ce post nous allons utiliser l’installation hors ligne et créer une image directement avec IIS intégré (nous aurions également pu ajouter IIS à une image déjà existante).

1. Reprenez les étapes de création de la partie 1 de cette série, à l’étape 5 exécutez à la place la ligne de commande suivante : New-NanoServerImage -MediaPath D:\ -BasePath .\Base -TargetPath ‘.\NanoImage\NanoVM.vhdx’ -GuestDrivers –EnableRemoteManagementPort –Language en-us –ComputerName NanoServerNode1 –Packages Microsoft-NanoServer-IIS-Package –ReverseForwarders

A propos du package ReverseForwarders : Pour pouvoir exécuter HttpPlatformHandler et Kestrel (c’est à dire libuv.dll) sur Windows Server, vous allez devoir ajouter un package ReverseForwarders. Les appels à kernel32.dll et advapi32.dll (DLLs qui n’existent pas dans Nano Server) seront ainsi redirigés vers les nouvelles de ces APIs qui ont été déplacés dans d’autres composants. Ce package n’est pas installé par défaut dans Nano Server (alors que c’est le cas sur Win10 IoT) puisque l’objectif est de n’avoir que le strict minimum d’embarqué, il vous faut donc le rajouter.

Création de la machine virtuelle Hyper-V Nano Server

Créer une nouvelle machine virtuelle Hyper-V et connectez une machine virtuelle avec ce nouveau VHD. Vous devriez voir la recovery console.

image

Exemple de script PowerShell de création de VM :

New-VM -VHDPath ‘.\NanoImage\NanoVM.vhdx’ -MemoryStartupBytes 512MB -Name NanoServerNode1 -Generation 2

Set-VMMemory -VMName NanoServerNode1 -DynamicMemoryEnabled $True -MaximumBytes 512MB -MinimumBytes 256MB

Set-VMProcessor -Count 2 -VMName NanoServerNode1

Note : N’oubliez pas mettre le bon switch virtuel pour avoir du réseau et vous connecter à la VM (cf étape suivante pour le vérifier).

Vérifier le fonctionnement de IIS

1. La première chose à faire est de récupérer l’adrese IP de la machine, pour cela, deux options :
- Récupérer l’IP depuis la console de restauration (recovery console) en vous connectant sur la machine et en vous authentifiant
- Récupérer l’IP depuis Hyper-V avec la ligne de commande suivante :  Get-VM –name <Nom de votre VM>| Select -ExpandProperty networkadapters | Select IPAddresses

image

2. Connectez vous avec un navigateur web sur cet IP, vous devriez observer une page de bienvenue IIS :

image

Vous voilà avec un serveur IIS fonctionnel.

Se connecter à Nano Server

Bien qu’il existe plusieurs façons de pouvoir se connecter à distance avec Nano Server, nous allons utiliser le module de gestion IIS PowerShell pour gérer notre serveur IIS. Tout d’abord

1. Pour pouvoir vous connecter au Nano Server avec une session PS, vous devez d’abord l’ajouter dans la liste des hôtes de confiance.  Exécuter la commande PowerShell (toujours dans une console en tant qu’administrateur) : Set-Item WSMan:\localhost\Client\TrustedHosts "<IP de votre serveur>"

image

2. Exécutez la ligne de commande suivante dans PowerShell :
$session = New-PSSession –ComputerName <IP de votre serveur> –Credential Administrator
Enter-PSSession $session

Un prompt vous demandera le mot de passe de l’administrateur.

image

3. (facultatif )Dans la session distante, importez le module de gestion IIS puis récupérer les sites IIS avec les commandes :
Import-Module IISAdministration
Get-IISSite

image

Vous êtes connectez à Nano Server, nous allons pouvoir créer le projet ASP.NET 5 et le déployer.

Création du projet ASP.NET 5

Nano Server ne contient pas de Framework .NET justement parce que celui-ci possède trop de dépendance avec Windows et qu’il fallait couper sévèrement dans les composants. Néanmoins, pour faire fonctionner Powershell, Nano Server utilise une partie de .NET Core (la version open source et portable du framework .NET) mais qui ne suffira pour exécuter votre application.

Note : vous pouvez aussi récupérer le projet ASPNET5WebHello.

Installer la dernière version de .NET Core

Avant de créer votre projet ASP.NET 5 sur votre machine de développement, assurez vous que vous avez bien la dernière version de .NET Core (surtout en ces temps de Beta et RC) avec la commande : dnvm list

image

Si vous n’avez pas la dernière version (ou disons la version que vous souhaitez déployer) de la Core CLR (et en version x64, Nano Server ne s’exécutant qu’en 64 bits), exécuter le commande :

dnvm install latest –r coreclr –arch x64 –alias coreclr-latest

image

image

Projet ASP.NET 5 avec Visual Studio 2015

Dans Visual Studio 2015 (toutes éditions confondues) :

1. Créez un nouveau projet Visual C# > Web > ASP.NET Web Application :

image

2. Choisissez ASP.NET 5 Preview Templates :

image

3. Dans les propriétés du projet, vérifiez que la cible du DNX est bien celle que vous souhaitez :

image

Dans l’onglet de Debug (pour les tests sur l’environnement de développement) :

image

4. Lancez l’application (F5), pour voir un magnifique texte “hello world” apparaître dans votre navigateur.

image

5. Avant de publier votre application, il reste un détail important (sans quoi Nano Server ne servira pas vos pages web) : remplacez l’URL du projet. Dans le fichier project.json, changer la ligne :

"commands": {
"web": "Microsoft.AspNet.Server.Kestrel server.urls=
http://localhost:5000"
  },

par

"commands": {
"web": "Microsoft.AspNet.Server.Kestrel server.urls=
http://<ip de votre serveur Nano Server>:5000"
  },

Enregistrez les modifications du fichier.

6. Nous allons maintenant pouvoir publier l’application web sur notre disque dur avant de copier les fichiers vers Nano Server. Ouvrez une console PowerShell dans le répertoire de votre projet :

image

Dans la console excutez les commandes suivantes pour restaurer les packages (normalement Visual Studio a dû le faire pour vous mais nous ne sommes jamais trop prudent) et publier l’application avec le runtime dnx-coreclr-win-x64.1.0.0-rc1-update1  :

dnu restore
dnu publish –out <chemin vers répertoire de sortie>--runtime C:\Users\<nom de l’utilisateur>\.dnx\runtimes\dnx-coreclr-win-x64.1.0.0-rc1-update1

Remarque : Publiez votre projet si possible à la racine d’un disque, la technique de copie à suivre ne permettra pas les chemins d’accès de plus de 260 caractères.

6. Vous devriez avoir dans votre répertoire cible, un contenu similaire à celui-ci :

image

Publication du projet vers Nano Server

A ce stade, la seule option que j’ai trouvé pour publier le site est de faire un copier/coller du répertoire publié vers IIS sur le Nano Server. La possibilité d’utiliser un WebDeploy n’est aujourd’hui pas supporté sur le IIS de Nano Server.

Remarque : pour procéder à la copie vers une session distante, si vous êtes sur Windows 8.1 ou 7, vous devrez installer Windows Management Framework 5.0.

Nous allons donc procéder à une copie entre le système de fichier de la machine de développement et le serveur Nano Server :

- Ouvrez une session avec :  $session = New-PSSession –ComputerName <ip de voter serveur> –Credentials Administrator

image

- Exécutez la commande de copie : Copy-item –ToSession $session –Path <chemin vers votre projet publié> –Destination C:\Users\Administrator\Documents –Recurse

image

La copie des fichiers devraient prendre un peu de temps. Les fichiers de votre projet sont maintenant publiés sur Nano Server.

Configurer le pare-feu de Nano Server

Nous avons configurer le site sur le port 5000 qui n’est pas encore ouvert (les ports HTTP et HTTPS sont déjà ouverts). Pour ouvrir le port 5000, vous avez deux options : la ligne de commande ou la console de restauration (recovery console) :

netsh advfirewall firewall add rule name="HTTP (5000)" dir=in action=allow protocol=TCP localport=5000

image

Démarrer le site web

Le démarrage va être effectuer via le fichier web.cmd qui a été créé lors de la publication du projet. Ce fichier contient les commandes nécessaires pour démarrer votre projet en analysant le fichier project.json.

Naviguez dans le répertoire approot de votre projet et exécuter le fichier web.cmd pour démarrer le serveur :

image

image

Ouvrez un navigateur avec l’adresse http://<ip de votre serveur>:5000 , et voilà :

image

Important : une fois que vous aurez lancé la commande web.cmd, vous devriez observer un écran noir dans votre machine virtuelle. Une fois le serveur arrêté (Ctrl+C), la recovery console réaffichera l’écran en cours. Nous verrons dans un prochain post comment faire éviter cela.

 

Nano Server est définitivement le futur du serveur IIS pour les applications ASP.NET 5. Bien que cette édition soit pour le moment assez limitée en termes d’interface et d’outil de gestion, Microsoft devrait améliorer cet aspect là dans les prochaines versions de son OS.

A ce stade, le manque de documentation se fait sentir ! La communauté et Microsoft devrait combler cette lacune rapidement au vu de l’engouement pour Nano Server. Tous les contributeurs de docs.asp.net sont les bienvenus sur le projet Github.

La solution présentée dans ce post n’est pas définitive, mais permet de montrer comment exécuter une application web ASP.NET 5 dans Nano Server.

Dans un prochain post nous verrons l’hébergement d’un application web ASP.NET 5 dans un container Nano Server et également comment bénéficier de IIS pour l’exécution en production.

Ressources

En attendant, voici quelques ressources qui m’ont bien aidé (malgré que tout ne fonctionne pas) à faire fonctionner un site ASP.NET 5 sur le IIS de Nano Server :

- Pour plus de détails sur les commandes et fichier de configuration IIS : https://msdn.microsoft.com/en-us/library/mt627783.aspx

- Channel 9 “Nano Server in a container running IIS & ASP.NET 5” : https://channel9.msdn.com/Series/Nano-Server-Team/Demo-Nano-Server-in-a-Container-running-IIS-ASPNET5

Déployer ASP.NET 5 dans un container Docker

image

Docker et bientôt Windows Server Container vont vous permettre de délivrer et d’exécuter des applications plus rapidement et avec moins de ressources. La “containerization” des applications embrace l’approche DevOps en permettant d’exécuter des centaines d’applications en parallèle alors que même un cluster de VMs en seraient incapable et de surcroit difficile à gérer. Le container permet aussi de rendre l’architecture microservices plus fiable et plus accessible aux équipes réduites.

imageCette série de post vous proposer une première approche au déploiement d’une application ASP.NET 5 dans un container Docker. Ainsi vous serez capable de déployer votre application sur vos serveurs de production ou dans le Cloud (AWS, Azure, etc) rapidement et de façon fiable.

Introduction sur les containers

L’avantage des containers, en dehors d’une densification plus importante des serveurs en applications, est aussi l’utilisation des images. Une image contient aussi bien l’OS que les dépendances de l’application (CoreCLR, ASP.NET MVC, etc) et est de de petite taille. Cela permet de créer des containers rapidement et de les démarrer tout aussi rapidement. Aujourd’hui le hub Docker contient plus de 100 000 images.

Bien que Docker se limite aujourd’hui à délivrer des containers Linux (OS du container et OS hôte), l’arrivée de Windows Container et de Nano Server devraient faire évoluer le paysage de cette technologies dans les prochains mois.

Pour ce post, .NET Core étant multi plateforme, nous allons créer une application ASP.NET 5 MVC puis l’exécuter un container Docker sous Linux.

Prérequis

Vous devez disposer :

  • D’une machine hébergeant Docker. Pour ce blog, j’ai utilisé une machine hébergée sur  Azure mais une VM Hyper-V avec Ubuntu ou autre fait tout aussi bien l’affaire.
  • Eventuellement d’un projet ASP.NET 5 à déployer. Pour ce post, j’ai créé une application excessivement simple affichant une page de bienvenue et disponible sur Github.

Création du fichier Dockerfile

Le fichier Dockerfile permet de créer des containers en industrialisant sa composition par un script de création. Ces fichiers peuvent être versionnés et mis à jour en fonction de l’évolution de vos plateformes et applications.

FROM microsoft/aspnet:1.0.0-rc1-final-coreclr

COPY . /app
WORKDIR /app
RUN ["dnu", "restore"]

EXPOSE 5004
ENTRYPOINT ["dnx", "-p", "project.json", "kestrel"]

L’instruction FROM permet de spécifier l’image Docker de base utilisée. Dans notre cas, une image préconfigurée avec la version CoreCLR 1.0.0 RC1.

L’instruction COPY va exécuter une copie des fichiers situés à la racine dans le répertoire app avant de devenir le répertoire courant (instruction WORKDIR) dans lequel nous allons restaurer les packages de l’application à partir du fichier project.json.

L’instruction EXPOSE spécifie que le container aura un port 5004 exposé (ce port est configuré dans le fichier project.json comme étant celui du serveur web). Le point d’entrée ENTRYPOINT spécifie la commande à exécuter lors du lancement du container. Dans notre cas, nous exécutons un serveur kestrel.

Créer le container

A partir  de ce fichier Docker, vous allez maintenant pouvoir construire votre container, voir automatiser ce processus afin d’effectuer des tests automatisés de votre application (nous aurons l’occasion d’en parler plus tard).

Dans votre machine Docker (ici dans une console d’une VM Azure connectée en SSH) :

1. Exécuter la commande Git afin de récupérer un projet simple et le fichier Dockerfile prêt à l’emploi sur votre serveur :
git clone https://github.com/NCITNoumea/docker-ressources.git

2. Une fois les fichiers récupérés depuis github sur votre serveur
cd docker-ressources/images/mvc-hello/
sudo docker build -t mvc-hello .

La construction du container devrait prendre quelques minutes, nécessaires au téléchargement de l’image de base et des dépendances .NET. Au bout de quelques minutes, vous devriez avoir un message indiquant le succès de l’opération :

image
Remarque : dans cette capture, vous pourrez observer que l’image et les dépendances sont déjà contenues dans le cache (“Using cache”). Lors de la première exécution, vous verrez défiler les téléchargements.

3. Votre container nommé mvc-hello est maintenant prêt à être déployer et exécuter dans le Docker Engine.

Exécuter le container

Toujours dans votre machine Docker (ici dans une console d’une VM Azure connectée en SSH) :

1. Exécuter le commande de démarrage du container :
sudo docker run –t –d –p 80:5004 mvc-hello

L’exécution de cette commande devrait vous renvoyer un identifiant excessivement long :

image

Cette commande propose différent paramètres, le plus important dans notre cas est le mapping des ports entre le container et l’hôte Docker. Nous spécifions que le port 80 de l’hôte sera redirigé vers le port 5004 (que nous avons exposé précédemment) du container.

Vérifier le déploiement

Vous pouvez vous connecter sur l’IP de votre VM (port 80) avec un navigateur web pour constater l’exécution du serveur web et de votre application ASP.NET 5 :

image

En cas d’erreur …

L’exécution d’un container n’est pas sans mauvaise configuration de notre part, aussi vous pouvez demander à Docker d’afficher les logs d’exécution d’un container afin de diagnostiquer la source de l’erreur :

1. Exécuter le commande de démarrage du container :
sudo docker logs <identifiant de votre container>

Vous pouvez récupérer l’identifiant de votre container de plusieurs façons, la plus simple est de copier/coller celui-ci lorsqu’il s’est affiché à l’exécution de la commande run. Il s’agit bien de l’ “identifiant excessivement long” évoqué précédemment.

image

Arrêter le container

Dans votre machine Docker (ici dans une console d’une VM Azure connectée en SSH) :

1. Exécuter le commande de démarrage du container :
sudo docker ps

Cette commande liste les containers en cours d’exécution. Vous devriez trouver le vôtre :

image

2. Exécuter le commande de démarrage du container :
sudo docker stop <nom de votre container>

L’arrêt devrait prendre quelques secondes le temps que le serveur web s’arrête. Si vous réexécuter la commande sudo docker ps, le container devrait avoir disparu.

Conclusion

Bien qu’attendu au premier semestre 2016, ASP.NET 5 est d’ores et déjà fonctionnel que ce soit au travers d’un serveur IIS ou d’un serveur web Linux (kestrel).

L’utilisation d’application “containeriser” devrait apporter une nouvelle bouffée d’air aux process DevOps des projets .NET. L’arrivée de Windows Server Container (dont nous parlerons dans un prochain post) devrait encore ajouter de l’agilité à ces projets, comme c’est déjà le cas avec l’intégration des extensions Docker dans Visual Studio et Azure.

Alors que le déploiement de services .NET (site web, services SOAP/REST/OData, etc) avait un TCO plus élevé que des homologues tels que PHP, Java, Ruby, etc (hébergés le plus souvent sur Linux/Apache), le déploiement d’une application .NET dans un container Linux devrait radicalement changer la donne et permettre à toutes les entreprises et développeurs de pouvoir utiliser la puissante et la flexibilité de .NET et de ses framework (ASP.NET MVC, Entity Framework, etc) à coûts d’hébergement identiques.

Cela devrait permettre à .NET de devenir enfin une plateforme de service compétitive : économique tout en continuant de garantir la productivité acquises avec les frameworks .NET et ses outils (notamment Visual Studio) pour apporter plus et plus rapidement de la valeur utilisateur à ses utilisateurs / clients.

Note : ce post se base sur des versions préliminaires des images ASP.NET , par conséquent les instructions pourront changer en cours de temps. Néanmoins, n’hésitez pas à consulter le repository Docker des images officielles : https://hub.docker.com/r/microsoft/aspnet/