Astuce - lancer un conteneur docker comme un service système

le 8 octobre 2015, par Jean-Philippe Caruana

Je ne vais pas ici vous faire une introduction à docker, ce n'est pas l'objet de ce post.

Je trouve personnellement docker très pratique en particulier pour essayer des logiciels dans des versions différentes (par exemple la base de données dans sa toute nouvelle version avant de la déployer en production) et de pouvoir revenir en arrière en cas de pépin. Le tout sans casser son système d'exploitation. Par contre, au début, je me suis souvent fait mordre par l'espace disque. J'ai ainsi appris dans la douleur l'option -v (comme volumes) de la commande docker rm (je vous invite à consulter la documentation) pour tout nettoyer à la suppression d'un conteneur.

En revanche, cela m'embêtait de plus en plus de devoir démarrer à la main les conteneurs dont j'ai besoin, d'oublier de les arrêter quand j'éteinds ma machine, etc. J'ai donc voulu me plonger un peu dans systemd qui vient désormais en standard dans les dernières version d'Ubuntu, et j'ai été ébloui par sa simplicité de mise en oeuvre.

Dans cette page, nous allons prendre l'exemple de la dernière version (à ce jour) de MongoDB : la 3.0.6.

Une fois votre image mongo installée (avec la commande docker pull mongo:3.0.6) en local, voici le fichier mongo.service que je vous invite à copier dans /etc/systemd/system/mongo.service :

[Unit]
Description=Mongo container
Requires=docker.service
After=docker.service

[Service]
ExecStart=/usr/bin/docker run -p 27017:27017 --name mongo mongo:3.0.6 --storageEngine wiredTiger
ExecStartPost=/bin/sleep 1

ExecStop=/usr/bin/docker stop mongo
ExecStopPost=/usr/bin/docker rm -v mongo

[Install]
WantedBy=multi-user.target

Cela démarre l'image mongo en version 3.0.6, fait correspondre le port 27017 du conteneur sur le même port de ma machine, et lance mongo avec le nouveau moteur Wired Tiger. Ensuite, à l'arrêt du service, le conteneur est entièrement détruit (les données de mongo aussi).

Pour démarrer le service, 2 options :

  • sudo service mongo start
  • sudo systemctl start mongo.service

(pour l'arrêter... c'est la même chose mais avec la commande stop bien sûr).

Enfin, pour lancer ce mongo au démarrage de votre machine, il faut lui dire ceci :

sudo systemctl enable mongo.service

Voilà ! Rien de plus simple comme on peut le voir. Je vous laisse pour exercice la conversion pour un MySQL, un redis, un Cassandra ou encore pour un système avec upstart (indice).

MongoDb le cluster qui bagote, la suite

le 23 septembre 2015, par Bruno Thomas

Suite de notre épisode précédent sur les bagots mongo, nous reprenons où nous nous étions arrêtés : nous avons un test d'acceptance instable et nous avons acquis la certitude que le cluster mongo en est la cause. Soit il est mal configuré soit buggué.

Être alerté en cas de OutOfMemoryException

le 7 septembre 2015, par Jean-Philippe Caruana

Un des plus grands dangers quand on exploite un service en production, c'est de ne pas être au courant qu'un problème a eu lieu. Un des problèmes graves que l'on peut rencontrer est l'arrêt d'une JVM qui n'a plus assez de mémoire disponible. D'innombrables causes peuvent en être l'origine, mais ce n'est pas le sujet de ce billet. Ici, nous allons voir comment en être alerté, afin de pouvoir réagir (relancer le service par exemple). Il faudra ensuite que l'équipe se penche sur le problème pour éviter que cela ne se reproduise.

Optimiser son client ssh

le 25 août 2015, par Jean-Philippe Caruana

Dans mon travail quotidien, je me connecte très souvent à une multitude de serveurs, que ce soit pour aller sur le serveur de logs, pour faire une mise en production ou faire de la maintenance système. Je me connecte également très souvent (sans le savoir) aux serveurs de github à chacune de mes actions git pull et git push.

Retour sur l'Agile Conférence 2015

le 8 juillet 2015, par Bruno Thomas

La semaine dernière, nous avons retrouvé les oies et les canards du chalet de la porte jaune pour la 10e édition de la conférence agile (anciennement XP Days), pour une thématique "par delà l'agilité". Retour sur ce que nous avons retenu de l'ère post-agile, avec notre filtre forcément subjectif.

Le bagot du jour de l'an ou l'assert laxe

le 8 janvier 2015, par Bruno Thomas

Le 2 janvier est propice à la chasse au bagot : il est fréquent de rentrer encore un peu barbouillé des fêtes de fin d'années et d'être accueilli par une intégration continue rouge. Tests qui ne fonctionnent qu'en année bissextile, année codée en dur, numéro de mois qui va de 0 à 11, toutes les raisons sont bonnes.

Astuce - laisser nginx répondre robots.txt

le 7 janvier 2015, par Jean-Philippe Caruana

Sur le service sur lequel je travaille, j'ai observé de nombreuses erreurs 500 suite à des tentatives du Google Bot de trouver le fichier /robots.txt. Voici par exemple une log d'erreur de nginx :

Git - le message systématique qui agace

le 19 décembre 2014, par Jean-Philippe Caruana

A chaque git fetch ou git pull --rebase ou encore git merge branche, j'avais un message agaçant, même quand il n'y avait rien à faire (branche à jour). Par exemple :

Migrer un blog de Wordpress vers Jekyll

le 11 décembre 2014, par Jean-Philippe Caruana

Suite à la migration de notre blog vers un jekyll hébergé chez github, je vous propose quelques explications sur le sujet. Dans cet article, nous verrons :