Flussi di lavoro CI/CD senza soluzione di continuità con GitHub Actions su GCP i tuoi strumenti per un’efficace MLOps.

Seamless CI/CD workflows with GitHub Actions on GCP are your tools for effective MLOps.

IL FRAMEWORK MLOPS A 7 PASSI PER IL FULL STACK

Lezione 7: Distribuire tutti i componenti di ML su GCP. Costruisci una pipeline CI/CD utilizzando le azioni di GitHub.

Questo tutorial rappresenta la lezione 7 di un corso di 7 lezioni che ti guiderà passo dopo passo su come progettare, implementare e distribuire un sistema di ML utilizzando le buone pratiche di MLOps. Durante il corso, costruirai un modello pronto per la produzione per prevedere i livelli di consumo energetico per le prossime 24 ore in diversi tipi di consumatori della Danimarca.

Alla fine di questo corso, comprenderai tutti i fondamenti della progettazione, della codifica e della distribuzione di un sistema di ML utilizzando un’architettura batch-serving.

Questo corso si rivolge a ingegneri di machine learning di livello medio/avanzato che vogliono migliorare le proprie competenze costruendo i propri progetti end-to-end.

Oggi, i certificati sono ovunque. La costruzione di progetti avanzati end-to-end che poi puoi mostrare è il miglior modo per ottenere riconoscimento come ingegnere professionista.

• Problema del gradiente spariente cause, conseguenze e soluzioni
• Classificazione e Localizzazione di Diverse Forme di Molestie Sessuali
• Ricerca di similarità, Parte 2 Quantizzazione di prodotto

Indice:

• Introduzione al corso
• Lezioni del corso
• Fonte dei dati
• Lezione 7: Distribuire tutti i componenti di ML su GCP. Costruisci una pipeline CI/CD utilizzando le azioni di GitHub.
• Lezione 7: Codice
• Conclusione
• Riferimenti

Introduzione al corso

Alla fine di questo corso di 7 lezioni, saprai come:

• progettare un’architettura batch-serving
• usare Hopsworks come feature store
• progettare una pipeline di ingegneria delle feature che legge i dati da un’API
• costruire una pipeline di addestramento con sintonizzazione degli iperparametri
• usare W&B come piattaforma di ML per tracciare i tuoi esperimenti, modelli e metadati
• implementare una pipeline di previsione batch
• usare Poetry per creare i tuoi pacchetti Python
• distribuire il tuo server privato PyPi
• orchestrare tutto con Airflow
• usare le previsioni per scrivere un’app Web utilizzando FastAPI e Streamlit
• usare Docker per containerizzare il tuo codice
• usare Great Expectations per garantire la validazione e l’integrità dei dati
• monitorare le prestazioni delle previsioni nel tempo
• distribuire tutto su GCP
• costruire una pipeline CI/CD utilizzando le azioni di GitHub

Se sembra molto, non preoccuparti. Dopo aver coperto questo corso, capirai tutto quello che ho detto prima. Ma soprattutto, saprai PERCHÉ ho usato tutti questi strumenti e come funzionano insieme come un sistema.

Se vuoi ottenere il massimo da questo corso, ti suggerisco di accedere al repository GitHub che contiene tutto il codice delle lezioni. Questo corso è progettato per leggere rapidamente e replicare il codice insieme agli articoli.

Alla fine del corso, saprai come implementare il diagramma qui sotto. Non preoccuparti se qualcosa non ti è chiaro. Spiegherò tutto in dettaglio.

Alla fine della lezione 7, saprai come distribuire manualmente le 3 pipeline di ML e l’app Web su GCP. Inoltre, costruirai una pipeline CI/CD che automatizzerà il processo di distribuzione utilizzando le azioni di GitHub.

Lezioni del corso:

1. Batch serving. Feature stores. Feature engineering pipelines.
2. Training pipelines. Piattaforme di ML. Sintonizzazione degli iperparametri.
3. Pipeline di previsione batch. Pacchetti Python con Poetry.
4. Server privato PyPi. Orchestrazione di tutto con Airflow.
5. Convalida dei dati per la qualità e l’integrità utilizzando GE. Monitoraggio continuo delle prestazioni del modello.
6. Consuma e visualizza le previsioni del tuo modello utilizzando FastAPI e Streamlit. Containerizza tutto con Docker.
7. Distribuire tutti i componenti di ML su GCP. Costruisci una pipeline CI/CD utilizzando le azioni di GitHub.

