Machine: A criação da máquina falha com o Docker mais recente

Criado em 29 jun. 2017  ·  46Comentários  ·  Fonte: docker/machine

Olá

docker-machine versão 0.12.0, compilação 45c69ad

docker-machine create falha agora:

docker-machine -D create \
    --driver google \
    --google-project project \
    --google-zone us-east1-d \
    --google-machine-type n1-standard-1 \
    --google-disk-size 20 \
    --google-preemptible \
    build-vm2

A máquina é criada e o Docker está instalado, mas não inicia. O problema parece estar relacionado a uma nova versão do Docker sendo instalada por uma nova versão do script de instalação em https://get.docker.com. Minhas instalações foram de 17.05.0-ce para 17.06.0-ce e, com essa mudança, o Docker é instalado, mas não inicia.

Jun 29 00:50:08 build-vm2 docker[5705]: `docker daemon` is not supported on Linux. Please run `dockerd` directly

ou

Jun 29 00:56:12 build-vm2 dockerd[6407]: Error starting daemon: error initializing graphdriver: driver not supported

A menos que eu mude:

/usr/bin/docker daemon -H tcp://0.0.0.0:2376 -H unix:///var/run/docker.sock --storage-driver aufs --tlsverify --tlscacert /etc/docker/ca.pem --tlscert /etc/docker/server.pem --tlskey /etc/docker/server-key.pem --label provider=google

para

/usr/bin/dockerd -H tcp://0.0.0.0:2376 -H unix:///var/run/docker.sock --tlsverify --tlscacert /etc/docker/ca.pem --tlscert /etc/docker/server.pem --tlskey /etc/docker/server-key.pem --label provider=google

em /etc/systemd/system/docker.service.d/10-machine.conf .

areprovision kinbug

Comentários muito úteis

Estou usando isso como uma solução alternativa:

docker-machine create \
--driver amazonec2 \
--engine-install-url = https://web.archive.org/web/20170623081500/https : //get.docker.com

ou
--engine-install-url = https://releases.rancher.com/install-docker/17.05.sh

Todos 46 comentários

Mesmo problema aqui

docker-machine create 
    --driver=digitalocean
    --digitalocean-access-token=XXX 
    --digitalocean-size=2gb
    machinename

Ontem, o mesmo comando funcionou bem com docker versão 17.05.0-ce
Hoje, a docker da minha nova máquina não inicia (17.06.0-ce)
Tentei várias vezes.

Eu posso confirmar isso também:

dm create -d digitalocean \
--digitalocean-access-token XXX \
--digitalocean-size 4gb machine

Estou usando isso como uma solução alternativa:

docker-machine create \
--driver amazonec2 \
--engine-install-url = https://web.archive.org/web/20170623081500/https : //get.docker.com

ou
--engine-install-url = https://releases.rancher.com/install-docker/17.05.sh

Eu tenho o mesmo problema.

versão do docker: Docker versão 17.06.0-ce
versão docker-machine: 0.12.0, compilação 45c69ad

docker-machine create --driver amazonec2 --amazonec2-region eu-west-1 --amazonec2-instance-type t2.small --amazonec2-access-key XXX --amazonec2-secret-key XXX test-create-machine

29 de junho 12:26:56 ip-172-31-10-149 systemd [1]: Iniciando o Docker Application Container Engine ...
29 de junho 12:26:56 ip-172-31-10-149 docker [5234]: docker daemon não é compatível com Linux. Execute dockerd diretamente

docker daemon não é compatível com Linux. Execute dockerd diretamente

Consegui fazer funcionar com este PR
https://github.com/docker/machine/pull/4128

Basta compilar a docker-machine com esta correção e tudo funcionará novamente

@gnomus super, isso é interessante! Eu me pergunto por que estava funcionando para 17.05.0-ce, no entanto.

@therealppa haahaha incrível! Gostaria de saber como posso obter a versão antiga desse script, ou se o script ao vivo leva parâmetros para instalar uma versão mais antiga. web.archive.org definitivamente não me ocorreu.

@dminkovsky Não acho que funcionará para sempre, se você olhar no script, ele não especifica a versão em lugar nenhum ... Mesmo assim, agora funciona.

@therealppa @dminkovsky Uma correção de longo prazo é mudar a linha 457 do script de

$sh_c 'apt-get install -y -q docker-ce'

para

$sh_c "apt-get install -y -q docker-ce=17.05.0~ce-0~$lsb_dist-$dist_version"

Esperançosamente, a versão corrigida do docker-machine será lançada em breve.

