C'est vachement cool d'avoir autant de développeurs ici sur Lexpage, et vu que vous êtes emballés tant mieux. Je m'excuse par avance pour la passive aggressivité de mon message, mais j'aimerais des réponses honnêtes.

Perso je suis administrateur système et réseau, et j'utilise des containers en prod depuis des années avec LXC. J'ai très très peur de Docker et du merdier que ça va apporter et je n'ai absolument aucune envie de maintenir un truc aussi bancal sécuritairement. Sans compter le rêve du "ça tourne sur n'importe quel linux, oui oui tant que kernel > 3.8, osef de ta prod actuelle sous debian stable".

Donc s'il vous plait expliquez moi l'intérêt dans la vraie vie, car franchement je ne vois pas ce que ça apporte à du LXC pour de la prod. Pour du dev très clairement je comprend l'intérêt et l'engouement, mais pour packager et livrer... j'en ai des frissons tellement c'est criant de connerie.

Syssonj'aimerais des réponses honnêtes.

Sur Lexpage ? Really?

SyssonDonc s'il vous plait expliquez moi l'intérêt dans la vraie vie, car franchement je ne vois pas ce que ça apporte à du LXC pour de la prod. Pour du dev très clairement je comprend l'intérêt et l'engouement, mais pour packager et livrer... j'en ai des frissons tellement c'est criant de connerie.

Je ne connais pas en détails LXC, mais je pense que le principal argument de Docker est la facilité avec laquelle tu peux déployer les containers, et de bootstraper un environnement virtuel en quelques secondes à peine. Je crois qu'il faut voir ça surtout comme un "emballage sympathique autour d'une technologie existante". Le fait d'avoir intégrer directement un DockerHub à la GitHub pour la gestion des images doit aussi motiver beaucoup de gens à utiliser Docker, puisque cela permet "en une commande" de récupérer un environnement prêt à l'emploi.

