Installation Nutanix Ce sur une station de travail

Résultat de recherche d'images pour "nutanix"

 

1 – Présentation de la solution

La plate-forme de virtualisation informatique Nutanix est une solution d’infrastructure convergente qui mutualise la puissance de calcul (serveur) et la puissance de stockage en un unique appareil intégré.

Nutanix a été conçu en mettant l’accent sur la simplicité, grâce aux mêmes principes et technologies utilisés par des innovateurs informatiques tels que Google, Facebook, ou Amazon.

La solution adapte ces principes et technologies pour les entreprises et les institutions.

La plate-forme Nutanix se présente comme une solution simple et performante comparée aux infrastructures de datacenters traditionnels :

  • Rentabilisation instantanée : déploiement en moins de 30 minutes
  • Pas de perturbation des opérations en cours
  • Fonctionne avec les composants existants, garantie des investissements déjà réalisés
  • Réduit le prix et la complexité du stockage
  • Facilement adaptable
  • Matériel non-propriétaire prêt à l’emploi
  • Fournit des capacités de stockage avancées pour les entreprises

La conception  modulable de la solution permet à votre organisation de démarrer avec des déploiements modestes  et de les développer au fur et à mesure selon vos besoins. Avec un seul appareil, vous pouvez réaliser de la petite opération jusqu’aux déploiements de grande envergure, en passant par des initiatives de virtualisation de postes, des tests et développements d’applications, des projets Big Data, et plus encore.

En outre, la plate-forme de virtualisation informatique Nutanix intègre des ressources serveur haute-performance et du stockage dans un appareil rack 2U économique. Il supprime ainsi la nécessité d’architectures de stockage en réseau tel que le SAN (Storage Area Network) ou le NAS (Network-Attached Storage). L’évolutivité et les performances dont bénéficient les plus grands et les plus efficaces datacenters du monde sont désormais disponibles pour les entreprises et organismes de toute taille.

2 – Les prérequis :

  • Intel Processor with VT-x support.
  • 32Go de ram. La CVM prend 16Go plus quelques GO pour la faire tourner. Il est possible de faire tourner la version CE (community edition) sur Workstation/Fusion avec 12Go par node (via un tweak)
  • 1 x 200Go SSD (tweak possible)
  • 1 x 500Go HDD
  • Intel NIC

Ma plateforme de test:

  • Gigabyte Ga-x79-UD3
  • Intel i7 3820
  • SSD Disk : Samsung PRO 850 250Go
  • HDD Disk : WD 3Tb 7200rpm Sata 6Gb HDD
  • RAM : 32GB
  • Configuration : Nutanix CE installé en version Single-Node sur Workstation de VmWare

3 – Inscription sur le site my.nutanix.com et téléchargement de la version CE.

Une fois inscris sur le site, il vous faudra télécharger la version CE. Ce fichier se nomme ce-2015.06.08-beta.img.gz. Une fois le fichier extrait il prendra le nom de ce-201x.xx.xx-beta.img. Chaque release porte un nom différent.

4 – Préparation de l’environnement de test

Si comme moi vous n’avez que votre station de travail comme laboratoire, il va falloir préparer cet environnement pour les besoins du test.

Commencer par identifier les disques durs qui vont vous servir pour ce test.

Dans mon cas, il s’agissait de c:\ d:\ et e:\.

J’ai préparé chaque disque dur en créant un répertoire Virtual-Machines\Nutanix à la racine.

C:\ pour l’iso

D:\ en tant que SSD

E:\ pour le stockage lent

Il faut ensuite copier le fichier image dans le répertoire de travail puis le renommer en flat-ce.vmdk ansi que créer un fichier ce.vmdk qui servira au boot de notre image.

Voici ce que vous devez mettre dans le fichier ce.vmdk :

# Disk DescriptorFile
version=4
encoding=”UTF-8″
CID=4470c879
parentCID=ffffffff
isNativeSnapshot=”no”
createType=”vmfs”
# Extent description
RW 14540800 VMFS “ce-flat.vmdk”
# The Disk Data Base
#DDB
ddb.adapterType = “lsilogic”
ddb.geometry.cylinders = “905”
ddb.geometry.heads = “255”
ddb.geometry.sectors = “63”
ddb.longContentID = “ac2a7619c0a01d87476fe8124470c879”
ddb.uuid = “60 00 C2 9b 69 2f c9 76-74 c4 07 9e 10 87 3b f9”
ddb.virtualHWVersion = “10”

Une fois le tout préparé, il ne reste plus qu’a créer la VM qui accueillera Nutanix.

  • 8 cores
  • 16Go
  • Intel Vt-X enable
  • Le premier disque le fichier que nous avons fait auparavant : ce.vmdk
  • Le second disque pointera dans le répertoire sur le disque D :
  • Le troisième disque pointera dans le répertoire sur le disque E :

 5 – Le lancement

Une fois votre VM démarrée, vous arrivez sur cette écran :

Tapez install et appuyez sur entré.

Si vous avez de la chance et possédez une bonne configuration les tests de la plateforme passerons et vous pourrez continuer l’installation, si ce n’est pas le cas, il va falloir faire un petit tweak pour que le système prenne en compte votre matériel.

Connectez vous sur l’image d’installation et faire un petit changement de configuration dans le format des disques détectés :

NCE (17)

Au lieu de taper ‘’ install ‘’, vous allez taper ‘’ root ‘’ avec le mot de passe ‘’ nutanix/4u ‘’

 Une fois connecter sur la VM, faire ;

  1. Fdisk –l
  2. Identifier le second disque (200go)
  3. Récupérer son nom (sdb pour mon cas)
  4. Executer “cat /sys/block/sda/queue/rotational” 0 pour le SSD et 1 pour le HDD
  5. Executer “echo 0 > /sys/block/sda/queue/rotational” pour changer la valeur de 1 to 0
  6. Vous pouvez relancer l’installation J

Une fois l’installation lancée, vous arrivez sur cet écran ;

NCE (19)

Choisir le clavier correspondant à votre matériel.

Ensuite il faut renseigner l’ip du host KVM et celle du CVM.

Libre à vous de choisir la plage d’adressage par rapport à votre infra.

Il est conseillé par exepérience de déchocher la case ‘’Create single-node cluser’’. On devra déclarer ce node en cluster à la fin de l installation.

Suivant puis installer.

NCE (21)

Une fois l’installation terminée, il va falloir manuellement créer le cluster (mono node)

NCE (25)

 6 – La création du cluster

 Se connecter en SSH sur le CVM et utiliser les identifiants suivant ;

User : nutanix

Pass : nutanix/4u

Taper la commande suivante : ‘’ cluster -s cvm_ip_address create ‘’

Remplacer cvm-ip-address par celle de votre CVM. Dans le cas de plusieurs nodes, il suffit de mettre les adresses des CVM séparées par une virgule.

Ensuite taper : ncli cluster add-to-name-servers servers=8.8.8.8

Faire un ping : ping 8.8.8.8 puis ping www.google.fr

7 – Se connecter à l’interface graphique

Se connecter sur l’interface PRISM à l’adresse de votre CVM
NCE (31)

Pour cela, ouvrez une page web et mettez l’addresse comme suit :

https://CVM_IP_Master:9440

