Aujourd’hui , les conteneurs sont devenus une sorte de norme en termes de déploiement.
Docker s’est démocratisé mais aujourd’hui encore, Azure Kubernetes Service est une option compliquée à mettre en place pour la plupart mais prend en charge beaucoup plus de scénarios comme l’orchestration de conteneurs , le scaling automatique ou encore le service discovery.
Jusqu’au Microsoft Ignite 2021, voici les options qui étaient proposées par Microsoft sur Azure :
Mais cela a changé car Microsoft a annoncé un nouveau venu dans la famille : Azure Container Apps.
Ce service a pour but de réduire les compétences requises pour utiliser une application sous AKS.(Azure Kubernet Service).
Qu’est ce qu’Azure Container App ?
ACA(Azure Container App) fournit un hébergement serverless reposant sur le service AKS, permettant de déployer de multiples containers sans avoir à se charger de l’aspect infrastructure.
Lorsque vous déployez ou modifiez les conteneurs dans ACA, le service crée automatiquement un instantané de votre application, appelé révision, et exécute ses conteneurs dans un pod. Tout comme dans Kubernetes, ces conteneurs partagent le même cycle de vie d’application, le même réseau et le même disque. Ils peuvent également communiquer entre eux.
De plus, grâce à son intégration avec KEDA (Kubernetes-based Event-Driven Autoscaling), le service augmentera/diminuera automatiquement (vertical scaling n’est pas prise en charge) le nombre de pods liés à une révision en fonction de métriques comme le nombre de requêtes HTTP simultanées et l’utilisation de la mémoire. Pour économiser de l’argent, vous pouvez également définir le nombre minimum de répliques sur 0. S’il n’y a pas de demandes pour l’application, le service réduira le nombre de pods actifs à 0 et vous ne paierez rien.
Plusieurs ACA peuvent également être déployés dans un seul environnement. Ce faisant, ils seront placés sous le même réseau virtuel et isolés du monde extérieur. Pour fournir des fonctionnalités de surveillance, chaque environnement possède son propre espace de travail Log Analytics qui est partagé avec les ACA qu’il contient. Pour ceux qui connaissent Kubernetes, nous pouvons voir l’environnement ACA en tant qu’espace de noms Kubernetes et la révision ACA en tant que déploiement Kubernetes.
Dans Kubernetes, il existe plusieurs manières d’acheminer du trafic externe vers un cluster. ClusterIPs, NodePorts et Ingresses sont des ressources couramment utilisées pour exposer des services avec un ensemble unique de fonctionnalités et de compromis. Les ACA réduisent les options disponibles à un simple Ingress qui, une fois activée, fournit une entrée HTTPS et un nom de domaine complet (FQDN), composé comme suit : (j’ai créé une ACA avec l’image « Hello-world »:
Gestion des changements
Comme mentionné précédemment, lorsque vous déployez ou modifiez les conteneurs dans votre ACA, le service prend automatiquement un instantané immuable de l’ACA. Ensuite, il déploie une nouvelle version sur un pod séparé. Cependant, tous les changements ne déclencheront pas ce comportement. Dans l’ACA, on peut distinguer deux types de changements :
- Revision-scope changes. => ceux-ci vont déclencher la création d’une nouvelle révision lorsque la section « template » de la configuration est modifiée
Il est important de mentionner que le traffice vers l’ancienne revision sera redirigé vers la nouvelle sauf si vous définissez un découpage du trafic.
- Application-scope changes. => ces changements ne déclenchent pas de création de nouvelle révision :
- Modifications des règles de répartition du trafic qui définissent la façon dont le trafic est équilibré entre les différentes révisions.
- Modifications liées à la configuration d’entrée qui définissent l’exposition de votre ACA au Web public.
- Modifications des valeurs secrètes stockées dans la configuration (les révisions doivent être redémarrées avant qu’un conteneur ne reconnaisse de nouvelles valeurs secrètes).
- Tout changement en dehors de la section modèle de la configuration.
Integration avec Dapr :
ACA fournit une compatibilité avec Dapr (Distributed Application Runtime).
Je ne vais pas revenir sur l’utilisation de Dapr que je connais pas très bien mais c’est une belle feature.
En conclusion , Microsoft nous offre une nouvelle ressource qui va devenir de plus en plus populaire dans le future car elle réduit drastiquement la compléxité de mise en place comparé à Kubernetes.
Articles similaires