Si desarrollas con Docker es probable que uses multi-stage builds para crear tus contenedores, en este caso unificas bajo un mismo Dockerfile la creación del binario (usando una imagen de compilación) y la creación de la imagen final (basandote en una imagen de runtime).
Ahora bien, si usas un pipeline de CI/CD con VSTS… ¿como gestionar los tests de esos contenedores? Eso es lo que vamos a discutir en este post.
Cuando desarrollamos una aplicación en asp.net core que queremos terminar ejecutando con Docker, el como gestionar la configuración puede causarnos más de un quebradero de cabeza.
En este post voy a comentar, brevemente, como podemos gestionar varios escenarios de configuración.
Buenas! Imagina que tienes una aplicación hecha en Asp.Net Core y que referencia al metapaquete Microsoft.AspNetCore.All. También tienes un Dockerfile y un fichero compose para generar la imagen usando una multi-stage build.
La imagen se genera sin problemas pero al ejecutarla recibes un error y no arranca.
Seguimos con esta serie de posts sobre Kubernetes. Los posts anteriores:
En este tercer post veremos que son los recursos ingress y los controladores ingress y que ventajas nos aportan.
Si conoces compose conocerás su “modelo de aplicación”. Es un modelo sencillo, contiene básicamente servicios. Un servicio en compose no es nada más que una imagen de Docker y su configuración asociada. Luego cuando levantamos una aplicación compose con docker-compose up se crea uno (o varios) contenedor por cada servicio y listos.
Pero Kubernetes tiene su propio modelo de aplicación radicalmente distinto. En este post vamos a ver (de forma simplificada) cual es el modelo de aplicación que tiene Kubernetes y ¡desplegaremos nuestra primera aplicación!
Bueno, con este post empiezo una serie de posts sobre Kubernetes. Tengo varios posts en borrador, pero creo que antes de publicarlos puede estar bien una pequeña introducción a Kubernetes: qué es. Y de esto va este post.
Poco a poco los contenedores, y Docker en especial, se han ido abriendo paso en nuestro workflow diario. Y si al principio era tan solo un mecanismo para encapsular aplicaciones, luego también vimos en ellos una magnífica opción para evitar tener que instalar mil dependencias en las máquinas de desarrollo y finalmente para compilar cualquier proyecto… sin tener que instalar ningún SDK en local.
Una de las novedades de VS2017 es el soporte integrado para Docker: podemos desplegar fácilmente nuestras soluciones en contenedores locales y depurar nuestro código Docker que se ejecuta en un contenedor. Pero… ¿cómo funciona exactamente?
**
**
En el post anterior vimos como empaquetar y desplegar en Docker una sencilla aplicación (un hello world) en asp.net core. En este post vamos a ver como desplegar en Docker una aplicación asp.net core (con sus controladores y vistas) y también ver como lo podemos usar usando una imagen base que no tenga el SDK, solo el runtime.
¡Vamos allá!
Seguimos con esta sobre el uso de Docker desde el punto de vista de un desarrollador asp.net (core). En este caso vamos a construir nuestra primera imagen Docker.
Nota: Visual Studio 2017 incorpora de serie las Docker Tools que automatizan todo lo que veremos en estos artículos. Tiempo tendremos, más adelante en esta serie, de hablar de las Docker Tools. La razón de hacerlo primero todo “manual” es porque el objetivo de esta serie es ayudarte a que entiendas Docker, no presentarte el “botón mágico” que se encarga de todo. Yo, es que soy de la vieja escuela: me gusta entender las cosas (al menos hasta donde puedo).