Utilisez les identifiants suivants ;

Login : admin

Pass : admin

Cela vous permettra de reset le compte admin avec votre mot de passe.

Il faut impérativement que la VM communique avec votre passerelle réseaux car elle doit pouvoir se connecter sur le site communautaire de Nutanix. Vous devrez utiliser les identifiants créer pour la 3 étape de ce tutorial.
NCE (33)
NCE (34)

Si vous n’arrivez pas à vous connecter sur l’inerface c’est que votre machine virtuelle ne communique pas avec la passerelle. Il faudra troubleshooter la connexion soit sur l’hyperviseur soit dans les fichiers de conf de votre CVM.

Voici à quoi ressemble l’interface.

NCE (35)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Tier3, Tier4… de quoi s’agit-il ?

Classification des différents tiers Datacenter

 

Il faut que l’usine tourne !   C’est la première responsabilité du DSI.

Chaque jour, de nombreuses entreprises se tournent vers le Cloud Computing et l’externalisation de leur SI. Véritable révolution dans la gestion etl’administration des services informatiques, le Cloud soulève également de réelles questions en matière de sécurité et de fiabilité. Le choix d’un fournisseur pour le Cloud comme pour l’infogérance de son Datacenter privé, prend tout son sens lorsqu’on s’intéresse aux différents tiers de datacenter, véritable échelle des niveaux de sécurité et de fiabilité offerts par ces centres de données.

Niveaux et tiers Datacenter

Définition des différents tiers de Datacenter:

Tier 1 : Un seul circuit électrique pour l’énergie et la distribution de refroidissement, sans composants redondants
Disponibilité : 99.67% – 28.8 heures d’interruption/an – Aucune redondance 

Tier 2 : Un seul circuit électrique pour l’énergie et la distribution de refroidissement, avec composants redondants
Disponibilité : 99.75% – 22 heures d’interruption/an – Redondance partielle

Tier 3 : Plusieurs circuits électriques pour l’énergie et la distribution de refroidissement (un seul actif), avec composants redondants
Disponibilité : 99.982% – 1.6 heures d’interruption/an – Redondance N+1

Tier 4 : Plusieurs circuits électriques pour l’énergie et la distribution de refroidissement, avec composants redondants actifs et supporte la tolérance de panne
Disponibilité : 99.995% – 0.8 heures d’interruption/an – Redondance 2N+1

Différences Tier 3 et Tier 4:

Les Datacenters de Tier 3 assurent une disponibilité de 99,98%, permettant de gérer des opérations de maintenance sans affecter la continuité des services des serveurs hébergés. Cependant, le Tier 3 n’inclut pas une redondance complète et distincte et ne sont donc pas à l’abri de coupures en cas d’incidents sur l’infrastructure.

Les Datacenters de Tier 4 représentent le plus haut niveau de garantie avec des taux de disponibilité de 99,99%. Cette certification assure une redondance complète des circuits électriques, des dispositifs de refroidissement et du matériel réseau et permet de garantir la complète disponibilité des services hébergés, même en cas de lourds incidents techniques.

Le choix d’un fournisseur Cloud

En fonction de la criticité des services qu’une entreprise souhaite externaliser, elle pourra faire le choix d’un datacenter de dernière génération, offrant une certification et des garanties pour la sérénité de ses données.

Le choix d’un fournisseur Cloud doit aller au-delà de la notoriété et des services proposés par celui-ci. Les tiers de datacenter permettent une vision claire et précise des niveaux de sécurité et de fiabilité que peuvent offrir ces derniers.

Clusters de containers Docker

Une fois déployée une infrastructure de containers Docker, se pose la question de savoir comment optimiser l’utilisation des ressources du serveur hôte par la fourniture de services de failover et de distribution. Il existe plusieurs solutions offrant ce type de mécanisme.

Docker Swarm

Docker Swarm (« Essaim ») est la technologie proposée nativement par Docker pour gérer le clustering de containers Docker. Plus précisément, Docker Swarm permet aux utilisateurs de créer des pools de serveurs hôtes exécutant les services de Docker, de les exposer comme un seul hôte Docker virtuel, puis de configurer des containers Docker en gérant automatiquement la répartition de la charge et la gestion de l’état du cluster.

Docker Swarm utilise l’API standard de Docker, donc n’importe quel outil qui communique déjà avec un démon de Docker peut utiliser Swarm pour réaliser les mêmes actions sur de multiples hôtes Docker de manière transparente.

Comme d’autres projets de Docker, Swarm suit le principe de «batteries included but removable ». Il est donc fourni nativement avec un mécanisme simple d’orchestration complété par des points d’extensibilité permettant de le remplacer par des solutions pour les déploiements de production à grande échelle, comme Mesos, que je présenterai dans la section suivante.

Pour installer un cluster swarm, il faut commencer par obtenir l’image officielle proposée dans le référentiel Docker Hub.

docker pull swarm

Une fois téléchargée l’image de l’application swarm, on peut alors l’exécuter dans un container pour générer le jeton qui permettra d’identifier ensuite le cluster Swarm.

docker run –rm swarm create

Une première approche pour déployer un cluster Swarm consiste à utiliser une série de commandes docker, comme l’illustre le script suivant :

# on each of your nodes, start the swarm agent

# <node_ip> doesn’t have to be public (eg. 192.168.0.X),

# as long as the swarm manager can access it.

$ docker run -d swarm join –addr=<node_ip:2375> token://<cluster_id>

# start the manager on any machine or your laptop

$ docker run -d -p <swarm_port>:2375 swarm manage token://<cluster_id>

# use the regular docker cli

$ docker -H tcp://<swarm_ip:swarm_port> info

$ docker -H tcp://<swarm_ip:swarm_port> run …

$ docker -H tcp://<swarm_ip:swarm_port> ps

$ docker -H tcp://<swarm_ip:swarm_port> logs …

# list nodes in your cluster

$ docker run –rm swarm list token://<cluster_id> <node_ip:2375>

L’article de mon collègue Steve Squillace décrit dans le détail une configuration de Swarm fondée sur cette approche. Une autre démarche, plus rapide, est d’utiliser Docker Machine. En effet, cet outil offre des paramètres spécifiques à Swarm…

La première étape est de créer le serveur Docker qui hébergera le rôle « Swarm-master ».

docker-machine -D create -d azure \

–azure-subscription-id= »<identifiant de la souscription> » \

–azure-publish-settings-file= »<fichier de parametres de publication> » \

–azure-location « West Europe » \

–swarm \

–swarm-master \

–swarm-discovery token://<token généré avec Swarm> \

swarm-master-qa-stephgou

On peut alors créer les nœuds du cluster.

docker-machine -D create -d azure \

–azure-subscription-id= »<identifiant de la souscription> » \

–azure-publish-settings-file= »<fichier de parametres de publication> » \

–azure-location « West Europe » \

–swarm \

–swarm-discovery token://<token généré avec Swarm> \

swarm-node-qa-stephgou-0

En utilisant ces commandes, il est ainsi extrêmement simple de monter son cluster et d’afficher la liste des nœuds avec la commande :

docker-machine env –swarm swarm-master-qa-stephgou

