RSS Feed

Archives de la catégorie ‘Linux’

Bash – set -xe pour un développement plus rapide

16 July 2015 par SeB Pas de commentaire »

Lorsque l’on écrit des scripts shell de provision, leur validation peut se révéler très longue. Et l’analyse de l’erreur initiale n’est pas toujours facile. Pourtant, le bash propose la commande set avec 2 options qui peuvent grandement augmenter votre productivité :

  • -e : sort du script dès qu’une erreur est rencontrée (retour différent de 0)
  • -x : affiche la commande exécutée avec ses arguments

Ainsi donc, en phase de développement, vous pouvez commencer vos scripts ainsi :

#! /bin/bash
set -xe
echo "starting..."
ls /bad/path
echo "done"

Le résultat sera le suivant :

+ echo starting...
starting...
+ ls /bad/path
ls: /bad/path: No such file or directory

Pour un écriture plus compacte, il est possible d’activer ces options de cette façon :

#! /bin/bash -xe
echo "starting..."
ls /bad/path
echo "done"

Je vous laisse retourner à vos | !

 

Conteneurisation d’un LAMP avec Docker

22 April 2015 par SeB Pas de commentaire »

J’avais pensé intituler cette note LAMP is dead, long life Docker! mais le LAMP n’est pas vraiment mort. Il se transforme sous l’impulsion de Docker.

Introduction

Nous allons voir ici comment conteneuriser avec Docker une application existante de type LAMP. Pour information, cette application est réelle, tourne en production et se compose :

  • D’un serveur MySQL v5.5.35 administré via phpMyAdmin
  • D’un serveur Apache 2.2.22 hébergeant une application web PHP v5.4.4-14

Création des conteneurs

La base de données MySQL

Le démarrage du conteneur MySQL est assez simple :

docker run --name mysite-db -e MYSQL_ROOT_PASSWORD=secret-pwd -v /mnt/data/mysite/mysql:/var/lib/mysql -d mysql:5.5

Vous remarquez que les données sont persistées dans un volume sur la machine host dans /mnt/data/mysite/mysql.

Il est possible de se connecter à cette base via un conteneur également :

docker run -it --rm --link mysite-db:mysql mysql:5.5 sh -c 'exec mysql -h"$MYSQL_PORT_3306_TCP_ADDR" -P"$MYSQL_PORT_3306_TCP_PORT" -uroot -p"secret-pwd"'

Maintenant, nous devons restaurer les données récupérées de l’environnement de production. Pour cela, il faut créer la database mysite puis exécuter le script dump.sql :

echo "create database mysite;" > /mnt/data/mysite/scripts/init.sql
docker run -it --rm --link mysite-db:mysql -v /mnt/data/mysite/scripts:/scripts mysql:5.5 sh -c 'exec mysql -h"$MYSQL_PORT_3306_TCP_ADDR" -P"$MYSQL_PORT_3306_TCP_PORT" -uroot -p"secret-pwd" < /scripts/init.sql'
docker run -it --rm --link mysite-db:mysql -v /mnt/data/mysite/dumps:/scripts mysql:5.5 sh -c 'exec mysql -h"$MYSQL_PORT_3306_TCP_ADDR" -P"$MYSQL_PORT_3306_TCP_PORT" -p mysite -uroot -p"secret-pwd" < /scripts/dump.sql'

Après avoir démarré notre serveur MySQL dans un conteneur Docker puis créé la base et enfin inséré les données, nous allons démarrer un conteneur phpMyAdmin :

docker run -d --link mysite-db:mysql -e MYSQL_USERNAME=root --name mysite-pma -p 8080:80 corbinu/docker-phpmyadmin

L’application phpMyAdmin est maintenant accessible sur la machine host avec le port 8080 et donc à l’URL suivante : http://localhost:8080. Vous avez sûrement deviné que le mot de passe est “secret-pwd”.

Notre première étape est terminée et s’est révélée assez simple. Passons donc à l’application web en PHP.

Application web en PHP

