Ahora que .NET Core 2.1 ya es oficial ya podemos desgranar algunas de sus novedades más interesantes. La verdad es que, por fin, se vislumbra una madurez en la plataforma. Realmente a no ser que haya algún motivo de fuerza mayor (librería no disponible), .NET Core 2.1 debería ser la opción por defecto a la hora de empezar cualquier proyecto nuevo.
Disclaimer: En ese post hablo de una librería (Beatpulse) de la que soy contribuidor (lo aclaro, para que no haya ningún malentendido).
En todo sistema distribuído es importante disponer de un mecanismo que permita saber en todo momento si un servicio está funcionando o no. Es cierto que el concepto de “funcionando” es algo difuso de definir, pero yendo a mínimos deberíamos saber si un sistema se ha caído o no.
Hoy me han preguntado eso, así que mira, aprovecho para apuntarlo aquí, por si alguien más tiene esta duda.
La situación es la siguiente: tienes minikube instalado y funcionando en Windows, pero quieres usarlo desde un kubectl ejecutándose en un terminal WSL. ¿Es posible?
¡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.
¡Buenas! A raíz de una situación en la que me he encontrado en un proyecto real (de la que luego hablaré) me he decidido a escribir este post para comentar algunas cosillas sobre varianzas en los delegados mismos.
Cuando hablamos de varianzas en delegados hay que contemplar dos aspectos:
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.
Bueno, dejémoslo en arquitecturas distribuídas, que a veces hablamos muy (demasiado) alegremente de microservicios…
La idea es hablar sobre algunos conceptos, patrones que se prestan a confusión porque muchas veces “se tocan” a nivel funcional y no queda claro si estamos uno u otro. Vamos a hablar de proxies, API Gateway, Service Mesh y Backend For Frontend.
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.
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.