Machine: La creación de la máquina falla con la última versión de Docker

El mismo problema aqui

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

Ayer, el mismo comando funcionó bien con la versión de Docker 17.05.0-ce
Hoy, la ventana acoplable de mi nueva máquina no se inicia (17.06.0-ce)
Lo he intentado varias veces.

Puedo confirmar esto también:

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

Estoy usando esto como una solución:

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

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

Tengo el mismo problema.

versión de Docker: Docker versión 17.06.0-ce
versión de docker-machine: 0.12.0, compilación 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 junio 12:26:56 ip-172-31-10-149 systemd [1]: Iniciando el motor contenedor de la aplicación Docker ...
29 de junio 12:26:56 ip-172-31-10-149 docker [5234]: docker daemon no es compatible con Linux. Ejecute dockerd directamente

docker daemon no es compatible con Linux. Ejecute dockerd directamente

Pude hacerlo funcionar con este PR
https://github.com/docker/machine/pull/4128

Simplemente compile docker-machine con esta solución y todo volverá a funcionar

@gnomus super, ¡eso es interesante! Sin embargo, me pregunto por qué estaba funcionando para 17.05.0-ce.

@therealppa haahaha ¡increíble! Me preguntaba cómo podría obtener la versión anterior de ese script, o si el script en vivo necesita parámetros para instalar la versión anterior. web.archive.org definitivamente no se me ocurrió.

@dminkovsky No creo que funcione para siempre, si miras el script, en realidad no especifica la versión en ninguna parte ... Aún así, ahora mismo funciona.

@therealppa @dminkovsky Una

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

a

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

Con suerte, la versión fija de docker-machine se lanzará pronto.

lo mismo para mi
Lo hacemos funcionar usando "dockerd" en lugar de "docker daemon" en el archivo /etc/systemd/system/docker.service.d/10-machine.conf

@ fabio-barile ¿qué pasa con el --storage-driver aufs arg? El mío no empezaría a menos que me deshaga de eso también.

@dminkovsky Tuve el mismo problema en un ci de autoescalado con gitlab, obtuve el problema de aufs + problema de dockerd, tuve que resolverlo especificando la superposición en el controlador de almacenamiento.

Más allá del problema del controlador de almacenamiento, también veo errores de verificación para los certificados creados por gitlab-runner (9.3.0). @JustEra, ¿te has encontrado con el mismo problema o soy el ú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=...

Este problema solucionado del controlador de almacenamiento para mí (acaba de eliminar ese parámetro; SOLO para systemd). Aplicar encima de https://github.com/docker/machine/pull/4128 y volver a construir:

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 cualquiera que quiera una versión anterior específica, nosotros (Rancher) mantenemos scripts get.docker.com ligeramente modificados para instalar cada uno:

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

@ fabio-barile arriba es completamente correcto. No puedo imaginar cómo las 'pruebas' permiten que se emitan tales cosas.

Más información aquí: https://github.com/docker/for-linux/issues/11#issuecomment -312143765

@ vincent99 ... siempre me gusta cómo suenan ustedes, y gracias.

+1
Vuelvo todos los días para ver si hay una nueva versión de la máquina acoplable ... Este error me está matando :-)

Por ahora, agrego /etc/systemd/system/docker.service.d/20-machine.conf que anula 10-machine.conf con la línea de comando correcta. De esa manera, un comando adicional de la máquina acoplable que normalmente lo rompería, no lo hace. Por supuesto, cuanto más tiempo se tarde en solucionar este problema en la versión, más trabajo tendré que volver a poner todo.

Gracias por el gran desglose de los detalles sobre el problema. Lo estamos investigando para tratar de averiguar qué salió mal.

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

Por lo tanto, esto no está relacionado con el script de instalación en get.docker.com sino más bien con la comparación de versiones que no funciona correctamente y con 17.06.0-ce siendo el primero en desaprobar oficialmente docker daemon por eso estamos viendo fracasos.

