Machine: 【Resuelto】 ¿Cómo puede docker-machine agregar un host de docker existente?

¿El soporte de la máquina acoplable agrega un host acoplable existente?

Mientras buscaba los documentos durante las últimas 5 horas, de hecho, hay la opción "--driver = none" (sin documentar). Consulte https://github.com/docker/machine/issues/2270 .

@ tdy218 @atemerev Según recuerdo, las opciones --driver none fueron enterradas intencionalmente (y pensé que se eliminaron del ejecutable publicado) porque solo se usan con fines de prueba.

Problema relacionado: tengo una gota en el océano digital creada con docker-machine. ¿Cómo puedo administrar una instancia desde otra computadora portátil?

Un colega recreó los certificados desde su computadora portátil usando docker-machine regenerate-certs [name] . y ahora ya no puedo acceder a mi instancia. ¿Debo copiar los nuevos certificados en algún lugar manualmente? La documentación sobre esto es realmente confusa.

$ docker-machine ls
NAME           ACTIVE   DRIVER         STATE     URL                        SWARM   DOCKER    ERRORS
default        -        virtualbox     Stopped                                      Unknown   
gapp-sandbox   *        digitalocean   Running   tcp://xx.xxx.xxx.xx:2376           Unknown   Unable to query docker version: Get https://xx.xxx.xxx.xx:2376/v1.15/version: x509: certificate signed by unknown authority

Encontré una solución alternativa: https://github.com/docker/machine/issues/2270

Edite el config.json de la máquina para que apunte a la CA y las claves de cliente para esa máquina específica en lugar de las de la máquina global.

Así que copié todos los archivos de la carpeta de mi colega y reemplacé todas las rutas por las de mi máquina. En mi caso, la ruta final es /Users/mturatti/.docker/machine/machines/gapp-sandbox/ .
Solución desagradable, pero parece funcionar.

ca.pem
cert.pem
config.json
id_rsa
id_rsa.pub
key.pem
server-key.pem
server.pem

@dweomer ¿No es un caso de uso básico y muy común agregar una máquina acoplable existente desde otra computadora?

@dweomer ¿No es un caso de uso básico y muy común agregar una máquina acoplable existente desde otra computadora?

@atemerev : No, no creo que lo sea. Según tengo entendido, Docker Machine existe para crear / aprovisionar hosts que estén habilitados para Docker.

Dicho esto, existe el controlador generic algo menos que obvio que creo que @ tdy218 debería usar. El controlador generic se hará cargo de un host y lo reaprovisionará. Todo lo que requiere es un host en ejecución con un demonio ssh y un usuario en ese host con acceso sudo sin contraseña (o simplemente root). Este reaprovisionamiento no es destructivo en el sentido de que, como máximo, se actualizará una instalación de Docker existente.

@dweomer
Intenté usar un controlador genérico para agregar un host docker existente en las siguientes pruebas.
Nombre del host local (mi computadora portátil): Chris-Laptop
docker-machine ya está instalado, versión 0.6.0, compilación e27fb87, Mac OS X 10.11
Nombre del host remoto (Mi VPS): li845-130 (139.162.3.130)
docker-engine ya está instalado, CentOS 7.0

1.Proceso del demonio de Docker en host remoto
[ root @ li845-130 ~] # ps -ef | grep docker |
root 12093 1 0 02:09? 00:00:00 / usr / bin / docker daemon -H tcp: //0.0.0.0 : 2376

2.Configurar la conexión ssh sin contraseña
[ tdy218 @ Chris-Laptop ~] $ ssh [email protected]
Último inicio de sesión: lun 28 de marzo de 03:06:07 de 2016 de 111.193.199.188

