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
Le novità di Entity Framework (Core) 7
Test reporting in un workflow di GitHub
Caricare un asset come parte di una release con un workflow di GitHub
Leggere e scrivere su cookie tramite Blazor
Trasformare qualsiasi backend in un servizio GraphQL con Azure API Management
Utilizzare il metodo reduce in JavaScript
Sviluppo applicazioni x-plat con .NET MAUI
Migrare un repository che contiene large file storage objects in GitHub
Dependency Injection e custom validator in Blazor con .NET 7.0
Velocizzare l'installazione delle dipendenze in un workflow di GitHub
Gestire i file esterni in una PWA
Pubblicare un pacchetto di NuGet nel feed di GitHub
I più letti di oggi
- Filtrare e rimuovere gli elementi dalla cache del browser tramite le API JavaScript
- Utilizzare HiLo per ottimizzare le insert in un database con Entity Framework
- Effettuare il deploy di immagini solo da container registry approvati in Kubernetes
- Ottenere il contenuto di una cartella FTP con la libreria FluentFTP
- Elencare le container images installate in un cluster di Kubernetes
- Recuperare un elemento inserito nella cache del browser tramite API JavaScript
- Controllare gli accessi IP alle app con Azure Container Apps
- Utilizzare le Cache API di JavaScript per salvare elementi nella cache del browser
- Determinare lo stato di un pod in Kubernetes
- .NET Conference Italia 2022 - Milano e Online