Machine: Conectarse al motor de Docker de Windows

Debido a la forma en que funciona actualmente el modelo de aprovisionamiento, puede que no sea _demasiado_ loco implementar dicha funcionalidad, aunque requeriría repensar o empapelar algunas suposiciones bastante fundamentales (por ejemplo, la presencia de SSH).

Tengo la sensación de que la forma en que debe implementarse es con algunos indicadores que indiquen específicamente que es una máquina con Windows. por ejemplo, --generic-winrm-userpass .

No sé mucho sobre los contenedores de Windows Server, sin embargo, como Nathan dijo, la mayor parte del trabajo sería obtener el protocolo SSH en Windows, ya sea esperando que Microsoft lo haga (está sucediendo) o proporcionando un polyfill usando WinRM tal vez (yo no saber cómo funciona).

Recuerdo que algunas discusiones sobre esto también estaban sucediendo internamente. cc: @jstarks ya que está en el equipo de contenedores de Windows.

Si crees que puedes crear un prototipo de algo, diría que hazlo.

Hola @StefanScherer , soy un primer ministro en el equipo de Hyper-V y estoy investigando cómo podríamos hacer esto posible. Una de las cosas en las que estamos pensando es que quizás podríamos usar esto como el sistema operativo que Docker Machine podría usar. Si usamos Nano, quedaría como una pequeña descarga. El repositorio para el proyecto Open SSH en Windows está aquí .

Se agradece cualquier idea y si va a crear un prototipo de algo, hágamelo saber. Seguiré publicando aquí si descubro más sobre cómo hacer que esto funcione.

cc: @dgageot

@ enderb-ms Oh, una imagen Nano, eso también sería genial. Y OpenSSH también es una opción. Mientras tanto, otros proyectos como Packer y Vagrant mejoraron el soporte de Windows para usar WinRM y deshacerse de SSH para tener una comunicación más nativa.

Lo que pensé como primer paso es dejar que la máquina acoplable se conecte a un servidor TP4, por ejemplo. con el controlador genérico.

Todavía no he probado el controlador azure. Pienso en seleccionar una plantilla TP4 VM + docker engine en Azure y la máquina docker sabe que debe aprovisionar una VM de Windows en lugar de una VM de Linux. Solo tiene que realizar algunos pasos mínimos para conectar la máquina local donde se está ejecutando docker-machine con ese Docker Engine remoto.

Estos son los pasos de un controlador genérico que se ejecuta en una máquina virtual Linux que ya tiene Docker instalado. Agregué algunas ideas para Windows:

1. docker-machine se conecta a la dirección IP remota
2. verifique la versión del sistema operativo si se puede aprovisionar (cat / etc / os-release -> obtenga información de Windows en su lugar)
3. actualizar el nombre de host?
4. actualizar / etc / hosts
5. instalar curl (no es necesario para instalarlo en hosts de Windows)
6. compruebe si Docker está instalado. Si no, instálelo. (probablemente ejecute el Install-ContainerHost.ps1 completo?)
7. comprobar la versión de Docker
8. crear el directorio de configuración de docker (/ etc / docker ->% ProgramData% / docker)
9. detener el servicio de Docker
10. inserte ca.pem (Windows:% ProgramData% / docker / certs.d)
11. insertar server.pem
12. inserte server-key.pem
13. escribir el archivo de configuración de docker (/ etc / default / docker, probablemente una mejora de% ProgramData% / docker / runDockerDaemon.cmd)
14. iniciar el servicio de Docker
15. netstat -an

Fase 1:

Para Azure / TP4 local con el escenario del motor de Docker preinstalado:

Paso 1.) tiene que usar WinRM (por ejemplo, eche un vistazo al comunicador winrm del

Paso 2) podría verificar si todo está funcionando y si la VM es un TP4. De lo contrario, cancele si no es posible instalar todo, por ejemplo, sin reiniciar.

Luego tiene que seguir los pasos 9.) ... 14.) para detener la ventana acoplable, inserte los certificados TLS y reinicie la ventana acoplable. Después de que la máquina acoplable haya creado la conexión a una máquina virtual de Azure existente o una máquina virtual de Windows local o local y haya asegurado el puerto acoplable.

