Gérer l’analyse à l’échelle du cloud
Aujourd’hui, DevOps a modifié culturellement la façon dont les gens pensent et travaillent et a accéléré le rythme auquel les entreprises réalisent de la valeur en aidant les individus et les organisations à développer et à maintenir des pratiques de travail durables. DevOps combine le développement et les opérations, et est souvent associé à des outils d’ingénierie logicielle qui prennent en charge les pratiques d’intégration continue (CI) et de livraison continue (CD). Ces outils et pratiques incluent des gestionnaires de code source (comme Git, Apache Subversion ou Team Foundation Version Control) et des gestionnaires de génération et de remise automatiques (comme Azure Pipelines ou GitHub Actions).
DevOps, combinée à l’observabilité, est essentielle pour fournir une plateforme agile et évolutive. DevOps permet aux équipes d’implémenter le contrôle de code source, les pipelines CI/CD, l’infrastructure en tant que code, les workflows et l’automatisation. Tandis que l’observabilité permet aux propriétaires d’entreprise, aux ingénieurs DevOps, aux architectes de données, aux ingénieurs de données et aux ingénieurs de fiabilité des sites de détecter, de prédire, d’empêcher et de résoudre les problèmes de manière automatisée et d’éviter d’éliminer les temps d’arrêt qui interrompent l’analyse de production et l’IA.
Contrôle de code source
Le contrôle de code source garantit la persistance du code et des configurations ainsi que le suivi et la gestion des versions des modifications. La plupart des systèmes de contrôle de code source intègrent également des processus de révision et de travail dans différentes branches d’un référentiel de code. Actuellement, le type de contrôle de code source le plus populaire est Git, un système de contrôle de version distribué qui permet aux utilisateurs de travailler hors connexion et d’effectuer une synchronisation auprès des référentiels centraux. En général, les fournisseurs Git utilisent également des branches et suivent des instructions de demande de tirage pour prendre en charge le flux de modification et de révision.
Les branches isolent les modifications ou les développements de fonctionnalités sans affecter les autres tâches qui se produisent en même temps. L’utilisation des branches doit être encouragée pour développer des fonctionnalités, corriger des bogues et expérimenter de nouvelles idées en toute sécurité. Les demandes de tirage fusionnent les modifications apportées à partir d’une branche dans la branche par défaut, et elles prennent en charge un processus de révision contrôlé. Pour des raisons de sécurité, la branche principale doit utiliser des demandes de tirage pour garantir la révision du code.
Important
Suivez les recommandations suivantes pour les référentiels d’analyse à l’échelle du cloud :
- Sécurisez la branche principale du référentiel en appliquant des branches et des demandes de tirage pour garantir un processus de révision contrôlé.
- Les référentiels Azure DevOps ou GitHub doivent être utilisés pour le contrôle de code source afin de suivre les modifications apportées au code source et de permettre à plusieurs membres d’équipe de développer du code en même temps.
- Le code d’application et les configurations d’infrastructure doivent être vérifiés dans un référentiel.
Pipelines CI/CD
L’intégration continue (CI) permet aux équipes de tester et de générer automatiquement le code source et permet des itérations rapides et des boucles de rétroaction pour garantir une qualité élevée du code dans le déploiement continu (CD). Les pipelines sont des moyens de configurer l’intégration continue des modifications (code logiciel ou code d’infrastructure) et le déploiement continu des modifications groupées/compilées. Ce processus est également appelé génération et mise en production. Le déploiement continu décrit le déploiement automatique d’applications dans un ou plusieurs environnements. Il suit habituellement un processus de CI et utilise des tests d’intégration pour valider l’application entière.
Les pipelines peuvent contenir plusieurs étapes avec différentes tâches et présenter des flux d’approbation simples et complexes pour garantir la conformité et la validation. Selon la préférence, les pipelines peuvent également être configurés avec différents déclencheurs automatiques. Dans le cas d’un déploiement d’IA à l’échelle de l’entreprise, les étapes de production doivent toujours avoir une pré-approbation humaine, et cette opération est intégrée au modèle d’opération. Les pipelines CI/CD doivent être générés avec GitHub Actions ou Azure Pipelines, et être des déclencheurs automatisés.
Infrastructure as code
Le terme code dans l’infrastructure as code (IaC) suscite souvent des inquiétudes chez le personnel informatique qui n’a pas de formation de développeur, mais l’IaC ne fait pas référence à l’écriture de code comme le font les développeurs de logiciels traditionnels. Toutefois, il adopte un grand nombre des outils et principes des processus de développement de logiciels pour fournir une infrastructure dans un format prévisible.
L’IaC permet d’approvisionner, de configurer et de gérer l’infrastructure dans le cadre d’un pipeline DevOps avec des contrôles complets des changements, un historique des audits, des tests, des validations et des processus d’approbation, ce qui garantit une délégation des tâches aux rôles appropriés pour le projet sans compromettre la sécurité et la conformité.
Les deux approches de l’IaC sont déclaratives et impératives :
Le terme Déclaratif fait référence à la spécification de l’état souhaité de l’infrastructure et à la présence d’un moteur d’orchestration qui exécute les actions nécessaires pour atteindre l’état souhaité. Dans Azure, cette opération s’effectue à l’aide de modèles Azure Resource Manager. Des couches d’abstraction tierces comme Terraform sont également disponibles pour cette approche.
L’approche impérative fait référence à l’exécution de commandes spécifiques dans un ordre défini. Pour Azure, cela peut être réalisé avec l’interface de ligne de commande ou PowerShell, mais des kits de développement logiciel en langage de programmation natif, par exemple, .NET, Python et Java, sont également disponibles si des solutions intégrées sont requises.
Dans les modèles Azure Resource Manager, le provisionnement de base se trouve dans la section ressources, et la configuration des ressources individuelles est définie dans une section propriétés. Pour une instance Azure Data Lake Storage Gen2, la configuration ressemble à ce qui suit :
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"resources": [
{
"type": "Microsoft.MachineLearningServices/workspaces/datastores",
"name": "[concat(parameters('workspaceName'), '/', parameters('datastoreName'))]",
"apiVersion": "2020-05-01-preview",
"location": "[parameters('location')]",
"properties": {
"DataStoreType": "adls-gen2",
"SkipValidation": "[parameters('skipValidation')]",
"ClientId": "[parameters('clientId')]",
"ClientSecret": "[parameters('clientSecret')]",
"FileSystem": "[parameters('fileSystem')]",
"AccountName": "[parameters('accountName')]",
"TenantId": "[parameters('tenantId')]",
"ResourceUrl": "[parameters('resourceUrl')]",
"AuthorityUrl": "[parameters('authorityUrl')]"
}
}
]
}
Important
Chaque couche de l’analyse à l’échelle du cloud, telle que la zone d’atterrissage de gestion des données, les zones d’atterrissage des données ou les applications de données, doit être définie à l’aide d’un langage déclaratif comme Azure Resource Manager ou Terraform, archivée dans un référentiel et déployée via des pipelines CI/CD. Cela permet aux équipes de suivre et de versionner les modifications apportées à l’infrastructure et à la configuration de l’étendue Azure tout en prenant en charge différents niveaux d'architecture à automatiser de manière agile. Ces instructions incitent les équipes à utiliser des référentiels Git pour toujours avoir une visibilité sur l’état des étendues Azure spécifiques.
Workflows et automatisation
Les équipes doivent utiliser les pipelines CI/CD en plusieurs étapes pour s’assurer que le code développé est sans erreur et prêt pour la production. Certaines meilleures pratiques consistent à disposer d’un environnement de développement, d’un environnement de test et d’un environnement de production. Ces étapes doivent également être reflétées dans Azure en utilisant des services distincts pour chaque environnement.
L’équipe chargée de la plateforme est chargée de la fourniture et de la maintenance des modèles de déploiement afin de garantir une évolution rapide au sein d’une organisation et de simplifier les déploiements pour les équipes qui ne sont pas familières avec l’IaC. Ces modèles constituent un point de référence pour les nouveaux artefacts au sein du scénario et doivent être gérés dans le temps pour représenter les meilleures pratiques et les normes courantes au sein de l’entreprise.
Les déploiements pour le test et la production doivent être gérés uniquement via un pipeline CI/CD et une connexion de service avec des autorisations élevées pour appliquer les meilleures pratiques courantes (par exemple, des modèles Azure Resource Manager).
Attention
Les équipes chargées des applications de données doivent uniquement disposer d’un accès en lecture aux environnements de test et de production, et les déploiements vers ces environnements doivent être exécutés uniquement via des pipelines CI/CD et des connexions de service avec des autorisations élevées. Pour accélérer la mise en production, les équipes chargées des applications de données doivent disposer d’un accès en écriture à l’environnement de développement.