Automatisation du cloud basée sur les événements

L’automatisation des workflows et des tâches répétitives dans le cloud, au moyen de technologies serverless, peut considérablement améliorer la productivité de l’équipe DevOps d’une organisation. Un modèle serverless s’adapte mieux aux scénarios d’automatisation correspondant à une approche basée sur les événements.

Architecture

Scénarios

Cet article illustre deux principaux scénarios d’automatisation du cloud :

1. Étiquetage du centre de coûts : cette implémentation effectue le suivi des centres de coûts de chaque ressource Azure. Le service Azure Policy étiquette toutes les nouvelles ressources d’un groupe avec un ID de centre de coûts par défaut. Azure Event Grid supervise les événements de création de ressources, puis appelle une fonction Azure. La fonction interagit avec Microsoft Entra ID et valide l’ID du centre de coûts pour la nouvelle ressource. En cas de différence, elle met à jour l’étiquette et envoie un e-mail au propriétaire de la ressource. Par souci de simplicité, les requêtes REST pour Microsoft Entra ID sont simulées. Microsoft Entra ID peut également être intégré à l’aide du module Microsoft Graph PowerShell ou de la bibliothèque d’authentification Microsoft (MSAL) pour Python.

2. Réponse de limitation : cet exemple surveille une base de données Azure Cosmos DB pour la limitation. Des alertes d’Azure Monitor sont déclenchées quand les demandes d’accès aux données adressées à Azure Cosmos DB dépassent la capacité d’unités de requête (ou RU). Un groupe d’actions Azure Monitor est configuré pour appeler la fonction d’automatisation en réponse à ces alertes. La fonction met à l’échelle les RU sur une valeur supérieure, ce qui augmente la capacité et arrête les alertes.

L’implémentation de référence de ce scénario est disponible sur GitHub.

Les fonctions de ces scénarios d’automatisation du cloud serverless sont souvent écrites en PowerShell et Python, deux des langages de script les plus courants utilisés dans l’automatisation des systèmes. Elles sont déployées à l’aide d’Azure Functions Core Tools dans Azure CLI. Vous pouvez également utiliser la cmdlet Az.Functions PowerShell pour déployer et gérer Azure Functions.

Workflow

Les scénarios d’automatisation basée sur les événements sont mieux implémentés à l’aide d’Azure Functions. Ils suivent les modèles courants suivants :

• Répondre aux événements liés aux ressources. Il s’agit des réponses à des événements tels qu’une ressource ou un groupe de ressources Azure créé, supprimé, modifié, etc. Ce modèle utilise Event Grid pour déclencher la fonction pour de tels événements. Le scénario d’étiquetage du centre de coûts est une illustration de ce modèle. Voici d’autres scénarios courants :

  • accorder aux équipes DevOps l’accès aux nouveaux groupes de ressources,
  • envoyer une notification à DevOps lorsqu’une ressource est supprimée, et
  • répondre aux événements de maintenance pour des ressources telles que les machines virtuelles Azure.

• Tâches planifiées. Il s’agit généralement de tâches de maintenance exécutées à l’aide de fonctions déclenchées par un minuteur. Voici des exemples de ce modèle :

  • arrêter une ressource la nuit et la redémarrer le matin,
  • lire du contenu de Stockage Blob à intervalles réguliers et le convertir en document Azure Cosmos DB,
  • analyser régulièrement les ressources qui ne sont plus utilisées, les supprimer, et
  • procéder à des sauvegardes automatisées.

• Traiter les alertes Azure. Ce modèle profite de la facilité d’intégration des alertes Azure Monitor et des groupes d’actions avec Azure Functions. La fonction prend généralement des mesures correctives en réponse aux métriques, à l’analytique des journaux d’activité et aux alertes provenant des applications et de l’infrastructure. Le scénario de réponse de limitation est une illustration de ce modèle. Voici d’autres scénarios courants :

  • tronquer la table lorsque SQL Database atteint la taille maximale,
  • redémarrer un service sur une machine virtuelle lorsqu’il est arrêtée par erreur, et
  • envoyer des notifications en cas d’échec d’une fonction.

