Machine: Adjuntar a una máquina existente desde otro cliente

: +1:

¿Qué tal agregarlo al segundo sistema usando el controlador 'genérico' y luego usar el mismo comando eval allí?

@clnperez, ¿ es esta una propuesta o algo que está seguro de que funciona (significa que reutilizará la máquina remota existente incluso si se está ejecutando actualmente)?

Bueno, en retrospectiva, no creo que pueda hacer esto porque tendría que configurar las claves ssh nuevamente, o importarlas desde su otro sistema.

Veo tu caso. No se puede agregar una entrada de la máquina acoplable en el segundo sistema usando el controlador genérico a menos que desee invalidar la configuración original de la máquina acoplable (ya que, por ejemplo, se generan nuevos créditos). Se puede ejecutar docker-machine create -d none --url [...] en el segundo sistema reflejando opciones importantes (como las banderas de enjambre) de la creación original en el primer sistema y luego copiando manualmente los archivos .pem seleccionados y el archivo id_rsa de la primera máquina a la segunda máquina Y agregue manualmente secciones para el acceso SSH (y cambie manualmente el controlador a genérico desde ninguno). Es un PITA. Una función de exportación / importación adecuada sería buena para permitir compartir. También se pueden compartir solo los archivos de crédito necesarios para configurar manualmente la ventana acoplable.

Correcto. La única forma actual sería tomar el directorio completo, pero esto no funcionará con algunos controladores (es decir, VirtualBox porque registra VM y redes con UUID que no coincidirían). Se ha debatido sobre una función de importación / exportación en el pasado (https://github.com/docker/machine/issues/23)

Tengo una solución de relaciones públicas / hacky para esto en las alas ... En general, creo que quiero mover la configuración a ser portátil / con plantilla en lugar de codificada como están las cosas ahora.

+1

Me encantaría poder volver a conectarme rápidamente a instancias en la nube (estoy usando GCE) que ya existen.

Ciertamente, tener configuraciones importables / exportables sería muy útil, pero me pregunto si (además) abordar el problema como una preocupación del controlador podría no generar una experiencia de usuario más simple.

De esa manera, utilizando el controlador de Google, uno podría conectarse a una instancia existente en una computadora alternativa simplemente proporcionando un token de acceso válido (que el controlador puede solicitar al usuario que genere automáticamente).

De manera similar, al usar el controlador aws, por ejemplo, (lo que todavía tengo que hacer yo mismo, pero supongo), uno podría conectarse a una instancia existente proporcionando un par clave / secreto válido (tal vez a través de variables de entorno correspondientes al controlador específico relevante banderas - asumiendo que el proceso ocurrirá a través de algún subcomando de la máquina acoplable que no sea "crear", ya que las expectativas son un poco diferentes).

Solo quiero decirle que esta sería una característica realmente excelente. Realmente me gustaría poder compartir una máquina con mis compañeros de equipo y me decepcionó descubrir que básicamente no había forma de hacerlo en este momento. Sería increíble si, por ejemplo, el generic conductor puede detectar automáticamente si un cuadro particular, ya había sido dotado con docker-machine y volver a utilizar TLS CERT, etc. cuando alguien corrió docker-machine create en esa caja de nuevo.

: +1. Me encantaría verlo funcionando. Actualmente estamos coadministrando las mismas máquinas (en Google Compute Engine) con otra persona y la única forma que encontré funcionando es copiar todo el directorio (+ cambiar los enlaces absolutos en el archivo config.json). Eso es patético. Creo que el controlador genérico no se puede usar fácilmente de esta manera; existe un problema de autenticación, por supuesto (tls certs, etc.) no se puede reutilizar simplemente cuando se ejecuta --crear con un controlador genérico (de alguna manera debe autenticarse y demostrar que tener acceso a la máquina, que es diferente para cada controlador; en GCE, tendría que verificar si su autenticación de gcloud le permite acceder a la máquina). También hay un pequeño problema: a menos que ya haya creado la máquina antes con el controlador dado, falta su pieza de autenticación (la única forma de autenticarse es ... crear la máquina).

Lo que creo que es la mejor solución es tener un comando de "importación" (con una implementación diferente para diferentes controladores). Por ejemplo, en GCE, puede almacenar todos los detalles necesarios (claves, etc.) en algún lugar de los metadatos de la máquina: https://cloud.google.com/compute/docs/metadata?hl=en#project_and_instance_metadata y luego especificando el proyecto / nombre de la máquina (y la autenticación) puede obtener todas las claves necesarias y configurar la máquina.

¡Realmente agradecería esta función!

@potiuk ¿Qué directorio copias?

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

+1!

+1 También me encantaría ver una solución para esto :-)