En général, il faut privilégier les images Docker officielles. Cependant, cette application n’utilisant pas le driver PDO pour la connexion à MySQL, nous avons rencontré quelques difficultés avec l’image officielle. Nous allons donc utiliser une image alternative : d11wtq/php.
De plus, l’application nécessite l’installation d’ImageMagick.

Ne souhaitant pas créer de nouvelle image dans un premier temps, nous allons personnaliser le container directement à son lancement :

docker run -d --name mysite-www -p 80:8080 --link mysite-db:mysql -v /mnt/data/mysite/www:/www/htdocs -v /mnt/data/mysite/apache/conf.d:/www/httpd.conf.d d11wtq/php bash -c "sudo apt-get update && sudo apt-get -y install ImageMagick && apachectl -d /usr/local -f /www/httpd.conf -DFOREGROUND"

Que permet cette commande ?

  • Démarrage du conteneur à partir de l’image d11wtq/php
  • Exposition du port 8080 d’Apache sur le port 80 de la machine host
  • Utilisation du conteneur MySQL “mysite-db” comme base de données “mysql”
  • Montage des volumes /www/htdocs pour les scripts PHP (et autres ressources web) et /www/http.conf.d pour la configuration Apache
  • Installation de ImageMagick

L’application phpMyAdmin est maintenant accessible sur la machine host avec le port 80 et donc à l’URL suivante : http://localhost.

Cette méthode n’est pas très élégante, ni performante car à chaque démarrage du conteneur, APT va mettre à jour ses indexes et installer la dernière version d’ImageMagick. Le temps de démarrage ne sera donc pas immédiat.

Il faut donc créer une image personnalisée à partir du Dockerfile suivant :

