Andaba yo ayer gastándome el dedo intentando refrescar mi Twitter, extrañado por qué no veía nuevos tweets. Total, que tras unos intentos infructuosos, repasé algunos tweets antiguos de mi timeline, mientras esperaba el bus que me llevaría de la T2 del Aeropuerto del Prat, donde aterricé, a la T1 donde tenía el coche. Y así di con este tweet de Quique:  .

If you have one JSON (or equivalent) file per ENV in your project... I'm sorry but you're not doing well 🤷🏽‍♂️ I don't care how much articles you read about this. Configure ENVs in your CD, if you don't have CD create one 😬 read about CI and CD and enjoy!

— Quique Fdez Guerra (@CKGrafico) July 11, 2019

Y bueno… iba yo a responder, pero vi que la respuesta daba para mucho más que un tweet o sea que, aquí va 😉

Bueno, he aquí un dilema que es más o menos como el tipado estático vs el dinámico o el preferir espacios o tabuladores: es decir, preferencia personal. Pero a veces las preferencias personales se ven influenciadas por lo que conocemos (o más precisamente por lo que desconocemos)… Así que dejadme que os cuente cuatro cosas al respecto y ya si eso, luego lo discutimos en los comentarios o en un bar…

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?

Estaba yo revisando algunas de las nuevas características que quizá incorpore C# 9 y me he encontrado con la propuesta de type classes (shapes en la teminología de C#), que me parece bastante interesante y sobre la cual me gustaría hacer algunos comentarios 🙂

Ahora que los contenedores windows empiezan a funcionar decentemente, nos puede interesar crear imágenes Docker multi-arquitectura para que se puedan desplegar en contenedores Windows o Linux dependiendo de las necesidades. En este post te cuento como hacerlo usando Azure Devops.

Vamos a ver primero qué es una imagen multi-arquitectura, como crearla con la CLI de Docker y finalmente como hacerlo desde Azure Devops 🙂

Los que más o menos me seguís por Twitter, quizá os habréis enterado de que estoy escribiendo una librería cross-platform (netstandard2) para desarrollar aplicaciones de consola. Evidentemente no es la única, es simplemente otra más y puedo asegurar que me lo paso genial desarrollándola.

Uno de los objetivos principales cuando empecé era permitir usar true color (es decir 16 millones de colores) en aquellos terminales que lo soportan y la verdad es que la historia del soporte de colores en terminales da para un post… y aquí estamos 😉

Una cosa que causa cierta confusión en la gente que empieza con Docker es **el nombre de los contenedores. **La verdad es que cuando ejecutamos un contenedor usando docker run este tiene un nombre aleatorio.

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