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
AWS, EKS e Fluent Bit
Leggere i dati di configurazione di ASP.NET Core da Azure Key Vault
Utilizzo di Set e Array in JavaScript
Determinare lo stato di un pod in Kubernetes
Migrare un repository git da Azure DevOps a GitHub
Effettuare il deploy di immagini solo da container registry approvati in Kubernetes
ChatOps con GitHub
Utilizzare l'API del browser fetch
Sfruttare la local cache del browser tramite gli ETag in ASP.NET Core
Pubblicare la documentazione di un repository con GitHub Pages
GitHub <3 .NET
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