Fase 2:

Más adelante, en el paso 2) se podría mejorar para permitir que los servidores 2016 "vacíos" instalen Docker con el paso 6).

Fase 3:

Y luego tener un "boot2docker.iso" con una imagen Nano para descargar localmente.

Solo algunos primeros pensamientos ;-)

Para contexto: http://ashleypoole.co.uk/2016/docker-containers-windows-server-2016-guide/

@dgageot , ¿planeas

@friism Ya hay trabajo en curso con @ enderb-ms

@dgageot ¡genial! ¿Hay algún lugar donde pueda obtener más detalles?

@dgageot Tengo un cambio que puede activar las instancias del servidor de Windows en Azure y configurar el motor Docker. ¿Hay un repositorio donde esté disponible el trabajo de @ enderb-ms? Puedo enviar el mío aquí para su revisión y posiblemente fusionarlo o unificarlo con cualquier cosa que esté haciendo @ enderb-ms.

Breve descripción de lo que he hecho

1. Agregue soporte para hacer girar la imagen de Windows.
2. Utilice la imagen TP4 de Windows Server 2016 en Azure
3. Gíralo. Estoy usando la biblioteca https://github.com/Azure/azure-sdk-for-go en lugar del código vendido en https://github.com/docker/machine/tree/master/vendor/github.com/ MSOpenTech / azure-sdk-for-go , que parece una versión anterior.
4. Use WinRM para conectarse a la instancia, instale docker-engine
5. Realice cualquier otro paso. He notado que la red se estropea a veces y es necesario configurar el Vswitch.

cc @ahmetalpbalkan

@ppadala Increíble

hawt

Gracias @stefanfoulis @friism. El trabajo está en https://github.com/containerx/machine , pero eso también incluye algunos otros cambios no relacionados con este PR.

Estoy creando una nueva rama, código de limpieza y enviaré una solicitud de extracción pronto.

Hice la solicitud de extracción, se agradecen los comentarios y revisiones.

Todavía hay un par de elementos codificados que necesitan mejorarse, los cuales corregiré en los próximos días.

PR para referencia: https://github.com/docker/machine/pull/3146

@ppadala realmente agradable. Creo que los mantenedores de @ enderb-ms y docker-machine están tratando de averiguar si deberían usar WinRM o bootstrap OpenSSH en Windows. Dejaré que esas personas decidan qué trabajo debería seguir adelante.

En lo que respecta al controlador azul, me temo que no podemos realizar cambios en el controlador azure . Acabo de reescribir el controlador azul con la pila de Azure Resource Manager (es un gran cambio rotundo). Los detalles están en: https://github.com/docker/machine/issues/2742#issuecomment -189993875 actualmente estamos abordando problemas de escasez en Azure SDK, una vez que estén listos, enviaré un PR para lanzar el nuevo azul. conductor.

@ppadala también es importante que esto probablemente no debería ser solo un cambio de controlador azure , ya que casi todos los proveedores de la nube tendrán imágenes WS2016 y (si es necesario) docker-machine probablemente necesite agregar esos indicadores específicos de Windows.

@ppadala realmente agradable. Creo que los mantenedores de @ enderb-ms y docker-machine están tratando de averiguar si deberían usar WinRM o bootstrap OpenSSH en Windows. Dejaré que esas personas decidan qué trabajo debería seguir adelante.

De hecho, también he considerado la opción SSH. Simplemente no me gustó el servidor Windows OpenSSH que probé, tuve problemas para conectarme al servidor desde OS X. Dicho esto, no he probado todos los servidores SSH posibles, ustedes lo saben mejor. Feliz de saltar a la discusión, avíseme dónde está sucediendo la discusión.

En lo que respecta al controlador azul, me temo que no podemos realizar cambios en el controlador azul. Acabo de reescribir el controlador azul con la pila de Azure Resource Manager (es un gran cambio rotundo). Los detalles están en: # 2742 (comentario) actualmente estamos abordando problemas de escasez en el SDK de Azure, una vez que estén listos, enviaré un PR para lanzar el nuevo controlador azul.