FROM d11wtq/php
RUN apt-get update \
	&& apt-get install -y --no-install-recommends ImageMagick \
	&& rm -rf /var/lib/apt/lists/* \
	&& apt-get clean
EXPOSE 8080
CMD ["apachectl", "-d", "/usr/local", "-f", "/www/httpd.conf", "-D", "FOREGROUND"]

Ensuite, créer notre image personnalisée avec Docker :

docker build -t mycompany/php .

Et enfin démarrer le conteneur de notre application web :

docker run -d --name mysite-www -p 80:8080 --link mysite-db:mysql -v /mnt/data/mysite/www:/www/htdocs -v /mnt/data/mysite/apache/conf.d:/www/httpd.conf.d mycompany/php

Démarrage rapide

Maintenant que tous les conteneurs ont été créés, leur démarrage est extrêmement simplifié :

docker start mysite-db mysite-www mysite-pma

Conclusion

Nous avons vu comment créer assez simplement et très rapidement quelques conteneurs pour faire tourner un LAMP et l’administrer. Vous êtes maintenant en possession d’une architecture LAMP multi-tenante et capable de déployer à l’infini votre solution pour vos clients.

De plus, vous allez pouvoir tester de façon assez simple la migration des applicatifs que vous utilisez (Apache, PHP, MySQL, phpMyAdmin, etc…) en jouant sur les versions des images. Le retour arrière étant quasi instantané.

Aller plus loin ?

  • Utilisation de docker-compose pour lier tous ces conteneurs automatiquement.
  • Mise en place d’un container Apache reverse proxy pour n’avoir qu’un port d’écoute sur la machine host.
  • Utilisation d’un conteneur de données pour la persistance de MySQL

En attendant de vous proposer la conteneurisation d’une architecture un peu plus complexe, qu’allez-vous conteneuriser maintenant ?

 

Console2 – enfin une console pour MS Windows

21 April 2015 par SeB Pas de commentaire »

Si votre poste de développement tourne sous MS Windows, la console de ligne de commande par défaut cmd.exe n’est pas l’outil qui permet la plus grande productivité. Il existe bien Cygwin mais je trouve ce programme trop intrusif.
Il y a de fortes chances pour que vous utilisiez le client Git pour Windows : msysGit. Cet outil propose une console de type GNU/Linux mais ce n’est qu’une simple personnalisation de la console MS Windows. Et cela se sent à l’usage…

J’ai récemment découvert Console2 qui permet de personnaliser msysGit. On s’éloigne ainsi un peu plus de cmd.exe et on se rapproche encore un peu de la console classique de GNU/Linux.

Installation

Vous l’avez sûrement compris. Il faut installer msysGit et Console2.

Configuration

Personnalisation de la console

Par défaut Console2 utilise le shell de MS Windows. Pour utiliser msysGit il faut lancer Console2 puis aller dans le menu Settings > Console et sélectionner le programme bash.exe se trouvant dans le répertoire bin de l’installation de msysGit en ajoutant à la fin les options –login -i. Relancer Console2 pour bénéficier de msysGit.

Personnalisation du bash

Créer /etc/bash_profile avec le contenu suivant :

HOME="/home/monutilisateur"

Puis créer le fichier /home/monutilisateur/.bash_profile suivant :

# Custom prompt "monutilisateur@monserveur:monrepertoire"
PS1='\[\e[32;1m\]\u\[\e[31;1m\]@\H\[\e[34;1m\]:\w\[\e[37;1m\] $ \[\e[0m\]'

# Aliases
alias ll='ls -laF --color --show-control-chars'

# Default folder
cd ~

Libre à vous d’ajouter toutes les personnalisations que vous souhaitez !

Configuration de l’éditeur

Si vous utilisez un éditeur de fichiers tel que SublimeText, vous souhaiteriez peut-être éditer simplement un fichier depuis la console. Pour celà, ajouter dans /etc/bash_profile (en supposant que SublimeText est installé dans C:\Programmes\SublimeText3) :

export PATH=$PATH:/c/Programmes/SublimeText3

Puis ajouter dans /etc/monutilisateur/.bash_profile :

alias sbt='sublime_text'

Après la réouverture de la console, il est possible d’ouvrir un fichier avec SublimeText avec la commande suivante :

sbt monfichier

Aller plus loin

Console2 permet de configurer pleins de “petits” détails tels que :

  • La position et la taille par défaut de la fenêtre
  • La transparence de la fenêtre
  • Le caractère de fin de ligne par défaut
  • Les raccourcis (CTRL + F1 par exemple pour ouvrir de nouveaux onglets)

Conclusion

Avec ces 3 outils (msysGit, Console2 et SublimeText), vous allez augmenter significativement votre productivité sous MS Windows tout en gardant un certain confort. 😉 Avez-vous d’autres outils qui permettent d’approcher de la productivité des systèmes GNU/Linux tout en restant sous MS Windows ?

 

Docker 1.6

18 April 2015 par SeB Pas de commentaire »

Une nouvelle version de la plate-forme de conteneurs Docker est disponible. En effet, l’équipe Docker vient d’annoncer la publication de Docker 1.6 qui comprend :

  • Docker Engine 1.6
    • Ajout de libellés sur les images et les conteneurs
    • Préversion du client Windows
    • Ajout de drivers de logging
    • Ajout d’un adressage des images via des digests
    • Ajout de l’option –cgroup-parent
    • Définition du ulimit par défaut
    • Application de modifications sur une image existante à partir d’un Dockerfile
  • Registry 2.0
    • Pulls plus rapides
    • Ajout de webhooks
    • Support natif du TLS
  • Compose 1.2
    • Ajout de la fonction “extends” pour partager des configurations ou gérer les multi-environnements
  • Swarm 0.2
  • Machine 0.2

La mise à jour sur Ubuntu est simple :

# apt-get update && apt-get upgrade lxc-docker

 

L’ajout d’une gestion de drivers de logging est très intéressant. Il va falloir suivre les implémentations qui seront proposées.

La fonction “extends” a été ajoutée pour répondre à 2 besoins :

  • Le partage de configuration entre applications
  • La configuration multi-environnement pour une même application

Autant, le premier besoin doit être adressé par Docker. Autant, on est en droit de se demander si c’est à Docker Compose de gérer la problématique de la configuration des environnements…

Il nous reste plus qu’à tester tout cela !

 

Docker – en route pour la SOA et les micro-services !

25 November 2014 par SeB Pas de commentaire »

Comme certains l’on déjà pu annoncer, la révolution Docker est en ordre de marche. Je n’ai pas encore pris le temps de bien expliquer ce qu’était Docker. En revanche, voici quelques avantages et surtout les impacts que cet outil peut avoir sur l’architecture de vos solutions.

VMs légères ?

Docker n’est pas une solution de VMs mais de containers. Cependant, la comparaison est facile et tout le monde est tenté de la faire. Dans un souci de vulgarisation, on peut donc s’autoriser à dire que Docker permet de créer des VMs très légères :

  • en terme d’espace disque : l’image du container n’embarque pas tout l’OS et le découpage en couche des images permet de réduire d’espace occupé pour leur stockage
  • pour la rapidité de démarrage : un container démarre en quelques secondes (c’est l’applicatif qui prend le plus de temps à démarrer)
  • avec une performance accrue : il n’y a plus d’émulation d’OS, l’overhead est donc réduit et les performances disque et réseaux semblent au rendez-vous

Un déploiement universel ?

L’avantage principal des containers réside dans leur promesse : développez une fois, déployez n’importe où !
Effectivement, jusqu’à présent, nous devions packager nos applications à partir des sources et fournir un ensemble de fichiers de configuration et de scripts de déploiement pour des livraisons sur les environnements autre que le développement. Avec Docker, tout celà est terminé. Vous définissez une fois pour toute l’éco-système de votre application (OS, applications et configuration) pour générer une image auto-suffisante. Vous l’enregistrez sur un dépôt partagé. Ensuite, n’importe quel système ayant Docker d’installé et un accès au dépôt peut déployer l’application sans avoir à lancer l’installation ou la configuration de quoi que ce soit. Adieu les erreurs de déploiement !

On peut rapidement imaginer le workflow à mettre en place pour faire au minima du continuous delivery mais surtout du continuous deployment !

Une nouvelle architecture ?

Pas si sûr…

Les containers Docker ne permettent pas de persister un état. Il faut passer par des services externes (d’autres containers ou des volumes) très faciles à mettre en place avec le système de liens inter-containers.
Si l’on ajoute les contextes d’exécution légers (pour ne pas parler de VMs :-P) et le déploiement aisé, il en résulte qu’un container doit contenir une portion de code très petite et doit être concentré sur un rôle (du métier) bien particulier. Or quelle architecture propose de décomposer un service métier de haut niveau (l’application) en un assemblage de composants indépendants et organisés par silo (les containers) ? Oui, oui. On parle bien de SOA ici.

Par ailleurs, le système de mise à jour des images Docker, permet de mettre à jour sans risque un composant qui tourne dans un container indépendant sans impacter le reste du système.

Enfin, la capacité de Docker à isoler les composants, à les déployer n’importe où et à favoriser le packaging de composants réutilisables (via des containers multi-tenants) avec un périmètre très limité, tend à aller au délà de la SOA en implémentant des micro-services !

Ces ressentiments m’ont été confirmés à la lecture de Docker: VMs, code migration and SOA solved. J’espère que cet article vous laisse entrevoir un début des possibilités offertes par Docker.

 

Docker – construction automatique sur Docker Hub

31 October 2014 par SeB Pas de commentaire »

Comme évoqué précédemment, Docker propose un dépôt d’images publiques. Après s’être inscrit sur ce Docker Hub, vous pouvez partager vos images Docker via la commande suivante :

$ sudo docker push votrelogin/votreimage

Cependant, Docker Hub permet également de construire automatiquement vos images à partir de vos sources (depuis GitHub ou Bitbucket). Pour celà, il faut se rendre sur la page de vos dépôts d’images, cliquer sur “Add”, puis choisir “Automated Build”. Ensuite, il faudra choisir votre hébergeur de sources et enfin votre dépot Git contenant vos sources. Seul le fichier Dockerfile est obligatoire. Mais la présence d’un README.md permet d’afficher automatiquement une description de votre image sur le Docker Hub.

Avec cette fonctionnalité de construction automatique, Docker Hub déclenche automatiquement un build de votre image dès que vous faites un commit sur votre dépôt de sources. Votre dépôt d’images Docker se synchronise donc tout seul avec votre dépôt de sources Git.

Une documentation explique plus en détail comment fonctionne la construction automatique d’image Docker.

raml-logo

J’ai testé cette fonctionnalité pour l’image de l’api:Console. Vous pouvez donc tester le déploiement de cette image via les commandes suivante :

$ docker pull slecache/api-console
$ docker run -p 9000:9000 -d slecache/api-console

Pour information, les sources sont disponibles sur GitHub et l’image sur Docker Hub.

A vos remarques et éventuelles contributions ! :-)

PS : Tiens donc ! Après une recherche sur Docker Hub pour trouver ma propre image, je me suis rendu-compte que quelqu’un a eu la même idée que moi aujourd’hui… 😮

 

Docker – premier container pour l’api:Console

30 October 2014 par SeB Pas de commentaire »

raml-logoSi vous me lisez, vous avez pu remarquer lors de mon article sur Vagrant vs Ubuntu vs NPM vs Bower que j’utilise l’api:Console de MuleSoft pour déployer en ligne de la documentation au format RAML pour des APIs REST.

Cette console tourne correctement dans Vagrant mais je ne suis dis que la création un container pour cette application serait une première application de Docker judicieuse et adaptée. :-)

Recherche d’une Base Docker Image

La première étape est de vérifier s’il n’existe pas déjà un container qui le fait déjà dans le Docker Hub Registry. Je n’ai rien trouvé.

Ensuite, avant de construire une image à partir de rien, il est plus rapide de se baser sur une image existante. L’api:Console nécessite l’installation de Node.js, Bower et Grunt. Justement, Docker propose eux-même une image avec ces outils : dockerfile/nodejs-bower-grunt. Nous allons donc la réutiliser.

Construction de l’image Docker

Afin de capitaliser sur la construction de cette image, nous allons utiliser un Dockerfile :

FROM dockerfile/nodejs-bower-grunt
MAINTAINER John DOE "xxxxxxxx@gmail.com"

# télécharge la dernière version de l'api:Console pour RAML
RUN git clone https://github.com/mulesoft/api-console.git /data

# installe les dépendences NPM et Bower
RUN npm install
RUN bower install --allow-root

# modifie la page d'accueil de la console pour pointer sur un sous-répertoire "apis" avec un fichier "main.raml"
ADD index.html /data/app/
# modifie la configuration du serveur pour activer le live-reload sur tous les fichiers du sous-répertoire "apis"
ADD Gruntfile.js /data/
# ajoute une documentation RAML d'exemple
ADD main.raml /data/app/apis/
# déclenche la copie de toute la documentation pour les images se basant sur notre image
ONBUILD ADD . /data/app/apis/

EXPOSE 9000
EXPOSE 35729

# démarre le server Node.js
ENTRYPOINT ["grunt", "server", "--force"]

Quelques explications sur l’instruction ONBUILD. Cette instruction n’est pas exécutée lors de la construction de l’image. Elle le sera lors de la construction d’image utilisant notre image. Ainsi, il sera possible de créer de nouvelles images à partir de celle-ci. Toute la documentation RAML sera alors automatiquement copiée dans le répertoire /data/app/apis du container et donc pris en compte par l’api:Console.

Maintenant, construisons l’image avec cette commande :

$ docker build -t mycompany/api-console

Déploiement du container

Standard

Si l’on souhaite déployer ce container en production, il suffit d’exécuter la commande suivante :

$ docker pull mycompany/api-console
$ docker run -p 9000:9000 -d mycompany/api-console

Rendez-vous sur votre serveur (sur le port 9000) pour admirer la superbe documentation ! 😮

Avancée

En phase de développement conception, cette documentation est amenée à changer souvent. Le rédacteur souhaite valider l’affichage de sa documentation avant de la commiter. Alors au lieu de reconstruire l’image à chaque fois que l’on modifie un fichier, nous allons monter un volume qui va surcharger le répertoire qui contient la documentation RAML ainsi :

# le répertoire /Users/myproject/doc-raml contient les fichiers éditables (dont main.raml)
$ docker run -v /Users/myproject/doc-raml:/data/app/apis --name RAML-DATA busybox true
$ docker run --volumes-from RAML-DATA -p 9000:9000 -p 35729:35729 -d mycompany/api-console

Grace à l’activation du live reload sur le répertoire /data/app/apis, une modification d’un fichier sur le host est directement prise en compte dans le container et donc sur dans le navigateur sans rechargement.

Création d’une image spécifique

Nous avons vu que l’image précédemment créée a été pensée pour être réutilisée. Créons donc un nouveau fichier main.raml (contenant la documentation de votre choix) et le Dockerfile suivant :

FROM mycompany/api-console
MAINTAINER John DOE "xxxxxxxx@gmail.com"

Construisons notre nouvelle image pour notre projet :

$ docker build -t mycompany/api-console-myproject

Démarrons le container :

$ docker run -p 9000:9000 mycompany/api-console-myproject

L’api:Console est déployée et contient la documentation spécifique à notre projet. Notez qu’il est toujours possible aux rédacteurs de cette dernière d’utiliser l’astuce de montage d’un volume pour pouvoir la modifier en direct sans avoir à reconstruire et redéployer le container.

Conclusion

Cet exemple est le cas classique où un container Docker est pertinent :

  • installation d’un serveur web (avec des dépendances plus ou moins simples à installer)
  • installation d’une application web (avec construction et configuration)
  • déploiement (avec de multiples instances)

Ainsi, au lieu de suivre une procédure d’installation (où l’erreur peut être humaine) ou d’exécuter un script de provisionning (qui peut échouer selon l’environnement), il est maintenant possible de lancer simplement une unique ligne de commande pour avoir notre serveur en ligne !

La prochaine étape (pour moi) est de publier cette image sur le Docker Hub Registry avec les sources complètes et la documentation…

 

Docker – arrêter et supprimer tous les containers

29 October 2014 par SeB 2 commentaires »

Quand on débute avec Docker, on fait plein de tests ou d’essais ratés. On perd rapidement le fil de l’état des containers déployés. Il y a donc un moment où l’on souhaite repartir à zéro en arrêtant tous les containers et en les supprimant. Pour celà, il suffit d’exécuter les 2 commandes suivantes :

$ docker stop $(docker ps -a -q)
$ docker rm $(docker ps -a -q)

Un petit coup de propre ne fait pas de mal 😉

 

Docker – répertoire Windows partagé dans boot2docker

27 October 2014 par SeB Pas de commentaire »

Comme vous avez pu le supposer avec mon dernier billet, je me suis mis sérieusement à Docker. Travaillant sous Windows (oui, oui… chacun son fardeau !), nous devons utiliser boot2docker pour construire des images et déployer des containers. Boot2docker est une VM GNU/Linux très petite (environ 20Mo) pour VirtualBox qui contient le serveur et le client Docker pour construire des images et manipuler des containers.

6394678

Quand on commence à jouer avec Docker, on récupère des images sur les dépôts distants. On tente la création de Dockerfile. Tout ce passe dans la VM de boot2docker. Ce qui pose rapidement 2 soucis :

  • stocker/archiver les tests : on peut passer par un SCM distant (comme GitHub)
  • utiliser les outils de développement de la machine host : certains utilisent un éditeur avec un mode FTP ou un partage samba (mais il faut avouer que ce n’est pas pratique)

En cherchant rapidement, il est possible de trouver des articles qui proposent de monter un partage entre la machine host (Windows ou Mac) et la machine guest (VM boot2docker). Comme la procédure ne fonctionne pas du premier coup, voici deux méthodes différentes pour arriver à nos fins.

Objectif

L’ojectif est de pouvoir éditer sur Windows des fichiers Dockerfile et autres ressources pour la construction d’une image Docker et de pouvoir construire l’image sans devoir transférer les fichiers entre Windows et boot2docker.

Boot2docker avec VirtualBox guest additions

La première solution consiste à modifier la VM de boot2docker. Pour celà, il faut télécharger une version de la VM qui supporte les options de VirtualBox (connues sous le nom de “VirtualBox guest additions”).

Ensuite, il faut remplacer l’image officielle qui se trouve dans c:\Users\[Votre login]\.boot2docker\boot2docker.iso par la non-officielle tout juste téléchargée.

Avant de configurer la VM, il faut s’assurer qu’elle est arrêtée avec la commande suivante :

boot2docker stop

Maintenant, nous pouvons demander à VirtualBox de faire pointer le répertoire monté sur le répertoire de la machine host avec la commande suivante :

C:\Program Files\Oracle\VirtualBox\VBoxManage.exe sharedfolder add boot2docker-vm -name home -hostpath C:\[Votre répertoire]

Enfin, vous pouvez démarrer boot2docker et vous y connecter :

boot2docker up
boot2docker ssh

Pour information, votre répertoire partagé est monté dans le répertoire /Users.

Si jamais le répertoire est vide, arrêtez votre VM puis lancer la commande suivante :

C:\Program Files\Oracle\VirtualBox\VBoxManage.exe sharedfolder remove boot2docker-vm -name c/Users

Vous pouvez à nouveau tester l’accès à votre répertoire. Si malgré tout vous n’arrivez pas à accéder à votre répertoire Windows dans la VM de boot2docker, n’hésitez pas à redémarrer votre OS host. Vérifiez également que vous utilisez la dernière version de VirtualBox (4.3.18 lors l’écriture de cet article).

Votre boot2docker vous résiste ? Avant de tout lancer par la fenêtre, je vais vous proposer une solution plus simple qui fonctionne très bien.

Boot2docker avec Vagrant

Par défaut Vagrant partage le répertoire courant du host dans le répertoire /vagrant de la VM. Alors pourquoi ne pas lancer boot2docker avec Vagrant ? Rien de plus simple avec les commandes suivantes :

# l'image d'origine avec docker 1.2.0
$ vagrant init mitchellh/boot2docker
$ vagrant up
$ vagrant ssh

# l'image modifiée avec docker 1.3.0
$ vagrant init yungsang/boot2docker
$ vagrant up
$ vagrant ssh

Mission accomplie !

Je n’aurais rien de mieux à ajouter que :

                        ##        .
                  ## ## ##       ==
               ## ## ## ##      ===
           /""""""""""""""""\___/ ===
      ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ /  ===- ~~~
           \______ o          __/
             \    \        __/
              \____\______/
 _                 _   ____     _            _
| |__   ___   ___ | |_|___ \ __| | ___   ___| | _____ _ __
| '_ \ / _ \ / _ \| __| __) / _` |/ _ \ / __| |/ / _ \ '__|
| |_) | (_) | (_) | |_ / __/ (_| | (_) | (__|   <  __/ |
|_.__/ \___/ \___/ \__|_____\__,_|\___/ \___|_|\_\___|_|
boot2docker: 1.3.0

A très bientôt au milieu de tous ces containers !

 

Docker – au revoir les VMs, bonjour les containers

22 October 2014 par SeB Pas de commentaire »

Le projet Docker est solution de « containerisation » publiée sous licence OpenSource il y a un an et demi et qui fait énormément parler de lui depuis un an.

Il est déjà utilisé par de nombreux actueurs majeurs du web tels que : Google, Spotify, Red Hat, AWS, Baidu, etc…

Au début du mois, OVH (3ième hébergeur mondial) a annoncé l’arrivée de Docker dans leur offre cloud RunAbove. Une semaine plus tard, cette solution double quasiment la taille de son parc potentiel en signant un partenariat avec Microsoft pour Windows Server et Azure.

Du côté de la communauté, Docker c’est plus de 11 000 commits, plus de 600 contributeurs et plus de 3 000 forks !

Tous ces signes montrent qu’il est temps de se lancer dans l’aventure ! A première vue, Docker va nous obliger à revoir nos modèles d’architecture… J’espère y revenir très bientôt. 😉

Et pour ceux qui pensent que Docker n’est qu’un jouet pour DevOps, voici 8 cas concrets d’utilisation.

En avant pour la révolution Docker !