3.Añadir host de Docker remoto a máquinas Docker locales
[ tdy218 @ Chris-Laptop ~] $ docker-machine -D create --driver generic --generic-ip-address 139.162.3.130 --generic-ssh-user root linodevps
Versión de la máquina Docker: 0.6.0, compilación e27fb87
Se encontró una ruta binaria en / usr / local / bin / docker-machine
Lanzamiento del servidor de complementos para controlador genérico
Servidor de complementos escuchando en la dirección 127.0.0.1:50319
() Llamando a .GetVersion
Usando API Versión 1
() Llamando a .SetConfigRaw
() Llamando a .GetMachineName
(búsqueda de bandera) Llamando a .GetMachineName
(flag-lookup) Llamando a .DriverName
(búsqueda de bandera) Llamando a .GetCreateFlags
Se encontró una ruta binaria en / usr / local / bin / docker-machine
Lanzamiento del servidor de complementos para controlador genérico
Servidor de complementos escuchando en la dirección 127.0.0.1:50323
() Llamando a .GetVersion
Usando API Versión 1
() Llamando a .SetConfigRaw
() Llamando a .GetMachineName
(linodevps) Llamando a .GetMachineName
(linodevps) Llamando a .DriverName
(linodevps) Llamando a .GetCreateFlags
(linodevps) Llamando a .SetConfigFromFlags
Ejecutando comprobaciones de creación previa ...
(linodevps) Llamando a .PreCreateCheck
(linodevps) Llamando a .GetConfigRaw
Creando máquina ...
(linodevps) Llamando .Create
(linodevps) Llamando a .GetConfigRaw
(linodevps) No se ha especificado ninguna clave SSH. La conexión a esta máquina ahora y en el futuro requerirá que el agente ssh contenga la clave adecuada.
(linodevps) DBG | IP: 139.162.3.130
(linodevps) Llamando a .DriverName
(linodevps) Llamando a .DriverName
Esperando a que la máquina esté funcionando, esto puede tardar unos minutos ...
(linodevps) Llamando a .GetState
Detectando el sistema operativo de la instancia creada ...
Esperando que SSH esté disponible ...
Llegar a la función WaitForSSH ...
(linodevps) Llamando a .GetSSHHostname
(linodevps) Llamando a .GetSSHPort
(linodevps) Llamando a .GetSSHKeyPath
(linodevps) Llamando a .GetSSHUsername
Usando el tipo de cliente SSH: externo
{[-o BatchMode = sí -o PasswordAuthentication = no -o StrictHostKeyChecking = no -o UserKnownHostsFile = / dev / null -o LogLevel = silencioso -o ConnectionAttempts = 3 -o ConnectTimeout = 10 -o ControlMaster = no -o ControlPath = ninguno [email protected] -p 22] / usr / bin / ssh}
A punto de ejecutar el comando SSH:
salir 0
SSH cmd err, salida::
Detectando el aprovisionador ...
(linodevps) Llamando a .GetSSHHostname
(linodevps) Llamando a .GetSSHPort
(linodevps) Llamando a .GetSSHKeyPath
(linodevps) Llamando a .GetSSHUsername
Usando el tipo de cliente SSH: externo
{[-o BatchMode = sí -o PasswordAuthentication = no -o StrictHostKeyChecking = no -o UserKnownHostsFile = / dev / null -o LogLevel = silencioso -o ConnectionAttempts = 3 -o ConnectTimeout = 10 -o ControlMaster = no -o ControlPath = ninguno [email protected] -p 22] / usr / bin / ssh}
A punto de ejecutar el comando SSH:
cat / etc / os-release
SSH cmd err, salida:: NAME = "CentOS Linux"
VERSION = "7 (Core)"
ID = "centos"
ID_LIKE = "rhel fedora"
VERSION_ID = "7"
PRETTY_NAME = "CentOS Linux 7 (Core)"
ANSI_COLOR = "0; 31"
CPE_NAME = "cpe: / o: centos: centos : 7"
HOME_URL = " https://www.centos.org/ "
BUG_REPORT_URL = " https://bugs.centos.org/ "

CENTOS_MANTISBT_PROJECT = "CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION = "7"
REDHAT_SUPPORT_PRODUCT = "centos"
REDHAT_SUPPORT_PRODUCT_VERSION = "7"

No se pudo establecer la clave CPE_NAME, no se encontró el campo de estructura correspondiente
No se pudo establecer la clave, no se encontró el campo de estructura correspondiente
No se pudo establecer la clave CENTOS_MANTISBT_PROJECT, no se encontró el campo de estructura correspondiente
No se pudo establecer la clave CENTOS_MANTISBT_PROJECT_VERSION, no se encontró el campo de estructura correspondiente
No se pudo establecer la clave REDHAT_SUPPORT_PRODUCT, no se encontró el campo de estructura correspondiente
No se pudo establecer la clave REDHAT_SUPPORT_PRODUCT_VERSION, no se encontró el campo de estructura correspondiente
No se pudo establecer la clave, no se encontró el campo de estructura correspondiente
host compatible encontrado: centos
Aprovisionamiento con centos ...
No se ha especificado ningún controlador almacenado mediante devicemapper