Essendo la Lezione 7 incentrata sull’insegnamento di come distribuire tutti i componenti su GCP e costruire attorno ad essi una pipeline CI/CD, per un’esperienza completa, ti consigliamo di guardare le altre lezioni del corso.

Guarda la Lezione 4 per imparare come orchestrare le 3 pipeline ML utilizzando Airflow e la Lezione 6 per vedere come consumare le previsioni del modello usando FastAPI e Streamlit.

Fonte dati

Abbiamo utilizzato un’API gratuita e aperta che fornisce valori di consumo energetico orario per tutti i tipi di consumatori energetici in Danimarca [1].

Forniscono un’interfaccia intuitiva in cui è possibile interrogare e visualizzare i dati. È possibile accedere ai dati qui [1].

I dati hanno 4 attributi principali:

• Ora UTC: la data e l’ora UTC in cui è stato osservato il punto dati.
• Area prezzo: la Danimarca è divisa in due aree di prezzo: DK1 e DK2 – divise dal Grande Belt. DK1 si trova a ovest del Grande Belt e DK2 a est del Grande Belt.
• Tipo di consumatore: Il tipo di consumatore è il codice di settore DE35, di proprietà e mantenuto da Danish Energy.
• Consumo totale: Consumo totale di elettricità in kWh.

Nota: Le osservazioni hanno un ritardo di 15 giorni! Ma per il nostro caso d’uso dimostrativo, non è un problema, poiché possiamo simulare gli stessi passaggi come se fosse in tempo reale.

I punti dati hanno una risoluzione oraria. Ad esempio: “2023-04-15 21:00Z”, “2023-04-15 20:00Z”, “2023-04-15 19:00Z”, ecc.

Modelleremo i dati come serie temporali multiple. Ogni tupla unica di area prezzo e tipo di consumatore rappresenta la sua serie temporale unica.

Quindi, costruiremo un modello che prevede in modo indipendente il consumo di energia per le prossime 24 ore per ogni serie temporale.

Guarda il video qui sotto per capire meglio come sono fatti i dati 👇

Panoramica del corso e della fonte dati [Video dell’autore].

Lezione 7: Distribuisci tutti i componenti ML su GCP. Costruisci una pipeline CI/CD utilizzando Github Actions.

L’obiettivo della Lezione 7

Nella Lezione 7, ti insegnerò 2 cose:

1. Come distribuire manualmente le 3 pipeline ML e l’app Web su GCP.
2. Come automatizzare il processo di distribuzione con una pipeline CI/CD utilizzando GitHub Actions.

In altre parole, prenderai tutto ciò che hai fatto finora e lo mostrerai al mondo.

Fintanto che il tuo lavoro è sul tuo computer, può essere la migliore soluzione ML al mondo, ma purtroppo non aggiungerà alcun valore.

Sapere come distribuire il tuo codice è fondamentale per qualsiasi progetto.

Quindi ricorda…

Useremo GCP come fornitore di cloud e GitHub Actions come strumento CI/CD.

Concetti teorici e strumenti

CI/CD: CI/CD significa integrazione continua e distribuzione continua.

La fase CI consiste principalmente nella costruzione e nella verifica del codice ogni volta che si effettua un push su git.

La fase CD distribuisce automaticamente il codice su più ambienti: dev, staging e produzione.

A seconda delle specifiche esigenze del software, potrebbe essere necessario o meno avere tutte le specifiche di una pipeline CI/CD standard.

Ad esempio, si potrebbe lavorare su una prova di concetto. In questo caso, un ambiente di staging potrebbe essere eccessivo. Tuttavia, avere una pipeline CD per l’ambiente di sviluppo e di produzione migliorerà notevolmente la produttività.

GitHub Actions: GitHub Actions è uno dei tool CI/CD più popolari al mondo. È direttamente integrato nel repository GitHub. La cosa fantastica è che non è necessario alcun VM per eseguire la pipeline CI/CD. Tutto viene eseguito sui computer di GitHub.