Hoy encontré exactamente ese problema para dar acceso a un colega.

+1 !!!!!

Parece ser un duplicado del # 23, ¿verdad?
Casi 1 año desde que hablamos de esta función, algunos han intentado hacer relaciones públicas para ella, pero se cerraron ...
Espero que esta función esté en la próxima versión (principal) :)

Esto es absolutamente necesario en escenarios de entrega continua, donde desea implementar utilizando esas claves de Travis o Circle CI. ¿Alguna pista sobre ETA?

tengo que darle a esto un +1 también

+1

+1

¿Hay algo que tenga que hacer además de copiar la carpeta ~/.docker/machine/machines/<name> y cambiar las rutas absolutas? Recibo un mensaje de error relacionado con mis certificados y el intento de regenerarlos también falla.

@jbasrai ¿

Presenté https://github.com/docker/machine/issues/2516 para comenzar a considerar los pasos en la dirección correcta para facilitar esto.

Esta es una característica vital y me encantaría verla en una versión futura. En mi opinión, la configuración de la máquina debe ser exclusiva de un cliente, no ser importada / exportada. En cambio (como han mencionado otros) docker-machine create run con los mismos argumentos debería poder crear una configuración para la máquina incluso si ya existe de forma remota en lugar de fallar como lo hace ahora. Cuando vuelvo a ejecutar mi comando de creación para una máquina amazonec2 existente, aparece este error que me dice que el host ya 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.

En cambio, podría advertirme que el host ya existe y continuar agregando la máquina como lo haría en una creación inicial (tal vez requiriendo que se pase un indicador de anulación). De esa manera puedo mantener los scripts de configuración de mi entorno de desarrollo / CI simples y no preocuparme por tener que almacenar esta configuración en algún lugar donde mis compañeros de equipo (u otras partes) puedan acceder a ella.

De hecho, es sorprendente que para que varias personas trabajen en la misma máquina virtual, tengamos que exportar / importar certificados de una máquina a otra. Si alguien encontrara una solución práctica y lista para producción, sería bueno saberlo.

+1

+1

Correcto. La única forma actual sería tomar el directorio completo, pero esto no funcionará con algunos controladores (es decir, VirtualBox porque registra VM y redes con UUID que no coincidirían). Se ha debatido sobre una función de importación / exportación en el pasado (n. ° 23)

@ehazlett, así que estoy usando el controlador aws, ¿puedo:

1. comprimir la máquina en la nube ~/.docker/machine/machines/staging
2. compartir con los miembros del equipo, se descomprimirán en ~/.docker/machine/machines/
3. Tendrán una máquina de puesta en escena como yo? docker-machine ls (o necesitan hacer otro comando)

@leandromoreira una barrera para ese enfoque es que los archivos de configuración de la máquina acoplable tienen rutas codificadas específicas para la máquina host:

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"
        }

por lo que simplemente copiar todo el directorio no es una solución completa

@bhurlow muchas gracias: smile:, ¿hay alguna herramienta para ayudar con esto? ¿O debería editar el config.json manualmente por mi cuenta? ¿Es esa la única barrera?

