Azure backup, quelques belles nouveautés

Niveau : ★★☆☆☆

Les services / fonctionnalités Azure évoluent sans cesse. Et c’est une bonne chose.

Azure Backup n’échappe pas à cette règle. Et c’est un service qui propose de plus en plus d’options et de paramètres. Sans faire ici une liste exhaustive des dernières évolutions, je vais revenir sur les plus marquantes, celles qui apportent un vrai plus à la fonctionnalité.

Avant de démarrer, un rappel rapide sur les 3 services (2 + 1) qu’Azure propose pour les sauvegardes.

Recovery Service Vault, le coffre qui offre le plus de fonctionnalités avec :

Des charges de travail Azure, Azure Stack Hub / HCI et des sauvegardes On-Premises. Et pour ces charges de travail, du backup pour les machines virtuelles, du partage de fichiers, du SQL sur machine virtuelle (du SQL sur un IAAS donc) et du SAP HANA sur VM Azure. Mais aussi toute la partie d’infra Site Recovery.

Backup Vault, différent et complémentaire. Du disque, du blob et du PostGreSQL.

Et pour finir, un service qui permet une gestion centralisée des sauvegardes, Backup Center.

Cette console est incroyablement complète, il faut consulter la documentation éditeur à cette adresse pour un tour complet de tout ce qu’elle propose (https://learn.microsoft.com/fr-fr/azure/backup/backup-center-overview?WT.mc_id=AZ-MVP-5003759).

Qu’elles sont les évolutions significatives pour ces quelques derniers mois et que peuvent elles apporter de plus ?

-La redondance des données a été améliorée avec l’arrivée pour le coffre Recovery Service d’une redondance de Zone. 3 niveaux sont donc dispo, LRS, ZRS et GRS. C’est une économie pour des environnements qui n’ont pas forcément besoin de données Géo-redondées mais pour lesquelles une redondance Locale est insuffisante. Attention toutefois, les paramètres de redondances ne sont plus modifiables à partir du moment ou le coffre héberge déjà des instances sauvegardées.

-La stratégie de backup ou Policy Enhanced pour le coffre Recovery Service ajoute une option qui ne se limite plus à une sauvegarde / jour.

Il est donc possible (même si c’est en Preview pour l’instant) d’avoir une fréquence de Backup comprise entre 4 et 12 heures).

Ce besoin était auparavant couvert par le Backup disque du Backup Vault. Il y a peut être un doublon, sauf éventullement pour des besoins très spécifiques.

-La sauvegarde CRR pour le coffre Recovery Service. C’est la possibilité de réaliser des sauvegardes et de les utiliser dans la région secondaire en cas de sinistre sur la région primaire. Cross région dans un premier temps, cette sauvegarde CRR est également depuis peu Cross Subscription. Cette fois, la boucle est bouclée. On comprend facilement que pour utiliser cette option, un stockage detype GRS est obligatoire pour le coffre. Infos et limitation sur ce lien https://learn.microsoft.com/fr-fr/azure/backup/backup-create-recovery-services-vault#set-cross-region-restore/?WT.mc_id=AZ-MVP-5003759

-Immutabilités des données pour le coffre Recovery Service et le Backup Vault. Et ? Pour faire quoi ? Je crois que ce texte de présentation de Microsoft est un excellent résumé de ce que va apporter l’immutabilité.

Avec les coffres immuables, Sauvegarde Azure vous offre une option pour vous assurer que les points de récupération qui sont créés ne peuvent pas être supprimés avant l’heure d’expiration prévue. Sauvegarde Azure effectue cette opération en empêchant toutes les opérations susceptibles d’entraîner une perte des données de sauvegarde. Par conséquent, cela vous aide à protéger vos sauvegardes contre les menaces telles que les attaques par ransomware et les acteurs malveillants en supprimant des opérations telles que la suppression de sauvegardes ou la réduction de la conservation dans les stratégies de sauvegarde.

Un indispensable !

-MUA ou Autorisation multi-utilisateur pour le coffre Recovery Service et le Backup Vault. C’est une couche de sécurité supplémentaire pour une gestion des droits de sauvegardes encore plus granulaires. C’est même beaucoup plus que ça puisque cela peut être couplé avec PIM / JIT. Du contrôle d’accès au travers d’une demande explicite sur le portail !!! J’ai besoin de ce type de droits pour cette durée. Et j’en fais la demande explicite ! Ouaouuuu !! Celles et ceux qui connaissent l’utilisation de PIM Azure sont (déjà) convaincus. Pour prendre connaissance du sujet PIM si vous n’avez jamais utilisé, c’est à voir ici : https://learn.microsoft.com/fr-fr/azure/active-directory/privileged-identity-management/pim-configure/?WT.mc_id=AZ-MVP-5003759

-Nouvelle gestion du monitoring et des alertes. Sujet que je ne connais pas encore assez, mais à creuser. Ce que je comprends pour l’instant, c’est qu’il va être possible du monitoring beaucoup plus pertinent sur la fonctionnalité Backup Azure.

Voici à mon avis les points les plus marquants sur ces derniers mois. Il y en à d’autre (j’attends vos commentaires 🙂 ), mais ce sont de très bonnes pistes pour faire évoluer son infrastructure de sauvegardes sur Azure.

Publicité

Private Endpoint Service Endpoint, quelles différences ?

Niveau : ★★★☆☆

Ce court sujet pour répondre à une question souvent posée, quelles différences entre le « service endpoint » et le « private endpoint » sur Azure.

Sans réexpliquer le fonctionnement détaillé, il faut comprendre le fonctionnement d’un service PAAS Azure et plus particulièrement son exposition réseau. Dans la grande majorité des cas, le PAAS est exposé publiquement, c’est à dire sur le réseau internet public. Ce qui sous entend qu’une machine VM Azure doit sortir sur le réseau public et revenir sur le réseau Azure pour se connecter à un service Azure.

Pour (entre autres choses) accroître la sécurité de ses services, il est intéressant de pouvoir réduire cette exposition.