(linodevps) Llamando a .GetMachineName
(linodevps) Llamando a .GetSSHHostname
(linodevps) Llamando a .GetSSHPort
(linodevps) Llamando a .GetSSHKeyPath
(linodevps) Llamando a .GetSSHUsername
Usando el tipo de cliente SSH: externo
{[-o BatchMode = sí -o PasswordAuthentication = no -o StrictHostKeyChecking = no -o UserKnownHostsFile = / dev / null -o LogLevel = silencioso -o ConnectionAttempts = 3 -o ConnectTimeout = 10 -o ControlMaster = no -o ControlPath = ninguno [email protected] -p 22] / usr / bin / ssh}

4.La línea de comando del host de la ventana acoplable remota.
[ root @ linodevps ~] # ps -ef | grep docker |
root 17079 1 0 03:06? 00:00:00 / usr / bin / docker daemon -H tcp: //0.0.0.0 : 2376
root 17185 1 0 03:06? 00:00:00 sudo docker versión
root 17190 17185 0 03:06? 00:00:00 versión docker

El proceso del demonio de la ventana acoplable se reinició, pero había dos procesos de versión de la ventana acoplable más, luego intenté ejecutar el comando de la versión de la ventana acoplable manualmente, se colgó.

Es tan difícil agregar un host de docker existente a la línea de comando de la máquina docker ...

Si el host remoto no tiene ningún motor de la ventana acoplable, es fácil crear un host de la ventana acoplable (instalar el motor de la ventana acoplable) desde la línea de comandos de la máquina acoplable, pero como el problema anterior, la máquina acoplable es limitada.

@dweomer Esto es cierto, pero si aprovisioné docker-machine o docker-swarm, ¿cómo puedo, digamos, permitir que otro desarrollador implemente contenedores allí? ¿Cómo transfiero las variables de configuración / env entre máquinas? Hasta ahora, solo puedo usar hosts de máquina acoplable aprovisionados yo mismo, y solo desde una sola máquina (¿y si está roto? ¿Cómo restauro la configuración en otra?).

Para mí, docker-machine / docker-swarm están muy lejos de estar listos para producción, y deberían marcarse como beta al menos. O me gustaría escuchar a alguien que realmente lo use en producción ...

FWIW, si simplemente suelta ~ / .docker desde el host de la estación de trabajo al nuevo (suponiendo que el directorio de inicio es la misma ruta), funcionará. Si el directorio de inicio difiere, deberá editar los archivos .json en varios lugares (claves y certificados, etc.) para cambiar, por ejemplo, /Users/macuser/.docker a /home/linuxuser/.docker .

Parece que esta pregunta se ha abordado a fondo y / o cubre un terreno ya establecido en otros temas. Gracias a todos.

@nathanleclaire Para ser claros, ¿el enfoque oficial para agregar hosts de docker existentes (ya sean creados por docker-machine o de otro modo) es copiar la carpeta ~ / .docker entre las máquinas cliente? Si es así, ¿hay algún subconjunto particular de los archivos / un archivo que necesitemos copiar?

Si, en cambio, el enfoque oficial es utilizar el controlador genérico, sería útil abordar el problema de @ tdy218 descrito en el comentario aquí .

No creo que se haya abordado esta cuestión en absoluto. Estoy tratando de enviar el código a una nueva máquina y la mejor respuesta que cualquiera puede dar es encontrar al tipo que hizo la máquina y copiar sus archivos en los míos.

No estoy seguro de si alguien ha probado esto aquí en el mundo real, pero apesta.

@TheSeanBrady Mantengamos la discusión sobre temas civiles. Si tiene propuestas de soluciones que le gustaría ver, compártalas. Sigamos enfocados en las soluciones sobre los problemas.