Este PR (docker / machine # 4128) parece solucionar este problema y tendré un PR para la tarde que agrega pruebas para las otras funciones de comparación para que no nos encontremos con algo como esto nuevamente.

@seemethere Suena bien, gracias. Me gusta escuchar sobre la prueba.

La diferencia en uno de los RP me pareció un poco extraña, pero creo que ustedes se habrán encargado de eso.

La versión 0.12.1 corrige este error. Gracias a todos por su paciencia y su ayuda.

@ shin- ¡gracias por la solución rápida! Deseando usarlo.

@ shin- Este parche corrige la parte docker daemon -> dockerd , pero Docker aún no se inicia en la máquina debido a

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

@ shin- Pude solucionar el problema del controlador de almacenamiento agregando --engine-storage-driver=overlay (https://github.com/docker/machine/issues/3895#issuecomment-270934728). Así que aquí está toda mi invocación docker-machine .

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

Sin --engine-storage-driver=overlay todavía falla con

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

como antes y como en # 3895

¿Viste el registro que explica por qué se estrelló?

El viernes 7 de julio de 2017 a las 9:39 a.m., Seweryn Zeman [email protected]
escribió:

@ shin- https://github.com/shin- desafortunadamente 0.12.1 no solucionó esto
para mi.

$ docker -v
Docker versión 17.06.0-ce, compilación 02c1d87
$ docker-machine -v
docker-machine versión 0.12.1, compilación c8b17e8

Estoy creando una máquina amazonec2 con --amazonec2-region = eu-central-1
que crea un ami-fe408091 para mí.

El resultado de la creación de la máquina acoplable es:

Ejecutando comprobaciones de creación previa ...
Creando máquina ...
(test-dm) Lanzando instancia ...
Esperando a que la máquina esté funcionando, esto puede tardar unos minutos ...
Detectando el sistema operativo de la instancia creada ...
Esperando que SSH esté disponible ...
Detectando el aprovisionador ...
Aprovisionamiento con ubuntu (systemd) ...
Instalación de Docker ...
Copiando certificados al directorio de la máquina local ...
Copiando certificados a la máquina remota ...
Establecer la configuración de Docker en el demonio remoto ...
Error al crear la máquina: Error al ejecutar el aprovisionamiento: error del comando ssh:
comando: sudo systemctl -f start docker
err: estado de salida 1
salida: el trabajo para docker.service falló porque el proceso de control salió con un código de error. Consulte "systemctl status docker.service" y "journalctl -xe" para obtener más detalles.

La salida de la máquina lanzada es:

$ systemctl status docker.service
● docker.service: motor contenedor de aplicaciones Docker
Cargado: cargado (/lib/systemd/system/docker.service; habilitado; preajuste del proveedor: habilitado)
Drop-In: /etc/systemd/system/docker.service.d
└─10-máquina.conf
Activo: inactivo (muerto) (Resultado: código de salida) desde el viernes 07-07-2017 a las 13:34:47 UTC; Hace 36s
Documentos: https://docs.docker.com
Proceso: 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 = salido, estado = 1 / FALLO)

07 de julio 13:34:46 test-dm systemd [1]: docker.service: La unidad entró en estado fallido.
07 de julio 13:34:46 test-dm systemd [1]: docker.service: Error con el resultado 'código de salida'.
07 de julio 13:34:47 test-dm systemd [1]: docker.service: Tiempo de espera del servicio terminado, programación de reinicio.
07 de julio 13:34:47 test-dm systemd [1]: Detenido el motor contenedor de la aplicación Docker.
07 de julio 13:34:47 test-dm systemd [1]: docker.service: Solicitud de inicio repetida demasiado rápido.
07 de julio 13:34:47 test-dm systemd [1]: No se pudo iniciar el motor contenedor de la aplicación Docker.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/docker/machine/issues/4156#issuecomment-313683311 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AANWZXHODzL3Lumb5NqlmXwnSi3VZBBkks5sLjUlgaJpZM4OIt7R
.

@dminkovsky Gracias por la solución. Decidí usar overlay2 ya que es la última versión del controlador.

¿Sabe si también hay una solución para docker-machine rm {instance-name} ? Recibo un error relacionado con EOF y deja restos de pares de claves en la nube de AWS que me impiden recrear la instancia.

Lo siento, eliminé mi mensaje después de depurarlo y noté que en realidad se debe a lo que escribió

Sin --engine-storage-driver=overlay todavía falla con
dockerd[6407]: Error starting daemon: error initializing graphdriver: driver not supported
como antes y como en # 3895

¿Tenemos algún problema para este caso particular de uso de almacenamiento de motor AUFS?

@cadavre

¿Tenemos algún problema para este caso particular de uso de almacenamiento de motor AUFS?

He visto https://github.com/docker/machine/issues/3895 , que está abierto y al que también hizo referencia.

Curiosamente, ya no veo este error. Obtengo --storage-driver overlay

@drujensen

Decidí usar overlay2 ya que es la última versión del controlador.

Oh genial, gracias, no lo sabía.

¿Sabe si también hay una solución para docker-machine rm {nombre-instancia}?

No estoy seguro, no he tenido ese error. Utilizo docker-machine rm -f cuando la máquina se ha cerrado y no responde. Con -f , docker-machine rm elimina la máquina virtual y los discos asociados incluso si no pueden alcanzar la caja.

@dminkovsky ¿Puedes crear una nueva edición para esto? No está relacionado con el problema dockerd / docker daemon , por lo que también deberíamos tratarlo por separado. Y por favor indique también qué sistema operativo está aprovisionando :)

