Nello script precedente abbiamo introdotto il concetto delle pipeline che possono girare all'interno di un container. In questo modo, possiamo portare nell'agent tutte le dipendenze di terze parti che sono richieste alle pipeline stesse, senza che questo debba essere preventivamente configurato. L'agent risulterà, infatti, a tutti gli effetti pulito e riutilizzabile da qualsiasi altra pipeline.
Supponiamo però il caso in cui dobbiamo eseguire degli integration test. Questi, poichè si basano su una infrastruttura vera e propria, potrebbero avere bisogno di un database in cui salvare i dati. In uno scenario simile, possiamo sfruttare il concetto di service container per caricare un container di servizio side-by-side a quello in cui verrà eseguita la pipeline.
pool: vmImage: 'ubuntu-latest' container: mcr.microsoft.com/dotnet/core/sdk:5.0 resources: containers: - container: sql image: mssql/server:2019-latest options: 'ACCEPT_EULA=Y SA_PASSWORD=yourStrong(!)Password' services: sql: sql steps: - script: dotnet restore - script: dotnet build -c release env: CONNECTIONSTRING: sql:1433
La pipeline è molto simile a quella che abbiamo visto la volta scorsa. Tuttavia, in questo caso facciamo uso del nodo resources per includere un ulteriore container (o una lista di essi) alla pipeline. Quando il processo verrà messo in esecuzione, verrà fatto il pull sia del container principale, ovvero di quello contenente l'SDK di .NET 5, sia del container di servizio contenente SQL Server 2019 (la cui configurazione può variare).
Grazie al nodo di services "esponiamo" effettivamente il container per fare in modo che questo sia "visibile" alla pipeline e utilizzabile da uno dei task contenenti nel job in esecuzione. Non solo, grazie al service possiamo creare un alias che identificherà in maniera univoca il container in esecuzione e che potrà essere utilizzato in seguito nella pipeline. In questo caso, il container è stato referenziato semplicemente passando il suo alias e la porta (di default sulla 1433 ma è personalizzabile tramite l'attributo port specificabile nel nodo container) come input di una variabile d'ambiente chiamata CONNECTIONSTRING. Questa variabile di per sè non significa nulla: è di fatto l'applicazione stessa che dovrà andare a leggere e recuperare il valore della variabile d'ambiente creata ed esposta dalla pipeline per fare in modo che possa salvare delle informazioni all'interno del SQL Server eseguito in container.
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
Creare una custom property in GitHub
Usare i servizi di Azure OpenAI e ChatGPT in ASP.NET Core con Semantic Kernel
Generare la software bill of material (SBOM) in GitHub
Code scanning e advanced security con Azure DevOps
Eseguire i worklow di GitHub su runner potenziati
Ordinare randomicamente una lista in C#
Come migrare da una form non tipizzata a una form tipizzata in Angular
Cancellare una run di un workflow di GitHub
Garantire la provenienza e l'integrità degli artefatti prodotti su GitHub
Generare velocemente pagine CRUD in Blazor con QuickGrid