Sólo estoy siendo honesto. Intenta enviar correos electrónicos solicitando archivos, porque hasta ahora no me está funcionando. Esto se cerró sin abordar el problema.

Sólo estoy siendo honesto. Intenta enviar correos electrónicos solicitando archivos, porque hasta ahora no me está funcionando. Esto se cerró sin abordar el problema.

¿No sientes que decir algo "apesta" e implicar que el resto de nosotros no vivimos "en el mundo real" es innecesariamente duro y no constructivo?

Intentamos fomentar una comunidad donde se fomenta la colaboración y la positividad. Le pido que si quiere participar, siga estos principios también.

Debido al uso de credenciales de API almacenadas, claves SSH y certificados, compartir docker-machine s entre computadoras es un problema de administración de secretos / ACL en toda regla, para el cual se han inventado otras clases de tecnología. Es un problema bastante grande de alcance. Se pueden tomar medidas para mitigarlo que ayuden a su caso de uso, así que ¿por qué no sugerir algunas soluciones proactivas para implementar?

Si desea enviar una propuesta para solucionar este problema, no dude en hacerlo. Si también desea hacer una propuesta respaldada por código en una solicitud de extracción, también lo animo a que lo haga. Pero en cualquier caso, centre la discusión en soluciones y mantenga una actitud positiva.

¿No sientes que decir algo "apesta" e implicar que el resto de nosotros no vivimos "en el mundo real" es innecesariamente duro y no constructivo?

Realmente no cuando está haciendo seguimiento ...

Parece que esta pregunta se ha abordado a fondo y / o cubre un terreno ya establecido en otros temas. Gracias a todos.

Eso es más o menos lo que yo llamo un despido sumario. Y por "mundo real", me refiero al entorno donde usamos estas cosas, no donde puedes pasar a uno de los desarrolladores en el pasillo.

Esta habría sido una respuesta más apropiada ...

Debido al uso de credenciales de API almacenadas, claves SSH y certificados que comparten máquinas acoplables entre computadoras, es un problema de administración de secretos / ACL en toda regla, para el cual se han inventado otras clases de tecnología.

... a pesar de que esas tecnologías se han inventado y la mayoría son de código abierto.

Sin embargo, ya que preguntaste, ¿qué tal un docker-machine add <hostname> , usando la autenticación de clave SSH para pasar los certificados requeridos para la conexión TLS?

¿qué pasa con una máquina acoplable?, utilizando la autenticación de clave SSH para pasar los certificados requeridos para la conexión TLS?

Eso podría resolver el problema ... para entornos de desarrollo al menos

Otra opción es usar un conector de ventana acoplable en un host disponible a través de SSH, lo cual es muy preferible para mí, ya que usa el mecanismo de autenticación SSH existente (que en mi caso está respaldado con HSM) y no requiere ajustar puertos / firewalls para soporte TLS.

He pirateado mi propia solución para esto usando socat, pero sería muy bueno si docker-machine pudiera admitirlo. No es difícil usar ssh en un host, instalar socat si aún no está instalado y usar socat para convertir la sesión ssh en un socket local para comunicarse con el /var/lib/docker.sock remoto. También significa que docker-machine no tendría que saber nada sobre autenticación o certificados o TLS en este modo de controlador, aunque depende de socat localmente para crear el socket local ...

Sería bueno ver un modo de controlador que hace este tipo de configuración de socket local de la misma manera que el controlador ssh existente configura todas las cosas de TLS. Muchas organizaciones ya han resuelto la distribución de claves SSH / reenvío de puertos, y esperar que ahora distribuyan / administren una PKI para TLS (y abran otro puerto) es una carga.

tyrell:~▻ cat Library/Local/bin/ber1docker 
#!/bin/bash

DOCKER_REMOTE_HOST="ber1.local"
DOCKER_SOCK="$TMPDIR/docker.sock"
export DOCKER_HOST="unix://$DOCKER_SOCK"
rm $DOCKER_SOCK

socat UNIX-LISTEN:$DOCKER_SOCK,reuseaddr,fork \
   EXEC:"ssh root@$DOCKER_REMOTE_HOST 'socat STDIO UNIX-CONNECT:/var/run/docker.sock'" &

Entonces, ¿no "docker-machine add ..."?

