Tous les articles par Steve

Mise en place d’une plateforme d’hébergement web automatisée basée sur Docker, pour ENGIE LAB CRIGEN

ENGIE LAB CRIGEN a récemment été accompagné par Microsoft et Docker lors d’un hackfest ayant pour objectif d’améliorer la manière dont ils mettent à disposition des applications dans l’entreprise.

Les principaux axes de travail abordés lors de ce POC ont été la mise en place des bonnes pratiques DevOps pour déployer en continu une application composée de services Node.js, d’une base de données MongoDb, le tout sur la plateforme Microsoft Azure à l’aide de conteneurs Docker.

Voilà les différentes pratiques DevOps et technologies mises en place lors de ce POC:

  • Continuous Integration
  • Continuous Deployment
  • Infrastructure as Code
  • Azure Container Service
  • Docker Datacenter
  • GitLab
  • Visual Studio Team Services

Le hackfest s’est déroulé en deux phases : une première permettant l’établissement d’un Value Stream Map (VSM), afin de mettre en évidence la manière dont ENGIE LAB CRIGEN met à disposition l’application à ses utilisateurs et les points d’améliorations qui sont possibles. La seconde phase a consisté à prototyper la plateforme d’hébergement basée sur Docker, en y incluant directement les bonnes pratiques DevOps mises en évidence lors de la première phase.

Voilà la liste des différentes personnes ayant travaillé sur ce sujet :

ENGIE LAB CRIGEN :

  • Delphine Leblanc, Chef de projet
  • Kévin Mencé, Chef de projet IT
  • Eric Sablonière, Activité Informatique
  • Jean-François Philippe, Ingénieur de recherche
  • Alain Chenuaud, Architecte Infrastructure
  • Thomas Roueche, Chef de projet
  • Nabil Debbou, Responsable DevOps
  • Didier Morhain, Expert Cloud
  • Cao Truong Hoang, Ingénieur
  • Gregory Chatelain, Consultant

Docker :

  • Stéphane Woillez (@swoillez)

Microsoft :

  • Julien Corioland, Technical Evangelist (@jcorioland)
  • Benjamin Guinebertière, Technical Evangelist (@benjguin)
  • Pascal Sauliere, Technical Evangelist (@psauliere)
  • Benoît Touzé, Consultant MCS
  • Pascal Veque, Cloud Solution Architect

Présentation du client

ENGIN LAB CRIGEN est le centre de recherche et d’expertise opérationnelle du Groupe ENGIE dédié aux métiers du gaz, aux énergies nouvelles et aux technologies émergentes. Situé en région parisienne, à la Plaine Saint-Denis et Alfortville, il regroupe 350 collaborateurs.

Contexte et problématiques

ENGIE LAB CRIGEN se charge d’héberger des applications développées dans le cadre de projets de recherche, reponsant sur des stacks LAMP (Linux, Apache, PHP, MySQL), Node.js + MongoDb et autres technologies issues du monde open source.

Le principal objectif fixé dans le cadre des différents ateliers effectués avec Microsoft était de pouvoir travailler sur la mise en place de cette plateforme.

Pour réaliser cet objectif, l’accompagnement de Microsoft s’est déroulé en deux phases :

  • Un atelier de deux jours pour réaliser un Value Stream Mapping (VSM) en se basant sur une application hébergée existante d’ENGIE LAB CRIGEN afin de comprendre comment ils travaillent, gèrent le cycle de vie de l’application et ainsi mettre en œuvre les pratiques DevOps à conserver, améliorer et ajouter dans la future plateforme
  • Un atelier (hackfest) de 3 jours, pour prototyper la plateforme et mettre en place des processus automatisés d’intégration continue et de déploiement continu.

Atelier 1 : Value Stream Mapping

Architecture

L’application qui a été utilisée pour réaliser le VSM est composée des services suivants :

  • Une API développée en Node.js
  • Un site web d’administration développé en Node.js
  • Un site web “front” développé en Node.js
  • Une base de données MongoDb

Il y a également une application mobile qui consomme l’API mais qui n’a pas été traitée dans le cadre de l’atelier.

Vue globale de l'application

Value Stream Map

Afin de mettre en évidence les points d’améliorations possibles dans la manière de gérer le cycle de vie complet de l’application, nous avons donc réalisé une Value Stream Map :

Version finale du VSM

Cette phase extrêmement importante permet de faire en sorte que tous les acteurs autour de la table prennent le temps d’échanger sur la manière dont ils travaillent, dans le but de cartographier les différents processus et mettre en évidence des points d’amélioration possibles.

En effet, l’un des premiers retours fait par le client en séance était de dire qu’avant même de voir les résultats de l’exercice, cela avait au moins permis de réunir tous les acteurs travaillant sur le projet dans une même salle de réunion pendant deux jours. Certains d’entres-eux ne travaillant pas sur les mêmes sites.

Le fait de réunir des profils très différents à discuter ensemble de comment ils travaillent sur le projet permet de comprendre les enjeux et objectifs de chacun, mais aussi de mettre en évidence des points de défaut à améliorer.

Dans le cas présent, nous avons notamment identifié qu’un certains nombre d’opérations étaient réalisées manuellement ou déclenchées par des envois d’emails, ce qui est potentiellement source d’erreurs et de latence dans le processus de déploiement en continu. Nous avons également mis en évidence que l’ajout de certaines pratiques DevOps permettraient d’automatiser un certains nombre de ces tâches :

  • De l’infrastructure as code, pour la mise en place des environnements (Azure Container Service pour la recette et Docker Datacenter pour la production)
  • De la configuration as code, à base de Dockerfile et Docker Compose pour définir les stacks applicatives à déployer sur la nouvelle plateforme
  • De l’intégration continue, pour la création des images Docker et le push de celles-ci dans une Docker Trusted Registry
  • Du Release Management pour la fluidification du déploiement en recette, et en production, avec certaines étapes d’approbation entre les différents environnements

Dans un second temps, nous avons également défini la stratégie de branches à appliquer et la manière dont une nouvelle release devrait se faire sur la nouvelle plateforme :

Stratégie de branches à mettre en place

En résumé, l’idée ici est de dire :

  • Une branche de développement pour le travail en cours sur le sprint courant, avec éventuellement des features branches par développeur, si nécessaire
  • Une branche d’intégration, avec une opération de merge manuelle faite par le chef de projet pour être capable de déployer l’application en l’état sur un environnement d’intégration, dans les cas où c’est nécessaire pour le projet
  • Une branche master, sur laquelle on merge la branche de développement au travers d’une pull request, et donc d’une approbation (avec également la possibilité de créer des branches depuis master, pour appliquer un hotfix, par exemple)

Une fois la PR acceptée sur la branche master, une release est déclenchée avec un déploiement automatique sur l’environnement de recette, puis après approbation, un déploiement sur la production.

La dernière étape de cet atelier était de fixer la liste des environnements et technologies à utiliser lors du hackfest, à savoir :

Les développeurs utilisant déjà GitLab, le choix a été fait de conserver cet outil qui est totalement interopérable avec les autres. Certaines équipes utilisent déjà Visual Studio Team Services, aussi le choix de cet outil a été fait pour cette application, dans le souci de prototyper son usage pour cette équipe. Enfin,

ENGIE LAB CRIGEN souhaitait avoir deux environnements dans le Cloud, un pour la recette et un pour la production. En production, ils souhaitent pouvoir bénéficier du support de Docker (CS Docker Engine) qui est fourni avec les licences Docker Datacenter. Pour la recette en revanche, pas besoin de support, nous avons donc opté pour Azure Container Service qui permet de déployer simplement et rapidement la version open source de l’orchestrateur Docker Swarm.

