Nelle grandi aziende ci sono sicuramente decine, se non centinaia, di progetti configurati all'interno di Azure DevOps. Quando si parla di incrementare (o perlomeno implementare) la sicurezza, soprattutto a livello di rete, spesso si ricorre all'integrazione di agent privati oltre a quelli hosted forniti da Microsoft stessa. Tuttavia, questi agent pool devono essere manutenuti e la complessità di manutenzione dipende dalla quantità di software e di configurazioni/versioni che devono essere disponibili.
Uno dei vantaggi dell'uso dei container, facendo un confronto con un ambiente web, ad esempio, consiste nel portarsi tutta l'infrastruttura e le dipendenze necessarie ad eseguire le applicazioni proprio all'interno del container stesso, così da non dover configurare un web server ad-hoc (la VM agent) e, ad esempio, fare hosting di applicazioni con diverse versioni di .NET installate side-by-side. La rimozione di uno dei container, inoltre, farebbe la pulizia di tutte queste dipendenze, lasciando la macchina fisica pulita e riutilizzabile per altri container/applicazioni.
Lo stesso concetto può essere quindi applicato anche per le pipeline di Azure DevOps. I container possono quindi essere deployati all'interno di un agent (sia hosted che self-hosted) e i vari task di processo possono girare all'interno di esso. Il vantaggio, come detto, è che le varie configurazioni sarebbero direttamente integrate con il container e la pipeline non deve preoccuparsi di installare software di terze parti e possiamo fare molta meno manutenzione sull'agent stesso (zero, se non abbiamo accesso come negli agent hosted).
Supponiamo, quindi, di avere N applicazioni che puntano ad N versioni diverse di .NET Core. Come detto, sul server non sarà necessario installare nulla, poichè sarà il container a servire le dipendenze necessarie all'esecuzione:

Lato pipeline, non dobbiamo fare altro che specificare su quale container eseguire la pipeline stessa:
pool: vmImage: 'ubuntu-latest' container: mcr.microsoft.com/dotnet/core/sdk:5.0 steps: - script: dotnet restore - script: dotnet build -c release
La stessa identica pipeline (quindi riutilizzando un template, potenzialmente), può girare all'interno di un altro container che punta, però, ad una versione differente di .NET 5.
L'unica difficoltà, come possiamo intuire, consiste nel trovare l'immagine ad-hoc richiesta per eseguire la pipeline. In questo caso la scelta è stata semplice poichè abbiamo bisogno di un container Linux-based, contenente l'SDK di .NET 5.
Nei prossimi script vedremo come integrare anche container di terze parti per eventuali dipendenze con servizi custom o esterni.
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Triggerare una pipeline su un altro repository di Azure DevOps
Utilizzare il metodo Index di LINQ per scorrere una lista sapendo anche l'indice dell'elemento
Gestire i dati con Azure Cosmos DB Data Explorer
Sostituire la GitHub Action di login su private registry
Migliorare i tempi di risposta di GPT tramite lo streaming endpoint in ASP.NET Core
Path addizionali per gli asset in ASP.NET Core MVC
Potenziare la ricerca su Cosmos DB con Full Text Search
Eseguire query manipolando le liste contenute in un oggetto mappato verso una colonna JSON
Ottimizzare le performance delle collection con le classi FrozenSet e FrozenDictionary
Esporre i propri servizi applicativi con Semantic Kernel e ASP.NET Web API
Creare un webhook in Azure DevOps
Applicare un filtro per recuperare alcune issue di GitHub