No se preocupe, el cambio que hice en realidad no es solo en el controlador azul, sino también en el resto de la máquina acoplable para agregar una opción para el sistema operativo. Probaré su código publicado en # 2742. ¿El código ya tiene soporte para hacer girar imágenes de Windows en Azure?

@ppadala también es importante que esto probablemente no debería ser solo un cambio de controlador azul, ya que casi todos los proveedores de nube tendrán imágenes WS2016 y (si es necesario) docker-machine probablemente necesite agregar esos indicadores específicos de Windows.

Como mencioné anteriormente, mi cambio tiene tanto el controlador azul como el resto de los cambios de la máquina acoplable. ¿Cómo procederemos desde aquí? Puedo esperar a que se confirmen los cambios de su administrador de recursos y luego podemos descubrir cómo agregar indicadores específicos de Windows a docker-machine.

@ahmetalpbalkan Revisé el código que publicaste en # 2742. Según tengo entendido, está moviendo el controlador para usar ARM API y no tiene soporte para imágenes de Windows. Esto es lo que propongo

1. Revisa y confirma tu código
2. Agregar soporte de imagen de Windows giratorio
3. Agregue el aprovisionador de Windows usando WinRM (o SSH si esa es la elección en la que estamos de acuerdo), banderas y otros cambios en el núcleo de la máquina acoplable

He hecho 2 y 3 con el controlador actual y puedo hacer cambios similares en función de su controlador basado en ARM. Déjame saber lo que piensas.

@ppadala suena bien. si intenta volver a colocar su código en la parte superior de mi rama, puede desbloquearse y comenzar a trabajar. En cuanto a la funcionalidad, el nuevo controlador está listo, pero todavía estamos abordando algunos problemas en azure-sdk-for-go y es posible que aún demoren algún tiempo (como un par de semanas) y enviaré el resultado final como un tirón solicitud.

@ppadala ¡ esto es increíble! Gracias por hacer esto. Desafortunadamente, no he podido conseguir tiempo de desarrollador, así que no hemos comenzado a trabajar en nuestras ideas. Pero esto podría ayudarme a que la gente se sume.
Una de las razones por las que queremos usar SSH es permitir que los desarrolladores de otras plataformas (Linux y OS X) puedan implementar hosts de contenedores de Windows en máquinas virtuales en sus máquinas locales o en la nube. Comenzamos a hablar sobre la posibilidad de incluir OpenSSH en algunas imágenes de Azure, de esa manera no se necesitarían pasos adicionales para agregar esa capacidad. ¿Podría contarme más sobre los problemas que vio con OpenSSH?
Etiquetando a @dgageot que también tenía algunas ideas sobre WinRM.
Nuevamente, esto es genial, gracias por hacer esto @ppadala

@ppadala ¡ esto es increíble! Gracias por hacer esto. Desafortunadamente, no he podido conseguir tiempo de desarrollador, así que no hemos comenzado a trabajar en nuestras ideas. Pero esto podría ayudarme a que la gente se sume.
Una de las razones por las que queremos usar SSH es permitir que los desarrolladores de otras plataformas (Linux y OS X) puedan implementar hosts de contenedores de Windows en máquinas virtuales en sus máquinas locales o en la nube. Comenzamos a hablar sobre la posibilidad de incluir OpenSSH en algunas imágenes de Azure, de esa manera no se necesitarían pasos adicionales para agregar esa capacidad. ¿Podría contarme más sobre los problemas que vio con OpenSSH?

Estaba configurando https://github.com/PowerShell/Win32-OpenSSH/wiki/Install-Win32-OpenSSH como servidor SSH. Cuando ejecuto ssh <server> <cmd> desde Mac, no parece funcionar, aunque ssh interactivo simple para el servidor funciona.

Si incluye el servidor SSH en las imágenes de Azure, definitivamente es más limpio. La interfaz del controlador docker-machine ya parece asumir que el acceso SSH está disponible.

