Usa Azure Cosmos DB come un contenitore Docker nelle pipeline CI/CD

Ci sono molti vantaggi nell’utilizzare i container Docker nelle pipeline CI/CD, specialmente per sistemi con stato come i database. Ad esempio, quando si eseguono test di integrazione, ogni job CI può avviare il database in un container isolato con uno stato pulito, prevenendo conflitti tra i test. Ciò porta a un ambiente di testing affidabile, coerente ed economico. Questo approccio riduce anche la latenza e migliora le prestazioni complessive della pipeline CI/CD perché il database è accessibile localmente.

Il emulatore Azure Cosmos DB basato su Linux è disponibile come container Docker e può essere eseguito su una varietà di piattaforme, inclusi architettura ARM64 come Apple Silicon. Consente lo sviluppo e il testing locali di applicazioni senza necessità di una sottoscrizione Azure o di costi di servizio. È possibile eseguirlo facilmente come container Docker e usarlo per lo sviluppo e il testing locali:

docker pull mcr.microsoft.com/cosmosdb/linux/azure-cosmos-emulator:vnext-preview

Azure Cosmos DB Con Azioni GitHub

Facciamo un esempio per capire meglio come utilizzare l’emulatore di Azure Cosmos DB con GitHub Actions, che è una piattaforma di integrazione continua e distribuzione continua (CI/CD) che ti consente di automatizzare la pipeline di build, test e distribuzione utilizzando i workflow. Un workflow è un processo automatizzato configurabile che può eseguire uno o più job. Viene definito da un file YAML inserito nel tuo repository e viene eseguito quando viene attivato da un evento nel tuo repository, o può essere attivato manualmente o in base a un programma definito.

Esempio: Workflow CI per un’applicazione .NET

Questo workflow di GitHub Actions configura l’emulatore di Azure Cosmos DB basato su Linux come un container del servizio GitHub actions come parte di un job. GitHub si occupa di avviare il container Docker e lo elimina quando il job è completato, non è richiesta alcuna intervento manuale (come l’esecuzione del comando docker run).

name: .NET App CI

on:
  push:
    branches: [main]
    paths:
      - 'dotnet-app/**'
  pull_request:
    branches: [main]
    paths:
      - 'dotnet-app/**'

jobs:
  build-and-test:
    runs-on: ${{ matrix.os }}

    strategy:
      matrix:
        os: [ubuntu-latest, ubuntu-24.04-arm]

    services:
      cosmosdb:
        image: mcr.microsoft.com/cosmosdb/linux/azure-cosmos-emulator:vnext-preview
        ports:
          - 8081:8081
        env:
          PROTOCOL: https

    env:
      COSMOSDB_CONNECTION_STRING: ${{ secrets.COSMOSDB_CONNECTION_STRING }}
      COSMOSDB_DATABASE_NAME: ${{ vars.COSMOSDB_DATABASE_NAME }}
      COSMOSDB_CONTAINER_NAME: ${{ vars.COSMOSDB_CONTAINER_NAME }}

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Set up .NET
        uses: actions/setup-dotnet@v3
        with:
          dotnet-version: '8.0.x'

      - name: Export Cosmos DB Emulator Certificate
        run: |
          sudo apt update && sudo apt install -y openssl
          openssl s_client -connect localhost:8081 </dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > cosmos_emulator.cert

          sudo cp cosmos_emulator.cert /usr/local/share/ca-certificates/
          sudo update-ca-certificates

      - name: Install dependencies
        run: cd dotnet-app && dotnet restore

      - name: Build
        run: cd dotnet-app && dotnet build --no-restore

      - name: Run tests
        run: cd dotnet-app && dotnet test --no-build --verbosity normal

