Non à quoi ? tu peux être en désaccord avec certains de mes propos, mais je doute que tu sois en désaccord sur la totalité si ce n'est juste par pur plaisir de contrariété.
Docker se base sur un dockerfile, ce qui te permet de reconstruire un docker très facilement. Toutes les images du docker hub sont reconstructibles facilement (tu clone le dépôt et tu build). Mettre à jour ou modifier une image est triviale. C'est le langage partagé par tous les linux : le shell.
Un docker container est une blackbox ( ou une boite noire si ça peut te faire plaisir ). C'est un gros ensemble binaire indivisible pas très différent d'une tarball de fichiers binaires. Tu peux certes créer ce blob à l'aide d'un script bash, mais ça reste la production d'un blob avec un contenu indivisible en lui même.
D'ailleurs, je te propose d'envoyer un gros script bash à ton sys-admin qui pip install la moitié d'internet, curl quelques binaires pré-compilés, installes des RPM depuis des repos non-trustés, et sed ses propres fichier de configuration. Tu lui dis "pas de soucis, c'est reproduisible, c'est un script linux bien connu, du SHELL, on peut déployer ça en production" et tu regardes sa réaction.
Je te conseil de courir vite également.
Ça te choque de faire quelque-chose comme ça ? C'est pourtant exactement ce que fait un bon paquet de DockerFile, et exactement ce que font un grand nombre d'utilisateur de Docker.
Maintenant ne me fait pas dire ce que je n'ai pas dit. Docker est un outil fantastique et une trés bonne technologie. Seulement ce n'est PAS un système de packaging.
C'est un système de shipping avec un système de snapshot (oui de l'anglais, encore ). Même son nom l'indique d'ailleurs.
Ça ne résous absolument pas les autres problématiques associés au packaging que j'ai listé précédemment ( tracabilité, update incrémentale, construction depuis les sources, versionning).
Les deux sont complémentaires et ça beaucoup de développeurs tentent à l'oublier.
Ça n'a rien de compliqué, ça ne te demande pas d'apprendre des choses démentes.
Je te conseil d'essayer de re-construire à chaque faille d'OpenSSL, ou chaque mise à jour de libc une infrastructure qui contient 500-600 containers docker en productions... Allez de préférence, avec des distributions différentes et des images différentes.
Et aprés tu compareras ça avec ce que tu peux faire avec un infra puppet ou ansible, et un packaging proprement fait.
[^] # Re: A chaque clou son marteau
Posté par Firwen (site web personnel) . En réponse au journal La multiplicité des gestionnaires de paquets. Évalué à 9. Dernière modification le 01 février 2017 à 12:12.
Non à quoi ? tu peux être en désaccord avec certains de mes propos, mais je doute que tu sois en désaccord sur la totalité si ce n'est juste par pur plaisir de contrariété.
Un docker container est une blackbox ( ou une boite noire si ça peut te faire plaisir ). C'est un gros ensemble binaire indivisible pas très différent d'une tarball de fichiers binaires. Tu peux certes créer ce blob à l'aide d'un script bash, mais ça reste la production d'un blob avec un contenu indivisible en lui même.
D'ailleurs, je te propose d'envoyer un gros script bash à ton sys-admin qui pip install la moitié d'internet, curl quelques binaires pré-compilés, installes des RPM depuis des repos non-trustés, et sed ses propres fichier de configuration. Tu lui dis "pas de soucis, c'est reproduisible, c'est un script linux bien connu, du SHELL, on peut déployer ça en production" et tu regardes sa réaction.
Je te conseil de courir vite également.
Ça te choque de faire quelque-chose comme ça ? C'est pourtant exactement ce que fait un bon paquet de DockerFile, et exactement ce que font un grand nombre d'utilisateur de Docker.
Maintenant ne me fait pas dire ce que je n'ai pas dit. Docker est un outil fantastique et une trés bonne technologie. Seulement ce n'est PAS un système de packaging.
C'est un système de shipping avec un système de snapshot (oui de l'anglais, encore ). Même son nom l'indique d'ailleurs.
Ça ne résous absolument pas les autres problématiques associés au packaging que j'ai listé précédemment ( tracabilité, update incrémentale, construction depuis les sources, versionning).
Les deux sont complémentaires et ça beaucoup de développeurs tentent à l'oublier.
Je te conseil d'essayer de re-construire à chaque faille d'OpenSSL, ou chaque mise à jour de libc une infrastructure qui contient 500-600 containers docker en productions... Allez de préférence, avec des distributions différentes et des images différentes.
Et aprés tu compareras ça avec ce que tu peux faire avec un infra puppet ou ansible, et un packaging proprement fait.
Même RedHat propose maintenant des solutions qui tentent de "scanner" les containers dockers à la volée pour analyser les versions réellement utilisées en production... C'est peu dire si la bête n'est un example de transparence ... ( http://www.infoworld.com/article/3089425/application-virtualization/red-hat-builds-linux-container-security-scanning-into-rhel.html )