Moby: Push/pull peer-to-peer entre les hôtes docker

Correct sur tous les points :)

Ce que nous visons, c'est un système comparable au langage go. par exemple. vous pouvez héberger un package n'importe où, et pour plus de commodité, il existe un espace de noms centralisé avec des directives pour la qualité, l'audit, la sécurité, etc.

Ceci est un sous-composant de #21.

J'ai changé le titre pour clarifier la différence avec #350.

Ce problème concerne l'ajout de la fonctionnalité push/pull peer-to-peer à Docker. Avec cette fonctionnalité, 2 hôtes docker peuvent échanger des images directement comme s'ils échangeaient des images avec le registre.

Penser un peu plus aux détails ici.

• Voulons-nous prendre en charge le push vers _et_ l'extraction depuis un autre démon ?
• Le docker doit-il toujours accepter les push (et les pulls) d'images, ou doit-il être exécuté en mode promiscuité ?
• Qu'en est-il du démon ? Authentification et autorisation du démon ?
• Quelle est la commande pour pousser vers un autre démon ? docker push -d other.docker.com myimage ?
• Le transfert va-t-il utiliser exactement le même mécanisme que le push/pull régulier du registre ? (HTTP...)
• #21 est lié à ce problème. Par exemple, il inclurait une route pour POST envoyer une image vers un autre démon. Ou peut-être que cela est remplacé par l'API utilisée par le registre.

Le lundi 8 avril 2013 à 20h21, Caleb Spare [email protected] a écrit :

• Voulons-nous prendre en charge le push vers _et_ l'extraction depuis un autre démon ?

Oui, je pense que oui. Si je devais en choisir un, je choisirais de pousser pour commencer.

• Le docker doit-il toujours accepter les poussées (et les tractions) d'image, ou est-ce qu'il
  besoin d'être exécuté en mode promiscuité?

Je pense que c'est bien de commencer comme ça. Nous pouvons en faire un interrupteur conditionnel,
par exemple. 'docker -d --no-push-pull'

• Qu'en est-il du démon ? Authentification et autorisation du démon ?

Je pense que nous pourrons nous en préoccuper plus tard.

• Quelle est la commande pour pousser vers un autre démon ? docker pousser -d
  autre.docker.com monimage ?

Cela semble raisonnable. @samalba @kencochrane et @shin- qui sont
la mise en œuvre du registre pourrait avoir une opinion ici.

• Le transfert va-t-il utiliser exactement le même mécanisme que le transfert régulier
  push/pull du registre ? (HTTP...)

Oui, c'est le but.

• #21 https://github.com/dotcloud/docker/issues/21 est lié à cela
  publier. Par exemple, il inclurait un itinéraire pour publier une image sur
  un autre démon. Ou peut-être que c'est remplacé par n'importe quelle API du registre
  les usages.

Absolument. J'ai commencé à travailler sur #21, que diriez-vous de partager la base avec vous
et on travaille en parallèle sur les 2 parties différentes de l'API ?

@shykes Ça sonne bien. Poussez simplement le code #21 vers une agence ?

Ce sera beaucoup plus facile en utilisant l'API 1.0.

Ce serait un excellent plugin, si quelqu'un est intéressé à travailler dessus, veuillez le dire ici. Je vais vous mettre en contact avec les premiers documents de l'API et des conseils pour démarrer.

Cela semble intéressant. Y a-t-il une date limite pour cette fonctionnalité ? Sinon, je peux le prendre et y travailler d'ici la fin de ce mois (ou peut-être en septembre. J'ai d'autres travaux à faire ces dernières semaines.)

@shykes Ce serait formidable si je pouvais accéder à un plan plus détaillé des API 1.0.

@tobstarr , si vous avez envie d'utiliser votre implémentation de registre go pour permettre à docker de recevoir un push ... Je pense que ce serait une fonctionnalité qui tue! Je serai heureux de vous aider à le fusionner.

Je suis toujours intéressé par cela. Si quelqu'un veut essayer, faites le moi savoir :)

+1 pour moi

J'aimerais vraiment que ce soit construit. L'idée de base est-elle de superposer l'API de registre au-dessus de l'API distante ? Il semble que le point de terminaison /images/:id/json soit plus ou moins compatible, et tout le reste n'entre pas en collision.

Ce serait vraiment bien si l'API de registre était un sous-ensemble de l'API distante. Alternativement, je suppose que nous pourrions avoir un espace de noms de port / URL séparé qui était le registre. Ou même une API entièrement différente ?

+1 - J'aimerais que cela fonctionne de la même manière que le registre, vous n'avez donc pas à vous soucier de savoir si vous parlez à un registre ou à un démon docker distant.

Je ne sais pas combien de travail cela représenterait, mais s'ils sont identiques, la fonctionnalité push / pull du registre pourrait essentiellement devenir une authentification légère qui se trouve devant un démon docker.

Une implémentation fonctionnelle sur SSH ici : https://github.com/docker/docker/pull/9304

Quelqu'un peut-il me dire si nous allons obtenir cette fonctionnalité dans un avenir proche dans n'importe quelle version ?
J'aimerais voir cette fonctionnalité

+1 J'adorerais voir ça aussi !

+1.

+1 à ce sujet. Actuellement, nous utilisons docker save | ssh -C docker load pour transférer des images, mais cela transfère _tout_, y compris les pièces que nous avons déjà. Ce serait beaucoup plus facile si je ne pouvais transférer que les bits qui comptent.

_SONDAGE UTILISATEUR_

_La meilleure façon d'être informé des changements apportés à cette discussion est de cliquer sur le bouton S'abonner en haut à droite._

Les personnes listées ci-dessous ont apprécié votre discussion significative avec un +1 aléatoire :

@xiaods
@hustcat
@leonardschneider
@v00rh33s

https://github.com/Dataman-Cloud/p2pull

Ressemble toujours à une fonctionnalité valide à avoir. Je ne sais pas si c'est possible avec des trucs de sécurité/vérification.
Des pensées @tonistiigi ?

@ LK4D4 je pense que nous pouvons le fermer, si quelqu'un peut donner une vraie conception de proposition, alors il peut ouvrir un autre problème pour suivre le sujet.