È necessario specificare un insieme di regole all’interno di un file YAML, e GitHub Actions si occuperà del resto. In questo articolo ti mostrerò come funziona.

GitHub Actions è completamente gratuito per i repository pubblici. Non è fantastico?

Come nota laterale, utilizzando GitHub Actions è possibile attivare qualsiasi job basato su vari eventi del repository, ma l’utilizzo come strumento CI/CD è il caso d’uso più comune.

Lezione 7: Codice

È possibile accedere al repository GitHub qui.

Nota: tutte le istruzioni di installazione sono nei README del repository. Qui si salta direttamente al codice.

Il codice e le istruzioni per la Lezione 7 si trovano sotto i seguenti:

• deploy/ — Docker e file di distribuzione shell
• .github/workflows — Flussi di lavoro GitHub Actions CI/CD
• README_DEPLOY — README dedicato alla distribuzione del codice su GCP
• README_CICD — README dedicato alla configurazione della pipeline CI/CD

Preparare le credenziali

Memorizzare direttamente le credenziali nel repository git rappresenta un enorme rischio per la sicurezza. Ecco perché si inietta informazioni sensibili utilizzando un file .env.

Il file .env.default è un esempio di tutte le variabili che devono essere configurate. È utile anche per memorizzare i valori predefiniti per gli attributi non sensibili (ad esempio, il nome del progetto).

Per replicare questo articolo, è necessario configurare tutta l’infrastruttura e i servizi utilizzati durante il corso.

Possono essere distribuiti separatamente due componenti principali.

#1. I 3 pipeline di ML:

• Pipeline delle caratteristiche
• Pipeline di formazione
• Pipeline di previsione batch

Per #1., è necessario configurare quanto segue:

• Hopsworks (gratuito) — Feature Store: Lezione 1
• W&B (gratuito) — Piattaforma ML: Lezione 2
• GCS buckets (gratuito) — Archiviazione su GCP: Lezione 3
• Airflow (gratuito) — Strumento di orchestrazione open source: Lezione 4

#2. App Web:

• Backend FastAPI (gratuito): Lezione 6
• Dashboard di previsione Streamlit (gratuito): Lezione 6
• Dashboard di monitoraggio Streamlit (gratuito): Lezione 6

Felizmente, per #2., è necessario configurare solo i bucket GCP GCS utilizzati come archiviazione.

Tuttavia, si noti che se si esegue solo la sezione #2., non si avranno dati da utilizzare nell’app Web.

Non vogliamo sovraccaricare questo articolo con argomenti noiosi, come la configurazione delle credenziali. Tuttavia, se si vuole implementare e replicare l’intero corso, si hanno istruzioni dettagliate nei precedenti articoli e nel README di GitHub.

Se si vuole vedere (e non replicare) come abbiamo distribuito il nostro codice su GCP e creato i flussi di lavoro di GitHub Actions, non è necessario preoccuparsi di alcuna delle credenziali. Basta procedere alle sezioni successive ✌️

NOTA: L’unico servizio che non ha un piano freemium si trova in questa lezione. Quando ho scritto questo corso, il costo del rilascio e del test dell’infrastruttura su GCP è stato di circa 20 $. Ma avevo un nuovo account GCP che mi ha offerto 300 $ di crediti GCP, rendendolo quindi indirettamente gratuito. Ricorda solo di eliminare tutte le risorse GCP quando hai finito e andrà tutto bene.

Rilascio manuale su GCP

Quindi, rilasciamo manualmente i 2 componenti principali su GCP:

• ML Pipeline
• Web App

Ma, come primo passo, impostiamo tutte le risorse GCP necessarie per il rilascio. Dopo, ti connetterai tramite SSH alle tue macchine e rilascerai il tuo codice.

Per maggiori informazioni, accedi al file README di rilascio di GitHub.

Imposta le risorse

Andiamo al tuo progetto energy_consumption di GCP e crea le seguenti risorse:

1. Account di servizio VM Admin con accesso IAP
2. Regola del firewall delle porte esposte
3. IAP per la regola del firewall di tunneling TCP
4. VM per il Pipeline
5. VM per la Web App
6. IP statico esterno