Questo lavoro è configurato per essere eseguito su un runner Ubuntu e utilizza l’immagine docker mcr.microsoft.com/cosmosdb/linux/azure-cosmos-emulator:vnext-preview come container di servizio. La stringa di connessione, il nome del database e il nome del contenitore sono configurati come variabili d’ambiente. Poiché il lavoro viene eseguito direttamente su un runner ospitato da GitHub Actions, il passaggio “Esegui test” può accedere all’emulatore utilizzando localhost:8081.

Il passaggio Esporta Certificato Emulatore di Cosmos DB è specifico per le applicazioni .NET (nonché Java) poiché al momento della stesura, le SDK .NET e Java non supportano la modalità HTTP nell’emulatore. La variabile d’ambiente PROTOCOL è impostata su https nella sezione services e questo passaggio esporta il certificato dell’emulatore e li aggiunge allo store di certificati fidati del sistema operativo.

Provalo!

Questo repository GitHub fornisce esempi su come configurare l’emulatore Linux come parte di un flusso di lavoro CI di GitHub Actions per applicazioni .NET, Python, Java e Go su entrambe le architetture x64 e ARM64 (dimostrato per runner Linux utilizzando Ubuntu).

Clona il repository

Naviga nel repository GitHub e clicca sul pulsante Fork nell’angolo in alto a destra della pagina del repository per creare una copia del repository nel tuo account GitHub.

Nel tuo account GitHub, apri il repository e assicurati di abilitare i flussi di lavoro (workflows) nelle impostazioni del repository.

Aggiungi la stringa di connessione dell’emulatore Cosmos DB (COSMOSDB_CONNECTION_STRING) come segreto del repository. Utilizza il seguente valore:

AccountEndpoint=http://localhost:8081/;AccountKey=C2y6yDjf5/R+ob0N8A7Cgv30VRDJIWEHLM+4QDU5DE2nQ9nDuVTqobD4b8mGGyPMbIZnqyMsEcaGQy67XIw/Jw==

Aggiungi il nome del database (COSMOSDB_DATABASE_NAME) e il nome del contenitore (COSMOSDB_CONTAINER_NAME) come variabili del repository:

Clona il repository forchettato sulla tua macchina locale (assicurati di utilizzare il tuo nome utente GitHub):

git clone https://github.com/<your-username>/cosmosdb-linux-emulator-github-actions.git

cd cosmosdb-linux-emulator-github-actions

Attiva il Flusso di Lavoro

Per attivare il flusso di lavoro, apporta una piccola modifica a parte o a tutto il codice (.NET, Java, Python o Go), aggiungi e committa le tue modifiche. Per una maggiore chiarezza, sono utilizzati flussi di lavoro separati per ciascun linguaggio.

Esegui il push delle tue modifiche nel tuo repository forkato su GitHub:

git add . 
git commit -m "Your commit message" 
git push origin main

Dopo aver effettuato il push delle modifiche, GitHub Actions eseguirà automaticamente il workflow. Vai alla scheda “Actions” nel tuo repository per vedere lo stato e i risultati dei workflow. Controlla eventuali log o output per assicurarti che i workflow si stiano eseguendo correttamente.

Considerazioni sul GitHub Actions Runner

Il repository di esempio ha mostrato l’utilizzo di runner basati su ubuntu (per architetture x64 e ARM64). Questo dovrebbe funzionare anche per i runner basati su Windows ARM. Se stai considerando runner Windows x64, tieni presente che al momento della stesura di questo testo, i contenitori di servizio di GitHub Actions non sono supportati nei runner non Linux. Tuttavia, puoi aggirare il problema aggiungendo passaggi per installare Docker e gestirne il ciclo di vita, inclusi l’avvio e l’arresto del contenitore.

Conclusione

Come accennato in precedenza, ci sono molti vantaggi nell’utilizzare i container Docker nei flussi di lavoro di CI. GitHub Actions è stato utilizzato come piattaforma CI/CD in questo caso, ma questi concetti si applicano anche ad altre soluzioni. Prova e facci sapere cosa ne pensi!