Archives de catégorie : Container

Lancement de Visual Studio 2017 à Nouméa

Publié le par
Répondre

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]

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

Publié le par
Répondre

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 :

[code language= »csharp » highlight= »1″]
FROM microsoft/dotnet:nanoserver
 
COPY . /app
WORKDIR /app
RUN ["dotnet", "restore"]
RUN ["dotnet", "build"]
 
EXPOSE 5000/tcp
ENTRYPOINT ["dotnet", "run", "–server.urls", http://*:5000]
[/code]

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

Publié le par
Répondre

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 :

    [code language= »csharp » highlight= »1,10,11,12,13,14,18,19″]
    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();
    }
    }
    }
    [/code]

    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 à :

[code]
FROM microsoft/dotnet

ENV ASPNETCORE_ENVIRONMENT= "Production"

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

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

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.

Tour d’horizon de Nano Server (partie 1) : création d’une image

Publié le par
Répondre

Dans ce post nous allons démarrer par créer un VHD minimal de Nano Server. Dans un prochain post, nous verrons la personnalisation des images et la mise en container de Nano Server avec le déploiement d’une application ASP.NET 5.

Nano Server ?

Nano Server est une version de Windows Server ultra minimaliste, plus sécurisée et optimisée pour le déploiement Cloud / Datacenter (c’est surtout cette partie qui va nous intéresser). Nano Server est encore plus réduit que la version Core de Windows Server : taille disque minime, ressource mémoire moindre mais aucune interface, pas de connexion directe à l’OS, support des applications 64 bits uniquement (donc exit vos applications 32 bits … enfin si vous en avez encore), aucun rôle préinstallé (rôle sur mesure à ajouter via des packages), etc. Tout cela amène à des (re)démarrages plus rapides, moins de mises à jour et un espace/transfert des VHD beaucoup plus léger et donc souple à maintenir.

Nano Server sera donc un système hôte de choix pour héberger un serveur IIS, un stockage de fichiers, héberger NodeJS et autre plateforme applicative, créer un cluster de reprise, un DNS, etc. Tout cela se configure via les packages qui seront disponibles avec Nano Server (et Microsoft à annoncer l’arrivée d’autres packages dans les mois à venir, sans compter sur les tierces parties).

Création du fichier VHD

Les étapes suivantes permettent de créer le fichier de disque dur virtuel VHD qui sera monté ensuite dans une VM puis dans un container Windows Server.

1. Télécharger une ISO de Windows Server 2016

2. Monter l’image dans votre système de fichier (sur Windows : clic droit sur le fichier .iso > Monter). Pour la suite de ce post, mon lecteur DVD est D:\.

3. A la racine de l’ISO, copier les scripts Convert-WindowsImage.ps1 et le nanoServerImageGenerator.psm1 vers un répertoire sur votre disque dur (dans mon cas c:\NanoServer ) :

image => image

4. Ouvrez une console PowerShell en mode administrateur et placez vous dans le répertoire que vous avez copié (celui où vous avez le fichier Convert-WindowsImage.ps1 et le nanoServerImageGenerator.psm1). Pour importer le module de génération d’image Nano Server, exécutez la ligne de commande : Import-Module .\NanoServerImageGenerator.psm1 –Verbose

image

Note : sur Windows 8.1, vous aurez sûrement à exécuter la commande Set-ExecutionPolicy -ExecutionPolicy Unrestricted pour permettre l’utilisation du module et du script PowerShell.

5. Pour créer un VHD NanoServer avec les drivers de VM hôte (et rien de plus !), exécutez la ligne de commande suivante : New-NanoServerImage -MediaPath D:\ -BasePath .\Base -TargetPath ‘.\NanoImage\NanoVM.vhd’ -GuestDrivers –EnableRemoteManagementPort –Language en-us –ComputerName NanoServerNode1

Lorsque le script vous le demande, saisissez le mot de passe administrateur qui vous permettre de vous connecter à la console de gestion (recovery console).

image

Cette ligne de commande utilise le fichier WIM situé sur le media monté sur D:\ (l’ISO montée) et utilisera le répertoire \Base situé dans le même répertoire que les scripts. Dans notre cas, nous ajoutons les drivers de machine virtuelle et activons la gestion à distance.

Note : si vous spécifiez .vhd pour votre VHD cible, vous aurez un VHD avec un support MBR. Si vous spécifiez .vhdx, vous aurez un support GPT, de génération 2 de machine virtuelle Hyper-V. La taille des fichiers VHD varient entre ces deux schémas de partitionnement :

image

Remarque :  le script prenant les paramètres locales de la machine, étant sur un système local fr-fr et les packages n’étant disponibles qu’en EN-US, nous devons spécifier le paramètre –Language en-us. Les packages devraient être localisés dans les mois à venir. Si vous ne spécifiez pas ce paramètre sur un système autre que en-us, vous aurez un message d’erreur.

Vous pouvez aussi exécuter la ligne de commande pour ne pas avoir à spécifier le mot de passe administrateur :

New-NanoServerImage -MediaPath D:\ -BasePath .\Base -TargetPath .\NanoImage\NanoVM.vhd -Compute -GuestDrivers -ComputerName 1stNano -AdministratorPassword (« P@ssw0rd » | ConvertTo-SecureString -AsPlainText -Force)

Attention : vous ne pouvez pas créer une image sur deux OS/versions d’Hyper-V différentes (par exemple créer l’image sur un Windows Server 2016 et l’exécuter Windows 8.1) car les drivers invités qui sont injectés sont ceux de la version d’Hyper-V de l’OS qui crée l’image.

Exécuter la machine virtuelle

Une fois le fichier VHD généré, nous allons créer une nouvelle machine virtuelle pour exécuter Nano Server :

1. Créer une machine virtuelle dans Hyper-V :

image

Ici nous allons utiliser le fichier .vhd et donc sélectionner la génération 1 :

image

Nano Server ayant besoin de peu de ressources, nous allons laisser 512 Mo de RAM (à dimensionner en fonction de vos besoins) :

image

image

Sélectionner le disque VHD NanoServer créé plus haut :

image

image

Une fois la machine virtuelle créée, n’hésitez pas éventuellement à modifier les paramètres tel que le nombre de processeurs, etc.

2. Démarrez et connectez vous la machine virtuelle Hyper-V pour afficher la console restauration vous permettant d’accéder à voter système même si vous avez un problème réseau :

image

3. Saisissez Administrator comme nom d’utilisateur et le mot de passe que vous aviez spécifié pendant la création de l’image (attention : clavier QWERTY de rigueur !) :

image

Pour naviguer dans l’interface, utilisez les touches de direction, Tab et Echap (pour sortir d’un menu).

Voilà ! Nous venons de créer notre image NanoServer fonctionnelle. Dans les posts à venir, nous allons voir comment personnaliser cette image pour héberger un IIS dans un Windows Server Container.

Ressources

Vous pourrez retrouver de nombreux détails sur la page https://msdn.microsoft.com/en-us/library/mt126167.aspx

Déployer ASP.NET 5 dans un container Docker

Publié le par
Répondre

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

Publié le par
Répondre

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).