Azure Automation et l’intégration des services liés

Bien au-delà des étapes de déploiement qui ne représentent qu’une toute petite partie de ce que doit apporter une solution Cloud, l’automatisation vient bien en complément et permet l’intégration de bout en bout.

Azure Automation : Quel rôle ?

Mieux encore, l’imbrication des services se fait naturellement et les ajouts se font même si au départ, la solution n’a pas été pensée dans son ensemble. Souvent, il n’y a pas de prérequis particulier et pas de blocage lorsque la solution doit évoluer.
Cette intégration de services liés ou services imbriqués se fera au fil de l’eau et des besoins, étape par étape.
Les exemples sont nombreux, et le sujet IAAS est l’un des sujets qui permet de mettre en lumière ces services liés.

Les Enjeux de l’IAAS

L’environnement d’infrastructure est en place et rapidement, les tâches d’exploitation, d’évolution ou de maintien en condition opérationnelle sont attendues. Effectivement, l’infrastructure en tant que service (IAAS) ne décharge pas l’exploitant de la gestion de son infrastructure et / ou des actions d’installation et de paramétrage.

Le scénario suivant présente une mise en place en 3 étapes pour :

• Garantir les configurations et faire évoluer le parc
• Assurer le reporting et les audits
• Alerter si des actions non désirées sont réalisées (maladresse, malveillance …etc.)

Ces services sont proposés par une brique très complète d’automatisation, Azure Automation.

Garantir les configurations et faire évoluer le parc

Ici, Powershell DSC est utilisé. Cette solution est sans aucun doute la meilleure dès lors qu’il s’agit d’un environnement de machine Windows (utilisable aussi pour des machines Linux, sujet non abordé). Gratuit et parfaitement intégré puisque activé par défaut sur Windows Serveur, Powershell DSC utilise un format déclaratif pour réaliser des actions de conformité ou de déploiement sur les machines. Par exemple, la présence de clefs de registre, de fichiers, le mode de démarrage des services, l’installation de fonctionnalités Windows…etc. Puis, ces configurations sont maintenues et les machines sont remises en conformité au fil de l’eau et automatiquement si les paramètres désirés sont modifiés.

Si la mise en place OnPremise demande l’installation d’un serveur dédié, DSC est mis en place en tant que service sur Azure. C’est-à-dire sans machine mais beaucoup plus simplement depuis le portail Azure. Sur le compte automation, le menu « Configuration Management » propose l’option « State configuration (DSC) ».

On réalise à la souris et sans difficulté notre configuration d’état. La configuration peut être « composée » en quelques clics (Compose configuration) ou même être issue d’une galerie à disposition (Gallery).

Ici, une configuration de base a été choisie.

Le nœud est ajouté, il devient client du service, récupère, applique et réapplique sa configuration. Cette intégration de service donne lieu à un premier niveau de rapport avec un état Compliant.

A la fin de cette étape 1, et en quelques actions, l’infrastructure a été enrichie d’un service lié assurant la conformité des machines.

Assurer le reporting et les audits

Le reporting proposé dans l’étape précédente est assez basique et permet en lecture rapide de connaître l’état de conformité de son parc. Ce niveau de log peut se révéler insuffisant.
L’activation des logs de recherche et la possibilité de réaliser un reporting plus complet sont proposées dans le menu, « Enable Log Search ».

Cette activation se fait en liant la collecte de log DSC à un espace de travail (Microsoft.OperationalInsights/workspaces). Ainsi, les logs sont envoyés, consolidés et prêts à être exploités.

Le service Log Analytics va être utilisé, c’est un nouveau service, une nouvelle brique à lier à l’ensemble existant => Machines IAAS + Service State Configuration DSC. L’interface Logs Analytics  permet de réaliser des requêtes d’état qui ne nécessitent aucune connaissance de langage. Elles se constituent depuis l’interface graphique. Les attributs sont ajoutés et constituent une requête. Le « pré filtre » est positionné sur DSC puis les attributs sont ajoutés à la souris. Le choix se fait dans l’exemple suivant sur un état de conformité (Compliance).

Exemple pour cette requête de vérification de conformité.

A la fin de cette étape 2, et en quelques actions, l’infrastructure est enrichie d’un service lié de rapport d’état. Les rapports sont visualisables sous forme de tableaux ou de graphiques.

Alerter si des actions non désirées sont réalisées (maladresse, malveillance …etc.) 

Le reporting créé dans l’étape précédente peut être enrichi d’une solution d’alerting. C’est un nouveau service, une nouvelle brique à lier à l’ensemble existant => Machines IAAS + Service State Configuration DSC + Log Analytics.
La requête de visualisation précédente permet (même si ce n’est pas obligatoire) de paramétrer le service d’alerting.  Depuis la requête apparaît une option « New alert rule ».

La requête d’état va donc constituer en partie la requête d’alerte pour des machines non conformes. L’écran d’alerte conserve les paramètres de la requête précédente (Search query), reste à positionner une condition. Par exemple, alerter si le nombre de machines non conformes est supérieur à 0.
Puis une méthode d’alerte (SMS, mail …etc.).

Là encore, ces services sont intégrés, le paramétrage est basique. Quelle fréquence, quelle type d’alerte, quel destinataire. Lorsque la conformité d’une machine n’est plus garantie, l’administrateur du parc reçoit instantanément un SMS d’alerte.

Quelques clics (seulement) ont été nécessaires pour lier des services à un environnement d’infrastructure déployé sans pré requis particulier, mais pour lequel la brique Azure Automation permet d’ajouter, d’imbriquer des services liés et très complémentaires !

Une très bonne chose pour l’ensemble du parc.

Pour aller plus loin sur ces thèmes : Quelle solution de Compute pour Azure ? · iTPro.fr