Non scoraggiarti dai nomi complicati. Avrai accesso a guide passo-passo utilizzando questo articolo + la documentazione GCP che fornirò.

Nota: Se non hai intenzione di replicare l’infrastruttura sulla tua infrastruttura GCP, salta la sezione “Imposta le risorse” e vai direttamente a “Rilascia l’ML Pipeline“.

#1. Account di servizio VM Admin con accesso IAP

Ai servizi GCP abbiamo bisogno di un nuovo account con diritti di amministratore e accesso IAP alle VM GCP.

Dovrai creare un nuovo account di servizio e assegnargli i seguenti ruoli:

• Amministratore dell’istanza di calcolo (v1)
• Utente del tunnel IAP-protetto
• Creatore di token per l’account di servizio
• Utente dell’account di servizio

IAP sta per Proxy basato sull’identità. È un modo per creare tunnel che instradano il traffico TCP all’interno della tua rete privata. Per la tua conoscenza, puoi leggere di più su questo argomento utilizzando i seguenti documenti (non devi capirlo per procedere ai passaggi successivi):

• Utilizzo di IAP per l’inoltro TCP [2]
• Panoramica dell’inoltro TCP [3]

#2. Regola del firewall delle porte esposte

Crea una regola del firewall che espone le seguenti porte TCP: 8501, 8502 e 8001.

Inoltre, aggiungi un tag di destinazione chiamato energy-forecasting-expose-ports.

Ecco 2 documenti che ci hanno aiutato a creare e configurare le porte per la regola del firewall:

• Come aprire una porta specifica come la 9090 in Google Compute Engine [4]
• Come aprire le porte del firewall su un’istanza GCP Compute Engine [5]

Ecco come appare la nostra regola del firewall 👇

#3. IAP per la regola del firewall di tunneling TCP

Ora creeremo una regola del firewall che consente l’IAP per il tunneling TCP su tutte le VM connesse alla rete predefinita.

Guida passo-passo su come creare la regola del firewall IAP per il tunneling TCP [6].

Ecco come appare la nostra regola del firewall 👇

#4. VM per il Pipeline

Vai al tuo progetto GCP energy_consumption -> VM Instances -> Crea istanza.

Scegli e2-standard-2: 2 core vCPU — 8 GB RAM come tipo di istanza VM.

Chiamalo: ml-pipeline

Cambia il disco a 20 GB Storage .

