C'est qui ce... Docker ?

Nh3xus, je vais voir si on se chauffe pour faire une blog post quand on aura un peu plus d'une semaine de retour d'expérience sur le truc.

On est sur EC2/ECS avec avec docker-compose et bientôt docker-swarm (à travers la CLI Amazon). Y'a une bonne partie du process de provisionning qui est manuelle et on va automatiser tout ça, donc pour l'instant pas d'API, enfin à travers ces commandes quoi, mais ça devrait bouger.

Je posterai des news ici si y'a des trucs intéressans à dire.

J'ai lu la page Wikipédia, mais j'ai pas bien compris exactement à quoi peut vous servir Docker.
Expliquez moi ça comme si j'avais 5 ans spv.

@[deban]_Dakien Tu vois comme tu te fais chier quand tu dois compiler certains softs puis qu'il te manque des outils de dévelopement, puis des librairies, puis les headers qui vont avec, et ainsi de suite, et que à chaque fois que tu fix un truc tu as une nouvelle erreur du genre jusqu'à ce que tu ais à peu près tout ce qu'il faut... quand tu te rends compte que ça compile quand même pas car tu as pas installé la bonne version d'une lib, ou pire que ça compile mais que tu te rends compte parfois à l'utilisation qu'il y a des comportements imprévus / crashs ?

Puis tu update ton système puis d'un coup ce que tu avais compilé marche plus ? Puis tu recompile puis ça merde pour une raison similaire ? Puis que tu te retape la même chose à chqaue mise à jour plus ou moins majeure du soft parce qu'il a changé de dépendances ?

Puis qu'un autre soft qui n'est pas packagé par ta distro et que tu as aussi besoin de compiler a des dépendances communes mais qu'il veut d'autres versions et que tu as des conflits et que tu dois te démerder pour installer les deux versions différentes dans deux dossier différents et modifier les LDFLAGS pour que ça trouve la bonne lib au bon endroit quand tu compiles ?

Et que ça fait la même chose avec les dépendances des dépendances des dépendances du soft que tu compile, et que tu te tapes la même merde récursivemet jusqu'à avoir traversé l'arbre de dépendances ?

Puis que à n'importe quel niveau tu peux avoir des dépendances pip, npm, ghc, composer, whatever plutôt que juste des librairies C. Et que tu as sensiblement les mêmes problèmes sauf que chacun a ces mêmes problèmes et solutions à sa propre façon et que tu dois tout réapprendre pour chaque gestionnaire de paquet que tu ne connais pas ?

Bah Docker est une solution populaire à ça. Au lieu d'avoir un programme et des dépendances, et toutes les merdes qui vont avec, tu configures un système complet (à partir d'une base plus ou moins vierge) qui contient juste le programme/service et ses dépendances et ainsi de suite, le tout dans des versions qui sont prévues pour bien marcher ensemble. Et tu distribues le système qui contient ton programme et ses dépendances plutôt que juste le programme.

Le problème en gros c'est qu'aujourd'hui la gestion de dépendances c'est putain de fucked up, et la solution que Docker apporte, plutôt que de résoudre la gestion de dépendance, c'est de distribuer un OS complet plutôt que juste ton programme.

C'est un peu comme si à chaque fois que tu "containerisais" un programme, tu créais ta propre variante *buntu, et que tu disais aux gens de l'installer pour utiliser ton programme.

Sauf que comme personne le ferait, le hack vise à runner ton *buntu à l'intérieur d'un système existant en utilisation la virtualisation niveau kernel (aka. conteneurs).

Et Nix, bah ça résoud le vrai problème, à savoir la gestion de dépendances. Et ça marche. Et on a pas tous les problèmes de Docker qui sont liés au fait que Docker corrige le problème à côté de la plaque.

Sauf que comme jusqu'à présent la gestion de dépendances / paquets est majoritairement fucked up bah Nix galère à décrire proprement les dépendances et les étapes de build d'un certain nombre de softs. Ou du moins ça a une certaine tendance à révéler des bugs dans les softs en question.

Du genre "ah tiens, curieux, ce soft a besoin de gcc au runtime".

Je suis bien bavard ce soir, ça doit être le Cognac qui me fait parler comme ça. ~:hap:~

Je viens de me rendre de compte qu'il y a un reCAPTCHA sauvage qui est apparu sur mon JVC depuis tout à l'heure je l'ignore aussi plus puissemment que les demoiselles m'ignorent en soirée et il a pas l'air de broncher. Amusant.

