Featured image of post Azure Container Apps – Part 1 – Le chainon manquant

Azure Container Apps – Part 1 – Le chainon manquant

Azure Container Apps a été annoncé en GA (General Availability) à la Build 2022, c’est l’occasion d’en faire une petite présentation.

Lorsque l’on veut faire du “Container” dans Azure, on a plusieurs solutions à notre disposition :

  • Azure Kubernetes Service (AKS) → Full support de Kubernetes dans Azure.
  • Azure Red Hat OpenShift → Runner du Kubernetes via OpenShift (permettre de profiter de ses propres container registry, solution de CI/CD, etc.).
  • Azure Container Instances → Fournit un single Pod.
  • Azure Functions → On peut déployer une Azure Function en tant que container.
  • Web App for Containers

On peut se poser la question : “Où se situe ACA (on utilisera ACA pour Azure Container Apps) dans l’offre existante des ressources de calcul Azure ?” Je positionnerais ce nouveau service de conteneur à la frontière entre la technologie Platform as a Service “PaaS” et Functions as a Service “FaaS” (serverless).

Azure Container Apps, c’est le déploiement d’applications conteneurisées type microservices, sans se préoccuper de l’infra complexe et la gestion de Kubernetes.

Container As A Service — Open Source

ACA se base sur de nombreuses briques Open Source de la CNCF (Cloud Native Computed Foundation) :

  • Kubernetes : mais attention, il n’y a pas d’accès à l’API, pas de kubectl, pas de gestion d’orchestrateur.
  • Linux Containers : Linux-based x86-64 (linux/amd64), ne fonctionne pas avec des containers Windows.
  • KEDA : Kubernetes Event Driven AutoScaling.
  • Envoy : Utilisé par Istio / Open Service Mesh, etc. C’est un produit mature.
  • Dapr : Full support de Dapr (Distributed Application Runtime), simplifie la gestion des microservices (s’occupe de la “plomberie”).

L’idée est de s’affranchir de l’infrastructure et laisser Azure gérer la partie Kubernetes, contrairement à d’autres services comme AKS (Azure Kubernetes Service).

Use Cases

Dans la multitude de scénarios possibles avec les utilisations de containers, ACA peut être utilisé pour :

  • Endpoints : Mettre à disposition des endpoints.
  • Background process : Ex. traiter de la data en base de données.
  • Event-Driven Processing : Ex. traiter des messages qui arrivent dans une “Queue”.
  • Microservices : Déployer et gérer des architectures microservices.

Concepts

Environnements

L’environnement se compose de 3 parties :

  1. vNet : La couche d’isolation (Virtual Network).
  2. Log Analytics Workspace : Tous les logs seront déversés dans un puits de log.
  3. La couche de communication entre applications.

Pourquoi déployer des container apps dans le même environnement :

  • Gérer des services connexes.
  • Déployer différentes applications sur le même réseau virtuel.
  • Faire en sorte que les applications communiquent entre elles à l’aide de Dapr.
  • Avoir des applications qui partagent la même configuration Dapr.
  • Avoir des applications qui partagent le même Log Analytics Workspace.

Pourquoi déployer des container apps dans des environnements différents :

  • Deux applications ne partagent jamais les mêmes ressources de calcul.
  • Deux applications ne peuvent pas communiquer entre elles via Dapr.

Containers

Les containers sont toujours basés sur des images Linux. Les images peuvent provenir de registries publics comme Docker Hub, ou alors de registries privées type ACR (Azure Container Registry).

Si un container “crash”, il sera automatiquement redémarré.

Sur chaque container, on pourra définir des Memory Request et CPU Request, c’est-à-dire que sur chaque container, on pourra lui indiquer le minimum dont il a besoin pour fonctionner et démarrer correctement. Ceux qui font déjà du Kubernetes connaissent déjà cette option.

