Docker, World of Container

Allez direct on fait péter un titre completement dingue, quoi ? tu aime pas ? tant pis 🙁

Ok ça commence mal … sinon de quoi on parle aujourd’hui père castor ?

Roh t’es toujours aussi rabat joie toi, t’étais cool avant 😀

Sinon aujourd’hui on va parler de Mobidic… ah non oui c’est Docker (avouez qu’on peu se tromper hein).

Kesako ?

Docker est la techno qui permet aux devs de faire le taff des ops (m’en fou moi je faisais les deux :D) les dev fournissent des images que tu as juste a lancer pour que ta stack se monte et c’est partie comme un ouf pas besoin de chercher les bonnes dépendances de projet n’y rien tout est dans le(s) container(s)

l’idée derrière ça est d’isoler tes services ton container qui fait tourner ton serveur de base de donnée il ne fait que ça du coup si il est compromis bah il peut rien casser d’autre (on revient un peu dans le « chroot » en plus avancé).

Ca marche bien, c’est sécurisé ?

C’est basé sur LXC (un ensemble de techno du kernel (Linux hein pas Darwin :o), docker utilise LXC pour que tes containers ai leurs propre user-space … etc mais puisse quand même accéder aux ressources matériel sans perte.

Niveau sécurité bon c’est a toi de voir, il est très facile de faire de l’escalade de privilège avec docker, il y a un daemon qui tourne en root qui s’occupe de crée les container, télécharger les images, gérer les volumes (Voir plus bas), lancer les container … etc, ce daemon écoute sur un socket unix et donne les droits en lecture / ecriture sur ce socket aux utilisateurs du groupe « docker », avec le client qui envoie les commandes aux daemon

Chaque container est par défaut lancer avec les droits root ($UID = 0) du coup ça veut dire qu’un utilisateur du groupe « docker » sur l’hôte même si il n’est pas dans le groupe de « sudo » il fait ce qu’il veut du genre

Ici l’utilisateur du groupe docker lance un nouveau container de type interactif (il ne se met pas en tache de fond) avec le « -it », le container va se suicider une fois quitter (il ne reste pas dans la liste des container crée) avec la commande –rm, il va monter la racine de l’hôte dans /host (en ROOT) et lancer un shell bash, on se base ici sur une ubuntu (osef).

Et bim l’utilisateur arrive dans un shell et si il fait cd /host il a le système de fichier de l’hôte avec tous les droits dessus.

Mais bien sur a la création de l’image il est possible de forcer le lancement du container avec un user prédéfinit, une image se crée a l’aide d’un docker-file celui-ci prépare l’image en fonction des commandes du dockerfile.

Tu parlais de volumes ?

Quand on lance un container basé sur une image par défaut toutes les modifications faites dedans sont « oublié » une fois le container stoppé, a moins de commit (oui comme git) les modifications. pour ça on utilise des « volumes » qui sont ni plus ni moins l’écriture des données qui changent (base de donnée, logs … etc) sur le volume de l’hôte et donc a chaque lancement on récupère ces precieuses données.

Un dockerfile est une suite d’instruction et pour chaque instruction on crée un « commit » donnant l’image finale une fois les commit telechargé bou a bou.

Pas de tuto ?

Non, internet regorge de tuto sur Docker, perso je voulais faire cet article car j’adore la technologie elle est pas parfaite mais c’est un vrai plaisir de pas se prendre la tête lors du déploiement, par exemple besoin de Redis dans un projet mais il n’est pas installé sur le serveur de prod ? on s’en tappe, il y a un container pour ça 😉

Pour plus d’exemples dockerien, jettez un oeil a mon Github il y a plusieurs dockerfile et docker-compose

bye bye

Vous avez aimé cet article ? Partagez-le :)

Facebook Google Plus Twitter Linkedin email

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *