Machine: Anexar à máquina existente de outro cliente

: +1:

Que tal adicioná-lo ao segundo sistema usando o driver 'genérico' e então usar o mesmo comando eval lá?

@clnperez é uma proposta ou algo que você tem certeza de que funcionará (significa que reutilizará a máquina remota existente, mesmo se estiver em execução)?

Bem, em retrospectiva, eu não acho que você pode fazer isso b / c você teria que configurar as chaves ssh novamente, ou importá-las de seu outro sistema.

Eu vejo seu caso. Não se pode adicionar uma entrada de docker-machine no segundo sistema usando o driver genérico, a menos que você queira invalidar a configuração original da docker-machine (já que, por exemplo, novos creds são gerados). Pode-se executar docker-machine create -d none --url [...] no segundo sistema espelhando opções importantes (como os sinalizadores de swarm) da criação original no primeiro sistema e, em seguida, copiando manualmente os arquivos .pem selecionados e o arquivo id_rsa da primeira máquina para a segunda máquina E adicione manualmente seções para acesso SSH (e altere manualmente o driver de nenhum para genérico). É um PITA. Uma função de exportação / importação adequada seria boa para permitir o compartilhamento. Também é possível compartilhar apenas os arquivos cred necessários para configurar manualmente o docker.

Corrigir. A única maneira atual seria pegar todo o diretório, mas isso não funcionará com alguns drivers (ou seja, VirtualBox porque ele registra VMs e redes com UUIDs que não correspondem). Houve discussão sobre um recurso de importação / exportação no passado (https://github.com/docker/machine/issues/23)

Eu tenho uma solução PR / hacky para isso nas asas ... Geralmente eu acho que quero mudar a configuração para ser portátil / modelada em vez de codificada como as coisas são agora.

+1

Eu adoraria ser capaz de me reconectar rapidamente a instâncias de nuvem (estou usando o GCE) que já existem.

Certamente, ter configurações importáveis ​​/ exportáveis ​​seria muito útil, mas eu me pergunto se (além disso) abordar o problema como uma preocupação do driver pode não resultar em uma experiência do usuário mais simples.

Dessa forma, usando o driver do google, pode-se conectar a uma instância existente em um computador alternativo simplesmente fornecendo um token de acesso válido (que o driver pode solicitar que o usuário gere automaticamente).

Da mesma forma, ao usar o driver aws, por exemplo, (o que eu ainda tenho que fazer, mas presumo), pode-se conectar a uma instância existente fornecendo um par de chave / segredo válido (talvez por meio de variáveis ​​de ambiente correspondentes ao driver específico relevante sinalizadores - assumindo que o processo ocorrerá por meio de algum subcomando docker-machine diferente de "criar", já que as expectativas são um pouco diferentes).

Só quero dizer que esse seria um ótimo recurso de se ter. Eu realmente gostaria de poder compartilhar uma máquina com meus companheiros de equipe e fiquei desapontado ao descobrir que basicamente não havia como fazer isso agora. Seria incrível se, por exemplo, o driver generic pudesse detectar automaticamente se uma determinada caixa já havia sido provisionada com docker-machine e reutilizar certificados tls, etc. quando alguém executasse docker-machine create nessa caixa novamente.

: +1. Eu adoraria ver isso funcionando. Atualmente, estamos co-gerenciando as mesmas máquinas (no Google Compute Engine) com outra pessoa e a única maneira que descobri trabalhando é copiar todo o diretório (+ alterar os links absolutos no arquivo config.json). Isso é ridículo. Acho que o driver genérico não pode ser usado facilmente desta forma - há um problema de autenticação, é claro (tls certs etc.) não pode ser simplesmente reutilizado quando você executa --create com o driver genérico (de alguma forma, você precisa autenticar e provar que tem acesso à máquina, que é diferente para cada driver - no GCE, você tem que verificar se sua autenticação gcloud permite acessar a máquina) Também há um pequeno problema que, a menos que você já tenha criado a máquina antes com o driver fornecido, sua parte de autenticação está faltando (a única maneira de autenticar é .. criar a máquina).

O que eu acho que a melhor solução é ter o comando "import" (com implementação diferente para drivers diferentes). Por exemplo, no GCE, você pode armazenar todos os detalhes necessários (chaves, etc.) em algum lugar nos metadados da máquina: https://cloud.google.com/compute/docs/metadata?hl=en#project_and_instance_metadata e, em seguida, por meio de especificação o nome do projeto / máquina (e autenticação) você pode obter todas as chaves necessárias e configurar a máquina.

Eu realmente aprecio esse recurso!

@potiuk Qual diretório você copia?

@AlexZeitler ~/.docker/machine/machines/<machinename>

+1!

+1 Eu adoraria ver uma solução para isso também :-)

Corri exatamente esse problema hoje para dar acesso a um colega.

+1 !!!!!

Parece ser uma duplicata do nº 23, certo?
Quase 1 ano desde que falamos sobre esse recurso, alguns tentaram fazer PRs para ele, mas foram fechados ...
Espero que este recurso esteja no próximo (principal) lançamento :)

Isso é absolutamente necessário em cenários de entrega contínua, onde você deseja implantar usando as chaves do Travis ou Circle CI. Alguma pista sobre o ETA?

tenho que dar a isso +1 também

+1

+1

Existe algo que você precisa fazer além de copiar a pasta ~/.docker/machine/machines/<name> e alterar os caminhos absolutos? Recebo uma mensagem de erro relacionada aos meus certificados e a tentativa de regenerá-los também falha.

@jbasrai O IP do que você está tentando acessar mudou?

Eu preenchi https://github.com/docker/machine/issues/2516 para começar a considerar as etapas na direção certa para tornar isso mais fácil.

Este é um recurso vital e eu adoraria vê-lo em uma versão em um futuro próximo. Na minha opinião, a configuração da máquina deve permanecer exclusiva para um cliente, não ser importada / exportada. Em vez disso (como outros mencionaram), docker-machine create executado com os mesmos argumentos deve ser capaz de criar uma configuração para a máquina, mesmo se ela já existir remotamente, em vez de falhar como agora. Ao executar novamente meu comando de criação para uma máquina amazonec2 existente, recebo este erro informando que o host já existe:

Error creating machine: Error with pre-create check: There is already a keypair with the name testing-recreate.  Please either remove that keypair or use a different machine name.

Em vez disso, pode me avisar que o host já existe e continuar a adicionar a máquina como faria em uma criação inicial (talvez exigindo que um sinalizador de substituição seja passado). Dessa forma, posso manter os scripts de configuração do meu ambiente de desenvolvimento / CI simples e não me preocupar em ter que armazenar essa configuração em algum lugar onde meus colegas de equipe (ou outras partes) possam acessá-la.

É realmente surpreendente que, para várias pessoas trabalharem na mesma VM, tenhamos que exportar / importar certificados de uma máquina para outra. Se alguém encontrou uma solução prática e pronta para a produção, seria bom saber.

+1

+1

