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).
Pero como digo, ese es solo el primer post, así que hablemos de ACI: el caso de uso más simple es tienes un contenedor y quieres ponerlo en Azure sin preocuparte de nada más? Bueno, pues usa ACI. Mira, vamos a usar la imagen dockercampusmvp/go-hello-world (publicidad: esa es una imagen de uno de los labs de mi curso de Docker y Kubernetes en CampusMVP). Este contendor simplemente expone un servidor web implementaado en Golang, que responde siempre con «hello world».
Pues bien vamos a desplegarlo en Azure, usando la Azure CLI con dos líneas (y una será para crear el resource group):
az group create -n test-aci -l northeurope az container create -g test-aci -n go-hello-world-ctr --image dockercampusmvp/go-hello-world --ports 80 --ip-address public --dns-name-label go-hello-world
El parametro «–ports» indica los puertos a abrir al exterior, con «–ip-address public» le indicamos que queremos una IP pública y usando «–dns-name-label» especificamos el prefijo DNS que queremos.
¡Con eso ya tenemos nuestro contenedor en Azure! Podemos usar «az container list» o «az container show» para verlo:
¡Fantástico! Y ahora… como accedemos al contenedor? Bueno, pues simplemente usando la IP asociada o bien buscando su DNS, que puedes encontrar con «az container show -g test-aci -n go-hello-world-ctr | findstr fqdn» (usa «grep» en lugar de «findstr» si estás en Linux):
¿Fácil, verdad? Ya os lo dije: dos comandos de az y todo listo. Nuestro contenedor ya está creado.
Mapeo de puertos en ACI
Nada es perfecto y ACI tampoco: actualmente el mapeo de puertos no está soportado. Es decir ACI siempre enruta del puerto externo X al mismo puerto X del contenedor. Por lo tanto si tu contenedor escucha por el puerto 8080, a este puerto deberás llamar cuando accedas a tu contenedor desde el exterior.
Eso sí, al menos sabemos que el mapeo de puertos está en el roadmap.
ACI versus Webapps
En Azure también se puede desplegar un contenedor en una Webapp. Aunque es igualmente muy sencillo, no lo es tanto como usar ACI. Y es que, de lejos, ACI es la manera más sencilla para desplegar un contenedor en Azure. Lo interesante de ACI es que se crea y destruye muy rápidamente y por lo tanto solo pagarás por el tiempo que el contenedor esté levantado (haga o no haga nada, por supuesto).
Ahora bien ACI tiene un gran, gran, gran problema al compararse con una webapp y es que NO TIENE SOPORTE BUILT-IN PARA TLS/SSL. Ojo, que quede claro: hay maneras de usar TLS/SSL con ACI pero complican el despliegue y perdemos esa inmediatez. Desde septiembre del 2018 está disponible en preview el poder crear ACIs en vnets propias de Azure, lo que nos da otra posibilidad de añadir TLS/SSL. Pero de nuevo, eso nos complica el despliegue.
ACI versus AKS
ACI y AKS se complementan más que compiten entre ellos. Si bien el uso de ACI permite levantar y parar contenedores y asumir así cargas muy variables de trabajo, para cargas más estables el uso de un clúster de máquinas virtuales (como AKS) es más barato. Todo es hacer los números, claro.
Por otra parte, como digo, se complementan porque AKS puede usar ACI como nodos virtuales (lo veremos en un futuro post), lo que permite usar todo el ecosistema de Kubernetes, ejecutar parte del workload en las propias VMs del clúster, pero tener otra parte del workload, la altamente variable, ejecutándose en ACI que se crean y destruyen bajo demanda.
Por supuesto AKS es mucho más complejo de manejar que ACI, y al mismo tiempo mucho más potente, siendo la solución que debería usarse para aquellos workloads que se componen de varios tipos de contenedores.
Posts de esta serie
Iré añdiendo los enlaces a medida que los posts se publiquen 🙂
- ACI: Serverless containers (este)
- Container groups en ACI
- ACI y AKS: nodos virtuales
- ACI y AKS: virtual kubelet
¡Espero que os sea interesante!