Aller au contenu

Azure Batch, le mal-aimé

Avec l'émergence des services managés de cloud-computing moderne proposés sur Azure : AKS, ARO, Databricks,... et maintenant Azure Container Apps. On finit par oublier les anciens... L'un des services que Microsoft ne met plus vraiment en avant depuis un certain temps mais qui pour moi est digne d'intérêt est Azure Batch.

Azure Batch : C'est quoi ?

Azure Batch est un service proposé par Microsoft permettant d'exécuter des traitements sur une machine virtuelle. Vous pouvez choisir la puissance de calcul (la taille de la VM), mais aussi choisir entre Windows et Linux (ubuntu, debian, centOS,...).

Et ce n'est pas tout !

Il propose aussi nativement :

  • un service de scalabilité horizontal que vous pourrez customiser,
  • un service de VM low-priority, qui vous permettra de diviser par 4 les coûts par rapport à une VM classique,
  • un gestionnaire de packages d'applications (Artefacts),
  • un gestionnaire de tâches avec l'historique des exécutions,
  • un planificateur de tâches,
  • la possibilité d'intégrer les machines virtuelles dans un Virtual Network,
  • la possibilité de charger les variables d'environnement depuis Azure KeyVault,
  • la possibilité d'exécuter des conteneurs Windows et Linux.

Et le mieux, c'est que ce service est GRATUIT ! Seules les machines virtuelles utilisées sont payantes.

Mais, dans quel cas j'aurais besoin d'Azure Batch ?

Les cas d'utilisation

Si vous préparez l'examen de certification Azure Architect vous avez dû tomber sur la question : "Dans quel cas utiliser Azure Batch ?"

Microsoft indique dans sa documentation que ce service permet d'exécuter des traitements par lot de calculs haute performance. Pour le traitement d'image, de vidéo, de modélisation ou de projection complexe, par exemple.

De mon point de vue, c'est un peu réducteur. Pour l'utiliser depuis des années, ce service permet des usages beaucoup plus communs comme :

  • l'exécution d'agents de build ou de déploiement éphémère,
  • le traitement d'opérations sur des données métier en mode batch.

Pour faire simple, si vous avez des traitements d'une durée de plusieurs minutes et que vous n'avez pas forcément de contraintes de temps de réponse, vous pouvez envisager Azure Batch comme une solution.

Je vous propose de nous focaliser sur un cas d'utilisation : les agents éphémères.

Les agents éphémères

Si vous utilisez Azure DevOps Services (ou Github Entreprise), vous avez la possibilité de provisionner des agents Microsoft Hosted. Ces agents sont hébergés par Microsoft et sont disponibles à la demande pour chaque Job. Et pour chaque Job, un agent "tout propre" est mis à disposition.

Ce mécanisme vous permet de réaliser vos builds et vos déploiements sans induire de biais liés à l'environnement de l'agent (logiciels, variables d'environnement, reliquats d'un précédent builds, ...).

L'inconvénient majeur, c'est que celui-ci s'exécute sur le réseau de Microsoft. Si vous souhaitez déployer une application dans votre SI isolé d'un point de vue réseau, vous devez autoriser les plages d'IP publiques utilisées par Microsoft pour ces agents. Autant dire que votre RSSI (Responsable de la Sécurité du Système d'Information) ne vous le permettra jamais !

Azure Batch peut vous permettre de résoudre cet inconvénient majeur.

Note

L'utilisation du service Azure Container Instance aurait pu être un bonne solution. Mais certaines limitations au niveau de l'interconnexion avec Azure Registry l'empèche de répondre pleinement au besoin d'isolation réseau des d'agents éphémères.

Cf. Azure Container Registry et Azure Container Instance dans votre Vnet

Pour cela, il nous faudra :

  • Le service Azure Batch,
  • Un pool de nœuds Windows Server 2019 with container (pour les builds windows),
  • Un pool de nœuds Ubuntu Server with container (pour les builds linux),
  • Un Virtual Network avec un subnet dédié à nos 2 pools d'agents,
  • Le service Azure Storage Queue pour transmettre les instructions de création d'agents,
  • Le service Azure Container Registry pour héberger les images utilisées pour instancier les agents,
  • Le service Azure Function pour déclencher la création des agents,
  • La solution Azure DevOps Services pour déclencher les tâches de build.

L'architecture applicative est la suivante :