On remarque que dans le cas du cluster Swarm, le DOCKER_HOST écoute sur le port 3376, alors que les URLs qui sont affichées lorsque l’on exécute la commande docker-machine env sont à l’écoute sur le port 2376. Le port 3376 est celui qui est utilisé pour les communications s’inscrivant dans le contexte du cluster Swarm, tandis que le port 2376 est utilisé pour une communication directe avec le serveur hôte Docker cible. Or, si le driver Azure pour Docker Machine crée automatiquement les points de terminaison pour autoriser les flux d’échange sur le port 2376, il ne crée pas celui correspondant au cluster Swarm. Il faut donc ajouter ce point de terminaison afin de finaliser la configuration du cluster, comme le montre la copie d’écran suivante.

ll devient alors possible d’interroger Docker pour connaître la configuration du cluster avec la commande :

docker info

Pour obtenir des informations filtrées sur la liste des nœuds du cluster Swarm, on peut utiliser la commande :

docker run –rm swarm list token://<token généré avec Swarm>

Pour tester le comportement de ce cluster Swarm, il suffit de déployer un serveur Web. On peut alors interroger le Docker Hub pour choisir une image de serveur http avec la commande :

docker search -s=10 http

Dans ce contexte, il est alors possible de monter jusqu’à 3 serveurs http (déployés respectivement sur le master et sur les deux nœuds du cluster) à l’écoute sur le port 80. La quatrième commande échoue car aucun des nœuds Swarm ne dispose d’un port 80 disponible.

docker run –d –p 80:80 –name stephgou-A httpd

docker run –d –p 80:80 –name stephgou-B httpd

docker run –d –p 80:80 –name stephgou-C httpd

docker run –d –p 80:80 –name stephgou-D httpd

Les 3 serveurs HTTP sont bien démarrés.

Il est possible d’explorer la configuration de l’un des containers (par exemple le containerabef948edf3e ) avec la commande :

docker inspect abef948edf3e

Pour le requêter en HTTP, il ne reste donc plus qu’à ajouter un endpoint sur la VM hébergeant le node swarm dans Azure.

On peut alors vérifier que le serveur HTTP répond bien sur cette url.

Apache Mesos

Apache Mesos est une solution open source de gestion de cluster conçue pour déployer et optimiser des systèmes distribués. Mesos est construit selon les mêmes principes que le noyau Linux, mais offre un niveau d’abstraction différent : en fait, Mesos se comporte comme le noyau d’un système d’exploitation à l’échelle d’un datacenter. Mesos propose des API permettant de gérer les caractéristiques (mémoire, CPU, disque et ports) de machines (physiques ou virtuelles) et de planifier leur utilisation en donnant à des applications comme Hadoop, Spark, Kafka, Elastic Search, la possibilité de manipuler ces ressources au sein d’un pool unique alloué dynamiquement.

Concrètement, Mesos permet ainsi d’exécuter plusieurs systèmes distribués sur le même cluster en isolant et en partageant des ressources. Testée en production, la capacité de dimensionnement de Mesos pourrait prendre en charge des milliers de nœuds. Cette solution est  d’ailleurs utilisée par des services comme Twitter, eBay et NetFlix. Enfin, Mesos supporte Docker…

Mesosphere

La startup Mesosphere propose une technologie de système d’exploitation de DataCenter (DCOS), fondée sur Apache Mesos, pour les plateformes Cloud comme Microsoft Azure. DCOS propose donc une solution axée sur un mécanisme à base de container permettant de traiter tous les serveurs et les ressources d’un Datacenter comme une seule entité de gestion d’infrastructure. L’objectif est de simplifier le déploiement de l’infrastructure, des composants associés et la construction des applications par la mise à disposition d’une version consolidée de Mesos intégrant un langage de commandes et un portail.

Mesosphere utilise le framework Open Source Marathon : il permet de provisionner un environnement PaaS opérationnel en l’espace de quelques minutes. Lors de la récente conférence Build de Microsoft, Mark Russinovich a démontré la bêta de Mesosphere sur Azure. Il a d’abord expliqué comment configurer un quelques clics un cluster Mesosphere (grâce au mécanisme de publication en ligne d’un template DCOS proposé par Corey Sanders).  Puis il a lancé, sur un cluster DCOS préconfiguré de 212 ressources (103 VMs, 103 Nic + 2*3 masters Mesosphere), 1000 containers Marathon et 1000 containers Spark avec les quatre lignes de commande suivantes :

dcos marathon app add marathon.json

dcos marathon app add spark.json

dcos marathon app update marathon instances=1000

dcos marathon app update spark instances=1000

Voici l’affichage du portail Mesosphere au cours de cette présentation.

Cette démonstration illustre également les possibilités qu’offrent le principe d’extension d’Azure Resource Manager, qui a permis, dans ce contexte, de déclarer des boucles d’instanciations de machines virtuelles au sein du template décrivant le cluster…

Apache Hadoop YARN

Apache Hadoop YARN (« Yet Another Resource Negotiator ») est la technologie de gestion de cluster incluse dans la version 2 de Hadoop offrant un système d’exploitation distribué à grande échelle pour les applications Big Data. Egalement appelé MapReduce 2.0, ce logiciel permet de dissocier les capacités de gestion et de planification des ressources qu’offre MapReduce, du composant de traitement des données.

A la différence de la première version de MapReduce qui ne permettait que du traitement orienté batch, cette nouvelle approche permet ainsi à Hadoop de supporter de multiples modèles de traitement et un plus large éventail d’applications, comme par exemple l’analyse de données en temps réel. YARN délègue les tâches correspondantes à des containers et ces containers peuvent être des containers Docker…

Kubernetes

Kubernetes (timonier en grec) est un projet OpenSource de Google pour gérer des containers Linux à grande échelle. Kubernetes supporte Docker et permet d’intégrer chaque hôte de Docker au sein d’un cluster auquel il distribue les informations de configuration. Microsoft supporte Kubernetes dans Azure et propose un outil Open Source de visualisation des clusters Kubernetes.

Utilisation de Docker

Une fois le hôte Docker déployé sur la plateforme Azure, il devient alors possible, depuis le client Docker, d’utiliser les différentes commandes et outils permettant de créer des images, de les publier, et d’exécuter des containers ayant ces images pour source…

Premier pas avec Docker

Les commandes qui permettent l’interaction avec le moteur Docker Hub sont extrêmement simples.
La recherche d’une image dans le référentiel Docker Hub se fait avec la commande search :docker search nginx

Les images « Automated » sont automatiquement créées par les clusters de serveurs de Build de DockerHub, à partir de la spécification d’un Dockerfile (que nous verrons dans la suite de cet article) ou depuis un contexte GitHub ou BitBucket.

Le téléchargement d’une image depuis le référentiel Docker Hub se fait par avec la commande pull : docker pull nginx

Le téléchargement d’une image se fait par avec la commande push : docker pushyourname/newimage
Pour lancer un container, il suffit d’exécuter une commande comme : docker run ubuntu:14.10/bin/echo ‘Hello Azure’

Cette commande spécifie l’image qui va être la source du container d’exécution. Ici, il s’agit de monter de système d’exploitation Ubuntu 14.10. Si l’hôte Docker ne dispose pas déjà de cette image, il la télécharge depuis le référentiel Docker Hub. Une fois l’image déployée, Docker peut lancer un nouvel environnement Ubuntu 14.10 et y exécuter la commande.

