Panoramica dell'architettura per Azure DevOps Server
Azure DevOps Server 2022 | Azure DevOps Server 2020 | Azure DevOps Server 2019
Per pianificare e gestire meglio la distribuzione, è prima necessario comprendere l'architettura sottostante di Azure DevOps Server. Comprendere l'architettura consente di gestire l'integrità complessiva della distribuzione e di garantire la disponibilità generale dei server e dei servizi necessari ai team di sviluppo.
È possibile distribuire Azure DevOps Server in diversi modi: in un server, in molti server o in un dominio o in un gruppo di lavoro o in più domini. In alternativa, è possibile scegliere di usare Azure DevOps Services, in cui tutti gli elementi server della distribuzione sono ospitati da Microsoft. Comprendere l'architettura può aiutare a decidere la topologia che con più probabilità soddisfa le proprie esigenze. Indipendentemente dalla scelta della topologia, se si comprende l'architettura sottostante Azure DevOps Server, è possibile gestire meglio i requisiti fisici e logici. Questo articolo offre una semplice panoramica delle varie architetture, con collegamenti a altre informazioni sulle distribuzioni di esempio. Vengono inoltre fornite informazioni tecniche sui servizi, sui database, sulle informazioni di configurazione, nonché protocolli e porte di rete delle distribuzioni locali.
Per comprendere l'architettura di Azure DevOps Server e come influisce sulla distribuzione, è consigliabile considerare quanto segue:
- Applicazione logica, dati e livelli client di Azure DevOps e se si desidera usare uno o più server per i livelli di dati e dell'applicazione o se si desidera che i livelli di applicazione e dati ospitati nel cloud siano ospitati usando Azure DevOps Services
- La posizione dei server fisici o virtuali in cui vengono ospitati i livelli in questione
- Team Foundation Build e il numero e la posizione dei computer di compilazione eseguiti nell'ambiente, incluso il numero di procedure di sviluppo necessarie o se si useranno i servizi cloud di Azure Pipelines per compilare e distribuire le applicazioni software
- La potenziale necessità del server proxy di Azure DevOps
È inoltre necessario considerare le interazioni tra queste entità. Ad esempio, se si sceglie di usare il servizio di Azure DevOps Server ospitato, è necessario assicurarsi che i client possano accedere al servizio sulla porta 443. Se si sceglie di distribuire Azure DevOps Server in locale, è necessario conoscere i servizi Web, i database e i modelli a oggetti Azure DevOps Server usati. È inoltre necessario conoscere quali porte di rete e protocolli Azure DevOps Server utilizzano per impostazione predefinita e quali porte di rete è possibile personalizzare. Infine, è necessario comprendere quali autorizzazioni è necessario impostare in Azure DevOps Server e i componenti e i programmi in base ai quali dipende la distribuzione.
Oltre ai propri servizi, Azure DevOps Server dipende da altri servizi per funzionare. Per altre informazioni su questi servizi, vedere Azure DevOps Server concetti e componenti del data warehouse Azure DevOps Server. Per altre informazioni sui requisiti e sulle dipendenze per l'installazione, vedere Azure DevOps Server guida all'installazione.
Importante
Non è consigliabile modificare manualmente uno dei database Azure DevOps Server, a meno che non venga richiesto di farlo supporto tecnico Microsoft o si seguono le procedure descritte per eseguire manualmente il backup dei database. Tutte le altre modifiche possono invalidare il contratto di assistenza.
Azure DevOps Services
Microsoft offre l'opzione di usare Azure DevOps Services, che può ospitare tutti gli aspetti lato server di Azure DevOps Server per l'utente. Il codice sorgente, gli elementi di lavoro, le configurazioni di compilazione e le funzionalità del team sono tutti ospitati nel cloud. Dal punto di vista dell'architettura, questo semplifica notevolmente l'uso di Azure DevOps Server, come gli unici aspetti dell'architettura da considerare sono i componenti client e l'accesso a Internet.
Quando si usa il Azure DevOps Services, usare un Web browser per connettersi al servizio usando l'account Microsoft. È possibile creare progetti, aggiungere membri al team e lavorare come si farebbe con un Azure DevOps Server installato in locale, senza il sovraccarico dell'amministrazione dei server. Azure DevOps Services ospita il livello dell'applicazione, il livello dati e i server di compilazione nel cloud.
Per altre informazioni sui servizi cloud rispetto alle distribuzioni locali, vedere Azure DevOps Services e Azure DevOps Server.
Il modello a oggetti
Con l'architettura ospitata o distribuita in locale, è possibile estendere le funzionalità e le funzionalità di Azure DevOps scrivendo un'applicazione basata sul server o sul modello a oggetti client. In tutti i tipi di distribuzione è possibile scrivere applicazioni mediante le quali si estendono le funzionalità client. Tuttavia, se si desidera estendere le funzionalità del server, l'applicazione deve essere eseguita nel server a livello di applicazione. Per estendere le funzionalità client, è necessario eseguire l'applicazione nello stesso computer di Team Explorer.
Servizi Web e database per distribuzioni locali
Azure DevOps Server include un set di servizi Web e database installati e configurati separatamente nel server o nei server che ospitano l'applicazione logica, i dati e i livelli client per Azure DevOps. Alcune funzionalità, ad esempio la scheda attività e le funzionalità basate sul team di backlog, sono completamente basate sul Web e accessibili solo tramite un portale Web, un servizio basato sul Web sul lato client. Altri utenti, ad esempio le funzionalità di controllo della versione, possono essere accessibili tramite un portale Web o tramite un'applicazione client. Le illustrazioni seguenti offrono una visualizzazione generale dei servizi Web, delle applicazioni e dei database per le distribuzioni locali di Azure DevOps Server.
Servizi a livello di raccolta
I servizi a livello di raccolta forniscono la funzionalità per le operazioni a livello di raccolta dei progetti. È possibile creare applicazioni che estendono Azure DevOps Server usando alcuni di questi servizi. Per altre informazioni sulla creazione di applicazioni per Azure DevOps Server, vedere Sviluppare estensioni.
Nota
Alcuni servizi vengono visualizzati in più di un livello. Ad esempio, il servizio Registro di sistema opera a livello di raccolta e a livello di server e viene visualizzato in entrambi gli elenchi.
Servizi framework:
- Servizio Registro di sistema
- Servizio di registrazione (per compatibilità con le versioni precedenti di Azure DevOps Server)
- Servizio proprietà
- Servizio eventi
- Servizio di sicurezza
- Posizione
- Servizio di gestione identità
- Servizio Web del controllo della versione
- Servizio Web della gestione elementi di lavoro
- Servizio Web Team Foundation Build
- Servizio Web Lab Management
- Servizio Web di amministrazione VMM
- Servizio Web controller dell'agente di test
Servizi a livello di server
I servizi a livello di server (noti anche come servizi a livello di applicazione) forniscono la funzionalità per le operazioni per Azure DevOps Server come applicazione software. È possibile creare applicazioni che estendono Azure DevOps Server usando alcuni di questi servizi.
Servizi framework:
- Servizio Registro di sistema
- Servizio eventi
- Servizio Raccolta progetti
- Servizio proprietà
- Servizio di sicurezza
- Posizione
- Servizio di gestione identità
- Servizio amministrazione
- Servizio di gestione raccolta
- Servizio catalogo
Livello dati
Nel livello dati sono inclusi dati, stored procedure e altra logica associata. Quando si usa Azure DevOps Services, il livello dati è ospitato per l'utente usando SQL Server Azure. In una distribuzione locale di Azure DevOps Server, il livello dati logico è costituito dagli archivi operativi seguenti all'interno di SQL Server. Questi archivi possono trovarsi in un server fisico o distribuiti in più server. È possibile creare applicazioni che estendono Azure DevOps Server usando alcuni di questi archivi operativi.
- Database di configurazione (TFS_Configuration)
- Warehouse applicazioni (TFS_Warehouse)
- Database di Analysis Services (TFS_Analysis)
- Database per raccolte di progetti (TFS_CollectionName)
Nella tabella seguente viene fornito un elenco dei database usati Azure DevOps Server nelle distribuzioni locali. Purché non sia diversamente specificato, è possibile spostare tutti i database in questo elenco dall'istanza e dal server originale in cui sono installati e ripristinarli in un altro server o un'altra istanza.
Nome database Descrizione Server TFS_Configuration Questo database archivia il catalogo delle risorse e le informazioni di configurazione per Azure DevOps Server. Questo database contiene gli archivi operativi per Azure DevOps Server. Istanza di SQL Server usata quando Azure DevOps Server è installato e configurato. TFS_Warehouse Questo database archivia i dati per i report. Istanza di SQL Server usata quando Azure DevOps Server è installato e configurato. TFS_Analysis Questo database multidimensionale archivia i dati aggregati dalle raccolte di progetti. Istanza di SQL Server usata quando SQL Server Analysis Services è installata e configurata. Database per raccolte di progetti Un database per ogni raccolta di progetti contenente i dati di tutti i progetti in tale raccolta. Istanza di SQL Server compatibile con Azure DevOps Server.
Livello client
Le comunicazioni tra il livello client e il livello applicazione vengono stabilite attraverso il modello a oggetti del server e da parte del livello client vengono usati gli stessi servizi Web elencati per il livello in questione. Questo vale se si distribuisce Azure DevOps Server in locale o se si usa Azure DevOps Services. Oltre a tale modello, il livello client è costituito da componenti di Visual Studio Industry Partners (VSIP), integrazione con Microsoft Office, interfacce della riga di comando e un framework per criteri di archiviazione.
Configurazione
Il servizio ospitato dipende dai servizi client, distribuiti in locale, e da una connessione Internet ai livelli applicazione e dati ospitati nel cloud. Una distribuzione locale di Azure DevOps Server dipende da SQL Server, Internet Information Services (IIS) e dal sistema operativo Windows. In base alla topologia scelta, Azure DevOps Server può dipendere anche da SQL Server Reporting Services o prodotti SharePoint. Pertanto, le informazioni di configurazione per Azure DevOps Server possono essere archiviate in una delle posizioni seguenti:
- Archivi dati di IIS.
- File di configurazione per Azure DevOps Server.
- Origini dati per Reporting Services, ad esempio dati di TFSREPORTS.
- Database di configurazione per Azure DevOps Server. Il registro di Azure DevOps Server fa parte del database di configurazione.
- Registro di sistema di Windows.
Per esempi di topologie di distribuzione locali diverse e in cui vengono archiviate queste risorse, vedere Esempi di topologia semplice, esempi di topologia moderata e esempi di topologia complessa. Man mano che si gestisce una distribuzione locale di Azure DevOps Server, è necessario prendere in considerazione queste origini di configurazione. Per modificare la configurazione in qualsiasi modalità, potrebbe essere necessario modificare le informazioni archiviate in più posizioni. Potrebbe inoltre essere necessario modificare le informazioni di configurazione per i livelli dati e client. Azure DevOps Server include una console di amministrazione e diverse utilità della riga di comando che consentono di apportare queste modifiche. Per altre informazioni, vedere Informazioni di riferimento rapido sull'attività amministrativa.
Active Directory e sincronizzazione delle identità del gruppo
Nelle distribuzioni locali in cui Azure DevOps è in esecuzione in un dominio di Active Directory, le informazioni di gruppo e identità vengono sincronizzate quando si verificano uno degli eventi seguenti:
- Viene avviato il server a livello di applicazione.
- Un gruppo di Active Directory viene aggiunto a un gruppo Azure DevOps.
Trascorre il periodo di tempo specificato nel processo pianificato. Il valore predefinito è un'ora e tutti i gruppi in Azure DevOps Server aggiornare ogni 24 ore.
I servizi di gestione di identità vengono sincronizzati con Active Directory e le identità modificate vengono propagate dal server ai client. Per impostazione predefinita, tutti i gruppi vengono aggiornati entro 24 ore. Questa impostazione, tuttavia, può essere personalizzata per meglio soddisfare le esigenze della distribuzione. Per altre informazioni, vedere Trusts and Forest considerations for Azure DevOps Server. Per le distribuzioni locali che non usano Active Directory, vedere Gestione di Azure DevOps Server in un gruppo di lavoro.
Gruppi e autorizzazioni
In una distribuzione locale, Azure DevOps Server dispone di un proprio set di gruppi e autorizzazioni predefiniti che è possibile impostare a livello di progetto, raccolta o server. È possibile creare gruppi personalizzati e personalizzare autorizzazioni a livelli singoli e di gruppo. Tuttavia, gli utenti o i gruppi aggiunti a Azure DevOps Server non vengono aggiunti automaticamente a due componenti in cui le distribuzioni locali di Azure DevOps Server possono dipendere: Prodotti SharePoint e Reporting Services. Se la distribuzione usa questi programmi, è necessario aggiungere utenti e gruppi a loro e concedere le autorizzazioni appropriate per avere tali utenti o gruppi funzionino correttamente in tutte le operazioni in Azure DevOps Server. Per altre informazioni, vedere Gestire utenti o gruppi in Azure DevOps Server.
Per le distribuzioni ospitate, l'accesso viene controllato mediante una combinazione di account Microsoft e appartenenza ai team. Per altre informazioni, vedere la panoramica Azure DevOps Services.
Porte e protocolli di rete
Per impostazione predefinita, una distribuzione locale di Azure DevOps Server è configurata per l'uso di porte e protocolli di rete specifici. Nella figura seguente viene illustrato il traffico di rete per Azure DevOps Server in una distribuzione semplice.
Analogamente, il servizio ospitato per Azure DevOps Server è configurato per usare porte e protocolli di rete specifici. Nella figura seguente viene mostrato il traffico di rete in una distribuzione ospitata.
La figura seguente illustra il traffico di rete in una distribuzione più complessa che include i componenti per Visual Studio Lab Management. Si noti che Lab Management è stato deprecato per TFS 2017 e versioni successive.
Le macchine virtuali usano la porta 80 per comunicare con qualsiasi controller di test riguardo al download di un agente di Lab Management. Se si sperimentano problemi correlati alla comunicazione, verificare che questa porta sia abilitata.
Impostazioni di rete predefinite
Per impostazione predefinita, la comunicazione tra i computer in una distribuzione di Azure DevOps usa i protocolli e le porte visualizzate nella tabella seguente. Se un asterisco (*) segue il numero di porta, è possibile personalizzare la porta.
| Livello e servizio | Protocollo | Porta |
|---|---|---|
| Livello applicazione - Servizi Web | HTTP/HTTPS | 8080/443* |
| Livello applicazione - Amministrazione prodotti SharePoint | HTTP | 17012* se SharePoint Products è stato installato con Azure DevOps Server; in caso contrario, generato in modo casuale |
| Livello applicazione - Prodotti SharePoint e Reporting Services | HTTP Servizio Strumentazione gestione Windows (WMI): necessario durante l'installazione per specificare e verificare gli URL per i servizi di rapporti |
80* Porta dinamica |
| Livello dati | TCP MS-SQL | 1433* |
| Livello dati (SQL Server Analysis Services) | MS-AS | Predefinita (2382 o 2383)* La porta predefinita varia in base alla versione di SQL Server installata e al tipo di istanza. Usare Gestione configurazione SQL Server per determinare le porte usate dalla distribuzione. |
| Server proxy di Azure DevOps - client to proxy | HTTP | 8081* |
| Server proxy di Azure DevOps - proxy al livello applicazione | HTTP/HTTPS | 8080/443* |
| Livello client - Reporting Services | HTTP | 80* |
| Livello client - Servizi Web | HTTP/HTTPS | 8080/443* |
| Compilare il controller al livello applicazione HTTP/HTTPS | 8080/443 | |
| Dall'agente di compilazione al livello applicazione | HTTP/HTTPS | 8080/443 |
| Release Management Server | HTTP o HTTPS | 1000* |
| Release Management Client | HTTP o HTTPS | 1000* |
| Release Management Agent | HTTP o HTTPS | 1000* |
| Dal controller di test al livello applicazione | HTTP/HTTPS | 8080/443* |
| Dal livello applicazione al controller di test | .NET remoto | 6901* |
| Dal livello applicazione a Domain Name System (DNS) | Aggiornamento dinamico DNS | 53 |
| Livello applicazione - Virtual Machine Manager | HTTP | 8100 |
| Dal controller di test all'agente di test | .NET remoto | 6910* |
| Dall'agente di test al controller di test | .NET remoto | 6901* |
| Dal controller di compilazione all'agente di compilazione | SOAP mediante HTTP | 9191 |
| Dall'agente lab all'agente lab in un ambiente isolato | Socket TCP | 9050 |
| Dall'agente di compilazione al controller di compilazione | SOAP mediante HTTP | 9191 |
| Console di amministrazione Virtual Machine Manager - Virtual Machine Manager | HTTP | 8100 |
| Virtual Machine Manager - Host Virtual Machine Manager | Gestione remota Windows (WinRM): per eseguire azioni Servizio trasferimento intelligente in background (BITS): per trasferire dati |
80: per eseguire azioni 443: per trasferire dati |
| Virtual Machine Manager - Server di libreria Virtual Machine Manager | WinRM: per eseguire azioni BITS: per trasferire dati |
80: per eseguire azioni 443: per trasferire dati |
| Livello applicazione - Host Virtual Machine Manager | Comunicazione Distributed Component Object Model/Strumentazione gestione Windows (DCOM/WMI): per trasferire dati | 135 Assegnata in modo dinamico nell'intervallo compreso tra 49152 e 65535. |
| Livello client - Host Virtual Machine Manager | Connessione basata su host con la macchina virtuale. | 2179 per eseguire connessioni basate su host |
| Servizi ospitati | HTTPS | 443 |
Impostazioni di rete personalizzabili
Come illustrato nella tabella precedente, è possibile modificare la comunicazione tra i livelli applicazione, dati e client nelle distribuzioni locali modificando Azure DevOps Server per usare porte personalizzate. Nella tabella seguente sono descritte le modifiche di esempio alle porte da HTTP a HTTPS.
Nota
Per configurare Azure DevOps Server per l'uso di HTTPS e Secure Sockets Layer, è necessario non solo abilitare le porte per il traffico di rete HTTPS, ma anche eseguire molte altre attività. Per altre informazioni, vedere Configurare HTTPS con Secure Sockets Layer (SSL) per Azure DevOps Server.
| Servizio | Protocollo | Porta |
|---|---|---|
| Servizi Web con SSL | HTTPS | Configurato dall'amministratore |
| HTTPS amministrazione centrale SharePoint | Configurato dall'amministratore | |
| Prodotti SharePoint | HTTPS | 443 |
| Reporting Services | HTTPS | 443 |
| Servizi Web client | HTTPS | Configurato dall'amministratore |
| Release Management | HTTPS | Configurato dall'amministratore |