@ppadala en realidad, acabo de descubrir que hay algunas bibliotecas que permiten la comunicación winrm en Linux y Mac OS X, lo que haría todo mucho más simple por ahora. Estás usando esta biblioteca para la comunicación winrm, ¿verdad? ¿Sabes si eso funciona en Linux y Mac OS X?

@ppadala en realidad, acabo de descubrir que hay algunas bibliotecas que permiten la comunicación winrm en Linux y Mac OS X, lo que haría todo mucho más simple por ahora. Estás usando esta biblioteca para la comunicación winrm, ¿verdad? ¿Sabes si eso funciona en Linux y Mac OS X?

Sí, la biblioteca de empaquetadores es lo que estoy usando. Funciona tanto en Mac OS X como en Linux.

@ppadala la discusión de ssh vs winrm es muy interesante:

• SSH es bueno porque significa que la máquina siempre usa el mismo protocolo para hablar con los hosts (ya sean Linux o Windows)
• winrm es bueno porque no implica bloquear software nuevo / externo en Windows

@ppadala parece que puede habilitar automáticamente winrm al aprovisionar en azure con EnableWinRMHttp . Detalles aquí: https://msdn.microsoft.com/en-us/library/azure/dn495299.aspx

@ enderb-ms @ taylorb-microsoft ¿Qué imagen inicial de WS2016 debería usarse para esto?

@ppadala parece que puede habilitar automáticamente winrm al aprovisionar en azure con EnableWinRMHttp. Detalles aquí: https://msdn.microsoft.com/en-us/library/azure/dn495299.aspx

Ya estoy haciendo esto, lo que abre los puertos en Azure. La imagen también debe tener WinRM habilitado y la regla de firewall de Windows configurada correctamente. Tal vez la gente de Microsoft pueda intervenir aquí, si entiendo esto incorrectamente.

@ppadala Quizás esta plantilla de inicio rápido de Azure ayude un poco.

1. Abriendo un puerto: https://github.com/Azure/azure-quickstart-templates/blob/master/windows-server-containers-preview/azuredeploy.json#L122 -L135
2. Abriendo el firewall con PowerShell: https://github.com/Azure/azure-quickstart-templates/blob/master/windows-server-containers-preview/containerConfig.ps1#L9 -L11
3. Configure WinRM: https://github.com/Azure/azure-quickstart-templates/blob/3c9980dd6baf21e84e48fcc9028ee54b3c0269f6/201-vm-winrm-lb-windows/ConfigureWinRM.ps1

Esto debería hacerse para el puerto 2376, pero es casi lo mismo.

con respecto a la cuestión de WinRM vs OpenSSH.

