El sistema de Builds y Releases de Azure Devops es extremadamente flexible, pero se basa en una premisa: la build publica cierto artefacto binario que la Release recoje e instala en los distintos entornos (stages en la terminología de Azure Devops).

Buenas! Esos días he tenido que desplegar una Azure Function en Python. A día de hoy solo se pueden desplegar en Azure Functions cuyo service plan sea Linux (no están soportadas en Windows).

En mi caso quería una plantilla ARM que soportase la creación del service plan y la function app tanto en consumption como en app service plan, para tener la máxima flexibilidad.

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][1], 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?