Una guida passo passo alla distribuzione di contenitori Docker con azioni GitHub
introduzione
La creazione e la distribuzione manuale di risorse in Azure e in altri provider cloud è relativamente semplice e, in alcuni casi, può essere sufficiente. Tuttavia, nella maggior parte dei casi, le risorse distribuite dovranno cambiare nel tempo, il che a sua volta richiede molto lavoro aggiuntivo per la manutenzione e la ridistribuzione delle risorse. Per automatizzare queste attività, sviluppatori e professionisti dei dati possono invece utilizzare un approccio Infrastructure-as-Code (IaC) e creare pipeline per l’integrazione e la distribuzione continue (CI/CD). Questo approccio consente agli sviluppatori di scrivere codice che definisce e ridistribuisce automaticamente le risorse ogni volta che vengono apportate modifiche.
In questa guida passo passo creeremo pipeline per un’applicazione di elaborazione dati per eseguire le seguenti attività:
- Effettua il provisioning di un registro contenitori
- creare e inviare un’immagine Docker al registro
- creare un’istanza di contenitore che esegua il carico di lavoro di elaborazione dei dati
- abilitare l’accesso con “identità gestita” ad Azure Key Vault, che consente alla nostra applicazione di recuperare le chiavi di accesso ad altre risorse come gli account di archiviazione
- distribuire le risorse di cui sopra in un ambiente di test e di produzione utilizzando trigger diversi per l’esecuzione delle pipeline
Iniziare
A scopo dimostrativo, l’applicazione stessa è costituita da uno script R molto semplice che carica un set di dati, stampa le prime righe e restituisce il set di dati a un account di archiviazione. Tieni presente che il codice dell’applicazione non è importante per il resto della pipeline e può essere facilmente sostituito dal tuo codice.
Per iniziare avrai bisogno di un account Azure. Potresti anche volerlo installare l’interfaccia della riga di comando di Azure sul tuo sistema locale. Tuttavia, puoi anche scegliere di eseguire i comandi dell’interfaccia della riga di comando di Azure tramite Cloud Shell disponibile nel portale di Azure.
Poiché la nostra applicazione trasferisce i dati da e verso Archiviazione BLOB di Azure e li restituisce, potresti trovare utile installare Azure Storage Explorer, che rende un po’ più semplice caricare i file e verificare che l’applicazione funzioni correttamente e restituisca i dati elaborati.
Passaggio 1: clonazione del repository e configurazione delle risorse statiche.
Per prima cosa dovrai clonare questo repository. Il file README descrive in dettaglio come eseguire questa operazione utilizzando RStudio, ma sei libero di utilizzare il tuo IDE preferito.
Successivamente, utilizzando il portale di Azure, creare le seguenti risorse:
- un gruppo di risorse che conterrà tutte le altre risorse.
- un account di archiviazione con un contenitore BLOB con due cartelle: una per i file di input e un’altra per i file di output. Nel nostro caso, questi dovrebbero essere denominati rispettivamente “input” e “output”. Archivia un piccolo set di dati come file CSV denominato “input_data.csv” all’interno del contenitore di input.
- un insieme di credenziali delle chiavi in cui sarà necessario archiviare come segreto la chiave di accesso primaria all’account di archiviazione.
Nel passaggio 3 sarà necessario il nome dell’insieme di credenziali delle chiavi e il nome del segreto contenente la chiave di accesso primaria.
Passaggio 2: collegamento di GitHub ad Azure
Per aggiornare le risorse di Azure, dobbiamo concedere l’autorizzazione a GitHub per farlo.
Innanzitutto, accedi al tuo account Azure utilizzando l’interfaccia della riga di comando di Azure.
az login
Quindi copia il id valore dall’output JSON, che è l’ID di sottoscrizione. Incolla l’ID dell’abbonamento nel comando seguente ed eseguilo. Viene creata un’entità servizio con controllo degli accessi basato sui ruoli, che può essere considerata come un utente che agisce per tuo conto durante la distribuzione o l’aggiornamento delle risorse con un flusso di lavoro di GitHub Actions.
az ad sp create-for-rbac \
--name "your-app-name" \
--role Owner \
--scopes /subscriptions/<your-subscription-id>/resourceGroups/<your-resource-group-name> \
--sdk-auth
Copia l’intero output JSON e vai al repository GitHub e fai clic su Impostazioni > Segreti e variabili > Azioni.
Creare un nuovo segreto del repository e denominarlo AZURE_CREDENTIALS. Incolla l’output JSON dal comando precedente e salva.
Passaggio 3: modifica degli script
In questo scenario, stiamo distribuendo un semplice script R che non fa molto. Pertanto, anche il Dockerfile è mantenuto molto semplice. Entrambi questi file dovranno ovviamente essere modificati in base alle vostre esigenze e al linguaggio di programmazione preferito. Tuttavia, se sei nuovo a questo, potrebbe essere utile rendere operativa la tua pipeline con il codice così com’è prima di applicare il tuo codice.
Se si sceglie di procedere con lo script R corrente (script.R), sarà necessario solo modificare i valori {keyvault-name} , {access-key-name} E {storage-account-name} (omettendo le parentesi).
Successivamente, modifica i seguenti valori in env: nei due file del flusso di lavoro chiamati flusso di lavoro.yml E flusso di lavoro_release_prod.yml nel .github/workflows/ rubrica:
env:
RESOURCEGROUP_NAME: my-rg
REGISTRY_NAME: my-cr
SHORT_NAME: mycr
ACI_NAME: my-ci-test
KV_NAME: my-kv
ENVIRONMENT: test
CPU: 1
MEMORY: 1.5
Passaggio 4: esecuzione della pipeline e dell’istanza del contenitore
Una volta apportate e inviate tutte le modifiche rilevanti al ramo “principale”, dovresti vedere la pipeline in esecuzione nel riquadro Azioni. Questo perché il flusso di lavoro è configurato con un trigger di ramo in modo che venga eseguito quando viene aggiornato il ramo principale.
Se non riscontri errori, l’istanza del contenitore dovrebbe essere pronta per l’esecuzione in circa dieci minuti. Vai al portale di Azure, trova la nuova istanza del contenitore e fai clic su Avvia. Nel riquadro Log, potresti vedere lo script in esecuzione nella console. Dopo il completamento, verifica che sia stato chiamato un nuovo file cv dati_output.csv è arrivato nella cartella “output” del contenitore BLOB.
E questo è tutto! Se lo desideri, ora puoi attivare manualmente il secondo flusso di lavoro che crea un’istanza di contenitore identica destinata ai carichi di lavoro di produzione.
Per comprendere cosa accade nella pipeline CI/CD, leggere la sezione seguente.
Fonte: towardsdatascience.com
