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/

Création d’une VM Docker dans Azure

Azure propose aujourdh’ui une VM préconfigurée pour exécuter Docker sur un Ubuntu 15.04 Server afin de vous épargner la création d’une machine et l’installation des différents composants.

Voici les étapes à suivre pour avoir une machine disponible en quelques minutes :

1. Connectez vous sur votre compte Azure : http://portal.azure.com

2. Dans le portail, cliquez sur Nouveau

image

3. Rechercher l’image “Docker on Ubuntu Server” dans le marketplace

image

image

4. Cliquez sur Créer en bas de page, puis saisissez le nom d’hôte, le nom d’utilisation et mot de passe. Gardez le type d’authentification en Mot de passe plutôt que clé publique SSH pour des raisons de simplicité. Si vous êtes familiarisé avec SSH et les clés publiques, changez de mode. Sélectionnez votre niveau de tarification selon vos besoins, le groupe de ressources et l’emplacement du data center.

image

5. Cliquez sur Créer puis attendez la création de la VM qui devrait prendre quelques minutes.

6. Une fois la VM créée, connectez-vous à l’interface d’administration de celle-ci dans le portail Azure

image

7. Naviguez dans Gérer > Adresses IP pour récupérer l’adresse IP avec laquelle vous vous connecterez en SSH

image

8. Créez un point de terminaison pour autoriser la connexion sur le port HTTP (80) si vous déployer un container avec un serveur web en naviguant dans Gérer > Points de terminaison :

image

9. Pour tester la connexion SSH avec le serveur, utilisez un client SSH (par exemple Putty) et essayer de vous connecter pour valider la bon fonctionnement de votre nouvel VM Docker :

image

10. Exécuter la commande sudo docker pour vérifier le bon fonctionnement de Docker :

image

Votre VM Docker est maintenant fonctionnelle. Vous allez pouvoir héberger des containers (voir prochains posts).

“SYSTEM.IO.FILENOTFOUNDEXCEPTION: COULD NOT LOAD FILE OR ASSEMBLY ‘MICROSOFT.SHAREPOINT.CLIENT. WORKFLOWSERVICES”

Vous lancez votre application ou solution SharePoint utilisant CSOM et Workflow Manager 1.0(WorkflowServicesManager, Workflow Definition), vous avez le message suivant qui s’affiche : “System.IO.FileNotFoundException: Could not load file or assembly ‘Microsoft.SharePoint.Client.WorkflowServices, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c’ or one of its dependencies. The system cannot find the file specified.”

Solution 1 (application seulement) :

Vous copiez les DLLs suivantes à la racine de votre applications (si c’est une solution SharePoint, cette solution n’est pas applicable) :

  • – Microsoft.SharePoint.Client.dll
  • – Microsoft.SharePoint.Client.Runtime.dll
  • – Microsoft.SharePoint.Client.WorkflowServices.dll

Solution 2 :

Si gacutil.exe n’est pas sur votre serveur de production/qualification, copiez depuis le répertoire de votre machine de développement “C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools” (ou d’un répertoire v8.0, v8.1A) les fichiers suivants :

– gacutil.exe
– gacutil.exe.config
– 1033\gacutlrc.dll

Ouvrez une console en tant qu’administrateur. Depuis l’emplacement où vous avez copier gacutil.exe (ou depuis n’importe quel emplacement si vous avez mis gacutil dans le PATH), saisissez :

gacutil -i “C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\ISAPI\Microsoft.SharePoint.Client.dll”

gacutil -i “C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\ISAPI\Microsoft.SharePoint.Client.Runtime.dll”

gacutil -i “C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\ISAPI\Microsoft.SharePoint.Client.WorkflowServices.dll”

Pour chaque commande, vous devriez avoir le message suivant : Assembly successfully added to the cache

Toutes les DLLs requises pour votre solution utilisant CSOM / Workflow Manager sont maintenant disponibles dans le GAC et votre solution devrait fonctionner.

Visual Studio 2015 est enfin là !

La version RTM de Visual Studio 2015 vient tout juste de sortir et nous avons le droit à de nombreuses améliorations et fonctionnalités comparé à VS 2013.

Alors pourquoi, un ‘enfin’ dans le titre ? Tout simplement car VS 2015 et .NET 4.6 apporte chacun de vraies nouveautés dans la façon de développer vos projets : nouveau modèle de projet, prise en charge de .NET 4.6 et ASP.NET 5 (et donc de .NET Core, la version open source et optimisée cloud de .NET), télémétrie (pour tout savoir de l’exécution de votre application), développement multi plateforme mobile, compilateur Roslyn, outils de diagnostic (un must), etc …

La version Community est disponible à cette adresse : https://www.visualstudio.com/downloads/download-visual-studio-vs

Les versions entreprise sont quantà elles disponibles sur votre compte MSDN dès aujourd’hui !

Les éditions

Quelle édition choisir :

  • Edition Community : gratuit pour les étudiants, les projets open source et les équipes de petite taille. Les fonctionnalités vous permettront de développer des applications web, Azure, Windows et multi plateforme mobile (iOS, Android et Windows Phone).
  • Edition Professionelle : l’environnement le plus répandu parmi les développeurs expérimentés. Possède tous les outils nécessaires à développer une application complexe à l’aide d’outil de productivité de code (CodeLens, collaboration Agile, connectivité avec Team Foundation Server, VS Online, etc).
  • Edition Test Professionnelle : uniquement dédié aux testeurs avec uniquement les outils pour ce dernier.
  • Edition Entreprise : dédié aux sociétés souhaitant réaliser et automatiser les tests (charge, unitaires, etc) et utiliser IntelliTest et IntelliTrace pour le débogage. Mais encore avoir 150$ de crédits Azure par mois.

Les fonctionnalités en (très) bref

  • Outils de développement pour réaliser des applications web, mobile (iOS, Android et WP via Cordova et Xamarin), Windows, Windows 10 universelle (PCs, tablets, XBox, HoloLens, IoT), et cloud
  • Langages supportés : C#, JavaScript, NodeJS, TypeScript, Visual Basic, F#, C++, IronPython, …

Coup de coeur : ASP.Net 5 et .NET Core

Supporté sur Windows, Linux et MacOS, les applications ASP.NET 5 et .NET Core vont pouvoir se déployer sur des serveurs cloud à moindre coût ! La plateforme .Net rentre dans une nouvelle phase d’adoption des développeurs, où mêmant outils et productivité, ceux-ci auront la vie beaucoup plus facile et pourront porter l’innovation rapidement et de façon fiable vers leurs utilisateurs.

Vous pouvez retrouver tous les projets .NET sur le github de la .NET Foundation à cette adresse : https://github.com/dotnet

Utilisation du service WorkflowQueuingService

L’exécution d’un workflow est souvent dépendante des entrées que les hommes (via une console ou une application Windows Form) ou les programmes (ASP.NET, Web Service, Mainframe, etc) feront dans votre workflow, même après plusieurs jours d’attente. Une activité qui attend des entrées d’une entité extérieure se doit de faire deux choses :

  • Notifier qu’elle attend des données (se mettre ‘au repos’)
  • Etre notifié quand les données seront mise à disposition.

Et cela, même si l’instance de son workflow est persistée (dans un fichier texte ou une base de données par exemple). Lorsque les données arrivent, le moteur d’exécution (le runtime) doit pouvoir recharger en mémoire l’instance et être capable de continuer l’exécution du workflow au bon endroit.

Comment faire en sorte de pouvoir spécifier au workflow qu’il est en attente d’une donnée et de traiter la donnée une fois celle-ci mise à la disposition de l’instance du workflow ? Comment assurer une communication ‘propre’ à l’intérieur des couches logicielles et de votre architecture ? Il y a plusieurs méthodes, plus ou moins robuste pour le faire,  une bonne méthode est néanmoins d’utiliser ce qui fait le fondement de WF : les files de Workflow !

De cette façon, à chaque fois que vous avez besoin de pousser une entrée vers le workflow, telle qu’une chaine de cractères ou tout autre objet (dans notre exemple, une transaction financière), vous ajoutez un élément à l’une ou les piles de l’instance du workflow. La pile se chargera à son tour d’appeler les méthodes abonnées aux évènements pour traiter ces entrées comme stimuli de l’activité. Ce principe nous permet d’utiliser le service WorkflowQueuingService qui s’exécute dans le moteur d’exécution de WF et qui va vous permettre d’ajouter et de nommer des files dans une instance de workflow.

