¿Pensando en cocinar algo con Docker estas Navidades? A continuación te dejo una receta muy simple para poner en marcha tu primer container con ASP.NET Core 1.0 y Docker.

Ingredientes:

Tiempo de elaboración: 20 minutos

 

OBSOLETO. ADVERTENCIA: El 28 de enero de 2016, el Readme.md del proyecto DNX se modificó anunciando la retirada de DNX a favor de “dotnet-cli”. Los pasos aquí expuestos funcionan con ASP.NET Core RC1. No se garantiza con que versiones más recientes los pasos aquí expuestos funcionen.

DNX (retired)

The DNX is being retired in favor of the new dotnet CLI command line tools. See:

As a result, we’re not accepting anymore changes to this project. Please file any new issues on http://github.com/dotnet/cli.

ASP.NET Core 1.0 al Docker Container

Paso 0: Abrimos la “Docker QuickStart Terminal”, lo cual creará automáticamente una VM con VirtualBox, y configurará todos los parámetros de entorno necesarios para operar. ¿Todo ha ido bien? Ejecutamos el siguiente comando y validamos que la VM está funcionando:

NOTA: En mi caso, Docker está ejecutándose bajo Parallels Desktop en lugar de VirtualBox, y la máquina se llama prl-dev. En tu caso, seguramente sea VirtualBox y se llame “default”.

En cualquier caso, debe estar en estado “Running”.

Paso 1: Tomamos una aplicación ASP.NET y la abrimos con VS2015 o VSCode. Si no la tenemos, podemos crearla con el asistente de VS2015 o Yeoman:

vscode-dockerized-app

Paso 2: Creamos un archivo “Dockerfile” en la raíz del proyecto e introducimos el siguiente contenido:

Esto indica a Docker que debe utilizar la imagen base proporcionada por Microsoft, copiar el contenido de la carpeta de trabajo (todo el código fuente) a la carpeta “app” del container, establecer la carpeta “app” como nuevo espacio de trabajo, restaurar los paquetes Nuget de la solución, exponer el puerto tcp 5000 y ejecutar el comando “web” de la DNX cada vez que el container arranca.

¿Has creado este sitio utilizando Yeoman? ¡Más fácil entonces! Puedes utilizar el subgenerator siguiente, él hará todo el trabajo sucio (incluyendo el código):

¿Un poco perdido? Entonces creo sería buena idea que dieras un vistazo a este tutorial de conceptos básicos de Docker.

Paso 3: Modificamos el archivo project.json, en su sección “commands”, incluyendo el parámetro “–server.urls http://0.0.0.0:5000” en el comando “web”, para que Kestrel acepte peticiones entrantes desde cualquier host:

Incluir el parámetro –server.urls es vital para que podamos acceder a nuestra web desde fuera del container. Si no lo incluimos, Kestrel rechazará cualquier conexión que no provenga desde el propio Container, algo poco útil…

Paso 4: Lanzamos una consola/terminal, nos ubicamos en la carpeta  y compilamos la imagen docker con el comando “build”, con los siguientes argumentos:

  • -t sesispla/dnxapp: Nombre de la imagen que vamos a crear en Docker
  • . : Utilizamos el directorio de trabajo actual como base para crear la imagen.
Paso 5: Comprobamos que la imagen Docker se ha creado correctamente:
¡Genial, la imagen ya está generada y se ha guardado en nuestra máquina Docker.

Paso 6: Creamos nuestro primer container con esta imagen:

Paso 7: Comprobamos que el Container se está ejecutando:

Paso 8: Abrimos en un navegador la ruta http://docker-ip:90 (donde docker-ip es la dirección ip de tu máquina Docker, en mi caso, http://10.211.55.17:90):

aspnet-docker-running

Bonus tracks

Bonus 1: ¿Quieres crear un segundo container que ejecuta esta misma imagen?

Y abrimos una nueva pestaña de nuestro navegador, abriendo en esta ocasión el puerto 91 (Por ejemplo, http://10.211.55.17:91):

aspnet-docker-running

Bonus 2: ¿Quieres arrancar y parar estas imágenes, una vez creadas? start y stop son tus comandos:

Bonus 3: Listar todos los containers (incluidos aquellos que están detenidos):

FAQ

A: ¿Debo generar una imagen cada vez que se produce un cambio en el código?
Q: Sí.

A: ¿Para fases de desarrollo, puedo utilizar los volúmenes de Docker para referencias la carpeta donde está el código fuente del proyecto, en lugar de generar una imagen del container cada vez que cambio el código?
Q: Sí. Pero en lugar de utilizar Docker para depurar tu proyecto… ¿por qué no utilizas tu propia máquina, y realizas las pruebas de desarrollo sobre ella antes de Dockerizar?

Tagged as: