Considérations relatives à l’automatisation d’une plateforme Red Hat Enterprise Linux sur Azure
Cet article explique comment gérer l’automatisation de Red Hat Enterprise Linux (RHEL) sur Azure. Il décrit les éléments à prendre en compte lors de la conception, fournit des recommandations de conception et répertorie différentes options d’outils de l’écosystème Azure que vous pouvez utiliser pour obtenir un environnement cohérent et stable. Cet article fournit des conseils adaptés à différents scénarios client, exigences métier, pratiques opérationnelles et degrés de maturité technique.
Vue d’ensemble
Lorsque vous automatisez RHEL pour les zones d’atterrissage Azure, pour aligner la gestion du cycle de vie de ces zones, vous utilisez la norme d’infrastructure Red Hat (RH-IS, Red Hat Infrastructure Standard) et le modèle d’adoption associé (RH-ISAM, Red Hat Infrastructure Standard Adoption Model). Normaliser les systèmes pour fournir une base fiable à la solution. La RH-IS définit l’environnement d’exploitation standard qui comprend l’ensemble par défaut de composants et configurations logiciels. Vous pouvez appliquer ces composants et configurations aux systèmes via le RH-ISAM, un ensemble de principes opératoires DevOps ou Git, des modèles Azure Resource Manager (modèles ARM), Terraform, Azure CLI et Azure PowerShell.
Vous pouvez automatiser différentes opérations. Par exemple, vous pouvez utiliser Automation pour :
- Approvisionner des composants
- Gérer des systèmes
- Faire évoluer la plateforme
- Incorporer des opérations d’infrastructure
- Configurer les cycles de vie des applications et des charges de travail
Vous pouvez implémenter ces opérations via l’infrastructure en tant que code (IaC) et la configuration en tant que code. Pour réduire les erreurs et augmenter la fiabilité, définissez et testez les configurations. Pour accélérer les migrations en masse, automatisez l’approvisionnement. Les configurations automatisées réduisent les dérives de configuration et garantissent que les systèmes fonctionnent correctement.
Considérations sur la conception
Red Hat Identity Management (IdM) fournit une plateforme centralisée et unifiée que vous pouvez utiliser pour gérer les magasins d’identités, les stratégies d’authentification et les stratégies d’autorisation pour les systèmes RHEL. Dans un scénario hybride, vous pouvez étendre votre infrastructure Red Hat IdM existante sur un réseau privé virtuel ou Azure ExpressRoute. Cette configuration connecte des environnements locaux à la zone d’atterrissage RHEL dans Azure. Pour prendre en charge les scénarios d’identité cloud hybride, étendez votre environnement local dans Azure afin de pouvoir intégrer vos charges de travail à Microsoft Entra. Pour plus d’informations, consultez Authentification Microsoft Entra.
En tant que solution secondaire de gestion des identités, vous pouvez joindre RHEL de façon à créer une approbation externe avec Windows Server Active Directory ou joindre RHEL directement à une forêt Windows Server Active Directory existante. Pour plus d’informations, consultez Intégrer des systèmes RHEL directement à Windows Server Active Directory.
Red Hat Satellite est la source unique de contenu fournie aux systèmes RHEL managés. Satellite inclut des packages Red Hat et des correctifs, ainsi que des packages non-Microsoft et des packages personnalisés que les équipes de développement d’applications développent. Satellite agit comme passerelle vers Red Hat Insights, qui offre une analyse prédictive des configurations pour identifier les risques de sécurité ou de performances. Si vous déployez des images RHEL préconfigurées avec paiement à l’utilisation, vous pouvez tirer parti de l’infrastructure de mise à jour Red Hat pour Azure, qui est un outil de mise à jour intégré aux images avec paiement à l’utilisation.
Considérations relatives à la conception de Red Hat Ansible Automation Platform
Red Hat Ansible Automation Platform (AAP) facilite la normalisation des workflows techniques et des tâches récurrentes. Vous pouvez utiliser AAP pour orchestrer des workflows, approvisionner des processus pour de nouveaux systèmes et créer des tâches opérationnelles récurrentes. Pour réduire la complexité, utilisez une plateforme et un langage d’automatisation communs. Les workflows entièrement automatisés accélèrent l’innovation des applications et simplifient la migration en masse de charges de travail entre des environnements locaux et des environnements cloud.
Les avantages de RHEL en tant que stratégie d’automatisation de plateforme sont les suivants :
Les nouveaux systèmes disposent d’un approvisionnement à l’échelle entièrement automatisé, ce qui améliore la vitesse des migrations en masse.
Uniformisation accrue de la configuration des systèmes et des installations d’applications testés entre les systèmes physiques et les systèmes virtuels.
Mises à jour en continu, car la gestion des correctifs est immédiatement disponible.
Plateforme normalisée et simplifiée pour fournir de nouvelles applications et charges de travail. Le personnel a plus de temps pour innover.
Vous pouvez implémenter :
Une instance AAP automanagée via une infrastructure locale, une infrastructure cloud ou les deux. Vous pouvez utiliser un déploiement RHEL ou un déploiement Red Hat OpenShift Container Platform.
Une instance AAP automanagée dans un cloud public
Une instance AAP managée dans un cloud public
Red Hat AAP automanagé localement ou dans le cloud
Déployez Red Hat AAP sur Microsoft Azure en mode automanagé dans une infrastructure locale, cloud ou hybride pour bénéficier des avantages suivants :
Architecture et échelle : déterminez votre architecture idéale pour prendre en charge la plateforme Automation. Vous pouvez baser l’architecture sur l’infrastructure RHEL ou un déploiement d’opérateur OpenShift. En fonction de la taille et des exigences de votre flotte, choisissez le nombre et les dimensions des instances de contrôleurs, de nœuds d’exécution et d’instances du hub Automation privé. Pour plus d’informations sur l’architecture, la conception, la configuration et la mise à l’échelle, consultez le guide de planification Red Hat AAP.
Configuration Azure : optimisez l’architecture Automation pour la conception et la configuration Azure de votre organisation.
Prise en charge d’Automation Mesh : utilisez la fonctionnalité AAP Automation Mesh pour distribuer les charges de travail Automation sur des nœuds cloud hybrides qui établissent des connexions pair à pair à l’aide des réseaux existants. Placez les nœuds de tronçon dans un emplacement en fonction de vos critères de conception de sécurité et de la topologie du réseau.
Architecture du hub Automation : optimisez une architecture du hub Automation pour la mise à l’échelle et le placement des instances privées du hub Automation. Optimisez les configurations pour améliorer la distribution sécurisée de contenu Automation et l’accès aux sources d’environnement d’exécution proches des ressources d’exécution d’Automation. Vous pouvez choisir les collections et versions de contenu Ansible auxquelles les consommateurs d’Automation peuvent accéder.
AAP Red Hat managé ou automanagé sur Azure
Red Hat AAP sur Microsoft Azure est disponible via une application managée ou automanagée, ce qui offre les avantages suivants :
Un retour sur investissement rapide en raison d’une facilité d’utilisation : vous pouvez déployer AAP sur Azure directement à partir de la Place de marché Azure. Cette solution managée est active immédiatement après le déploiement et vous pouvez commencer à automatiser la gestion de vos ressources Azure en quelques minutes. Red Hat gère l’infrastructure. Vous pouvez ainsi vous concentrer sur d’autres systèmes critiques pour votre entreprise.
Intégration simplifiée : AAP sur Azure est intégré aux services Azure. Microsoft et Red Hat ont développé la collection Ansible pour Azure et l’ont testée pour vérifier qu’elle est sécurisée. Vous bénéficiez donc d’une prise en charge maximale avec une configuration minimale. Utilisez AAP sur Azure dans le cadre de votre stratégie d’automatisation cloud hybride pour unifier la gestion et l’automatisation dans le cloud hybride, l’Internet des objets et les déploiements de périphérie.
Dépenses Azure validées existantes : vous pouvez utiliser des dépenses validées existantes avec Microsoft pour acheter Red Hat AAP sur Azure. Utilisez les dépenses validées afin que les équipes de votre organisation puissent déployer, configurer et automatiser les composants de manière transparente. Avec la facturation intégrée, vous bénéficiez d’une facture unique et d’une visibilité complète sur le coût.
Automatisation au-delà du cloud : avec AAP sur Azure, vous pouvez déployer des applications dans votre cloud Microsoft Azure, puis les étendre sur votre infrastructure. Déployez, exécutez et mettez à l’échelle des applications dans des environnements cloud hybrides et Azure.
Prise en charge : Red Hat et Microsoft ont collaboré pour créer AAP sur Azure afin de garantir des opérations cohérentes où l’accent est mis sur la sécurité. Red Hat gère, opère et prend en charge l’application afin que votre équipe informatique puisse se concentrer sur les stratégies d’automatisation.
Autres considérations relatives au mode managé
Vous pouvez installer AAP sur Azure en mode managé afin qu’elle soit une application managée. Red Hat gère à la fois les ressources Azure sous-jacentes et le logiciel exécuté par-dessus. Cette infrastructure s’exécute dans votre locataire Azure.
Le groupe de ressources de l’application managée est distinct des autres groupes de ressources de votre locataire. Red Hat a accès au groupe de ressources de l’application managée uniquement, sans visibilité sur d’autres ressources du locataire.
Pour plus d’informations, voir Vue d’ensemble des applications managées Azure.
AAP sur Azure en mode managé utilise les groupes de ressources suivants :
Un groupe de ressources nouveau ou existant dans votre locataire. Ce groupe de ressources comprend une seule ressource qui fait référence au déploiement d’applications managées Azure dans AAP. Red Hat a accès à l’application managée pour effectuer les tâches de prise en charge, de maintenance et de mise à niveau. Mais Red Hat ne gère pas le groupe de ressources.
Groupe de ressources managés multilocataire (MRG) qui contient la plupart des infrastructures nécessaires pour exploiter AAP sur Azure. Le locataire Red Hat et votre locataire partagent ce groupe de ressources mutualisé. Red Hat dispose d’un contrôle administratif total. Vous disposez d’un accès en lecture au groupe de ressources.
Un groupe de ressources de pool de nœuds Azure Kubernetes Service (AKS) (NPRG). Microsoft a besoin d’un NPRG pour les déploiements AKS. Un NPRG contient des ressources utilisées par AKS pour fonctionner. Ce groupe de ressources est créé lors du déploiement. Red Hat ne gère pas ce groupe de ressources. Pour plus d’informations, consultez la documentation de Microsoft AKS.
Pour AAP sur Azure en mode managé, tenez également compte des facteurs suivants :
Lorsque vous installez AAP sur Azure, vous choisissez si le déploiement est public ou privé, ce dont dépend la façon dont les utilisateurs peuvent accéder aux interfaces utilisateur AAP.
Que vous choisissiez un déploiement public ou privé, vous devez configurer le peering réseau pour la communication sortante entre AAP et les réseaux privés qui contiennent des ressources que vous souhaitez automatiser. Vous pouvez configurer le peering réseau à partir d’AAP sur Azure vers votre réseau virtuel Azure privé et vers des réseaux locaux ou des réseaux multiclouds où le routage du transit avec Azure existe.
Autres considérations relatives au mode automanagé
AAP sur Azure en mode automanagé offre beaucoup d’avantages semblables à l’AAP managé. Mais, alors que le mode managé s’exécute dans un cluster AKS, les ressources de la plateforme Automation en mode automanagé sont basées sur des machines virtuelles.
Pour AAP sur Azure en mode automanagé, tenez compte des facteurs suivants :
Event-Driven Ansible est inclus dans l’offre automanagée sur Azure. L’automatisation basée sur les événements vous aide à réduire les tâches manuelles et à fournir un environnement informatique efficace qui se concentre sur l’innovation. Event-Driven Ansible traite les événements, détermine les réponses appropriées, puis exécute des actions automatisées pour corriger l’événement.
Les abonnements sont disponibles par incréments de 100 nœuds managés actifs. Ils sont disponibles dans les offres publiques ou les offres privées.
Les ressources de machine virtuelle qui sous-tendent AAP sur Azure en mode automanagé peuvent se composer entièrement d’images de la Place de marché Azure, ou d’un mélange d’images de la Place de marché Azure et d’images gérées par le client.
Recommandations de conception
Lorsque vous utilisez la plateforme RHEL pour les zones d’atterrissage Azure, utilisez du contenu certifié Red Hat et des collections de contenu validées à partir du hub Red Hat Automation. Les collections suivantes ont des rôles importants dans l’infrastructure Automation :
redhat.rhel_idm
- Configurez les machines virtuelles principales IdM.
- Configurez les réplicas IdM.
- Intégrez et configurez des clients RHEL avec IdM.
redhat.satellite, redhat.satellite_operations et redhat.rhel_system_roles
- Déployez Satellite et Capsule.
- Créez et configurez les objets et paramètres Satellite.
- Approvisionnez et configurez des systèmes RHEL.
ansible.*, ansible.controller et infra.controller_configuration
- Configurez AAP.
- Créez et configurez des modèles et des paramètres de travail AAP.
La collection Ansible pour Azure comprend plus de 250 modules que vous pouvez utiliser pour interroger, gérer et automatiser les types de ressources Azure, tels que :
- AKS.
- Groupes de sécurité d’application.
- Azure Container Registry.
- Services de base de données Azure
- Azure Key Vault.
- Azure SQL Database.
- Machines virtuelles Azure.
- Microsoft Entra ID.
- Mise en réseau.
- Stockage.
Déploiement d’infrastructure de plateforme de base
Établissez des concepts et des processus pour déployer efficacement l’infrastructure de plateforme de base et prendre en charge une plateforme RHEL sur un modèle de zones d’atterrissage Azure.
Pour plus d’informations, consultez l’article suivant :
Conseils de conception pour les zones d’atterrissage Azure aux fin d’automatisation de la plateforme.
Cycle de vie de développement. Découvrez les principaux éléments à prendre en compte ainsi que des recommandations sur l’utilisation d’Automation pour créer une zone d’atterrissage. Ces conseils décrivent le dépôt, la branche, les builds automatisées, le déploiement et la stratégie de restauration.
IaC. Découvrez les avantages de l’implémentation de zones d’atterrissage Azure via l’IaC. Découvrez les éléments à prendre en compte quant à la structure du code, aux outils et aux technologies.
Environnements. Découvrez comment utiliser plusieurs environnements pour créer, tester et publier du code plus rapidement et plus fréquemment. Cette approche rend le déploiement aussi simple que possible.
Développement piloté par les tests Découvrez comment utiliser les tests unitaires pour améliorer la qualité des nouvelles fonctionnalités et apporter des améliorations à la base de code de la zone d’atterrissage Azure.
Lorsque vous disposez des outils de gestion du code source requis et des processus de gestion du code source établis à partir des sections précédentes, vous pouvez implémenter Automation. Développez du code Ansible Automation avec l’IaC ou la configuration en tant que code associés pour déployer l’infrastructure principale et prendre en charge le modèle de plateforme RHEL pour les zones d’atterrissage Azure. Pour les déploiements Greenfield, vous pouvez automatiser les tâches suivantes pour une implémentation d’environnement complète. Pour les déploiements Brownfield, vous pouvez automatiser uniquement les tâches dont vous avez besoin.
- Créer des groupes de ressources Azure
- Créer des réseaux virtuels
- Créer des sous-réseaux
- Créer des groupes de sécurité réseau.
- Créer des images de référence RHEL 8.x et 9.x pour Azure via l’outil automatisé Red Hat Image Builder
- Créer une machine virtuelle principale IdM (approvisionnement pré-Satellite) Configurer la machine virtuelle principale IdM via la configuration en tant que code
- Créer une machine virtuelle Satellite (approvisionnement pré-Satellite) Configurer Satellite via la configuration en tant que code
- Créer des machines virtuelles de capsule (approvisionnement Satellite) Configurer la capsule via la configuration en tant que code
- Créer des machines virtuelles de réplica IdM (approvisionnement Satellite) Configurer des réplicas IdM via la configuration en tant que code
- Créer une infrastructure AAP (approvisionnement Satellite), notamment :
- Machines virtuelles de contrôleur Automation
- Machines virtuelles de nœud d’exécution
- Machines virtuelles de nœud de tronçon (facultatif)
- Machines virtuelles du hub Automation
- Machines virtuelles Event-Driven Ansible (si activées).
- Serveur Azure Database pour PostgreSQL et bases de données nécessaires pour les composants Ansible pilotés par le contrôleur, le hub et l’événement La haute disponibilité ou la récupération d’urgence des configurations Azure Database pour PostgreSQL nécessitent une automatisation supplémentaire via la copie de réplication, la copie des journaux ou Crunchy Postgres.
- Créer des équilibreurs de charge (passerelles d’application)
- Front-end pour les machines virtuelles Capsule
- Front-end pour les machines virtuelles du contrôleur AAP
- Front-end pour les machines virtuelles du hub Automation
- Créez des groupes de sécurité d’application.
- Infrastructure IdM
- Infrastructure AAP
- Infrastructure Satellite ou Capsule
Gestion du cycle de vie du système RHEL
Une fois l’infrastructure de la plateforme principale en place, vous pouvez implémenter l’automatisation pour les applications RHEL et les cycles de vie des charges de travail. Le workflow suivant décrit un exemple d’implémentation d’automatisation pour un pipeline de cycle de vie de développement :
Mettre à jour la date de fin du filtre errata et publier le contenu dans Satellite
Promouvoir les vues de contenu (CV) et les vues de contenu composites (CCV) pour le développement
Déployer des systèmes de test de développement RHEL à partir de groupes hôtes Satellite Les images de référence RHEL 8.x et 9.x pour Azure via l’outil automatisé Red Hat Image Builder sont définies en tant que ressources de calcul Azure dans Satellite
Mettre à jour ou créer des groupes de sécurité réseau Azure en fonction des chemins de communication d’application
Mettre à jour ou créer des groupes de sécurité d’application Azure pour fournir une sécurité supplémentaire dans les piles d’applications multiniveaux
Mettre à jour les systèmes de développement RHEL et déployer et configurer les applications souhaitées à partir de CV ou de CCV de développement Satellite
- Déployer sur une seule instance RHEL dans une pile d’applications simple
- Déployer sur plusieurs instances RHEL dans des piles d’applications multiniveaux
- Configurer une règle d’application
Exécuter une infrastructure de test d’application
- Si le test échoue, informer l’administration OnCall Automation pour faciliter l’analyse du problème et sa résolution Quitter le workflow Automation Les systèmes de test RHEL restent déployés pour l’analyse des défaillances post-mortem.
- Si le test réussit, continuer les étapes
Promouvoir les CV et les CCV pour l’assurance qualité (QA)
Détruire les systèmes de test de développement RHEL
Les étapes suivantes du pipeline du cycle de vie sont légèrement différentes de la phase de cycle de vie du développement. Seule la phase de développement utilise la publication de contenu initiale et la promotion initiale des CV et CCV pour le développement. L’exemple suivant décrit un workflow d’automatisation pour les pipelines de cycle de vie hors développement, par exemple des pipelines d’assurance qualité, de préproduction et de production.
Déployer des systèmes de test RHEL QA à partir de groupes hôtes Satellite Les images de référence RHEL 8.x et 9.x pour Azure via l’outil automatisé Red Hat Image Builder sont définies en tant que ressources de calcul Azure dans Satellite
Mettre à jour ou créer des groupes de sécurité réseau Azure en fonction des chemins de communication d’application
Mettre à jour ou créer des groupes de sécurité d’application Azure pour fournir une sécurité supplémentaire dans les piles d’applications multiniveaux
Mettre à jour les systèmes de QA RHEL et déployer et configurer les applications souhaitées à partir de CV ou de CCV dans Satellite QA
- Déployer sur une seule instance RHEL dans une pile d’applications simple
- Déployer sur plusieurs instances RHEL dans des piles d’applications multiniveaux
- Configurer une règle d’application
Exécuter une infrastructure de test d’application
- Si le test échoue, informer l’administration OnCall Automation pour faciliter l’analyse du problème et sa résolution Quitter le workflow Automation Les systèmes de test RHEL restent déployés pour l’analyse des défaillances post-mortem.
- Si le test réussit, continuer les étapes
Promouvoir les CV et les CCV pour la production
Détruire les systèmes de test RHEL QA
Autres éléments à prendre en compte lors de la conception pour les outils natifs Azure
Azure Automation
Pour automatiser les tâches de gestion fréquentes, longues et susceptibles d’engendrer des erreurs, vous pouvez utiliser l’automatisation des processus d’Azure Automation. Cette fonctionnalité vous permet de vous concentrer sur des activités à valeur ajoutée. L’automatisation des processus réduit les erreurs et améliore l’efficacité, ce qui permet de réduire vos coûts opérationnels. Pour plus d’informations, consultez Vue d’ensemble de l’automatisation.
L’automatisation des processus prend en charge l’intégration des services Azure et d’autres systèmes partenaires comme Red Hat dont vous avez besoin pour le déploiement, la configuration et la gestion de vos processus de bout en bout. Vous pouvez également utiliser cette fonctionnalité pour créer des runbooks graphiques PowerShell et Python.
Vous pouvez utiliser des runbooks pour un large éventail de tâches d’automatisation, telles que la gestion des ressources, le démarrage et l’arrêt de machines virtuelles, et les tâches de maintenance dans Azure et en dehors d’Azure. Pour plus d’informations, consultez Vue d’ensemble de l’authentification de compte Azure Automation et Runbooks dans Azure Automation.
Le tableau suivant décrit les types de runbooks pris en charge :
| Type de runbook | Description |
|---|---|
| PowerShell | Runbook textuel basé sur les scripts Windows PowerShell Les versions prises en charge sont PowerShell 7.2 (GA) et PowerShell 5.1 (GA). Le produit parent PowerShell ne prend plus en charge PowerShell 7.1. Nous vous recommandons de créer des runbooks dans la version prise en charge à long terme de PowerShell 7.2. |
| Workflow PowerShell | Runbook textuel basé sur les scripts Windows PowerShell Workflow |
| Python | Runbook textuel basé sur les scripts Python Les versions prises en charge sont Python 3.8 (GA) et Python 3.10 (preview). Le produit parent Python ne prend plus en charge Python 2.7. Nous vous recommandons de créer des runbooks dans des versions prises en charge à long terme. |
| Graphique | Runbook graphique basé sur Windows PowerShell et créé et modifié entièrement dans l’éditeur graphique du portail Azure |
| Graphique workflow PowerShell | Runbook graphique basé sur le workflow Windows PowerShell et créé et modifié entièrement dans l’éditeur graphique du portail Azure |
Les webhooks vous permettent de répondre aux demandes et de garantir la continuité de la livraison et des opérations en déclenchant l’automatisation à partir d’Azure Logic Apps, d’Azure Function, de produits ou services de gestion des services informatiques, de DevOps et de systèmes de monitoring.
Azure Arc représente une avancée significative dans le cloud computing et offre une plateforme de gestion unifiée qui étend les fonctionnalités Azure aux environnements locaux, multiclouds et de périphérie. Azure Arc s’intègre au service Azure Automation à l’aide du framework d’extension de machine virtuelle pour déployer le rôle de travail de runbook hybride et simplifier l’intégration aux fonctionnalités de management des services, de suivi des modifications et d’inventaire.
Pour plus d’informations, consultez Connecter un serveur Linux existant à Azure Arc.
Modèles ARM
IaC via des modèles ARM fournit une méthode déclarative cohérente pour déployer et gérer des ressources Azure. Utilisez des modèles ARM pour définir l’infrastructure requise pour vos applications au format JSON. Les modèles ARM sont idempotents, ce qui signifie que vous pouvez déployer le même modèle plusieurs fois et obtenir les mêmes types de ressources dans le même état.
Pour plus d’informations, voir la Documentation des modèles ARM.
Exemple JSON
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"location": {
"type": "string",
"defaultValue": "[resourceGroup().location]"
},
"storageAccountName": {
"type": "string",
"defaultValue": "[format('toylaunch{0}', uniqueString(resourceGroup().id))]"
}
},
"resources": [
{
"type": "Microsoft.Storage/storageAccounts",
"apiVersion": "2021-06-01",
"name": "[parameters('storageAccountName')]",
"location": "[parameters('location')]",
"sku": {
"name": "Standard_LRS"
},
"kind": "StorageV2",
"properties": {
"accessTier": "Hot"
}
}
]
}
Vous pouvez utiliser le langage spécifique au domaine Bicep pour réduire la complexité de la syntaxe JSON et accélérer l’apprentissage d’Azure pour les nouveaux utilisateurs. Bicep est une abstraction transparente par rapport à un modèle ARM qui utilise JSON. Il conserve les fonctionnalités du modèle JSON. Pendant le déploiement, l’interface de ligne de commande Bicep convertit un fichier Bicep en un modèle ARM qui utilise JSON.
Les exemples dans cette section illustrent la différence entre un fichier Bicep et le modèle JSON équivalent. Les deux exemples déploient un compte de stockage.
Exemple Bicep
param location string = resourceGroup().location
param storageAccountName string = 'toylaunch${uniqueString(resourceGroup().id)}'
resource storageAccount 'Microsoft.Storage/storageAccounts@2021-06-01' = {
name: storageAccountName
location: location
sku: {
name: 'Standard_LRS'
}
kind: 'StorageV2'
properties: {
accessTier: 'Hot'
}
}
Azure DevOps
Azure DevOps est un ensemble complet d’outils de développement qui fournissent des services de gestion de projet, d’intégration continue et de livraison continue (CI/CD) et de dépôt de code source pour les environnements cloud et locaux. Vous pouvez combiner ces fonctionnalités avec Azure Test Plans, Azure Artifacts, Logic Apps et Azure Functions pour faciliter la collaboration, le développement et la livraison de projets logiciels modernes.
Azure Boards
Azure Boards prend en charge les méthodologies Agile pour le développement de logiciels cloud et la gestion des projets. Pour plus d’informations, consultez la documentation Azure Boards et Configurer et personnaliser Azure Boards.
Pour tirer le meilleur parti d’Azure Boards, comprenez comment vos équipes utilisent leurs outils et fonctions (par exemple, Scrum, Kanban et Scrumban), et comment ces outils dépendent des configurations et des personnalisations.
Le tableau suivant résume les principaux éléments à prendre en compte pour structurer votre projet.
| Au niveau du projet | Au niveau de l’équipe |
|---|---|
| Nombre d’équipes que vous souhaitez définir | Comment utiliser votre backlog produit pour planifier et hiérarchiser votre travail |
| Comment structurer les chemins de zone pour prendre en charge les vues de gestion de portefeuille | Si vous suivez les bogues en tant qu’exigences ou en tant que tâches, ou si vous n’utilisez pas de bogues du tout |
| Personnalisation des champs | Si vous utilisez ou non des tâches pour suivre le temps et la capacité |
| Types d’élément de travail personnalisés | Utilisation des niveaux de backlog de portefeuille |
| Personnalisations du backlog de portefeuille | Utilisation des niveaux de backlog de portefeuille |
| Personnalisation des workflows | Comment informer vos supérieurs de la progression, de l’état et des risques |
Azure Pipelines
Azure Pipelines offre un moyen rapide, facile et sûr d’automatiser vos builds de projets avec du code cohérent et de qualité facilement disponible.
Azure Pipelines :
- Fonctionne avec n’importe quel langage ou plateforme
- Se déploie sur différents types de cibles en même temps
- S’intègre aux déploiements Azure
- Génère sur des machines Windows, Linux ou Mac
- S’intègre à GitHub
- Fonctionne avec les projets open source
Pour plus d’informations, consultez la documentation Azure Pipelines.
Selon vos besoins organisationnels, vous pouvez choisir l’une des quatre architectures principales pour Azure Pipelines :
- Architecture de base d’Azure Pipelines
- Architecture Azure Pipelines pour la fonctionnalité Web Apps d’Azure App Service
- Architecture Azure Pipelines avec Azure DevTest Labs
- Architecture Azure Pipelines pour l’infrastructure en tant que service
Azure Repos
Azure Repos fournit deux types de contrôle de version, le contrôle de version Git et le contrôle de version centralisé.
Pour accéder à votre code, connectez votre environnement de développement à Azure Repos. Partager votre code via :
Pour plus d’informations, consultez la documentation Git Azure Repos et la documentation Team Foundation Version Control.
Utiliser des pipelines de mise en production et des sources Azure Artifacts
Azure Artifacts permet aux développeurs de publier et d’utiliser différents types de packages à partir de flux et de registres publics tels que PyPI, Maven Central et NuGet.org. Vous pouvez utiliser Azure Artifacts avec Azure Pipelines pour publier des artefacts de build et de pipeline, déployer des packages ou intégrer des fichiers à différentes étapes de votre pipeline pour la création, le test ou le déploiement de votre application.
Pour plus d’informations, consultez l’article suivant :
- Azure Artefacts dans Azure Pipelines
- Pipelines de mise en production et sources Azure Artifact
- Démarrer avec les autorisations et les accès
Intégrer Azure Policy avec Azure DevOps
Azure Policy s’applique directement aux ressources dans les environnements Azure, mais ses principes et sa gouvernance peuvent influencer indirectement les pratiques Azure DevOps. Par exemple, Azure Policy peut affecter :
Conformité dans les pipelines CI/CD : vous pouvez intégrer des vérifications de conformité dans vos pipelines. Par exemple, vous pouvez vérifier que toute infrastructure que vous déployez via Azure DevOps est conforme aux stratégies que vous définissez dans Azure Policy.
Cohérence de l’environnement : utilisez Azure Policy pour appliquer des configurations ou des types de ressources spécifiques pour vous assurer que les environnements que vous déployez via Azure DevOps sont cohérents et conformes.
Sécurité et gouvernance : les stratégies peuvent appliquer des normes de sécurité et des pratiques de gouvernance sur les ressources managées par Azure DevOps Projects. Ce règlement garantit que le cycle de vie du développement inclut la conformité aux normes organisationnelles et réglementaires.
Pour intégrer efficacement Azure Policy à Azure DevOps, vous pouvez utiliser les données de conformité Azure Policy et les fonctionnalités d’audit pour améliorer vos pratiques DevOps. Apportez des ajustements à vos pipelines ou définitions IaC pour vous aligner sur les stratégies organisationnelles que vous appliquez via Azure Policy.
Cette intégration garantit que les ressources que vous déployez et gérez via Azure DevOps sont toujours conformes aux normes de gouvernance de votre entreprise. Utilisez cette approche pour améliorer la sécurité, la cohérence et la gestion des coûts dans les environnements Azure.