o mesmo para mim
Fazemos isso funcionar usando "dockerd" em vez de "docker daemon" no arquivo /etc/systemd/system/docker.service.d/10-machine.conf

@ fabio-barile, e quanto ao --storage-driver aufs arg? O meu não iria começar a menos que eu me livrasse disso também.

@dminkovsky Eu tive o mesmo problema em um autoescaling ci com gitlab, peguei o problema aufs + problema dockerd, tive que resolver especificando overlay no driver de armazenamento.

Além do problema do driver de armazenamento, também estou vendo erros de verificação para certificados criados por gitlab-runner (9.3.0). @JustEra você está tendo o mesmo problema ou eu sou o único?

http: TLS handshake error from ...:
 tls:
  failed to verify client's certificate: x509:
   certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "unknown")
ERROR: Error creating machine:
 Error checking the host:
  Error checking and/or regenerating the certs:
   There was an error validating certificates for host "...":
    remote error: tls: bad certificate  driver=amazonec2 name=...

Esse problema de driver de armazenamento corrigido para mim (acabei de remover esse parâmetro; SOMENTE para o systemd). Inscreva-se em https://github.com/docker/machine/pull/4128 e recrie:

diff --git a/libmachine/provision/systemd.go b/libmachine/provision/systemd.go
index 90d02603..05d63bb5 100644
--- a/libmachine/provision/systemd.go
+++ b/libmachine/provision/systemd.go
@@ -53,7 +53,7 @@ func (p *SystemdProvisioner) GenerateDockerOptions(dockerPort int) (*DockerOptio

        engineConfigTmpl := `[Service]
 ExecStart=
-ExecStart=/usr/bin/` + arg + ` -H tcp://0.0.0.0:{{.DockerPort}} -H unix:///var/run/docker.sock --storage-driver {{.EngineOptions.StorageDriver}} --tlsverify --tlscacert {{.AuthOptions.CaCertRemotePath}} --tlscert {{.AuthOptions.ServerCertRemotePath}} --tlskey {{.AuthOptions.ServerKeyRemotePath}} {{ range .EngineOptions.Labels }}--label {{.}} {{ end }}{{ range .EngineOptions.InsecureRegistry }}--insecure-registry {{.}} {{ end }}{{ range .EngineOptions.RegistryMirror }}--registry-mirror {{.}} {{ end }}{{ range .EngineOptions.ArbitraryFlags }}--{{.}} {{ end }}
+ExecStart=/usr/bin/` + arg + ` -H tcp://0.0.0.0:{{.DockerPort}} -H unix:///var/run/docker.sock --tlsverify --tlscacert {{.AuthOptions.CaCertRemotePath}} --tlscert {{.AuthOptions.ServerCertRemotePath}} --tlskey {{.AuthOptions.ServerKeyRemotePath}} {{ range .EngineOptions.Labels }}--label {{.}} {{ end }}{{ range .EngineOptions.InsecureRegistry }}--insecure-registry {{.}} {{ end }}{{ range .EngineOptions.RegistryMirror }}--registry-mirror {{.}} {{ end }}{{ range .EngineOptions.ArbitraryFlags }}--{{.}} {{ end }}

Para quem deseja uma versão mais antiga específica, nós (Rancher) mantemos scripts get.docker.com ligeiramente modificados para instalar cada um:

http://rancher.com/docs/rancher/v1.6/en/hosts/#supported -docker-versions

@fabio-barile acima está totalmente correto. Como o 'teste' permite que tais coisas sejam emitidas, não consigo imaginar.

Mais informações aqui: https://github.com/docker/for-linux/issues/11#issuecomment -312143765

@ vincent99 ... sempre gostei do som de

+1
Eu volto todos os dias para ver se há uma nova versão da docker-machine ... Esse bug está me matando :-)

Por enquanto, adiciono /etc/systemd/system/docker.service.d/20-machine.conf que substitui 10-machine.conf com a linha de comando correta. Dessa forma, o comando docker-machine que normalmente o quebraria, não o faz. É claro que quanto mais tempo leva para isso ser corrigido no lançamento, mais trabalho terei para colocar tudo de volta!

Obrigado pela grande análise de detalhes sobre o problema. Estamos investigando para tentar descobrir o que deu errado.

relacionado a https://github.com/docker/for-linux/issues/11#issuecomment -312143765

Portanto, isso não está relacionado ao script de instalação em get.docker.com mas sim à comparação de versões que não está funcionando corretamente e com 17.06.0-ce sendo o primeiro a descontinuar oficialmente docker daemon é por isso que estamos vendo falhas.

Este PR (docker / machine # 4128) parece resolver esse problema e terei um PR no final da tarde que adiciona testes para as outras funções de comparação para que não encontremos algo assim novamente.

@seemethere Parece bom, obrigado. Gostaria de ouvir sobre o teste.

A diferença em um dos PRs pareceu um pouco estranha para mim, mas acho que vocês terão cuidado disso.

A versão 0.12.1 corrige esse bug. Obrigado a todos pela paciência e ajuda.

@ shin- obrigado pela solução rápida! Ansioso para usar isso.

@ shin- Este patch corrige a parte docker daemon -> dockerd , mas o Docker ainda não inicia na máquina devido a

dockerd[6407]: Error starting daemon: error initializing graphdriver: driver not supported

@ shin- Consegui contornar o problema do driver de armazenamento adicionando --engine-storage-driver=overlay (https://github.com/docker/machine/issues/3895#issuecomment-270934728). Então aqui está minha invocação docker-machine inteira.

docker-machine -D create \
    --driver google \
    --google-project $project \
    --google-zone $zone \
    --google-machine-type $type \
    --google-disk-size $size \
    --google-preemptible \
    --engine-storage-driver=overlay \
    $name

Sem --engine-storage-driver=overlay ainda falha com

dockerd[6407]: Error starting daemon: error initializing graphdriver: driver not supported

como antes e como em # 3895

Você viu o log que explica por que ele travou?

Na sexta-feira, 7 de julho de 2017 às 9h39, Seweryn Zeman [email protected]
escrevi:

@ shin- https://github.com/shin- infelizmente 0.12.1 não corrigiu isso
para mim.

$ docker -v
Docker versão 17.06.0-ce, compilação 02c1d87
$ docker-machine -v
docker-machine versão 0.12.1, build c8b17e8

Estou criando uma máquina amazonec2 com --amazonec2-region = eu-central-1
que cria um ami-fe408091 para mim.

A saída de docker-machine create é:

Executando verificações de pré-criação ...
Criando máquina ...
(test-dm) Iniciando instância ...
Esperando que a máquina esteja funcionando, isso pode levar alguns minutos ...
Detectando o sistema operacional da instância criada ...
Aguardando SSH estar disponível ...
Detectando o provisionador ...
Provisionando com ubuntu (systemd) ...
Instalando Docker ...
Copiando certificados para o diretório da máquina local ...
Copiando certificados para a máquina remota ...
Definindo a configuração do Docker no daemon remoto ...
Erro ao criar máquina: Erro ao executar provisionamento: erro de comando ssh:
comando: sudo systemctl -f start docker
err: sair do status 1
saída: Job para docker.service falhou porque o processo de controle saiu com código de erro. Consulte "systemctl status docker.service" e "journalctl -xe" para obter detalhes.

A saída da máquina lançada é:

$ systemctl status docker.service
● docker.service - Docker Application Container Engine
Carregado: carregado (/lib/systemd/system/docker.service; ativado; predefinição do fornecedor: ativado)
Drop-In: /etc/systemd/system/docker.service.d
└─10-machine.conf
Ativo: inativo (morto) (Resultado: código de saída) desde Fri 2017-07-07 13:34:47 UTC; 36s atrás
Docs: https://docs.docker.com
Processo: 5522 ExecStart = / usr / bin / dockerd -H tcp: //0.0.0.0 : 2376 -H unix: ///var/run/docker.sock --storage-driver aufs --tlsverify --tlscacer
PID principal: 5522 (código = saiu, status = 1 / FALHA)

07 de julho 13:34:46 test-dm systemd [1]: docker.service: Unidade entrou em estado de falha.
07 de julho 13:34:46 test-dm systemd [1]: docker.service: Falha com o resultado 'código de saída'.
07 de julho 13:34:47 test-dm systemd [1]: docker.service: Tempo de espera do serviço encerrado, reinicialização do planejamento
07 de julho 13:34:47 test-dm systemd [1]: Container Engine do aplicativo Docker interrompido.
07 de julho 13:34:47 test-dm systemd [1]: docker.service: solicitação inicial repetida muito rapidamente.
07 de julho 13:34:47 test-dm systemd [1]: falha ao iniciar o Docker Application Container Engine.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/docker/machine/issues/4156#issuecomment-313683311 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AANWZXHODzL3Lumb5NqlmXwnSi3VZBBkks5sLjUlgaJpZM4OIt7R
.

@dminkovsky Obrigado pela solução alternativa. Decidi usar overlay2 por ser a versão mais recente do driver.

Você sabe se há uma solução alternativa para docker-machine rm {instance-name} também? Estou recebendo um erro relacionado a EOF e isso deixa resquícios de pares de chaves na nuvem AWS me impedindo de recriar a instância.

Desculpe, eu removi minha mensagem depois de depurar fortemente e percebi que na verdade é devido ao que @dminkovsky escreveu:

Sem --engine-storage-driver=overlay ainda falha com
dockerd[6407]: Error starting daemon: error initializing graphdriver: driver not supported
como antes e como em # 3895

Temos algum problema para este caso particular de usar o armazenamento do motor AUFS?

@cadavre

Temos algum problema para este caso particular de usar o armazenamento do motor AUFS?

Eu vi https://github.com/docker/machine/issues/3895 , que está aberto e que você também fez referência.

Curiosamente, não estou mais vendo esse bug. Eu ganho --storage-driver overlay

@drujensen

Decidi usar overlay2, pois é uma versão mais recente do driver.

Legal, obrigado, eu não sabia disso.

Você sabe se há uma solução alternativa para docker-machine rm {instance-name} também?

Não tenho certeza, eu não tive esse bug. Eu uso docker-machine rm -f quando a máquina foi encerrada e não responde. Com -f , docker-machine rm remove a VM e os discos associados, mesmo que não consiga alcançar a caixa.

@dminkovsky Você pode criar um novo problema para isso? Não está relacionado ao problema de dockerd / docker daemon , portanto, devemos tratá-lo separadamente também. E indique também qual sistema operacional você está provisionando :)

@ shin- estou tudo bem. docker-machine está funcionando 100% agora para mim. você está se referindo à coisa overlay2?

Meu outro problema relacionado à remoção de máquinas foi abordado no pr # 4187. THX.

@dminkovsky Desculpe - sim, aquele que você mencionou aqui

@shin - Depois de experimentar o problema em https://github.com/docker/machine/issues/4168 , tentei recriar meu servidor de teste e encontrei uma série de problemas com docker-machine create que foram relatados em vários tickets recentes:

Tudo isso está relacionado? Começar a rastreá-los aqui? Posso confirmar que esse problema ainda está acontecendo hoje.

@ shin- docker-machine v0.12.1 ainda apresenta o mesmo problema

Ainda estou tendo o mesmo problema com a versão 0.12.1.

screen shot 2017-07-27 at 11 32 00 am

Atualize para a versão mais recente encontrada no github:
https://github.com/docker/machine/releases/tag/v0.12.2

@eamontaaffe @ajwah @costa

Obrigado @dminkovsky Eu estava recebendo este erro no 0.12.2 hoje também !!! Parece que o arquivo 10-machine.conf não foi substituído durante a atualização

De nada!

Eu especifico "overlay" na opção de linha de comando para o mecanismo de armazenamento e desde
a inicialização das minhas máquinas.

ср, 2 авг. 2017 г. 12:05, Denis [email protected] :

Obrigado @dminkovsky https://github.com/dminkovsky Eu estava entendendo
erro no 0.12.2 hoje também !!! Parece que o arquivo 10-machine.conf não
seja substituído durante a atualização

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/docker/machine/issues/4156#issuecomment-319719085 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AANWZSYqy1uGhWeXozx35OnFhPRSb144ks5sUJ5YgaJpZM4OIt7R
.

Se estiver usando sistemas com kernel> 4.4, sugiro usar overlay2 .

Não consegui fazer com que a máquina usasse overlay2 e o caso de uso para este
felizmente estava apenas construindo / CD

ср, 2 авг. 2017 г. 12h36, Seweryn Zeman [email protected] :

Se estiver usando sistemas com kernel> 4.4, sugiro usar overlay2.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/docker/machine/issues/4156#issuecomment-319727847 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AANWZXLGHjLvfOOAgmBWV0zOEBDZBdSVks5sUKWBgaJpZM4OIt7R
.

Também obtendo este erro em 0.12.2 :-(

esta ainda aberta!

Ainda vejo esse problema com docker-machine 0.12.2 . Avancei desinstalando o docker na máquina provisionada ( sudo apt purge docker-ce && sudo apt autoremove ) e usei o script de instalação do Rancher correto para minha versão, conforme listado acima.

Por algum motivo, isso ainda falha ao iniciar o docker, mas reiniciar a máquina resolve o problema.

Pode confirmar, ainda o mesmo erro

@jhartma eu acho que é necessário atualizar para a versão mais recente (imagem do linux) e funciona

@kassanmoor parece que meu AMI não era compatível com a AWS, fiz com que funcionasse com o padrão

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