Vue d’ensemble de l’architecture pour Azure DevOps Server
Azure DevOps Server 2022 | Azure DevOps Server 2020 | Azure DevOps Server 2019
Pour planifier et gérer au mieux votre déploiement, vous devez d’abord comprendre l’architecture sous-jacente de Azure DevOps Server. La compréhension de l'architecture peut vous aider à assurer l'intégrité globale du déploiement et à garantir la disponibilité globale des serveurs et des services dont vos équipes de développement ont besoin.
Vous pouvez déployer Azure DevOps Server de plusieurs façons : sur un serveur, sur plusieurs serveurs, ou dans un domaine ou un groupe de travail ou entre des domaines. Vous pouvez également choisir d’utiliser Azure DevOps Services, où tous les éléments serveur de votre déploiement sont hébergés pour vous par Microsoft. La compréhension de l'architecture peut vous aider à choisir la topologie la plus à même de répondre aux besoins de votre organisation. Quel que soit votre choix de topologie, si vous comprenez l’architecture sous-jacente Azure DevOps Server, vous pouvez mieux gérer les exigences physiques et logiques. Cet article fournit une vue d’ensemble simple des différentes architectures, avec des liens vers plus d’informations sur les exemples de déploiements. Il fournit également des informations techniques relatives aux services, aux bases de données, aux données de configuration et aux ports réseau et protocoles de déploiements locaux.
Pour comprendre l’architecture de Azure DevOps Server et son impact sur votre déploiement, vous devez prendre en compte les éléments suivants :
- Les niveaux application logique, données et client d’Azure DevOps, et si vous souhaitez utiliser un ou plusieurs serveurs pour les niveaux Application et Données, ou si vous souhaitez que les niveaux Application et Données soient hébergés dans le cloud pour vous à l’aide de Azure DevOps Services
- L'emplacement des serveurs physiques ou virtuels qui hébergent ces couches
- Team Foundation Build et le nombre et l’emplacement des ordinateurs de build qui s’exécutent dans votre environnement, y compris le nombre dont vous pourriez avoir besoin pour prendre en charge vos pratiques de développement, ou si vous allez utiliser les services cloud Azure Pipelines pour créer et déployer vos applications logicielles
- Le besoin potentiel pour le serveur proxy Azure DevOps
De plus, vous devez considérer les interactions entre ces entités. Par exemple, si vous choisissez d’utiliser le service Azure DevOps Server hébergé, vous devez vous assurer que vos clients peuvent accéder au service sur le port 443. Si vous choisissez de déployer Azure DevOps Server localement, vous devez savoir quels services Web, bases de données et modèles objet Azure DevOps Server utilise. En outre, vous devez savoir quels ports réseau et protocoles Azure DevOps Server utilise par défaut et quels ports réseau vous pouvez personnaliser. Enfin, vous devez comprendre les autorisations que vous devez définir dans Azure DevOps Server et les composants et programmes dont dépend votre déploiement.
Outre ses propres services, Azure DevOps Server dépend d’autres services pour fonctionner. Pour plus d’informations sur ces services, consultez Concepts Azure DevOps Server et Composants de l’entrepôt de données Azure DevOps Server. Pour plus d’informations sur la configuration requise et les dépendances pour l’installation, consultez Azure DevOps Server guide d’installation.
Important
Vous ne devez pas modifier manuellement les bases de données Azure DevOps Server, sauf si vous êtes invité à le faire par Support Microsoft ou si vous suivez les procédures décrites pour la sauvegarde manuelle des bases de données. Toutes les autres modifications peuvent invalider votre contrat de service.
Azure DevOps Services
Microsoft offre la possibilité d’utiliser Azure DevOps Services, qui peut héberger tous les aspects côté serveur de Azure DevOps Server pour vous. Le code source, les éléments de travail, les configurations de build et les fonctionnalités d'équipe sont hébergés dans le cloud. D’un point de vue architectural, cela simplifie considérablement l’utilisation de Azure DevOps Server, car les seuls aspects de l’architecture que vous devez prendre en compte sont les composants clients et leur accès à Internet.
Lorsque vous utilisez le Azure DevOps Services, vous utilisez un navigateur web pour vous connecter au service à l’aide de votre compte Microsoft. Vous pouvez créer des projets, ajouter des membres à votre équipe et travailler comme vous le feriez avec un Azure DevOps Server installé localement, sans la surcharge liée à l’administration des serveurs. Azure DevOps Services héberge vos serveurs de couche Application, de couche Données et de build dans le cloud.
Pour en savoir plus sur les services cloud et les déploiements locaux, passez en revue Azure DevOps Services et Azure DevOps Server.
Modèle d'objet
Avec l’architecture hébergée ou déployée localement, vous pouvez étendre les fonctionnalités d’Azure DevOps en écrivant une application basée sur son modèle objet serveur ou client. Dans tous les types de déploiement, écrivez les applications qui étendent les fonctionnalités clientes. Cependant, si vous souhaitez étendre les fonctions de serveur, votre application doit s'exécuter sur le serveur de couche Application. Pour étendre les fonctionnalités du client, vous devez exécuter l’application sur le même ordinateur que Team Explorer.
Services web et bases de données pour les déploiements locaux
Azure DevOps Server inclut un ensemble de services web et de bases de données que vous installez et configurez séparément sur le ou les serveurs qui hébergent les niveaux application logique, données et client pour Azure DevOps. Certaines fonctionnalités, telles que le tableau des tâches et les fonctionnalités basées sur l’équipe de backlog, sont entièrement basées sur le web et accessibles uniquement via un portail web, un service web côté client. D’autres, telles que les fonctionnalités de gestion de version, sont accessibles via un portail web ou via une application cliente. Les illustrations suivantes fournissent une vue d’ensemble des services web, des applications et des bases de données pour les déploiements locaux de Azure DevOps Server.
Services au niveau de la collection
Les services au niveau du regroupement fournissent les fonctionnalités pour les opérations au niveau de la collection de projets. Vous pouvez créer des applications qui étendent Azure DevOps Server à l’aide de certains de ces services. Pour plus d’informations sur la création d’applications pour Azure DevOps Server, consultez Développer des extensions.
Notes
Certains services s'affichent dans plusieurs niveaux. Par exemple, les fonctions du service Registre au niveau de la collection et au niveau serveur, et apparaît dans les deux listes.
Services d’infrastructure :
- Service de registre
- Service d’inscription (pour la compatibilité avec les versions antérieures de Azure DevOps Server)
- Service de propriété
- Service d'événement
- Service de sécurité
- Service de localisation
- Service de gestion des identités
- Service web de contrôle de version
- Service web de suivi des éléments de travail
- Service web Team Foundation Build
- Service web Lab Management
- Service web d'administration VMM
- Service web du contrôleur d'agent de test
Services au niveau du serveur
Les services au niveau du serveur (également appelés services au niveau de l’application) fournissent les fonctionnalités d’opérations pour Azure DevOps Server en tant qu’application logicielle. Vous pouvez créer des applications qui étendent Azure DevOps Server à l’aide de certains de ces services.
Services d’infrastructure :
- Service de registre
- Service d’événements
- Service de collection de projets
- Service de propriété
- Service de sécurité
- Service de localisation
- Service de gestion des identités
- Service d'administration
- Service de gestion de collection
- Service de catalogue
Couche Données
La couche Données inclut des données, des procédures stockées et une autre logique associée. Lorsque vous utilisez Azure DevOps Services, la couche Données est hébergée pour vous à l’aide de SQL Server Azure. Dans un déploiement local de Azure DevOps Server, la couche Données logiques se compose des magasins opérationnels suivants au sein de SQL Server. Ces magasins peuvent se trouver sur un serveur physique ou être distribués sur plusieurs serveurs. Vous pouvez créer des applications qui étendent Azure DevOps Server à l’aide de certains de ces magasins opérationnels.
- Base de données de configuration (TFS_Configuration)
- Entrepôt d'application (TFS_Warehouse)
- Base de données Analysis Services (TFS_Analysis)
- Bases de données pour les collections de projets (TFS_CollectionName)
Le tableau suivant fournit une liste des bases de données que Azure DevOps Server utilise dans les déploiements locaux. Sauf indication contraire, vous pouvez déplacer toutes les bases de données de cette liste à partir du serveur d'origine et de l'instance où elles sont installées, puis les restaurer sur un autre serveur ou une autre instance.
Nom de la base de données Description Serveur TFS_Configuration Cette base de données stocke le catalogue de ressources et les informations de configuration pour Azure DevOps Server. Cette base de données contient les magasins opérationnels pour Azure DevOps Server. Instance de SQL Server utilisée lors de l’installation et de la configuration de Azure DevOps Server. TFS_Warehouse Cette base de données stocke les données pour les rapports. Instance de SQL Server utilisée lors de l’installation et de la configuration de Azure DevOps Server. TFS_Analysis Cette base de données multidimensionnelle stocke les données agrégées des collections de projets. Instance de SQL Server utilisée lors de l’installation et de la configuration de SQL Server Analysis Services. Bases de données pour les collections de projets Une base de données pour chaque collection de projets, contenant les données de tous les projets de cette collection. Instance de SQL Server compatible avec Azure DevOps Server.
Couche cliente
La couche Application communique avec cette couche via le modèle d'objet serveur et utilise les mêmes services web qui sont répertoriés pour cette couche. Cela est vrai si vous déployez Azure DevOps Server localement ou si vous utilisez Azure DevOps Services. Outre ce modèle, la couche cliente est constituée de composants Visual Studio Industry Partners (VSIP), de l'intégration Microsoft Office, des interfaces en ligne de commande et d'une infrastructure pour les stratégies d'archivage.
Configuration
Le service hébergé dépend des services clients déployés localement et d'une connexion Internet à l'application et aux couches Données hébergées dans le cloud. Un déploiement local de Azure DevOps Server dépend de SQL Server, des services INTERNET (IIS) et du système d’exploitation Windows. En fonction de la topologie choisie, Azure DevOps Server peuvent également dépendre de SQL Server Reporting Services ou de produits SharePoint. Par conséquent, les informations de configuration pour Azure DevOps Server peuvent être stockées dans l’un des emplacements suivants :
- Magasins de données IIS.
- Fichiers de configuration pour Azure DevOps Server.
- Sources de données pour Reporting Services (par exemple, données TFSREPORTS).
- Base de données de configuration pour Azure DevOps Server. Le registre Azure DevOps Server fait partie de la base de données de configuration.
- Registre Windows.
Pour obtenir des exemples de topologies de déploiement local différentes et où ces ressources sont stockées, consultez Exemples de topologie simple, Exemples de topologie modérée et Exemples de topologie complexe. Lorsque vous gérez un déploiement local de Azure DevOps Server, vous devez tenir compte de ces sources de configuration. Pour modifier la configuration d'une quelconque façon, vous pouvez avoir besoin de modifier des informations qui sont stockées à plusieurs endroits. Vous devrez peut-être modifier également les informations de configuration pour les couches Données et Cliente. Azure DevOps Server inclut une console d’administration et plusieurs utilitaires de ligne de commande pour vous aider à effectuer ces modifications. Pour plus d’informations, consultez Informations de référence rapides sur les tâches d’administration.
Active Directory et synchronisation des identités de groupe
Dans les déploiements locaux où Azure DevOps s’exécute dans un domaine Active Directory, les informations de groupe et d’identité sont synchronisées lorsque l’un des événements suivants se produit :
- Le serveur de la couche Application démarre.
- Un groupe Active Directory est ajouté à un groupe Azure DevOps.
La période de temps spécifiée dans le travail planifié s'écoule. La valeur par défaut est une heure, et tous les groupes dans Azure DevOps Server mis à jour toutes les 24 heures.
Les services de gestion des identités (IMS, Identity Management Services) se synchronisent avec Active Directory et les identités modifiées se propagent du serveur aux clients. Par défaut, tous les groupes sont mis à jour dans les 24 heures, mais vous pouvez personnaliser ce paramètre afin de répondre au mieux aux besoins de votre déploiement. Pour plus d’informations, consultez Considérations relatives aux approbations et aux forêts pour Azure DevOps Server. Pour les déploiements locaux qui n’utilisent pas Active Directory, consultez Gestion des Azure DevOps Server dans un groupe de travail.
Groupes et autorisations
Dans un déploiement local, Azure DevOps Server a son propre ensemble de groupes et d’autorisations par défaut que vous pouvez définir au niveau du projet, du regroupement ou du serveur. Vous pouvez créer des groupes personnalisés et personnaliser des autorisations au niveau des groupes et des individus. Toutefois, les utilisateurs ou les groupes que vous ajoutez à Azure DevOps Server ne sont pas automatiquement ajoutés à deux composants sur lesquels les déploiements locaux de Azure DevOps Server peuvent dépendre : produits SharePoint et Reporting Services. Si votre déploiement utilise ces programmes, vous devez y ajouter des utilisateurs et des groupes et leur accorder les autorisations appropriées pour que ces utilisateurs ou groupes fonctionnent correctement dans toutes les opérations dans Azure DevOps Server. Pour plus d’informations, consultez Gérer les utilisateurs ou les groupes dans Azure DevOps Server.
Pour les déploiements hébergés, l'accès est contrôlé par une combinaison de comptes Microsoft et d'appartenance à une équipe. Pour plus d’informations, consultez la vue d’ensemble Azure DevOps Services.
Ports et protocoles réseau
Par défaut, un déploiement local de Azure DevOps Server est configuré pour utiliser des protocoles et des ports réseau spécifiques. L’illustration suivante montre le trafic réseau pour Azure DevOps Server dans un déploiement simple.
De même, le service hébergé pour Azure DevOps Server est configuré pour utiliser des protocoles et des ports réseau spécifiques. L'illustration suivante montre le trafic réseau dans un déploiement hébergé.
L’illustration suivante montre le trafic réseau dans un déploiement plus complexe qui inclut les composants de Visual Studio Lab Management. (Notez que Lab Management a été déconseillé pour TFS 2017 et versions ultérieures.)
Les ordinateurs virtuels utilisent le port 80 pour communiquer avec un contrôleur de test concernant le téléchargement d'un agent Lab Management. Si vous rencontrez des problèmes de communication, vérifiez que ce port est activé.
Paramètres réseau par défaut
Par défaut, la communication entre les ordinateurs dans un déploiement d’Azure DevOps utilise les protocoles et les ports indiqués dans le tableau suivant. Si un astérisque (*) suit le numéro de port, vous pouvez personnaliser ce port.
| Couche et service | Protocol | Port |
|---|---|---|
| Couche Application - Services web | HTTP/HTTPS | 8080/443* |
| Couche Application – Administration des produits SharePoint | HTTP | 17012* si les produits SharePoint ont été installés avec Azure DevOps Server ; sinon, générés de manière aléatoire |
| Couche Application – Produits et Reporting Services SharePoint | HTTP Service Windows Management Instrumentation (WMI) (obligatoire pendant l'installation pour spécifier et vérifier les URL chargées de signaler les services) |
Port dynamique 80* |
| Couche Données | MS-SQL TCP | 1433* |
| Couche Données (SQL Server Analysis Services) | MS-AS | par défaut (2382 ou 2383)* Le port par défaut varie selon la version de SQL Server que vous avez installée et le type d'instance. Utilisez le Gestionnaire de configuration SQL Server pour déterminer les ports utilisés par votre déploiement. |
| Serveur proxy Azure DevOps - client à proxy | HTTP | 8081* |
| Serveur proxy Azure DevOps - proxy vers la couche Application | HTTP/HTTPS | 8080/443* |
| Couche cliente - Reporting Services | HTTP | 80* |
| Couche cliente - Services web | HTTP/HTTPS | 8080/443* |
| Générer un contrôleur vers la couche Application HTTP/HTTPS | 8080/443 | |
| Agent de build vers couche Application | HTTP/HTTPS | 8080/443 |
| Release Management Server | HTTP ou HTTPS | 1000* |
| Release Management Client | HTTP ou HTTPS | 1000* |
| Release Management Agent | HTTP ou HTTPS | 1000* |
| Contrôleur de test vers couche Application | HTTP/HTTPS | 8080/443* |
| Couche Application vers contrôleur de test | .NET Remoting | 6901* |
| Couche Application vers DNS (Domain Name System) | Mise à jour dynamique de DNS | 53 |
| Couche Application – Virtual Machine Manager | HTTP | 8100 |
| Contrôleur de test vers agent de test | .NET Remoting | 6910* |
| Agent de test vers contrôleur de test | .NET Remoting | 6901* |
| Contrôleur de build vers agent de build | SOAP sur HTTP | 9191 |
| Agent lab vers agent lab dans un environnement isolé | Sockets TCP | 9050 |
| Agent de build vers contrôleur de build | SOAP sur HTTP | 9191 |
| Console Administrateur Virtual Machine Manager – Virtual Machine Manager | HTTP | 8100 |
| Virtual Machine Manager – Hôtes Virtual Machine Manager | Administration à distance Windows (WinRM) pour exécuter des actions Service de transfert intelligent en arrière-plan (BITS) pour transférer des données |
80 pour exécuter des actions 443 pour transférer des données |
| Virtual Machine Manager – Serveur de bibliothèque Virtual Machine Manager | WinRM pour exécuter des actions BITS pour transférer des données |
80 pour exécuter des actions 443 pour transférer des données |
| Couche Application – Hôtes Virtual Machine Manager | Communication DCOM/WMI (Distributed Component Object Model/Windows Management Interface) pour transférer des données | 135 Assigné dynamiquement dans la plage 49152 à 65535 |
| Couche cliente – Hôtes Virtual Machine Manager | Connexion basée sur hôte à l'ordinateur virtuel. | 2179 pour effectuer des connexions basées sur l’hôte |
| Services hébergés | HTTPS | 443 |
Paramètres réseau personnalisables
Comme le montre le tableau précédent, vous pouvez modifier la communication entre l’application, les données et les niveaux client dans les déploiements locaux en modifiant Azure DevOps Server pour utiliser des ports personnalisés. Le tableau suivant décrit les exemples de modification apportées aux ports de HTTP vers HTTPS.
Notes
Pour configurer Azure DevOps Server utiliser HTTPS et Secure Sockets Layer, vous devez non seulement activer les ports pour le trafic réseau HTTPS, mais également effectuer de nombreuses autres tâches. Pour plus d’informations, consultez Configurer HTTPS avec SSL (Secure Sockets Layer) pour Azure DevOps Server.
| Service | Protocol | Port |
|---|---|---|
| Services web avec SSL | HTTPS | Configuré par l'administrateur |
| Https administration centrale de SharePoint | Configuré par l'administrateur | |
| Produits SharePoint | HTTPS | 443 |
| Reporting Services | HTTPS | 443 |
| Services web clients | HTTPS | Configuré par l'administrateur |
| Gestion des versions | HTTPS | Configuré par l'administrateur |