Vue d’ensemble du Runbook Worker hybride d’Automation
Important
Le Runbook Worker hybride d’utilisateur basé sur l’agent Azure Automation (Windows et Linux) a été mis hors service le 31 août 2024 et n’est plus pris en charge. Suivez les instructions pour migrer à partir d’un Runbook Workers hybrides d’utilisateur basé sur l’agent existant vers des Workers hybrides basés sur l’extension.
Dans Azure Automation, les Runbooks peuvent ne pas avoir accès aux ressources d’autres clouds ou de votre environnement local, car ils s’exécutent dans la plateforme cloud Azure. Vous pouvez utiliser la fonctionnalité Runbook Worker hybride d’Azure Automation pour exécuter des runbooks directement sur la machine qui héberge le rôle et sur les ressources de l’environnement afin de gérer ces ressources locales. Les runbooks sont stockés et gérés dans Azure Automation et remis ensuite à une ou plusieurs machines assignées.
Azure Automation assure l’intégration native du rôle Runbook Worker hybride par le biais de l’infrastructure d’extension de machine virtuelle Azure. L’agent VM Azure est responsable de la gestion de l’extension sur les machines virtuelles Azure sous Windows et Linux, et l’agent Azure Connected Machine sur les machines non-Azure, notamment les serveurs avec Azure Arc et VMware vSphere avec Azure Arc (préversion). À présent, deux plateformes d’installation de Runbooks Workers hybrides sont prises en charge par Azure Automation.
| Plate-forme | Description |
|---|---|
| Basé sur une extension (V2) | Installée à l’aide de l’extension de machine virtuelle de Runbook Worker hybride, sans aucune dépendance vis-à-vis de l’agent Log Analytics qui rend compte à un espace de travail Log Analytics Azure Monitor. Il s’agit de la plateforme recommandée. |
| Basé sur des agents (V1) | Installée après l’achèvement de l’agent Log Analytics qui rend compte à un espace de travail Log Analytics Azure Monitor. |
Pour les opérations sur les Runbooks Workers hybrides après l’installation, le processus d’exécution des runbooks sur des Runbooks Workers hybrides est le même. L’objectif de l’approche basée sur une extension est de simplifier l’installation et la gestion du rôle Runbook Worker hybride et de supprimer la complexité liée à l’utilisation de la version basée sur un agent. La nouvelle installation basée sur une extension n’a pas d’impact sur l’installation ou la gestion d’un rôle Runbook Worker hybride basé sur un agent. Les deux types de runbook Worker hybrides peuvent coexister sur la même machine.
Le Runbook Worker hybride basé sur une extension prend uniquement en charge le type Runbook Worker hybride utilisateur et n’inclut pas le Runbook Worker hybride système requis pour la fonctionnalité Update Management.
Avantages des workers hybrides utilisateur basés sur une extension
L’approche basée sur les extensions simplifie considérablement l’installation et la gestion du Runbook Worker hybride de l’utilisateur, ce qui supprime la complexité de l’utilisation de l’approche basée sur un agent. Voici quelques-uns des principaux avantages :
- Intégration transparente : l’approche basée sur l’agent pour l’intégration du Runbook Worker hybride dépend de l’agent Log Analytics, qui est un processus en plusieurs étapes, chronophage et sujet aux erreurs. L’approche basée sur les extensions ne dépend plus de l’agent Log Analytics.
- Facilité de gestion : Intégration native avec une identité ARM pour le Runbook Worker hybride, et offre la flexibilité nécessaire pour une gouvernance à grande échelle en s’appuyant sur des stratégies et des modèles.
- Authentification basée sur Microsoft Entra ID – Il utilise des identités gérées attribuées par le système de machine virtuelle fournies par Microsoft Entra ID. Cela permet de centraliser le contrôle et la gestion des identités et des informations d’identification des ressources.
- Expérience unifiée : elle offre une expérience identique pour la gestion des machines Azure et hors Azure Arc.
- Plusieurs canaux d’intégration : vous pouvez choisir d’intégrer et de gérer les workers basés sur les extensions via les Portail Azure, les applets de commande PowerShell, Bicep, les modèles ARM, l’API REST et Azure CLI. Vous pouvez également installer l’extension sur une machine virtuelle Azure existante ou un serveur avec Arc dans l’expérience Portail Azure de cette machine via le panneau Extensions.
- Mise à niveau automatique par défaut : il offre une mise à niveau automatique des versions mineures par défaut, ce qui réduit considérablement la facilité de gestion de rester à jour sur la dernière version. Nous vous recommandons d’activer les mises à niveau automatiques pour tirer parti des mises à jour de sécurité ou de fonctionnalités sans surcharge manuelle. Vous pouvez aussi désactiver les mises à jour automatiques à tout moment. Les mises à niveau de version majeures ne sont actuellement pas prises en charge et doivent être gérées manuellement.
Types de Runbook Worker
Il existe deux types de Runbook Worker : système et utilisateur. Le tableau suivant décrit les différences entre les deux.
| Type | Description |
|---|---|
| Système | Prend en charge un ensemble de runbooks masqués utilisés par la fonctionnalité Update Management et conçus pour installer des mises à jour spécifiées par l’utilisateur sur des ordinateurs Windows et Linux. Ce type de Runbook Worker hybride n’est pas membre d’un groupe de Runbooks Workers hybrides et, par conséquent, n’exécute pas de runbooks qui ciblent un groupe de Runbooks Workers. |
| Utilisateur | Prend en charge les runbooks définis par l'utilisateur destinés à s'exécuter directement sur les machines Windows et Linux. |
Les Runbooks Worker hybrides basés sur un agent (v1) dépendent de l’agent Log Analytics qui rapporte à un espace de travail Log Analytics Azure Monitor. L’espace de travail ne collecte pas seulement des données de monitoring sur la machine, il télécharge aussi les composants nécessaires pour installer le Runbook Worker hybride basé sur agent.
Quand la solution Update Management d’Azure Automation est activée, toute machine connectée à votre espace de travail Log Analytics est automatiquement configurée en tant que Runbook Worker hybride système. Pour la configurer en tant que Runbook Worker hybride Windows utilisateur, consultez Déployer un Runbook Worker hybride Windows basé sur un agent dans Automation ou Déployer un Runbook Worker hybride Linux basé sur un agent dans Automation.
Limites de Runbook Worker
Le tableau suivant indique le nombre maximal de Runbook Worker hybrides système et utilisateur dans un compte Automation. Si vous avez plus de 4 000 machines à gérer, nous vous recommandons de créer un autre compte Automation.
| Type de Worker | Nombre maximum pris en charge par un compte Automation. |
|---|---|
| System | 4000 |
| Utilisateur | 4000 |
Comment fonctionne-t-il ?
Chaque Runbook Worker hybride utilisateur est membre d'un groupe Runbook Worker hybride que vous spécifiez lorsque vous installez le worker. Un groupe peut inclure un seul worker, mais vous pouvez inclure plusieurs workers dans un groupe pour une haute disponibilité. Chaque machine peut héberger un Runbook Worker hybride rendant compte à un compte Automation. Vous ne pouvez pas inscrire le Worker hybride dans plusieurs comptes Automation. Un worker hybride ne peut écouter des travaux qu’à partir d’un seul compte Automation.
Les machines qui hébergent le Runbook Worker hybride système géré par Update Management peuvent être ajoutées à un groupe Runbook Worker hybride. Toutefois, vous devez utiliser le même compte Automation pour Update Management et l’appartenance au groupe de Runbook Workers hybrides.
Un groupe de Workers hybrides avec Runbook Workers hybride est conçu pour une haute disponibilité et un équilibrage de charge en allouant des travaux entre plusieurs Workers. Pour une exécution réussie des runbooks, les travailleurs hybrides doivent être en bonne santé et donner un battement de cœur. Le Worker hybride fonctionne sur un mécanisme d’interrogation pour récupérer des travaux. Si aucun des travailleurs du groupe de travailleurs hybrides n'a envoyé une requête ping au service Automation au cours des 30 dernières minutes, cela implique que le groupe n'avait aucun travailleur actif. Dans ce scénario, les tâches seront suspendues après trois tentatives.
Lorsque vous démarrez un runbook sur un Runbook Worker hybride d’utilisateur, vous spécifiez le groupe sur lequel il s’exécute et vous ne pouvez pas spécifier un Worker particulier. Chaque Worker hybride actif du groupe interroge les travaux toutes les 30 secondes pour voir si des travaux sont disponibles. Le travailleur choisit les emplois selon le principe du premier arrivé, premier servi. En fonction du moment où une tâche a été poussée, quel que soit le travailleur hybride du groupe de travailleurs hybrides qui envoie une requête ping au service Automation, il récupère en premier la tâche. Le temps de traitement de la file d’attente des travaux dépend également du profil matériel et de la charge du Worker hybride.
Un seul travailleur hybride peut généralement récupérer 4 tâches par ping (c'est-à-dire toutes les 30 secondes). Si votre taux de transmission de tâches est supérieur à 4 toutes les 30 secondes et qu'aucun autre travailleur ne reprend la tâche, la tâche peut être suspendue avec une erreur.
Un Runbook Worker hybride est exempt de bon nombre des limites de ressources de bac à sable (sandbox) Azure en matière d’espace disque, de mémoire ou de sockets réseau. Les limites d’un worker hybride sont uniquement liées aux ressources de ce dernier, et elles ne sont pas limitées par la limite de temps en matière de répartition de charge équilibrée que présentent les bacs à sable Azure.
Pour contrôler la distribution de runbooks sur les Runbook Workers hybrides, ainsi que le moment ou la façon dont les travaux sont déclenchés, vous pouvez inscrire le worker hybride dans différents groupes Runbook Worker hybrides dans votre compte Automation. Ciblez les travaux sur le ou les groupes spécifiques afin de prendre en charge votre organisation d’exécution.
Scénarios courants pour les Runbooks Workers hybrides utilisateur
- Pour exécuter les runbooks Azure Automation pour la gestion des machines virtuelles invitées directement sur une machine virtuelle Azure existante et un serveur hors Azure inscrits en tant que serveur avec Azure Arc activé ou machine virtuelle VMware avec Azure Arc activé (préversion). Les serveurs avec Azure Arc activé peuvent être des machines virtuelles et serveurs physiques Windows et Linux hébergés en dehors d’Azure sur votre réseau d’entreprise ou sur d’autres fournisseurs cloud.
- Pour surmonter la limitation du bac à sable Azure Automation, les scénarios courants incluent l’exécution d’opérations de longue durée au-delà de la limite de trois heures pour les travaux cloud, l’exécution d’opérations d’automatisation gourmandes en ressources, l’interaction avec des services locaux exécutés sur site ou dans un environnement hybride, l’exécution de scripts qui nécessitent des autorisations élevées.
- Pour surmonter les restrictions de l’organisation afin de conserver les données dans Azure pour des raisons de gouvernance et de sécurité : comme vous ne pouvez pas exécuter des travaux Automation sur le cloud, vous pouvez les exécuter sur une machine locale intégrée en tant que Runbook Worker hybride utilisateur.
- Pour automatiser des opérations sur plusieurs ressources hors d’Azure exécutant des environnements locaux ou multiclouds. Vous pouvez intégrer une de ces machines en tant que Runbook Worker hybride utilisateur et cibler l’automatisation sur les autres machines dans un environnement local.
- Pour accéder à d’autres services en privé à partir du réseau virtuel Azure (VNet) sans ouvrir de connexion Internet sortante, vous pouvez exécuter des runbooks sur un Hybrid Worker connecté au VNet Azure.
Installation de Runbook Worker hybride
Le processus d’installation d’un Runbook Worker hybride utilisateur diffère selon le système d’exploitation. Le tableau ci-dessous définit les types de déploiement.
| Système d'exploitation | Types de déploiement |
|---|---|
| Windows | Automatisé Manuel. |
| Linux | Manuel |
| Vous pouvez soit utiliser | Pour les Runbooks Worker hybrides utilisateur, consultez Déployer un Runbook Worker hybride utilisateur Windows ou Linux basé sur une extension dans Automation. Il s’agit de la méthode recommandée. |
Remarque
Runbook Worker hybride n’est actuellement pas pris en charge sur les groupes identiques de machines virtuelles.
Planification réseau
Pour plus d’informations sur les ports, les URL et la mise en réseau qui sont requis pour le Runbook Worker hybride, consultez Configuration réseau d’Azure Automation.
Utilisation du serveur proxy
Si vous utilisez un serveur proxy pour la communication entre Azure Automation et les machines exécutant l’agent Log Analytics, veillez à ce que les ressources appropriées soient accessibles. Le délai d’expiration pour les demandes du Runbook Worker hybride et des services Automation est de 30 secondes. Après trois tentatives, une demande échoue.
Utilisation du pare-feu
Si vous utilisez un pare-feu pour restreindre l’accès à Internet, vous devez configurer le pare-feu pour autoriser l’accès. Si vous utilisez la passerelle Log Analytics en tant que proxy, vérifiez qu’elle est configurée pour les Runbooks Workers hybrides. Consultez Configurer de la passerelle Log Analytics pour les Runbooks Workers hybrides Azure Automation.
Étiquettes de service
Azure Automation prend en charge les étiquettes de service de réseau virtuel Azure, à commencer par l’étiquette de service GuestAndHybridManagement. Vous pouvez utiliser des étiquettes de service pour définir des contrôles d’accès réseau sur des groupes de sécurité réseau ou sur le pare-feu Azure. Les étiquettes de service peuvent être utilisées à la place d’adresses IP spécifiques pendant la création de règles de sécurité. En spécifiant le nom d’étiquette de service GuestAndHybridManagement dans le champ source ou de destination approprié d’une règle, vous pouvez autoriser ou refuser le trafic pour le service Automation. Cette étiquette de service ne permet pas d’autoriser un contrôle plus précis en limitant les plages d’adresses IP à une région spécifique.
L’étiquette de service du service Azure Automation fournit uniquement les adresses IP utilisées pour les scénarios suivants :
- Déclencher des webhooks à partir de votre réseau virtuel
- Autoriser les Runbooks Worker hybrides ou les agents State Configuration de votre réseau virtuel à communiquer avec le service Automation
Remarque
L’étiquette de service GuestAndHybridManagement ne prend actuellement pas en charge l’exécution de tâches de runbook dans un bac à sable (sandbox) Azure, uniquement directement sur un Runbook Worker hybride.
Prise en charge d’Impact Level 5 (IL5)
Le Runbook Worker hybride d’Azure Automation peut être utilisé dans Azure Government pour prendre en charge les charges de travail Impact Level 5 dans l’une des deux configurations suivantes :
Machine virtuelle isolée. Une fois déployées, elles consomment la totalité de l’hôte physique pour cette machine, fournissant ainsi le niveau d’isolation nécessaire pour prendre en charge les charges de travail IL5.
Les hôtes dédiés Azure, qui fournissent des serveurs physiques capables d’héberger une ou plusieurs machines virtuelles et dédiés à un abonnement Azure.
Remarque
L’isolation de calcul via le rôle Runbook Worker hybride est disponible pour les clouds commerciaux Azure et le cloud US Government.
Adresses Update Management pour Runbook Worker hybride
En plus des adresses et des ports standard requis pour le Runbook Worker hybride, Update Management a d’autres exigences en matière de configuration du réseau décrites dans la section relative à la planification du réseau.
Azure Automation State Configuration sur un Runbook Worker hybride
Vous pouvez exécuter Azure Automation State Configuration sur un Runbook Worker hybride. Pour gérer la configuration des serveurs qui prennent en charge le Runbook Worker hybride, vous devez les ajouter en tant que nœuds DSC. Consultez Activer la gestion des machines par Azure Automation State Configuration.
Runbooks sur un Runbook Worker hybride
Vous pouvez faire en sorte que les runbooks gèrent les ressources sur la machine locale ou qu’ils s’exécutent sur des ressources de l’environnement local dans lequel un Runbook Worker hybride utilisateur est déployé. Dans ce cas, vous pouvez choisir d’exécuter vos runbooks sur le Worker hybride plutôt que dans un compte Automation. Les runbooks exécutés sur un runbook Worker hybride sont identiques en structure à ceux que vous exécutez dans le compte Automation. Consultez Exécuter des runbooks sur un runbook Worker hybride.
Travaux Runbook Worker hybride
Les travaux du Runbook Worker hybride s’exécutent sous le compte Système local sur Windows, ou le compte nxautomation sur Linux. Azure Automation gère les travaux exécutés sur des Runbooks Workers hybrides différemment des travaux exécutés dans des bacs à sable Azure. Consultez Environnement d’exécution de runbook.
Si la machine hôte du runbook Worker hybride redémarre, tous les travaux du runbook en cours d’exécution redémarrent au début ou au dernier point de contrôle pour les runbooks PowerShell Workflow. Quand un travail de runbook a redémarré plus de trois fois, il est suspendu.
Autorisations d’un Runbook Worker hybride
Étant donné qu’ils accèdent à des ressources non-Azure, les runbooks s’exécutant sur un Runbook Worker hybride utilisateur ne peuvent pas utiliser le mécanisme d’authentification généralement utilisé par les runbooks pour s’authentifier auprès des ressources Azure. Un runbook peut fournir sa propre authentification auprès des ressources locales ou en configurer une à l’aide d’identités managées pour les ressources Azure. Vous pouvez également spécifier un compte d’identification pour fournir un contexte utilisateur pour l’ensemble des runbooks.
Afficher les Runbooks Workers hybrides système
Une fois la fonctionnalité Update Management activée sur les machines Windows ou Linux, vous pouvez inventorier la liste du groupe Runbook Workers hybrides système dans le portail Azure. Vous pouvez afficher un maximum de 2 000 Workers sur le portail en sélectionnant l'onglet Groupe de Workers hybrides du système de l'option Groupe de Workers hybrides dans le volet de gauche du compte Automation sélectionné.
Si vous disposez de plus de 2 000 Workers hybrides, pour obtenir la liste complète de ceux-ci, vous pouvez exécuter le script PowerShell suivant :
Get-AzSubscription -SubscriptionName "<subscriptionName>" | Set-AzContext
$workersList = (Get-AzAutomationHybridWorkerGroup -ResourceGroupName "<resourceGroupName>" -AutomationAccountName "<automationAccountName>").Runbookworker
$workersList | export-csv -Path "<Path>\output.csv" -NoClobber -NoTypeInformation
Étapes suivantes
Pour apprendre à configurer vos Runbooks afin d’automatiser les processus dans votre centre de données local ou un autre environnement cloud, consultez la rubrique Exécuter des Runbooks sur un Runbook Worker hybride.
Pour savoir comment résoudre les problèmes de vos Runbook Workers hybrides, consultez Résoudre les problèmes liés à la fonctionnalité Runbook Worker hybride.