Un groupe de containers est égal à un Pod, ce qui veut dire qu’ils partagent la même adresse IP ainsi que le même espace disque.

Contrairement à AKS, les containers ne peuvent pas s’exécuter en mode “Privilège”, ce qui est de toute façon une mauvaise pratique quand on fait du container.

Revisions

Une Révision, c’est quoi ? C’est un snapshot d’une version de container app.

Pourquoi utiliser les révisions ?

  • Déployer une nouvelle version de votre application.
  • Rapidement revenir à une ancienne version de votre app (oui, des rollbacks arrivent plus souvent qu’on le croit).
  • Splitter le trafic entre les révisions, ce qui va permettre de faire de l’A/B Testing.

Cycle de vie

Création

Une fois que l’on déploie, la première révision est créée.

Mise à jour

Dès que le Container App est mis à jour, une nouvelle révision est créée.

Désactivation

Quand une révision n’est plus nécessaire, il est possible de la désactiver de façon individuelle, ou automatique.

Shutdown

Quand est-ce que le Shutdown est effectué :

  • En cas de Scale-in.
  • Si une révision est désactivée.
  • Si le container est supprimé.

Microservices

  • ACA va permettre de gérer le scaling, le versioning et la mise à niveau de façon indépendante.
  • ACA dispose d’un service de discovery.
  • ACA bénéficie de la gestion native de Dapr.

Scalability

ACA nous permet de faire du scaling horizontal, c’est-à-dire que l’on peut ajouter/supprimer des instances (Scale-In & Scale-Out).

Les critères :

  • Trafic HTTP : En fonction du nombre de requêtes concurrentes (par défaut : 50).
  • CPU Load : En fonction de la charge processeur.
  • Memory Load : En fonction de la charge mémoire.
  • Event Driven Processing via les scalers KEDA.

Deploy & Manage

Quels outils ?

  • Azure Portal
  • Pulumi
  • Azure CLI (via PowerShell par exemple)
  • ARM → Bicep

ACA permet l’utilisation des Secrets. L’utilisation de secrets est scopée à l’application. Les changements sont appliqués si :

  • Une nouvelle révision est déployée.
  • On redémarre une révision.

Continuous Deployment

En plus des pipelines classiques qu’on utilise déjà dans Azure DevOps, on a la possibilité d’utiliser GitHub Actions.

Un schéma vaut mieux qu’un long discours 🙂

Monitoring

Network Access

Mais finalement, comment on accède à notre application ?

On va simplement passer par un controller Ingress, c’est aussi le cas avec AKS.

Features

  • TLS Support 1.2 : Avec Envoy derrière, le 1.2 est par défaut.
  • Support du HTTP/2.
  • Expose sur HTTP et HTTPS, sachant que par défaut, si les deux ports sont ouverts, il redirige sur la 443 (en même temps, qui utilise encore du HTTP 😄).

Access

L’accès à notre application se fera via un FQDN (Fully-Qualified Domain Name).

Dans le cas INTERNAL, le trafic est autorisé uniquement au sein du VNET associé.

Traffic Splitting

Le Traffic Splitting est un mécanisme qui achemine un pourcentage configurable de requêtes entrantes (trafic) vers divers services en aval.

Conclusion

Si on a une architecture microservices, une équipe de développeurs et qu’on n’est pas à l’aise avec Kubernetes (faire une configuration qui tient la route, l’air de rien c’est pas si évident que ça), ACA me semble être la meilleure solution. À mon sens, ACA permet de mettre le focus sur les apps et non sur l’infrastructure, et par la même occasion d’accélérer la productivité vu qu’on se concentre que sur le code.

Ressources

Keda : https://keda.sh/

Envoy : https://www.envoyproxy.io/

Dapr : https://dapr.io/

Prez Dapr : https://www.youtube.com/watch?v=ruQFIPZl2QM

Azure Container Apps : https://docs.microsoft.com/fr-fr/azure/container-apps/