@leandromoreira Lo he escrito de esta manera , las versiones más recientes de docker-machine ya no codifican claves en base64 en el archivo de configuración. Al final del día, cualquiera que quiera usar una máquina acoplable remota _debe_ tener los certificados TLS, por lo que creo que se requiere un intercambio entre las partes

Gracias @bhurlow

@bcwalrus hizo una gran herramienta hasta que tengamos 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 se ve muy bien, pude exportar e importar las configuraciones con éxito.

@muhammadghazali fue idea @bhurlow y esfuerzo: stuck_out_tongue:

+1 ¿Alguna actualización sobre una solución oficial para esto?

Con la versión 1.10.1 de docker, noté que el archivo config.json tiene referencias a lo siguiente del directorio ~ / 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",

También debe copiar la carpeta ~ / .docker / machine / certs de la máquina original para que este escenario funcione.

La solución actual para esto parece ser (por ejemplo, si desea crear una máquina Docker en AWS en una computadora y ver los registros o SSH en la máquina desde otra):

1. Cree un nuevo directorio my-dir y my-dir/machine para las máquinas Docker que desea compartir para que no use sus certificados predeterminados
2. Cree su máquina Docker usando la opción --storage-path my-dir/machine (asegúrese de especificar la ruta absoluta)
3. Para compartir la Máquina, edite config.json en my-dir/machine/machines/machine-name y reemplace la ruta absoluta a my-dir/machine con $MACHINE_STORAGE_PATH
4. Sube my-dir algún lugar, por ejemplo, a Github

Cuando alguien quiere importar esta máquina:

1. Clonar o descargar my-dir
2. Edite config.json para la Máquina en my-dir/machine/machines/machine-name y reemplace $MACHINE_STORAGE_PATH con la ruta absoluta a my-dir/machine en su computadora local
3. chmod 0600 el id_rsa en my-dir/machine/machines/machine-name

Ahora puede usar los comandos de Docker Machine usando la opción --storage-path my-dir/machine (asegúrese de especificar la ruta absoluta).

Esto posiblemente podría mejorarse mediante:

• Docker Machine almacena las rutas relativas en config.json, por lo que no es necesario editarlo
• Docker Machine SSH (y comandos relacionados) modificando id_rsa a 0600 automáticamente (si tienen permiso para hacerlo)

Un punto rápido, si usa envsubst entonces puede reemplazar programáticamente $ MACHINE_STORAGE_PATH y no tiene que editar manualmente. Aún así, todo el asunto es un poco inconveniente para los equipos que intentan utilizar una granja de sistemas de máquinas acoplables.

Sin embargo, si las personas buscan una solución alternativa, la más fácil que he encontrado es:

1. Copie el .docker/machine/certs en un lugar privado. Tenga en cuenta que _no_ ponga esto en un repositorio ya que tiene secretos que le dan acceso a las otras máquinas. Usamos una tienda privada para este propósito.
2. En la nueva máquina host, copie los certificados en el nuevo .docker/machine/certs
3. Ahora vuelva a ejecutar lo que crea su docker-machine y tendrá la capacidad de usar esto sin cambiar todas las configuraciones. Lleva más tiempo, pero es más portátil y no tiene que editar todos esos archivos de configuración.

Tengo dos computadoras diferentes con las que trabajo y esto es un problema real para mí.
Describo aquí el comportamiento del sueño que espero cuando uso docker-machine:

1) Cree una gota en DigitalOcean con docker-machine y el controlador DigitalOcean (con algún token que obtenga del panel de control de 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) Vaya a una computadora diferente, obtenga otro token de DigitalOcean y conéctelo a la máquina existente con un comando mágico adjunto, como este:

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

¿Cuáles son los obstáculos para que esto funcione? Creo que el token de acceso de DigitalOcean le otorga suficientes privilegios para adjuntarlo a un host existente y configurar toda la comunicación segura.

