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
Linting di un Dockerfile con un workflow di GitHub
Configurare policy CORS in Azure Container Apps
Creazione di plugin per Tailwind CSS: espandere le Funzionalità del Framework
Usare ASP.NET Core dev tunnels per testare le applicazioni su internet
Utilizzare un service principal per accedere a Azure Container Registry
Generare token per autenicarsi sulle API di GitHub
Utilizzare Model as a Service su Microsoft Azure
Sostituire la GitHub Action di login su private registry
Creare un'applicazione React e configurare Tailwind CSS
3 metodi JavaScript che ogni applicazione web dovrebbe contenere - Parte 2
Effettuare il deploy di immagini solo da container registry approvati in Kubernetes
I più letti di oggi
- Evitare il flickering dei componenti nel prerender di Blazor 8
- Rilasciata la Beta 2 di Visual Studio 2008
- tra pochi minuti inizia la keynote della seconda giornata. seguila live su http://aspitalia.com/mix-11 #mix11
- .@dbochicchio ora su #aspnetcore 2 a #netconfit https://aspit.co/netconf-17
- Utilizzare angular-cli per creare una direttiva in Angular 2
- Windows Vista: il ritorno di WinFS con la beta1
- .@CristianCivera tra poco su #azure con i suoi tips&tricks per lo sviluppatore web: https://aspit.co/web15-live #aspilive
- Le novità di C# 10