archi

  • L'Azure Container Registery et l'Azure Batch Account sont restreints au réseau Virtual network A via l'utilisation de private endpoint.
  • L'Azure Function utilise le mécanisme de Vnet intégration afin d'être visible dans le Virtual network A (Il faut aussi penser à mettre en place les règles firewall pour restreindre l'accès au Virtual network A uniquement).
  • Les pools de nœuds (Windows et Ubuntu) exécutent les machines virtuels dans le Virtual network A.
  • Pour éviter un flux entrant depuis Azure DevOps (sur internet) et notre Azure Function (isolée), nous utilisons le service Azure Storage Queue en ayant pris soin de mettre en place les règles firewall afin de limiter l'accès :

  • au Virtual network A pour l'Azure Function,

  • aux plages d'IP publiques d'Azure DevOps.

Ainsi avec cette architecture nous limitons l'accessibilité des agents Azure DevOps à :

  • un flux sortant depuis l'Azure Function vers une Storage Queue (qui fera office de passe-plat)
  • un flux sortant depuis les agents Azure DevOps (obligatoire à minima pour enregistrer l'agent).

Concrètement voici le séquencement qui va se produire pour la mise à disposition d'un agent éphémère :

archi-sequence

  1. La tâche agentless "Invoke REST API" du pipeline de build/deploiement Azure DevOps envoie un message dans la Storage Queue A pour demander un agent éphémère,
  2. L'Azure Function consomme la file d'attente de la Storage Queue A,
  3. Pour chaque message, l'Azure Function crée une tâche dans Azure Batch Account,
  4. L'Azure Batch Account traite les tâches et affecte la tâche au bon pool de nœuds,
  5. Le pool de nœuds instancie un conteneur à partir de l'image présente dans l'Azure Container Registry,
  6. Une fois le conteneur instancié et démarré, celui-ci s'enregistre auprès d'Azure DevOps pour faire savoir qu'il est disponible. Azure DevOps lui affecte alors un job en attente.
  7. Le job Azure DevOps s'exécute dans le Virtual Network A et peut communiquer avec le réseau On Premise.

Dans ce cas d'utilisation, on peut très facilement utiliser la fonctionnalité des VM low-priority et ainsi réduire au maximum les coûts de run de nos agents Azure DevOps. Il s'avérera difficile de trouver une solution moins onéreuse et aussi sécurisée.

Les fonctionnalités

Maintenant, voyons en détail les fonctionnalités d'Azure Batch.

function

Le gestionnaire de pool

Le service Azure Batch Account vous permet de gérer une multitude de pools. Un pool est un ensemble de VM dedicated ou low-priority ayant une configuration commune :

  • type et taille de machine,
  • OS de la VM,
  • subnet,
  • variables d'environnements,
  • commande s'exécutant au démarrage de chaque machine virtuelle,
  • certificats,
  • images des conteneurs à précharger (vous permettra de réduire de façon significative la durée d'instanciation du conteneur),
  • nombre de tâches pouvant s'executer en parallèle sur une même machine virtuelle.

Le gestionnaire d'application

Le service Azure Batch Account vous permet de gérer les packages d'applications. Ainsi vous pouvez vous passer d'outils comme Azure DevOps Artifacts, Nexus ou Artifactory. Le gestionnaire de packages est simple mais reste efficace avec 2 paramètres pour gérer le référencement :

  • Nom de l'application
  • Version

Attention

Le gestionnaire d'application ne vous permet pas de gérer vos images Docker.

Le gestionnaire de certificat

Le service Azure Batch Account vous permet de gérer aussi les certificats. Vous pouvez les mettre à disposition de vos pools qui pourront les utiliser au moment de l'exécution des tâches.

Attention

Azure Batch Account ne vous préviendra pas de l'expiration de vos certificats !

Le gestionnaire de job et de tâches

Le service Azure Batch Account vous permet de regrouper vos tâches dans le cas où vous souhaitez exécuter sur un même pool un ensemble de tâches. Vous pouvez au sein de votre job définir :

  • des variables d'environnement communes à l'ensemble des tâches,
  • des commandes au démarrage et à la fin du job.

Une tâche ne peut s'exécuter qu'au sein d'un job. S'il n'y a pas de disponibilité sur le pool utilisé par le job, Azure Batch Account va mettre en attente la tâche. Pour exécuter votre tâche vous pouvez définir :

  • une ligne de commande
  • des variables d'environnement spécifique
  • les applications du gestionnaire d'application à charger lors de l'exécution de la tâche.

Le service Azure Batch Account historise les exécutions des tâches et des jobs. Mais, je vous recommande d'utiliser des outils comme Log Analytics pour tracer les logs d'exécution des tâches, la recherche dans Azure Batch étant fastidieuse.

Note

Log Analytics est un service managé d'Azure permettant de collecter et parcourir les logs de vos différentes applications. Vous pouvez donc l'utiliser pour centraliser les logs de vos batchs, mais aussi de vos autres applications (Web, Mobile, Desktop, ...).

Le planificateur de tâches

Enfin, Azure Batch Account propose un planificateur de tâches. Mais ce planificateur ne vous permettra de définir que la fréquence d'exécution. Je vous recommande vivement de passer votre chemin et d'utiliser des services intégrant un planificateur complet basé sur un CRONtab par exemple.

Conclusion

Pour conclure je vous propose de résumer les plus et les moins de ce service.

Les plus

  • Le gestionnaire d'application qui vous évitera d'avoir à provisionner un autre service,
  • Le gestionnaire de certificat qui vous simplifiera le déploiement de vos certificats sur vos VM,
  • La prise en charge des OS Windows et Linux,
  • La possibilité d'exécuter des conteneurs sur les OS Windows et Linux,
  • L'intégration Vnet complète qui vous permet d'exécuter vos batchs et conteneurs de façon entièrement isolée,
  • La possibilité de provisionner des VM low-priority qui vous permettra une réduction des coûts significative.

Les moins

  • Le planificateur de tâches qui se limite à la fréquence d'exécution. Un CRONtab aurait été le bienvenu,
  • L'intégration aux autres services managés Azure comme Logic Apps, Data Factory est inexistante ou trop peu exploitable. Vous serez souvent obligé d'utiliser une Azure Function pour palier à ce manque,
  • Le moteur de recherche de l'historique des jobs n'est pas assez abouti.

Le mot de la fin

Si vous avez régulièrement besoin d'exécuter des traitements de plusieurs minutes sur le cloud, le service Azure Batch peut être considéré comme une véritable solution.

De plus, si vous êtes en pleine migration Cloud et que dans votre SI OnPremise vous avez des traitements batchs en ligne de commande, le service Azure Batch peut-être un véritable QuickWin. Il vous évitera un refactoring de vos batchs pour les intégrer à des services plus moderne comme Azure DataFactory.

Références

Remerciements

Rédigé par Philippe MORISSEAU, Publié le 1er Décembre 2021