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

Azure Active Directory
Event Grid
Fonctions
Logic Apps
Monitor

L’automatisation des workflows et des tâches répétitives sur le cloud à l’aide de technologies serverless permet de 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. Cette architecture de référence illustre deux 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. Event Grid surveille les événements de création de ressources, puis appelle une fonction Azure. La fonction interagit avec Azure Active Directory 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 Azure Active Directory sont simulées. Azure AD peut également être intégrés à l’aide du module PowerShell Azure AD ou de la bibliothèque ADAL pour Python.

  2. Réponse de limitation : Cette implémentation de référence surveille une base de données Cosmos DB pour la limitation. Des alertes Azure Monitor sont déclenchées quand les demandes d’accès aux données adressées à 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. Notez que le mode Autopilot CosmosDB (préversion) est une alternative à cette implémentation.

Automatisation du cloud serverless

Logo GitHub Les implémentations de référence de cette architecture sont disponibles sur GitHub.

Les fonctions de ces implémentations sont écrites en PowerShell et Python, deux des langages de script les plus courants utilisés dans le domaine de l’automatisation. Elles sont déployées à l’aide d’Azure Functions Core Tools dans Azure CLI. Vous pouvez également essayer une version préliminaire de la cmdlet PowerShell pour déployer et gérer Azure Functions.

Modèles automatisation basée sur les événements

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. L’implémentation de l’é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 machine virtuelle la nuit et la redémarrer le matin,
    • lire du contenu de stockage d’objets blob à intervalles réguliers et le convertir en document 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 tire parti 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, ainsi que de l’infrastructure. L’implémentation de la 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. L’implémentation de l’é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.

Architecture

L’architecture se compose des blocs 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. Dans les implémentations de référence, une fonction est appelée à l’aide d’une requête HTTP. 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.

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 HTTP.

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, Azure Active Directory 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.

Remarques relatives à la 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 de Cosmos DB est rapide.

Fiabilité de la fonction d’automatisation

Les fonctions durables, qui maintiennent l’état entre les appels, offrent une alternative à l’approche ci-dessus. Actuellement, elles sont uniquement prises en charge dans JavaScript et C#.

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. Les implémentations de référence utilisent Application Insights en tant que 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 ce billet de blog sur les modèles d’idempotence.

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.

Considérations relatives à la 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 les implémentations de référence, 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 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, à l’aide de l’intégration Easy Auth.

Notez que l’authentification au niveau de la fonction est la seule option disponible pour les groupes d’actions Azure Monitor.

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. Désormais, 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, 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

Identités managées pour les ressources Azure, une fonctionnalité Azure Active Directory, simplifie la manière dont la fonction s’authentifie et accède à d’autres ressources et services Azure. Géré par Azure AD, 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 implémentations de référence 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. 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.

Considérations relatives au coût

Utiliser la calculatrice de prix Azure pour estimer les coûts. Voici quelques-uns des 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 d’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 cette architecture, Azure Functions est utilisé pour des tâches telles que la mise à jour des étiquettes dans Azure Active Directory ou la modification de la configuration Cosmos DB avec mise à l’échelle les RU sur une valeur supérieure. Le plan de consommation est adapté à ce cas d’usage car ces tâches sont interactives, et pas continues.

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 Cosmos DB.

Dans cette architecture, lorsque les demandes d’accès aux données adressées à 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é 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.

Déployer la solution

Pour déployer les implémentations de référence pour cette architecture, consultez les étapes de déploiement sur GitHub correspondant au workflow souhaité.

Étapes suivantes

En savoir plus sur les implémentations serverless.