El otro día habé de como crear imágenes Docker para las aplicaciones SPA de .NET Core. Hoy quiero comentaros como crear imágenes Docker para aplicaciones SPA puras y un tema importante al respecto: como configurarlas.
¡Buenas!
Cuando creas un proyecto SPA de netcore, ya sea mediante VS o bien usando dotnet new y alguna plantilla SPA como react (dotnet new react), se genera una estructura parecida a la siguiente:
La carpeta “ClientApp” contiene todo el código de cliente (javascript, CSS y demás) mientras que el resto es el código netcore que se limita a “lanzar” la SPA.
Una de las preguntas más frecuentes que me hacen sobre contenedores es hasta que punto penalizan el rendimiento. Es una pregunta muy lógica ya que al final los contenedores ofrecen un cierto nivel de aislamiento, parecen máquinas virtuales… Algo han de penalizar, ¿no?. En esta entrada voy a hablar de los runtimes de contenedores, para que entendamos un poco más qué significa ejecutar un contenedor.
Una de las novedades de ASP.NET Core 2.1 es que redirige automáticamente todo el tráfico de http a https y, además, fuerza el uso de HSTS. Sobre https nada que decir, seguro que todos lo conocéis.
Sobre HSTS simplemente comentar que es un protocolo mediante el cual el servidor informa a los user-agents de que solo acepta conexiones seguras, es decir que deben usar HTTPS para acceder a sus recursos. A pesar de que HSTS tiene sus limitaciones (y que para evitarlas sería necesaria un protocolo a nivel de DNS y no de servidores) su uso es una práctica imprescindible en seguridad web. De hecho **hoy en día NO HAY EXCUSA PARA NO USAR HTTPS NI HSTS **en cualquier sitio web. Da absolutamente igual lo que haga. No usar https ni hsts es una negligencia que debería avergonzar a cualquiera.
Una de las ventajas que tiene **Visual Studio 2017 es el soporte de depuración para contenedores netcore. **A partir de la versión 15.7 el soporte está relativamente maduro soportando algunos escenarios que daban errores en versiones anteriores (p. ej. dos servicios compose usando la misma imagen).
Pero… ¿y si no podemos/queremos usar Visual Studio? ¿Tenemos alguna alternativa? Pues sí: usar visual studio code, y aunque el workflow no es tan sencillo como en Visual Studio, al final se puede conseguir algo similar: ejecutar y depurar un contenedor. ¡Vamos allá!
Una de las características menos conocidas de Docker son las imágenes multi-arch. Es una característica que agradecerás si trabajas tanto en contenedores Linux como Windows.
Como ya debes saber, Docker no permite ejecutar contenedores cuyos binarios no sean los mismos de la plataforma que los hospeda: es decir, si estás en Windows solo puedes ejecutar contenedores cuyos binarios sean Windows y si estás en Linux pues lo mismo. Y sí, Docker CE For Windows “hace tramas” para permitirte ejecutar contenedores Linux: los ejecuta en una máquina virtual Hyper-V.
Si desarrollas un producto multi-plataforma y quieres ofrecer contenedores tanto Linux como Windows, el uso de imágenes multi-arch es algo que, como digo, vas a agradecer, ya que te permite usar un solo Dockerfile para generar ambas imágenes.
En este post vamos a ver como escalar servicios, tanto en Compose, como en Swarm como en Kubernetes y luego veremos algunas consideraciones cuando usemos HttpClient desde el cliente al acceder a un servidor escalado.
Nos centramos en el escenario de escalado básico, es decir, sin demasiada lógica.
[Autobombo]: Si estás interesado en temas de Docker y Kubernetes, échale un vistazo a mi curso de Docker y Kubernetes en CampusMVP.
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.