C'est un peu comme si à chaque fois que tu "containerisais" un programme, tu créais ta propre variante *buntu, et que tu disais aux gens de l'installer pour utiliser ton programme.

Pour ça qu'Alpine Linux existe.

Ce qui est génial aussi c'est :
https://hub.docker.com/explore/
Les miennes : https://hub.docker.com/u/wonderfall/
Je vais bientôt mettre tout en ligne. Mais j'ai vu des fous qui s'amusent à dockerizer Wine, Skype, etc. Passionnant.

Je suis pas sûr d'avoir tout compris... Faut que j'essaye je pense

Le 02 décembre 2015 à 07:46:10 [deban]_Dakien a écrit :
Je suis pas sûr d'avoir tout compris... Faut que j'essaye je pense

Docker c'est tout simplement de la paravirtualisation. Docker est 100% compatible GNU/Linux, OSX ça passe, Windows oui mais partiellement. Par contre pour BSD, le support vient à peiner d'arriver pour FreeBSD. Pour l'installation suffit d'installer le dernier binaire, de configurer le daemon, et c'est tout bon. Personnellement j'utilise overlay avec, de base Docker utilise aufs.

Je te propose une petite mise en pratique.
vava a parfaitement résumé la problématique. Docker facilite énormément le déploiement d'applications. Imaginons que tu veuilles par exemple déployer une instance Gogs via Docker. Naturellement, tu vas chercher sur le hub une image Gogs. Bingo, il en existe une officielle, et c'est gogs/gogs.
Tu vas donc télécharger l'image avec docker pull gogs/gogs. Il ne reste plus qu'à lancer un container à partir de cette image. Il faut savoir que l'activité d'un container est liée à sa commande définie lors que tu le lances avec run. Si le container n'a rien à faire, il ne peut être actif (mais tu n'as pas à t'en préoccuper, si l'image est bien faite...). Quand tu initialises ton container, tu peux lui définir plusieurs caractéristiques :
Son nom (--name)
Le port mapping (-p host:container).
Externalisation de dossiers, très utile (-v host:container).
Il en existe d'autres, mais ce sont là les principales.