Atelier 2 : Hackfest

La deuxième phase de l’atelier d’accompagnement d’ENGIE LAB CRIGEN a été la réalisation d’un hackfest de 3 jours pendant lequel nous avons prototypé la mise en place de la plateforme d’hébergement d’application web basée sur des conteneurs Docker, en y ajoutant des pratiques DevOps comme de l’intégration en continue, de l’infrastructure as code et du release management. Le but étant de permettre à ENGIE LAB CRIGEN de pouvoir déployer n’importe quelle application en continue !

Cet atelier a été divisé en 3 grandes étapes :

  • la mise en place de l’infrastructure des environnements de recette et de production, sur lequel les profils opérationnels ont travaillé
  • le packaging de l’application existante afin de pouvoir l’exécuter dans des conteneurs Docker, sur lesquel les profils plutôt développeurs ont travaillé
  • et enfin la mise en place du pipeline complet de CI/CD à l’aide de VSTS, avec à la fois des développeurs et opérationnels.

Afin d’être sûr de toujours garder le bon cap, nous avions des points de synchronisation régulier (après maximum 1/2 journée) pour toujours bien valider que toutes les briques s’assemblaient entre elles. Tout le monde était dans la même salle, ce qui facilite clairement la collaboration.

Travail sur la mise en place de la plateforme

Environnement de recette

Automatisation de l’environnement de recette

L’environnement de recette est hébergé dans Microsoft Azure dans un cluster Docker Swarm mis en œuvre par Azure Container Service (ACS).

Schéma de principe d’un cluster ACS en mode Docker Swarm :

ACS en mode Docker Swarm

Le principe est d’utiliser la ligne de commande Azure Xplat CLI pour déployer un nouveau cluster ACS. Cela se fait en une seule commande azure acs create, avec les paramètres appropriés et après avoir créé un groupe de ressources pour accueillir le cluster.

1. Préparation

Pour tester les commandes et le script dans Ubuntu ou dans Bash sur Ubuntu sur Windows 10 (Windows Subsystem for Linux), l’installation d’Azure CLI se fait de cette manière :

sudo apt-get install nodejs-legacy
sudo apt-get install npm
sudo npm install -g azure-cli

Pour que l’installation de l’environnement de recette soit automatisée dans un script, il faut que l’authentification dans Azure se fasse sans interaction. Pour ce faire, il faut utiliser un Service Principal dans Azure AD, ainsi que documenté ici.

Création du Service Principal et assignation des permissions sur l’abonnement Azure :

azure ad sp create -n <service principal name> -p <password> --home-page <homepage> --identifier-uris <uris>

azure role assignment create --objectId <Service Principal Object ID> -o Contributor -c /subscriptions/<Subscription ID>/

Les paramètres homepage et uris sont obligatoires, doivent être uniques, et vous seront utiles pour gérer le SPN plus tard, si besoin. Exemple :

$ azure ad sp create -n demosp1 -p Passw0rd! --home-page https://demo.com --identifier-uris https://demo.com/demo
info:    Executing command ad sp create
+ Creating application demosp1                                                 
+ Creating service principal for application 8dd44fe4-0290-4a51-b652-b8473015528d
data:    Object Id:               02b739e5-d5e7-43aa-b296-176f9b326b71
data:    Display Name:            demosp1
data:    Service Principal Names:
data:                             8dd44fe4-0290-4a51-b652-b8473015528d
data:                             https://demo.com/demo
info:    ad sp create command OK

$ azure role assignment create --objectId 02b739e5-d5e7-43aa-b296-176f9b326b71 -o Contributor -c /subscriptions/ca8358b6-1ae3-4ccd-860e-82c9dc9a9539/
info:    Executing command role assignment create
(...)
info:    role assignment create command OK

Une fois le Service Principal créé et autorisé comme contributeur sur l’abonnement Azure, il faut conserver ces trois éléments :

  • l’App ID du Service Principal
  • le mot de passe du Service Principal
  • le Tenant ID de l’abonnement Azure

Pour afficher l’App ID du Service Principal et le Tenant ID de l’abonnement :

azure ad sp show -c <Service Principal Name> --json
azure account show

Dans un script automatisé, il faudra utiliser cette commande pour l’authentification :

azure login -u "<App ID>" -p "<password>" --service-principal --tenant "<Tenant ID>"

2. Fichier de paramètres ACS

Le déploiement automatique d’un cluster ACS utilise un fichier de paramètres JSON. Ce fichier est généré par le script proposé avec les paramètres fournis.

Pour information, un fichier de paramètres ACS est créé, vide, par cette commande :

azure acs config create --parameter-file acsparam.json 

Complété avec des paramètres d’exemple, il ressemble à cet exemple (la clé publique SSH a été supprimée de l’exemple) :

{ 
  "provisioningState": "", 
  "orchestratorProfile": { 
    "orchestratorType": "Swarm" 
  }, 
  "masterProfile": { 
    "count": 1, 
    "dnsPrefix": "acsdemomaster", 
    "fqdn": "acsdemomaster.westeurope.cloudapp.azure.com" 
  }, 
  "agentPoolProfiles": [ 
    { 
      "name": "acsdemoagent", 
      "count": 2, 
      "vmSize": "Standard_D2_v2", 
      "dnsPrefix": "acsdemoagent", 
      "fqdn": "acsdemoagent.westeurope.cloudapp.azure.com" 
    } 
  ], 
  "linuxProfile": { 
    "adminUsername": "acsadmin", 
    "ssh": { 
      "publicKeys": [ 
        { 
          "keyData": "(...)"
        } 
      ] 
    } 
  }, 
  "diagnosticsProfile": { 
    "vmDiagnostics": { 
      "enabled": null, 
      "storageUri": "" 
    } 
  }, 
  "id": null, 
  "name": null, 
  "type": null, 
  "location": "westeurope", 
  "tags": {} 
} 

Remarquons que les noms DNS ne doivent pas déjà exister.

3. Script de déploiement automatique

Le script automatisé est joint : recette.sh.

Il effectue les tâches suivantes :

  • Récupération des paramètres (à finaliser)
  • Génération du fichier de paramètres ACS : /tmp/acsparam.json
  • Authentification Azure avec le Service Principal
  • Création du groupe de ressources
  • Déploiement du cluster ACS
  • Mise à jour de l’exécutable docker-compose avec la version 1.8.1 sur le master 0

4. Test et suppression de l’environnement

Une fois le cluster déployé, on peut se connecter en SSH sur un master :

ssh -p 2200 -i <private key file> acsadmin@<master fqdn> 

Pour connecter le client Docker au Swarm :

export DOCKER_HOST=:2375 

En cas de besoin, pour supprimer entièrement l’environnement, il suffit de supprimer le groupe de ressources :

azure group delete RG_acsdemo

Environnement de production

Contrairement à l’environnement de recette, l’environnement de production n’est pas destiné à être redéployé / cloné régulièrement. Les applications y sont bien déployées en continue, par contre le choix a été fait de ne pas recréer l’environnement à chaque déploiement d’une nouvelle version d’un service, pour la simple et bonne raison que cet environnement est destiné à être mutualisée entre plusieurs équipes.

L’accent a donc été mis sur le déploiement d’un environnement répondant aux exigences de la production, plutôt que sur l’automatisation de ce déploiement.

Le choix s’est porté sur Docker Datacenter dans Azure. Docker Datacenter est l’environement d’entreprise proposé par Docker, composé des éléments suivants :

  • Docker Engine : runtime, orchestration, réseau, volumes, avec support
  • Docker Trusted Registry (DTR) : gestion et distribution sécurisées des images
  • Docker Universal Control Plane (UCP) : portail de gestion du cluster