+1 por docker-machine add ...

Queremos tener la belleza de eval $(docker-machine env mymachine) para todos los miembros de nuestro equipo (para entornos de desarrollo compartidos, por supuesto).

Hice girar una gota con el controlador digitalocean y puse un sitio en funcionamiento usando docker-compose desde mi estación de trabajo.

Luego tuve que trabajar en el sitio pero desde una ubicación completamente diferente, lejos de mi estación de trabajo donde hice los comandos originales de la máquina acoplable.

¿No es esta una situación bastante común?

Es una solución muy común. Especialmente si trabajas en algo llamado "equipo". Pero evitan este tema desde hace unos 18 meses. Todo lo que hacen es cerrar problemas como este y luego decir algo como "es muy complicado implementar tal característica" y que puede hacerlo usted mismo y proponer una solicitud de extracción en cualquier momento.
Me parece que ni siquiera han comenzado a trabajar en una solución en los últimos 18 meses.

Gracias por su respuesta, aunque todavía no es una forma fácil de darse cuenta.

Mantenga las credenciales y todo eso en la nube.

Dame instrucciones sobre cómo usar mi Dropbox o Google Drive para almacenarlo.

Permítanme consultar la información de digitalocean, ya que ese es el controlador que estaba usando.

Esto realmente no puede ser tan difícil.

Sí, eso suena seguro.
El miércoles 9 de noviembre de 2016 a las 09:28 Michael Schwartz [email protected]
escribió:

Mantenga las credenciales y todo eso en la nube.

Dame instrucciones sobre cómo usar mi Dropbox o Google Drive para almacenarlo.

Esto realmente no puede ser tan difícil.

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

No menos seguro que enviar los comandos y todo mi código a través de Internet para hacer en primer lugar.

O cargar todas mis cosas patentadas en Docker Hub o Github, incluso en un repositorio privado.

Para aquellos que intentan agregar una máquina acoplable al entorno de desarrollo, pueden hacer lo siguiente:

docker-machine create -d "none" --url http://192.168.10.100 : 4243 bla

esto es si tiene la autenticación HTTP y no TSL habilitada en el host.

Pasé mucho tiempo buscando estas cosas indocumentadas

Creo que parece un poco miope permitir que solo una máquina administre también un clúster de Docker. Más que simplemente compartir la responsabilidad de administrar el clúster con su equipo, ¿qué tal tener más de un punto de falla o permitir que múltiples agentes automatizados puedan interactuar con el clúster de Docker?

+1 para el comando de exportación.

Podría exportar todas las configuraciones y certificados a un archivo tar o zip seguro que se puede importar con una contraseña.

Parece una solicitud razonable.

@bmmathe Ese comando ya es tar -c ~/.docker/machine | bzip2 > docker-machine-config.tbz2 .

Así es como lxd se ocupa de esto. Quizás se podría configurar una contraseña o clave en la máquina que le permitiría copiar o regenerar certificados.

Eso es tan triste 😖. Mis máquinas remotas ahora muestran localmente el estado timeout al ejecutar docker-machine ls , algo estropeó las configuraciones de la máquina. Parece que no puedo averiguar cómo reconfigurarlos / arreglarlos en la carpeta local de máquinas Docker. ¿No más aprovisionamiento local? ¿Debo eliminar las VM y volver a crearlas?

Votar por una opción para agregar máquinas remotas a las máquinas Docker locales:

docker-machine agregar--conductor

⏳🤒

Esta es una característica realmente importante. No entiendo por qué es tan difícil. Incluso, si necesito regenerar los certificados no será un problema para mí, pero me gustaría tener esto documentado y un comando con el que trabajar.

Si puedo recordar correctamente, mi problema se debió a que tenía permisos incorrectos y / o un nombre de usuario local que no coincide con el remoto (el usuario predeterminado es docker-user ). Probablemente sea un problema en su nombre, necesita profundizar más.
El controlador genérico para el comando docker-machine funciona bien para diferentes proveedores, por ejemplo, google.

Marque estos:
• https://github.com/docker/machine/issues/3522#issuecomment -280275707
• https://docs.docker.com/machine/drivers/generic/
• No puedo encontrar las otras conversaciones que tuve sobre este tema que me llevaron a la solución.