Il est également possible de démarrer un container de façon interactive, si on le lance avec les flags « t » (terminal) et « i » (interactif via la capture du STDIN du container) avec la commande « /bin/bash » : docker run -t -i ubuntu:14.04 /bin/bash

Cette commande est un cas particulier de la commande suivante : docker run -ti ubuntu:14.04 –entrypoint /bin/bash

Le « entrypoint » par défaut est « /bin/sh -c » que l’on peut personnaliser dans un document texte baptisé Dockerfile.

Dockerfile

Un Dockerfile contient toutes les commandes requises qu’il faudrait exécuter manuellement pour parvenir à la construction d’une image de Docker.
L’équivalent d’un Dockerfile pour une application Console affichant l’universel « Hello World » pourrait être le suivant :

FROM busybox

ENTRYPOINT [« echo »]

CMD [« hello world »]

Le fichier suivant permet de décrire l’image d’une application node.js bâtie sur l’image node:0.10-onbuild disponible dans le référentiel Docker Hub.

FROM node:0.10-onbuild

EXPOSE 8888

COPY . /app

RUN cd /app; npm install

CMD [« node », « /app/server.js »]

En appelant la commande docker build, Docker construit l’image cible étape par étape, en exécutant les instructions successivement.

docker build –tag=nodejs nodejs

Une fois déployés les pré-requis liés à la construction de l’image, la même commande s’exécute beaucoup plus rapidement.

On peut alors lancer le container hébergeant l’application, en lui précisant une redirection de port, puisque dans cet exemple, il s’agit d’une application Web hébergée dans un container s’exécutant dans une VM déployée sur Azure (et pour laquelle il faut également ajouter un endpoint pour exposer le port http permettant de requêter cette application Web…)

docker run -d -t -p 8080:8888 -name node-app nodejs

