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