• Orchestrer avec les systèmes externes. Ce modèle permet l’intégration avec les systèmes externes, à l’aide de Logic Apps à des fins d’orchestration du workflow. Les connecteurs Logic Apps peuvent facilement s’intégrer à différents services tiers, ainsi qu’à des services Microsoft tels que Microsoft 365. Azure Functions peut être utilisé pour l’automatisation réelle. Le scénario d’étiquetage du centre de coûts illustre ce modèle. Voici d’autres scénarios courants :

  • surveiller les processus informatiques tels que les demandes de modification ou les approbations, et
  • envoyer une notification par e-mail une fois la tâche d’automatisation terminée.

• Exposer en tant que webhook ou API. Les tâches d’automatisation à l’aide d’Azure Functions peuvent être intégrées à des applications tierces, voire à des outils de ligne de commande, en exposant la fonction en tant que webhook/API moyennant un déclencheur HTTP. Plusieurs méthodes d’authentification sont disponibles dans PowerShell et Python pour sécuriser l’accès externe à la fonction. L’automatisation intervient en réponse aux événements externes spécifiques à l’application, par exemple, une intégration avec Power Apps ou GitHub. Scénarios courants :

  • déclencher l’automatisation pour un service défaillant et,
  • intégrer des utilisateurs aux ressources de l’organisation.

• Créer une interface ChatOps. Ce modèle permet aux clients de créer une interface opérationnelle basée sur les conversations et d’exécuter des commandes ainsi que des fonctions de développement et d’exploitation en ligne avec intervention humaine. Il peut s’intégrer à Azure Bot Framework et utiliser les commandes Microsoft Teams ou Slack pour le déploiement, la surveillance, les questions courantes, etc. Une interface ChatOps crée un système en temps réel pour gérer les incidents de production, et chaque étape est automatiquement documentée dans la conversation. Pour plus d’informations, consultez Comment ChatOps facilite les opérations DevOps.

• Automatisation hybride. Ce modèle utilise les connexions hybrides Azure App Service pour installer un composant logiciel sur votre ordinateur local. Ce composant permet un accès sécurisé aux ressources sur cet ordinateur. La possibilité de gérer des environnements hybrides est actuellement disponible sur les systèmes Windows à l’aide de fonctions PowerShell. Scénarios courants :

  • gérer vos machines locales, et
  • gérer d’autres systèmes derrière le pare-feu (par exemple, une instance SQL Server locale) via un serveur de rebond.

Composants

L’architecture est constituée des composants suivants :

• Azure Functions. Dans cette architecture, Azure Functions fournit des fonctionnalités de calcul serverless basées sur les événements. Une fonction exécute des tâches d’automatisation lorsqu’elle est déclenchée par des événements ou des alertes. Cette fonction est appelée avec une requête HTTP dans deux scénarios. La complexité du code doit être réduite, en développant la fonction sans état et idempotente.

  Plusieurs exécutions d’une fonction idempotente produisent des résultats similaires. Pour gérer idempotence, la mise à l’échelle de fonction dans le scénario de limitation reste simpliste. En situation réelle, veillez à effectuer un scale-up ou un scale-down. Pour connaître les meilleures pratiques en matière d’écriture de fonctions, consultez Optimisation des performances et de la fiabilité d’Azure Functions.

• Azure Logic Apps. Logic Apps peut être utilisé pour effectuer des tâches simples et faciles à implémenter à l’aide des connecteurs intégrés. Il peut, par exemple, s’agir de notifications par e-mail ou d’une intégration à des applications de gestion externes. Pour savoir comment utiliser Logic Apps avec des applications tierces, consultez Intégration d’entreprise de base dans Azure.

  Logic Apps fournit un concepteur visuel avec peu ou pas de code et peut être utilisé seul dans certains scénarios d’automatisation. Pour connaître le service adapté à votre scénario, consultez cette comparaison entre Azure Functions et Logic Apps.