Creo que, en última instancia, ambas deberían ser opciones ... el trabajo de OpenSSH para Windows está progresando (https://github.com/PowerShell/Win32-OpenSSH) pero aún no está completamente completo (por ejemplo, aún no funciona en Nano Server ). Así que creo que WinRM es una buena opción en este momento y luego podemos superponer OpenSSH cuando esté disponible para la paridad con las experiencias de Linux.

Hola @ppadala , algunos de mis compañeros de trabajo tienen algunas preguntas sobre la actualización que planea realizar en el controlador de Azure:

1. ¿Tiene planes de probarlo con Nano Server? ¿Cómo elige el controlador qué sistema operativo elegir?
2. Usando los cambios que va a hacer, ¿funcionará este escenario? "El usuario usa la función docker-machine create con el controlador de Azure para aprovisionar una máquina virtual host de contenedor de Windows, luego usa docker-machine env para comenzar a administrar sus contenedores desde la VM desde su cliente"
3. ¿Cómo será el comando "docker-machine create" para Windows?

Además, no quiero ser agresivo, pero tengo curiosidad, ¿alguna idea de cuándo subirá tu PR? Nuevamente, ¡muchas gracias por esto!

En lo que respecta a la pregunta de @friism , si esto puede funcionar con las imágenes Full Server y Nano Server de WS2016, sería perfecto.

1. ¿Tiene planes de probarlo con Nano Server? ¿Cómo elige el controlador qué sistema operativo elegir?

Si. El controlador simplemente activa cualquier imagen de servidor de Windows dada como una opción similar a cómo se elige la imagen de Linux con la opción --azure-image. Dicho esto, el nano servidor necesita ser probado.

1. Usando los cambios que va a hacer, ¿funcionará este escenario? "El usuario usa la función docker-machine create con el controlador de Azure para aprovisionar una máquina virtual host de contenedor de Windows, luego usa docker-machine env para comenzar a administrar sus contenedores desde la VM desde su cliente"

Si. Este es el caso de uso principal. La funcionalidad del cliente sigue siendo la misma, porque todo lo que estamos haciendo es activar un servidor Docker de Windows y configurar puertos. Si el motor de la ventana acoplable de Windows lo admite (lo que es así), entonces funciona.

1. ¿Cómo será el comando "docker-machine create" para Windows?

Las opciones adicionales serían --azure-os "windows", --azure-winrm-username "username", --azure-winrm-password "contraseña" similar a como @StefanScherer sugirió anteriormente.

Con respecto a la línea de tiempo, ya realicé la mayor parte de mi cambio con el nuevo controlador de Azure (https://github.com/docker/machine/pull/3159), pero @ahmetalpbalkan , algunos otros y yo encontramos un problema con la autenticación (https: //github.com/docker/machine/issues/3201) y @ahmetalpbalkan hicieron un comentario sobre volver al controlador anterior (https://github.com/docker/machine/issues/3201#issuecomment-199409527). Primero tenemos que resolver esa discusión para ir más allá. Si volvemos al controlador anterior, me resultará más fácil fusionarme.

¿Asistirás a Build? Sería genial sincronizar en persona.

@ppadala ¡ @ ah3rz para más detalles

@ppadala No estaré en Build, pero mi gerente @ taylorb-microsoft lo estará, así que podrías sincronizarte con él :-)

@ppadala , mencionaste que te desbloquearon , avísanos si hay algo que podamos hacer para ayudarte.

Actualizar. Tengo la mayor parte del cambio basado en cambios, puedo activar servidores de Windows. Limpiar el código para enviarlo para su extracción en unos días.

Sin embargo, debemos decidir qué imagen del servidor de Windows se utilizará como imagen de la máquina virtual de destino. La imagen oficial actual de Windows Server Core solo tiene habilitado RDP. Necesito que WinRM esté habilitado en la imagen. Tenga en cuenta que no se trata de habilitar WinRM a través de Azure (https://msdn.microsoft.com/en-us/library/azure/dn495299.aspx) como pocas personas sugirieron. Eso solo abre puertos WinRM en Azure. La instancia en ejecución de la imagen (luego capturada en una nueva imagen a través de sysprep) debería haber ejecutado los siguientes comandos.

PS C:\> winrm set winrm/config/service/auth @{Basic=”true”}
PS C:\> winrm set winrm/config/service @{Allowunencrypted=”true”}
PS C:\> New-NetFirewallRule -Protocol TCP -LocalPort 5985 -Direction Inbound -Action Allow -DisplayName winrm
PS C:\> winrm quickconfig

Otro inconveniente es que la instalación del motor Docker lleva mucho más tiempo que la instalación en el lado de Linux. La máquina virtual también debe reiniciarse. Estoy usando los siguientes comandos para la instalación del motor Docker.

PS C:\> wget -uri https://aka.ms/tp4/Install-ContainerHost -OutFile C:\Install-ContainerHost.ps1
PS C:\> powershell.exe -NoProfile C:\Install-ContainerHost.ps1 -HyperV

Reboot

PS C:\> Install-ContainerImage -Name WindowsServerCore -Version 10.0.10586.0
PS C:\> wget https://raw.githubusercontent.com/Microsoft/Virtualization-Documentation/live/windows-server-container-tools/Update-ContainerHost/Update-ContainerHost.ps1 -OutFile Update-ContainerHost.ps1
PS C:\> ./Update-ContainerHost.ps1

Preguntas para @ enderb-ms y @ahmetalpbalkan : ¿puede Microsoft proporcionar una imagen que tenga habilitado WinRM? Mientras hacemos eso, ¿deberíamos considerar incluir el motor acoplable también con él en lugar de la instalación bajo demanda? Aunque esto restringe a los usuarios a una versión empaquetada específica de docker-engine, la máquina virtual estará disponible mucho más rápido (de lo contrario, el usuario ejecuta la máquina docker y espera una hora o más para obtener su host de la ventana acoplable de Windows Server).

Actualmente, creé una imagen personalizada que tiene WinRM y Docker-Engine instalados y configurados.

@ppadala ¿la sucursal es pública en https://github.com/Azure/azure-quickstart-templates/blob/875d139c16c9c023dce519e6dd48c707e3473346/201-vm-winrm-windows/azuredeploy.json#L183

@ppadala ¿la sucursal es pública en https://github.com/Azure/azure-quickstart-templates/blob/875d139c16c9c023dce519e6dd48c707e3473346/201-vm-winrm-windows/azuredeploy.json#L183

La sucursal es pública, pero aún no he comprobado la última versión. Déjame ver si puedo hacer esto.

@ppadala ¿la sucursal es pública en https://github.com/Azure/azure-quickstart-templates/blob/875d139c16c9c023dce519e6dd48c707e3473346/201-vm-winrm-windows/azuredeploy.json#L183

Intenté pasar los recursos, pero aparece un error

Error creating machine: Error in driver during machine creation: compute/VirtualMachinesClient:CreateOrUpdate 400 Failure responding to request -- Original Error: azure: Service returned an error. Code="InvalidRequestContent" Message="The request content was invalid and could not be deserialized: 'Could not find member 'resources' on object of type 'ResourceDefinition'. Path 'resources', line 1, position 953.'." Status=400

Aquí está el código que intenta hacer esto: https://github.com/ppadala/machine/blob/azure-windows/drivers/azure/azureutil/azureutil.go#L540. Puede ver las confirmaciones https://github.com/ppadala/machine/commits/azure-windows para ver mis cambios para obtener soporte de Windows.

La forma correcta de hacerlo es hacer que Azure go-sdk exponga una función fácil de usar para preparar esta plantilla de implementación. Es difícil traducir las cosas correctas para pasar al observar las plantillas de implementación de json. @ahmetalpbalkan , ¿alguna idea?

Básicamente, hay dos caminos.

1. Tener una imagen personalizada con WinRM (y posiblemente docker-engine) instalado y configurado. Entonces, el código que tengo hasta ahora está listo para funcionar.
2. Comience desde la imagen genérica de Windows Server 2016, descubra la instalación a través de plantillas y luego continúe con el resto de los pasos, como cargar certificados, etc.

@ppadala Yo también estoy desconcertado. Apuesto a que la API está tratando de decir que no puede especificar extensiones en la llamada de creación de VM. Por ejemplo, cuando implementa una plantilla ARM con extensiones y observa cómo ocurre la implementación, ARM primero crea la VM y luego crea el recurso Extensión por separado una vez que se crea la VM ...

Debe haber algunos métodos para agregar extensiones a las VM en el paquete arm/compute . Sugiero agregar extensiones una vez que se crea la VM, eso debería desbloquearlo.

Gracias @ahmetalpbalkan. Agregué VirtualMachineExtension después de la creación de la máquina virtual y funcionó. Tuve que luchar un poco para encontrar la forma correcta de configurar los oyentes WinRM HTTPS, pero tengo lista la solicitud de extracción # 3329. Hazme saber tus comentarios.

También cargué los binarios en https://www.dropbox.com/sh/kpc46xtc8su2sj7/AABtxVIVbGo8KLy7tu6HnWwza?dl=0 para facilitar las pruebas.

Uso: se agregan tres nuevos parámetros al controlador de Azure

--azure-os "linux"                  OS for the Azure VM (Windows|Linux)
--azure-winrm-user "docker-user"    Username for WinRM login [$AZURE_WINRM_USER]
--azure-winrm-password              Password for WinRM login [$AZURE_WINRM_PASSWORD]

Comando de muestra

docker-machine -D create -d azure --azure-subscription-id $(cat ~/azure/subid) --azure-os "windows" --azure-image MicrosoftWindowsServer:WindowsServer:2016-Technical-Preview-with-Containers:2016.0.20151118 --azure-winrm-password "mysecretpassword" vhost-win-test

@ppadala @ahmetalpbalkan No sé si ya incorporaste esto, pero este artículo sobre cómo proteger el demonio de Windows también puede ser bueno: https://github.com/Microsoft/Virtualization-Documentation/tree/master/windows-server- contenedor-herramientas / DockerTLS

/ cc @PatrickLang @swernli

@ppadala Gracias, esto es totalmente increíble. Acabo de probar el comando de muestra para crear una máquina TP4 en Azure. Y sí, funcionó con sus binarios prediseñados desde el primer momento. (ok, debe ingresar una contraseña más compleja para que se ajuste a los requisitos de complejidad de la contraseña de Windows)

Un motor Docker seguro con un comando de máquina acoplable tan simple. ¡Eso es un gran avance!

$ ./docker-machine-Darwin-x86_64 -D create -d azure --azure-subscription-id $(pass azure) --azure-os "windows" --azure-image MicrosoftWindowsServer:WindowsServer:2016-Technical-Preview-with-Containers:2016.0.20151118 --azure-winrm-password $(pass azure-winrm-password) vhost-win-test
$ eval $(./docker-machine-Darwin-x86_64 env vhost-win-test)
$ docker version
Client:
 Version:      1.10.1
 API version:  1.22
 Go version:   go1.5.3
 Git commit:   9e83765
 Built:        Fri Feb 12 22:11:40 UTC 2016
 OS/Arch:      darwin/amd64

Server:
 Version:      1.10.0-dev
 API version:  1.22
 Go version:   go1.5.1
 Git commit:   59a341e
 Built:        Fri Nov 13 17:23:07 UTC 2015
 OS/Arch:      windows/amd64

@ppadala Y lo que es aún más fantástico es que un docker-machine rm -f vhost-win-test limpia TODO : luché tantas veces limpiando todas las partes de una máquina virtual creada con "implementar en azul", siempre me perdí un botón de "anular implementación de azul" 😄

@ppadala @ahmetalpbalkan No sé si ya incorporaste esto, pero este artículo sobre cómo proteger el demonio de Windows también puede ser bueno: https://github.com/Microsoft/Virtualization-Documentation/tree/master/windows-server- contenedor-herramientas / DockerTLS

Gracias por el enlace @friism. Sí, el motor de acoplamiento ya está protegido con TLS similar a Linux. docker-machine create workflow genera las credenciales (cert, key y ca) y uso WinRM para cargarlas en Windows Server.

@ppadala Gracias, esto es totalmente increíble. Acabo de probar el comando de muestra para crear una máquina TP4 en Azure. Y sí, funcionó con sus binarios prediseñados desde el primer momento. (ok, debe ingresar una contraseña más compleja para que se ajuste a los requisitos de complejidad de la contraseña de Windows)

Gracias por probar @StefanScherer. La contraseña de texto sin formato es la única parte que no me gusta aquí (me gusta su enfoque de pase). Podemos cambiar a una autenticación basada en certificados más tarde. Desafortunadamente, la biblioteca de empaquetadores aún no lo admite.

@ppadala Y lo que es aún más fantástico es que una máquina acoplable rm -f vhost-win-test limpia TODO. Luché muchas veces para limpiar todas las partes de una máquina virtual creada con "deploy to azure", siempre perdí un " anular la implementación del botón azul "😄

El crédito es para @ahmetalpbalkan por pasar a Azure ARM y escribir una "limpieza" limpia.

@ppadala, esto es increíble. ¡Buen trabajo! Supongo que la pregunta ahora será cómo fusionar esto con el controlador azul a corto y con otros controladores (como google / aws) a largo plazo.

@ahmetalpbalkan, la solicitud de extracción # 3329 ya está sincronizada con el maestro y fusionada con el controlador azure, será excelente si puede revisar y proporcionar comentarios. Actualmente, solo Azure tiene máquinas virtuales Windows Server 2016, pero el código está escrito de tal manera que admite GCP, AWS, vSphere y otros fácilmente.

Actualmente, solo Azure tiene máquinas virtuales Windows Server 2016, pero el código está escrito de tal manera que admite GCP, AWS, vSphere y otros fácilmente.

• @ppadala
  ¿Significa esto que el soporte a los proveedores de VM locales está en el horizonte?

@ppadala @srounce Diría que alguien debería echar un vistazo a las capacidades de ejecución de WinRM y Startup Script de las API de AWS / GCE / otras para averiguar si la funcionalidad se puede trasladar a otros controladores con un conjunto mínimo de cambios.

@ppadala @ahmetalpbalkan ¿Podría AzureStack ?

@nilleb Me temo que todavía no. Si lo necesita, abra una edición separada.

Acabo de descargar la ventana acoplable para Windows que tiene el 1.12 RC2 que tiene el 0.8.0-rc1 pero cuando pruebo la opción "azure-os" "windows" no parece funcionar. Por favor, avíseme dónde podría adquirir una versión de máquina acoplable que pueda crear hosts acoplables TP5 Windows 2016 en Azure.

Gracias,

@SharadGumaste ¿ --azure-image ?

Acabo de descargar la ventana acoplable para Windows que tiene el 1.12 RC2 que tiene el 0.8.0-rc1 pero cuando pruebo la opción "azure-os" "windows" no parece funcionar. Por favor, avíseme dónde podría adquirir una versión de máquina acoplable que pueda crear hosts acoplables TP5 Windows 2016 en Azure.

@SharadGumaste Supongo que estabas probando la versión publicada. El parche para admitir Windows (opción de azure-os windows) aún no está combinado.

Pradeep, sí, hice la actualización desde el software de la ventana acoplable. Que es lo mejor
forma de obtener binarios de su trabajo? Estoy muy cerca de hacer una demostración para un
cliente nuestro, excepto que no puedo crear un servidor Windows barebone e instalar
Docker aloja cosas relacionadas desde cero y agrega esa máquina a
docker-machine y compile e implemente desde Visual Studio.
Estoy atascado en certificados TLS, etc.

Gracias de antemano por cualquier ayuda.

El jueves 23 de junio de 2016, Pradeep Padala [email protected] escribió:

Acabo de descargar la ventana acoplable para Windows que tiene el 1.12 RC2 que
tiene el 0.8.0-rc1 pero cuando pruebo la opción "azure-os" "windows", sí
no parece funcionar. Por favor, avíseme dónde puedo adquirir una máquina acoplable
versión que puede crear hosts de ventana acoplable TP5 Windows 2016 en Azure.

@SharadGumaste https://github.com/SharadGumaste Supongo que estabas
probando la versión publicada. El parche para soportar Windows (azure-os
opción de Windows) aún no se ha fusionado.

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

"A common mistake people make when trying to design something

completamente infalible es subestimar el ingenio de los tontos ".

– Douglas Adams, author (1952 – 2001)

@SharadGumaste ¿puedes enviar un correo electrónico a [email protected]? Tengo un repositorio separado para docker-machine para Windows, puedo enviarle instrucciones sobre la configuración.

¿Hay alguna noticia sobre la activación de un host de Windows Docker en un VirtualBox local?

¿Alguien tiene un prototipo capaz de poner en marcha máquinas virtuales de Windows en Azure?

@djanosik Estoy trabajando para intentar que la máquina acoplable active el escalado automático de instancias de Windows OpenStack y EC2 para mis compilaciones de CI de GitLab. Tomé la rama de relaciones públicas de https://github.com/davidarcher/machine/tree/azure_winrm .

Seguí las instrucciones de @ jen20 para crear una AMI de Windows con SSH. Funciona con Docker Machine hasta el punto de aprovisionamiento, donde falla porque no hay /etc/os-release archivo