Que tu le redémarres, que tu l'arrêtes, il conservera ces caractéristiques et ceci ne peut être modifié à moins de relancer un nouveau container. Par ailleurs, si tu veux mettre ton container à jour, il faut d'abord mettre ton image à jour, puis supprimer le container et en refaire un. Des outils facilitent ceci, mais quand tu débutes il te suffit simplement de noter tes commandes. Aucune donnée ne sera perdue puisque tu devrais externaliser ces données, et pour éviter des soucis d'incompatibilité, jouer avec les tags de l'image dès son téléchargement (c'est en gros, une version, parce que sinon tu auras toujours la dernière image avec un pull).

Pour résumer, voici comment tu initialises ton Docker Gogs :
docker run -d --name gogs -v /home/docker/gogs:/data gogs/gogs
Je crée le container (run) de nom gogs (--name gogs) et qui doit tourner en background (-d). De plus, je veux que /data (dossier du container) pointe vers /home/docker/gogs (qui est sur l'host, attention aux permissions avec le bon GID).

Pour le démarrer, l'arrêter, le redémarrer, supprimer : docker start/stop/restart/rm gogs
Pour administrer le container : docker exec -ti gogs /bin/sh
Voir les containers up/tout: docker ps/ps -a
Voir les images disponibles : docker images
En mettre à jour/installer une : docker pull image
Et en supprimer une : docker rmi image

Si tu supprimes le container, /home/docker/gogs/data ne sera pas affecté par la suppression. Tu peux par exemple lancer un container à partir d'une image à jour avec les mêmes paramètres, il tournera comme si de rien n'était.

Tip : comme on a pas utilisé de port mapping, on va utiliser nginx en reverse proxy. docker inspect gogs | grep '"IPAddress"' te retourne l'IP locale du container, il ne reste plus qu'à ajouter un reverse sur IP:80.

La grande puissance de Docker, c'est aussi la facilité avec laquelle tu peux créer des images. Pour build une image, il faut un Dockerfile, qui doit suivre une syntaxe précise mais simple. Tu peux te baser sur une image existante (tu devrais, même), et ensuite faire comme si tu installais un système fraîchement installé pour déployer une application. Pour automatiser tout ce processus, Docker Hub est là. Mais je ne rentre pas plus dans les détails, quand bien même ce serait un jeu d'enfant !

Et ça sort d'où ce produit miracle ?

Tu veux dire quoi par là ?

Qui c'est qui qui l'a inventé ?

C'est trop bizarre comme truc en fait... Je pourrais utiliser ça sur NetBSD pour installer tout et n'importe quoi qui n'est dispo sur NetBSD ?

Je ne sais pas qui l'a inventé.

C'est trop bizarre comme truc en fait... Je pourrais utiliser ça sur NetBSD pour installer tout et n'importe quoi qui n'est dispo sur NetBSD ?

Au contraire je trouve que c'est le truc le plus simple au monde.
Simplification énorme pour le déploiement.

Je ne sais vraiment pas si tu peux l'utiliser avec NetBSD. Comme dit, c'est de la para-virtualisation, pas de la virtualisation complète. Le container sait qu'il est un container et non un système pleinement émulé.
http://ippon.developpez.com/tutoriels/virtualisation/docker-presentation-part-1/images/1000020100000279000001629D2FA334.png
Pour mieux comprendre. Docker reposant énormément sur LXC, etc. J'ai franchement des doutes quant à la compatibilité hors GNU/Linux (là je ne peux pas t'aider, j'utilise avec Debian et CoreOS).

Tu peux grossièrement comparer son fonctionnement aux jails de FreeBSD.

Ça me rappelle Xen avec les domaines votre truc

Le 02 décembre 2015 à 06:03:25 vava740 a écrit :
je l'ignore aussi plus puissemment que les demoiselles m'ignorent en soirée

J'en peux plus

Je vais te l'emprunter celle-là.

Le 02 décembre 2015 à 18:47:55 [deban]_Dakien a écrit :
Ça me rappelle Xen avec les domaines votre truc

Non non ça n'a rien à voir, renseigne toi c'est intéressant

Du coup on fait tourner des systèmes dans un système ?

Mais en gros, c'est quoi l'intérêt de l'utiliser quand on a déjà tout les binaires bien empaqueté pour sa distribution (exemple Arch Linux) ? Ça apporte juste des logiciels non ? Si on les a déjà tous, ça sert à quelque chose ou c'est gadget ?

Le 02 décembre 2015 à 19:07:57 -Moopie- a écrit :

Le 02 décembre 2015 à 18:47:55 [deban]_Dakien a écrit :
Ça me rappelle Xen avec les domaines votre truc

Non non ça n'a rien à voir, renseigne toi c'est intéressant

Pourtant Xen est bien un para-virtualiseur... Je vois pas trop la différence en fait. Grâce à cette para-virtualisation, je peux faire tourner Windows sous NetBSD sans utiliser d'émulation du processeur à paramétrer via des domaines. On y mets même le système hôt en domaine 0 du coup

C'est utile pour déployer plus facilement certains applications, au lieu de distribuer un binaire qui ne fonctionnera pas parce que telle ou telle lib n'est pas dispo, tu fais un gros paquet similaire à une distrib contenant tout ce qu'il faut et ça tourne tout seul.
Si tu as tout un tas d'applications différentes à déployer sur différentes machines, tu peux te rendre compte de l'intérêt du truc.

(si j'ai bien compris, mais perso j'ai jamais utilisé docker pour l'instant)

Le 02 décembre 2015 à 21:34:59 [deban]_Dakien a écrit :

Le 02 décembre 2015 à 19:07:57 -Moopie- a écrit :

Le 02 décembre 2015 à 18:47:55 [deban]_Dakien a écrit :
Ça me rappelle Xen avec les domaines votre truc

Non non ça n'a rien à voir, renseigne toi c'est intéressant

Pourtant Xen est bien un para-virtualiseur... Je vois pas trop la différence en fait. Grâce à cette para-virtualisation, je peux faire tourner Windows sous NetBSD sans utiliser d'émulation du processeur à paramétrer via des domaines. On y mets même le système hôt en domaine 0 du coup

Docker est different par rapport à la consommation des ressources (pour Xen tu alloues tant à ton hôtes, et tant à tes systèmes virtualisés), permet essentiellement d'avoir le même système (incl version des binaires) de prod pour toutes les machines peu importe le système hôte.