Monthly Archives: mai 2017

Mon passage à Docker et CoreOS

Depuis plusieurs mois / années, j’entends parler de Docker. Comme j’ai un serveur dédié avec plusieurs services indépendants, je m’intéresse un minimum aux solutions techniques envisageables.
Je n’ai pas tout de suite compris l’intérêt de Docker. À l’époque, j’utilisais Proxmox avec des containers LXC pour isoler mes services. Et pour moi c’était la solution idéale. Simplicité du déploiement, facilité de faire des sauvegardes, légèreté par rapport à des VM lourdes… Du coup quand j’ai considéré Docker, il fallait vraiment qu’il ait de bons arguments pour me convaincre.

Pourquoi migrer vers Docker

En dehors du faite d’apprendre quelque chose de nouveau bien entendu, ce qui m’a vraiment décidé à passer à docker c’est la quantité de templates disponible. Avec Docker, il est extrêmement facile de partager un environnement, et ils foisonnent sur github. Quand j’utilisais LXC, il fallait la majorité du temps que je configure moi-même tous l’os et les services à l’intérieur du container.
Prenant un exemple simple : ARK. ARK est un jeu en ligne multijoueur. Il est possible d’héberger soit même des serveurs et afin de jouer avec des amis, j’avais commencé à configurer un container pour jouer. Et ce fut un calvaire. Au moment oü j’ai commencé a regardé, il y avait encore très peut de retour d’expérience sur la mis en place se serveur sous Linux et auprès des heures de recherches et d’essaies, j’ai fini par abandonner. Avec docker, je trouve facilement sur Github des personnes qui ont pris le temps de fourni des templates pour installer rapidement un serveur ARK.

Un autre argument, c’est la maintenance. Avec LXC, si j’ai besoin de mettre moi-même à jour mes services au sein d’un container. Alors oui il est possible de mettre à jour automatiquement le système, mais comment mettre à jour automatiquement wordpress par exemple ? Ce n’est pas forcement un paquet et dans ce cas la mise à jour passe par la récupération et le remplacement des sources. Alors oui WordPress est bien pensé et il st possible de faire la mise a jour directement depuis le site, mais ça demande une action de notre part et chaque service qu’on installe aura son propre mécanisme. Ce que je cherchais, c’était un moyen de mettre à jour tous mes services installé sur mon serveur de manière automatique et transparente.
Avec docker, il suffit de récupérer la dernière image du service que l’on utilise pour le mettre à jour. Un simple docker pull et le tour est joué.

Pourquoi migrer vers CoreOS

La décision d’utiliser Docker ne fait pas tout. Il faut aussi choisir le système host qui hébergera les différents services. Proxmox me plaisait vraiment beaucoup pour LXC pour son interface web. J’ai donc cherché une interface web pour Docker. Et je cherche toujours…
J’en ai essayé des dizaines en passant de Panamax à Rancher et de Mist.io à Shipyard. Aucune ne m’a convaincu. C’est le principal frein que j’ai rencontré avant de sauter le pas. Mais j’ai fini par faire mon deuil.
Alors pourquoi CoreOS ? Pour plusieurs raisons plus ou moins bonnes. Tout d’abord il faut parti des OS qu’il est possible de préinstallé sur mon serveur dédié chez Online.net. Ensuite c’est un OS spécialisé pour utiliser Docker. CoreOS propose beaucoup de solutions que je n’utilise pas. Par exemple il est possible de faire communiquer des flottes de serveurs installés sur CoreOS pour se répartir la charge. CoreOS ne propose pas de gestionnaire de paquets. Mais alors, comment installer votre éditeur favori pour modifier un ficher ? En passant par un container ! Avec la commande toolbox, il est possible de démarrer un container tournant sous Fedora dans lequel vous pourrez installer tout ce qui vous fait plaisir sans polluer l’host !

Configuration des nouveaux services

J’ai commencé à chercher les templates docker des services dont j’avais besoin comme wordpress, ts3, ou encore plex.
J’ai ensuite démarré et configuré les containers en local en important les données de chaque service depuis mon serveur. J’ai bien entendu pris soin de m’assurer que chaque service mount un dossier depuis l’host pour stocker configuration et données.
Cette manière de faire le permet de n’avoir à backuper que les données / paramètres qui m’intéresse. Pour simplifier davantage, j’ai suivis une convention pour localiser les dossiers de l’host qui sont montés dans les guest. J’ai un dossier ~/to_backup/ qui doit être backuper et un ~/no_backup/ qui n’a pas besoin d’être backuper. Mais pourquoi monter des dossiers qui ne sont pas à sauvegarder ? Pour partager des données entre containers. Par exemple j’ai un container qui se charge de récupérer le contenu diffusé par Plex. Ce n’est pas pour autant que je souhaite sauvegarder ce contenu. Récemment j’ai appris une autre manière de faire des volumes partageables entre containers, mais la solution que j’ai retenue, même si ce n’est pas la meilleure, fonctionne.

Mise en place des services sur le dédié

Afin que les containers docker redémarrer automatiquement en cas de redémarrage du CoreOS (par exemple quand le Kernel est mis a jour), il faut créer des fichiers .service a positionné dans /etc/system/systemd/. Vous trouverez plus d’information sur comment écrire ces fichiers, mais c’est relativement simple :

[Unit]
Description=TS3
After=docker.service
Requires=docker.service

[Service]
TimeoutStartSec=0
ExecStartPre=-/usr/bin/docker kill ts3
ExecStartPre=-/usr/bin/docker rm ts3
ExecStartPre=-/usr/bin/docker pull linuxserver/gsm-ts3
ExecStart=/usr/bin/docker run –name ts3 –net=host -v /home/core/to_backup/ts3_config:/config linuxserver/gsm-ts3

[Install]
WantedBy=multi-user.target

Afin de ne pas perdre ces fichiers en cas de défaillance du disque de mon dédié, mais aussi pour simplifier le déploiement, je fais un lien hard dans ~/to_backup/.

Une fois que tous mes services fonctionnaient bien en local, j’ai fait un gros zip de ~/to_back/, que j’ai uploadé sur mon dédié. J’ai décompressé le tout et c’est parti !

En espérant avoir pu vous aider

Julien