• Event Grid. Event Grid offre une prise en charge intégrée des événements issus d’autres services Azure, ainsi que des événements personnalisés (également appelés rubriques personnalisées). Les événements opérationnels, tels que la création de ressources, peuvent être facilement propagés à la fonction d’automatisation à l’aide du mécanisme intégré d’Event Grid.

  Event Grid simplifie l’automatisation basée sur les événements avec un modèle publish-subscribe, ce qui permet une automatisation fiable des événements remis via HTTPS.

• Azure Monitor. Les alertes Azure Monitor permettent de surveiller les conditions critiques et de prendre des mesures correctives moyennant des groupes d’actions Azure Monitor. Ces groupes d’actions s’intègrent facilement à Azure Functions. Ils sont utiles pour surveiller et corriger les conditions d’erreur de votre infrastructure, telles que la limitation de la base de données.

• Action d’automatisation. Ce bloc représente d’autres services avec lesquels votre fonction peut interagir afin de fournir la fonctionnalité d’automatisation. Par exemple, Microsoft Entra ID pour la validation des étiquettes comme dans le premier scénario, ou une base de données à approvisionner comme dans le deuxième scénario.

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Microsoft Azure Well-Architected Framework.

Résilience

Azure Functions

Gérer les délais d’expiration HTTP

Pour éviter les délais d’expiration HTTP liés à une tâche d’automatisation plus longue, mettez en file d’attente cet événement dans un Service Buset gérez l’automatisation dans une autre fonction. Le scénario d’automatisation de la réponse de limitation illustre ce modèle, même si l’approvisionnement RU d’Azure Cosmos DB est rapide.

Durable Functions, qui maintiennent l’état entre les appels, offrent une alternative à l’approche ci-dessus. Durable Functions prennent uniquement en charge des langages spécifiques.

Consigner les échecs

En guise de meilleure pratique, la fonction doit consigner les échecs liés aux tâches d’automatisation et ce, afin de remédier aux conditions d’erreur. Azure Functions prend en charge l’intégration en mode natif avec Application Insights comme système de télémétrie.

Accès concurrentiel

Vérifiez l’exigence de concurrence de votre fonction d’automatisation. L’accès concurrentiel est limité en définissant la variable maxConcurrentRequests dans le fichier host.json. Ce paramètre limite le nombre d’instances de fonction concurrente en cours d’exécution dans votre application de fonction. Chaque instance consommant des ressources UC et de la mémoire, cette valeur doit être ajustée pour les opérations sollicitant fortement le processeur. Réduisez maxConcurrentRequests si vos appels de fonction semblent trop lents ou ne peuvent aboutir. Pour plus d’informations, consultez Configurer les comportements d’hôte pour mieux gérer l’accès concurrentiel.

Idempotence

Assurez-vous que votre fonction d’automatisation est idempotente. Azure Monitor et Event Grid peuvent émettre des alertes ou des événements indiquant une progression telle que votre événement abonné est résolu, déclenché, en cours, etc., que votre ressource est en cours d’approvisionnement, créée, etc., ou même envoyer des alertes erronées en raison d’une configuration incorrecte. Veillez à ce que votre fonction agisse uniquement sur les alertes et les événements pertinents, tout en ignorant les autres, pour éviter que les événements erronés ou mal configurés ne produisent de résultats indésirables. Pour plus d'informations, consultez Conception d’Azure Functions pour une entrée identique.

Event Grid

Si votre workflow utilise Event Grid, vérifiez si votre scénario peut générer un volume élevé d’événements, suffisant pour saturer la grille. Pour comprendre comment Event Grid gère les événements en l’absence d’accusé de réception suite à une distribution et modifier votre logique en conséquence, consultez Distribution et nouvelle tentative de distribution de messages avec Azure Grid. Le workflow du centre de coûts n’implémente pas de vérifications supplémentaires, car il surveille uniquement les événements de création de ressources dans un groupe de ressources. La surveillance des ressources créées dans un abonnement entier peut générer un plus grand nombre d’événements, ce qui implique une gestion plus résiliente.