Je pense par contre qu'ils ont bien joué le coup avec un gros buzz autour du projet, et que c'est ce buzz qui fait que tout le monde veut ou va y toucher un jour ou l'autre, pas forcément pour les qualités intrinsèques du produit. Il faut aussi voir le compromis que ça apporte : même si c'est pas sécurisé (les gens confondent souvent environnement virtuel et sandbox, de ce que j'ai pu voir), c'est une "première étape" par rapport à l'approche "classique" qui consiste à tout déployer sur l'hôte (comme j'ai fait pour le VPS, j'avoue).

Ben dans mon infra les applis sont containerisées : le redmine pour support, le joomla pour le site web, le roundcube pour le webmail... mais les containers ne sont pas abandonnés en prod depuis un environnement de dev.

Chaque container se fait checker par nagios, que ce soit l'espace disque, la conso ram, les mises à jour de l'OS, etc. Là un dev te file un docker tu fais quoi. Tu le repackage à chaque fois que tu met à jour une lib système dedans? Et si le dev ne repackage pas assez vite, mon infra reste vulnérable?

Je conserve les bases de données consolidées sur l'hôte, qui gère notamment la réplication postgresql vers un autre hote. Quand c'est nécessaire j'ai aussi une réplication à base de drbd ou unison pour des fichiers de l'appli (par exemple les uploads d'un owncloud). Comment ces tâches typiquement adminsys sont elles réalisables lorsqu'un developpeur package avec Docker?

J'ai conscience que si c'est une nouvelle façon de travailler il faut apprendre et trouver des solutions, mais étant du côté admin de la Force j'ai l'impression qu'on obscurcit le tableau en utilisant Docker.

SyssonDonc s'il vous plait expliquez moi l'intérêt dans la vraie vie, car franchement je ne vois pas ce que ça apporte à du LXC pour de la prod. Pour du dev très clairement je comprend l'intérêt et l'engouement, mais pour packager et livrer... j'en ai des frissons tellement c'est criant de connerie.

Ben si tu as un process de LXC qui est bien rodé et bien outillé, tu vas pas avoir un bénéfice immédiat monstrueux.
Tout au plus une jolie interface avec des trucs comme Panamax (mais qui triche en imposant un premier niveau de virtualisation classique).

L'avantage de Docker c'est que ça amène une couche d'outillage et de répétabilité sur la virtualisation par conteneurs, ce qui la ramène à la portée de tous ceux qui n'ont pas investi sur les LXC.

Les outils des dévs (besoin de générer à volonté des environnements de dév stable et iso-prod) et des admins (besoin de virtualiser et provisionner des environnements) ont tendance à converger en s'industrialisant.
Docker est juste un produit de cette convergence, comme Ansible, Vagrant, etc...

SyssonSans compter le rêve du "ça tourne sur n'importe quel linux, oui oui tant que kernel > 3.8, osef de ta prod actuelle sous debian stable".

Ça tourne pas de la même manière sous n'importe quel linux. Un bon host docker nécessite un brin de compétence.
L'argument de la version du kernel n'est pas recevable, personne ne t'impose de déployer AUJOURD'HUI des images docker, et Jessie is coming
(sauf si tu compte garder wheezy 5 ans de plus )

SyssonBen dans mon infra les applis sont containerisées : le redmine pour support, le joomla pour le site web, le roundcube pour le webmail... mais les containers ne sont pas abandonnés en prod depuis un environnement de dev.

Pourquoi "depuis un environnement de dév" ? Rien ne t'empêche d'avoir un registry d'images de prod.

SyssonChaque container se fait checker par nagios, que ce soit l'espace disque, la conso ram, les mises à jour de l'OS, etc. Là un dev te file un docker tu fais quoi. Tu le repackage à chaque fois que tu met à jour une lib système dedans? Et si le dev ne repackage pas assez vite, mon infra reste vulnérable?

Tu peux aussi fournir une image de base avec tes libs à jour que tes développeurs ont obligation d'utiliser, et rebuilder les images applicatives à chaque fois que tu update ton image de base.

SyssonJe conserve les bases de données consolidées sur l'hôte, qui gère notamment la réplication postgresql vers un autre hote. Quand c'est nécessaire j'ai aussi une réplication à base de drbd ou unison pour des fichiers de l'appli (par exemple les uploads d'un owncloud). Comment ces tâches typiquement adminsys sont elles réalisables lorsqu'un developpeur package avec Docker?

Le principe reste le même, les BDD et les binary logs seront sur l'hôte et montés dans les containers via le mécanisme de volume, tes scripts de réplication ne bougent même pas.

SyssonJ'ai conscience que si c'est une nouvelle façon de travailler il faut apprendre et trouver des solutions, mais étant du côté admin de la Force j'ai l'impression qu'on obscurcit le tableau en utilisant Docker.

C'est vrai que c'est une techno encore en construction, mais il faut reconnaître qu'elle a murit à un vitesse exceptionnelle. C'est pas adapté à toutes les infras actuelles, c'est aussi possible qu'on trouve des technos encore plus rassembleuses à l'avenir, en attendant on a déjà une super base pour faire bosser tout le monde : dévs, ops, et devops

qu'est-ce que c'est pénible de migrer une db dans un container

J'comptais profiter de la journée pour organiser tout ça sur le VPS, mais je coince déjà juste avec MariaDB et les données actuelles.... problème de permissions, etc. je sens qu'il va me falloir 3 containers :
- Un pour le serveur, en isolation ;
- Un pour les données avec un volume /var/lib/mysql ;
- Un pour m'importer un dump logique

... alors que je pensais pouvoir me contenter d'un montage de /var/lib/mysql du host vers /var/lib/mysql du container

Comme tu le dis Fabe, heureusement que ça reste une techno en construction. T'as tellement de points à sécuriser sur un système que en résolvant le problème du packaging et du déploiement de cette façon tu ne fais que déplacer le problème et multiplier les points de vulnérabilité. Tes briques sont isolées les une des autres mais ça ne les sécurise pas pour autant.

Les aventures de Guybrush au pays de Docker m'intéressent, mais même après avoir maté la vidéo hier soir je dois dire que en tant qu'admin je ne suis pas convaincu de l'intérêt pour de la prod. T'as du potentiel, mais... ça me chiffonne.

p.. d'OVH. Même quand on est sur un VPS, ils parviennent encore à être emmerdant

J'peux pas déployer Docker sur le VPS à cause de la version du kernel, et je peux pas patcher le kernel parce que ce sont des kernels spécifiques OVH (en lien avec leur OpenVZ, je suppose). J'ai installé un 3.18, mais impossible de booter dessus (et je ne vois rien pour modifier le bootloader sur le VPS).


[Edité : Désolé pour les coupures ce soir. J'avais prévu un joli container pour mettre Lexpage dedans, et vu que ce n'était pas possible, et qu'il me fallait tout de même déployer la dernière version du site, j'ai du chipoter... et j'ai bien foiré, à plusieurs reprises, en bindant gunicorn sur le port 80 (au lieu du 8000), en oubliant de virer la config temporaire de Nginx (prévue pour gérer le container) et en oubliant de fixer la variable d'environnement permettant de switcher les settings du dev à la prod Bref, un beau petit merdier qui n'aurait pas du arriver.]