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).
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á!
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?
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 🙂
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.
Este es el segundo post sobre Azure Container instances. En el post anterior vimos lo fácil que era publicar un contenedor y ejecutarlo usando ACI y discutimos algunas de sus limitaciones.
En este post veremos que ACI nos permite ejecutar grupos de contenedores, de forma igualmente sencilla y así tener algunos escenarios más complejos.
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).
Cuando hablamos de serverless todo el mundo lo asociamos a las soluciones tipo FaaS como Azure Functions o Amazon Lambda, pero hay otros productos que se engloban dentro de ese paradigma y en Azure uno de los más interesantes es Azure Container Instances. Del mismo modo que con una Azure Function me limito a poner código en “ejecución” y esto se ejecuta en algún sitio, usando ACI lo que hago es “poner un contenedor” que se ejecutará en… bueno, donde sea. Eso es serverless señores.
Con este post quiero iniciar una pequeña serie dedicada a ACI, como ACI se compara con su primo Zumosol (AKS) y como AKS y ACI habilitan interesantes escenarios (altísima escalabilidad y workloads mixtos de contenedores).
Imagina que estás probando alguna versión release de netcore (pongamos la 2.2-preview3) y quieres generar imágenes Docker de tu proyecto para esa imagen. Pero a la vez quieres también crear las imágenes usando la última versión estable (pongamos la 2.1).
Asumiendo que el código fuente es compatible, ¿como puedes gestionar eso sin morir en el intento?