Azure Monitor

Si un nombre suffisamment élevé d’alertes sont générées et que l’automatisation met à jour les ressources Azure, les limites de la limitation Azure Resource Manager peut être atteintes. Cela peut avoir un impact négatif sur le reste de l’infrastructure de cet abonnement. Pour éviter une telle situation, limitez la fréquence des alertes générées par Azure Monitor. Vous pouvez également limiter les alertes générées pour une erreur donnée. Pour plus d’informations, consultez la documentation relative aux alertes Azure Monitor.

Sécurité

La sécurité fournit des garanties contre les attaques délibérées, et contre l’utilisation abusive de vos données et systèmes importants. Pour plus d’informations, consultez Vue d’ensemble du pilier Sécurité.

Contrôler l’accès à la fonction

Limitez l’accès à une fonction déclenchée par HTTP en définissant le niveau d’autorisation. Avec l’authentification anonyme, la fonction est facilement accessible à l’aide d’une URL telle que http://<APP_NAME>.azurewebsites.net/api/<FUNCTION_NAME>. L’authentification au niveau de la fonction peut obfusquer le point de terminaison http, en imposant des clés de fonction dans l’URL. Ce niveau est défini dans le fichier function.json :

{
  "bindings": [
    {
      "authLevel": "function",
      "type": "httpTrigger",
      "direction": "in",
      "name": "Request",
      "methods": [
        "get",
        "post"
      ]
    },
    {
      "type": "http",
      "direction": "out",
      "name": "Response"
    }
  ]
}

Dans un environnement de production, des stratégies supplémentaires peuvent être nécessaires afin de sécuriser la fonction. Dans ces scénarios, les fonctions sont exécutées au sein de la plateforme Azure par d’autres services Azure et ne sont pas exposées à Internet. L’autorisation de fonction est parfois suffisante pour les fonctions accessibles en tant que webhooks.

Envisagez d’ajouter des couches de sécurité en plus de l’authentification de fonction, par exemple,

• authentification avec certificats clients, ou
• vérification que l’appelant fait partie du répertoire qui héberge la fonction ou y a accès, en activant l’authentification App Service.

L’authentification au niveau de la fonction est la seule option disponible pour les groupes d’actions Azure Monitor qui utilisent Azure Functions.

Si la fonction doit être appelée à partir d’une application ou d’un service tiers, il est recommandé de fournir un accès avec une couche Gestion des API. Cette couche doit appliquer l’authentification. La Gestion des API dispose d’un niveau de consommation intégré à Azure Functions et vous ne payez que si l’API est exécutée. Pour plus d’informations, consultez Créer et exposer vos fonctions avec OpenAPI.

Si le service appelant prend en charge les points de terminaison de service ou la liaison privée, les options plus coûteuses suivantes peuvent être envisagées :

• Utilisez un plan App Service dédié vous permettant de verrouiller les fonctions dans un réseau virtuel afin d’en limiter l’accès. Cela n’est pas possible dans le cas d’un modèle serverless basé sur la consommation.
• Utilisez le plan Premium Azure Functions, qui comprend un réseau virtuel dédié à utiliser par vos applications de fonction.

Pour comparer la tarification et les caractéristiques de ces options, consultez Mise à l’échelle et hébergement dans Azure Functions.

Contrôler ce à quoi la fonction peut accéder

La fonctionnalité Microsoft Entra Identités managées pour les ressources Azure simplifie la manière dont la fonction s’authentifie et accède à d’autres ressources et services Azure. Puisqu’il est géré par Microsoft Entra ID, le code n’a pas besoin de gérer les informations d’authentification.

Il existe deux types d’identités administrées :

