Moby: Push/pull peer-to-peer entre hosts docker

Creado en 29 mar. 2013  ·  22Comentarios  ·  Fuente: moby/moby

Después de la discusión con @shykes en irc.

Cuando el demonio de la ventana acoplable se está ejecutando, debe aceptar solicitudes push/pull. Esto permitirá que dos demonios se envíen imágenes entre sí de forma p2p o centralizada.

Además, debe haber una opción -norun para deshabilitar la ejecución. Esto será útil cuando se ejecute un repositorio de imágenes dedicado. En este modo, la ventana acoplable debería funcionar incluso sin lxc o el módulo aufs.

Una vez que esto exista, la implementación actual del repositorio público podría reemplazarse con un demonio docker.

aredistribution exexpert kinfeature

Todos 22 comentarios

Correcto en todos los aspectos :)

Lo que buscamos es un sistema comparable al lenguaje go. p.ej. puede alojar un paquete en cualquier lugar y, para su comodidad, hay un espacio de nombres seleccionado central con pautas de calidad, auditoría, seguridad, etc.

Este es un subcomponente del #21.

Cambié el título para aclarar la diferencia con el #350.

Este problema se trata de agregar la función de inserción/extracción punto a punto a Docker. Con esta característica, 2 hosts docker pueden intercambiar imágenes directamente como si estuvieran intercambiando imágenes con el registro.

Pensando un poco más en detalles aquí.

  • ¿Queremos admitir empujar a _y_ tirar de otro demonio?
  • ¿Debe la ventana acoplable aceptar siempre las inserciones (y extracciones) de imágenes, o debe ejecutarse en modo promiscuo?
  • ¿Qué pasa con daemon - autenticación y autorización de daemon?
  • ¿Cuál es el comando para empujar a otro demonio? docker push -d other.docker.com myimage ?
  • ¿La transferencia va a utilizar exactamente el mismo mecanismo que el push/pull normal del registro? (HTTP, etc)
  • # 21 está relacionado con este problema. Por ejemplo, incluiría una ruta para POST enviar una imagen a otro demonio. O tal vez eso sea reemplazado por cualquier API que use el registro.

El lunes 8 de abril de 2013 a las 8:21 p. m., Caleb Spare [email protected] escribió:

  • ¿Queremos admitir empujar a _y_ tirar de otro demonio?

Sí, creo que sí. Si tuviera que elegir uno, elegiría empujar para comenzar.

  • ¿Debería la ventana acoplable aceptar siempre las inserciones (y extracciones) de imágenes, o lo hace
    necesita ser ejecutado en modo promiscuo?

Creo que está bien empezar de esa manera. Podemos convertirlo en un cambio condicional,
p.ej. 'docker -d --no-push-pull'

  • ¿Qué pasa con daemon - autenticación y autorización de daemon?

Creo que podemos preocuparnos por eso más tarde.

  • ¿Cuál es el comando para empujar a otro demonio? ventana acoplable empujar -d
    other.docker.com mi imagen?

Esto parece razonable. @samalba @kencochrane y @shin- quienes son
implementar el registro podría tener una opinión aquí.

  • ¿La transferencia va a utilizar exactamente el mismo mecanismo que la transferencia regular?
    Registro push/pull? (HTTP, etc)

Sí, ese es el objetivo.

  • #21 https://github.com/dotcloud/docker/issues/21 está vinculado a esto
    asunto. Por ejemplo, incluiría una ruta para publicar una imagen en
    otro demonio. O tal vez eso sea reemplazado por cualquier API del registro
    usos.

Absolutamente. Empecé a trabajar en el #21, ¿qué tal si les comparto la base?
y trabajamos en paralelo en las 2 partes diferentes de la API?

@shykes Eso suena genial. ¿Solo empuja el código #21 a una sucursal?

Esto será significativamente más fácil usando la API 1.0.

Este sería un gran complemento, si alguien está interesado en trabajar en esto, por favor dígalo aquí. Lo conectaré con los primeros documentos de API y consejos para comenzar.

Esto suena interesante. ¿Hay alguna fecha límite para esta característica? Si no, puedo tomarlo y trabajar en él para fines de este mes (o puede ser septiembre. Tengo otro trabajo que hacer en las últimas semanas).

@shykes Sería genial si pudiera acceder a un plan más detallado de las API 1.0.

@tobstarr , si tiene ganas de usar esa implementación de registro go suya para permitir que la ventana acoplable reciba un impulso ... ¡Creo que sería una característica excelente! Estaré encantado de ayudarte a fusionarlo.

Todavía estoy interesado en esto. Si alguien quiere darle una oportunidad, hágamelo saber :)

+1 para mi

Realmente me gustaría construir esto. ¿La idea básica es superponer la API de registro sobre la API remota? Parece que el extremo /images/:id/json es más o menos compatible, y todo lo demás no choca.

Sería genial si la API de registro fuera un subconjunto de la API remota. Alternativamente, supongo que podríamos tener un espacio de nombres de puerto / URL separado que fuera el registro. ¿O incluso una API completamente diferente?

+1 - Me encantaría verlo funcionar de la misma manera que funciona el registro, por lo que no tenía que preocuparse si estaba hablando con un registro o con un demonio docker remoto.

No estoy seguro de cuánto trabajo sería esto, pero si son iguales, entonces la funcionalidad de empujar/tirar del registro podría convertirse esencialmente en una autenticación liviana que se encuentra frente a un demonio docker.

Una implementación funcional sobre SSH aquí: https://github.com/docker/docker/pull/9304

¿Alguien puede decirme si vamos a obtener esta función en un futuro próximo en alguna versión?
Me encantaría ver esta característica.

+1 ¡Me encantaría ver eso también!

+1.

+1 en esto. Actualmente usamos docker save | ssh -C docker load para transferir imágenes, pero eso transfiere _todo_, incluidas las piezas que ya tenemos. Sería mucho más fácil si solo pudiera transferir los bits que importan.

_ENCUESTA DE USUARIOS_

_La mejor manera de recibir una notificación cuando haya cambios en esta discusión es haciendo clic en el botón Suscribirse en la parte superior derecha._

Las personas que se enumeran a continuación han apreciado su discusión significativa con un +1 aleatorio:

@xiaods
@hustcat
@leonardschneider
@v00rh33s

Todavía parece una característica válida para tener. No estoy seguro de si es posible con cosas de seguridad/verificación.
¿Pensamientos @tonistiigi ?

@ LK4D4 creo que podemos cerrarlo, si alguien puede dar un diseño de propuesta real, entonces puede abrir otro tema para seguir el tema.

¿Fue útil esta página
0 / 5 - 0 calificaciones