Hoy, encontré la causa de agregar una falla de host de docker remoto en mi caso.
[ root @ linodevps ~] # ps -ef | grep docker | grep -v grep
root 17079 1 0 03:06? 00:00:00 / usr / bin / docker daemon -H tcp: //0.0.0.0 : 2376 // Este estilo de escritura no permite la comunicación local fd o unix socket entre el cliente y el servidor de docker, por lo que se cuelga en sudo docker comando version cuando se ejecuta el docker-machine add.

Para corregirlo, solo necesita editar el archivo de configuración del servicio de docker (el predeterminado es /usr/lib/systemd/system/docker.service), cambie el valor del parámetro ExecStart de / usr / bin / docker daemon -H tcp: // 0.0.0.0 : 2376 a / usr / bin / docker daemon -H tcp: //0.0.0.0 : 2376 -H unix: ///var/run/docker.sock (el predeterminado es / usr / bin / docker daemon -H fd: //) o / usr / bin / docker daemon -H tcp: //0.0.0.0 : 2376 -H fd: // o exportar DOCKER_HOST = tcp: //0.0.0.0 : 2376,
y luego sudo systemctl daemon-reload && sudo systemctl restart docker, vuelva a ejecutar el comando docker-machine add, espere un momento, se agregará correctamente. En el proceso de adición, la máquina docker generará certificados ssl para el host de la ventana acoplable de destino y generará un nuevo archivo de configuración del servicio de la ventana acoplable 10-machine.conf en un nuevo directorio que se llama /etc/systemd/system/docker.service.d

tdy218 @ Chris-Laptop $ dm ls
NOMBRE CONDUCTOR ACTIVO ESTADO URL ERRORES DE SWARM DOCKER
docker-vm119 - genérico en ejecución tcp: //192.168.135.119 : 2376 v17.03.1-ce
docker-vm120 - genérico detenido desconocido

docker-vm119 es el host de docker existente antes de agregar.

A partir de este caso, sabemos que docker-machine admite la adición de un host de docker existente, gracias @Bean Young

docker-machine create --driver none -url=tcp://123.123.123.123:2376 dockerhost1 es lo mejor que he aprendido sobre Docker en mucho tiempo.

Realmente debería ser más fácil compartir una máquina de desarrollo entre usuarios.

// cc @nathanleclaire

actualización: para ser claros: específicamente, no me importa compartir previamente los certificados con otros miembros del equipo. Allí también hay margen de mejora.

@dhrp ¿qué proceso sigue para

Oh mi querido señor, no puedo creer en el pasado más de un año y medio nadie quiere disparar este problema 😞 😞 😞

@thaJeztah @AkihiroSuda @albers @tianon ¿De verdad crees que este no es un requisito muy común y crítico?