• Identités managées attribuées par le système : Ces identités sont créées dans le cadre de la ressource Azure et ne peuvent pas être partagées entre plusieurs ressources. Elles sont supprimées une fois la ressource supprimée. Utilisez-les pour les scénarios impliquant une seule ressource Azure ou nécessitant des identités indépendantes. Ces deux scénarios utilisent des identités attribuées par le système, car elles ne mettent à jour qu’une seule ressource. Les identités managées sont uniquement nécessaires pour mettre à jour une autre ressource. Par exemple, une fonction peut lire les étiquettes de ressource sans identité managée. Pour ajouter une identité attribuée par le système à votre fonction, consultez ces instructions.

• Identités managées attribuées par l’utilisateur: Ces identités sont créées en tant que ressources Azure autonomes. Elles peuvent être partagées entre plusieurs ressources et doivent être supprimées explicitement quand elles ne servent plus. Pour ajouter une identité attribuée par l’utilisateur à votre fonction, consultez ces instructions. Utilisez-les dans les scénarios qui :

  • Requièrent un accès à plusieurs ressources susceptibles de partager une même identité
  • Nécessitent une pré-autorisation pour sécuriser les ressources lors de l’approvisionnement
  • Disposent de ressources recyclées fréquemment, tandis que les autorisations doivent être cohérentes.

Une fois l’identité attribuée à la fonction Azure, attribuez-lui un rôle à l’aide du contrôle d’accès en fonction du rôle Azure (RBAC Azure) pour accéder aux ressources. Par exemple, pour mettre à jour une ressource, le rôle Contributeur doit être attribué à l’identité de la fonction.

Optimisation des coûts

L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez Vue d’ensemble du pilier d’optimisation des coûts.

Utiliser la calculatrice de prix Azure pour estimer les coûts. Voici quelques points à prendre en compte pour réduire les coûts.

Azure Logic Apps

Logic Apps dispose d’un modèle de tarification avec paiement à l’accès. Les déclencheurs, les actions et les exécutions de connecteur sont comptabilisés chaque fois qu’une application logique s’exécute. Toutes les actions qui réussissent et échouent, notamment les déclencheurs, sont considérées comme des exécutions.

Logic Apps dispose également d’un modèle de tarification fixe. Si vous devez exécuter des applications logiques qui communiquent avec des ressources sécurisées dans un réseau virtuel Azure, vous pouvez les créer dans un environnement de service d'intégration (ISE).

Pour plus de détails, consultez Modèle de tarif pour Azure Logic Apps.

Dans cette architecture, les applications logiques sont utilisées dans le scénario d’étiquetage du centre de coûts afin d’orchestrer le workflow.

Les connecteurs intégrés permettent de se connecter à Azure Functions et d’envoyer une notification par e-mail lorsqu’une tâche automatisation est terminée. Les fonctions sont exposées en tant que webhook/API à l’aide d’un déclencheur HTTP. Les applications logiques sont uniquement déclenchées en cas de requête HTTPS. Il s’agit là d’un moyen économique par rapport à une conception dans laquelle les fonctions interrogent et vérifient en permanence certains critères. Chaque requête d’interrogation est mesurée en tant qu’action.

Pour plus d’informations, consultez Tarifs Logic Apps.

Azure Functions

Azure Functions est disponible avec les trois plans tarifaires suivants.

• Plan de consommation. Il s’agit du plan serverless le plus économique disponible ; vous payez uniquement pour le temps d’exécution de votre fonction. Dans le cadre de ce plan, les fonctions peuvent s’exécuter jusqu’à 10 minutes à la fois.

• Plan Premium. Envisagez d’utiliser le plan Premium Azure Functions pour les scénarios d’automatisation présentant des exigences supplémentaires, telles qu’un réseau virtuel dédié, une durée d’exécution plus longue, etc. Ces fonctions peuvent s’exécuter jusqu’à une heure et sont à privilégier pour les tâches d’automatisation plus longues, telles que l’exécution de sauvegardes, l’indexation de base de données ou la génération de rapports.

