Créer et gérer une infrastructure Kubernetes dans le cloud peut être difficile, même en utilisant un environnement géré comme Azure Kubernetes Service (AKS). Lors de la conception d’une application cloud native, vous devez prendre en compte l’infrastructure virtuelle sous-jacente et provisionner la bonne classe de serveurs pour votre charge de travail et le bon nombre pour prendre en charge votre évolutivité prévue. Ensuite, il faut créer et gérer un maillage de services pour gérer la mise en réseau et la sécurité.
C’est beaucoup de travail que d’ajouter plusieurs nouvelles couches devops à votre équipe de développement : une pour les infrastructures physiques ou virtuelles, une pour votre application et ses services associés, et une pour gérer votre plateforme applicative, qu’elle soit Kubernetes ou autre couche d’orchestration ou de gestion des conteneurs. C’est un problème important qui annule de nombreux avantages du passage à un fournisseur de cloud hyperscale. Si vous n’avez pas le budget pour gérer Kubernetes, vous ne pourrez pas profiter de la plupart de ces technologies.
Le cloud natif peut être difficile
Il existe des alternatives, basées sur retour -des technologies end-as-a-service comme Azure App Service. Ici, vous pouvez utiliser des conteneurs comme alternative aux runtimes intégrés, en remplaçant votre propre espace utilisateur par l’environnement managé d’Azure. Cependant, ces outils ont tendance à se concentrer sur la création et l’exécution de services prenant en charge les applications Web et mobiles, et non sur les environnements évolutifs axés sur la messagerie nécessaires pour fonctionner avec l’Internet des objets ou d’autres systèmes centrés sur les événements. Bien que vous puissiez utiliser des technologies sans serveur comme Azure Functions, vous n’avez pas la possibilité de packager tous les éléments d’une application ou de travailler avec des services de mise en réseau et de sécurité.
Ce qui est nécessaire, c’est un moyen de fournir des services Kubernetes sans serveur qui vous permette de transférer les opérations des serveurs sous-jacents ou de l’infrastructure virtuelle à un fournisseur de cloud. Vous pouvez vous appuyer sur l’expertise du fournisseur en matière d’infrastructure pour gérer vos services applicatifs ainsi que les réseaux et serveurs virtuels sous-jacents. Là où vous auriez passé du temps à créer YAML et à configurer Kubernetes, vous comptez maintenant sur l’automatisation de votre fournisseur et vous vous concentrez sur la création de votre application.
Présentation d’Azure Container Apps
À Ignite, Microsoft a présenté un aperçu d’un nouveau service de plateforme Azure, Azure Container Apps (ACA), qui fait exactement cela, offrant la cible un service de conteneur sans serveur qui gère la mise à l’échelle pour vous. Tout ce que vous avez à faire est d’apporter vos conteneurs emballés, prêts à fonctionner. Sous le capot, ACA est construit sur des services AKS familiers, avec la prise en charge de KEDA (Kubernetes-based Event-Driven Autoscaling) et du maillage de services Envoy. Les applications peuvent tirer parti de Dapr (Distributed Application Runtime), vous donnant une cible commune pour votre code qui permet aux conteneurs d’applications de s’exécuter à la fois sur les infrastructures Kubernetes existantes ainsi que dans le nouveau service.
Microsoft suggère quatre scénarios différents où Azure Container Apps pourrait convenir :
- Gestion des API basées sur HTTP
- Exécution du traitement en arrière-plan
- Déclenchement sur événements à partir de n’importe quelle source compatible KEDA
- Exécuter des architectures de microservices évolutives
Cette dernière option fait d’ACA un outil très flexible, offrant des outils de mise à l’échelle à zéro et de paiement à l’utilisation pour les composants d’application qui peuvent ne pas être utilisés la plupart du temps. Vous pouvez héberger une application sur plusieurs services Azure différents, en appelant vos services ACA au fur et à mesure de vos besoins sans encourir de frais pendant qu’ils sont inactifs.
Coûts dans le aperçu sont faibles. Voici quelques chiffres pour la région Est US 2 :
- Les demandes coûtent 0,40 $ par million, les deux premiers millions par mois étant gratuits.
- Les coûts du processeur virtuel sont : actif à 0,000024 $ par seconde et inactif à 0,000003 $ par seconde.
- La mémoire est également facturée par Go par seconde : 0,000003 $ par seconde pour les conteneurs actifs et inactifs.
- Il y a une subvention gratuite par mois de 180 000 secondes de processeur virtuel et 360 000 Go-secondes.
Tout ce dont vous avez besoin pour utiliser Azure Container Apps est une application conditionnée dans un conteneur, en utilisant n’importe quel runtime que vous voulez. C’est à peu près la même chose que d’exécuter Kubernetes, avec des conteneurs configurés pour s’installer avec toutes vos dépendances d’application et conçus pour s’exécuter sans état. Si vous avez besoin d’un état, vous devrez configurer un environnement de stockage ou de base de données Azure pour conserver et gérer l’état de l’application pour vous, conformément aux meilleures pratiques d’utilisation d’AKS. Il n’y a pas d’accès aux API Kubernetes ; tout est géré par la plateforme.
Bien qu’il existe certaines similitudes avec Azure Functions, avec des options sans serveur de mise à l’échelle jusqu’à zéro, Azure Container Apps ne remplace pas Functions. Au lieu de cela, il vaut mieux le considérer comme une maison pour des applications plus complexes. Les conteneurs Azure Container Apps n’ont pas une durée de vie limitée, vous pouvez donc les utiliser pour héberger des applications complexes qui s’exécutent pendant une longue période, ou même pour des applications en arrière-plan.
Démarrer avec Azure Container Apps
La prise en main d’Azure Container Apps est relativement simple, en utilisant le portail Azure et en travaillant avec des modèles ARM ou par programmation via Azure CLI. Dans le portail Azure, commencez par configurer votre application environnement et la surveillance et le stockage associés dans un groupe de ressources Azure. L’environnement d’application est la limite d’isolement de vos services, en configurant automatiquement un réseau local pour les conteneurs déployés. Créez ensuite un espace de travail Log Analytics pour votre environnement.
Les conteneurs se voient attribuer des cœurs de processeur et de la mémoire, en commençant par 0,25 cœurs et 0,5 Go de mémoire par conteneur, jusqu’à 2 cœurs et 4 Go de mémoire. Les cœurs fractionnaires sont le résultat de l’utilisation de locataires partagés, où le calcul basé sur les cœurs est partagé entre les utilisateurs. Cela permet à Microsoft d’exécuter des environnements Azure Container Apps à très haute densité, permettant une utilisation efficace des ressources Azure pour les petits conteneurs événementiels.
Les conteneurs sont chargés à partir d’Azure Container Registry ou de tout autre registre public, y compris Docker Hub. Cette approche vous permet de cibler Azure Container Apps à partir de votre pipeline CI/CD existant (intégration continue et livraison continue), en livrant un conteneur packagé dans un registre prêt à être utilisé dans Azure Container Apps. Actuellement, seuls les conteneurs basés sur Linux sont pris en charge, bien qu’avec la prise en charge de .NET, Node.js et Python, vous devriez pouvoir rapidement porter n’importe quelle application ou service vers un conteneur prêt pour ACA.
Une fois que vous avez choisi un conteneur, vous pouvez choisir d’autoriser l’accès externe pour les connexions HTTPS. Vous n’avez pas besoin d’ajouter et de configurer de fonctionnalités de mise en réseau Azure, telles que des réseaux virtuels ou des équilibreurs de charge ; le service les ajoutera automatiquement si nécessaire.
Utiliser Azure CLI pour travailler et évoluer avec Dapr
Applications plus complexes, comme celles créées à l’aide de Dapr, doit être configuré via Azure CLI. Travailler avec la CLI nécessite l’ajout d’une extension et l’activation d’un nouvel espace de noms. Le service est toujours en préversion, vous devrez donc charger l’extension CLI à partir d’un blob Microsoft Azure. Comme pour le portail, créez un environnement Azure Container Apps et un espace de travail Log Analytics. Commencez par configurer un magasin d’état dans un compte Azure Blob Storage pour toutes les applications Dapr déployées sur le service, ainsi que les fichiers YAML de configuration appropriés pour votre application. Ceux-ci doivent contenir les détails de votre conteneur d’application, ainsi qu’un pointeur vers le side-car Dapr qui gère l’état de l’application.
Vous pouvez désormais déployer vos conteneurs d’applications à partir d’un registre distant en utilisant une seule ligne de code pour l’ajouter à votre groupe de ressources et activer toutes les fonctionnalités Dapr. Dans le même temps, configurez un nombre minimum et maximum de réplicas afin de pouvoir gérer la façon dont le service fait évoluer vos applications. Actuellement, vous êtes limité à un maximum de 25 réplicas, avec la possibilité de mettre à l’échelle jusqu’à zéro. Il est important de se rappeler qu’il y a un démarrage associé au lancement de toute nouvelle réplique, vous pouvez donc vouloir garder une seule réplique en cours d’exécution à tout moment. Cependant, cela signifiera que l’utilisation de cette ressource sera facturée aux frais d’inactivité d’Azure Container Apps.
Vous pouvez ensuite définir votre échelle déclencheurs en tant que règles dans les fichiers de configuration JSON. Pour les requêtes HTTP (par exemple lorsque vous exécutez un microservice d’API REST), vous pouvez choisir le nombre de requêtes simultanées qu’une instance peut desservir. Dès que vous dépassez cette limite, Azure Container Apps lance un nouveau réplica de conteneur jusqu’à ce que vous atteigniez votre limite prédéfinie. La mise à l’échelle basée sur les événements utilise les métadonnées KEDA pour déterminer quelles règles sont appliquées.
Choisissez le nom de l’événement utilisé pour faire évoluer votre application, le type de service que vous utilisez, ainsi que les métadonnées et le déclencheur utilisés pour faire évoluer. Par exemple, une file d’attente de messages peut avoir une longueur de file d’attente maximale. Ainsi, lorsque la file d’attente atteint sa longueur maximale, une nouvelle réplique de conteneur est lancée et attachée à la file d’attente. D’autres options de mise à l’échelle sont basées sur les fonctions Kubernetes standard, vous pouvez donc utiliser l’utilisation du processeur et l’utilisation de la mémoire pour évoluer. Il est important de noter qu’il ne s’agit que d’un système évolutif ; vous ne pouvez pas modifier les ressources affectées à un conteneur.
Kubernetes simplifié
Il y a beaucoup à aimer ici. Azure Container Apps simplifie grandement la configuration et la gestion des applications Kubernetes. En traitant un conteneur comme unité d’application par défaut et en tirant parti de technologies telles que Dapr, vous pouvez créer des applications qui s’exécutent à la fois dans des environnements Kubernetes standard et dans Azure Container Apps. La configuration est simple, avec des définitions de base pour votre application et son évolution, vous permettant de fournir rapidement des applications évolutives et natives du cloud sans avoir besoin d’une équipe devops complète.
Azure a commencé sa vie en tant qu’hôte d’outils de plateforme en tant que service, et Azure Container Apps est la dernière instanciation de cette vision. Là où Azure App Service d’origine vous limitait à un ensemble spécifique d’API et de runtimes, Azure Container Apps a une portée beaucoup plus large, fournissant un cadre qui rend le cloud natif aussi simple que de placer votre code dans un conteneur.
.
Toute l’actualité en temps réel, est sur L’Entrepreneur
