A ver, era algo que se veía a venir… Microsoft ha anunciado finalmente el abandono de Full Framework, en favor de Net Core. Cualquiera que estuviese al tanto de los intríngulis de pasillo del gigante de Redmond sabía que ambos equipos andaban bastante a la greña.
Dentro de esta vorágine de productos relacionados con los contenedores en la que está inmersa Microsoft, ahora le toca el turno a Service Fabric Mesh que salió hace nada en public preview. En este post quiero comentaros un poco de qué va este producto y como ha ido mi (limitada) experiencia con él.
Disclaimer: Este es un post sobre un producto que está en preview. Lo expuesto aquí puede cambiar a medida que avance tanto el propio producto como mi experiencia en él.
¡Buenas! En este post vamos a ver como añadir soporte TLS a tu clúster de Kubernetes desplegado en ACS o AKS. Hace tiempo escribí un post sobre como añadir certificados de desarrollo a un servicio NGINX que tuvieses en Kubernetes. Aunque lo dicho en aquel post sigue siendo válido, hay una manera mucho más sencilla con la condición de que usemos ingress para exponer nuestros servicios al exterior.
En este post parto de la suposición de que:
Es decir, haciendo http://IP-CLUSTER/servicio obtienes alguna respuesta. Lo que queremos es poder usar https en su lugar.
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.
Bueno, imagina que trabajas en un proyecto en NetCore que debe ser multiplataforma. En general el propio framework te provee de todo lo necesario, pero sigamos imaginando que algunas partes de tu proyecto dependen via P/Invoke de llamadas nativas.
En este caso puedes optar por tener todos los enlaces P/Invoke para cada plataforma en el mismo proyecto (no hay ningún problema) o bien tenerlos separados en proyectos por cada una de las plataformas.
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.
Todos estamos acostumbrados a usar los paquetes de NuGet en nuestros desarrollos. Pero a raíz de Net Core 2.0, apareció el concepto de metapaquete. Qué es exactamente un metapaquete y por qué existen?
La respuesta rápida es que un metapaquete de NuGet es simplemente un paquete que no incluye ningún ensamblado, solo referencia a otros paquetes. Es, en definitiva, un mecanismo para “agrupar” paquetes de NuGet bajo un mismo número de version.
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!
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.
¡Buenas! En esta entrada voy a resumir los pasos seguidos para añadir soporte SSL a un cluster Kubernetes. En mi caso lo tengo desplgado en ACS pero eso es irrelevante.
Lo único que si usas ACS y quieres usar una IP determinada, recuerda que la IP pública que vayas a usar debe estar creada anteriormente. Si no, por más que la especifiques dentro de la configuración del servicio (usando loadBalancerIP), Kubernetes no va a poder levantar el servicio.