L’autre avantage de cette méthode est le fait de pouvoir ainsi marquer des points d’exécution et des points de persistence dans votre workflow sans que vous ne soyez obligé d’être dans la portée d’une transaction.

Imaginons que nous voulons traiter un workflow simple qui attend le traitement d’une transaction financière par un serveur backend.

Voici la structure d’une transaction attendue comme entrée par le workflow :

public struct Transaction {

public double Amount;

public DateTime Date;

public Guid ID;

public Transaction(Guid id, double amount, DateTime date) {

this.ID = id; this.Amount = amount; this.Date = date;

}

public override string ToString() {

return string.Format(« ID: {0} – Amount: {1} – Date: {2} », ID, Amount, Date);

}

}

Commençons par implémenter une activité possédant une propriété contenant notre transaction  :

public partial class WaitProcessedTransaction : System.Workflow.ComponentModel.Activity

{

private Transaction mTransaction;

public Transaction Transaction

{

get { return mTransaction; }

set { mTransaction = value; }

}

}

Voici les méthodes de création (méthode d’initialisation de l’activité) et de destruction (méthode de ‘désinitialisation’, comprendre que cette méthode est appelée de façon synchrone lorsque de la transition de l’état de l’activité de Executing vers Closed) de la file de Workflow :

protected override void Initialize(IServiceProvider provider) {

WorkflowQueuingService qService =

(WorkflowQueuingService)provider.GetService(typeof(WorkflowQueuingService));

if (!qService.Exists(this.Name))

qService.CreateWorkflowQueue(this.Name, true);

}

protected override void Uninitialize(IServiceProvider provider) {

WorkflowQueuingService qService = (WorkflowQueuingService)provider.GetService(typeof(WorkflowQueuingService));

if (qService.Exists(this.Name))

qService.DeleteWorkflowQueue(this.Name);

}

}

On peut constater que les files sont nommées, ici par le nom de l’activité.

Nous allons redéfinir la méthode d’exécution de l’activité par la méthode suivante :

protected override ActivityExecutionStatus Execute(ActivityExecutionContext executionContext) {

WorkflowQueuingService qService = executionContext.GetService<WorkflowQueuingService>();

WorkflowQueue queue = qService.GetWorkflowQueue(this.Name);

if (queue.Count > 0){

this.mTransaction = (Transaction)queue.Dequeue();

return ActivityExecutionStatus.Closed;

}

queue.QueueItemAvailable += this.ContinueAt;

return ActivityExecutionStatus.Executing;

}

void ContinueAt(object sender, QueueEventArgs e){

ActivityExecutionContext context = (ActivityExecutionContext)sender;

WorkflowQueuingService qService = context.GetService<WorkflowQueuingService>();

WorkflowQueue queue = qService.GetWorkflowQueue(this.Name);

this.mTransaction = (Transaction)queue.Dequeue();

context.CloseActivity();

}

Dans la méthode d’exécution, nous récupérons le service de file puis nous extrayons l’entrée qui pourrait potentiellement se trouver dans la file. Si la donnée est récupérée de la file, nous spécifions la clôture de l’activité, sinon nous abonnons une méthode à l’évènement qui sera appelée dés qu’une entrée dans la file sera disponible, puis nous laissons le statut de l’activité comme ‘en cours d’exécution’.

Maintenant c’est au tour de l’application de jouer son rôle en fournissant l’entrée dans la file nommée de l’instance du workflow :

// Création d’une instance de workflow et démarrage

WorkflowInstance instance = workflowRuntime.CreateWorkflow(typeof(WorkflowDemo.WorkflowQueueTest));

instance.Start();

// On crée une transaction financière et la met dans la file nommée ‘WaitTransactionProcessed’ (qui est le nom de l’activité ciblée) ce qui aura pour effet de réveiller le workflow et d’exécuter la méthode abonnée à l’évènement ‘QueueItemAvailable’ de la file (méthode ‘ContinueAt’)

