oui, enfin "conflit" ouvert, faut pas exagérer, ça reste des divergences techniques, rien de plus. Y a pas de violences ou de combats.
Après dire que la plateforme sous jacente n'est plus
importante n'est pas forcément faux, si tu passe tout dans des
conteneurs tu te moque de la plateforme (modulo la version de
ton kernel).
Pas vraiment. Déjà, le kernel importe pas mal pour les perfs, pour le support matériel, pour tout un tas de trucs.
Ensuite, go est compilé en statique, mais y a plein de dépendances ignorés dans docker et/ou kubernetes.
Par exemple, il faut qu'iptables soit la ce qui pose la question de la future migration à nftables, pour ne citer que ça.
Autre exemple, kubernetes à un un type de volume gitRepo, qui requiert d'avoir git dispo pour le kubelet, et ça fait parti de la plateforme (et par défaut, il est pas par exemple dans les images docker que Google fourni pour hyperkube).
3eme exemple, pour assurer la sécurité et l'isolation des containers docker, une des méthode est d'utiliser un équivalent de sVirt (ie, mettre chaque containeur dans un domaine selinux séparé, ce qui fait que root a pas trop d'accès dans le containeur, même si il en sort), et ça, ça requiert une platforme qui supporte avec la policy, etc. Pareil pour l'équivalent avec apparmor.
Y a plein d'exemple comme ça. La portabilité, c'était déjà la promesse de java il y a 10 ans, et c'est pas vraiment ce qui est arriver en pratique. Et je pense pas que les ingénieurs de l'époque soient moins bon que maintenant.
Y en a qui ont appliqué ce principe à l’extrême c'est
rancherOS (http://rancher.com/rancher-os/) ou tu te retrouve
sur un système ou tu as juste un docker "système" et un docker
"user" et rien d'autre, tous le reste tourne dans des
conteneurs
Donc tu va utiliser tes conteneurs comme un rpm mais sans dépendances. Et sans facilité pour combiner les binaires (exemple, si je veux rajouter git et iptables sur l'image, bah, j'ai quand même besoin d'avoir un paquet pour rajouter à l'image de base, vu que ton image ne peux dépendre que d'une image à la fois).
On verra qui gagne la bataille du conteneur entre systemd et
docker mais je dirais que pour l'instant docker à une longueur
d'avance pas sur le plan technique car effectivement
l'approche daemon n'est pas la meilleur mais niveau
eco-system/buzz ils sont loin devant.
Je ne pense pas que systemd cherche à gagner une bataille quelconque. Systemd supporte de démarrer un container docker, donc bon, les options sont déjà la. Et globalement, vu que docker engine est plus une brique de base qu'autre chose, tu es obligé d'avoir des outils à coté, notamment pour l'orchestration, et les outils de docker inc sont trop simplistes pour ça. Donc tu as tout un écosystème qui supporte plus que docker (genre kubernetes supporte rkt, mesos supporte kubernetes ou docker en natif, etc, etc). Donc la question se pose pas vraiment comme ça.
Le fait que les Windows conteneur utilisent l'API Docker c'est
plutôt impressionnant je trouve.
Ben c'est logique, ils vont bénéficier de l’écosystème sans rien faire.
Bah, donc même docker inc voit que leur approche de démon centralisé n'est pas suffisante.
Il faut bien voir que runc, c'est juste une réaction suite à la sortie de rkt. Et pendant que docker inc tente d'éviter que les gens aillent ailleurs, rkt bosse sur la sécurité en profondeur, avec l'attestation des images, une approche federé pour les images de base, etc).
À la fin, utiliser runc/rkt (ou systemd-nspawn) est plus propre pour un orchestrateur (qui va être capable de surveiller le processus, de récuperer les logs, de ne pas attendre que docker incorpore les derniers changements niveau noyau, etc). Donc je pense que les gens vont migrer vers ça à terme.
[^] # Re: Ce n'est qu'une première étape.
Posté par Misc (site web personnel) . En réponse au journal Docker 1.10 et les user namespace.. Évalué à 4.
oui, enfin "conflit" ouvert, faut pas exagérer, ça reste des divergences techniques, rien de plus. Y a pas de violences ou de combats.
Pas vraiment. Déjà, le kernel importe pas mal pour les perfs, pour le support matériel, pour tout un tas de trucs.
Ensuite, go est compilé en statique, mais y a plein de dépendances ignorés dans docker et/ou kubernetes.
Par exemple, il faut qu'iptables soit la ce qui pose la question de la future migration à nftables, pour ne citer que ça.
Autre exemple, kubernetes à un un type de volume gitRepo, qui requiert d'avoir git dispo pour le kubelet, et ça fait parti de la plateforme (et par défaut, il est pas par exemple dans les images docker que Google fourni pour hyperkube).
3eme exemple, pour assurer la sécurité et l'isolation des containers docker, une des méthode est d'utiliser un équivalent de sVirt (ie, mettre chaque containeur dans un domaine selinux séparé, ce qui fait que root a pas trop d'accès dans le containeur, même si il en sort), et ça, ça requiert une platforme qui supporte avec la policy, etc. Pareil pour l'équivalent avec apparmor.
Y a plein d'exemple comme ça. La portabilité, c'était déjà la promesse de java il y a 10 ans, et c'est pas vraiment ce qui est arriver en pratique. Et je pense pas que les ingénieurs de l'époque soient moins bon que maintenant.
Donc tu va utiliser tes conteneurs comme un rpm mais sans dépendances. Et sans facilité pour combiner les binaires (exemple, si je veux rajouter git et iptables sur l'image, bah, j'ai quand même besoin d'avoir un paquet pour rajouter à l'image de base, vu que ton image ne peux dépendre que d'une image à la fois).
Je ne pense pas que systemd cherche à gagner une bataille quelconque. Systemd supporte de démarrer un container docker, donc bon, les options sont déjà la. Et globalement, vu que docker engine est plus une brique de base qu'autre chose, tu es obligé d'avoir des outils à coté, notamment pour l'orchestration, et les outils de docker inc sont trop simplistes pour ça. Donc tu as tout un écosystème qui supporte plus que docker (genre kubernetes supporte rkt, mesos supporte kubernetes ou docker en natif, etc, etc). Donc la question se pose pas vraiment comme ça.
Ben c'est logique, ils vont bénéficier de l’écosystème sans rien faire.
Bah, donc même docker inc voit que leur approche de démon centralisé n'est pas suffisante.
Il faut bien voir que runc, c'est juste une réaction suite à la sortie de rkt. Et pendant que docker inc tente d'éviter que les gens aillent ailleurs, rkt bosse sur la sécurité en profondeur, avec l'attestation des images, une approche federé pour les images de base, etc).
À la fin, utiliser runc/rkt (ou systemd-nspawn) est plus propre pour un orchestrateur (qui va être capable de surveiller le processus, de récuperer les logs, de ne pas attendre que docker incorpore les derniers changements niveau noyau, etc). Donc je pense que les gens vont migrer vers ça à terme.