Proceso de desarrollo de aplicaciones basadas en Docker
Desarrollar aplicaciones .NET contenerizadas de la manera que prefiera, ya sea orientado hacia un IDE con Visual Studio y herramientas de Visual Studio para Docker u orientado a CLI/Editor con Docker CLI y Visual Studio Code.
Ya sea que prefiera un IDE completo y poderoso o un editor ligero y ágil, Microsoft tiene herramientas para desarrollar aplicaciones Docker.
Visual Studio (para Windows). Para desarrollar aplicaciones basadas en Docker con Visual Studio, se recomienda usar Visual Studio 2017 o versiones posteriores, que ya vienen con herramientas integradas para Docker. Las herramientas para Docker le permiten desarrollar, ejecutar y validar las aplicaciones directamente en el entorno Docker de destino. Se puede presionar F5 para ejecutar y depurar la aplicación (contenedor único o contenedores múltiples) directamente en un host Docker, o presione CTRL + F5 para editar y actualizar su aplicación sin tener que reconstruir el contenedor. Esta es la opción de desarrollo más poderosa para las aplicaciones basadas en Docker.
Visual Studio para Mac. Es un IDE, la evolución de Xamarin Studio, que se ejecuta en macOS y es compatible con Docker desde mediados de 2017. Esta debería ser la opción preferida para los desarrolladores que trabajan en Mac, que también quieren usar un IDE poderoso.
Visual Studio Code y CLI de Docker. Para trabajar con un editor liviano y multiplataforma, está Visual Studio Code (VS Code), que permita cualquier lenguaje de desarrollo y la CLI de Docker. Este es un enfoque de desarrollo multiplataforma para Mac, Linux y Windows.
Al instalar la herramienta Docker Community Edition (CE), se puede usar la CLI de Docker para crear aplicaciones tanto para Windows como para Linux.
Como se mencionó en secciones anteriores, se puede usar .NET Framework, .NET Core o el proyecto Mono open source para desarrollar aplicaciones .NET en contenedores Docker. Se Puede desarrollar en C#, F# o Visual Basic cuando se apunta a Contenedores Linux o Windows, dependiendo de cuál framework.NET Framework se utilice. Para obtener más detalles sobre los lenguajes .NET, consulte el artículo de blog The .NET Language Strategy.
El ciclo de vida de desarrollo de la aplicación comienza en la máquina de cada desarrollador, donde se codifica la aplicación con el lenguaje preferido y se prueba localmente. Independientemente del lenguaje, el framework y la plataforma elegida, con este flujo de trabajo, el desarrollador siempre desarrolla y prueba contenedores Docker, pero lo hace de forma local.
Cada contenedor (una instancia de una imagen Docker) incluye los siguientes componentes:
Esta sección describe el flujo de trabajo del bucle interno para el desarrollo de aplicaciones basadas en contenedores Docker. El bucle interno significa que no tiene en cuenta el flujo de trabajo de DevOps más amplio (que puede incluir hasta el despliegue en producción) y sólo se centra en el trabajo de desarrollo realizado en la máquina del desarrollador. No se incluyen los pasos iniciales para configurar el entorno, ya que se realizan sólo una vez.
Una aplicación se compone de los servicios propios más las librerías adicionales (dependencias). Los siguientes son los pasos básicos que por lo general son necesarios para construir una aplicación Docker, como se ilustra en la Figura 5-1.
Figura 5-1. Flujo de trabajo, paso-a-paso para desarrollar aplicaciones Docker contenerizadas
En esta guía se detalla el proceso y se explica cada paso importante, enfocándose en un entorno con Visual Studio.
Cuando se utiliza un entorno de desarrollo con editor/CLI (por ejemplo, Visual Studio Code más CLI de Docker en macOS o Windows), en general necesita conocer cada paso con más detalle que si se usa Visual Studio. Para obtener más información sobre cómo trabajar en un entorno con CLI, consulte el eBook Containerized Docker Application lifecycle with Microsoft Platforms and Tools.
Cuando se usa Visual Studio 2015 o Visual Studio 2017, muchos de esos pasos son manejados por el IDE, lo que mejora drásticamente la productividad. Esto es especialmente cierto cuando usa Visual Studio 2017 y se apunta a aplicaciones de múltiples contenedores. Por ejemplo, con sólo un clic del mouse, Visual Studio agrega los ficheros Dockerfile y docker-compose.yml a los proyectos con la configuración de la aplicación. Cuando se ejecuta la aplicación en Visual Studio, se crea la imagen Docker y se ejecuta directamente en Docker la aplicación multi-contenedores. Incluso permite depurar varios contenedores a la vez. Estas características aumentarán significativamente la velocidad de desarrollo.
Sin embargo, el que Visual Studio haga que esos pasos sean automáticos, no significa que no necesite saber qué está sucediendo debajo con Docker. Por esta razón, a continuación, detallamos cada paso.
Paso 1. Programar la versión inicial de la aplicación o servicio |
Desarrollar una aplicación Docker es similar desarrollar cualquier otra aplicación. La diferencia es que, al desarrollar con Docker, se está desplegando y probando la aplicación o servicios dentro de contenedores Docker en su entorno local (ya sea una configuración de máquina virtual de Linux por Docker o directamente Windows, si usa contenedores de Windows).
Para comenzar, se debe tener instalado el Docker Community Edition (CE) for Windows, como se explica en las siguientes instrucciones:
Get started with Docker CE for Windows
Además, debe estar instalado Visual Studio 2017. Esto es preferible a Visual Studio 2015 con el complemento Visual Studio Tools for Docker, porque Visual Studio 2017 tiene un soporte más avanzado para Docker, por ejemplo, para depuración en contenedores. Visual Studio 2017 incluye las herramientas para Docker cuando se selecciona la carga de trabajo de .NET Core multiplataforma durante la instalación, como se muestra en la Figura 5-2.
Figura 5-2. Seleccionado la carga de trabajo .NET Core and Docker al configurar Visual Studio 2017
Puede comenzar a programar su aplicación en .NET (normalmente en .NET Core si planea usar contenedores) incluso antes de habilitar Docker en la aplicación para despliegue y pruebas. Sin embargo, se recomienda empezar a trabajar en Docker lo antes posible, porque ese será el entorno real y eso ayuda a descubrir cualquier problema lo antes posible. Visual Studio promueve esto, porque hace que trabajar con Docker sea tan fácil que resulte casi transparente, esto se puede apreciar en especial al depurar aplicaciones de varios contenedores desde Visual Studio.
Paso 2. Crear el fichero Dockerfile para una imagen base de .NET existente |
Se necesita un Dockerfile para cada imagen personalizada que se deba construir, también necesita un Dockerfile para cada contenedor que se desplegará, ya sea que despliegue automáticamente desde Visual Studio o manualmente mediante la Docker CLI (comandos docker run y docker-compose). Si la aplicación contiene un servicio único personalizado, se necesita sólo un Dockerfile. Si la aplicación contiene múltiples servicios (como en una arquitectura de microservicios), se necesita un Dockerfile para cada servicio.
El fichero Dockerfile se coloca en la carpeta raíz de la aplicación o servicio. Contiene los comandos que le dicen a Docker cómo configurar y ejecutar la aplicación o servicio en un contenedor. Se puede crear manualmente un fichero Dockerfile en un editor y agregarlo al proyecto junto con sus dependencias .NET.
Con Visual Studio y sus herramientas para Docker, esta tarea requiere sólo unos pocos clics del mouse. Cuando crea un nuevo proyecto en Visual Studio 2017, hay una opción llamada Habilitar el soporte para Docker, como se muestra en la Figura 5-3.
Figura 5-3. Habilitando soporte para Docker al crear un nuevo proyecto en Visual Studio 2017
También puede habilitar el soporte Docker en un proyecto existente haciendo clic derecho en su fichero de proyecto en Visual Studio y seleccionando la opción Add > Docker Support, como se muestra en la Figura 5-4.
Figure 5-4. Habilitando soporte para Docker en un proyecto ASP.NET Core existente en Visual Studio 2017
Al hacer esto en un proyecto (como una aplicación web ASP.NET o un servicio API web) se agrega el fichero Dockerfile al proyecto con la configuración necesaria. También se agrega un fichero docker-compose.yml para toda la solución. En las siguientes secciones, describimos la información que se incluye en cada uno de esos ficheros. Aunque Visual Studio se puede encargar de este trabajo, es útil entender qué entra en un Dockerfile.
Por lo general, se crea una imagen personalizada para su contenedor sobre una imagen base que puede obtener de un repositorio oficial en el registro de Docker Hub. Eso es precisamente lo que sucede por debajo cuando se habilita el soporte para Docker en Visual Studio. El fichero Dockerfile usará una imagen aspnetcore existente.
Anteriormente explicamos qué imágenes y repositorios Docker se pueden usar, según el framework y el sistema operativo seleccionado. Por ejemplo, para usar ASP.NET Core (Linux o Windows), la imagen a usar es microsoft/aspnetcore: 2.0. Por lo tanto, sólo necesita especificar cuál imagen base Docker usará para el contenedor. Para hacerlo, agregue FROM microsoft/aspnetcore: 2.0 a su Dockerfile. Esto será realizado automáticamente por Visual Studio, pero si se tuviera que actualizar la versión, este valor que se cambia.
El uso de un repositorio de imágenes .NET oficial de Docker Hub, con un número de versión, garantiza que estén disponibles las mismas funciones del lenguaje en todas las máquinas (incluyendo desarrollo, pruebas y producción).
El siguiente ejemplo muestra un fichero Dockerfile de ejemplo para un contenedor ASP.NET Core.
FROM microsoft/aspnetcore:2.0 ARG source WORKDIR /app EXPOSE 80 COPY ${source:-obj/Docker/publish} . ENTRYPOINT ["dotnet", " MySingleContainerWebApp.dll "] |
En este caso, el contenedor se basa en la versión 2.0 de la imagen oficial de ASP.NET Core Docker (multi-arch para Linux y Windows). Esta es la configuración FROM microsoft/aspnetcore: 2.0. (Para obtener más detalles sobre esta imagen base, consulte las páginas ASP.NET Core Docker Image y .NET Core Docker Image.) En el fichero Dockerfile, también debe indicar a Docker el puerto TCP que se utilizará en tiempo de ejecución (en este caso, el puerto 80, como se indica con la configuración EXPOSE).
Se pueden especificar opciones de configuración adicionales en el fichero Dockerfile, según el lenguaje y el framework que esté utilizando. Por ejemplo, la línea ENTRYPOINT con ["dotnet", "MySingleContainerWebApp.dll"] le dice a Docker que ejecute una aplicación .NET Core. Si se estuviese utilizando el SDK y la CLI .NET (dotnet CLI) para compilar y ejecutar la aplicación .NET, esta configuración sería diferente. La conclusión es que la línea ENTRYPOINT y otras opciones serán diferentes según el lenguaje y la plataforma que seleccionada para la aplicación.
Un repositorio puede contener variantes por plataforma, como una imagen Linux y otra Windows. Esto permite a los proveedores como Microsoft (creadores de imágenes base) crear un solo repositorio para cubrir múltiples plataformas (es decir, Linux y Windows). Por ejemplo, el repositorio microsoft/aspnetcore disponible en el registro de Docker Hub proporciona soporte para Linux y Windows Nano Server utilizando el mismo nombre de repositorio.
Se puede especificar una etiqueta que apunte a una plataforma explícita como en los siguientes casos:
microsoft/aspnetcore:2.0.0-jessie |
.NET Core 2.0 runtime-only on Linux |
microsoft/dotnet: 2.0.0-nanoserver |
.NET Core 2.0 runtime-only on Windows Nano Server |
Pero, y esto es nuevo desde mediados de 2017, si especifica el mismo nombre de imagen, incluso con la misma etiqueta, las nuevas imágenes multi-arch (como la imagen mencionada de aspnetcore) usarán la versión Linux o Windows dependiendo en el sistema operativo del host Docker donde se esté desplegando, como se muestra en el siguiente ejemplo:
microsoft/aspnetcore:2.0 |
.NET Core 2.0 runtime-only on Linux or Windows Nano Server depending on the Docker host OS |
De esta forma, cuando extrae una imagen de un host de Windows, extraerá la variante de Windows y, al extraer la imagen (con el mismo nombre) de un host de Linux, se extraerá la variante de Linux.
Se puede crear una imagen base Docker desde cero. Este escenario no se recomienda para alguien que está comenzando con Docker, pero si desea usar la versión específica de su propia imagen base, puede hacerlo.
Paso 3. Crear imágenes Docker personalizadas e incluir la aplicación o servicio en ellas |
Para cada servicio de la aplicación, se debe crear una imagen relacionada. Si la aplicación se compone de un solo servicio o aplicación web, sólo necesita una imagen.
Hay que tener en cuenta que las imágenes Docker se crean automáticamente en Visual Studio. Los siguientes pasos sólo son necesarios para el entorno de trabajo con editor/CLI y se explican para aclarar qué sucede por debajo.
Durante el desarrollo se necesita programar y probar localmente hasta que se guarde el cambio o característica completa en sistema de control de versiones (por ejemplo, a GitHub). Esto significa que se deben crear las imágenes de Docker e implementar contenedores en un host Docker local (VM de Windows o Linux) y ejecutar, probar y depurar contra esos contenedores locales.
Para crear una imagen personalizada en el entorno local mediante Docker CLI y el Dockerfile, se puede usar el comando docker build, como en la Figura 5-5.
Figura 5-5. Creando una imagen Docker personalizada
Opcionalmente, en lugar de ejecutar directamente Docker Build desde la carpeta del proyecto, se puede generar primero una carpeta de despliegue con las librería y binarios .NET necesarios ejecutando dotnet publish y luego usar el comando docker build.
Esto creará una imagen Docker con el nombre cesardl/netcore-webapi-microservice-docker: first. En este caso, first es una etiqueta que representa una versión específica. Se puede repetir este paso para cada imagen personalizada que se necesite crear para una aplicación Docker compuesta.
Cuando una aplicación se compone de varios contenedores (es decir, es una aplicación multi-contenedor), también se puede usar el comando docker-compose up --build para compilar todas las imágenes relacionadas con un solo comando, usando los metadatos expuestos en los ficheros docker-compose.yml relacionados.
Se pueden encontrar las imágenes existentes en el repositorio local con el comando docker images, como se muestra en la Figura 5-6.
Figura 5-6. Consultando las imágenes existentes con el comando docker images
Cuando se usa Visual Studio para crear un proyecto con soporte para Docker, no es necesario crear la imagen explícitamente. En cambio, la imagen se crea automáticamente al presionar F5 y se ejecuta la aplicación o servicio contenerizado. Este paso es automático en Visual Studio y no lo verá, pero es importante que sepa lo que está sucediendo por debajo.
Paso 4. Definir los servicios en docker-compose.yml al construir aplicaciones multi-contenedor |
El fichero docker-compose.yml permite definir un conjunto de servicios relacionados que se desplegarán como una aplicación compuesta, con comandos de despliegue.
Para usar un fichero docker-compose.yml, debe crearlo en la carpeta raíz de la solución principal, con un contenido similar al del siguiente ejemplo:
version: '3'
services:
webmvc:
image: eshop/web
environment:
- CatalogUrl=http://catalog.api
- OrderingUrl=http://ordering.api
ports:
- "80:80"
depends_on:
- catalog.api
- ordering.api
catalog.api:
image: eshop/catalog.api
environment:
- ConnectionString=Server=sql.data;Port=1433;Database=CatalogDB;…
ports:
- "81:80"
depends_on:
- postgres.data
ordering.api:
image: eshop/ordering.api
environment:
- ConnectionString=Server=sql.data;Database=OrderingDb;…
ports:
- "82:80"
extra_hosts:
- "CESARDLBOOKVHD:10.0.75.1"
depends_on:
- sql.data
sql.data:
image: mssql-server-linux:latest
environment:
- SA_PASSWORD=Pass@word
- ACCEPT_EULA=Y
ports:
- "5433:1433"
Tenga en cuenta que este fichero docker-compose.yml es una versión simplificada y combinada (con varios contenedores). Contiene datos estáticos de configuración para cada contenedor (como el nombre de la imagen personalizada), que siempre aplican, además de la información de configuración que puede depender del entorno de despliegue, como la cadena de conexión. En secciones posteriores, veremos cómo puede dividir la configuración de docker-compose.yml en varios ficheros docker-compose y sobreescribir valores según el entorno y el tipo de ejecución (depuración o publicación).
En el fichero docker-compose.yml del ejemplo, se definen cinco servicios: el servicio webmvc (una aplicación web), dos microservicios (ordering.api y basket.api) y un contenedor de fuente de datos, sql.data, basado en SQL Server para Linux que se ejecuta como un contenedor. Cada servicio se implementará como un contenedor, por lo que se requiere una imagen Docker para cada uno.
El fichero docker-compose.yml especifica no solo qué contenedores se están utilizando, sino cómo se configuran individualmente. Por ejemplo, la definición del contenedor webmvc en el fichero .yml:
Revisaremos nuevamente el fichero docker-compose.yml más adelante, cuando veamos cómo implementar microservicios y aplicaciones multi-contenedor.
Cuando se agrega soporte Docker a un proyecto en una solución de Visual Studio, como se muestra en la Figura 5-7, Visual Studio agrega un fichero Dockerfile al proyecto y agrega una sección de servicios (un proyecto) en la solución con los ficheros docker-compose.yml. Esto facilita comenzar a componer una solución de contenedores múltiples. A continuación, puede abrir los ficheros docker-compose.yml y actualizarlos con funciones adicionales.
Figura 5-7. Añadiendo soporte para Docker en Visual Studio 2017 con click-derecho en un proyecto ASP.NET Core
Después de agregar soporte para Docker a la solución en Visual Studio, también se agrega un nuevo nodo (en el fichero de proyecto docker-compose.dcproj) en el Solution Explorer, que contiene los ficheros docker-compose.yml agregados, como se muestra en la Figura 5- 8.
Figura 5-8. El nodo docker-compose añadido al Solution Explorer en Visual Studio 2017
Se puede desplegar una aplicación multi-contenedor con un fichero único docker-compose.yml usando el comando docker-compose up. Sin embargo, Visual Studio agrega un grupo de ellos para que sea más fácil reemplazar los valores según el entorno (desarrollo versus producción) y el tipo de ejecución (ejecución versus depuración). Esta facilidad se explicará en secciones posteriores.
Paso 5. Construir y ejecutar la aplicación Docker |
Si la aplicación sólo tiene un contenedor único, se puede ejecutar desplegándolo en un host Docker (máquina virtual o servidor físico). Sin embargo, si la aplicación contiene múltiples servicios, se puede desplegar como una aplicación compuesta, ya sea utilizando un único comando CLI (docker-compose up) o con Visual Studio, que utilizará ese comando por debajo. Veamos las diferentes opciones.
Se puede ejecutar un contenedor Docker usando el comando docker run, como se muestra en la Figura 5-9:
docker run -t -d -p 80:5000 cesardl/netcore-webapi-microservice-docker:first |
Figura 5-9. Ejecutando un contenedor Docker con el comando docker run
En este caso, el comando vincula el puerto interno 5000 del contenedor al puerto 80 del host. Esto significa que el host está escuchando en el puerto 80 y reenviando al puerto 5000 en el contenedor.
En la mayoría de los escenarios empresariales, una aplicación Docker estará compuesta por múltiples servicios, lo que significa que se debe ser multi-contenedor, como se muestra en la Figura 5-10.
Figura 5-10. Máquina virtual con contenedores Docker desplegados
Para ejecutar una aplicación multi-contenedor con Docker CLI, se puede ejecutar el comando docker-compose up. Este comando usa el fichero docker-compose.yml, que está a nivel de la solución, para desplegar una aplicación multi-contenedor. La Figura 5-11 muestra los resultados al ejecutar el comando desde el directorio principal de la solución, que contiene el fichero docker-compose.yml.
Figura 5-11. Ejemplo de resultados cuando se ejecuta el comando docker-compose up
Cuando se ejecuta el comando docker-compose up, la aplicación y sus contenedores relacionados se despliegan en el host Docker, como se ilustra en la representación de máquina virtual en la figura 5-10.
No podría ser más sencillo ejecutar una aplicación multi-contenedor con Visual Studio 2017. No sólo se puede ejecutar la aplicación multi-contenedor, sino que también se pueden depurar todos sus contenedores directamente desde Visual Studio estableciendo break-points comunes y corrientes.
Como se mencionó anteriormente, cuando se agrega soporte para Docker a un proyecto, dentro de una solución, ese proyecto se configura en el fichero global docker-compose.yml (a nivel de solución), que permite ejecutar o depurar toda la solución a la vez. Visual Studio iniciará un contenedor para cada proyecto que tenga habilitada la compatibilidad con Docker y realizará todos los pasos internos necesarios (dotnet publish, docker build, etc.).
El punto importante aquí es que, como se muestra en la Figura 5-12, en Visual Studio 2017 hay un comando Docker adicional para la tecla F5. Esta opción permite ejecutar o depurar una aplicación de varios contenedores, ejecutando todos los contenedores definidos en los ficheros docker-compose.yml a nivel de la solución. La capacidad de depurar soluciones de varios contenedores significa que se pueden establecer varios break-points, uno en cada proyecto diferente (contenedor) y, al depurar desde Visual Studio, se detendrá en puntos definidos en los diferentes proyectos y ejecutándose en los contenedores diferentes.
Figura 5-12. Ejecutando aplicaciones multi-contenedores con Visual Studio 2017
Los comandos docker-compose up y docker run (o ejecutar y depurar los contenedores en Visual Studio) son adecuados para probar contenedores en el entorno de desarrollo. Pero no se debe usar este enfoque cuando el objetivo es desplegar en clusters Docker y orquestadores como Docker Swarm, Mesosphere DC/OS o Kubernetes. Si está utilizando un cluster como Docker en modo Swarm (disponible en Docker CE para Windows y Mac desde la versión 1.12), se debe desplegar y probar con comandos adicionales como docker service create para servicios individuales. Si está desplegando una aplicación multi-contenedor, se deben usar los comandos docker compose bundle y docker deploy myBundleFile para implementar la aplicación compuesta como un stack. Para obtener más información, consulte el artículo Introducing Experimental Distributed Application Bundles en el blog de Docker.
Para DC/OS y Kubernetes también se usarían comandos y scripts de despliegue diferentes.
Paso 6. Probar la aplicación Docker en el host Docker local |
Este paso variará dependiendo de lo que haga la aplicación. En una aplicación web .NET Core simple, que se despliega como un solo contenedor o servicio, se puede acceder al servicio abriendo un navegador en el host Docker y navegando hacia el sitio como se muestra en la Figura 5-13. (Si la configuración en el fichero Dockerfile mapea el contenedor a un puerto en el host que no sea 80, se debe incluir la publicación de host en la URL).
Figura 5-13. Ejemplo de pruebas locales de la aplicación Docker usando localhost
Si localhost no está apuntando a la IP del host Docker (es el valor por defecto al usar Docker CE), para navegar a su servicio, use la dirección IP del adaptador de red de su máquina.
Tenga en cuenta que esta URL en el navegador usa el puerto 80 para el ejemplo. Sin embargo, internamente, las peticiones se redireccionan al puerto 5000, porque así fue como se desplegó con el comando docker run, como se explicó en un paso anterior.
También se puede probar la aplicación utilizando curl desde una ventana de terminal, como se muestra en la Figura 5-14. En una instalación de Docker en Windows, la IP predeterminada del host es siempre 10.0.75.1, además de la dirección IP real de su máquina.
Figura 5-14. Ejemplo de pruebas locales de la aplicación Docker usando curl
Al ejecutar y depurar contenedores con Visual Studio 2017, se puede depurar la aplicación .NET de la misma forma como lo haría al ejecutarla sin contenedores.
Si se está desarrollando con el enfoque editor/CLI, la depuración de contenedores es más difícil y tendrá que hacerlo generando trazas.
El flujo de trabajo al usar Visual Studio es mucho más simple y eficiente que con el enfoque editor/CLI. La mayoría de los pasos requeridos por Docker, relacionados con los ficheros Dockerfile y docker-compose.yml, están ocultos o simplificados por Visual Studio, como se muestra en la Figura 5-15.
Figura 5-15. Proceso simplificado cuando se usa Visual Studio
Además, sólo necesita realizar el paso 2 (agregar soporte Docker a sus proyectos) una vez. Por lo tanto, el flujo de trabajo es similar a las tareas habituales cuando usa .NET para cualquier otro desarrollo. Sin embargo, es necesario saber qué sucede por debajo (el proceso de creación de imágenes, qué imágenes base está utilizando, despliegue de contenedores, etc.) y, a veces, también necesitará editar el fichero Dockerfile o docker-compose.yml, para personalizar los comportamientos. Pero la mayoría del trabajo se simplifica enormemente al usar Visual Studio, lo que le hace mucho más productivo.
Los Contenedores de Windows le permiten convertir sus aplicaciones de Windows existentes en imágenes Docker y desplegarlas con las mismas herramientas que el resto del ecosistema de Docker. Para usar Contenedores de Windows, incluya los comandos de PowerShell en el fichero Dockerfile, como se muestra en el siguiente ejemplo:
FROM microsoft/windowsservercore LABEL Description="IIS" Vendor="Microsoft" Version="10" RUN powershell -Command Add-WindowsFeature Web-Server CMD [ "ping", "localhost", "-t" ] |
En este caso, estamos utilizando una imagen base de Windows Server Core (la configuración FROM) e instalando IIS con un comando de PowerShell (la configuración RUN). De manera similar, también podría usar los comandos de PowerShell para configurar componentes adicionales como ASP.NET 4.x, .NET 4.6 o cualquier otro software de Windows. Por ejemplo, el siguiente comando en un Dockerfile configura ASP.NET 4.5:
RUN powershell add-windowsfeature web-asp-net45 |