Moby: Peer-to-Peer-Push/Pull zwischen Docker-Hosts

Richtig in allen Punkten :)

Was wir anstreben, ist ein System, das mit der Go-Sprache vergleichbar ist. z.B. Sie können ein Paket überall hosten, und als Annehmlichkeit gibt es einen zentral kuratierten Namensraum mit Richtlinien für Qualität, Auditierung, Sicherheit usw.

Dies ist eine Unterkomponente von #21.

Ich habe den Titel geändert, um den Unterschied zu #350 zu verdeutlichen.

In diesem Problem geht es darum, die Peer-to-Peer-Push/Pull-Funktion zu Docker hinzuzufügen. Mit dieser Funktion können 2 Docker-Hosts Bilder direkt austauschen, als ob sie Bilder mit der Registrierung austauschen würden.

Denken Sie hier ein wenig mehr an Einzelheiten.

• Wollen wir das Pushen zu _und_ das Pullen von einem anderen Daemon unterstützen?
• Sollte der Docker immer Image-Pushs (und -Pulls) akzeptieren oder muss er im Promiscuous-Modus ausgeführt werden?
• Was ist mit Daemon - Daemon-Authentifizierung und -Autorisierung?
• Wie lautet der Befehl, um zu einem anderen Daemon zu pushen? docker push -d other.docker.com myimage ?
• Wird für die Übertragung genau derselbe Mechanismus verwendet wie für das reguläre Push/Pull-Verfahren in der Registrierung? (HTTP usw.)
• #21 ist mit dieser Ausgabe verbunden. Beispielsweise würde es eine Route für POST enthalten, die ein Bild an einen anderen Daemon sendet. Oder vielleicht wird das durch die von der Registrierung verwendete API ersetzt.

Am Montag, den 8. April 2013 um 20:21 Uhr schrieb Caleb Spare [email protected] :

• Wollen wir das Pushen zu _und_ das Pullen von einem anderen Daemon unterstützen?

Ja, ich denke schon. Wenn ich mich für einen entscheiden müsste, würde ich push to start wählen.

• Sollte der Docker Image-Pushs (und -Pulls) immer akzeptieren, oder tut er es
  müssen im Promiscuous-Modus ausgeführt werden?

Ich finde es gut, so anzufangen. Wir können es zu einem bedingten Schalter machen,
z.B. 'docker -d --no-push-pull'

• Was ist mit Daemon - Daemon-Authentifizierung und -Autorisierung?

Ich denke, darüber können wir uns später Gedanken machen.

• Wie lautet der Befehl, um zu einem anderen Daemon zu pushen? Docker-Push -d
  other.docker.com meinbild?

Dies erscheint vernünftig. @samalba @kencochrane und @shin- wer sind
Die Implementierung der Registrierung könnte hier eine Meinung haben.

• Wird die Übertragung genau denselben Mechanismus verwenden wie die reguläre
  Registry-Push/Pull? (HTTP usw.)

Ja, das ist das Ziel.

• #21 https://github.com/dotcloud/docker/issues/21 ist damit verbunden
  Ausgabe. Beispielsweise würde es eine Route zum POSTen eines Bildes enthalten
  ein weiterer Dämon. Oder vielleicht wird das durch die API der Registrierung ersetzt
  Verwendet.

Absolut. Ich habe angefangen, an Nr. 21 zu arbeiten, wie wäre es, wenn ich die Basis mit Ihnen teile
und wir arbeiten parallel an den 2 verschiedenen Teilen der API?

@shykes Das klingt großartig. Einfach den Code #21 zu einer Filiale schieben?

Dies wird mit der 1.0-API erheblich einfacher.

Dies wäre ein großartiges Plugin, wenn jemand daran interessiert ist, daran zu arbeiten, sagen Sie es bitte hier. Ich werde Sie mit frühen API-Dokumenten und Tipps für den Einstieg versorgen.

Das klingt interessant. Gibt es eine feste Deadline für diese Funktion? Wenn nicht, kann ich es nehmen und bis Ende dieses Monats daran arbeiten (oder vielleicht im September. Ich habe in den letzten Wochen einige andere Arbeiten zu erledigen.)

@shykes Es wäre großartig, wenn ich auf einen detaillierteren Plan der 1.0-APIs zugreifen könnte.

@tobstarr , wenn Sie Lust haben, Ihre Go-Registry-Implementierung zu verwenden, damit Docker einen Push erhalten kann ... Ich denke, das wäre ein Killer-Feature! Gerne helfe ich Ihnen bei der Zusammenführung.

Das interessiert mich immer noch. Wenn jemand es ausprobieren möchte, lass es mich wissen :)

+1 für mich

Das würde ich mir echt gerne bauen lassen. Besteht die Grundidee darin, die Registrierungs-API über die Remote-API zu legen? Es sieht so aus, als ob der Endpunkt /images/:id/json mehr oder weniger kompatibel ist und alles andere nicht kollidiert.

Es wäre wirklich schön, wenn die Registrierungs-API eine Teilmenge der Remote-API wäre. Alternativ könnten wir, denke ich, einen separaten Port-/URL-Namespace haben, der die Registrierung war. Oder sogar eine ganz andere API?

+1 - Ich würde gerne sehen, dass es genauso funktioniert wie die Registrierung, sodass Sie sich nicht darum kümmern müssen, ob Sie mit einer Registrierung oder einem Remote-Docker-Daemon sprechen.

Ich bin mir nicht sicher, wie viel Arbeit das wäre, aber wenn sie gleich sind, könnte die Push/Pull-Funktionalität der Registrierung im Wesentlichen zu einer leichten Authentifizierung werden, die vor einem Docker-Daemon sitzt.

Eine funktionierende Implementierung über SSH hier: https://github.com/docker/docker/pull/9304

Kann mir bitte jemand sagen, ob wir diese Funktion in naher Zukunft in irgendeiner Version bekommen werden?
Ich würde diese Funktion gerne sehen

+1 Würde das auch gerne sehen!

+1.

+1 dazu. Derzeit verwenden wir docker save | ssh -C docker load , um Bilder zu übertragen, aber das überträgt _alles_, einschließlich der Teile, die wir bereits haben. Wäre viel einfacher, wenn ich nur die wichtigen Bits übertragen könnte.

_USER-UMFRAGE_

_Der beste Weg, um über Änderungen in dieser Diskussion benachrichtigt zu werden, besteht darin, oben rechts auf die Schaltfläche "Abonnieren" zu klicken._

Die unten aufgeführten Personen haben Ihre sinnvolle Diskussion mit einem zufälligen +1 gewürdigt:

@xiaods
@hustcat
@leonardschneider
@v00rh33s

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

Sieht immer noch nach einem gültigen Feature aus. Ich bin mir nicht sicher, ob es mit Sicherheits-/Verifizierungsmaterial möglich ist.
Gedanken @tonistiigi ?

@LK4D4 Ich denke, wir können es schließen, wenn jemand ein echtes Vorschlagsdesign abgeben kann, dann kann er ein anderes Problem eröffnen, um das Thema zu verfolgen.