Docker Datacenter est disponible directement dans le Marketplace d’Azure, avec support conjoint de Microsoft et de Docker.

Docker Datacenter

Voici l’architecture que nous avons mis en place dans Azure :

Docker Datacenter

Nous avons regroupé toute les ressources au sein d’un groupe de ressources Microsoft Azure :

Docker Datacenter

Les 3 grandes composantes sont : les noeuds UCP, DTR et les agents, créés dans des groupes de haute disponibilité différents et derrière des load balancers différents.

Toutes les machines virtuelles exécutent des Ubuntu 14.04.

Une fois l’infrastructure déployée, nous avons suivi la procédure d’installation disponible sur le site de Docker pour l’installation et la configuration de Docker Datacenter.

Travail sur le packaging de l’application avec Docker

Le travail de cette partie de l’équipe consiste à partir des sources de l’application. L’application a des sources dans des repos git différents :

  • api. C’est l’API elle-même, ainsi que la base MongoDB qu’elle utilise.
  • vitrine.
  • supervision.

Il s’agit de trois applicatoins en Node.js.

première approche: un repo pour déployer les sources

Notre première approche a été de créer un repo git qui serait destiné à contenir les outils pour packager le code en Docker et ainsi l’envoyer vers les autres environnements (recette, production).

L’idée était de ne pas toucher aux repos existant et d’uniquement en ajouter pour le déploiement.

Nous n’avons finalement pas suivi cette piste car nous aurions eu des dépendances entre les fichiers Dockerfile de ce repo et les fichiers sources eux-mêmes. Par exemple, cela aurait consisté à copier dans un même répertoire, typiquement sur une VM de build, des fichiers venant du repo api et des fichiers venant du repo de packaging. La gestion du cycle de vie des sources aurait été complexe.

De plus, dans une démarche DevOps, il semble nécessaire que les Dev créent eux-mêmes les conteneurs Docker de façon à avoir une idée plus précise de ce dont les Ops disposeront.

Il sera à nouveau question de cela plus bas, à propos de la livraison de MongoDB.

seconde approche

Nous avons donc plutôt opté pour une approche consistant à mettre les fichiers Dockerfile dans les mêmes repos que les sources qu’ils embarquent.

Les fichiers Dockerfile peuvent embarquer des fichiers via la commande ADD. Ces fichiers doivent nécessairement se trouver sous le Dockerfile dans la hiérarchie des répertoires. C’est pourquoi, le fichier Dockerfile principal se trouve à la racine du repo git.

Dans le cadre du repo api, nous avions besoin de deux images Docker et non d’une seule:

  • une image Docker pour packager api lui-même
  • une image Docker pour packager la base MongoDB (nous y reviendrons plus en détail)

Pour cela, nous avons choisi de mettre les deux fichiers Dockerfile à la racine, avec des noms différents évidemment. Le fichier principal s’appelle Dockerfile et celui pour les outils de déploiement de la base de données Dockerfile-tools.

Ainsi, depuis chacun des fichiers, on peut ajouter tout ou partie des fichiers du repo. Par exemple, dans le cas d’api, on inclut tous les fichiers dans un dossier de travail du conteneur appelé /data par les deux commandes suivantes :

WORKDIR /data
ADD . .

Le contenu complet du fichier Dockerfile du repo api est le suivant:

# obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-api
#
# VERSION   0.2

FROM obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-nodejs:0.1

WORKDIR /data
ADD . .
RUN chmod a+x containerimage/init.sh
RUN npm install

ENTRYPOINT ["/bin/sh", "-c"]
CMD ["/data/containerimage/init.sh", ""]

NB: obfuscated* correspondent à des noms volontairement masqués dans cette documentation.

On remarque que l’image d’api hérite d’une image obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-nodejs:0.1 qui est d’ailleurs la même pourvitrine et pour supervision.

C’est pourquoi nous avons aussi un repo base-container-images pour cette image et d’autres; en l’occurrence mongodb-base et mongodb-replicaset. Dans ce repo base-container-images, on a un dossier par image Docker visée avec chacun son fichier Dockerfile:

Le nom des images Docker est du type obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-nodejs:0.1 et non pas crigen/obfuscated10-nodejs pour indiquer que l’image peut être téléchargée depuis la registry obfuscated1.westeurope.cloudapp.azure.com et avoir pour numéro de version 0.1 ici.

Lors de nos tests, l’équipe de packaging Docker n’avait pas accès à cette registry, de façon à vérifier que nous pouvions travailler sur une VM de build ou dev sans problème.

Ce fut le cas. Ce nom contenant la registry fonctionne aussi en local.

La gestion des numéros de versions des images Docker est dans les sources, plus précisément dans les fichiers Dockerfile pour que le développeur ne dépende pas d’un processus de build en aval pour avancer.

Autrement dit, le numéro de version des images Docker est déterministe à partir des sources.

Le processus de build peut le récupérer à partir des commentaires à l’intérieur du Dockerfile.

Il en est de même pour le nom des images Docker.

Déploiement de la base de données MongoDB

La base de données est toujours un cas spécial quand il s’agit de déploiement car, par définition, elle contient des données. Ces données ont un cycle de vie différent de l’application. Ce n’est pas parce qu’on passe de la version n à la version n+1 de l’application que les données changent.

Nous avons évoqué différentes hypothèses, regardé la façon dont le processus de livraison était documenté par les développeurs (il s’agit d’un document PDF qui décrit les opérations à effectuer suivant les cas rencontrés). Nous en avons déduit que la meilleure option était de fournir aux ops des outils permettant d’exécuter les commandes nécessaires sur la base pour la créer, restaurer ses données, modifier le schéma etc. en fonction du contexte.

Ce que Docker apporte dans ce cas est le fait que les développeurs qui rédigent la documentation, et les ops qui sont dans un environnement contraint, peuvent ici avoir accès aux mêmes environnements. En effet, le développeur peut packager dans un conteneur d’outils, tous les scripts, outils et autres binaires qui sont nécessaires. De plus, le développeur peut sur son environnement de développement tester dans les mêmes conditions que ce qu’auront les ops.

La seule différence est que les conteneurs Docker en dev s’éxécutent sur un seul hôte (une seule VM), alors que les conteneurs des ops sont a priori plutôt exécutés sur un cluster de plusieurs hosts. Cette différence est gérée par les moteurs Docker et sont donc assez transparentes une fois que tout est en place.

Voici le contenu du fichier Dockerfile-tools:

# obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-api-tools
#
# VERSION   0.1

FROM obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-api:0.2

RUN apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv EA312927 && \
    echo "deb http://repo.mongodb.org/apt/debian wheezy/mongodb-org/3.2 main" | tee /etc/apt/sources.list.d/mongodb-org-3.2.list && \
    apt-get update && \
    apt-get install -y \ 
        mongodb-org-shell \
        mongodb-org-tools 

