Como comenté en mi post anterior sobre gRPC, la traducción entre gRPC y JSON es estándard. Esto nos permite tener nuestra comunicación interna en gRPC y exponer una fachada en HTTP con JSON para aquellos clientes que (todavía) no pueden usar gRPC.

En este post os voy a mostrar como podemos crear dicha fachada usando Envoy ejecutándose en un contenedor Docker. ¡Vamos allá!

Una de las novedades que incluye Net Core 3 es el soporte para gRPC. ¿No conoces gRPC? Bueno, pues básicamente se trata del RPC de toda la vida, pero vestido a la moda, duchado y perfumado. Vamos, si te lees los puntos principales de la página oficial de gRPC (definición de servicio independiente del lenguaje, soporte de muchos lenguajes, streaming bi-direccionales) es como si volvieses unos cuantos años atrás y Don Box estuviese en la bañera vendiéndote SOAP. Y de todos modos, cuando hablábamos de SOAP ya era difícil no acordarse de CORBA (ya fuese el estándard o el de Microsoft xD).

Buenas! Andaba yo preparando unas demos donde tenía varios contenedores ejecutándose en un Kubernetes, usando netcore y Linux. Todo funcionaba (más o menos) bien, hasta que de golpe y porrazo los contenedores empezaron a fallar:

System.IO .IOException: The configured user limit (1024) on the number of inotify instances has been reached

Este error apareció cuando escalé el número de contenedores y se daba en los nuevos contenedores creados (los iniciados seguían funcionando). ¿Qué podía estar sucendiendo?

¡Buenas! Vamos a ver en este artículo como podemos leer secretos almacenados en un Azure Key Vault desde nuestro código netcore ejecutándose en un AKS.

A diferencia de ACR donde contamos con una integración nativa en la cual nos basta con usar un _service account _de AKS vinculado a un _service principal _de Azure que tenga permisos de lectura contra el ACR (escribiéndolo veo que esto da para un pequeño futuro post), para Key Vault no tenemos integración nativa.

AKS Devspaces es una característica que Microsoft está promocionando bastante en sus charlas: casi en cualquier evento donde se hable de AKS se demuestra, ni que sea brevemente, Devspaces.

Pero… qué es y lo más importante: ¿Para qué sirve y como se usa?

He visto este problema con un proyecto generado a partir de la plantilla de SPA de React, pero quizá puede aplicar a otras plantillas de SPA (como Angular).

¡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 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.