Moby: Push/pull ponto a ponto entre hosts do docker

Criado em 29 mar. 2013  ·  22Comentários  ·  Fonte: moby/moby

Após discussão com @shykes no irc.

Quando o daemon do docker estiver em execução, ele deverá aceitar solicitações push/pull. Isso permitirá que dois daemons enviem imagens entre si de forma p2p ou centralizada.

Além disso, deve haver uma opção -norun para desabilitar a execução. Isso será útil ao executar um repositório de imagens dedicado. Nesse modo, o docker deve funcionar mesmo sem o módulo lxc ou aufs.

Uma vez que isso exista, a implementação atual do repositório público pode ser substituída por um daemon docker.

aredistribution exexpert kinfeature

Todos 22 comentários

Correto em todos os aspectos :)

O que estamos buscando é um sistema comparável à linguagem go. por exemplo. você pode hospedar um pacote em qualquer lugar e, como conveniência, há um namespace central com curadoria com diretrizes para qualidade, auditoria, segurança etc.

Este é um subcomponente do nº 21.

Mudei o título para esclarecer a diferença com #350.

Este problema é sobre como adicionar o recurso push/pull ponto a ponto ao Docker. Com esse recurso, 2 hosts docker podem trocar imagens diretamente como se estivessem trocando imagens com o registro.

Pensando um pouco mais em detalhes aqui.

  • Queremos dar suporte ao push para _e_ ao pull de outro daemon?
  • O docker deve sempre aceitar pushs (e pulls) de imagens ou precisa ser executado no modo promíscuo?
  • E quanto ao daemon - autenticação e autorização do daemon?
  • Qual é o comando para enviar para outro daemon? docker push -d other.docker.com myimage ?
  • A transferência usará exatamente o mesmo mecanismo que o push/pull de registro regular? (HTTP, etc.)
  • O nº 21 está ligado a esta questão. Por exemplo, incluiria uma rota para POST ing de uma imagem para outro daemon. Ou talvez isso seja substituído por qualquer API que o registro use.

Em segunda-feira, 8 de abril de 2013 às 20h21, Caleb Spare [email protected] escreveu :

  • Queremos dar suporte ao push para _e_ ao pull de outro daemon?

Acho que sim. Se eu tivesse que escolher um, escolheria o push para começar.

  • O docker deve sempre aceitar pushs (e pulls) de imagens ou
    precisa ser executado em modo promíscuo?

Acho bom começar assim. Podemos torná-lo um interruptor condicional,
por exemplo. 'docker -d --no-push-pull'

  • E quanto ao daemon - autenticação e autorização do daemon?

Acho que podemos nos preocupar com isso mais tarde.

  • Qual é o comando para enviar para outro daemon? docker push -d
    other.docker.com minha imagem?

Isso parece razoável. @samalba @kencochrane e @shin- que são
implementar o registro pode ter uma opinião aqui.

  • A transferência vai usar exatamente o mesmo mecanismo que o normal?
    registro push/pull? (HTTP, etc.)

Sim, esse é o objetivo.

  • # 21 https://github.com/dotcloud/docker/issues/21 está vinculado a isso
    questão. Por exemplo, incluiria uma rota para POSTar uma imagem para
    outro demônio. Ou talvez isso seja substituído por qualquer API do registro
    usa.

Absolutamente. Comecei a trabalhar no número 21, que tal eu compartilhar a base com vocês
e trabalhamos em paralelo nas 2 partes diferentes da API?

@shykes Isso parece ótimo. Basta enviar o código #21 para uma ramificação?

Isso será significativamente mais fácil usando a API 1.0.

Este seria um ótimo plugin, se alguém estiver interessado em trabalhar nisso, diga aqui. Vou conectar você com os primeiros documentos da API e dicas para começar.

Isso soa interessante. Existe algum prazo rígido para este recurso? Se não, posso pegá-lo e trabalhar nele até o final deste mês (ou pode ser setembro. Tenho algum outro trabalho para fazer nas últimas semanas.)

@shykes Seria ótimo se eu pudesse acessar um plano mais detalhado de APIs 1.0.

@tobstarr , se você quiser usar essa sua implementação de registro go para permitir que o docker receba um push ... acho que seria um recurso matador! Ficarei feliz em ajudá-lo a combiná-lo.

Ainda estou interessado nisso. Se alguém quiser experimentar, avisa :)

+1 para mim

Eu gostaria muito de construir isso. A ideia básica é sobrepor a API de registro em cima da API remota? Parece que o endpoint /images/:id/json é mais ou menos compatível, e todo o resto não colide.

Seria muito legal se a API de registro fosse um subconjunto da API remota. Como alternativa, acho que poderíamos ter um namespace de porta / URL separado que era o registro. Ou até mesmo uma API totalmente diferente?

+1 - Eu adoraria vê-lo funcionar da mesma maneira que o registro funciona, para que você não precise se preocupar se estiver falando com um registro ou com um daemon docker remoto.

Não tenho certeza de quanto trabalho isso seria, mas se eles forem os mesmos, a funcionalidade push/pull do registro pode se tornar essencialmente uma autenticação leve que fica na frente de um daemon do docker.

Uma implementação de trabalho sobre SSH aqui: https://github.com/docker/docker/pull/9304

Alguém pode me dizer se vamos obter esse recurso em um futuro próximo em qualquer versão?
Eu adoraria ver esse recurso

+1 Adoraria ver isso também!

+1.

+1 nisso. Atualmente usamos docker save | ssh -C docker load para transferir imagens, mas isso transfere _tudo_, inclusive as peças que já temos. Seria muito mais fácil se eu pudesse transferir apenas os bits que importavam.

_PESQUISA DE USUÁRIO_

_A melhor maneira de ser notificado quando houver alterações nesta discussão é clicando no botão Inscrever-se no canto superior direito._

As pessoas listadas abaixo apreciaram sua discussão significativa com um +1 aleatório:

@xiaods
@hustcat
@leonardschneider
@v00rh33s

Ainda parece um recurso válido para ter. Não tenho certeza se é possível com coisas de segurança/verificação.
Pensamentos @tonistiigi ?

@LK4D4 acho que podemos fechá-lo, se alguém puder dar um design de proposta real, ele poderá abrir outro problema para acompanhar o tópico.

Esta página foi útil?
0 / 5 - 0 avaliações