Machine: Usar docker-machine para importar hosts usando --driver = generic y / o --url, no funciona.

Hola @smakam , creo que lo que estás buscando es el controlador url : http://docs.docker.com/machine/#adding -a-host-without-a-driver

Hola @nathanleclaire
Gracias por la respuesta.
Miré el enlace que mencionaste e intenté lo siguiente, sin suerte.

Primero, probé sin ningún TLS:
En la máquina Ubuntu hice esto para iniciar el agente de Docker:
sudo docker -d -H unix: ///var/run/docker.sock -H tcp: //192.168.56.101 : 2376 &

En Windows, donde tenía instalada la máquina acoplable, hice esto:
$ docker-machine create --url = tcp: //192.168.56.101 : 2376 custom6
← [34mINFO ← [0m [0000] "custom6" se ha creado y ahora es la máquina activa.
$ docker-machine ls
NOMBRE CONDUCTOR ACTIVO ESTADO URL SWARM
custom6 * ninguno tcp: //192.168.56.101 : 2376

Me sale este error:
$ docker-machine env personalizado6
← [31mFATA ← [0m [0000] abrir C: \ Users \ srmakam.docker \ machine \ machines \ custom6ca.pem: El sistema no puede encontrar el archivo especificado.

No estoy seguro si docker-machine aplica TLS. Intenté iniciar el agente de Docker con certificado y clave y lo intenté con el cliente de Docker, pero tampoco tuve suerte.

Gracias
Sreenivas

Básicamente, exigimos TLS en nuestra forma actual. Si configura su propia CA y certs / keys, creo que probablemente podría usarlos a través de las opciones --tls-ca-cert , --tls-ca-key gloabl para Docker Machine. @ehazlett ¿ Algún comentario?

Hola

Intenté con TLS, todavía no pude hacerlo funcionar, no estoy seguro de lo que me falta:
Comencé Docker en mi host de Ubuntu:
sudo / usr / bin / docker -d --tlsverify --tlscacert =

Lo más probable es que desee utilizar CA existente, cliente, etc. para todas las cosas relacionadas con la máquina, ya que la configuración --tls-ca-cert etc. es global.

En cuanto a su demonio docker, desea usar la CA y el certificado / claves del servidor; en lo anterior, está usando el certificado CA, pero la clave del cliente y el cert. Necesitarías algo como:

docker -d --tlsverify --tlscacert ca.pem --tlscakey ca-key.pem --tlscert server.pem --tlskey server-key.pem

@ehazlett
Intenté usar la configuración global en el directorio "certs" para docker-machine create especificando opciones en la línea de comandos, todavía se queja de que "ca.pem" falta en las máquinas /\ directorio.
¿Cómo obtengo "server.pem" y "server-key.pem"? ¿Debería generarlo?

Pude conectarme entre el cliente de Docker y el agente de Docker en una máquina separada usando TLS sin usar docker-machine.

Gracias
Sreenivas

¿Puede mostrar los argumentos de la línea de comandos utilizados? Si especifica la máquina de certificados, simplemente debe usarlos. Si no, es un error :)

Hola @ehazlett
Primero, comencé el agente de Docker de esta manera:
sudo / usr / bin / docker -d --tlsverify --tlscacert = / home / xxx / .docker / machine / certs / ca.pem --tlskey = / home / xxx / .docker / machine / certs / key.pem --tlscert = / home / xxx / .docker / machine / certs / cert.pem --host = unix: ///var/run/docker.sock --host = tcp: //0.0.0.0 : 2376

Luego comencé con el cliente docker-machine así:
docker-machine --tls-ca-cert = / home / xxx / .docker / machine / certs / ca.pem --tls-client-key = / home / xxx / .docker / machine / certs / key.pem - -tls-client-cert = / home / xxx / .docker / machine / certs / cert.pem create --url = tcp: //0.0.0.0 : 2376 custom3

Recibí este error al configurar el entorno:
xxx @ ubuntu : ~ $ docker-machine env custom3
abrir /home/xxx/.docker/machine/machines/custom3/ca.pem: no existe tal archivo o directorio

Aquí, estoy ejecutando el agente de la ventana acoplable y la máquina acoplable en la misma máquina Ubuntu. Recibo un error similar cuando ejecuto el agente de Docker en Ubuntu y el Docker-Machine en Windows.

Gracias
Sreenivas

No debería utilizar key.pem y cert.pem para el motor Docker. El motor necesita un par de clave / certificado de servidor (la máquina los creará).

Para el medio ambiente, ¿cómo creaste la máquina custom3 ? Parece que algo salió mal durante la creación si ese archivo no existe.

Hola @ehazlett
¿Cómo debo iniciar el motor Docker? Según tengo entendido, la máquina acoplable exige el uso de TLS.

Así es como creé la máquina custom3. Esto no me dio ningún error.
docker-machine --tls-ca-cert = / home / xxx / .docker / machine / certs / ca.pem --tls-client-key = / home / xxx / .docker / machine / certs / key.pem - -tls-client-cert = / home / xxx / .docker / machine / certs / cert.pem create --url = tcp: //0.0.0.0 : 2376 custom3

¿Debería crear un par de clave / certificado de servidor manualmente como lo que haría la máquina si se usara el controlador con la máquina acoplable?

Gracias
Sreenivas

@smakam esto debería ser correcto. Debería generar una clave de servidor basada en esa CA existente. Haré algunas pruebas para ver si hay algún problema.

@smakam ¿ Alguna actualización sobre este problema o podemos cerrarlo?

@nathanleclaire Todavía no puedo hacer que funcione. Incluso probé con docker-machine 3.0 con el procedimiento de controlador genérico mencionado aquí (http://blog.docker.com/2015/06/docker-machine-0-3-0-deep-dive/)
Esto es lo que se menciona:
docker-machine create -d generic \
--generic-ssh-usuario ubuntu \
--generic-ssh-key ~ / Descargas / manualmente_created_key.pub \
- dirección-IP-genérica 12.34.56.78 \
selva

Supongo que .pub es un error tipográfico y tenemos que dar una clave privada. Recibí 2 tipos de errores en 2 hosts diferentes:

caso 1:
Importando clave SSH ...
Error al crear la máquina: estado de salida 1
Deberá consultar al proveedor para asegurarse de que la máquina y los recursos asociados se hayan eliminado correctamente.

caso 2:
Importando clave SSH ...
Error al obtener el comando SSH para verificar si el demonio está activo: estado de salida 1
Error al obtener el comando SSH para verificar si el demonio está activo: estado de salida 1

Por cierto, ¿dónde se almacenan los registros detallados de la máquina acoplable?
Intenté con docker-machine para Windows y Linux.

Gracias
Sreenivas

El mismo problema.
Ambas formas genéricas --url y -d no funcionan.

Intenté los mismos pasos que el póster original y obtuve un problema similar, momento en el que probé el controlador genérico y encontré un error similar al caso 1 (CentOS 7)

El mismo problema. No se puede usar --url y especificar el certificado.

¿Podría sugerirle al equipo de Docker que escriba un breve tutorial que nos lleve paso a paso? Sería muy útil.

El mismo problema aquí con anyconnect vpn conectado, mucho después de que reinicié mi computadora portátil sin ninguna conexión, desapareció.

+1 por el problema.
Intenté usar docker-machine create --url= con mi configuración de Docker existente en el host remoto, pero no tuve suerte. DM falla al intentar obtener TLS de $HOME/.docker/machine/machines/<name>/ca.pem .

El mismo problema. Intenté los mismos pasos, pero aún no se generaron certificados / claves de servidor.
docker-machine versión 0.4.0
Docker versión 1.8.0

El mismo problema. Intenté los mismos pasos, pero aún no se generaron certificados / claves de servidor.
docker-machine versión 0.4.1
Docker versión 1.8.1

@csokun @ miracle-in-sunday @narqo Generalmente se asume que usando --url usted "trae sus propios certificados", aunque lo admito, esa parte del código ha estado languideciendo por lo que puede estar roto.

Si desea que los certificados y las claves se generen automáticamente, pruebe el controlador generic : https://docs.docker.com/machine/drivers/generic/

Si eso no funciona para su caso de uso, ¿puedo pedirle que presente un problema por separado que detalle los pasos exactos que está tomando y los resultados que está viendo?

¡Gracias!

Hola chicos, ¿probaron con --virtualbox-hostonly-cidr speciefied? Trabajó para mi:

BartSlaman @ VLRNB176 ~
$ docker-machine create -d virtualbox --virtualbox-hostonly-cidr "192.168.99.100/24" dev4
Creando VirtualBox VM ...
Creando clave SSH ...
Iniciando VirtualBox VM ...
Iniciando VM ...
Para ver cómo conectar Docker a esta máquina, ejecute: C: \ Archivos de programa (x86) \ Git \ bindocker-machine env dev4

BartSlaman @ VLRNB176 ~
$ docker-machine env dev4
exportar DOCKER_TLS_VERIFY = "1"
exportar DOCKER_HOST = " tcp: //192.168.99.101 : 2376"
exportar DOCKER_CERT_PATH = "C: \ Users \ BartSlaman.docker \ machine \ machines \ dev4"
exportar DOCKER_MACHINE_NAME = "dev4"

Saludos
Bart Slaman

¿Alguna actualización sobre este tema? Intenté --url con --tls- * pero obtuve err "open /Users/user/.docker/machine/machine/ss/ca.pem no existe tal archivo o directorio". Yo uso docker-machine versión 0.4.1

Lo mismo aquí, pero un error diferente al crear:

Importando clave SSH ...
Error de cmd SSH!
comando: sudo nombre de host interno && echo "interno" | sudo tee / etc / hostname
err: estado de salida 1
salida: sudo: no hay tty presente y no se ha especificado ningún programa askpass

Y luego, al ejecutar eval "$ (docker-machine env internal)":
abrir /Users/marlon/.docker/machine/machines/internal/ca.pem: no existe tal archivo o directorio

Eso significa que los certificados no se están generando.

Es curioso, puedo enviar ssh a la máquina que ejecuta "docker-machine ssh internal".

Pude hacer que --url funcionara y apuntar a un motor Docker existente en DigitalOcean creado con Docker Machine.

Para usar --url o el controlador none , simplemente copié la carpeta ~/.docker/machine/machines/dobox/ en la máquina que usé para crear el host y eliminé cert.pem , key.pem , id_rsa.pub , id_rsa y config.json (dejando ca.pem , server.pem y server-key.pem ). Luego generé un nuevo certificado de cliente / par de claves (https://docs.docker.com/articles/https/, comenzando en "Para la autenticación del cliente") dentro del directorio recién creado de antes y lo copié en la máquina en la que estaba tratando de conectarse desde. Por último, agregué el host remoto usando docker-machine create --url=tcp://SOME_IP:2376 dobox y moví los certificados a donde Docker Machine espera que estén: ~/.docker/machine/machines/dobox/ . La carpeta ya debería estar allí y contener config.json , por lo que solo está agregando sus certificados. No estoy tratando de cambiar los indicadores TLS / esquema de autenticación que está usando Docker, que son:

--tlsverify \
--tlscacert="/home/roberto/.docker/machine/machines/dobox/ca.pem" \
--tlscert="/home/roberto/.docker/machine/machines/dobox/cert.pem" \
--tlskey="/home/roberto/.docker/machine/machines/dobox/key.pem" \
-H=tcp://SOME_IP:2376

Ahora puedo docker $(docker-machine config dobox) images o solo eval "$(docker-machine env dobox)" etc en la segunda máquina cliente.

docker-machine versión 0.4.0
Docker versión 1.8.2

Cómo autenticar cliente y servidor en Docker, cuyo nombre de usuario y contraseña tengo que configurar con él
Estoy usando https://docs.docker.com/reference/api/docker_remote_api_v1.20/
y tener cliente y servidor de Docker en la misma máquina host.
Y también avíseme si ambos no están en la misma máquina.

Chicos, por el amor de Dios, agreguen un tutorial sobre cómo importar máquinas acoplables existentes.
He creado 2 máquinas diferentes de azul en la nube a partir de 2 PC separadas y ahora no puedo conectarme desde la PC a la máquina azul que se crearon en otra.
Ya pasé 2 tardes, probando todas las sugerencias y sin resultado.

@nathanleclaire wdyt?

@ dmp42 ¿Sobre qué exactamente? --url rotura de

Supongo que sería genial tener al menos una declaración clara de que la importación de hosts existentes, de PC a PC, no está funcionando por ahora (o tiene algunos problemas conocidos) en algún lugar de la documentación oficial o aquí en github.

@baio +1

Tengo un host Centos 7 en el que ya instalé el paquete docker estándar del repositorio estándar de Centos, es decir, no usé el paquete del sitio web de Docker.

Desde mi estación de trabajo local, cuando trato de crear la máquina para este host Centos 7 usando el controlador genérico, falla con "estado de salida 1" cuando intenta instalar un paquete llamado "docker-engine".

Supongo que esto no funciona si Docker ya está instalado en el host remoto.

Relacionado: # 2270

Creo que tengo un ejemplo mínimo reproducible:

crear un simple Vagrantfile

VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|

  # Box
  config.vm.box = "ubuntu/precise64"
  config.vm.box_url = "http://cloud-images.ubuntu.com/vagrant/precise/current/precise-server-cloudimg-amd64-vagrant-disk1.box"

  # To make this easily reproducible
  config.ssh.insert_key = false
  config.vm.network "private_network", ip: "192.168.50.4"

end

iniciar la VM

$ vagrant up

confirme que puede SSH con la clave, el usuario y la IP que espera

ssh -i ~/.vagrant.d/insecure_private_key [email protected]

^ Esto funciona para mi

crear la máquina Docker

$ docker-machine create -d generic --generic-ssh-user vagrant --generic-ssh-key ~/.vagrant.d/insecure_private_key --generic-ip-address 192.168.50.4 repro

Importing SSH key...
Error creating machine: Maximum number of retries (60) exceeded
You will want to check the provider to make sure the machine and associated resources were properly removed.

¿Están obteniendo el mismo resultado? Avísame si hay algo más que pueda intentar ayudar a depurar.

El mismo problema aquí. No se puede hacer que --url (sin controlador) funcione con:

• Docker Machine 0.5.1 (lado del cliente) bajo OSX
• Docker 1.9 (lado del servidor remoto)
• El demonio remoto comenzó con:

--tlsverify -H=unix:///var/run/docker.sock -H=0.0.0.0:2376 --tlscacert=/root/.docker/ca.pem --tlscert=/root/.docker/cert.pem --tlskey=/root/.docker/key.pem

• Certificados de cliente (ca, key, cert) instalados en ~/.docker/machine/machines/mymachine/

Al escribir docker-machine env mymachine , falla en:

Error running connection boilerplate: Error checking and/or regenerating the certs: There was an error validating certificates for host "": open /Users/f2i/.docker/machine/machines/anakin/server.pem: no such file or directory
You can attempt to regenerate them using 'docker-machine regenerate-certs name'.
Be advised that this will trigger a Docker daemon restart which will stop running containers.

Sin docker-machine, todo parece estar bien:

> docker --tlsverify -H=myhost:2376 ps
CONTAINER ID        IMAGE                       COMMAND                  CREATED             STATUS              PORTS 

Me pregunto, ¿cuál es la diferencia real entre genérico ( --driver "generic" --generic-ip-address ... ) y sin controlador ( --driver "none" --url ...) ?
Entiendo que las conexiones genéricas a través de SSH (por lo que es como usar la ventana acoplable directamente en el servidor remoto) y ningún controlador se conecta al host mediante TCP.

En consecuencia, al no usar server.pem y server-key.pem en el host del cliente? No deben ser administrados por máquina. Correcto ?

Incluso proporcionando esos últimos archivos PEM, falla en:

Error running connection boilerplate: Error checking and/or regenerating the certs: There was an error validating certificates for host "": crypto/tls: failed to parse private key
You can attempt to regenerate them using 'docker-machine regenerate-certs name'.
Be advised that this will trigger a Docker daemon restart which will stop running containers.

El "sin controlador" es más un controlador de prueba de integración utilizado para el desarrollo. Pero si piratea lo suficiente, tu configuración puede usarse para registrar una máquina existente. Está programado para ser eliminado en una versión futura (# 2437). La documentación actual es engañosa sobre este controlador none .

El controlador generic debe usarse para registrar e instalar correctamente la ventana acoplable en cualquier host.
Tenga en cuenta que al menos reiniciará el demonio de la ventana acoplable en el host de destino. Pero es una forma confiable de registrar cualquier máquina 'genérica' en la máquina acoplable siempre que proporcione un acceso ssh.

@jeanlaurent el problema con el controlador generic es que se estropea con su máquina si la ventana acoplable ya está instalada (por ejemplo, cambiando el nombre de host; ejecutando yum update ). Creo que lo que muchos de nosotros estamos tratando de decir es que el controlador none tiene un caso de uso de primera clase y, si funcionara correctamente, sería una capacidad valiosa para muchos de nosotros (además de los controladores específicos). .

De acuerdo con @metasim en esto. El controlador none es un caso de uso muy común. Esta es una de las formas más básicas de interactuar con la API de Docker remota. Sería lamentable llamarlo test . Peraphs, el engaño proviene del hecho de que no queremos crear / administrar una nueva máquina ( docker-machine create ), sino solo conectarnos a una máquina existente ...

No estoy diciendo que no deberíamos poder 'registrar' la máquina existente en la máquina acoplable de una forma u otra, solo tenemos que hacerlo correctamente. Hay mucha confusión en torno al controlador none , no funciona en muchos lugares y la gente lo está haciendo mal. La intención aquí es preparar el terreno para una característica register existing machine real.

Pero una vez que una máquina es 'pirateada' en docker-machine a través del controlador none, hay muchas cosas que van a romper la cadena -> restart , upgrade y ssh obviamente. Hacer un cambio manual en el archivo json es tan eficiente como usar el controlador none para registrar una máquina.

@metasim Actualizar el generic para que no 'ensucie con su máquina' es una forma de manejarlo.

@vpusher Es posible que necesitemos diseñar una función de registro adecuada.

@jeanlaurent Gracias por tu respuesta. Puedo ver que actualizar generic para manejar este caso de uso (incluidas las claves existentes) puede ser un buen camino a seguir. Sin embargo, en el espíritu de "separación de preocupaciones", recomendaría considerar un nuevo controlador ( existing ?, preconfig ?, manual ?, diy ? :-)) para manejar este caso de uso, particularmente para que la estabilidad dentro de este contexto estrecho pueda establecerse mejor.

FYI. # 2260 y # 2269 (cerrados pero no abordados realmente) fueron un intento de capturar parte de esta confusión en torno al controlador none

PD: Creo que es totalmente aceptable que algunos comandos no sean compatibles explícitamente en este caso de uso (por ejemplo, restart , upgrade , etc.).

@metasim Sí, un controlador dedicado es probablemente la mejor manera de manejar una función de registro, pero no la única, un comando dedicado es otra. Pero antes de decidir cómo hacerlo, necesitamos aclarar / definir en qué caso todos necesitamos registrar una nueva máquina sin docker-machine instalando docker en ella.

Si echa un vistazo a PR # 2442, por ejemplo, hacemos ping al host de la ventana acoplable para la versión de la ventana acoplable. Porque queremos poder proporcionar actualizaciones en algún momento, o advertirle que su host de Docker es demasiado antiguo con su cliente de Docker actual. Con una máquina en la que no instalamos el demonio de la ventana acoplable, esto resultará difícil o, al menos, muy inestable.

Si consideramos que podemos actualizar el controlador generic de alguna manera, me pregunto para qué caso de uso alguien le gustaría registrar una máquina en docker-machine sin proporcionar acceso ssh.

Lo que es tuyo ? Vamos a enumerarlos.

Algunos comentarios sobre la definición del caso de uso para none y / o potencialmente desaprobarlo aquí: https://github.com/docker/machine/pull/2437#issuecomment -160768813

Mi sensación es que nosotros (el equipo de Machine) deberíamos:

• Siga las pautas existentes de Docker sobre la desaprobación de funciones (desapruebe durante 2 ciclos de lanzamiento).
• En consecuencia, si vamos a desaprobar el controlador none , deberíamos esperar para eliminarlo por completo hasta 0.7.0.
• Mientras tanto, corrija los errores existentes con el controlador none y trabaje para definir el flujo de trabajo futuro ideal (ya sea import / register o cambios en generic driver) para que los usuarios interesados ​​puedan seguir adelante y tener el tiempo suficiente para prepararse para los cambios que se avecinan.

@dgageot @jeanlaurent ¿Cómo suena eso?

@jeanlaurent Puedo ver que ssh sería prácticamente necesario, lo cual no es tan malo. Hasta ahora, había asumido que casi todo se podía hacer a través de la API REST.

Utilizo docker-machine principalmente como una herramienta para configurar las variables env requeridas para hacer que docker hable con otro host. Nunca uso los comandos upgrade / restart etc. Mis hosts Docker están en vSphere con una plantilla personalizada creada a través de un flujo de trabajo de vOrchestrator; usar el controlador vSphere en docker-machine no es una opción.

Dicho esto, me doy cuenta de que mi caso de uso no es el único caso de uso, pero espero que sea algo a considerar al menos.

Probablemente podría reemplazar docker-machine con un alias de shell, al menos para mis propósitos.

Aquí hay un ejemplo de caso de uso en caso de que sea de ayuda:

Me gustaría crear mis máquinas ec2 en Amazon usando elasticbeanstalk en lugar de docker-machine, porque elasticbeanstalk tiene muchas ventajas (como el escalado automático y el reinicio de la máquina). Me gustaría registrarlos con docker-machine y controlarlos usando docker-swarm.

Actualizar esas máquinas para que tengan Docker 1.9 es trivial, pero ejecutan algunos Amazon Linux (bifurcación centos antigua) y genérico no funciona con ellos. Debido a que el motor de la ventana acoplable no tiene tls, el truco que utilizo para administrarlos de forma remota con la ventana acoplable simple es exponer el archivo docker.sock en localhost: 2375 usando socat (como en https://github.com/sequenceiq/docker- socat) y hacer un túnel ssh desde mi máquina local con algo como ssh -i id_rsa [email protected] -L 2375: localhost: 2375 -N. Entonces puedo conectarme a través de la red con la ventana acoplable --tls = false -H tcp: // localhost : 2375.

Es mucha gimnasia. La combinación de acceso ssh y una configuración de la ventana acoplable que funcione (incluso sin ssl) debería ser todo lo que la máquina acoplable necesita para muchos casos interesantes (sin actualización, reinicie como se notó otro, pero nunca los uso de todos modos).

Espero que sea de utilidad.

@bonitao Me alegro de que lo hayas deletreado. También tengo el caso de uso de "túnel a través de ssh" en algunos compromisos empresariales.

Estoy empezando a intentar de nuevo usar la máquina Docker con hosts existentes ... Estoy de acuerdo con las declaraciones de none ... Tiene valor hoy para la comunidad, ya que el generic aún no está haciendo lo que es su intención ... Pasé muchas horas tratando de hacer funcionar el none para saber que hay una propuesta para cambiarle el nombre a test . @nathanleclaire ¿ Algún plan para hacer que el controlador generic funcione como se describe en ???

Pasé una buena cantidad de tiempo en https://github.com/docker/machine/issues/2628 y este es un caso de uso que tenemos ... Apoyar a los equipos existentes en toda la empresa con Docker ...

He estado buscando en Google, asumiendo que simplemente me faltaba algo de comprensión, tratando de descubrir cómo conectarme a una máquina docker azul desde mi servidor CI que creé en otro lugar. Terminé aquí y me sorprende que esto no sea posible (sin piratería).

Creé y obtuve instancias de máquinas de Azure Docker completamente en funcionamiento desde una estación de trabajo y solo quiero poder controlarlas e implementarlas desde scripts de CI, que pueden ejecutarse desde varias instancias esclavas de CI. ¿Realmente no hay una forma oficial de que se suponga que esto se lleve a cabo?

Actualicé mi ventana acoplable y ahora ya no puedo conectarme a mi antigua instancia de la máquina acoplable. yo obtengo

Error running connection boilerplate: Error checking and/or regenerating the certs: There was an error validating certificates for host "xxxxx:2376": open : no such file or directory
You can attempt to regenerate them using 'docker-machine regenerate-certs [name]'.
Be advised that this will trigger a Docker daemon restart which will stop running containers.

los comandos regeenrate-certs me dan

Regenerate TLS machine certs?  Warning: this is irreversible. (y/n): y
Regenerating TLS certificates
Detecting the provisioner...
Installing Docker...
Copying certs to the local machine directory...
Copying ca.pem to machine dir failed: open : no such file or directory

lo gracioso es que puedo

docker-machine ssh

sin ningún problema..

alguna solución?

Escenario: servidor existente y en funcionamiento con Docker y TLS habilitados.

Agregue el servidor / máquina existente a docker-machine:

docker-machine --tls-ca-cert path/to/ca.pem --tls-ca-key path/to/ca-key.pem --tls-client-cert path/to/client.pem --tls-client-key path/to/client-key.pem create --driver none --url tcp://HOST:2376 NAME

En su directorio de usuario (~ / .docker / machine / machines / NAME) agregue el mismo certificado de cliente como "cert.pem" y "server.pem" y la clave del certificado de cliente como "key.pem" y "server-key. pem "también ajuste su config.json para incluir la configuración SSH relevante ...

Yo había planteado este problema. Recientemente hice que esto funcionara y he puesto las instrucciones aquí (https://sreeninet.wordpress.com/2015/05/31/docker-machine/) en caso de que alguien quiera hacer una referencia.

Aquí hay un guión que me está funcionando un poco:
https://github.com/docker/machine/issues/3344#issuecomment -212536797

@devcrust dónde están exactamente esos:

path/to/ca.pem
path/to/ca-key.pem
path/to/client.pem
path/to/client-key.pem

???

$ ls certs/
ca-key.pem  ca.pem  cert.pem  key.pem
$ ls machines/adhoc/
ca.pem  cert.pem  config.json  id_rsa  id_rsa.pub  key.pem  server-key.pem  server.pem

No puedo configurarlo correctamente. Yo también tengo este problema:

Copying ca.pem to machine dir failed: open : no such file or directory

después de actualizar a 0.6.0 .... Perdí el acceso tcp a 12 máquinas

@nathanleclaire ¿ Alguna actualización sobre esto? Estoy tratando de averiguar cómo me conectaría a un Docker Host que se ejecuta en Microsoft Azure, que creé desde una computadora diferente, usando docker-machine . En este momento, no tengo soluciones.

Solución: _ (desea) _

docker-machine agregar <🖥️ nombre> --driver <☁️️ controlador de proveedor>

Es muy triste que haya pasado tanto tiempo y todavía no se haya introducido ninguna función para resolver este problema.

Por lo que vale. Puede crear una máquina usando el controlador genérico, pero eso reiniciará todos sus contenedores.
Agregar reinicio: siempre en sus contenedores garantizará que no se detengan. Secundaría la opción de

También soy partidario de tener una opción de agregar máquina acoplable.

Aquí hay dos proyectos con diferentes enfoques para compartir máquinas:

• https://github.com/dmstr/docker-roj
• https://github.com/bhurlow/machine-share

@jeanlaurent

Lo que es tuyo ? Vamos a enumerarlos.

Mi idea era conectar mi máquina local a un servidor físico existente con una carga de contenedores en ejecución. Hacer docker-machine create --driver generic probablemente los detendrá, y más . Me pregunto por qué es necesario reiniciar la ventana acoplable ...

Bueno, simplemente puedo ejecutar comandos sobre ssh, pero por su descripción parece que docker-machine podría usarse.

Pero luego, si creó una máquina virtual desde una computadora y desea administrarla desde otra. O reinstaló su sistema operativo local ... O quiere delegar el control sobre la VM a otra persona ...

PD: Estoy dando mis primeros pasos con Docker, por lo que es posible que me falten puntos ...

@ x-yuri Para "crear" una máquina manualmente, simplemente copie sus archivos de .docker/machine/machines y ajuste sus rutas.