En primer lugar, contamos con la participación de Ignacio Sánchez y Ramón Román de atSistemas donde me quedo sin duda con su clúster de Raspberry Pi integrado con los nuevos pipelines de Jenkins 2.0. Media hora de sesión donde ver cómo emplear Docker Swarm para la gestión de clústeres basados en Docker y la instanciación de aplicaciones basadas en microservicios. Muy útil las nuevas capacidades incorporadas en Swarm para reinstanciar los contenedores en otro nodo si el host se cae.
Tras ellos, por mi parte hice una breve introducción a cómo se encuentra el ecosistema de Docker en entornos basados en Windows. Desde los avances en Docker for Windows con Kitematic para permitirte trabajar con Docker directamente en Windows 10 con Hyper-V de forma sencilla, hasta los cambios que están llegando en la parte de Windows Server con la implementación a nivel del núcleo del soporte a contenedores.
En artículos anteriores ya he estado haciendo una introducción de qué es Docker y cómo empezar a usarlo desde nuestros equipos con Windows o a través de Microsoft Azure. Sin embargo, para los usuarios acostumbrados a trabajar con Windows Server, no suele ser sencillo comprender las nuevas posibilidades que ofrece y cómo funciona. A través de Twitter llegué al blog de Richard Seroter donde recopilaba una buena colección de preguntas y respuesta enfocadas a aquellos usuarios que usan Windows. Tras pedirle permiso para adaptarlo al español os dejo a continuación con la colección de preguntas y respuestas.
Por lo tanto, ya sólo nos queda mostrar cómo desplegar alguna aplicación en un contenedor dentro de la instancia de Docker que tenemos ejecutándose en Azure. Podríamos probar con un simple comando imprimiendo un “Hola Mundo” pero aprovechando que de versiones alfa anda el juego, vamos a desplegar una aplicación ASP.Net vNext que tras los últimos anuncios ya es posible ejecutarlo en entornos Mac OSX y Linux también.
Obteniendo nuestra aplicación de ejemplo
En primer lugar vamos a buscar la aplicación de ejemplo que queremos desplegar. Podríamos escribirla nosotros mismos desde cero o, por el contrario, optimizar el tiempo y hacer uso de alguno de los ejemplos disponibles. Si accedemos al repositorio de GitHub del equipo de ASP.Net veremos que tenemos disponible el código fuente. Dentro de los ficheros existe la carpeta de Samples donde tenemos tres ejemplos de aplicación. De todos ellos, usaremos el de HelloMVC.
Para descargarlo tenemos dos opciones, descargar el fichero .zip disponible en GitHub con todo el código fuente del repositorio o clonar el repositorio con el siguiente comando:
git clone https://github.com/aspnet/Home.git
git clone https://github.com/aspnet/Home.git
Tanto con una opción como con la otra tendremos en nuestro ordenador una copia de los ficheros que necesitamos.
Preparando la imagen de Docker
A la hora de configurar nuestra imagen para ser ejecutada en el contenedor podemos seguir dos caminos: realizarlo de forma manual o utilizar un fichero específico, DockerFile , para que Docker lo haga por nosotros. En esta ocasión emplearemos esta segunda opción para simplificar el proceso.
Lo primero será crear nuestro fichero DockerFile. Lo podemos hacer directamente desde nuestro bloc de notas. Dentro de él iremos definiendo los pasos necesarios para desplegar nuestra aplicación.
Desde Microsoft se ha preparado una imagen base que se puede emplear como plantilla para generar las nuestras propias. Está disponible en el repositorio bajo el nombre microsoft/aspnet. Esta imagen se encarga de configurar todos los elementos necesarios para tener un entorno de ASP.Net vNext. Si tenemos curiosidad podemos ver el contenido de su DockerFile.
Por lo tanto, la primera línea de nuestro DockerFile será la siguiente.
FROM microsoft/aspnet
FROM microsoft/aspnet
Tras ello, necesitaremos copiar los ficheros que forman nuestra aplicación web dentro del contenedor. A día de hoy la versión alfa del cliente de Windows para Docker no gestiona correctamente las rutas de ficheros, es necesario pararlo como un fichero comprimido. Por ello, comprimiremos nuestra carpeta HelloMVC en formato .tar con 7-Zip. El comando ADD es capaz de reconocer los ficheros .tar entre otros y descomprimirlos. Además de copiarlos, a continuación navegaremos dentro de la carpeta app para continuar con la configuración de la imagen.
Traducido lo anterior a nuestro DockerFile quedaría como lo siguiente.
ADD HelloMvc.tar /app/
WORKDIR app
ADD HelloMvc.tar /app/
WORKDIR app
Una vez que tenemos nuestra aplicación copiada necesitamos restaurar las dependencias con los paquetes de NuGet que tiene. Esto lo permite gestionar el comando kpm que se incluye con ASP.Net vNext. En nuestro DockerFile necesitaremos incorporar lo siguiente.
RUN kpm restore
RUN kpm restore
Por último necesitamos exponer un extremo de nuestro contenedor a través del cual accederemos a nuestra aplicación web y configurar la image para que al ser ejecutada inicialice el servidor web de ASP.Net vNext: k. Por lo tanto, las últimas líneas de nuestro DockerFile serán las siguientes.
EXPOSE 5004
ENTRYPOINT ["k", "kestrel"]
EXPOSE 5004
ENTRYPOINT ["k", "kestrel"]
DockerFile para nuestra aplicación ASP.Net vNext
El último paso será construir nuestra imagen. Para el comando siguiente suponemos que nuestro fichero DockerFile y HelloMVC.tar se encuentran dentro de nuestra carpeta HelloMVC.
Carpeta de ejemplo de la aplicación
Si no es así tendremos que adaptar el siguiente comando para que se ajuste a nuestra ruta. De todo el comando, la última parte es la que nos interesa, lo otro únicamente define los parámetros de la conexión usando HTTPs como mencionaba en el artículo anterior.
Tras ello nuestra imagen comenzará a obtener los ficheros que necesita de forma automática. Esperaremos hasta que termine antes de continuar.
Creación de nuestra imagen personalizada para ASP.NET vNext
Una vez que haya finalizado solo nos quedará ejecutar la imagen dentro de un contenedor y nuestro sitio web estará disponible.
docker.exe --tlsverify--tlscacert="C:\Users\jangelfdez\Desktop\ca-public-key.pem"--tlscert="C:\Users\jangelfdez\Desktop\client-cert.pem"--tlskey="C:\Users\jangelfdez\Desktop\client-private-key.pem"-H=jangelfdez.cloudapp.net:2376 run -d-t-p8080:5004 myaspnetvnextapp
Comentaba en el artículo anterior que activar el extremo de escucha HTTP en Docker para que otras máquinas de la red pudieran acceder al motor no era una buena práctica. Esto se debe a que al habilitarlo estamos dando acceso a cualquier persona que conozca la combinación de IP y puerto donde tenemos nuestra instancia de Docker en ejecución. Para protegerlo será necesario configurar Docker para que haga uso de la conexión a través de HTTPs.
El proceso de configuración no es trivial ya que lleva involucrado la creación de certificados para el servidor y los diferentes clientes que se conecten. Gracias a ellos, es posible establecer una relación de confianza entre ambos extremos de la conexión y así, en el caso de que otra persona se intente conectar sin disponer de los certificados correctos, el motor de Docker rechazará la conexión. Para crearlos necesitaremos trabajar con OpenSSL dentro de nuestra máquina con Linux.
A la hora de trabajar con sistemas de clave pública es necesario tener mucho cuidado en la configuración y gestión de su información como las claves privadas. Este artículo no entra en detalles de cómo montar una buena solución basada en OpenSSL, únicamente emplea los elementos necesarios para mostrar la configuración del acceso por HTTPs en Docker
Tras esta pequeña advertencia comenzamos.
Creando nuestra entidad certificadora
Para tener un poco ordenada la información relacionado con este proceso de generar los certificados trabajaremos con un directorio a nivel local de nuestro usuario. Dentro del mismo, crearemos varias subcarpetas para guardar los diferentes ficheros involucrados ref. En la primera guardaremos los certificados emitidos, en la segunda las peticiones para generar nuevos certificados, en la tercera la lista de revocación de certificados y por último, la que contendrá la información privada de nuestra CA. Necesitaremos protegerla para evitar el acceso por otros usuarios.
En el siguiente paso, crearemos los dos ficheros necesarios por nuestra entidad certificadora. El fichero index.txt es empleado por OpenSSL para llevar un listado de los certificados firmados y el fichero ca.srl los números de serie. Ambos forman la base de datos de nuestra entidad.
cd CA
echo"01"> ca.srl
touch index.txt
cd CA
echo "01" > ca.srl
touch index.txt
Tras ello, generaremos nuestra clave RSA privada de tamaño 2048 bits. Durante el proceso nos pedirá la clave de paso que queremos usar para protegerla.
El siguiente paso será obtener la clave pública de nuestra entidad certificadora. Los campos que nos piden los podemos completar con nuestra información correcta o no, según deseamos. El que será importante será el definir el FQDN de nuestro servidor.
Una vez que hemos terminado con nuestra entidad certificadora nos toca configurar ahora el certificado para nuestro motor de Docker. Para ello, tendremos que generar una nueva clave privada de forma similar a lo que hemos hecho anteriormente. Necesitaremos introducir una nueva clave de paso para protegerla.
Una vez que la tenemos el siguiente paso es solicitar una petición de firma de nuestro certificado, también conocido como Certificate Signing Request . Es muy importante sustituir el parámetro CN, Common Name, por el nombre del servidor al que nos conectaremos. En mi caso será jangelfdez.cloudapp.net. Será necesario introducir la clave que hemos definido en el paso anterior.
Este proceso será muy parecido al del apartado anterior, la única diferencia será que necesitaremos configurar una de las extensiones del certificado para que permita ser utilizado para autenticación. Por lo tanto, comenzamos creando la clave privada y generando la petición de firma de nuestro certificado.
Una vez que lo tenemos, configuramos la extensión para autenticación. Únicamente será necesario definir una pareja clave-valor y pasarle el fichero a la hora de firmar la petición.
La parte complicada ya la hemos terminado, ahora necesitaremos dos cosas más antes de tener listo el acceso por HTTPs. En primer lugar, eliminar la frase de paso de las claves de nuestro cliente y servidor.
El servidor ya está configurado correctamente para aceptar únicamente peticiones a través de HTTPs y que se autentiquen con un certificado firmado por nuestra autoridad certificadora en el puerto 2376. Por lo tanto, faltará a nuestro cliente indicarle que queremos utilizar este tipo de autenticación lanzándolo con los siguientes parámetros.
docker.exe --tlsverify--tlscacert="C:\Users\jangelfdez\Desktop\ca-public-key.pem"--tlscert="C:\Users\jangelfdez\Desktop\client-cert.pem"--tlskey="C:\Users\jangelfdez\Desktop\client-private-key.pem"-H=jangelfdez.cloudapp.net:2376 info
docker.exe --tlsverify --tlscacert="C:\Users\jangelfdez\Desktop\ca-public-key.pem" --tlscert="C:\Users\jangelfdez\Desktop\client-cert.pem" --tlskey="C:\Users\jangelfdez\Desktop\client-private-key.pem" -H=jangelfdez.cloudapp.net:2376 info
Y con ello tendremos nuestro cliente desde Windows 10 conectado a nuestro motor de Docker a través de HTTPs.
El siguiente paso consiste en probar la comunicación entre ambos extremos. Por defecto, Docker escucha las conexiones entrantes a través del siguiente socket unix:///var/run/docker.sock. La única conexión permitida será a nivel local accediendo con el usuario root. Sin embargo, para hacer esta prueba rápida vamos a ver cómo modificarlo para que escuche en un puerto TCP y nos podamos conectar desde otras IPs.
Es muy importante tener en cuenta que esto habilita el acceso a nuestro motor de Docker a cualquier persona que conozca la combinación de IP y puerto, por ello no lo debemos realizar nunca fuera de entornos de prueba.
Para ello, lanzaremos el demonio de Docker pasánadole el parámetro -H donde especificaremos que escuche a través de TCP en el puerto que le indiquemos.
$ sudo docker -H 0.0.0.0:2375-d&
$ sudo docker -H 0.0.0.0:2375 -d &
Arrancando el motor de Docker
Ahora, podremos conectarnos desde nuestro cliente Windows y mostrar la información de nuestro servidor:
Cliente de Docker en Windows
Lo siguiente será configurarlo utilizando HTTPs para permitir la conexión segura desde otros equipos fuera de la red local como el ordenador en mi oficina y el servidor desplegado en Azure.
La firma del acuerdo colaboración entre Docker y Microsoft anunciada a mediados de octubre de este año va a traer dos piezas importantes de Docker a los entornos Windows. En primer lugar, la disponibilidad del engine de Docker en Windows Server para poder desplegar contenedores de una forma similar a la que se realizar a día de hoy en Linux/Unix. Y en segundo, la disponibilidad del cliente de Docker para Windows con lo que no necesitaremos ya soluciones como Boot2Docker para trabajar con él.
En primer lugar necesitaremos tener instalado en nuestra máquina Go, el lenguaje de programación. Si no lo tenemos, desde la página del proyecto podemos descargarnos el instalador para Windows y completar este primer paso.
Descargar instalador Go
Una vez que lo tengamos, necesitamos comprobar que funciona de forma correcta ejecutando el comando go en nuestra consola.
Go ejecutado desde PowerShell
Tras ello, necesitaremos Git para podernos descargar el código fuente del cliente y proceder a compilarlo en nuestra máquina. Si no lo tienes disponible, también podemos bajarlo desde la página oficial de Git.
Instalación de Git para Windows
Una vez que lo tengamos, comprobaremos también que funciona correctamente.
Git ejecutándose en Windows
Tras cumplir con los dos requisitos previos ya estamos preparados para obtener el código y compilarlo. Para ello, clonaremos el repositorio de Docker disponible de forma pública en GitHub.
Una vez clonado, configuramos las siguientes variables de entorno para definir dónde se puede encontrar el compilador de Go y activar la flag del proceso de compilación que sólo habilitará el proceso que genera la parte cliente de Docker. A día de hoy no existe aún la parte de servidor.
setGOPATH=c:\go;c:\go\src\github.com\docker\docker\vendor
setDOCKER_CLIENTONLY=1cd c:\go\src\github.com\docker\docker\docker
go build -v
set GOPATH=c:\go;c:\go\src\github.com\docker\docker\vendor
set DOCKER_CLIENTONLY=1
cd c:\go\src\github.com\docker\docker\docker
go build -v
Compilando el cliente de Docker en Windows
Si has seguido todos los pasos de forma correcta ya tendrás disponible tu cliente de Docker en Windows para empezar a trabajar con él de forma similar a como lo realizas ya en Linux/Unix.
Es recomendable usar el enlace de descarga disponible dentro de la columna de “Descargar archivo único” en lugar de la opción de “Descargar” dentro del botón azul si no deseas usar el administrador de transferencia de ficheros. Dichero ejecutable incluye dos ficheros:
GalileoWatcher.exe: es una utilidad para detectar la placa conectada a la red o al ordenador y extraer información básica de la misma como su dirección IP y su nombre.
Windows Developer Program for IoT.vsix: es la extensión de Visual Studio que añade soporte al desarrollo de proyectos basados en la placa galileo.
Para completar la instalación únicamente necesitas seguir el asistente que se abre cuando ejecutas el fichero .msi.
A continuación, saltará la UAC dos veces para que apruebes la instalación de la extensión y del otro programa.
Tras ello, solo tienes que abrir Visual Studio para tener listo tu proyecto C++ para comenzar con ello:
Otra herramienta que resultará útil es el cliente de Telnet para acceder de forma remota a nuestra placa y poder interactuar con ella. Para ello, únicamente necesitas seguir los siguientes pasos extraídos de la librería de TechNet:
Haga clic en Inicio y, a continuación, haga clic en Panel de control.
En la página Ventana principal del Panel de control, haga clic en Programas.
En la sección Programas y características, haga clic en Activar o desactivar las características de Windows.
Si aparece el cuadro de diálogo Control de cuentas de usuario, confirme que la acción que muestra es la que desea y, a continuación, haga clic en Continuar.
En la lista Características de Windows, seleccione Cliente Telnet y, a continuación, haga clic en Aceptar
Ahora a seguir esperando por una placa para las pruebas. Por ahora, ya han comenzado a enviarlas
Just received…”We are pleased to share that your Windows Developer Program for IoT Kit has been shipped” :-) #winbuilder#windowsondevices — Paolo Patierno (@ppatierno) julio 16, 2014
Empezar a escribir algo siempre lleva una cierta resistencia, sobre todo cuando es con una pantalla en blanco y encima el artículo inicial del blog. Al final terminas dejándolo a un lado en busca del tiempo o la idea con la que ponerte a escribir. Creo que ese día llegó aprovechando el lanzamiento del programa para desarrolladores de Windows para el Internet de las Cosas, más conocido como el Internet of Things (IoT). En abril, en la primera keynote del Build se presentó esta nueva línea de trabajo para ofrecer la opción a los desarrolladores de poder hacer aplicaciones para esta nueva serie de dispositivos.
Sin embargo, no tiene por qué ser solo para desarrolladores. Aquellos como yo que les guste en el punto medio entre los cacharros de hardware y el software que los controla les va a resultar seguramente interesante. Rafa Serna escribía una muy buena introducción a lo que consistía Windows para el IoT. Con este artículo yo únicamente quería aclarar un poco qué pasos son necesarios para empezar a conocer más detalles de este nuevo sistema. La página clave es http://www.windowsondevices.com; sin embargo, a partir de ahí puede resultar más confuso qué es necesario realizar. Por lo tanto estos son los pasos:
Seguro que quieres tener algo de hardware para probar. Si es así, accede a http://www.windowsondevices.com/signup.aspx para completar tu solicitud de una placa Intel Galileo. Hay más solicitudes que placas disponibles por lo que es posible que no todos podamos recibir una.
Y con esto, más o menos tendrías todo listo para empezar a trabajar con esta nueva plataforma. Ahora solo queda esperar que nos llegue una placa para probarlo.