Corrigir. A única maneira atual seria pegar todo o diretório, mas isso não funcionará com alguns drivers (ou seja, VirtualBox porque ele registra VMs e redes com UUIDs que não correspondem). Houve discussão sobre um recurso de importação / exportação no passado (# 23)

@ehazlett então estou usando o driver aws, posso:

1. comprimir a máquina em nuvem ~/.docker/machine/machines/staging
2. compartilhar com os membros da equipe, eles descomprimirão em ~/.docker/machine/machines/
3. eles terão máquina de teste como eu tenho? docker-machine ls (ou eles precisam fazer outro comando)

@leandromoreira uma barreira para essa abordagem é que os arquivos de configuração da máquina docker têm caminhos

cat ~/.docker/machine/machines/local/config.json

outputs:

...
        "AuthOptions": {
            "CertDir": "/Users/pretzel/.docker/machine/certs",
            "CaCertPath": "/Users/pretzel/.docker/machine/certs/ca.pem",
            "CaPrivateKeyPath": "/Users/pretzel/.docker/machine/certs/ca-key.pem",
            "CaCertRemotePath": "",
            "ServerCertPath": "/Users/pretzel/.docker/machine/machines/local/server.pem",
            "ServerKeyPath": "/Users/pretzel/.docker/machine/machines/local/server-key.pem",
            "ClientKeyPath": "/Users/pretzel/.docker/machine/certs/key.pem",
            "ServerCertRemotePath": "",
            "ServerKeyRemotePath": "",
            "ClientCertPath": "/Users/pretzel/.docker/machine/certs/cert.pem",
            "ServerCertSANs": [],
            "StorePath": "/Users/pretzel/.docker/machine/machines/local"
        }

então, simplesmente copiar o diretório inteiro não é uma solução completa

@bhurlow muito obrigado: smile: existe alguma ferramenta para ajudar nisso? ou devo editar config.json manualmente? essa é a única barreira?

@leandromoreira tenho script em torno dele como este , versões mais recentes do estivador-máquina chaves codificar não base64 no arquivo de configuração. No final do dia, qualquer pessoa que queira usar uma docker-machine remota _deve_ ter os certificados TLS, então alguma troca entre as partes é necessária, eu acho

Obrigado @bhurlow

@bcwalrus fez uma ótima ferramenta até conseguirmos algo oficial.

npm install -g machine-share

# export
machine-share export amazon

# import
machine-share import  amazon.tar

# fix locations :D (it seems this is not using base64 anymore)
machine-share driverfix amazon

@leandromoreira parece ótimo cara, consegui exportar e importar as configurações com sucesso.

@muhammadghazali foi @bhurlow ideia e esforço: stick_out_tongue:

+1 Alguma atualização sobre uma solução oficial para isso?

Com docker versão 1.10.1, percebi que o arquivo config.json tem referências ao seguinte do diretório ~ / docker / machine / certs

        "CertDir": "/home/abc/.docker/machine/certs",
        "CaCertPath": "/home/abc/.docker/machine/certs/ca.pem",
        "CaPrivateKeyPath": "/home/abc/.docker/machine/certs/ca-key.pem",
        "ClientKeyPath": "/home/abc/.docker/machine/certs/key.pem",
        "ClientCertPath": "/home/abc/.docker/machine/certs/cert.pem",

Você precisa copiar a pasta ~ / .docker / machine / certs também da máquina original para que este cenário funcione.

A solução atual para isso parece ser (por exemplo, se você deseja criar uma máquina Docker na AWS em um computador e visualizar os logs ou SSH na máquina de outro):

1. Crie um novo diretório my-dir e my-dir/machine para as máquinas Docker que deseja compartilhar para que não use seus certificados padrão
2. Crie sua máquina Docker usando a opção --storage-path my-dir/machine (certifique-se de especificar o caminho absoluto)
3. Para compartilhar a máquina, edite config.json em my-dir/machine/machines/machine-name e substitua o caminho absoluto para my-dir/machine por $MACHINE_STORAGE_PATH
4. Faça upload de my-dir algum lugar, por exemplo, no Github

Quando alguém quiser importar esta Máquina:

1. Clone ou baixe my-dir
2. Edite config.json para a Máquina em my-dir/machine/machines/machine-name e substitua $MACHINE_STORAGE_PATH pelo caminho absoluto para my-dir/machine em seu computador local
3. chmod 0600 the id_rsa em my-dir/machine/machines/machine-name

Agora você pode usar comandos Docker Machine usando a opção --storage-path my-dir/machine (certifique-se de especificar o caminho absoluto).

Isso poderia ser melhorado por:

• Máquina Docker armazenando caminhos relativos em config.json, então isso não precisava ser editado
• Docker Machine SSH (e comandos relacionados) chmodding id_rsa para 0600 automaticamente (se eles tiverem permissão para)

Um ponto rápido, se você usar o envsubst então você pode substituir programaticamente o $ MACHINE_STORAGE_PATH e não tem que editar manualmente. Mesmo assim, a coisa toda é meio inconveniente para as equipes que tentam usar um conjunto de sistemas docker-machine.

No entanto, se as pessoas estão procurando uma solução alternativa, o mais fácil que encontrei é:

1. Copie .docker/machine/certs para um local privado. Nota _não_ coloque isso em um repositório, pois ele contém segredos que fornecem acesso a outras máquinas. Usamos uma loja privada para este fim
2. Na nova máquina host, copie os certificados para o novo .docker/machine/certs
3. Agora execute novamente a criação de sua docker-machine e você poderá usar isso sem alterar todas as configurações. Demora mais, mas é mais portátil e você não precisa editar todos os arquivos de configuração.

Tenho dois computadores diferentes com os quais trabalho e isso é um problema real para mim.
Descrevo aqui o comportamento dos sonhos que espero ao usar docker-machine:

1) Crie uma gota no DigitalOcean com docker-machine e o driver DigitalOcean (com algum token que você obtém do painel de controle do DigitalOcean).