C’est ce à quoi vont s’employer les fonctionnalités service endpoint et le private endpoint. Mais de façon très différente. Dans ce sujet, l’explication de deux des différences majeures. Il y en a des très nombreuses autres (https://learn.microsoft.com/fr-fr/azure/virtual-network/vnet-integration-for-azure-services/?WT.mc_id=AZ-MVP-5003759).

Ce qui est promis par le service endpoint, c’est ce qui est expliqué dans la documentation éditeur :

Aujourd’hui, le trafic du service Azure à partir d’un réseau virtuel utilise des adresses IP publiques en tant qu’adresses IP source. Avec les points de terminaison de service, le trafic de service change pour utiliser des adresses privées de réseau virtuel en tant qu’adresses IP source lors de l’accès au service Azure à partir d’un réseau virtuel. Ce changement permet d’accéder aux services sans avoir besoin d’adresses IP publiques réservées et utilisées dans les pare-feux IP.

Le + important, c’est de bien lire et bien comprendre ce qui est exposé dans la documentation => Ce changement permet d’accéder aux services sans avoir besoin d’adresses IP publiques réservées

J’insiste sur ce point, parce que j’ai discuté de cela à de très nombreuses occasions et il y a souvent une vue inexacte du fonctionnement. Parce qu’une lecture rapide de la doc et la consultation du schéma de cette même doc (voir ci-dessous) amène à l’erreur suivante … l’exposition public est désactivée pour le service (en jaune).

Ce qui est faux …

/!\ Le service NE PEUT PAS désactiver son adresse IP publique /!\

A la différence du private endpoint qui est une vraie privatisation du service. Une interface réseau est placée devant le service, et, en complément, il est possible de couper les accès public.

C’est ce que l’on retrouve sur le schéma suivant. Le private enpoint pesamba et son interface réseau pesamba-nic sont placés devant le compte de stockage titi, puis l’exposition publique est désactivée dans le menu Firewalls and virtual networks.

Voilà pour la première différence, elle est majeure.

Seconde différence, le scope.

Si l’on regarde ce qu’il se passe sur le PE (private endpoint) pesamba de l’exemple précédent, on remarque que le scope est à la maille d’une sous ressource blob.

C’est ce qui est permis par certaines ressources pour lesquelles un paramétrage très granulaire est possible. Un très bon exemple pour illustrer cela est le compte de stockage. Créer un PE pour un compte de stockage, c’est choisir ce qui va être placé derrière le PE. Ici en jaune, une ressource type Microsoft.Storage/storageAccounts, mais il faut aller plus loin (à la sous-ressource) pour valider le PE.

La granularité est ici poussée à son maximum. Seules les queues du compte de stockage titi sont exposées derrière le PE.

Même exercice en créant un service endpoint.

Ici, tous les types Microsoft.Storage pour le subnet ciblé. Là encore, la différence est majeure. Il existe pour affiner cette partie les service endpoint policy que l’on retrouvent sur l’image suivante.

Ces policy permettent de réduire le scope. Ici, seulement le compte de stockage stintermediaire dans le groupe de ressource rg-infra-test-001.

Voici pour 2 des différences majeures qu’il existe entre cette exposition de endpoint. Il y en a d’autres, à consulter dans la doc en lien un peu + haut sur le sujet.

Azure Spot Instance, comment et pourquoi, partie 3/3

Niveau : ★★★★☆

Avant d’aborder cette troisième partie, un lien vers les articles précédents :
Article 1 : https://thierrybtblog.wordpress.com/2022/12/12/azure-spot-instance-comment-et-pourquoi-partie-1-
Article 2 : https://thierrybtblog.wordpress.com/2022/12/19/azure-spot-instance-comment-et-pourquoi-partie-2-3/

Dans cette troisième et dernière partie, la solution est déployée dans un environnement de test.

Le déploiement se fait directement depuis le Git (https://github.com/mspnp/interruptible-workload-on-spot), il suffit de dérouler la procédure qui ne pose aucun soucis et ne prend que quelques minutes. Juste un point d’attention concernant les prérequis, l’installation de .NET 6.0 SDK est obligatoire pour le build qui va être réalisé dans la procédure.

A noter que je fais le choix de ne pas déployer la partie appelée Optional | Local Development qui propose 4 étapes supplémentaires pour aller un peu + loin avec le sujet. Je fais également le choix de ne pas « alléger » l’infra mise en place même s’il y a plusieurs ressources qui ne vont pas servir pendant les tests. Il y a quelques composants non essentiels qui sont facturés et qui sont un peu + coûteux. Mais une fois ce sujet terminé, le ressource groupe et les ressources seront supprimées immédiatement.

Le déploiement se fait à l’aide de Bicep et se termine avec le message "Succeeded".

Fin du déploiement pour la première partie.

Voilà pour la première partie, les ressources Azure sont maintenant Ok dans le RG de destination.

Ce sont ces quelques ressources qui constituent l’environnement de test. Il ne manque qu’une seule ressource à ce niveau du déploiement, la VM Spot.

Environnement de test, sources et images éditeurs.

Reste quelques commandes de Build pour terminer les opérations. Puis le déploiement de l’app (comprendre ici l’app hébergée dans la VM), de la VM Spot et le peuplement d’une queue de stockage sur le compte déjà provisionné.

Fin de provisionnement pour la VM Spot

C’est ici qu’il faut expliquer à quoi va servir cette instance Spot et ce qui a été préparé dans cet exercice (https://learn.microsoft.com/fr-fr/azure/architecture/guide/spot/spot-eviction#example-scenario/?WT.mc_id=AZ-MVP-5003759).
Avec le schéma très détaillé que propose l’éditeur et qui est expliqué dans le lien précédent. Typiquement une charge de travail interruptible. Ce schéma est plus détaillé que le précédent. Les points importants sont à souligner, je les ai encadré en noir dans la schéma et j’ai fléché en rouge dans ce même schéma.

En noir, les deux ressources avec lesquelles va discuter l’app. Ici l’extrait de la documentation qui expose très clairement la manière dont va fonctionner cette instance.

« le script orchestrate.sh installe une application Worker .NET qui exécute deux services d’arrière-plan. Le premier service interroge le point de terminaison Scheduled Events, recherche le signal Preempt et envoie ce signal au deuxième service. Le deuxième service traite les messages de la file d’attente de stockage et écoute le signal Preempt du premier service. Lorsque le deuxième service reçoit le signal, il interrompt le traitement de la file d’attente de stockage et commence l’arrêt. »

Cette Spot est capable de se « surveiller », de traiter la queue de message du compte de stockage tout en écoutant le endpoint de publication du preempt. Lorsqu’elle détecte un signal d’éviction, elle va stopper le traitement de la file d’attente et va stopper proprement ses services et autres process.

Du côté de la VM, préparation de 2 commandes pour « voir » ce qu’il se passe lors de l’évection. La première va surveiller le endpoint d’éviction, la seconde va lancer une éviction. Elle est appelée simulation d’éviction, mais elle réalise en fait une véritable éviction, sans attendre qu’Azure déclenche le mécanisme en cas de besoin de ressource (voir le chapitre 1/3 de ce sujet pour comprendre les règles d’éviction). Les commandes à destination du endpoint sont lancées depuis la Spot, la commande d’éviction depuis la CLI (portail, IDE …Etc).

curl -H Metadata:true http://169.254.169.254/metadata/scheduledevents?api-version=2019-08-01
az vm simulate-eviction -g rg-vmspot -n vm-spot

Attention, pour bien afficher toutes les informations, il faut lancer les commandes Curl depuis la VM (bastion a été déployé, la machine est donc exposée de manière complètement sécurisée : https://learn.microsoft.com/fr-fr/azure/bastion/bastion-overview/?WT.mc_id=AZ-MVP-5003759) et la commande d’éviction depuis la CLI.
Lorsque le endpoint est appelé la première fois, le retour de commande ne donne aucune information d’évènements

Events = Pas de contenu.

Lancer la commande d’éviction puis basculer de nouveau sur la Spot et lancer « en boucle » le Curl. Tout va très vite, il n’est pas toujours facile d’intercepter le contenu du endoint.

Events = nouvelles informations après déclenchement.

Même si l’impression écran est de petite taille, on comprend que la Spot vient de changer d’état. Après remise en forme du Json de retour de commande, on peut retrouver les informations sous cette forme :

Mise en forme du Json de retour

L’Event type est de type Preempt, la ressource est la vm-spot.

Dans le menu, au bout de quelques secondes, on trouve la ressource dans un état « Stopped (deallocated)« .

Le Status de la ressource est Stopped (deallocate)

Pour voir et revoir en action toutes ces étapes, il faut reprendre une partie de l’exercice. Comme la Spot a démarré, elle a déjà traité les 100 messages présents dans la queue. Il faut rejouer une petite partie du code pour peupler de nouveau la queue.

SA_NAME=$(az deployment group show -g rg-vmspot -n prereq --query properties.outputs.saName.value -o tsv)
for i in {1..100}; do az storage message put -q messaging --content $i --account-name $SA_NAME;done;

Puis reprendre les tests au besoin.

Cette solution pourrait être plus complète du côté des actions à lancer lorsque le signal d’éviction est intercepté. A commencer par l’indispensable, provisionner une Spot pour reprendre les traitements dans la queue de stockage. C’est à dire déclencher l’automatisation et recréer ce qui vient supprimé. Avec tout ce qui a été dit dans les 3 parties de ce sujet, on se tournera vers une autre région pour avoir + de chance de pouvoir créer une nouvelle Spot. Et pour rappel, cela ne pourra se faire que si la VM Spot est détruite (comme indiqué dans la partie 2/3).

Finalement, le plus …compliqué n’est pas de faire fonctionner l’instance et l’automatisation liée, mais plutôt d’identifier les applications / tâches / action …Etc qui sont éligibles à ce mode de fonctionnement

L’exemple déployé depuis le Git est un premier cas d’utilisation. La queue de stockage fait office de service de messagerie, les messages sont en attente d’être consommés, et pour peu qu’un traitement asynchrone soit possible pour une application, l’instance Spot est parfaitement adaptée. Il y a sûrement d’autres usages. Par exemple, ce qui est présenté dans cet article de Thomas (https://thomasrannou.azurewebsites.net/2021/05/12/utiliser-des-instances-spot-avec-aks/), spécialiste AKS.

Alors n’hésitez pas à partager vos idées sur le sujet.
Prochaine étape pour ma part, regarder du côté des runners (Git xxx, Azure Devops) si ce type de machine pourrait convenir.



Azure Spot Instance, comment et pourquoi, partie 2/3

Niveau : ★★★★☆

Avant d’aborder cette seconde partie, un lien vers l’article précédent : https://thierrybtblog.wordpress.com/2022/12/12/azure-spot-instance-comment-et-pourquoi-partie-1-3/

Une fois les premiers concepts de la Spot instance bien compris, quelques éléments supplémentaires indispensables pour la mise en pratique. Un point important lors de la création d’une Spot, il peut y avoir une erreur sur le choix du SKU qui apparaîtra sous cette forme.

‘The requested size for resource ‘/subscriptions/xxxxxxxxxx/resourceGroups/spotrg/providers/Microsoft.Compute/virtualMachines/vmspot01’ is currently not available in location ‘northeurope’ zones  » for subscription ‘xxxxxxxxxx’. Please try another size or deploy to a different location or zones. See https://aka.ms/azureskunotavailable for details.’.’. (Code : InvalidTemplateDeployment)

Si d’apparence la résolution est assez simple, le message se répète sur différentes régions et différentes tailles de VM alors que le SKU est dans la liste des modèles éligibles au Spot. Ce message est parfois incorrect, il y a un limitation liée au type d’abonnement que l’on trouve en fouillant un peu la doc.

https://learn.microsoft.com/fr-fr/azure/virtual-machines/spot-vms#limitations/?WT.mc_id=AZ-MVP-5003759

Aucun texte alternatif pour cette image

Attention donc aux offres de type Free Trial 0044P, MSDN Platforms subscribers 0062P, Visual Studio Enterprise subscribers 0063P, Visual Studio Professional subscribers 0059P …etc qui ne sont pas prises en charge. Il y a de quoi passer pas mal de temps à modifier SKU et région avant de chercher à savoir pourquoi cela ne fonctionne pas !

A la lecture de la partie 1/3, il est clairement difficile de trouver une utilité à l’instance Spot… Ce qui apparaît rapidement, c’est que sans automatisation / orchestration, une instance qui va être évincée un peu n’importe quand / comment ne présente pas de réel intérêt. De l’économie, OUI, mais pas avec des contraintes aussi fortes. Avec un peu de recul sur la solution, je peux dire que bien exploiter une Instance Spot, c’est FAIRE VITE (ET BIEN) !

Il faut fouiller dans les différentes documentation et tester quelques scénarios pour commencer à se faire une idée de ce qui est vraiment important pour le bon fonctionnement. Je cite ici un passage de la documentation qui pour résume parfaitement la philosophie de la solution :

« Pour une charge de travail exécutée sur des machines virtuelles spot, la capacité de calcul est un trésor. Le risque imminent d’éviction doit augmenter votre appréciation du temps de calcul alloué, et se traduire par des décisions de conception significatives qui accordent une priorité à la vitesse de la charge de travail.« 

Voilà ce qui doit guider les choix de conception tout au long de la mise en place des instances Spot. Priorité à la vitesse.

Je reprends ici quelques uns des points les plus importants à intégrer dans la réflexion, je n’invente rien, je consolide avec tout ce qui apparaît dans l’ensemble des docs et qui m’a permis de me faire une bonne idée des possibilités :

  • Le déploiement de la machine se fera depuis une image, une machine opérationnelle. Pas question de « gaspiller » du temps Spot pour des tâches de post installation.
  • Utiliser si possible une stratégie de suppression plutôt qu’une stratégie d’arrêt / libération. C’est un concept avec lequel j’ai eu du mal, mais une suppression offre plus de souplesse. Pour une raison assez simple. Une machine supprimée peut-être rapprovisionnée dans une autre région / zone. Ce qui n’est pas le cas de l’arrêt / libération.
  • Automatiser et orchestrer, c’est avant tout savoir ce qu’il se passe sur l’instance. Une supervision fine est donc INDISPENSABLE. Savoir ce qui va être stoppé (vu dans la partie 1, il y a 30 secondes pour réagir et agir) pour engager les actions. Par exemple, un arrêt propre des process suivi d’une orchestration de redéploiement.
  • Dernier point, même si c’est le premier à traiter … les charges de travail doivent être IDEMPOTENTE. Ce qui a déjà été partiellement fait par une instance Spot ne doit pas être refait après une éviction / recréation.

Cette liste n’est pas exhaustive mais ce sont les points importants pour l’ensemble du concept. Je propose ce schéma simple pour bien appréhender la mise en œuvre.

Aucun texte alternatif pour cette image
Une bonne idée de mise en œuvre

Il faut partir du principe que le temps d’utilisation du Spot est une valeur indéfinissable (« Temps indéfini ! » en rouge). Même si ce n’est pas aussi simple que ça.

Avant de se jeter sur l’orchestration, pas d’autres solutions que de se pencher sur la supervision et le signal Preempt. Il n’est volontairement pas intégré dans la partie Spot Utilisation (process) du schéma, mais traité en rouge et à part dans la partie Préavis (signal Preempt). Parce qu’il est hybride, selon la manière dont va se passer l’éviction.

/!\ Il s’agit du point le plus complexe de la doc… et de loin. /!\

2 cas de figure :

  • CAS 1 : La supervision permanente de l’éviction.
  • CAS 2 : L’éviction immédiate.

Et il y a une différence … ABYSSALE entre les 2.

Dans les 2 cas, c’est un appel API qui récupère les events sur un point de terminaison (adresse 169.254.169.254). Ce point de terminaison est appelé Scheduled Events. Et dans les 2 cas, c’est l’instance Spot qui « s’auto-surveille ». Pourquoi cette autosurveillance ? Et bien parce que je cite :

« Les requêtes doivent provenir d’une application s’exécutant sur la machine virtuelle spot. La requête ne peut pas provenir d’une source externe.« 

En lien avec ce point et même si pour la plupart des évènements, le délai de prévenance peut être large (5 à 15 minutes par exemple), la fréquence d’interrogation pour le Preempt d’une Spot doit être réduite. Cette valeur est au minimum de 1 seconde comme il est dit dans la doc éditeur.

« La plupart des événements préviennent de 5 à 15 minutes à l’avance, bien que dans certains cas, 30 secondes suffisent. Pour être sûr de disposer du maximum de temps pour prendre des mesures d’atténuation, nous vous recommandons d’interroger le service une fois pas seconde.« 

Il faut donc que la Spot Instance ait la capacité à s’auto-surveiller, sans impacter considérablement ses ressources et ait capacité à se signaler comme une ressource à qui il reste moins de 30 secondes de durée de vie. De cette manière, elle passe la main le + rapidement possible à l’orchestration et / ou à des process locaux d’arrêt contrôlé, complément indispensable de la Spot Instance. Il faut trouver le bon rapport entre une interrogation très (trop ?) fréquente, par exemple 1 seconde qui va impacter les performances et la réactivité de la machine et une interrogation moins fréquente, par exemple 5 secondes, qui laisse moins de temps mais plus de ressources à la machine pour réaliser un arrêt le + propre possible. 1 seul conseil pour ces paramètres … Go pour les tests.

Si cette opération est possible lorsqu’une machine est déjà provisionnée, donc dans ce que nous appellerons « La supervision permanente de l’éviction » (CAS 1), elle ne l’est plus si l’on parle « D’éviction immédiate » (CAS 2). La voilà la différence abyssale. Je cite une nouvelle fois :

« Il est possible que votre machine virtuelle spot soit désignée pour éviction dès sa création et avant même l’exécution de votre charge de travail. Le simple fait qu’il y avait de la capacité pour créer une machine virtuelle spot ne signifie pas qu’elle persistera. »

L’éviction immédiate, c’est donc l’éviction d’une machine en cours de création. Comme il est expliqué plus haut, seule la machine Spot peut récupérer son Preempt. Comme cette dernière n’ira même pas au bout de son provisionnement, impossible de lui demander de se signaler efficacement. Et cette fois, c’est important de le noter (et c’est assez clairement exposé sur la doc) :

« Le contrôle d’intégrité doit donc résider en dehors de l’environnement de charge de travail. »

MAIS … mais comment ? Et bien en dehors de l’environnement, c’est en dehors de l’API Scheduled Events. Ce qui équivaut à surveiller la ressource Azure Virtual Machine de type Spot Instance et un état de type Libération ou Arrêté. Ce que l’on trouve dans le portail à cet endroit.

Aucun texte alternatif pour cette image
Statut de la ressource Azure.

Voilà bien quelque chose de très différent. Ce sera toujours avec un appel API, mais plus sur le lien Scheduled Events qui n’expose pas ces états dans les EventType.

Aucun texte alternatif pour cette image
Valeur des états, pas d’état Libération ou Arrêté

On se tournera donc plutôt vers cette documentation (https://learn.microsoft.com/en-us/rest/api/compute/virtual-machines/instance-view?tabs=HTTP/?WT.mc_id=AZ-MVP-5003759) pour exploiter un point de terminaison qui expose les informations de ce type.

Ces API et bien d’autres sont au cœur de l’orchestration des instances Spot. Reste à mettre en musique cette belle mécanique. C’est ce qui sera présenté dans la partie 3/3 de ce sujet.

Pour celles / ceux qui souhaitent démarrer cette partie, une architecture de test est déployable depuis le Git à cette adresse : https://github.com/mspnp/interruptible-workload-on-spot

Un petit avant goût de ce qui va être mis en œuvre (CAS 1) avec la capacité que va avoir la machine à s’auto-surveiller avant de passer la main tout en limitant au mieux l’impact d’un arrêt sous les 30 secondes.

Aucun texte alternatif pour cette image
30 secondes, c’est … large 😉

Azure Spot Instance, comment et pourquoi, partie 1/3.

Niveau : ★★★☆☆

Il y a 1000 manières d’optimiser ses coûts Azure. Bon, peut-être pas 1000, mais il y a quand même pas mal de plans d’actions à mettre en place pour au final une bonne qualité de services, au juste prix.

Les actions les plus courantes sont :

Il y a déjà de quoi occuper pas mal de son temps avec toutes ces optimisations.

Ce ne sont pas les seules pistes, il y en a beaucoup d’autres, mais l’une d’elle est assez peu connue. Parce que pas toujours très très facile à utiliser et aussi et surtout parce qu’elle ne répond pas à tous les cas d’usages. Il s’agit d’Azure Spot Instance.

La promesse d’une instance Spot c’est d’être vraiment pas chère. Mais alors, VRAIMENT pas !

90% de réduction, c’est assez impressionnant.

La contrepartie ? Si l’infrastructure Azure a « besoin » de cette machine (de RAM, de CPU donc), la machine sera supprimée. Avec un préavis de 30 secondes. Ici, pas question de SLA. Autre contrepartie, l’instance Spot a une priorité plus faible qu’une instance classique. Elle n’est pas prioritaire lorsqu’elle a besoin de capacité de calcul.

Ahhh ! Mais ça ne sert à rien alors ?
Si, mais ces instances sont adaptées à des besoins bien spécifiques que Microsoft défini comme des charges de travail interruptibles.

Et pour lesquelles un tableau comparatif est proposé.

Voilà qui est déjà un peu plus clair. Mais si je dois perdre une machine, est-ce vraiment complètement au hasard ou bien existe-t-il des critères particuliers ? Et si oui, quelles-sont ils ?

Il y en a plusieurs, ils sont clairement exposés lors de la création de l’instance. Tout se met en place lorsque l’option Exécuter avec la remise Azure Spot est sélectionnée dans le menu. Cette coche donne accès à des options complémentaires et à tous les paramètres qui font la spot instance.

On y trouve une Stratégie d’éviction, un Type d’éviction et un Prix maximum que vous souhaitez payer par heure (USD).

La stratégie d’éviction propose 2 options qui sont Arrêter / Libérer ou Supprimer. J’avoue avoir joué un peu avec ces choix pour voir si cela modifiait le coût de la machine, mais pas de changement dans le simulateur des coûts. Il faut relire attentivement la doc pour bien saisir les subtiles différences qu’il y a entre ces 2 choix.

  • Une machine supprimée ne coûte plus rien. Si il y a des disques attachés à cette machine, ils sont également supprimés.
  • Une machine libérée ou arrêté qui est utilisée avec des disques attachés est toujours facturée pour ses disques. Un comportement plutôt normal. Elle est également comptabilisée dans les quota. Cette partie n’est pas très très précise dans la doc (j’imagine qu’il s’agit là des quota de compute pour la subscription). Dans la théorie, cette machine peut être redéployée mais SANS garantie.

Voilà un choix qui n’est pas très difficile à faire et à chacune / chacun d’adapter à son besoin.

Le Type d’éviction est lui beaucoup plus technique.

Il faut vraiment prendre le temps de comprendre cette partie. Il y a 2 choix.

  • Capacité uniquement : votre machine virtuelle sera supprimée lorsque la capacité excessive d’Azure disparaîtra.
    /!\/!\C’est à dire ? /!\/!\
    Il s’agit ici d’une belle erreur de traduction. La traduction est en fait :
    « Lorsque la capacité excédentaire disparaîtra ».
    La machine coûte le même prix qu’une machine de type « à l’utilisation » (Pay as You Go), mais elle sera stoppée ou supprimée dès qu’Azure ne sera plus en capacité excédentaire. En clair, Azure à besoin de ressources, la machine est évincée. Je n’ai pas pour l’instant trouvé de réel cas d’usage pour cette option. Les commentaires sont ouverts pour partager sur ce sujet.
  • Prix ou capacité : votre machine virtuelle est supprimée lorsque la capacité excessive d’Azure disparaît ou que les coûts dépassent le prix maximal spécifié. On retrouve ici la même erreur de traduction, je ne reviens pas sur le sujet.

Voilà clairement le point central pour les instances Spot.

Pour travailler ce sujet prix, il faut sélectionner l’option pour afficher des métriques d’aide au choix. Cette écran de définition du prix maximum est vraiment LE cœur du sujet. Je préfère utiliser cette vue en mode tables qu’en mode graphique et je choisis un intervalle de temps de Trois mois qui est la valeur maxi. Je conserve la devise USD.

Une parenthèse avant d’aller plus loin, le choix USD est obligatoire. S’il est possible de simuler ses coûts en EUR, il ne sera pas possible de les saisir et de les valider. C’est pour l’instant un petit bug du portail.

Retour donc à la simulation en dollars. En bas de l’écran se trouve les prix (c’est un prix par heure) et le très important taux d’éviction pour les différentes régions. Il y a une petite subtilité puisque les régions affichées sont en fait des régions proches de la région sélectionnée dans le menu de création de l’instance de VM.

Dans l’exemple ci dessous, je choisis (US) East US qui me propose 3 régions dans le simulateur. Avec des coûts en $ très différents mais aussi des taux d’éviction très différents. Il y a parfois des écarts très significatifs pour ces valeurs.
Des taux d’éviction compris entre 0-5% et 10-15%
Des coûts compris entre 0.01200$ et 0.04224$

Il manque je pense une information dans cette vue ou l’ajout du coût par heure en mode de « Paiement à l’utilisation » permettrait de savoir si l’instance Spot est vraiment une « bonne affaire ». Je fais donc ce contrôle depuis la calculatrice Azure (https://azure.microsoft.com/fr-fr/pricing/calculator/?WT.mc_id=AZ-MVP-5003759) pour comparer les prix. La calculatrice me donne 0.10$ / heure.

Voilà pour les paramètres qui me paraissent importants.

Pour en terminer avec cette première partie, Spot instance est également disponible pour les groupe de machines virtuelles identiques avec un menu de configuration un peu différent.

Dans la partie 2/3, il sera question de pousser plus loin la compréhension du sujet. Il y a encore beaucoup à faire.

Conservation Azure Log Analytics, de grands changements.

Niveau : ★★★★☆

/!\ /!\ Toutes les images de ce sujet sont des images tirées de la documentation éditeur. /!\ /!\

/!\ /!\ Certaines fonctionnalités présentées dans ce sujet sont encore en préversion. /!\ /!\

Le puits de log Azure (log anaytics) est un composant central. Il collecte les logs (tout ou presque) et est ensuite exploité entre autres par un langage de requêtes appelé KQL ou Kusto. Il y a beaucoup d’autres possibilités attachées à ce puits de logs, c’est un sujet sans fin …


Collecter les log, c’est ingérer de très gros volumes de données.
Et cette fonctionnalité a évidement un coût.

Sur ce lien, toutes les explications pour comprendre comment sont calculés les principaux frais liés à ce service.
https://azure.microsoft.com/fr-fr/pricing/details/monitor/?WT.mc_id=AZ-MVP-5003759

Pour faire le plus simple possible, il y a notamment des coûts d’ingestion, c’est à dire de récupération des informations puis des coûts de stockage dans le temps de ces données.

Avec comme il est très souvent d’usage sur Azure des économies à réaliser si les volumes sont conséquents. Par exemple, dans le tableau suivant, ce sont les coûts d’ingestion dont il est question.
Le paiement à l’utilisation démarre à 2,761 € / Go mais il est possible de réduire la facture par Go dès que les volumes sont plus conséquents. Jusqu’à -27 % soit 2,02 € / Go

Ce sont bien ici des frais d’ingestion.

Ensuite, les données stockées sont facturées si vous souhaitez les conserver + de 31 jours (ou 90 jours si Sentinel est activé). Au delà de cette durée, il y a un coup supplémentaire de 0,121 € / Go / Mois.

Pour rappel, les durées de rétention standards sont configurable de 30 à 730 jours (ou tout du moins, elles étaient configurables de 30 à 730 jours).

Voilà avec ces deux critères principaux de quoi comprendre un peu mieux la facturation des puits de logs.


Il y a ensuite quelques notions plus compliquées et pas mal de nouveauté en preview pour le composant log analytics. Elles vont à différents venir à terme impacter les coûts du composant (dans les deux sens).

Par exemple, la conservation « à la table / plan » qui ne va plus s’appuyer sur la valeur positionnée sur le composant log analytics mais qu’il est possible de paramétrer plus finement. On parle de plans de données.

-Le premier plan est le journal analytics.C’est un plan « complet » en terme de fonctionnalité.

-Le second plan est un plan basic. C’est un plan réduit qui vise à (source éditeur) :
…économiser sur le coût de l’ingestion et du stockage de gros volumes de journaux d’activité verbeux dans votre espace de travail Log Analytics pour le débogage, la résolution des problèmes et l’audit, mais pas pour l’analyse et les alertes.

Rien de mieux qu’un tableau récapitulatif pour mieux cerner les énormes différences entre ces deux plans :

Les coûts d’ingestion sont réduits pour une table dans un plan Basic. En contrepartie, la durée de conservation est fixée à 8 jours et le jeux de commandes pour les requêtes KQL a été simplifié. Ainsi, toutes les commandes connues ne sont plus utilisables. Place ici à quelques opérateurs seulement. Peut être pas assez pour de l’analyse fine, mais comme expliqué ci-dessus, le plan Basic n’est pas fait pour cela.


Côté tables, toutes ne sont pour l’instant pas éligibles à ce plan Basic, en voici la liste :

C’est donc pour ces tables « verbeuses » la possibilité de réaliser des opérations de débogage, de résolution de problèmes, mais plus d’analyse sur la durée et plus non plus de règles d’alertes. C’est un choix. On voit clairement ci dessous dans la colonne Plan ce qui est du domaine de l’Analytics et ce qui est du domaine Basic. Avec les différences en terme de rétention.

Plus en détail, la manière dont une table éligible va pouvoir basculer dans un mode Basic.

Dernière et nouvelle subtilité, la Total rétention period. Ce qui était connu jusqu’à ce jour c’est la rétention interactive. Mais il est maintenant possible (pour des raisons légales par exemple) d’ajouter une période d’archivage (Archive period) qui va allonger la durée globale de rétention. Ce qui apparaît en rouge dans l’impression écran précédent.
C’est un peu le meilleur des deux mondes.

Il y a donc à partir de maintenant une changement de discours.Parler de rétention log analytics est maintenant tout à fait différent.

– La période de rétention est la durée pendant laquelle les logs sont accessibles pour des requêtes interactives !

– La rétention total, c’est la période de rétention + la période d’archivage.

Diagramme d’un aperçu des périodes de conservation et d’archivage des données.

Exploiter des données d’archive n’est donc plus interactif mais se fera au travers d’un job de recherche (search job) ou d’une restauration (restore).

Une tâche de recherche créée une nouvelle table suffixée _SRCH. Cette table est accessible dès sa création mais les travaux de recherche peuvent demander du temps. Ci-dessous, la vue d’un job de recherche avec le nommage particulier et le suffixe _SRCH.

Le cadre d’utilisation de la table de recherche est définie comme telle par l’éditeur :

Les tâches de recherche sont des requêtes asynchrones qui extraient des enregistrements dans une nouvelle table de recherche dans votre espace de travail pour une analyse plus poussée. La tâche de recherche utilise le traitement parallèle et peut s’exécuter pendant des heures sur des jeux de données volumineux. Cet article explique comment créer une tâche de recherche et comment interroger ses données résultantes.

L’opération de restauration n’adresse pas le même besoin. Elle est définie comme telle par l’éditeur :

L’opération de restauration crée la table de restauration et alloue des ressources de calcul supplémentaires pour interroger les données restaurées à l’aide de requêtes hautes performances prenant en charge les KQL complètes.

La requête de restauration expose clairement ce qui est fait dans ce cadre :
Une table, une date de début, une date de fin.

J’ai encore trop peu de recul sur le sujet pour savoir ce qu’il me faudra choisir à l’avenir, mais nul doute que ce sont deux notions très importantes qui n’adresseront pas le même besoin.

Voici les limites actuelles pour ces fonctionnalités en preview :
– Recherche : https://learn.microsoft.com/fr-fr/azure/azure-monitor/logs/search-jobs?tabs=portal-1%2Cportal-2%2Cportal-3#limitations
– Restauration : https://learn.microsoft.com/fr-fr/azure/azure-monitor/logs/restore?tabs=api-1%2Capi-2#limitations

Alors oui, clairement, c’est un peu la révolution de le monde passionnant des puits de logs Azure ! Il va falloir réapprendre beaucoup pour profiter efficacement de toutes ces nouveautés.

Question finale … MAIS COMBIEN CA COÛTE !

Et bien … rien pour l’instant. C’est donc le moment idéal pour tester ces belles fonctionnalités.

Go ?

Logic App Azure, comment réduire sa facturation.

Niveau : ★★★☆☆

Si le Cloud Azure sait tout faire ou presque, chaque solution doit faire l’objet d’une étude avant le déploiement. En terme de définition technique mais aussi en terme de coût. Le débat est même ouvert sur le sujet, est-il possible de parler de bonne définition technique si la contrainte du coût n’est pas abordée ?

Et c’est encore plus important sur le Cloud ou un défaut de conception est assez facilement couvert par l’upgrade d’un service. En clair, « surtailler » sa solution pour masquer les erreurs techniques. Alors oui, cela peut fonctionner, mais cela peut (va) coûter beaucoup plus cher. Bien entendu, les défauts de conception ne sont pas les seuls cas ou les coûts (ou les surcoûts) viennent un peu gâcher la solution.

Voici un exemple de réalisation ou l’approche technique est bonne, la solution répond à la demande, le coût même s’il était difficle à définir paraissait adapté… mais au final, c’est un peu « tout ça pour ça ».

Il s’agit dans la demande initiale d’intercepter la création des règles de NSG pour les ports SSH et RDP. Pour faire simple, récupérer à la volée les informations de création pour les custom règles AllowAnySSHInbound et AllowAnyRDPInbound. Une fois ces informations obtenues, la ou le responsable sont instantanément informés par mail et ils sont redirigés sur les règles de bonnes pratiques de l’entreprise en terme de sécurité.

Les actions sur les ressources sont déjà consignées et envoyées sur un Hub d’évènements côté Azure. Avec cette information, assez simple de mettre une solution en œuvre. Comme les données sont déjà consignées, il faut les récupérer puis les traiter pour en extraire les bonnes infos et créer un workflow pour le traitement et l’envoi de mail. Tout ce que permet de (facilement) faire une Logic App. Impec, la solution est là.

Et ça marche, et ça marche même très bien !!

Mais le nombre d’exécutions est extrêmement élevé (plusieurs fois par minute) et cela se voit en terme de facturation.

Sans trop rentrer dans le détail de la Logic App de départ, les évènements de subscription sont récupérés et filtrés, puis s’ils correspondent à la création de l’une des règles (RDP, SSH), ils sont utilisés pour générer un mail auto.

Du coup, pas grand-chose à dire, c’est techniquement ce qu’il fallait faire. mais déjà à la conception, le filtre utilisé me laissait un peu perplexe. Il est beaucoup trop large. Et même s’il est fonctionnel et permet de récupérer les infos, 99% des traitement se font dans le vide, sans que la donnée (intercéptée puis traitée) soit pertinente.

Aucun texte alternatif pour cette image

Dans la liste défilante, il n’est pas possible de spécifier Microsoft.Resources.Network. Bon, un petit hack du code de la Logic App me permet de modifier cette valeur et de ne récupérer que les évènements de type réseau, et pas tout ce qu’il se passe sur la sub. Et ça marche !

                    }
                    "path": "/subscriptions/@{encodeURIComponent('xxxxxxxxxxxxxx')}/providers/@{encodeURIComponent('Microsoft.Resources.Network')}/resource/eventSubscriptions",
                    "queries": {
                        "x-ms-api-version": "2017-09-15-preview"
                    },

Mais c’est encore beaucoup trop, les modifications sur les éléments du réseau sont fréquentes et la Logic App tourne bien trop souvent. Et il n’y a pas à ma connaissance de possibilité pour mieux filtrer depuis ce trigger. Au final, la dépense engagée est importante, le service est très sollicité même si ça marche plutôt très bien.

S’il n’est pas possible de filtrer à ce niveau, je me tourne vers les évènements de l’event pour voir si il est possible de faire mieux. On y retrouve les filtres de bases comme le type de ressources ou le type d’évènements. Puis en parcourant la doc sur le sujet, je découvre qu’il existe des filtres avancés. https://learn.microsoft.com/fr-fr/azure/event-grid/event-filtering/?WT.mc_id=AZ-MVP-5003759

Il est possible de faire du « AND et OR » et il est possible d’utiliser toutes les sortes d’opérateurs dont les StringContains (https://learn.microsoft.com/fr-fr/azure/event-grid/event-filtering?WT.mc_id=AZ-MVP-5003759#or-and-and).

Aucun texte alternatif pour cette image

Voilà qui commence à être beaucoup plus intéressant…

Si je regarde le JSON généré lors de la création d’une règle de NSG (ces informations se retrouvent sur l’activity log Azure), c’est assez fourni. J’ai besoin d’identifier la présence des champs suivants pour être certain qu’il s’agit bien de la création d’une règle de NSG et d’une règle non autorisée.

Aucun texte alternatif pour cette image

Ce qui se traduit dans le code du « AND et OR » par le filtre avancé suivant :

"filter": 
                    "includedEventTypes": [
                        "Microsoft.Resources.ResourceWriteSuccess"
                    ],
                    "enableAdvancedFilteringOnArrays": true,
                    "advancedFilters": [
                        {
                            "values": [
                                "networkSecurityGroups"
                            ],
                            "operatorType": "StringContains",
                            "key": "subject"
                        },
                        {
                            "values": [
                                "AllowAnySSHInbound",
                                "AllowAnyRDPInbound"
                            ],
                            "operatorType": "StringContains",
                            "key": "subject"
                        }
                    ]
                },

Contient « networkSecurityGroups » et contient « AllowAnySSHInbound » ou « AllowAnyRDPInbound« . Voici ces même paramètres de filtrage depuis l’interface graphique :

Aucun texte alternatif pour cette image

Toujours dans l’esprit d’avoir une solution performante, mais la moins coûteuse possible, ces évènements sont envoyés sur une… queue de stockage. C’est un service de remise de message basic mais qui offre tout ce dont j’ai besoin.

Une taille de message à 64 Ko maximum, une durée de rétention de 7 jours et un coût ridicule pour le service rendu. Autre avantage, les queues de stockage sont des triggers côté Logic App.

Aucun texte alternatif pour cette image

Voilà, la boucle est bouclée. Tous les éléments sont en place pour que cette application logique soit 100 % fonctionnelle et coûte le moins possible.

Pas grand chose à dire sur le workflow de traitement. Le filtre avancé dépose sur la queue de stockage le Json si et seulement si il s’agit d’une règle non autorisé. La Logic App vérifié toutes les 3 minutes si il y a de nouveaux messages (comprendre Json) en attente.

Le Json est parcouru est les informations importantes sont extraites. C’est à dire tout ce qui va être utilisé dans le mail auto. Upn, ressource impactée, heure de création. Une fois ces informations traitées, la queue est vidée puis le mail est envoyé.

Pour résumer, la différence majeure est que le filtre ne traite plus toutes les demandes réseau, mais uniquement l’écriture de 2 règles clairement identifiées.

Dernier point, la facturation est un calcul (assez savant 😉 ) basé grosso modo sur le nombre de runs (d’actions) + le nombre de trigger (lancement pour le contrôle du contenu de la queue). Ce mode de facturation est valable dans le cadre d’un service appelé « Plan de consomation (mutualisé) ». Le caclul est différent dans un plan standard, voir à ce sujet la doc éditeur.

https://azure.microsoft.com/fr-fr/pricing/details/logic-apps/?WT.mc_id=AZ-MVP-5003759

Avec cette nouvelle architecture basée sur le filtrage en amont, l’équilibre coût / valeur de l’usage est totalement respecté. On en a « pour son argent ». Les metrics de la Logic App sont assez clairs sur le sujet. Il y a eu sur la dernière heure 20 exécutions (pour rappel, trigger toutes les 3 minutes) et aucun run.

Aucun texte alternatif pour cette image

Cette même logic app non filtrés tournait plusieurs 100 aines de fois chaque heure.

Voilà le parfait exemple d’une mise en ouevre initiale techniquement correcte, mais pour laquelle le coût n’a pas été assez étudié !

Une bonne gymnastique pour la création de prochaines Logic App.

Utilisation de Azure Resource Graph Explorer dans une logic app Azure

Niveau : ★★★☆☆

Azure Resource Graph Explorer offre de réels avantages lorsqu’il s’agit de réaliser de grosses requêtes sur les ressources Azure.

  • En terme de scope puisque qu’il permet de remonter les résultats sur des 10 aines de subscription sans avoir a changer de contexte d’exécution (le Set-Azcontext du Powershell ou le az account set de l’AZ CLI)
  • En terme de de vitesse puisque les réponses sont instantanées ou presque.
  • En terme de richesse du langage et des innombrables possibilités de filtrage ou de jointures entre les tables.

Son utilisation devient régulière, et rapidement, c’est un service que l’on cherche à lier avec d’autres services / composants Azure. Par exemple, les logic app. Comme expliqué sur la documentation éditeur :
Azure Logic Apps est une plateforme cloud où vous pouvez créer et exécuter des workflows automatisés sans code. En utilisant le concepteur visuel et en sélectionnant dans les opérations prédéfinies, vous pouvez créer rapidement un flux de travail qui intègre et gère vos applications, données, services et systèmes (voir la documentation à cette adresse : https://learn.microsoft.com/fr-fr/azure/logic-apps/logic-apps-overview/?WT.mc_id=AZ-MVP-5003759)

Voilà que s’ouvrent de chouettes possibilités !

Ou pas … Ou pas immédiatement et pas sous la forme attendue.

Dans l’exemple qui suit, le besoin est simple. Identifier sur les machines virtuelles les ouvertures de port en Any sur le port 22, SSH. Et envoyer chaque semaine un mail aux équipes sécu, RSSI …Etc avec la liste des ressources concernées. Ce genre de reporting auto est un workflow assez simple à réaliser, c’est efficace et utile. Un autre exemple assez demandé, la liste des ressources orphelines sur l’ensemble des subscriptions pour un Finops encore plus efficace.

Dans un premier temps, direction le portail et le service Azure Resource Graph Explorer. Le plus simple lorsque l’on se lance dans une requête Graph, c’est de rechercher le composant dans la liste déroulante (ici, Network security groups) et de sélectionner ce composant pour créer une première requête globale (sans filtre).

Le (nouveau) menu pour Azure Resource Graph Explorer.

Reste ensuite à consulter le retour de la requête et à renseigner les champs nécessaires à l’obtention du port source et du port destination. Puis à filtrer en affichant pour le rapport le nom du NSG et son groupe de ressources.

resources
| where type == "microsoft.network/networksecuritygroups"
| where properties['securityRules'][0]['properties']['destinationPortRange'] == "22"
| where properties['securityRules'][0]['properties']['sourceAddressPrefix'] == "*"
| project name, resourceGroup

Retour pour la requête Graph

Le travail est terminé côté Graph.

Direction la logic app pour intégrer cette requête dans un workflow. Le trigger est de type Recurrence, la logic app et lancée 1 fois / semaine. Puis dans le choix des opérations, une recherche sur Graph. Sans résultat, puisque les seules opérations Microsoft Graph disponibles sont Microsoft Graph Security et MS Graph Groups and Users.

Recherche sur le terme Graph

Ahhhh … Bizarre. Sans, comment s’appuyer sur une logic app ? Il reste possible d’utiliser Azure Automation, c’est à dire d’appeler un job qui lancerait les commandes au travers de Powershell et du module dédié, mais quelle lourdeur. Ou l’utilisation de l’API également intégré dans un script Powershell lancé par Automation.

Azure Automation dans les logic app.

Pas fan, et pas très élégant. C’est un peu « tiré par les cheveux ». Bon, direction mon moteur de recherche. Et la réponse n’est pas bien difficile à trouver. Je parlais plus haut d’API, il est normal de ne pas trouver Graph dans les modules, puisqu’il faut utiliser … une action HTTP.

Action HTTP

Le reste est assez simple puisqu’il s’agira d’inclure le code (headers, queries, body) dans l’action sous cette forme :

Le contenu de la requête.

Il faut pour terminer faire un Run sur la logic app pour vérifier la sortie de la requête. Puis ce contenu sera utilisé pour les étapes suivantes.

Le retour de requête

On peut ajouter une action de type condition ou une action de type mail pour terminer cette logic app. La condition peut être le test du contenu du body et le contrôle de la valeur totalRecords. Si elle est égale à 0, alors plus de traitement, si elle est plus grande que 0, alors le body est inséré dans le mail et le mail est envoyé.

Finalement, le plus long dans cet exercice est la réalisation d’une requête côté Graph. Avec un peu d’habitude, moins de 15 minutes sont nécessaires pour construite ce type de solution. Petit investissement pour un reporting auto plutôt utile.

Travailler son Cloud en ligne de commande :

Niveau : ★☆☆☆☆

Si il est possible de travailler son Cloud Azure depuis le portail, il est également important de savoir le faire à l’aide du code. Pour toutes sortes de raisons, principalement pour l’homogénéité des déploiements et pour la vitesse des déploiements lorsqu’il s’agit de déploiements. Et pour la rapidité de récupération des éléments et pour les possibilité de filtrage lorsqu’il s’agit d’exploitation..
On le fait soit en exploitant au travers du code, ce que j’appelle le code ligne à ligne, soit en déployant à l’aide de code.

Exploiter avec le code, c’est lancer des commandes de ce type là (ici, Powershell) :
Get-AzVM

Retour de commande dans le portail Powershell Azure

La même commande avec une filtre pour ne cibler que quelques ressources, c’est à dire les machines déployées en « francecentral »
Get-AzVM | Where-Object {$_.location -eq "francecentral"}

Et pour finir, la même commande avec une mise en forme pour une sortie écran filtrée sur quelques propriétés :

Get-AzVM | Where-Object {$_.location -eq "francecentral"} | Select-Object Name,ResourceGroupName

Vue filtrée

Voilà qui simplifie les actions de bases.

Déployer avec du code, c’est « parfois » utiliser une suite de commandes ligne à ligne comme dans l’exemple suivant (source éditeur, ici AZ CLI) :

Déployer une VM avec AZ CLI

Mais la création de ressources à l’aide des commandes est tout de même assez rare. Les outils de déploiement (ARM, BICEP, TERRAFORM) sont plus souvent utilisés.
Lorsqu’il s’agit de ces 3 outils, les possibilités sont étendues. On parlera de variables, de paramètres …Etc. Mais on en parlera plus tard dans un autre sujet. Ce qui est présenté ici, c’est une introduction pour les débutantes / débutants et quelques concepts et outils de bases.
L’exemple suivant est la création d’un compte de stockage au travers de BICEP.

BICEP, la façon la plus simple de démarrer

Pour plus d’exemples et pour faire la différence entre ARM et BICEP, un lien INDISPENSABLE : https://bicepdemo.z22.web.core.windows.net/

Après cette présentation rapide, la question est de choisir ses outils / langages de déploiement et d’exploitation . Voici quelques pistes sur le sujet :

Exploitation :
Je viens du monde Linux :
AZ CLI
https://learn.microsoft.com/fr-fr/cli/azure/?WT.mc_id=AZ-MVP-5003759
Je viens du monde Windows :
Powershell
https://learn.microsoft.com/fr-fr/powershell/azure/?view=azps-8.3.0/?WT.mc_id=AZ-MVP-5003759

Déploiement :
Je travaille uniquement sur Azure, je suis familière / er avec le code :
ARM
https://learn.microsoft.com/fr-fr/training/paths/deploy-manage-resource-manager-templates/?WT.mc_id=AZ-MVP-5003
Je travaille uniquement sur Azure, je NE suis PAS familière / er avec le code :
BICEP
https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/learn-bicep/?WT.mc_id=AZ-MVP-5003759
Je travaille sur Azure et sur d’autres Cloudeurs :
Terraform
https://learn.hashicorp.com/terraform

Peut-être un peu caricaturale, mais pas bien loin non plus de la vérité.

Pour terminer, il existe un éditeur de code gratuit https://code.visualstudio.com/ qui offre la possibilité d’ajouter des plugins dédié pour améliorer son expérience du code (colorisation, auto complétion, mise en forme automatique …Etc).

Quelques plugins ARM pour Visual Studio Code.

Et un dernier conseil pour mieux apprendre Powershell. Dans un premier temps, j’utilise TOUJOURS la commande native et PAS UN ALIAS.
L’alias est une commande raccourcie qui est en fait un « pointeur » sur la commande complète. Ici, la commande Get-Childitem est la commande native, GCI un alias de cette même commande et Dir un autre alias de cette même commande.

Ce qui se vérifie avec la commande Powershell suivante.
Get-Alias dir
Get-Alias gci

Dans la phase d’apprentissage, il est préférable de choisir la commande complète pour mieux mémoriser ces commandes. L’utilisation de la touche de tabulation et un plus, elle affiche la fin de la commande ou l’ensemble des commandes qui commencent par les caractères saisis.
Par exemple :
Get-AzV + tabulation

Vue partielle, tout ce qui commence par Get-AzV

Voilà, tout est là pour (bien) démarrer. Y’a plus k’a 🙂



L’initiative, ou comment respecter / auditer les configurations de références.

Dès lors que les sujets de gouvernance sont à l’ordre du jour sur Azure, il est question de policy ou stratégies Azure.

C’est un outil puissant et simple (c’est possible) pour bien gérer les bonnes pratiques liées aux différents composants Azure. Pour rappel, la policy est même l’outil central de la gouvernance Azure. Ce qui a été expliqué sur le blog dans un article en 3 parties dont voici les liens :

Conformité et gouvernance avec Azure Policy 1/3 – Une techno, des infos. (wordpress.com)

Conformité et gouvernance avec Azure Policy 2/3 – Une techno, des infos. (wordpress.com)

Conformité et gouvernance avec Azure Policy 3/3 – Une techno, des infos. (wordpress.com)

Gouverner, c’est donc définir un ensemble de policy. Même s’il existe des thèmes, des catégories de policy, il faut en général contrôler son Azure avec plusieurs points.

Les policy rangées par type.

Ce regroupement de policy est possible au travers des initiatives. Que l’on trouve déjà prêtes à l’utilisation dans le portail ou que l’on peut créer selon son besoin. L’initiative, c’est un peu de la policy à grande, très grande échelle.
Avec non plus un thème par services comme exposé dans l’écran ci dessus (CDN, Cognitive Services, Compute …Etc) mais plutôt par configuration de référence.

Prenons deux exemples parfaitement représentatifs que sont le NIST et le CIS.

Quelques initiatives

Ces configurations de références sont pour le NIST composées de 955 policy et pour le CIS, 90 policy. Lorsque l’initiative CIS est sélectionnée, elle présente l’ensemble des policy qui la compose.

L’ensemble des policy pour l’initiative CIS

Et c’est lors de l’assignation de l’initiative que se fera le paramétrage des effets disponibles pour chaque policy.

Choix de l’effet pour chaque policy.

Il existe pour l’instant une cinquantaine d’initiatives dans le portail. Toutes ne sont pas aussi complètes et certaines ne sont même qu’un ensemble de 2, 3 ou 4 policy. C’est essentiellement le cas dès lors que la policy n’est plus en mode audit, mais plutôt en mode de configuration.

Dans cet autre exemple, l’initiative nommée Configure Windows machines to run Azure Monitor Agent and associate them to a Data Collection Rule va effectuer plusieurs étapes pour obtenir comme résultat la configuration par étapes du monitoring pour la machine virtuelle.

  • Configurer l’agent pour la VM
  • Configurer l’agent pour un scale set si nécessaire
  • Configurer ARC
  • Associer une data collection rule

Ce type d’initiative rend également de grands services.

Si ce qui est proposé dans le portail est insuffisant, il est tout à fait possible de créer ses propres initiatives. Cette action est simple, puisqu’il s’agit d’un wizard de sélection des policy.

Ajout des policy pour la création d’initiative.

Si ces actions ne présentent aucune difficulté, il ne s’agira pas de sélectionner les policy en les empilant pour avoir une bonne initiative. Il faut se pencher sur le besoin et concevoir une initiative cohérente. C’est à dire de ne pas sélectionner des policy qui adressent le même point mais avec un résultat attendu différent.

Voilà pour cette présentation rapide (et très incomplète) des possibilités de l’initiative Azure. C’est un beau sujet de gouvernance, avec quelques « packages » très complets qui facilitent vraiment la vie !