Por ahora voy a probar machine-share por @bhurlow : https://github.com/bhurlow/machine-share

+1 Bump en esto: ¿alguien tiene una actualización sobre esto?

@brandontamm : escribí algunos scripts para manejar este problema por mí mismo. No sé si resolverán el tuyo, pero al menos puedo intentarlo. Mira la esencia aquí

Un resumen de la esencia: hay dos funciones: store_machine y load_machine. store_machine almacena toda la información sobre una máquina dentro del alijo seguro (encriptado en el almacén de datos del disco). Deberá proporcionar una contraseña. La función load_machine carga una máquina desde el almacén de datos del disco.

Tenga en cuenta que este código de Python asume que tiene sstash (Python Secure Stash) instalado. Puede instalarlo ejecutando

pip install sstash

+1

En serio, de qué sirve Docker-Machine a menos que pueda acceder a él desde otro dispositivo predefinido ...

CASO DE USO: construyó la máquina acoplable en el trabajo, pero luego necesita la computadora portátil para las vacaciones en caso de que un servidor explote ...

Vamos, ¿dónde está el administrador de Docker para intervenir en esto? Ese es un caso de uso que TODOS pueden apreciar.

@realcr ¿ compartir máquina ?

Me niego a usar más dependencias :) Copiar la carpeta .docker en ambas máquinas OSX funcionó perfectamente para mí. Mis rutas y nombres de usuario eran los mismos en ambas máquinas aunque esa es la clave sin editar manualmente las rutas.

Brandon Tamm
Enviado desde el móvil

El 4 de noviembre de 2016, a las 3:36 a.m., Sébastien Boulet [email protected] escribió:

@realcr ¿

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub o silencia el hilo.

+1

+1

+1

+1

Escribí docker_machinator para intentar resolver este problema.
Esta es una herramienta de Python que le permite guardar todas las credenciales y la configuración de su máquina acoplable en un escondite encriptado que puede almacenar en su proveedor de nube, por ejemplo. Luego puede descargar esto desde otro host y volver a cargar sus máquinas desde el escondite.
Esta es una herramienta de Python, por lo que debería tener un pip install de usarla.

No creo que esta sea la solución perfecta, pero esto podría ayudarte hasta que encontremos una mejor.

Chicos, deben saber que machine-share exporta su clave ssh privada que utilizó al crear el host de la ventana acoplable a través de la máquina acoplable con un controlador genérico. Por lo tanto, todos los que envíe un archivo exportado podrán obtener acceso al servidor que ejecuta la ventana acoplable.

@mxl docker-machine proporciona un subcomando ssh que le otorgará acceso al servidor, por lo que la situación que está describiendo es inevitable si tiene una herramienta que crea una configuración completa como un archivo importable.

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

Supongo que la forma en que evitaría esto sería crear un comando que pudiera descargar la configuración actual desde la máquina remota. Dicha descarga requeriría que pudieras hacer SSH en la máquina, en lugar de empaquetar el acceso en el archivo importable.

Ser capaz de controlar únicamente la máquina acoplable desde un host es una limitación incómoda.
También me encantaría ver algo como docker-machine config-from <otherhost> .

Entonces +1 de mi parte también.

/ Editar: Actualmente estoy resolviendo el problema sincronizando .docker de un "servidor maestro" con todos los demás servidores que necesitan las mismas configuraciones, a través de cron y rsync. Esto es, por ejemplo, necesario para varios esclavos de construcción. No es una buena solución.

+1

Aquí hay un escenario diferente que me trae aquí.

Creé una gota para crear un montón de imágenes de la ventana acoplable para luego darme cuenta de que necesito mover la región del host ...

La pregunta es ¿cómo adjunto la instancia de la máquina acoplable restaurada desde la instantánea que se ejecuta en el nuevo host?

El viernes 10 de marzo de 2017 a las 6:16 a. M., Exjimsk [email protected] escribió:

Creé una gota para construir un montón de imágenes de Docker para luego darme cuenta de que
Necesita mover la región del anfitrión. ¿Cómo adjunto la instancia de docker-machine?
restaurado desde la instantánea que se ejecuta en el nuevo host?

Si los certificados no han cambiado, debería poder cambiar su
docker-machine config para que apunte a la nueva dirección IP. Encontrarás el
archivo en ~ / .docker / machine / machines / your-machine-name / config.json.

Alternativamente, si nunca conserva datos en sus contenedores Docker, en su lugar
de mover el host, simplemente mátelo, cree uno nuevo y comience el mismo
contenedores en el nuevo host.
ᐧ

+1

+1

+1

+1

+1

+1

+1

+1

docker-machine attach , por favor.

Es bastante notable que una funcionalidad tan obvia aún no exista lista para usar. Vamos a administrar conjuntamente los hosts de la ventana acoplable, y esto es una molestia.

En mi caso, muy feliz de adjuntar el host existente ${HOST} con

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

Pero necesita copiar certificados ( ca.pem, cert.pem, key.pem ) a DOCKER_CERT_PATH manualmente.

¿Algún plan para esto? Tener rutas completas registradas en config.json es frustrante.

Mi caso de uso: tengo un repositorio git con configuraciones de máquina en él (uso el -s para apuntar la máquina acoplable en él). Los secretos se almacenan con git encrypt y la idea es que los trabajos de CI puedan hacer uso de estas configuraciones para manipular las máquinas a las que necesitan acceder.

FYI: # 3212

@lyda Estamos usando un enfoque de este tipo con https://github.com/dmstr/docker-roj , pero sin cifrado, ¡lo cual sería una característica muy buena en realidad!

Si bien roj siempre funciona con las mismas rutas, ya que está en un contenedor, existen otras soluciones como:

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

que básicamente cambia algunas rutas en config.json .
No es una gran magia, a menos que me esté perdiendo algo aquí.

¿Docker está desarrollando activamente docker-machine ? Lo pregunto porque ha pasado más de un mes desde que un compromiso llegó a dominar: https://github.com/docker/machine/commits/master

+1

+1

+1

¡Dios mío, el horror! ¡¿Este hilo sigue vivo después de casi tres años?!? Este es un caso de uso con el que todo el mundo se topa, o parecería hacerlo. ¿Qué me estoy perdiendo?

Bueno, supongo que docker-machine está muerto (al menos para mí: D). Cambié a kubernetes . Incluso autohospedado kubeadm en la versión alfa funciona mejor que esto en realidad. Puedo recomendarlo :)

por favor apoya esto :(

agregue "~ / .docker" a una carpeta que esté sincronizada o tal vez simbólicamente vinculada a la carpeta de la nube en ambas máquinas. hay un par de soluciones prediseñadas. no es demasiado difícil, solo investiguen un poco, nunca tuve un problema después de configurar una vez durante 30 segundos.

+1

+1

No entiendo cómo esta función, además de especificar una IP estática, las dos funciones más solicitadas en la historia del proyecto de la máquina acoplable, no se implementa.

Han pasado casi 4 años 😮 ¿Hay alguna actualización sobre esto?

Por el momento, muchos artículos / tutoriales sobre Docker todavía sugieren usar docker-machine como la herramienta de facto para administrar hosts. Sin embargo, la presencia de este problema es un factor limitante importante.

Actualmente sigo usando docker-machine y uso el enfoque "copy-certs-dirs" para compartir entre nuestras computadoras locales. Me gustaría actualizar a Kubernetes pero parece demasiado para mi proyecto.

¿Qué tal ejecutar docker-machine create desde dentro de un contenedor Docker? Ese contenedor podría luego exportarse, importarse en otra computadora y luego ejecutarse allí.

Todavía no tengo un apego, oh Dios mío