Transaction t = new Transaction(Guid.NewGuid(), 1000.0, DateTime.Now);

instance.EnqueueItem(« AttendreTraitementTransaction », t, null, null);

En utilisant un objet d’une instance de workflow, et cela n’importe où dans l’application hôte, vous allez pouvoir marquer des points d’exécution dans votre workflow grâce aux files et communiquer une ou plusieurs entrées à votre activité pour pouvoir continuer son exécution. Cela est vrai même si celui-ci a été persisté pendant son état de repos.

Dans notre cas, nous parlons d’un workflow qui peut attendre un stimulus d’une entité extérieure sur des périodes plutôt longues, il faut donc s’attendre à se que le workflow soit décharger de la mémoire pour être persisté à un endroit physique. Dans notre cas nous allons le faire persister dans une base SQL Server 2005 (classique en quelque sorte) en utilisant le service SqlWorkflowPersistenceService (voici un lien pour mettre en place tout ce qu’il faut : http://msdn2.microsoft.com/en-us/library/aa349366.aspx).

clip_image002

Note : voici également un excellent schéma des états d’un workflow : http://msdn2.microsoft.com/en-us/library/aa663362.hostingwwf03l%28en-us,msdn.10%29.jpg

Voici les quelques lignes qu’il faut rajouter pour configurer le runtime :

string stringConnection = @ »Initial Catalog=WF_Persistence;Data Source=localhost\SQLEXPRESS;User Id=x;Password=x »;

// Création d’une instance du service de persistence Sql Server avec un argument à true pour spécifier de persister une instance de workflow dés que son état passe au repos

SqlWorkflowPersistenceService persistenceService = new SqlWorkflowPersistenceService(

stringConnection, true, TimeSpan.MaxValue, new TimeSpan(0, 1, 0));

workflowRuntime.AddService(persistenceService);

Pour mieux comprendre ce qui se passe on rajoute des handle à différents évènements qui afficheront les changements d’état :

workflowRuntime.WorkflowIdled += new EventHandler<WorkflowEventArgs>(workflowRuntime_WorkflowIdled);

workflowRuntime.WorkflowPersisted += new EventHandler<WorkflowEventArgs>(workflowRuntime_WorkflowPersisted);

workflowRuntime.WorkflowLoaded += new EventHandler<WorkflowEventArgs>(workflowRuntime_WorkflowLoaded);

workflowRuntime.WorkflowCompleted += new EventHandler<WorkflowCompletedEventArgs>(workflowRuntime_WorkflowCompleted);

void workflowRuntime_WorkflowCompleted(object sender, WorkflowCompletedEventArgs e) { Console.WriteLine(« Workflow completed ! »); }

void workflowRuntime_WorkflowLoaded(object sender, WorkflowEventArgs e){ Console.WriteLine(« Workflow loaded ! »); }

void workflowRuntime_WorkflowPersisted(object sender, WorkflowEventArgs e) { Console.WriteLine(« Workflow persisted ! »); }

void workflowRuntime_WorkflowIdled(object sender, WorkflowEventArgs e) { Console.WriteLine(« Workflow idle ! »); }

Imaginons que nous avons un workflow séquentiel contenant notre activité qui attend le traitement d’une transaction lancée en amont d’un workflow, et d’une activité qui affiche un message de confirmation du traitement :

clip_image004

Nous pourrons observer le résultat suivant :

clip_image006

Voici un cas simple d’utilisation du service WorkflowQueuingService. Ce service est à la base de nombreuses activités et reste un moyen élégant et efficace de placer des points d’attente nommés – par le nom de la file – où vos activités peuvent recevoir des données, c’est à dire des endroits logiques dans votre workflow dont l’exécution peut être reprise quand un stimuli spécifique (une données, un évènement, …) arrive, tout en étant capable d’être persisté pendant le temps d’attente.

Le lien MSDN vers le WorkflowQueuingService qui devrait être à la base de beaucoup de vos activités communicant avec l’extérieur (permet de remplacer très élégamment l’activité HandleExternalEvent : http://msdn2.microsoft.com/en-us/library/system.workflow.runtime.workflowqueuingservice.aspx