• Plan App Service. Le plan App Service est adapté aux scénarios d’automatisation hybride utilisant les connexions hybrides d’Azure App Service. Les fonctions créées dans le cadre de ce plan peuvent s’exécuter pour une durée illimitée, comme pour une application web.

Dans ces scénarios d’automatisation, Azure Functions est utilisé pour des tâches telles que la mise à jour des étiquettes dans Microsoft Entra ID ou la modification de la configuration Azure Cosmos DB avec mise à l’échelle des RU sur une valeur supérieure. Le plan de consommation est adapté à ce cas d’usage, car ces tâches sont interactives, et pas durables.

Azure Cosmos DB

Azure Cosmos DB facture le débit approvisionné et le stockage consommé par heure. Le débit approvisionné est exprimé en unités de requête par seconde (RU/s), qui peuvent être utilisées pour les opérations de base de données classiques, comme les insertions et les lectures. Le stockage est facturé pour chaque Go utilisé pour vos données et index stockés. Pour plus d'informations, consultez Modèle de tarification Azure Cosmos DB.

Dans cette architecture, lorsque les demandes d’accès aux données adressées à Azure Cosmos DB dépassent la capacité d’unités de requête (ou RU), Azure Monitor déclenche des alertes. En réponse à ces alertes, un groupe d’actions Azure Monitor est configuré pour appeler la fonction d’automatisation. La fonction met à l’échelle les RU sur une valeur supérieure. Cela permet de réduire les coûts car vous payez uniquement les ressources dont vos charges de travail ont besoin sur une base horaire.

Pour obtenir une estimation rapide du coût de votre charge de travail, utilisez la calculatrice de capacité Azure Cosmos DB.

Pour plus d'informations, consultez la section Coûts de Microsoft Azure Well-Architected Framework.

Points à prendre en considération pour le déploiement

Pour les workflows d’automatisation critiques qui gèrent le comportement de votre application, un déploiement sans temps d’arrêt s’impose moyennant un pipeline DevOps efficace. Pour plus d’informations, consultez déploiement back-end serverless.

Si l’automatisation couvre plusieurs applications, conservez les ressources requises par l’automatisation dans un groupe de ressources distinct. Un même groupe de ressources peut être partagé entre l’automatisation et les ressources d’application, si l’automatisation couvre une même application.

Si le workflow implique un certain nombre de fonctions d’automatisation, regroupez les fonctions répondant à un scénario dans une même application de fonction. Pour plus d’informations, consultez Gérer une application de fonction.

L’application que vous déployez devra être surveillée. Envisagez d’utiliser Application Insights pour permettre aux développeurs de surveiller les performances et de détecter les problèmes.

Pour plus d'informations, consultez la section DevOps de Microsoft Azure Well-Architected Framework.

Mesures à prendre sur les ressources Azure

Dans les deux scénarios ci-dessus, le résultat final a conduit à une modification de l’état des ressources Azure par le biais d’une interaction Azure Resource Manager directe. Même si ce résultat était attendu, réfléchissez à l’impact que cela pourrait avoir sur votre environnement si les ressources modifiées avaient été déployées à l’origine de manière déclarative, par des modèles Bicep ou Terraform. Sauf si ces modifications sont répliquées à nouveau dans vos modèles sources, la prochaine utilisation de ces modèles peut annuler les modifications apportées par cette automatisation. Tenez compte de l’impact lié au fait de combiner des modifications impératives à des ressources Azure qui sont déployées régulièrement par le biais de modèles.

Déployer ce scénario

Pour déployer le scénario dU centre de coûts, consultez les étapes de déploiement sur GitHub.

Étapes suivantes

• Formation : Présentation d’Azure Functions
• Documentation : Présentation d’Azure Functions
• Qu'est-ce qu'Azure Event Grid ?

Ressources associées

• Présentation détaillée du code : Application serverless avec Fonctions
• Conception d’architecture des fonctions serverless
• Architectures de référence des fonctions serverless