@ shin- estoy bien. docker-machine está funcionando al 100% en este momento para mí. ¿te refieres a la cosa overlay2?

Mi otro problema relacionado con la eliminación de máquinas se abordó en pr # 4187. Gracias.

@dminkovsky Lo siento, sí, el que mencionas aquí

@shin : después de experimentar el problema en https://github.com/docker/machine/issues/4168 , intenté volver a crear mi servidor de ensayo y encontré una serie de problemas con docker-machine create que se han informado en múltiples tickets recientes:

• https://github.com/docker/machine/issues/4156
• https://github.com/docker/machine/issues/4166
• https://github.com/docker/machine/issues/4189
• https://github.com/docker/machine/issues/4197
• https://github.com/docker/machine/issues/4198

¿Están todos relacionados? ¿Empezar a rastrearlos aquí? Puedo confirmar que este problema sigue ocurriendo hoy.

@ shin- docker-machine v0.12.1 todavía presenta el mismo problema

Sigo teniendo el mismo problema con la versión 0.12.1.

Actualice a la última versión que se encuentra en github:
https://github.com/docker/machine/releases/tag/v0.12.2

@eamontaaffe @ajwah @costa

Gracias @dminkovsky ¡ También recibí este error en 0.12.2 hoy !!! Parece que el archivo 10-machine.conf no se anula durante la actualización

¡De nada!

Especifico "superposición" en la opción de línea de comando para el motor de almacenamiento y desde
el arranque de mis máquinas.

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

Gracias @dminkovsky https://github.com/dminkovsky Estaba recibiendo esto
error en 0.12.2 hoy también !!! Parece que el archivo 10-machine.conf no
se anula durante la actualización

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/docker/machine/issues/4156#issuecomment-319719085 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AANWZSYqy1uGhWeXozx35OnFhPRSb144ks5sUJ5YgaJpZM4OIt7R
.

Si usa sistemas con kernel> 4.4, sugiero usar overlay2 .

No pude hacer que la máquina usara overlay2, y el caso de uso para esto
afortunadamente estaba construyendo / CD

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

Si usa sistemas con kernel> 4.4, sugiero usar overlay2.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/docker/machine/issues/4156#issuecomment-319727847 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AANWZXLGHjLvfOOAgmBWV0zOEBDZBdSVks5sUKWBgaJpZM4OIt7R
.

También obteniendo este error en 0.12.2 :-(

esto todavía está abierto!

Sigo viendo este problema con docker-machine 0.12.2 . Seguí adelante desinstalando Docker en la máquina aprovisionada ( sudo apt purge docker-ce && sudo apt autoremove ) y usé el script de instalación Rancher correcto para mi versión como se indica arriba.

Por alguna razón, esto aún no inicia la ventana acoplable, pero reiniciar la máquina luego lo resuelve.

Puede confirmar, sigue siendo el mismo error

@jhartma Supongo que es necesario actualizar a la última versión (imagen de Linux) y funciona

@kassanmoor parece que mi AMI no lo admite en AWS, lo hice funcionar con el predeterminado