docker-machine create --driver digitalocean --digitalocean-access-token \
    [token_goes_here] --digitalocean-image ubuntu-16-04-x64 --digitalocean-size \
    1gb [host_name_goes_here]

2) Vá para um computador diferente, obtenha outro token do DigitalOcean e anexe à máquina existente com um comando mágico de anexação, como este:

docker-machine **attach** --driver digitalocean --digitalocean-access-token \
    [token_goes_here]  [host_name_goes_here]

Quais são os obstáculos para fazer este trabalho? Acho que o token de acesso DigitalOcean dá privilégios suficientes para anexar a um host existente e configurar toda a comunicação segura.

Por enquanto, vou tentar o compartilhamento de máquina por @bhurlow : https://github.com/bhurlow/machine-share

+1 Bump nisto - alguém tem uma atualização sobre isso?

@brandontamm : Eu escrevi alguns scripts para lidar com esse problema sozinho. Não sei se eles vão resolver o seu, mas posso pelo menos tentar. Confira a essência aqui

Um resumo da essência: Existem duas funções - store_machine e load_machine. store_machine armazena todas as informações sobre uma máquina dentro do stash seguro (criptografado no armazenamento de dados do disco). Você terá que fornecer uma senha. A função load_machine carrega uma máquina do armazenamento de dados do disco.

Observe que este código python assume que você tem o sstash (Python Secure Stash) instalado. Você pode instalá-lo executando

pip install sstash

+1

Sério - para que serve Docker-Machine a menos que você possa acessá-lo de outro dispositivo pré-definido ....

CASO DE USO - Construí a docker-machine no trabalho, mas depois preciso do laptop para as férias, caso um servidor exploda ...

Qual é - onde o Docker Admin está falando sobre isso ?! Esse é um caso de uso que TODOS podem apreciar.

@realcr Você tentou o compartilhamento de máquina ?

Recuso-me a usar mais dependências :) Copiar a pasta .docker para ambas as máquinas OSX funcionou perfeitamente para mim. Meus caminhos e nomes de usuário eram os mesmos em ambas as máquinas, embora essa seja a chave sem editar os caminhos manualmente.

Brandon Tamm
Enviado de celular

Em 4 de novembro de 2016, às 03h36, Sébastien Boulet [email protected] escreveu:

@realcr Você tentou o compartilhamento de máquina?

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub ou ignore a conversa.

+1

+1

+1

+1

Escrevi docker_machinator para tentar resolver esse problema.
Esta é uma ferramenta python que permite que você salve todas as suas credenciais e configuração da docker-machine em um esconderijo criptografado que você pode armazenar em seu provedor de nuvem, por exemplo. Você pode então fazer o download de outro host e carregar suas máquinas de volta do stash.
Esta é uma ferramenta python, então você deve estar pip install de usá-la.

Não acho que essa seja a solução perfeita, mas pode ajudar você até que encontremos uma melhor.

Pessoal, vocês devem saber que machine-share exporta sua chave ssh privada que você usou para criar docker host via docker-machine com driver genérico. Assim, todos para quem você enviar o arquivo exportado poderão obter acesso ao servidor que executa o docker.

@mxl docker-machine fornece um subcomando ssh que concederá acesso ao servidor, portanto, a situação que você está descrevendo é inevitável se você tiver uma ferramenta que cria uma configuração inteira como um arquivo importável.

➜ docker-machine
Usage: docker-machine [OPTIONS] COMMAND [arg...]
...
Commands:
...
  ssh                   Log into or run a command on a machine with SSH.

Acho que a maneira de evitar isso seria criando um comando que pudesse baixar a configuração atual da máquina remota. Esse download exigiria que você pudesse fazer o ssh para a máquina, em vez de empacotar o acesso no arquivo importável.

Ser capaz de controlar a docker-machine apenas de um host é uma limitação desconfortável.
Também adoraria ver algo como docker-machine config-from <otherhost> .

Então, 1 de mim também.

/ Edit: No momento, estou resolvendo o problema sincronizando .docker de um "servidor mestre" para todos os outros servidores que precisam das mesmas configurações - via cron e rsync. Isso é, por exemplo, necessário para vários escravos de construção. Não é uma solução muito boa.

+1

Aqui está um cenário diferente que me traz aqui.

