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.
Cette 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 :
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 :
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 :
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.
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 :
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/