Signalons qu’il existe aussi un moyen de passer des commandes à un container déjà lancé (par exemple pour se retrouver dans son contexte d’exécution : très pratique pour debugger un Dockerfile) avec la commande docker exec – en spécifiant l’identifiant du container lancé (dans notre exemple : 6a4e9745f0ba ou son nom (le nom généré « loving_bardeen »).

docker exec -ti 6a4e9745f0ba bash

Compose

Compose est un outil Docker permettant de définir dans un seul fichier des applications multi-containers et de les déployer ou de les exécuter avec des commandes ayant une portée sur le cycle de vie de l’ensemble des composantes de ces applications :
• Démarrage, arrêt et reconstruction des services
• Affiche du statut de l’exécution des services
• Capture du flux d’information issu du journal de l’exécution de services
• Exécution d’une commande ponctuelle sur un service
L’utilisation de Compose est un processus en trois étapes.
Tout d’abord, il faut définir l’environnement de l’application avec un Dockerfile.

FROM python:2.7

WORKDIR /code

ADD requirements.txt /code/

RUN pip install -r requirements.txt

ADD . /code

CMD python app.py

Il faut ensuite configurer la liste des services qui constituent l’application avec le fichier docker-compose.yml de façon à établir leur association au sein d’un environnement isolé :

web:

build: .

links:

– db

ports:

– « 8000:8000 »

db:

image: postgres

Enfin, la commande docker-compose up permet de lancer l’application et ses composants.

Après cette exploration de l’utilisation des commandes de Docker, nous voici prêts à aborder la clusterisation des containers. Ce sera l’objet de mon prochain article…

Provisioning d’un host Docker dans Azure

Les rôles client et serveur Docker peuvent fonctionner sur le même système (en environnement Linux ou sur Windows Server 10) ou sur deux machines différentes (Mac, Windows, Linux). Dans le cas où le moteur Docker s’exécute sur un serveur hôte différent de la machine qui exécute le client Docker, se pose la question de l’hébergement de ce serveur. La plateforme Microsoft Azure peut héberger la machine virtuelle hôte Docker permettant de déployer images et containers. Il faut donc pouvoir provisionner cet hôte Docker et nous allons voir qu’il existe de multiples solutions pour y parvenir. Dans l’immédiat, nous nous limiterons volontairement au provisioning de host Docker sous Linux.

Nouveau portail Azure et Docker

Le nouveau portail Azure offre aujourd’hui deux mécanismes permettant de faciliter le déploiement d’environnements hôtes Docker sur Azure.
Le premier de ces dispositifs est une extension qui cible les machines virtuelles Linux Ubuntu ou CoreOS. Il s’agit d’un composant installé dans l’instance de la machine virtuelle lors de sa création. Son rôle est d’installer le moteur Docker sur la machine virtuelle et de le configurer pour écouter les commandes en provenance du client Docker.
La copie d’écran présente l’ajout de cette extension pour une machine CoreOS :

La deuxième approche consiste à utiliser une image de machine virtuelle accessible via la MarketPlace. Cette image est déjà configurée pour assurer le déploiement d’une version Ubuntu Server 14.04 LTS et installer le moteur Docker via l’extension de VM précédemment évoquée.

Langage de script Azure-Cli

Une alternative au portail Azure est d’utiliser le langage de script Azure Cross-Platform Command Line Interface (xplat-cli) depuis une machine cliente, par exemple une machine Ubuntu ou un Mac. Azure-cli est le langage de scripting Azure en ligne de commande pour les environnements Windows, Mac et Linux. Il est développé en javascript et nécessite l’installation de node.js. La première étape consiste donc à installer nodejs, npm, puis azure-cli.

sudo apt-get update

sudo apt-get install nodejs-legacy

sudo apt-get install npm

sudo npm install azure-cli –global

 

Pour configurer Azure-Cli afin d’utiliser une souscription Azure, deux approches sont possibles.
La première approche consiste à  télécharger le fichier de paramètres de publication depuis l’adresse http://manage.windowsazure.com/publishsettings/index. Microsoft Azure crée un alors un nouveau certificat de gestion et attache ce certificat à l’ensemble des souscriptions Azure sur lequel le compte connecté a des droits d’administration (on peut alors le voir dans la section « Management Certificates » du module « Settings » du Portail Azure).
LLe fichier téléchargé contient les données brutes de ce certificat (y compris la clé privée, mais non exportable). Tout outil supportant ce type de fichier, et en particulier azure-cli peut alors analyser ce fichier XML, lire les données du certificat et l’installer en local (généralement dans le magasin de certificats « Current User – Personal »).
La seconde approche consiste à se logger avec un compte d’organisation (attention les comptes Microsoft ne sont pas supportés). Dans ce deuxième cas, c’est Azure Active Directory qui est utilisé pour authentifier les paramètres d’identification de l’utilisateur.

azure login –u <compte-organisation>

Une fois authentifié par l’une ou l’autre de ces methodes, on peut alors utiliser la commandeazure vm docker create dont voici l’aide.

La commande azure vm docker create permet de créer la machine virtuelle host Docker, d’installer l’extension de VM Docker, de générer et télécharger les certificats d’authentification pour la communication Docker.

azure vm docker create -e 22 -l ‘West Europe’ <machine-cible>

« b39f27a8b8c64d52b05eac6a62ebad85__Ubuntu-14_10-amd64-server-20141022.3-en-us-30GB » <user-name> <password>

Les certificats sont créés automatiquement lors du premier usage de cette commande. Ils sont stockés sur la machine cliente et sur le serveur hôte. Lors des exécutions suivantes, les certificats existants seront réutilisés et partagés avec le nouvel hôte. Par défaut, les certificats sont placés dans  ~/.docker et le moteur Docker est configuré pour s’exécuter sur le port 4243. Il est possible d’utiliser un autre port ou un répertoire avec les options de commande suivantes :

–docker-port [port]

–docker-cert-dir [dir]

Sur le host, le démon Docker est configuré pour écouter et authentifier les connexions client sur le port spécifié avec les certificats générés. L’ordinateur client doit donc nécessairement disposer de ces certificats pour interagir avec le moteur Docker.

Docker Machine

Les fonctions de Docker Machine

Docker Machine permet de facilement créer des hosts Docker soit sur la machine locale, soit sur un service de Cloud. Cet outil proposé par Docker offre de multiples intérêts :
• Possibilité de provisionner les serveurs Docker directement dans le Cloud de son choix
• Configuration du client Docker pour qu’il puisse communiquer avec ces serveurs (il génère notamment les certificats et partage les clés assurant la sécurité des échanges).
• Exécution depuis de multiples environnements (Linux, iOS, Windows,…)
• Une fois que l’hôte Docker a été créé, il offre des commandes pour leur gestion : démarrage, arrêt, mise à jour,….

Docker Machine et Azure

Un driver Azure pour Docker Machine a été développé par Jeff Mendoza (Microsoft). Ce pilote est écrit en Go et utilise le SDK Azure proposé pour ce langage afin de communiquer avec les APIs Azure Service Management pour provisionner les machines virtuelles et installer Docker à l’aide de l’extension Docker pour les VMs Azure. Les sources et détails d’implémentation ont été publiés sur GitHub.
Le nom de l’exécutable correspondant à un Docker Machine varie suivant les environnements cibles. Je vous invite à le renommer en « docker-machine ». Ainsi vous utiliserez la même commande (simplifiée) depuis n’importe quel système d’exploitation…

Avant de pouvoir utiliser Docker Machine, il faut télécharger un fichier de paramètres de publication depuis l’adresse http://manage.windowsazure.com/publishsettings/index (cf section précedente : Langage de script Azure-Cli).

Voici donc un exemple d’une commande docker-machine permettant de créer un hôte Docker hébergé sur une machine de type « Small » dans Azure.

docker-machine -D create -d azure \

–azure-subscription-id= »<souscription-id> » \

–azure-docker-port= »2376″ \

–azure-publish-settings-file= »<souscription-publishsettingsfile> » \

–azure-location= »West Europe » \

–azure-password= »<password> » \

–azure-size= »Small » \

–azure-ssh-port= »22″ \

–azure-username= »<username> » \

<nom de la machine docker host>

Par défaut, c’est une Ubuntu 14.04 LTS, qui est utilisée, mais il est également possible de spécifier une version spécifique de la distribution Linux, par exemple »b39f27a8b8c64d52b05eac6a62ebad85__Ubuntu-14_10-amd64-server-20141204-en-us-30GB », en utilisant le paramètre –azure-image

Une fois l’exécution de cette commande achevée, il est alors possible de contrôler si le host docker ainsi créé fonctionne en utilisant le client Docker avec la commande dockerinfo : on peut alors utiliser le client Docker sur les VMs hôtes Docker déployées dans Azure provisionnées avec Docker Machine comme on le ferait depuis un client Docker déployé sur Linux. La copie d’écran suivante présente les informations correspondant à la configuration de deux hosts Docker provisionnés depuis Windows.
Pour utiliser Docker, il faut alors configurer l’environnement d’exécution, notamment les variables :

DOCKER_HOST=tcp://stephgoudockerfromwin.cloudapp.net:2376

DOCKER_CERT_PATH=C:\Users\stephgou\.docker\machine\machines\stephgoudockerfromwin

Ces valeurs sont obtenues à partir de la commande docker-machine env et elles doivent être injectées en tant que variables d’environnement. Etudions maintenant plus en détail la configuration de Docker Machine sur les différents systèmes Linux, Mac, et Windows.

Docker Machine sur Linux

Pour installer Docker Machine sur Linux, il suffit de télécharger le binaire depuis l’url suivantehttps://github.com/docker/machine/releases/download/v0.2.0/docker-machine_linux-amd64 dans un répertoire connu dans le PATH (par exemple, « /usr/local/bin ») et de le rendre exécutable.

Sous Linux, la commande suivante permet d’exporter directement les variables d’environnement Docker :
eval « $(./docker-machine env stephgoudockerfromwin) »

Docker Machine sur Mac

Pour installer Docker Machine sur Mac, il suffit de télécharger le binaire depuis l’url suivantehttps://github.com/docker/machine/releases/download/v0.2.0/docker-machine_darwin-amd64 dans un répertoire connu dans le PATH (par exemple, « /usr/local/bin ») et de le rendre exécutable. On pourra utiliser les commandes suivantes :

curl -L https://github.com/docker/machine/releases/download/v0.2.0/docker-machine_darwin-amd64 > /usr/local/bin/docker-machine

chmod +x /usr/local/bin/docker-machine

Sous Mac, l’export des variables d’environnement Docker est identique à celui réalisé sur Linux :
eval « $(docker-machine env stephgoudockerfromwin) »

Docker Machine sur Windows

Pour installer Docker Machine sur Windows, il suffit de télécharger l’exécutable depuis l’url suivantehttps://github.com/docker/machine/releases/download/v0.2.0/docker-machine_windows-amd64.exe dans un répertoire connu dans le PATH.
Sous Windows, le fonctionnement de Docker Machine, se heurte à deux difficultés :
• La nécessité de mettre à disposition la commande OpenSSL (qui n’est pas fourni nativement dans Windows) qui est un pré-requis de l’utilisation de la commande Docker Machine
• La gestion des variables d’environnement Docker

Mise à disposition de la commande OpenSSL

Il existe de multiples façons d’obtenir OpenSSL sur Windows. L’une d’elle est d’utiliser l’application « Git for Windows » dont je vous ai déjà parlé dans un précédent article.
• La commande OpenSSL est directement disponible depuis le shell Mingw32 fourni avec « Git Bash ». Son usage dans cet environnement d’exécution impose le respect de certaines conventions liées à un système Unix (comme l’illustre la gestion des variables d’environnements que je traiterai un peu plus loin…).
• Une alternative à cette approche est d’ajouter dans le path de Windows le répertoire dans lequel est installé OpenSsl et d’utiliser directement le Shell Windows (cf copie d’écran suivante).

Suivant la version de « Git Bash » que vous aurez installé, vous serez amené ou non à rencontrer l’erreur « Error creating machine: exit status 1 » lors de l’utilisation de docker-machine sous Windows. Avec une version 1.8.x, ce dysfonctionnement ne se produisait pas. Avec la dernière version (j’utilise la version 1.9.5-preview20150319), on évite cette erreur en positionnant la variable d’environnement OPENSSL_CONF avec comme valeur le chemin d’accès au fichier openssl.cnf :

  • Si l’on exécute ses commandes depuis le shell Windows, cela se traduit donc par la commande :

set OPENSSL_CONF=C:\Program Files(x86)\Git\ssl\openssl.cnf

  • Si l’on exécute ses commandes depuis le shell Mingw32, il faut utiliser quelques séquences d’échappement pour parvenir au résultat souhaité :

export OPENSSL_CONF=/C/Program\ Files\ \(x86\)/Git/ssl/openssl.cnf

Gestion des variables d’environnement

Comme vu précédemment pour Linux et pour Mac, il nous faut positionner les variables d’environnement retournées par la commande docker-machine env ou docker-machine env <nom de la machine>.
Lorsqu’on utilise le shell Windows, la commande docker-machine env fournit les variables en les préfixant d’un « export », il nous faut donc explicitement positionner les valeurs affichées en remplaçant les commandes « export » par des « set ».
Lorsqu’on utilise le shell Mingw32, quoique la commande « eval » et les « export » résultant de l’appel à cette commande soit supportés, on ne peut pas comme sous Linux ou Mac se contenter d’exécuter la ligne eval eval « $(docker-machine env stephgoudockerfromwin) ». En effet, la commande docker-machine env expose la variable d’environnement  DOCKER_CERT_PATH au format « C:\Users\… ». Il nous faudra donc veiller à ce que la variable DOCKER_CERT_PATH soit au format « C/Users/stephgou/docker/machine/machine/…  ». Si l’on est amené à répéter fréquemment ces déclarations, une façon de procéder est alors de lancer avec la commandesource setenv.sh un fichier setenv.sh dans lequel on « adapte » ces variables d’environnement de la façon suivante :

export DOCKER_TLS_VERIFY=yes

export DOCKER_HOST=tcp:// stephgoudockerfromwin.cloudapp.net:2376

export DOCKER_CERT_PATH= C/Users/stephgou/.docker/machine/machines/stephgoudockerfromwin

Template Azure Resource Manager

« Azure Resource Manager » permet de déclarer une entité de gestion dans laquelle sont intégrés des regroupements de multiples ressources Azure de même type ou non. L’appartenance à un groupe de ressources est exclusive. Les ressources peuvent être multi-régions. Dans ce contexte, un groupe de ressources est un conteneur logique destiné à faciliter la gestion du cycle de vie d’un regroupement de multiples ressources, comme dans le cas d’une application construite autour d’un site Web, d’une base SQL Database et d’une machine virtuelle.

La solution proposée pour le déploiement et la configuration d’un groupe de ressources est déclarative afin de faciliter la configuration des ressources, de leurs dépendances, de leurs interconnexions, de leur contrôle d’accès, et de leur facturation. Elle se fonde sur l’utilisation d’un modèle baptisé « Azure Template » qui va permettre de garantir l’idempotence, simplifier l’orchestration, la gestion du cycle déploiement, ou le retour sur une version antérieure. Ces modèles sont implémentés en JSON et peuvent donc être gérés dans un contrôleur de code source.

Une librairie de templates de déploiement Azure est publiée sur GitHub. Parmi les modèles disponibles, le modèle « docker-containers-vm-resource-loops » permet de créer N machines virtuelles et déployer deux container docker [nginx et redis] sur chaque VM.

Le bouton « Deploy to Azure » permet de configurer les paramètres requis pour déployer ce modèle sur votre souscription.

Le template correspondant est fondé sur l’utilisation de l’extension Docker.

Docker et la virtualisation par container sous Windows

Support de Docker dans Windows Server

Docker a construit un écosystème avec une dynamique Open Source fondée sur les containers Linux. Microsoft a souhaité élargir la portée des scénarios de virtualisation de containers en offrant un support natif pour Docker pour Windows Server 10, comme l’a illustré la démonstration de Mark Russinovich (Keynote Microsoft Build jour 1 – minute 22)

docker-windows

L’implémentation du support de Docker dans Windows Server 10 a été réalisée en étroite collaboration avec la communauté Docker. Elle s’appuie sur les technologies de container incluses dans la nouvelle version de Windows Server (les containers Windows Server ainsi que les containers Hyper-V) et sera complétée par la mise à disposition de Nano Servers. Cette ouverture permettra d’enrichir le référentiel d’images Docker Hub. Dans un même ordre d’idée, les images du Docker Hub seront fédérées dans la MarketPlace du nouveau portail Azure. Le code du moteur Docker pour Windows devrait être publié en Open Source sur le référentiel GitHub de Docker.

Container Windows Server

Microsoft disposait déjà d’un retour d’expérience sur des projets connexes comme Microsoft App-V (à l’origine Softricity SoftGrid, une solution de virtualization d’application et de streaming d’application) ou le projet « Drawbridge » (Rethinking the Library OS from the Top Down : un prototype de Microsoft  Research ciblant une nouvelle forme de virtualisation pour la mise en sandbox d’application fondée sur le concept de picoprocess, une forme de container).
C’est donc une nouvelle génération de containers que Microsoft propose dans Windows Server 10 et c’est cette technologie qui a rendu possible le portage du moteur de Docker sur Windows. Le principe de fonctionnement de Docker avec ces containers Windows est rigoureusement symétrique à celui que l’on connaissait déjà pour Linux, comme l’illustre le schéma suivant.

 container-windows

Container Hyper-V

Les containers Hyper-V proposent une nouvelle option de déploiement de container, en offrant la pleine intégration multi-plateformes de Docker et en conservant un niveau d’isolation précédemment réservé aux machines physiques dédiées ou aux machines virtuelles. Ce mécanisme permettra de s’assurer que le code qui s’exécute dans un container reste isolé et ne peut pas influer sur le système d’exploitation hôte ou sur d’autres containers en cours d’exécution sur le même hôte.
Il sera possible d’utiliser les mêmes outils de développement et d’administration que ceux utilisés pour les containers Windows Server. En outre, les applications développées pour les containers Windows Server pourront être déployées dans des containers Hyper-V sans modification, ce qui offrira une agilité supplémentaire dans un environnement multi-plateformes, multi applications.

container-hyper-v

Nano Server

Nano Server est une installation minimaliste de Windows Server qui fournit uniquement les composants requis (pas de GUI, ni de support du 32 bits…). Cela se traduit par une forte réduction de la taille des images Windows Server (taille des VHDs réduite de 93%, 80% de reboot en moins…), une accélération du déploiement, une diminution de la consommation de bande passante réseau et améliore la disponibilité et la sécurité. Ce faible encombrement fait de Nano Server un complément particulièrement adapté à l’usage de containers Windows Server et Hyper-V, ainsi qu’à d’autres scénarios optimisés pour le Cloud.

Docker : une révolution ?

L’un des intérêts de Docker est la séparation des responsabilités entre développeurs et responsables des opérations. Docker offre aux développeurs la possibilité de transformer le mythe du « Write once, run anywhere » en réalité. En effet, cette solution peut apporter une réelle réduction du cycle de production logicielle pour les applications multi-tiers distribuées, notamment grâce à la portabilité et résolution des dépendances pour les architectures fondées sur des micro-services, et au partage d’images et layering sur des containers existants. Dans le même temps, Docker garantit aux responsables des opérations une cohérence et une simplification des modèles de déploiement, une plus grande automatisation avec un contrôle uniforme des opérations de démarrage, arrêt et log des services, ainsi qu’une meilleure utilisation des ressources.


La virtualisation par les containers permet dès aujourd’hui d’accroître la scalabilité des applications tout en augmentant leur densité de déploiement. Couplé avec le dynamisme de l’écosystème Docker, la flexibilité qu’offre le choix d’utiliser des containers Windows Server, Linux ou Hyper-V à demeure ou dans le Cloud (en particulier Azure), devrait se traduire par un impact très significatif dans le développement et la gestion opérationnelle des applications de demain. Il deviendra alors possible de gérer des applications composées sur la base d’images Linux et Windows depuis le même environnement Docker client, et ce, indépendamment de leur infrastructure d’hébergement.

Dans le prochain article, je vous présenterai différentes méthodes de provisioning d’un hôte Docker dans Azure.

Installation du moteur et du client Docker

La mise en place du moteur Docker requiert l’installation du moteur Docker, du client Docker et l’hébergement et le provisioning du serveur hôte exécutant le moteur Docker.

Installation du moteur Docker

Historiquement, le moteur de Docker a été conçu pour utiliser des fonctionnalités spécifiques aux containers LXC : il ne s’exécutait donc que dans un environnement Linux. Lors de la Build 2015 sera démontré le support de Docker par Windows 10 Server (nous reviendrons ultérieurement sur ce point).

Installation du moteur Docker sur Linux

Pour installer l’environnement Docker sur une machine Linux, on peut faire usage de l’ « advanced packaging tool » pour déclencher le déploiement avec la commande suivante (cf « Create a Docker Host on Microsoft Azure ») :

sudo apt-get install docker.io

Mais pour être sûr de disposer de la dernière version, il est préférable de la télécharger directement depuis le référentiel Docker.

wget -qO- https://get.docker.com/ | sh

Installation du moteur Docker sur d’autres environnements

Une des façons de disposer du moteur Docker sous Mac ou sous Windows est d’utiliser l’application appelée Boot2Docker pour installer une machine virtuelle hébergeant une distribution Linux très légère et exécutant le daemon de Docker. Par défaut cette machine virtuelle est hébergée sous VirtualBox.

Installation de BootDocker sur Mac

Docker met également à disposition un programme d’installation de Boot2Docker qui installe le client Docker. Il suffit de double-clicker sur le package Boot2Docker-x.x.x.pkg. L’installation ajoute Boot2Docker au dossier « Applications ». Les binaires « docker » et « boot2docker » sont copiés dans le répertoire  /usr/local/bin directory.

Installation de Boot2Docker sur Windows

Docker met à disposition un programme d’installation pour Windows qui installe le client Docker pour Windows, VirtualBox, Git for Windows (MSYS-git), l’ISO Linux boot2docker Linux et l’outil d’administration Boot2Docker. Le script de démarrage Boot2Docker permet alors de lancer un shell Unix déjà configuré pour gérer Docker au sein d’une machine virtuelle.

Dans le cas de Windows, il est également possible de déployer une image Boot2Docker au format Hyper-V, notamment en utilisant DockerMachine, un outil Docker dont je vous reparlerai prochainement.

Installation du client Docker

Le client Docker est présent sur les machines Linux sur lesquelles l’environnement Docker est installé. Mais le client qui interagit avec le moteur de Docker n’est pas fondamentalement dépendant de Linux. Son rôle est uniquement de contrôler le moteur pour créer des images, les publier, puis les exécuter et gérer les containers correspondant à l’instanciation de ces images. Rien n’empêche donc de le mettre à disposition des utilisateurs d’autres environnements (comme Mac ou Windows) afin qu’ils puissent utiliser l’interface Docker standard pour manipuler containers et images sur leurs environnements de développement Linux.

Installation du client Docker sur Mac

La documentation officielle pour l’installation de Docker sur Mac propose d’installer Boot2Docker (et d’exécuter le client Docker au sein de la VM Boot2Docker. Ce n’est pas la seule option). Il est en effet possible de ne mettre à disposition que le client Docker. Pour se faire, on peut s’appuyer sur l’utilitaire Homebrew, un fort efficace package manager pour OS X. L’installation d’« Homebrew » peut se faire avec le script suivant :

ruby -e « $(curl -fsSL-https://raw.githubusercontent.com/Homebrew/install/master/install) »

D’autres mécanismes d’installation d’« Homebrew » sont proposés sur Github.

L’installation du client Docker sur Mac peut alors être réalisée par l’appel des commandes suivantes :

brew update

brew search docker

brew Install docker

Installation du client Docker sur Windows

Le code source du client Windows pour Docker publié sur GitHub est fourni avec différents scripts de pré ou post-compilation qui supposent un environnement de type Linux et la présence du langage de programmation Open Source baptisé « Go ». Le langage Go propose un programme d’installation MSI disponible pour Windows 32 et 64 bits.

Restait donc à lever la difficulté liée aux scripts précédemment évoqués. Plutôt que de porter l’ensemble de ces scripts pour une exécution Windows, l’approche retenue par Ahmet Alp Balkan a consisté à réaliser une opération dite de « cross-compilation » sur la base d’une « pull request » GitHub, en exécutant ces scripts dans un sous-système Unix de Windows (SUA : Subsystem for Unix-based Application). En général, les opérations de « cross-compilation » sous Windows se fondent sur l’utilisation des projets Open Source comme Mingw64 ou Cygwin.

Dans notre contexte, « Git for Windows » propose un shell Unix suffisant pour réaliser cette compilation avec l’aide de l’environnement « Go ».

Pour obtenir une version à jour du client Docker pour Windows, on peut donc de lancer le script suivant depuis le shell « Git Bash » :

git clone –depth 1 https://github.com/docker/docker.git/c/users/stephgou/src/github.com/docker/docker

cd /c/users/stephgou/src/github.com/docker/docker

exportGOPATH=/c/users/stephgou:/c/users/stephgou/src/github.com/docker/docker/vendor

export DOCKER_CLIENTONLY=1

chmod +x hack/make/.go-autogen && hack/make/.go-autogen

cd docker

go build

Une approche similaire à celle de l’installation du client Docker sur Mac existe également sur Windows avec PowerShell OneGet. Il s’agit d’une technologie dont l’objectif est de simplifier considérablement la découverte et l’installation de logiciel sur les machines Windows.
Avec OneGet, il est possible de :
• Gérer une liste de dépôts de logiciels dans lequel les packages logiciels peuvent être recherchés, acquis et installés
• Installer et désinstaller silencieusement des packages d’un ou plusieurs référentiels avec une seule commande PowerShell
OneGet fonctionne avec le référentiel communautaire « Chocolatey » qui recense plus de 1 700 logiciels uniques. La prise en charge de dépôts supplémentaires sera proposée dans des versions ultérieures.
Pour l’utiliser, il suffit d’importer le module OneGet dans PowerShell.

Import-Module -Name OneGet

On peut alors faire usage des commandes OneGet suivantes pour installer le client Docker.

Dans le prochain article nous verrons les multiples solutions proposes pour le provisioning de serveurs Hôte Docker sur la plateforme Azure.

Avec Docker, le Cloud Computing est-il sur le point de franchir un nouveau cap ?

a virtualisation des machines est le fondement du Cloud Computing tel que nous le connaissons aujourd’hui. Pourtant, il semble que les grands acteurs du Cloud public s’intéressent de plus en plus aux mécanismes de virtualisation à base de containers, ainsi qu’aux solutions permettant de les gérer plus les efficacement. Parmi celles-ci, le projet Open Source Docker semble recueillir la plus grande attention.
J’ai récemment eu l’occasion de participer à un projet Azure qui m’a offert l’occasion de me pencher sur le sujet. Voici donc une série d’articles qui je l’espère vous permettra d’accélérer votre découverte de cet environnement.

Docker : les fondamentaux

Virtualisation par les containers LXC

LXC est une technologie de virtualisation que l’on peut mettre en œuvre sur de multiples distributions Linux. Le principe consiste à reconstruire la vue qu’un processus a de son environnement d’exécution (et de lui donner l’illusion qu’il est le seul à s’exécuter sur la machine, avec une arborescence de fichiers limitée par le périmètre du container). Les containers sont isolés mais partagent l’OS et le cas échéant certaines librairies. Il en résulte un déploiement et un redémarrage plus rapide, moins d’overhead, ainsi qu’une grande facilité de migration.

image

Les containers Docker : exécution des applications

A l’origine, Docker se fonde sur les mécanismes de container LXC. Si le container d’application offre de multiples analogies avec le container qui a révolutionné le transfert maritime (capacité à empaqueter tout type d’application et de ses dépendances, exécution sur tout type d’environnement, isolation des dépendances, facilité de déplacement), Docker s’inspire directement  de son homologue portuaire.
Le rôle de Docker est en effet de faciliter le chargement et le déchargement de ces containers et de contribuer à la construction d’un écosystème qui va pouvoir tirer le meilleur parti de ce nouveau mode d’échange. Docker étend le format LXC, afin de permettre d’empaqueter une application et ses dépendances au sein d’un container. La contribution la plus significative de Docker se matérialise donc dans les moyens qu’il met à disposition pour définir comment les containers et leur contenu est défini puis distribué. Grâce à l’automatisation de la manipulation des containers, Docker offre la possibilité de déployer des applications avec des caractéristiques d’isolement similaires à celles d’applications s’exécutant dans des machines virtuelles tout en évitant les contraintes liées au chargement en mémoire du système d’exploitation et de ses services complémentaires.

Un container Docker se présente comme un répertoire contenant les pré-requis pour l’exécution d’une application. Il est constitué d’un système d’exploitation, des fichiers ajoutés par l’utilisateur et des métadonnées. Un container peut être lancé, arrêté, interrogé pour connaitre son statut, supervisé, déplacé, supprimé. Chaque container est isolé des autres containers qui peuvent s’exécuter simultanément sur le même système.
Ces containers sont créés à partir d’images Docker.

Les images Docker : génération des modèles d’applications

Docker offre la possibilité pour les développeurs de créer, personnaliser et composer des images d’application accessibles en lecture seule qui pourront être ultérieurement déployée sur de multiples hôtes Docker. Docker offre les commandes permettant de construire de nouvelles images application préconfigurée (ce qui inclut l’ensemble de ces dépendances logicielles) ou de mettre à jour les images existantes.
Par exemple, Docker permet très simplement de mettre à disposition un modèle d’application Web Node.js offrant des fonctions de realtime grâce à Socket.io et interagissant avec une base MongoDB.


Chaque image commence par une image de base, par exemple, Ubuntu ou plus « avancée » comme nodejs installée sur Ubuntu. Chaque image est ensuite constituée d’une série de couches baptisées « layers ». Docker utilise des regroupement de systèmes de fichiers distincts baptisées « branches » pour combiner ces couches en une seule image donnant une vue cohérente de l’ensemble. Lorsque l’on modifie une image de Docker, par exemple, pour mettre à jour une application vers une nouvelle version, un nouveau « layer » est généré. Ce processus de mise à jour est extrêmement efficace et se traduit par une distribution simple et rapide. En effet, seul ce nouveau « layer » sera distribué lors d’une prochaine mise à jour de l’image, au lieu d’un remplacement intégral de l’image comme le nécessiterait une machine virtuelle.
L’image indique à Docker ce que le container contient, quel processus s’exécute lorsque le container est lancé et une variété d’autres données de configuration. Lors de l’exécution de Docker le container ajoute une couche de lecture / écriture sur le dessus de l’image.

L’image de base fournit l’environnement minimal pour l’OS (système de fichiers, bibliothèques et autres….). Puis les « layers » sont ajoutés pour les packages d’application ou les informations de configuration. Chaque « layer » est identifié de manière unique et stocké sous forme d’une archive « tar » avec le contenu et des métadonnées qui indiquent, entre autres, la liste des « layers » sous-jacents… Lorsqu’une « image » est stockée dans le référentiel, elle reçoit un nom et éventuellement une étiquette (« tag ») afin qu’elle puisse être récupérée sur demande.
Les images de docker sont donc construites à partir d’images de base à l’aide d’un jeu d’instructions (lancer l’installation d’un framework, ajouter un module, ajouter des fichiers à l’application, lancer un processus) permettant de décrire l’image cible, chaque instruction se traduisant par un nouveau « layer » sur cette image. Ces instructions peuvent être exécutées manuellement ou enregistrées dans un fichier Dockerfile, qui sera le point d’entrée de la commande « build » de Docker pour générer l’image finale. Docker impressionne par la facilité avec laquelle il permet de créer un environnement d’exécution pour une application.
Docker permet alors de télécharger ces images vers des référentiels.

Les référentiels Docker : la publication et distribution des images

Les référentiels d’images peuvent être privés ou publics. Ils permettent de stocker les images, de les nommer et de les mettre à disposition pour un téléchargement afin qu’elles puissent être réutilisées. Parce que l’application a été testée dans un container, le développeur est assuré de la présence des prérequis de configuration qui en garantissent l’exécution, indépendamment des autres services qui pourraient cohabiter sur le même hôte.
Le référentiel public, le Docker Hub offre un très large éventail de services et d’images existantes :
• La « registry », qui est un système de stockage pour les images de containers
• Le « public index », qui permet de référencer les images publiques avec un système d’attribution d’étoiles pour le « ranking »
• « Automated builds », qui permet de lier un dépôt de code GitHub ou Bitbucket, et créer automatiquement des images Docker à chaque commit, afin que ces images soient toujours à jour par rapport au code.
Le référentiel Docker Hub est également exposé via une API REST.

Topologie de l’environnement

L’environnement Docker est fondé sur une architecture client-serveur. Il n’y a pas d’interaction directe avec le serveur, toutes les requêtes sont à l’initiative du client. Le client Docker communique avec un service Docker, le « Docker Engine » qui assure la génération et la publication des images ainsi que leur exécution au sein de containers. Les composants correspondants (le client Docker et le démon à l’écoute de ses requêtes) communiquent via des sockets ou via une API REST. Toutes les fonctions de Docker sont donc exposées via cette API, ou via un outil en ligne de commande. Le « Docker Engine »,  peut être installé sur un serveur Linux et le transformer ainsi en hôte Docker.


image
Dans le prochain article nous étudierons les multiples façons de mettre en place cet environnement.