Eu criei um droplet para construir um monte de imagens docker para depois perceber que preciso mover a região do host ...

A questão é como faço para anexar a instância docker-machine restaurada do instantâneo em execução no novo host?

Na sexta-feira, 10 de março de 2017 às 6h16, exjimsk [email protected] escreveu:

Eu criei uma gota para construir um monte de imagens docker para depois perceber que
precisa mover a região hospedeira. Como faço para anexar a instância docker-machine
restaurado a partir do instantâneo em execução no novo host?

Se os certificados não mudaram, você deve ser capaz de alterar apenas o seu
configuração docker-machine para apontá-lo para o novo endereço IP. Você encontrará o
arquivo em ~ / .docker / machine / machines / your-machine-name / config.json.

Como alternativa, se você nunca persistir os dados em seus contêineres Docker, em vez disso
de mover o hospedeiro, apenas mate-o, faça um novo e inicie o mesmo
contêineres no novo host.
ᐧ

+1

+1

+1

+1

+1

+1

+1

+1

docker-machine attach , por favor.

É notável que tal funcionalidade óbvia ainda não exista fora da caixa. Vamos administrar os hosts docker em conjunto, e isso é um incômodo.

No meu caso, muito prazer em anexar o host existente ${HOST} com

docker-machine --tlscacert=ca.pem --tlscert=cert.pem --tlskey=key.pem create \
    --drive none --url tcp://${HOST}:2376

Mas é necessário copiar os certificados ( ca.pem, cert.pem, key.pem ) para DOCKER_CERT_PATH manualmente.

Algum plano para isso? Ter caminhos completos registrados em config.json é frustrante.

Meu caso de uso: tenho um repositório git com configurações de máquina nele (eu uso -s para apontar docker-machine para ele). Os segredos são armazenados com git encrypt e a ideia é que os jobs de CI sejam capazes de usar essas configurações para manipular as máquinas que precisam acessar.

FYI: # 3212

@lyda Estamos usando essa abordagem com https://github.com/dmstr/docker-roj - mas sem criptografia, o que seria um recurso muito bom, na verdade!

Embora o roj sempre trabalhe com os mesmos caminhos, já que está em um contêiner, existem outras soluções como:

• https://github.com/bhurlow/machine-share
• https://gist.github.com/realcr/2363c699e893c66ac7ed72da29804b0a

que basicamente muda alguns caminhos no config.json .
Não é nenhuma grande mágica, a menos que eu esteja totalmente perdendo alguma coisa aqui.

docker-machine está sendo ativamente desenvolvido pelo docker? Eu pergunto porque já se passou mais de um mês desde que um commit chegou ao master: https://github.com/docker/machine/commits/master

+1

+1

+1

Meu Deus, que horror! Este tópico ainda está vivo depois de quase três anos?!? Este é um caso de uso que todo mundo encontra, ou parece que sim. o que estou perdendo?

Bem, eu presumo que docker-machine está morto (pelo menos para mim: D). Mudei para kubernetes . Mesmo auto-hospedado kubeadm na versão alfa funciona melhor do que na verdade. Posso recomendar :)

por favor apoie isto :(

adicione "~ / .docker" a uma pasta que é sincronizada ou talvez simbolicamente vinculada à pasta da nuvem em ambas as máquinas. existem algumas soluções pré-construídas. não é muito difícil rapazes, apenas pesquisem - nunca tive um problema depois de configurar uma vez por 30 segundos.

+1

+1

Como esse recurso, além de especificar um IP estático - os dois recursos mais solicitados na história do projeto da docker-machine - fica sem implementação, está além de mim.

Quase 4 anos se passaram 😮 Há alguma atualização sobre isso?

No momento, muitos artigos / tutoriais sobre o Docker ainda estão sugerindo o uso do docker-machine como a ferramenta de fato para gerenciar hosts. No entanto, essa presença de problema é um forte fator limitante!

Atualmente, continuo usando docker-machine e uso a abordagem “copy-certs-dirs” para compartilhar entre nossos computadores locais. Eu gostaria de fazer upgrade para o Kubernetes, mas parece demais para o meu projeto.

Que tal executar docker-machine create de dentro de um contêiner do docker? Esse contêiner poderia então ser exportado, importado em outro computador e executado lá.

Ainda não tem anexo meu deus