Scegli la regione europa-ovest3 (Francoforte) ` e la zona europa-ovest3-c. Qui, puoi scegliere qualsiasi altra regione & zona, ma se è la prima volta che lo fai, ti consigliamo di farlo come noi.

Rete: default

Inoltre, controlla le caselle HTTP e HTTPS e aggiungi la regola firewall personalizzata energy-forecasting-expose-ports che abbiamo creato qualche passaggio fa.

Ecco 2 documenti che mi hanno aiutato a creare e configurare le porte per la regola firewall:

• Come aprire una porta specifica come 9090 in Google Compute Engine [4]
• Come aprire le porte del firewall su un’istanza GCP Compute Engine [5]

#5. VM per l’App Web

Ora ripetiamo un processo simile per la VM dell’App Web, ma con impostazioni leggermente diverse.

Questa volta scegli e2-micro: 0.25 2 core vCPU — 1 GB RAM come tipo di istanza VM.

Chiamalo: app

Cambia il disco a 15 GB standard persisted disk

Scegli la regione europa-ovest3 (Francoforte) e la zona europa-ovest3-c.

Rete: default

Inoltre, controlla le caselle HTTP e HTTPS e aggiungi la regola firewall personalizzata energy-forecasting-expose-ports che abbiamo creato qualche passaggio fa.

#6. Indirizzo IP statico esterno

Questo è l’ultimo pezzo del puzzle.

Se vogliamo che l’IP esterno per la nostra app web sia statico (ovvero che non cambi), dobbiamo allegare un indirizzo statico alla nostra VM dell’App Web.

Suggeriamo di aggiungerlo solo alla VM dell’app che abbiamo creato qualche passaggio fa.

Inoltre, aggiungere un IP esterno statico alla VM ml-pipeline va benissimo.

Documenti sulla riservazione di un indirizzo IP esterno statico [7].

Ora che la parte noiosa è finita, iniziamo a distribuire il codice 👇

Distribuisci il Pipeline di ML

Come primo passo, dobbiamo installare lo strumento CLI gcloud GCP per comunicare tra il nostro computer e le VM GCP.

Per autenticarci, useremo l’account di servizio configurato con i diritti di amministratore per le VM e l’accesso IAP a SSH.

Ora dobbiamo dire al CLI gcloud GCP di utilizzare quell’account di servizio.

Per farlo, devi creare una chiave per il tuo account di servizio e scaricarla come file JSON. Come hai fatto per gli account di servizio dei bucket – ecco alcuni documenti per rinfrescarti la memoria [8].

Dopo aver scaricato il file, devi eseguire il seguente comando gcloud nel tuo terminale:

gcloud auth activate-service-account [email protected] - key-file=/path/key.json - project=PROJECT_ID

Controlla questo documento per maggiori dettagli sul comando gcloud auth .

Ora ogni volta che esegui comandi con gcloud , utilizzerà questo account di servizio per l’autenticazione.

Ora connettiamoci tramite SSH alla VM GCP ml-pipeline che hai creato qualche passaggio fa:

gcloud compute ssh ml-pipeline - zone europe-west3-c - quiet - tunnel-through-iap - project <your-project-id>

• NOTA 1: Modifica la zona se non hai creato una VM nella stessa zona come noi.
• NOTA 2: Il tuo project-id NON è il nome del tuo progetto . Vai alla lista dei tuoi progetti GCP e trova l’id del progetto.

A partire da questo punto, se hai configurato correttamente i firewall e l’account di servizio, poiché tutto è Dockerizzato, tutti i passaggi saranno al 99% simili a quelli degli altri articoli.

Controlla il README di Github – Set Up Additional Tools e Usage per le istruzioni passo passo.

Puoi seguire gli stessi passaggi mentre sei connesso con SSH alla macchina GCP ml-pipeline.

Nota che la macchina GCP utilizza Linux come sistema operativo. Pertanto, puoi copiare e incollare direttamente i comandi dal README indipendentemente dal sistema operativo che usi sul tuo dispositivo locale.

È possibile ripetere in tutta sicurezza tutti i passaggi eseguiti configurando il The Pipeline in locale utilizzando questa connessione SSH, ma è necessario tenere a mente i seguenti 3 casi limite:

#1. Clonare il codice nella directory home della VM

Basta connettersi tramite SSH alla VM e eseguire:

git clone https://github.com/iusztinpaul/energy-forecasting.gitcd energy-forecasting

#2. Installare Docker utilizzando i seguenti comandi:

Installare Docker:

sudo apt updatesudo apt install --yes apt-transport-https ca-certificates curl gnupg2 software-properties-commoncurl -fsSL https://download.docker.com/linux/debian/gpg | sudo apt-key add -sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/debian $(lsb_release -cs) stable"sudo apt updatesudo apt install --yes docker-ce

Aggiungere l’accesso sudo a Docker:

sudo usermod -aG docker $USERlogout 

Effettuare nuovamente il login alla macchina:

gcloud compute ssh ml-pipeline --zone europe-west3-c --quiet --tunnel-through-iap --project <your-project-id>

Consultare questi documenti per le istruzioni complete [9].

#3. Sostituire tutti i comandi cp con gcloud compute scp :

Questo comando ti aiuterà a copiare i file dalla tua macchina locale alla VM.

Ad esempio, anziché eseguire:

cp -r /path/to/admin/gcs/credentials/admin-buckets.json credentials/gcp/energy_consumption

Eseguire in un terminale diverso (non quello connesso tramite SSH alla tua VM):

gcloud compute scp --recurse --zone europe-west3-c --quiet --tunnel-through-iap --project <your-project-id> /local/path/to/admin-buckets.json ml-pipeline:~/energy-forecasting/airflow/dags/credentials/gcp/energy_consumption/

Questo comando copierà il tuo file admin-buckets.json locale sulla VM ml-pipeline.

Dopo aver configurato il tuo codice sulla VM GCP ml-pipeline, vai alla vista della tua VM da GCP e alla sezione Network tags. Lì troverai la colonna Indirizzo IP esterno, come mostrato nell’immagine qui sotto. Copia quell’IP e aggiungi la porta 8080.

Ad esempio, basandoci sull’indirizzo IP esterno dell’immagine qui sotto, ho acceduto ad Airflow utilizzando questo indirizzo: 35.207.134.188:8080 .

Congratulazioni! Ti sei connesso alla tua applicazione Airflow auto-ospitata.

Nota: Se non si connette, concedi qualche secondo per caricare correttamente.

Effettuare il deploy dell’app Web

Connettiamoci tramite SSH alla VM GCP “app” creata pochi passaggi prima:

gcloud compute ssh app --zone europe-west3-c --quiet --tunnel-through-iap --project <your-project-id>

• NOTA 1: Modificare la zona se non hai creato una VM nella stessa zona che noi.
• NOTA 2: Il tuo project-id NON è il nome del tuo progetto . Vai alla lista dei tuoi progetti GCP e trova l’id del progetto.

Qui il processo è simile a quello descritto nella sezione “Deploy della Pipeline ML”.

Puoi distribuire l’applicazione web seguendo i passaggi descritti nella lezione 6 o nelle sezioni “Set Up Additional Tools & Usage” del repository GitHub.

Ma non dimenticare di tenere a mente i 3 casi limite descritti nella sezione “Deploy the ML Pipeline”.

Per favore scusami per il riferimento a tanta documentazione esterna su come impostare questa roba. L’articolo è troppo lungo e non ho voluto replicare la documentazione di Google GCP qui.

Pipeline CI/CD Utilizzando GitHub Actions (gratuito)

I file YAML di GitHub Actions si trovano nella directory .github/workflows.

Innanzitutto, lasciami spiegare i principali componenti che devi conoscere di un file di GitHub Actions 👇

Utilizzando la sezione ” on -> push -> branches:“, specifici su quale branch ascoltare per gli eventi. In questo caso, l’azione di GitHub viene attivata quando viene committato nuovo codice nel branch “main”.

Nella sezione ” env: “, puoi dichiarare le variabili d’ambiente necessarie all’interno dello script.

Nella sezione “jobs -> ci_cd -> steps:”, dichiarerai i passaggi della pipeline CI/CD, che verranno eseguiti in sequenza.

Nella sezione “jobs -> ci_cd -> runs-on:”, specifici l’immagine della VM su cui eseguire i passaggi.

Adesso, diamo un’occhiata a alcuni veri file di GitHub Action 🔥

File YAML di GitHub Actions di ML Pipeline

L’azione verrà attivata quando viene committato nuovo codice nel branch “main”, ad eccezione delle directory dell’applicazione web e dei file YAML e Markdown.

Abbiamo aggiunto variabili d’ambiente che contengono informazioni sul progetto GCP e sulla VM.

Per quanto riguarda i passaggi CI/CD, facciamo principalmente 2 cose:

1. configuriamo le credenziali e l’autenticazione su GCP,
2. ci connettiamo con SSH sulla VM GCP data e eseguiamo un comando che: va nella directory del codice, tira fuori le ultime modifiche, costruisce i pacchetti Python e li distribuisce nel registro PyPi. Adesso Airflow utilizzerà i nuovi pacchetti Python la prossima volta che verrà eseguito.

In sostanza, fa ciò che avresti fatto manualmente, ma ora tutto è piacevolmente automatizzato utilizzando GitHub Actions.

Nota che non devi ricordare o sapere come scrivere un file di GitHub Actions da zero, poiché puoi trovare modelli già scritti per la maggior parte dei casi d’uso. Ad esempio, ecco il repository google-github-actions/ssh-compute [11] che abbiamo utilizzato per scrivere il file YAML qui sotto.

Troverai modelli simili per quasi ogni caso d’uso che hai in mente.

File YAML di GitHub Actions dell’applicazione Web

Il file delle azioni dell’applicazione Web è al 90% lo stesso di quello utilizzato per la pipeline ML, ad eccezione dei seguenti:

• ignoriamo i file della pipeline ML;
• eseguiamo un comando docker che costruisce ed esegue l’applicazione web.

Ma da dove viene la strana sintassi ” ${{ vars… }}”? Spiegherò tra poco, ma ciò che devi sapere adesso è il seguente:

• ” ${{ vars.<name> }}“: variabili impostate all’interno di GitHub;

• ” ${{ secrets.<name> }}”: segreti impostati all’interno di GitHub. Una volta impostato un segreto, non puoi più vederlo (le variabili sì);

• ” ${{ env.<name> }}”: variabili d’ambiente impostate nella sezione “env:”.

Importante Osservazione

Il file YAML sopra non contiene la parte CI, solo quella CD.

Per seguire le buone pratiche per una robusta pipeline CI, dovresti eseguire un’azione che crea le immagini Docker e le carica su un registro Docker.

In seguito, dovresti eseguire il tuo set di test SSH su un ambiente di test. Come ultimo passaggio, dovresti connetterti via SSH alla VM di produzione, scaricare le immagini e avviarle.

La serie è diventata troppo lunga e abbiamo voluto mantenerla semplice, ma la buona notizia è che hai imparato tutti gli strumenti e i principi necessari per fare ciò che abbiamo descritto sopra.

Imposta Secret e Variabili

In questo punto, devi fare il fork del repository energy-consumption per configurare le credenziali GitHub Actions con le tue.

Consulta questo documento per vedere come fare il fork di un repository su GitHub [10].

Imposta le variabili delle Azioni

Vai al tuo repository forkato. Dopo aver cliccato su: “Impostazioni -> Secret e variabili -> Azioni.”

Ora, fai clic su “Variabili”. Puoi creare una nuova variabile cliccando su “Nuova variabile del repository”. Vedi l’immagine qui sotto 👇

Devi creare 5 variabili che gli script delle GitHub Actions utilizzeranno:

• APP_INSTANCE_NAME : il nome della VM dell’applicazione web. Nel nostro caso, si chiama “app”. Il valore predefinito dovrebbe andare bene se usi le nostre convenzioni di denominazione consigliate.
• GCLOUD_PROJECT : l’ID del tuo progetto GCP. Qui, devi cambiarlo con il tuo ID del progetto.
• ML_PIPELINE_INSTANCE_NAME : il nome della VM della pipeline ML. Nel nostro caso, è “ml-pipeline”. Il valore predefinito dovrebbe andare bene se usi le nostre convenzioni di denominazione consigliate.
• USER: l’utente che hai usato per connetterti alle VM mentre configuravi la macchina utilizzando la connessione SSH. Il mio era “pauliusztin”, ma devi cambiarlo con il tuo. Vai alla VM e digita echo $USER.
• ZONE : la zona in cui hai distribuito le VM. Il valore predefinito dovrebbe andare bene se usi le nostre convenzioni di denominazione consigliate.

Imposta i Secret delle Azioni

Nella stessa sezione “Secret e variabili/Azioni”, fai clic sulla scheda “Secrets”.

Puoi creare un nuovo secret premendo il pulsante “Nuovo secret del repository”.

Questi sono simili alle variabili che abbiamo appena completato, ma dopo aver inserito i loro valori, non puoi più vederli. Ecco perché si chiamano secret.

Qui è dove aggiungi tutte le tue informazioni sensibili. Nel nostro caso, le credenziali GCP e le chiavi private. Vedi l’immagine qui sotto 👇

Il secret GCP_CREDENTIALS contiene il contenuto della chiave JSON del tuo account di servizio amministratore VM. Impostando questo, la pipeline CI/CD utilizzerà quell’account di servizio per l’autenticazione alle VM.

Perché il contenuto del file è in formato JSON, per formattarlo correttamente, devi fare i seguenti passaggi:

Installa lo strumento CLI jq:

sudo apt updatesudo apt install -y jqjq - version

Formatta il tuo file chiave JSON:

jq -c . /percorso/al/tuo/admin-vm.json

Prendi l’output di questo comando e crea il tuo secret GCP_CREDENTIALS con esso.

GCP_SSH_PRIVATE_KEY è la tua chiave SSH privata GCP (non la tua personale – GCP ne crea automaticamente un’altra), che è stata creata sul tuo computer locale quando hai usato SSH per connetterti alle VM GCP.

Per copiarlo, eseguire:

cd ~/.sshcat google_compute_engine

Copia l’output dal terminale e crea la variabile GCP_SSH_PRIVATE_KEY.

Esegui la pipeline CI/CD

Ora apporta qualsiasi modifica al codice, pushalo al branch principale e i file di GitHub Actions dovrebbero attivarsi automaticamente.

Controlla la scheda “Actions” del tuo repository di GitHub per vedere i risultati.

Verranno attivati due azioni. Una costruirà e distribuirà i moduli ml-pipeline sulla tua VM GCP ml-pipeline e l’altra costruirà e distribuirà l’app web sulla tua VM GCP app.

Conclusione

Congratulazioni! Hai completato l’ultima lezione del corso Full Stack 7-Steps MLOps Framework. Ciò significa che sei un ingegnere ML full-stack 🔥

Mi scuso ancora per l’articolo altamente tecnico. Non è una lettura molto divertente ma è un passaggio cruciale per finalizzare questa serie.

Nella lezione 7 hai imparato come:

• deployare manualmente le 3 pipeline di ML su GCP;
• deployare manualmente l’app web su GCP;
• costruire una pipeline CI/CD per automatizzare il processo di deploy utilizzando GitHub Actions.

Ora che hai capito come aggiungere un vero valore commerciale deployando il tuo sistema ML e mettendolo in funzione, è il momento di costruire il tuo fantastico progetto di ML.

Nessun progetto è perfettamente costruito, e questo non fa eccezione.

Dai un’occhiata alla nostra lezione bonus del corso The Full Stack 7-Steps MLOps Framework, dove discuteremo apertamente quali altre scelte di design avremmo potuto prendere per migliorare ulteriormente il sistema ML costruito durante questo corso.

Apprezzo sinceramente che tu abbia scelto il mio corso per imparare MLE & MLOps, e spero che ti abbia aiutato nel tuo percorso di apprendimento ✌️

Connettiamoci su LinkedIn e fammi sapere se hai domande e condividi i grandi progetti che hai costruito dopo aver completato il corso The Full Stack 7-Steps MLOps Framework.

Accedi qui al repository di GitHub.

💡 Il mio obiettivo è aiutare gli ingegneri di machine learning a migliorare nella progettazione e produzione di sistemi ML. Seguimi su LinkedIn o iscriviti alla mia newsletter settimanale per maggiori approfondimenti!

🔥 Se ti piace leggere articoli come questo e vuoi sostenere la mia scrittura, considera di diventare un membro di Nisoo. Utilizzando il mio link di referral, puoi supportarmi senza costi aggiuntivi e goderti l’accesso illimitato alla ricca collezione di storie di Nisoo.

Unisciti a Nisoo con il mio link di referral – Paul Iusztin

🤖 Unisciti per ottenere contenuti esclusivi sulla progettazione e costruzione di sistemi ML pronti per la produzione 🚀 Sblocca l’accesso completo a…

pauliusztin.medium.com

Grazie ✌🏼 !

Riferimenti

[1] Consumo energetico per codice settore DE35 da Denmark API, Denmark Energy Data Service

[2] Utilizzo di IAP per il forwarding TCP, GCP Docs

[3] Panoramica del forwarding TCP, GCP Docs

[4] Google Cloud Collective, Come aprire una porta specifica come 9090 in Google Compute Engine (2017), Stackoverflow

[5] ANTHONY HEDDINGS, Come aprire le porte del firewall su un’istanza di GCP Compute Engine (2020), How-To Geek

[6] Preparazione del tuo progetto per il forwarding TCP di IAP, GCP Docs

[7] Riserva di un indirizzo IP esterno statico, GCP Docs

[8] Creazione e eliminazione di chiavi per account di servizio, GCP Docs

[9] Tom Roth, Installare Docker su una macchina virtuale di Google Cloud (2018), Blog di Tom Roth

[10] Fork di un repo , Documenti di GitHub

[11] Repository GCP GitHub Actions , GitHub