Traté de reaprovisionar un host de la ventana acoplable existente ( docker-machine create --driver=generic --generic-ip-address <ip> <name> y parecía funcionar sin invalidar los certificados existentes. Esto se hizo desde la misma máquina que originalmente aprovisionó el host de la ventana acoplable ... ¿es este un resultado esperado?

¿Puede reabrir este problema? No creo que esto esté resuelto todavía.

Tropecé con esto por accidente.

Bueno, @nathanleclaire dejó en claro el punto: este NO es el punto de agregar una función docker-machine, sino más bien el punto de compartir claves que NO se supone que se almacenen en ningún otro lugar que no sea la máquina cliente original. Así es exactamente como se supone que debe hacerse y algunas personas aquí se están enojando sin pensar lo suficiente en el tema.

Si realmente desea compartir las claves con un equipo, simplemente continúe con cualquier repositorio privado de control de fuente y acepte los riesgos que está tomando. Para exportar las claves necesarias, hay un script que alguien ya hizo: https://gist.github.com/schickling/2c48da462a7def0a577e

"No hay razón para que no podamos ser civiles" - Leonidas

Sigo pensando que docker-machine debería comportarse más como scp. ¿Qué impide agregar soporte para múltiples claves?

Una solución a esto, que acabo de encontrar.
Si tiene una máquina acoplable existente en la misma plataforma (la mía es google) y puede usar ssh / scp en esa máquina sin requerir una máquina acoplable, puede copiar la otra máquina y hacer que funcione.
Yo hice:

mkdir ~/.docker/machine/machines/new-machine
cp -r ~/.docker/machine/machines/old-machine/* ~/.docker/machine/machines/new-machine/

#then replace all instances of "old-machine" with "new-machine" in ~/.docker/machine/machines/new-machine/config.json

#then add the public key from your new-machine folder into the authorized_keys file for the docker-user on the new machine, e.g.
scp ~/.docker/machine/machines/new-machine/id_rsa.pub docker-user<strong i="8">@new_machine</strong>:/home/docker-user
ssh docker-user<strong i="9">@new_machine</strong> -c "cat ~/id_rsa.pub >>~/.ssh/authorized_keys"

(No copie los comandos ssh textualmente, busque cómo hacerlo correctamente: https://encrypted.google.com/search?hl=en&q=ssh%20copy%20public%20key)

+1 para el comando de exportación / importación.
+1 para compatibilidad con varias teclas.

No poder mover las estaciones de trabajo de administración es simplemente inaceptable y crea un punto único masivo de falla.

Por ejemplo, pérdida de computadora, robo, incendio, falla de hardware, falla de software, problemas de acceso al equipo, problemas de administración, etc.

Docker-machine no se concibió con eso en mente: esta es una herramienta de comida rápida para el aprovisionamiento de un solo desarrollador. Esto es todo, simple y llanamente, y funciona, ¡y es gratis!

Algunas características mencionadas aquí se implementan en la oferta de Docker EE (como equipos y RBAC).

Si la gente no puede estar agradecida, intente al menos ser razonable.

No creo que se haya mencionado el uso

machine-export <machine-name>
>> exported to <machine-name>.zip
machine-import <machine-name>.zip
>> imported

Hola @andrevtg

Perdón si parecía ingrato. Realmente amo la máquina acoplable y pensé que esto la haría aún mejor.
Creo que la capacidad de los desarrolladores individuales para moverse fácilmente entre computadoras sería realmente útil.

Si mi agenda se libera, podría intentar aprender GO e intentar agregar esta función.

Hola @ dmitrym0

Creo que este ticket se centró más en la falta de capacidad para conectarse a los hosts de Docker remotos existentes.
Dicho esto, el uso compartido de máquinas parece útil cuando se mueven los hosts de la ventana acoplable local.
Gracias por la sugerencia.

@ Jared-Harrington-Gibbs machine-share resuelve específicamente el problema de "_añadir hosts de máquina acoplable existentes_". Implementamos varias aplicaciones a través de docker-compose y nos funciona bien. Exportamos el conjunto de certificados con machine-share y lo distribuimos a todos los miembros del equipo que lo necesiten. No es ideal pero funciona bien.

Intenté usar un controlador genérico para agregar un host de docker existente, se agregará correctamente después de varios reintentos.

@sneak Esta solución no parece funcionar para mí, ya que las rutas en config.json no apuntarán a los archivos correctos. Asumiría que docker-machine basa en el archivo config.json , pero podría estar equivocado, aún no lo he probado.

Esto presenta un problema para mí, porque tal vez estoy ejecutando desde un entorno en el que quizás no sepa la ruta exacta en la que se almacenan los archivos. ¿Quizás podría haber una opción para una ruta relativa?

Si el problema es la mano de obra, podría dedicar unos días a intentar dar una solución a la comunidad. Sin embargo, preferiría tener alguna dirección de los mantenedores. ¿ [Resolved] en este caso indica una decisión de no admitir esta función de forma nativa, o ya se admite en algún lugar que no veo?

Esta es una característica que NO ESTÁ DISEÑADA para ser implementada en absoluto. No tiene sentido esperar que la máquina remota almacene las claves privadas que se supone que no existen en ningún lugar excepto en la máquina del desarrollador original.

Incluso Docker EE se asegura de que se genere un "paquete de cliente" diferente cada vez que se solicita, y no los almacena en el host.

La gente aquí está pidiendo una función que sea simple de implementar, pero que no tiene ningún sentido implementar debido a una restricción de seguridad razonable.

@andrevtg La solicitud no es para que la máquina virtual almacene las claves (lo que haría que las claves fueran completamente inútiles), sino para el cliente de la máquina acoplable (que está hecho de código, es una aplicación real), para proporcionar una forma para los usuarios transmitir voluntariamente claves de un cliente a otro.

Una forma sencilla de hacer esto podría ser proporcionar un comando docker-machine export que agrupe las claves en un archivo, y un comando docker-machine import para que un destinatario de este archivo importe las máquinas descritas en el archivo. El cifrado / descifrado en los límites de transmisión de las claves es entonces asunto de los usuarios (pueden usar correo electrónico PGP, SFTP, lo que quieran).

Exactamente docker-machine create crea un archivo de configuración enorme y claves que los principiantes no entienden o saben cómo replicar. Quizás crear una clave ssh sea tan simple como agregar una clave al archivo de hosts, pero eso no está documentado. ¿A qué contenedor lo agregamos? ¿Y cómo lo configuramos en una máquina diferente y notificamos a docker-machine respecto? ¿Podemos seguir usando docker-machine use o tenemos que configurar manualmente todas las variables ambientales?

Idealmente, debería haber un docker-machine add [name] para agregar una clave, docker-machine export para exportar los archivos de configuración y docker-machine import para importar esos archivos de configuración en otra máquina. También sería bueno tener docker-machine rm [name] para revocar el acceso a las claves.

@dhrp Tengo un servidor acoplable ejecutándose en un rpi. Me gustaría acceder a él desde mi localhost con la máquina acoplable. Entonces todo lo que tendría que hacer es:
docker-machine create --driver none -url=tcp://raspberry.local:22 rpihost
¿Esto funciona?

Entonces @ 360disrupt , ¿verdad? Lucho con el mismo caso de uso.

Entonces @ 360disrupt , ¿verdad? Lucho con el mismo caso de uso.

No aún no.

Hola a todos. ¿Esto aún no se resolvió? Usamos Docker para todas las aplicaciones de la empresa para la que trabajo. Nuestro mayor problema está relacionado con compartir las máquinas. Intenté usar el controlador genérico varias veces, pero el problema con ese enfoque es que cuando crea una máquina con el controlador genérico y la conecta con un servidor existente, la creación simplemente elimina los contenedores que se están ejecutando actualmente en el servidor.

La única forma que hemos encontrado fue crear un script simple en Python que solo importe y exporte la máquina a la que el desarrollador desea acceder. Este script es responsable de copiar todos los archivos de configuración y los certificados del propietario de la máquina a la nueva fuente. Funciona bien y no tenemos ningún problema con eso, es solo que no puedo creer que no haya una forma oficial de compartir máquinas sin tener que compartir nuestros certificados privados.

Estoy trabajando en un proyecto y lo publicaré en GitHub para solucionar este problema de otra forma. Básicamente, solo estoy construyendo una PaaS que concentrará todos los certificados de todas las máquinas que tenemos aquí en nuestra empresa. Y cuando alguien quiere implementar o hacer algo así, solo necesita conectarse con PaaS, y no con el servidor. Es como un tunel. Pronto lanzaré la primera versión de esta PaaS.

+1 por docker-machine add o docker-machine create --existing

esto resolvió mi problema: machine-share : computer:: rabbit2:

@dweomer ¿No es un caso de uso básico y muy común agregar una máquina acoplable existente desde otra computadora?

@atemerev : No, no creo que lo sea. Según tengo entendido, Docker Machine existe para crear / aprovisionar hosts que estén habilitados para Docker.

Dicho esto, existe el controlador generic algo menos que obvio que creo que @ tdy218 debería usar. El controlador generic se hará cargo de un host y lo reaprovisionará. Todo lo que requiere es un host en ejecución con un demonio ssh y un usuario en ese host con acceso sudo sin contraseña (o simplemente root). Este reaprovisionamiento no es destructivo en el sentido de que, como máximo, se actualizará una instalación de Docker existente.

Sé que esto parece ser un problema resuelto, pero solo quería decir que estoy de acuerdo con @atemerev : como equipo de desarrollo, tenemos la necesidad de conectarnos a otras máquinas aprovisionadas casi semanalmente .

esto resolvió mi problema: machine-share 💻 🐇

Puedo confirmar que este paquete npm funciona.