RUN chmod a+x containerimage-tools/*.sh

ENTRYPOINT ["init"]

Ici, il n’y a pas de commande ADD parce qu’on hérite de l’image obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-api:0.2 qui a elle-même inclus tout le repo api où se trouve aussi Dockerfile-tools. Cela inclut donc par exemple les fichiers containerimage-tools/*.sh sur lesquels on fait un chmod.

On aurait tout aussi bien pu opter pour une stratégie plus fine, avec des ADD différents dans les deux fichiers Dockerfile d’api.

On trouvera plus bas un exemple d’utilisation du conteneur généré par Dockerfile-tools, pour restaurer la base MongoDB.

Composition des conteneurs

Reste à composer tout cela dans une composition Docker. Le fichier docker-compose.yml et d’autres fichiers annexes se trouvent dans un 5ème repo: compose-containers.

Suivant qu’on est en dev/build, recette, production ou autre environnement, certains éléments de contexte changent. Il a été choisi d’avoir ces éléments de contexte sous forme de variables d’environnement.

Chaque environnement est responsable du positionnement des valeurs des variables. Les sources, dans l’environnement de dev, et les repos git, fournissent les variables nécessaires et des exemples de valeurs que sont celles de développement.

Exemples, dans le repo compose-containers, avec le fichier set_environment_variables.sh:

export DOCKER_NETWORK_TYPE=bridge

et le fichier docker-compose.env référencé par docker-compose.yml:

MONGODB_HOSTS_PORTS=mongodb:27017,slave1:27017,slave2:27017
MONGODB_USER=obfuscated3
MONGODB_PASSWORD=obfuscated4
MONGODB_DB=crigen
MONGODB_DEBUG=true

En ce qui concerne la montée en charge, il nous a semblé prudent de se limiter à une montée en charge statique au niveau du fichier docker-compose.yml, plutôt qu’avec des conteneurs génériques sur lesquels on demande a posteriori une montée en charge. Les raisons principales sont les suivantes:

  • une montée en charge dynamique n’était pas prioritaire dans le cadre du projet
  • une montée en charge statique (ex: vitrine1, vitrine2) permet
    • une résolution de nom simple, sans mise en place de services tels que CONSUL,
    • de connaître le nombre de noeuds à indiquer dans les chaînes de connexion MongoDB par exemple,
  • au moment du hackfest, Docker ne permet pas un docker-compose en indiquant directement le nombre de conteneurs nécessaires pour un service. Il faut le faire après ledocker-compose up.
  • il n’est pas très compliqué d’ajouter statiquement des conteneurs dans le docker-compose.yml par copie de blocs et changement des numéros de ports publics.

Au final, le fichier docker-compose.yml a le contenu suivant:

version: '2'
services:
  vitrine1:
    image: obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-vitrine:0.1
    container_name: vitrine1
    ports: 
      - "50001:3001"
    networks:
      - obfuscated10net
  vitrine2:
    image: obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-vitrine:0.1
    container_name: vitrine2
    ports: 
      - "50002:3001"
    networks:
      - obfuscated10net
  api1:
    image: obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-api:0.2
    container_name: api1
    ports: 
      - "50011:8894"
    networks:
      - obfuscated10net
    env_file:
      - docker-compose.env
  api2:
    image: obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-api:0.2
    container_name: api2
    ports: 
      - "50012:8894"
    networks:
      - obfuscated10net
    env_file:
      - docker-compose.env
  supervision1:
    image: obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-supervision:0.1
    container_name: supervision1
    ports: 
      - "50021:3001"
    networks:
      - obfuscated10net
    env_file:
      - docker-compose.env
  supervision2:
    image: obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-supervision:0.1
    container_name: supervision2
    ports: 
      - "50022:3001"
    networks:
      - obfuscated10net
    env_file:
      - docker-compose.env
  mongodb-master:
    image: obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-mongodb-replicaset:0.1
    networks:
      - obfuscated10net
    environment:
      ROLE: "master"
      SLAVE1: "slave1"
      SLAVE2: "slave2"
    hostname: mongodb
    container_name: mongodb
  mongodb-slave1:
    image: obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-mongodb-replicaset:0.1
    networks:
      - obfuscated10net
    hostname: slave1
    container_name: slave1
    depends_on:
      - mongodb-master
  mongodb-slave2:
    image: obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-mongodb-replicaset:0.1
    networks:
      - obfuscated10net
    hostname: slave2
    container_name: slave2
    depends_on:
      - mongodb-master
  api-tools:
    image: obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-api-tools:0.1
    container_name: api-tools
    networks:
      - obfuscated10net
    env_file:
      - docker-compose.env
    depends_on:
      - mongodb-master
      - mongodb-slave1
      - mongodb-slave2
      - api1
      - api2
networks:
  obfuscated10net:
    driver: ${DOCKER_NETWORK_TYPE}

On notera le réseau Docker de type bridge en build/dev pour fonctionner sur un host unique. Il sera de type overlay sur plusieurs hosts.

Construction des images et exécution du code dans les conteneurs sur la VM de build/dev

Voici la façon dont nous contruisons les images depuis une VM de build ou de dev (sous Ubuntu 16.04 dans le cadre de nos tests):

Récupération des sources depuis les différents repos:

cd $obfuscated10_HOME
git clone git@obfuscated2.westeurope.cloudapp.azure.com:atelier/vitrine.git 
git clone git@obfuscated2.westeurope.cloudapp.azure.com:atelier/api.git
git clone git@obfuscated2.westeurope.cloudapp.azure.com:atelier/supervision.git
git clone git@obfuscated2.westeurope.cloudapp.azure.com:atelier/base-container-images.git
git clone git@obfuscated2.westeurope.cloudapp.azure.com:atelier/compose-containers.git

Potentiellement, reset des images:

docker rmi obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-mongodb-base:0.1
docker rmi obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-mongodb-replicaset:0.1
docker rmi obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-nodejs:0.1
docker rmi obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-api:0.2
docker rmi obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-api-tools:0.1
docker rmi obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-vitrine:0.1
docker rmi obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-supervision:0.1

Construction des images:

cd $obfuscated10_HOME/base-container-images
docker build -t obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-nodejs:0.1 ./nodejs
docker build -t obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-mongodb-base:0.1 ./mongodb-base
docker build -t obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-mongodb-replicaset:0.1 ./mongodb-replicaset

cd $obfuscated10_HOME
docker build -t obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-api:0.2 ./api
docker build -t obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-api-tools:0.1 --file ./api/Dockerfile-tools ./api
docker build -t obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-vitrine:0.1 ./vitrine
docker build -t obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-supervision:0.1 ./supervision

Depuis cette même VM, on peut exécuter l’ensemble des conteneurs. Dans notre cas, nous avons fait fonctionner cela depuis une VM Azure avec 14 Go de RAM, plus que sur mon ordinateur portable ;-).

cd $obfuscated10_HOME/compose-containers
. set_environment_variables.sh
docker-compose up -d

Ces différentes commandes sont globalement celles qui sont ensuite exécutées depuis Visual Studio Team Services pour la construction automatisée des images docker depuis le code source.

Exemple d’utilisation du conteneur outils pour MongoDB

Voici par exemple ensuite comment on peut restaurer la base MongoDB:

docker exec -ti api-tools bash
cd database/export/db-pwz-v2-20161005
mongorestore --host rs0/$MONGODB_HOSTS --db $MONGODB_DB --drop ./dump/crigen
cd /data
mongo --host rs0/$MONGODB_HOSTS $MONGODB_DB
use crigen
show collections

Mise en place du déploiement en continu

Intégration Continue

La première tâche sur laquelle nous avons travaillé est la mise en place d’intégration continue pour faire en sorte de déclencher une build Visual Studio Team Services à chaque fois qu’une pull request est acceptée sur la branche master du projet GitLab.

L’objectif principal de la build est de packager l’application dans une image Docker à partir de son Dockerfile est de la pousser automatiquement dans la Docker Trusted Registry du projet. Pour réaliser cet objectif, il a été nécessaire de :

  • Installer et configurer un agent de build Visual Studio Team Services sous Linux
  • Installer l’extension Docker pour Visual Studio Team Services depuis la Marketplace
  • Configurer une connexion externe vers le dépôt GitLab et la Docker Trusted Registry dans Visual Studio Team Services
  • Créer une nouvelle définition de build et la connecter au dépôt GitLab
Installation d’un agent de build Visual Studio Team Services sous Linux

Visual Studio Team Services propose des agents hébergés sous Windows (fournis par la plateforme). Pour les workloads Linux, comme c’est le cas ici, il est nécessaire de créer sa propre machine et d’y installer un agent.

La procedure d’installation et de configuration est décrite sur cette page. Dans le cas présent, nous avons créé une machine Ubuntu 16.04 dans Microsoft Azure, nous y avons installé Docker en suivant la procédure décrite sur le site de Docker, puis nous avons configuré l’agent en suivant la documentation ci-dessus.

Nous avons choisi de créer l’agent dans un nouveau pool, nommé Crigen-docker. Une fois l’installation et la configuration terminées, on peut voir cet agent disponible dans les paramètres du projet d’équipe, dans Visual Studio Team Services :

Agent Queue

Nous configurerons ensuite chaque build et la release pour s’exécuter sur cet agent.

Installation de l’extension Docker pour VSTS

Afin de pouvoir générer les images Docker dans une build Visual Studio Team Services, il est nécessaire d’installer une extension développée par Microsoft et disponible dans la MarketPlace. Ceci se fait très simplement en cliquant sur le bouton Install et en suivant les instructions données par le site :

Définitions des différentes builds

Connexion de GitLab et Docker Trusted Registry dans VSTS

Visual Studio Team Services supporte la connexion à des dépôts Git externe, pour cela il faut se rendre dans les paramètres du projet d’équipes, onglet Services puis d’ajouter une nouvelle connexion vers un Git externe :

Définitions des différentes builds

Il suffit ensuite de renseigner l’URL du dépôt Git (ici hébergé sur une machine virtuelle dans Azure, dans GitLab) et les informations de connexion :

Définitions des différentes builds

De la même manière, il est possible de configurer une connexion vers la Docker Trusted Registry dans laquelle devront être poussées les images :

Définitions des différentes builds

Mise en place de la définition de build

Une fois la configuration des différents services externes et l’installation de l’extension Docker pour Visual Studio Team Services terminées, nous pouvons passer à la création des différentes définitions de Build (une pour chaque repository).

La première étape consiste à configurer le dépôt Git auquel se lier, via l’onglet Repository :

Configuration du dépôt

Nous avons ensuite besoin de 4 étapes pour chaque image Docker à envoyer dans la trusted registry :

1. La récupération du nom de l’image à l’aide d’un script Bash dans le Dockerfile (cf. astuce ci-dessous) 2. La récupération de la version de l’image à l’aide d’un script Bash dans le Dockerfile (cf. astuce ci-dessous)

Script Bash

3. Le build de l’image

Build Docker image

4. Le push de l’image dans la trusted registry

Push Docker Image

Enfin, il est possible de configurer la build pour s’exécuter sur l’agent Linux créé au préalable. Ceci se fait dans l’onglet General :

Configuration du pool

Après avoir réalisé ces quelques étapes simple, à chaque fois que des modifications sont poussées sur la branche master du projet GitLab, une build se déclenche automatiquement et se charge de recréer l’image Docker et de la pousser dans la Docker Trusted Registry.

Ils nous a ensuite suffi de répéter ces opérations pour chaque dépôt GitLab :

Définitions des différentes builds

ASTUCE

Pour le versionnage des images, nous avons utilisé des commentaires en en-tête des fichiers Dockerfile :

# URL_DOCKER_TRUSTED_REGISTRY/crigen/api
#
# VERSION   0.2

Pour récupérer le nom de l’image, nous utilisons :

/bin/bash -c "grep \"# URL_DOCKER_TRUSTED_REGISTRY\" .../Dockerfile | awk '{print \"##vso[task.setvariable variable=image.name;]\"$2}'"

Pour récupérer la version, nos utilisons :

/bin/bash -c "grep \"# VERSION\" .../Dockerfile | awk '{print \"##vso[task.setvariable variable=image.version;]\"$3}'"

Nous pouvons ensuite directement utiliser une tâche d’exécution d’un script bash pour pouvoir extraire le nom de l’image et numéro de version afin de l’affecter à des variables de la build que nous réutilisons par la suite :

Affectation de la variable au moment de la build

Utilisation des variables

Pour plus d’information concernant les “logging commands” qui permettent notamment d’affecter des variables en cours de build, consultez cette page.

Release Management

Le but du Release Management est de pouvoir déclencher une séquence de déploiement après la fin d’une build. Dans le cas présent, l’application est composée de micro-services et chaque build permet de créer et d’envoyer l’image Docker qui correspond au service dans la Trusted Registry Docker. Afin de garder une certaine maîtrise sur le déploiement de l’application, il a été choisi de stocker les scripts de déploiement (basés sur Docker Compose) dans un autre dépôt GitLab.

Ce choix nous a permis de déclarer une build d’intégration continue qui se déclenche automatiquement à chaque fois que les scripts de déploiement sont modifiés et uniquement quand ceux-ci sont modifiés. Cette nouvelle build ne se charge que de copier ces scripts en sortie, pour qu’ils soient disponibles en tant qu’artefacts réutilisables dans le processus de release :

CI Deploiement

Ainsi, on retrouve bien les fichiers nécessaires au déploiement en sortie de build :

CI artefacts

A partir de là, nous pouvons définir une nouvelle définition de Release dans Visual Studio Team Services, et la lier à la build précédente afin d’en récupérer les artefacts :

CI artefacts

Ensuite, nous avons défini nos deux environnements de Recette (Azure Container Service) et de Production (Docker DataCenter) :

CI artefacts

Pour chacun des environnements, le déploiement se fait à l’aide de deux étapes :

  1. La copie des fichiers de déploiement issus de la build à l’aide de SCP
  2. L’exécution d’un script de déploiement via SSH : ce script est très simple puisqu’il ne fait que manipuler la ligne de commande docker-compose: il commence par faire un pull, pour récupérer la dernière version des images à utiliser, puis stop les services, les supprime, et démarre les nouveaux !

Pour pouvoir faire cela, nous avons tout simplement déclaré les connexions SSH dans les services externes de Visual Studio Team Services :

CI artefacts

Enfin, ENGIE LAB CRIGEN souhaitait pouvoir valider le passage sur l’environnement de production, nous avons donc utilisé la fonctionnalité d’approbation de Visual Studio Team Services pour faire en sorte qu’une validation manuelle soit obligatoire entre l’environnement de Recette et l’environnement de Production. Pour cela, il suffit de cliquer sur les “…” au niveau de l’environnement de Production et de cliquer sur Assign approvers :

CI artefacts

Cela étant fait, à chaque fois qu’une étape de release sur la Recette se termine, le processus reste en attente d’une approbation manuelle :

CI artefacts

Conclusion

Dans cet atelier, Microsoft a accompagné le centre de recherche ENGIE LAB CRIGEN dans le prototypage d’une plateforme d’hébergement d’application web “as a service”, totalement bâtie sur la plateforme Microsoft Azure et capable d’exécuter n’importe quelle application web, quelle que soit la technologie utilisée pour la développer, et ce grâce aux conteneurs Docker. Cette plateforme a été pensée pour être totalement automatisée pour faire en sorte que les applications puissent y être déployées en continu, en utilisant Visual Studio Team Services.

Quelques mots du d’ENGIE LAB CRIGEN pour conclure:

Nous avons souhaité faire cet atelier, car nous cherchons à mettre en place une infrastructure nous permettant de déployer rapidement des applications dans le cadre de nos activités de recherche (POC …).

Ce workshop nous a permis de tester l’association de Docker sur Azure et de découvrir les produits commerciaux de Docker (Docker Datacenter, Trusted Registry…)

L’accompagnement de Microsoft a permis de voir de nouvelles « bonnes pratiques » concernant pour la mise en place d’un process devops, notamment sur l’automatisation des différentes étapes et de nous aider à mettre rapidement des choses en place pendant l’atelier

Références externes

Deep Learning : définition, concept et usages potentiels

Nous avons vu que le Machine Learning est un domaine de l’intelligence artificielle qui vise à étudier comment des algorithmes peuvent apprendre en étudiant des exemples.

Le Deep Learning est une méthode particulière d’apprentissage, qui ouvre de nouvelles possibilités.

Des exemples connus et visibles tirant partie de ces procédés de Deep Learning sont AlphaGo qui s’est imposé face aux champions du jeu de Go, DeepDream de Google ou même Watson d’IBM.

Afin de qualifier le Deep Learning un rapide rappel sur le Machine Learning s’impose.

Le Machine Learning

Le Machine Learning vise à entraîner un algorithme en se basant sur des exemples, avec pour objectif la construction d’un modèle prédictif.

Le Machine Learning vise à entraîner un algorithme en se basant sur des exemples, avec pour objectif la construction d’un modèle prédictif.

Le but est d’être capable de déterminer ce qui lie une sortie à une entrée.

Nous avons pris un exemple simple basé sur les données suivantes :

Notre objectif était de déterminer la fonction ou l’algorithme qui transforme les nombres en entrées en ceux en sortie.

Pour cela le Machine Learning va étudier les exemples fournis, puis essayer de déterminer l’algorithme de transformation. Cette phase s’appelle l’apprentissage.

C’est là que l’algorithme se sert des exemples fournis pour trouver un lien entre les données en sorties et les données en entrées. Ainsi il sera capable, peu importe le nombre en entrée, de déterminer le nombre en sortie.

Pour parvenir à cet objectif, l’algorithme va définir une fonction f(x)=aX, et faire varier a, jusqu’à ce qu’il trouve la bonne valeur. “a” est une caractéristique permettant de déterminer la sortie en fonction de l’entrée. Ici c’est a =2, et donc la fonction liant les entrées aux sortie est Y = f(x) = 2x.

Ensuite il sera capable de déterminer quelle sera la sortie (Y) pour n’importe quelle valeur de X, même si cette valeur n’est pas présente dans les exemples utilisés pour l’apprentissage.

Cette deuxième phase, c’est la prédiction. Simplement, l’algorithme est maintenant capable de déterminer que si X = 5, Y= 10.

Dans notre article précédent, nous nous en étions arrêté là. Maintenant comment modéliser des problématiques plus compliquées avec des dizaines de caractéristiques comme “a” différentes ?

Les réseaux de neurones

Prenons un exemple concret et cherchons à construire un algorithme qui exprime le temps qu’il a fait dans une journée (beau temps ou mauvais temps).

Pour cela, il faut lui fournir un certain nombre de paramètres en entrée :

  • La température
  • L’hygrométrie
  • La pression atmosphérique
  • La vitesse du vent

Et lui donner des exemples pour s’entraîner.

Evidemment plus le nombre d’exemple sera grand et varié, plus l’entraînement permettra d’arriver à un modèle précis et pertinent. Ici il faudrait un grand nombre de cas exposés pour être capable de généraliser la subjectivité liée au beau temps ou au mauvais temps. Pour la simplicité de l’exemple, nous nous en tiendrons à ces quelques valeurs.

Au final, nous aurons un algorithme qui pourra déterminer pour n’importe quel ensemble de ces entrées (Température, pression, hygrométrie, vitesse du vent) s’il fait beau ou non.

Pour modéliser et appréhender cette relation complexe, une simple fonction ne suffit pas, nous avons besoin d’un réseau de neurones.

Ce réseau de neurones aura deux couches (et sera donc extrêmement simple) :

L’intérêt du réseau de neurones est de modéliser l’impact des différents facteurs et leur relation entre eux. Lorsque la complexité des facteurs est grande, plutôt que de les traiter tous ensemble, on décompose l’analyse en étapes, les plus petites possibles.

Chaque étape est représentée par un neurone. Un neurone reçoit un certain nombre d’informations, chacune pondérée (p), et renvoi une réponse binaire 0 ou 1.

Ensuite cette réponse va venir alimenter le neurone suivant dans le réseau, qui lui-même produira une réponse binaire, et ainsi de suite jusqu’au dernier neurone du réseau.

La sortie du dernier neurone du réseau représente la réponse que l’on cherche à obtenir.

Pour affiner ce modèle, on joue sur la pondération de chaque entrée et le seuil qui déclenche la sortie 0 ou la sortie 1.

Autrement dit, un neurone : est une fonction mathématique qui met en relation une entrée X et une sortie Y. L’importance de chaque critère d’entrée est pondéré par un coefficient “p”. Avec le seuil “s”, d’activation de la sortie (qui va définir à quel moment la sortie va afficher 0 ou 1, soleil ou pluie ici), ce sont les deux variables qui vont pouvoir évoluer pour affiner et donc entraîner notre réseau de neurone pendant la phase d’apprentissage.

Le réseau de neurones permet donc de traiter des cas complexes avec de multiples entrées. Toutefois que se passe t’il lorsque les entrées sont encore plus nombreuses ?

Machine Learning et concepts abstraits

Dans le cas d’une image où l’objectif est d’identifier automatiquement ce qu’elle représente, les entrées seraient les pixels. Une image de 300x300px, représente 90 000 pixels et donc 90 000 valeurs en entrées potentielles. Tout traiter dans un réseau de neurones traditionnel serait bien trop complexe, et ce dernier serait incapable d’intégrer les concepts nécessaires à l’abstraction de l’image pour en déduire quoi que ce soit.

Intuitivement, nous serions tentés de penser qu’il faut traiter l’image par groupe de pixels pour faire ressortir des arbres, des constructions, des personnages etc…

C’est exactement ce qu’il manque pour pouvoir traiter ces images : des caractéristiques représentatives qui vont représenter au final, les entrées à traiter par le réseau de neurones.

Dans ce cas un algorithme tiers (non lié au réseau de neurone ou au machine learning) identifiera des caractéristiques prédéfinies.

Par exemple, si l’on veut que l’algorithme soit capable de distinguer sur des photos les motos des voitures, les caractéristiques à identifier en amont seraient

  • Nombre de roues
  • Nombres de vitres
  • La forme
  • Présence d’un casque…

Une fois ces caractéristiques identifiées il “suffit” de les passer au réseau de neurones qui, comme pour l’exemple de la météo, les traitera à partir d’exemples et identifiera une logique pour distinguer moto et voitures.

Cette solution nous laisse néanmoins avec deux problèmes :

  • Les performances de tels algorithmes sont loin d’être parfaites (15% d’erreurs)
  • Les caractéristiques à identifier dépendent de l’expertise humaine. Que faire alors dans une situation où les caractéristiques distinctives d’une situation ne sont pas identifiables par l’homme ? Autrement dit lorsqu’on ne sait pas déterminer intuitivement le lien entre la sortie et l’entrée ?

Le Deep Learning

Le Deep Learning construit lui-même ses caractéristiques d’analyse.

Ce qui rend le deep learning différent des méthodes de machine learning traditionnelles c’est que lors d’analyses complexes, les caractéristiques essentielles du traitement ne seront plus identifiées par un traitement humain dans algorithme préalable, mais directement par l’algorithme de Deep Learning.

En effet, si le réseau de neurones est suffisamment bien entraîné, il sera en mesure deconstruire lui-même ces caractéristiques, et sera donc capable d’identifier ce qu’il y a sur une image. Dans notre cas une moto ou une voiture, sans lui avoir transmis au préalable des informations sur ce qui caractérise une voiture ou une moto.

Pour ce faire, il construira à partir des exemples à disposition, ses propres caractéristiques (parfois similaires à celles qu’un humain aurait identifiées : Nombre de roues, Vitres, forme, casque…) et s’en servira pour analyser l’image et définir s’il s’agit d’une moto ou d’une voiture.

Pour parvenir à cela on utilisera un réseau de neurone profond (plusieurs couches), auquel, une fois entraîné, on passera directement l’image en entrée.

Pour résumer, lorsque les méthodes traditionnelles d’analyse d’images, résument au préalable l’image selon des caractéristiques définies par des experts, le Deep Learning construit lui-même ses caractéristiques d’analyse.

Le Deep Learning permet donc implicitement de répondre à des questions du type “que peut on déduire de ces données ?” et ainsi décrire des caractéristiques parfois cachées ou des relations entre des données souvent impossibles à identifier pour l’homme.

Nous disions plus tôt que passer des images sans les résumer à des réseaux de neurones serait trop complexe, et c’était le cas jusqu’en 2012 environ.

Même si leur origine remonte à aux années 90 avec Yann Le Cun, c’est donc au début des années 2010 avec les travaux de Geoffrey Hinton, que les algorithmes de Deep Learning ont commencé à démontrer leur efficacité.

Qu’est ce qui a changé ?

Cela est rendu possible par le partage de bases de données d’images catégories, qui permettent d’entraîner ces réseaux de neurones

Les architectures des réseaux de neurones se sont améliorés et la puissance de calcul disponible a grimpée en flèche (grâce au Cloud notamment).

Mais la plus grande révolution, c’est la disponibilité des données. En effet, le grand enjeu pour le Deep Learning (encore plus que pour le machine learning) reste la capacité à être correctement entraîné et à avoir à disposition un nombre virtuellement infini d’exemples pour parfaire le modèle à construire.

Dans l’exemple précédent, pour qu’un tel réseau de Deep Learning fonctionne, il faut un nombre très élevé d’exemples de photos catégorisées représentant des voitures et des motos.

Cela est rendu possible par le partage de bases de données d’images catégories, qui permettent d’entraîner ces réseaux de neurones (Image Net, par exemple).

Et concrètement ?

Plus ambitieux, le Deep Learning permet d’établir des relations et d’identifier des causes qui restent indétectable par l’homme.

Maintenant que le concept de Deep Learning est précisé, qu’est-ce que cela peut apporter ?

Evidemment, en allant dans le sens de l’exemple, analyser et décrire des images ou des vidéos pour faciliter des études ou automatiser des actions. Par exemple, pour un service client, être capable de préqualifier un défaut sur un produit, à partir de l’analyse automatique de la photo envoyée par le client insatisfait, en améliorant drastiquement le délai de traitement de sa demande.

Plus ambitieux, le Deep Learning permet d’établir des relations et d’identifier des causes qui restent indétectable par l’homme. On peut penser à un système de détection de fraudes avancées dans des contextes Big Data bancaires ou une optimisation de l’infrastructure de son informatique en fonction d’une demande qui serait anticipée par un réseau Deep Learning traitant en temps réel les actions des utilisateurs.

Enfin, le plus intriguant (et le plus étonnant), reste la capacité à transformer les réseaux Deep Learning en modèle génératif.

Le concept est simple : une fois le modèle entraîné (et donc les caractéristiques de traitement identifiées), on est en capacité d’inverser le processus en fournissant des entrées aux caractéristiques de traitement en sortie de réseau, pour obtenir une image originale.

Dans le cas de notre réseau qui permettait d’identifier motos et voitures, on peut imaginer lui fournir une information en entrée étant “Moto” et le voir créer des images originales de motos.

Une réponse à des pannes de créativité ou d’originalité dans le design des produits ?

Pour aller à la source, visitez https://www.tensorflow.org/ Un MOOC par Vincent Vanhoucke, Principal Scientist at Google Brain Team : https://www.udacity.com/course/deep-learning–ud730

L’innovation informatique rentabilisée

Lorsque l’on parle d’informatique, les directions générales ont trop souvent tendance à penser « coûts ». Certes, ça coûte, mais on peut regarder l’autre facette, on « INVESTIT« .

Ne confondez pas innovation informatique avec recherche !!

  • La recherche : c’est l’action de parvenir à une connaissance nouvelle
  • L’innovation : c’est l’art d’assembler d’une nouvelle façon des éléments connus

 

Il est de notoriété publique que sur 10 projets innovants, un seul va devenir rentable. De grands cabinets vous démontreront comment mesurer ce fameux ROI, ou RSI en français dans le texte, comment implémenter des KPI (BearingPoint dispose d’un très beau document sur le sujet ici). Mais faire de l’innovation pour faire de l’innovation, ce n’est pas la fonction première des entreprises. Ce sont les start-up à majorité qui sont à l’origine des innovations et qui, soit émergent, soit se font racheter.

Trop rares sont les grandes entreprises qui savent mettre en place, organiser et surtout exploiter ce qui fera d’elle « l’entreprise leader de demain ».

La méthode française de l’innovation : avoir un département innovation

Trop souvent on se plait à croire que l’innovation informatique, c’est le département de ceux dont on ne sait pas quoi faire, qui n’ont plus leur place dans la production de l’entreprise : en gros, la planque. Alors quand on veut mettre en place un département innovation, on réunit des génies dans une pièce et on leur dit « inventez-nous quelque chose pour notre métier ». Les seules contraintes sont alors, soit le budget, soit l’effectif. Peu d’obligation de résultat, peu de motivation et donc une dégradation progressive de la motivation des équipes et de résultats.

Dommage au début, ils étaient bien ces petits gars là !! Bilan, les bons qui ont faim d’avancer dans leur carrière vont partir, parce qu’ils ne veulent pas végéter, et les mauvais, ou déprimés, eux vont rester, parce que la situation est finalement pas si inconfortable : être payé pour occuper un siège sans beaucoup de contraintes !

Quand elle fonctionne cette équipe innovation, 15% du travail a été effectué. Il faut alors industrialiser la solution, et puis enfin la vendre : ce sont ces étapes qui coûtent le plus cher : convaincre le reste de l’entreprise du bien fondé du projet. C’est le point noir de ce système : personne n’aime le changement. Changer de comportement implique des changements d’habitudes et c’est là que ça se complique.

 

Filialiser les projets innovants et en faire des micro-structures

Mettre une contrainte de rentabilité sur chaque projet : C’est la méthode qu’a adopté Google depuis deux ans. 

  • Avoir une idée
  • Faire un POC (Proof of Concept) ou prototype en français
  • Constater qu’il est bien définir les attentes d’un tel projet
  • Créer une structure autonome avec les moyens et le soutien de la grande entreprise
  • En fonction du succès ou non du projet, se déployer à plus grande échelle et rayonner en faisant le buzz.

Attention, 9 projets sur 10 iront à la poubelle, ce n’est pas une raison pour se débarrasser des membres qui ont fait partie du projet ou qui l’ont mené. Quelque soit le résultat, pour peu que l’on sache impliquer les équipes dans le projet, si c’est un succès, ils seront fiers et travailleront d’autant plus pour le succès en perspective, et si c’est un échec, il faudra en analyser les causes de façon objective afin que tous puissent partager le fruit de l’expérience et ils auront progressé.

L’expérience ne se transmet pas, elle s’acquiert

Mais pour monter une telle structure, soit il faut un dirigeant d’entreprise qui veuille faire de son entreprise une entreprise à la pointe, donc l’appui de la direction générale est plus que nécessaire, soit il faut des directeurs qui sachent porter les projets, prendre des risques et parfois se mettre en danger pour faire valoir leurs convictions.

Malheureusement, toutes les entreprises n’ont pas cette capacité. Il devient alors impératif, pour le bien de l’entreprise de savoir porter l’innovation au fil des projets.

Comment donc faire de l’innovation tout en étant productif ?

Pour faire de l’innovation, hors cas exceptionnels, soit c’est un projet innovant qui est demandé, mais là, c’est la perle rare, soit aucune innovation n’est demandée, et on attend une productivité maximale. Dans les deux cas, c’est sur le manager que va retomber la responsabilité de faire les bon choix, accompagné de ses équipes.

Le projet innovant

Ça peut paraître simple. Il y a un projet dont l’idée vient du métier, il se trouve à la pointe de la technologie, il y a souvent un délai et un coût. Le triptyque du projet informatique rentre alors en ligne de compte : c’est la qualité qui en fera les frais.

Belle idée reçue et correspondant toujours aux situations rencontrées. Il existe pourtant un 4ième levier, méconnu : « Le raccourci technologique », la réutilisation de ce qui existe déjà, car ne rêvez pas, au moins une partie de ce que vous devez faire l’a déjà été.

Comme dans la vie, il n’y a jamais un seul moyen d’atteindre une destination. Il y a le chemin le plus court, le plus rapide et de nombreux compromis entre les deux. Dans cette multitude de chemins, ou de choix à faire, il existe des briques, toutes faites, qui font déjà une partie du travail.

 

Pourquoi refabriquer la roue, quand il suffit d’aller en acheter une ?

Charge alors au manager de savoir orienter le projet, sur des méthodologies qui permettront la réutilisation d’éléments existants. On peut les nommer bibliothèques ou libraries, framework si elles sont devenues état de l’art, ou encore codes sources s’il est possible de les réutiliser et ont déjà été développées par ailleurs. Tout l’art de la direction de projet est alors de déterminer ce qui sera le plus rentable, et de faire les bons choix pour y arriver.

C’est de la factorisation. Lorsqu’elle se répète sur de l’interne, elle porte un nom beaucoup plus connu : l’urbanisation, ou l’art de factoriser l’informatique de l’entreprise de façon modulaire. Réutiliser ce qui existe déjà et ne pas le recréer. Idée toute bête, qui existe depuis la nuit des temps, à qui l’on vient de donner un nom en informatique qui est à la mode.

Mais que faire si aucune idée innovante rentre en projet ?

La production, la rentabilité et son innovation

Tout le monde sait qu’une équipe ne peut pas être efficace à 100% de son temps. On parle en général d’un taux de 85% d’efficacité en production informatique. Bien entendu, tout dépend de la vélocité de chacun d’entre eux, mais globalement, c’est sur ce chiffre sur lequel on peut se baser.

Bien manager son équipe, c’est la faire progresser : toujours, tout le temps. Plus vite, plus performant, plus rentable, plus pointu. Un bon service informatique, c’est anticiper les besoins du client, ne pas simplement se baser sur ses attentes, mais intégrer ce qu’il en attend aujourd’hui et ce qu’il en attendra demain. Il faut donc prévoir, anticiper l’architecture pour permettre demain, de mener la phase 2 du projet à moindre coût et y insérer de l’innovation, des idées, des propositions.

Offrez un chocolat à quelqu’un, il en mangera.

C’est la même chose pour l’informatique, sachez proposer dans les produits et projets des choses nouvelles, au fil des projets, des fonctionnalités. Mettez du défis partout, prévoyez l’avenir, urbanisez et faites des économies d’échelle !

Si vous consacrez entre 10% et 20% de la bande passante d’une équipe à trouver de nouvelles visions de nouvelles façon de voir les choses, de les aborder, de nouveaux outils, du rattrapage de dette technique (oups …), à proposer des POC en rapport avec le produit ou le projet, à faire des points sur des problématiques envisagées ou des sujets à perfectionner, ce grand mot qui ne veut rien dire, « innovation », prendra tout son sens et l’équipe n’en sera que plus productive.

Ce principe est valable pour toutes les méthodologies projets : Scrum, XP, Clycle en V et est applicable à tous les langages : de l’assembleur en passant par du C# ou du PHP et peut prendre toute sorte de forme.

Innover c’est laisser l’esprit libre de trouver des solutions, des assemblages pour répondre à une problématique donnée. Nous ne sommes plus dans un monde où seul un penseur est détenteur de la vérité. Il faut savoir tirer le meilleur de chacun, c’est le monde de l’uberisation. Chacun à son niveau peut être contributeur d’un projet, et comme de par hasard, il interviendra toujours sur ce qui le motive, il sera donc plus impliqué que jamais et saura apporter sa propre contribution à l’entreprise.

Créez les conditions de liberté de penser pour qu’émerge l’innovation, et l’entreprise s’en retrouvera gagnante.

N’est-ce pas ce qui nous manque à tous, innover, se faire plaisir au travail, augmenter la productivité et aider nos entreprises à devenir les leaders de leur marché ?

[Atos-Rack]Modul’X : Le coup de coeur du salon Datacenter Solutions 23 & 24 Mars Paris

 

Etant donné la nouvelle directive Européenne F-GAS 842 / 2006 révisée et entrée en vigueur depuis Janvier 2015 et qui a pour objectif de restreindre progressivement la commercialisation des solutions de refroidissement à détente directe, il a fallu trouver une nouvelle approche du refroidissement en Datacenter.

PRESENTATION :

Le Modul’X est une solution modulaire qui permet une urbanisation réussie des salles informatiques aboutissant à une exploitation maitrisée.

Le Modul’X est constitué principalement de plusieurs baies accouplées et équipées en partie arrière d’un confinement mutualisé.

Des portes hydro réfrigérées assurent l’extraction de l’air chaud confiné dans la zone mutualisée pour le restituer dans la salle à la température souhaitée (suivant la consigne utilisateur).

La mutualisation des confinements arrière garantit le niveau de redondance N+1, N+2, 2N.

PRINCIPE :

L’air de la salle est aspiré par les serveurs.  Il est ensuite refoulé chaud dans la partie arrière confinée des baies.

Des portes HYDRO-RÉFRIGÉRÉES installées en partie arrière du Modul’x, aspirent cet air chaud pour le refroidir via un échangeur air/eau et le rejeter dans la salle suivant une consigne « utilisateur ».

Les portes hydro-réfrigérées sont issues de la gamme THD et disposent de 2 systèmes avec régulation indépendante et optimisée.

1

AVANTAGES :

  • Flexibilité d’aménagement des salles au fur et à mesure des besoins.
  • Réduction du volume d’air et rapidité de traitement des zones chaudes => jusqu’ à 50% de volume d’air en moins, soit + de rendement thermique.
  • Installation rapide et économique sans modifications des confinements d’allées (toits, porte, etc.).
  • Compatible avec tous les systèmes de détection et d’extinction incendie.
  • Pas de dépose des toits d’allée pour intervention sur les chemins de câbles aériens ou les éclairages de salle.
  • Pas de portes coulissantes d’allée (pas d’entretien annuel de celles-ci).

2

EXEMPLE D’URBANISATION :

3

Une photo est toujours plus parlante.

IMG_6929

IMG_6930

Cerise sur le gâteau ces 2 logos sont très valorisants à mes yeux.
45

En savoir plus sur : http://www.atos-racks.com/

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.