Introduction Après avoir abordé le sujet Azure Function sur Azure Container Apps, l’article se penche sur un autre scénario visant...
27 novembre 2024
Read this post in English
Hébergement d’Azure Functions dans Azure Apps
Azure Container Apps : Une solution simplifiée pour l’hébergement d’applications conteneurisées
Azure Container Apps, comme expliqué par Pierre Chesné dans son article Introduction à Azure Container Apps, offre une plateforme Kubernetes optimisée pour l’hébergement d’applications conteneurisées. Contrairement à Azure Kubernetes Services (AKS), cette solution gérée par Microsoft permet aux utilisateurs de se concentrer sur les applications sans avoir à gérer l’infrastructure Kubernetes.
Dans Azure Container, plusieurs types d’applications peuvent être hébergés :
- Des conteneurs
- Des applications Java
- Des Azure Functions
L’hébergement de conteneurs est la vocation principale de Azure Container Apps (ACA). Pour les applications Java, Azure Container Apps offre une alternative suite à l’annonce de la fin de d’Azure Spring Apps prévue pour mars 2028 avec une première échéance à septembre 2024. Il est donc essentiel de prévoir une transition pour les utilisateurs actuels.
Il reste donc Azure Function. Mais pourquoi héberger ses Azure Functions sur Azure Container Apps ? Il y a plusieurs avantages.
Rappel des offres historiques pour héberger des fonctions
Azure Function est un service qui a déjà une longue carrière dans Azure, il offre déjà de multiples possibilités d’hébergement (cj : hosting plans.) Historiquement, nous avions les offres suivantes :
- L’offre Consumption plan est une offre historique de type Serverless pour laquelle nous ne payons que le temps d’exécution de nos fonctions.
- L’offre Premium plan est une évolution de cette offre pour proposer du compute plus performant avec plus de fonctionnalités, charge à nous de maximiser l’usage du compute mis à disposition pour héberger le plus de fonctions possibles.
- L’offre Dedicated plan permet de prendre en charge le service sur Azure App Service Environment (ASE) pour héberger les Azure Functions.
L’offre Flex Consumption : Une nouvelle alternative
Dernièrement, une nouvelle alternative est apparue, l’offre Flex Consumption. Cette offre est encore actuellement en preview. Il faut la voir comme une version modernisée de l’offre Consumption Plan tout en lui apportant les bénéfices de l’offre Premium Plan, dont :
- La capacité à proposer des instances dites Always Ready pour réduire les effets du Cold Start
- La capacité à s’intégrer à un VNET existant avec VNET intégration et la rendre inaccessible publiquement
- La capacité à configurer la scalabilité au niveau de chaque Azure Function
- La prise en charge de OpenTelemetry pour améliorer l’Observabilité de nos fonctions
Sous l’offre Flex Consumption, Microsoft a repensé l’infrastructure technique des fonctions traditionnelles avec un projet nommé Légion. Ce qui est intéressant avec cette architecture, c’est qu’elle est ISO compatible avec les spécifications de la Kubernetes Pod API.
L’un des principaux atouts de cette architecture réside dans son modèle de facturation. Si on exclut l’usage des instances en Always Ready qui sont facturées selon un prix fixe mensuel, la consommation est principalement calculée en fonction du temps d’exécution et du nombre d’instanciations.
Actuellement en Preview, l’offre Flex Consumption n’est pas encore disponible dans toutes les régions Azure (comme West Europe ou France Central). De ce fait, le prix public n’est pas encore officiel. La page documentant la facturation du Service Azure Function indique que le prix de l’offre Flex Consumption est très légèrement supérieure pour le critère de facturation de la durée d’exécution (+-0.000003€/GB-s).
Cette offre est moins avantageuse que le Consumption plan en termes de quotas d’exécution et d’instanciations gratuites, ce qui peut impacter les utilisateurs intensifs d’Azure Functions, notamment pour des scripts PowerShell, où il est possible de ne facturer que quelques euros par mois avec le Consumption plan.
Cependant, l’offre Flex Consumption présente encore certaines limitations empêchant son adoption dans certains cas d’usage, notamment :
- Non disponible dans certaines régions clés (West Europe, France Central).
- Toujours en phase Preview.
- Absence de support pour les conteneurs (pour le moment).
Parmi ces contraintes, la dernière est particulièrement pénalisante, surtout dans un contexte où la conteneurisation prend une place de plus en plus importante. Une approche davantage Cloud native est nécessaire. Heureusement, une alternative existe avec Azure Container Apps. En utilisant déjà les conteneurs avec l’offre Premium plan, la transition vers Azure Container Apps s’est révélée fluide et efficace.
Pourquoi héberger ses Azure Functions sur Azure Container Apps ?
Choisir Azure Container Apps pour ses Azure Functions présente plusieurs avantages :
- L’infrastructure est similaire à celle de Flex Consumption basée sur le projet Legion. Cependant, pour des conteneurs et toujours en serverless avec la prise en charge des environnements des Workload profiles en Consumption only.
- L’isolation réseau est simplifiée, gérée au niveau de l’environnement des Container Apps.
- Pouvoir bénéficier de composants comme Kubernetes-based Event Driven Autoscaler (Keda) pour scaler ses fonctions avec des évènements.
- Une approche de l’observabilité plus Cloud-Native avec le support de OpenTelemetry & Aspire.
Pour les utilisateurs nouveaux aux conteneurs, il est nécessaire de créer une image avec DockerFile, en utilisant par exemple une image PowerShell. Depuis septembre 2024, nous avons un worker PowerShell 7.4 sur un socle Debian 12. Pour être informé des dernières versions disponibles, rendez-vous ici. (lien : https://github.com/Azure/azure-functions-docker)
Création et déploiement d’une Azure Function dans Azure Container Apps
Pour le DockerFile, je vous propose de travailler avec Azure Function Core tools. Dans un répertoire vide dédié à cet usage, nous commençons par créer la structure de notre Azure Function avec la commande suivante :
func init MonProjet –worker-runtime PowerShell –docker –managed-dependencies
Nous obtenons un DockerFile personnalisable. Il est mieux d’externaliser la version de l’image à utiliser afin de pouvoir plus facilement contrôler quelle version de l’image je va être utilisée pour PowerShell.
Enfin, il ne reste plus qu’à créer les Azure Functions depuis VSCode ou la ligne de commande comme illustré ci-dessous :
func new –name ActivityLog_HTTP –template « HTTP trigger » –authlevel « function » –worker-runtime PowerShell
Pour les détails relatifs au développement PowerShell avec Azure Function, n’hésitez pas à aller consulter le Azure Function Powershell developer guide. Il vous permettra de comprendre toutes les subtilités de configurations.
Nous devons maintenant construire notre image. Cette opération peut être effectuée localement avec Docker, ou bien déportée directement sur notre instance Azure Container Registry avec la ligne de commande suivante :
az acr build –registry nprdacr –image demonfunction:1.0.0 . –build-arg ‘FUNCTION_IMAGE_TAG=4.0-powershell7.4’
L’avantage est que ce processus s’intègre facilement dans un pipeline de build, que ce soit avec Azure DevOps ou GitHub Actions, selon vos préférences. Une fois le build terminé, il ne reste plus qu’à déployer. Ce déploiement peut être géré directement depuis le portail Azure, au niveau de notre environnement Container Apps. L’interface intuitive du portail vous permettra de vous y retrouver facilement.
Cependant, pour exploiter pleinement les possibilités offertes, il est également possible d’effectuer cette étape via la ligne de commande, comme illustré ci-dessous :
Cependant, ces solutions seules ne suffisent pas pour industrialiser le déploiement de nos fonctions. Il est nécessaire de configurer des variables d’environnement supplémentaires pour nos fonctions. Pour aller plus loin, je vous recommande de consulter ce repository de qualité : Azure-Functions-on-container-apps. Vous y découvrirez comment automatiser le déploiement avec Bicep.
Côté DevOps, voici quelques ressources utiles :
- L’action azure/container-apps-deploy-action pour Github Action
- La tâche AzureContainerApps pour Azure DevOps
De plus, avec le projet Legion qui est compatible ISO avec les spécifications de la Kubernetes Pod API, on pourrait envisager l’utilisation native de YAML. Après quelques recherches, il s’avère que cela est effectivement en cours de développement : Azure Container Apps ARM and YAML template specifications. Cependant, à la date de rédaction de cet article, Azure Function n’est pas encore pris en charge.
En quoi est-ce différent d’Azure Function on Container Apps ?
Au moment de la rédaction de cet article, Azure Function on Container Apps est en GA (General Availability) depuis mai 2024, mais certaines limitations et différences sont encore à noter. Parmi celles-ci :
- Bien que les Diagnostics Settings soient disponibles au niveau de l’environnement Azure Container Apps, ils ne le sont pas encore pour Azure Function. Cela s’explique par une infrastructure sous-jacente différente. Microsoft travaille actuellement sur ce point, notamment avec l’intégration du support d’OpenTelemetry dans Azure Application Insights.
- À ce jour, la fonctionnalité d’auto-instrumentation d’Application Insights n’est pas encore compatible avec le worker PowerShell, qui reste pourtant un des favoris.
La conséquence de ce manque se voit lorsqu’on essaie de consulter les invocations de nos Azure Functions. Cela semble vide.
Après quelques investigations, il apparaît que cette fonctionnalité n’est pas encore supportée pour PowerShell. En attendant, une solution existe : Azure Container Apps intègre nativement le .NET Aspire Dashboard. Il suffit d’activer cette option pour bénéficier de ce tableau de bord.
Conclusion
Depuis sa disponibilité en GA fin mai 2024, Azure Function on Container Apps reste une solution récente, ce qui explique les quelques limitations et contraintes observées. Cependant, l’environnement Azure Container Apps offre une grande flexibilité en permettant d’isoler plusieurs Azure Functions au sein d’un VNET dédié, simplifiant ainsi la configuration par rapport à l’utilisation de Private Endpoint ou VNET Integration.
En matière de performances, Azure Container Apps propose des instances optimisées, avec une amélioration notable dans la gestion du Cold Start grâce à la possibilité de configurer des instances en Always Ready.
Enfin, un autre avantage notable est la réutilisabilité de l’environnement Azure Container Apps pour divers usages. Personnellement, j’utilise souvent les Azure Container Apps Jobs couplés à Keda (Kubernetes Event-driven Autoscaler) pour déployer des GitHub Action Runners à la demande. Je développerai ce sujet dans un prochain article consacré à Azure Container Apps.
Quelques liens pour approfondir
En attendant, voila quelques liens pour approfondir :
