Con gli ultimi progressi in materia di cloud computing, è diventato ancora più necessario per l'implementazione di strumenti che siano, allo stesso tempo, scalabili e che garantiscano la riproducibilità dell'esecuzione. Tenendo presente questa esigenza, sono nati al lavoro alcuni strumenti, come Docker, che consentono la creazione di una “ricetta” dell'applicazione, garantendo che build differenti della stessa applicazione funzionino allo stesso modo.
A differenza di una virtual machine (VM), che fornisce un'infrastruttura attraverso processori e memoria tramite un hypervisor, Docker condivide queste risorse in tutti i container, consentendo allo sviluppatore di concentrarsi meno sulle infrastrutture e più sullo sviluppo dell'applicazione. Tuttavia, la containerizzazione di progetti e applicazioni mitiga l'espressione “It Runs on My Machine”, dato che cerca di garantire che, indipendentemente dalla piattaforma scelta dallo sviluppatore, il container Docker venga eseguito sempre allo stesso modo.
Dato che i vantaggi della containerizzazione vanno oltre lo sviluppo di applicazioni e possono essere utili in altri campi, molti data scientist hanno iniziato a utilizzare Docker per containerizzare la loro analisi, l'addestramento del modello, i dashboard e le API, sia per rendere più facile la consegna dei progetti (dato che riduce la possibilità di bug) e per garantire che i risultati trovati una volta, possano essere sempre raggiunti nuovamente.
Anche se molti modelli di machine learning generati dai data scientist sono preziosi, non riescono ad aggiungere valore al business che vengono inseriti quando i progetti sono bloccati in una macchina personale che non può essere utilizzata da altre persone. Pertanto, per garantire che eventuali modifiche vengano identificate e che i suoi risultati siano estesi ad altri team, esiste il processo di continuous integration e continuous delivery (CI / CD), che consente l'automazione dei processi di test e distribuzione nelle versioni iniziali del progetto .
Molte persone potrebbero avere familiarità con i concetti di CI / CD, tuttavia, molti degli strumenti utilizzati per questo processo sono a pagamento (come Jenkins , CircleCI e TravisCI ), limitandone l'utilizzo solo a persone che:
a) sono disposti a pagare il prezzo di questi strumenti;
oppure b) lavorano in un'azienda che ha già sviluppato un ciclo CI / CD.
GitHub è una nota piattaforma di controllo delle versioni del codice che ha più di 40 milioni di utenti e più di 100 milioni di repository, essendo un'enorme fonte di codice open-source, disponibile per migliaia di persone in tutto il mondo.
Con l'obiettivo di supportare la creazione di progetti open-source, nonché consentire ai propri utenti di astrarre i processi che coinvolgono CI / CD, GitHub creato nel 2019, lo strumento GitHub Actions. Consente l'automazione dei flussi di lavoro definiti dall'utente per aiutare con i test integrati, la convalida delle richieste pull e molte altre funzionalità. Inoltre, il numero di azioni che l'utente deve utilizzare cresce di giorno in giorno, dato che molte aziende stanno cercando di sviluppare strumenti per aiutare la comunità degli utenti. Molte di queste azioni consentono già l'integrazione di molti strumenti popolari come Docker, AWS CloudFormation, Terraform e molti altri che possono essere trovati qui.
Anche se GitHub Actions può essere utilizzato gratuitamente solo per repository non privati, ci sono diversi livelli di utilizzo che possono essere sfruttati in progetti privati, prima di considerare l'uso di qualsiasi strumento GitHub Enterprise. Questo apre le porte affinché molte persone che sviluppano progetti open source possano testare i propri strumenti e diffondere le proprie scoperte in modo più automatizzato e scalabile.
Uno degli strumenti sviluppati per essere utilizzati insieme a GitHub Actions sono le azioni di accesso nei repository che consentono l'archiviazione di immagini Docker (come Docker Hub , ECR da AWS , GCR da GCP ), nonché la creazione di queste immagini senza la necessità per occupare la macchina dell'utente. Con questi in mente, vengono dichiarate due azioni nel file del flusso di lavoro CI, che può essere trovato in questi collegamenti: docker / login-action e docker / build-push-action .
Inserimento di Data Science nel processo CI / CD
Il campo della Data Science è pieno di framework, dipendenze e linguaggi differenti che possono essere usati secondo le necessità e le abilità del data scientist, ma una verità comune tra loro è che hanno tutti la possibilità di essere incapsulati da un processo di containerizzazione , contribuendo a garantire la riproducibilità del progetto.
Con questo in mente, l'esempio da me utilizzato per distribuire lo strumento di automazione di GitHub Actions prevede lo sviluppo di un'applicazione web utilizzando la libreria Shiny di R. Tuttavia, la stessa implementazione del flusso di lavoro potrebbe essere utilizzata per distribuire API sviluppate utilizzando FastAPI di Python , ovvero qualsiasi altro framework che può essere incapsulato in un contenitore Docker.
Il progetto può essere trovato qui: paeselhz / ghActionsDockerShiny . Non entrerò nei dettagli dello sviluppo dell'applicazione, perché l'esempio da me utilizzato è relativamente semplice e non ha sviluppo elaborato. Il fulcro di questo articolo è la containerizzazione del progetto e l'automazione del flusso di lavoro per creare l'immagine e archiviarla in Docker Hub , rendendola disponibile per ulteriori download.
Creazione del Dockerfile
Per coloro che hanno familiarità con il Dockerfile e la sua sintassi, l'esecuzione è la stessa prevista in un progetto che verrà sviluppato, costruito ed eseguito localmente con Docker. In esso, dichiariamo l'immagine di base che verrà utilizzata per l'ulteriore installazione di librerie e dipendenze, nonché la configurazione del progetto, la copia del file e altri passaggi che di solito possono essere aggiunti a un Dockerfile.
Questo script, che si trova nella directory root del progetto, ha il compito di raccogliere un'immagine che ha già Shiny e le sue dipendenze installate e l'installazione delle librerie che verranno utilizzate dall'app sviluppata all'interno di R.
Creazione del file del flusso di lavoro
Affinché le azioni di GitHub sappiano quali passaggi devono essere eseguiti per l'automazione del flusso di lavoro, diventa necessario creare un file all'interno del progetto che si troverà in .github / workflows / main.yml, la sintassi del file è la stessa di qualsiasi file YAML, essendo facile da codificare. Nel caso in cui l'utente non desideri eseguire questo processo localmente e confermare le modifiche, GitHub stesso dispone di un editor di codice online per la creazione del flusso di lavoro.
In questo file vengono dichiarati alcuni passaggi come il nome del flusso di lavoro, i trigger che verranno utilizzati per distribuire l'esecuzione del flusso di lavoro e i lavori che sarà responsabile dell'esecuzione. Il nome e le parti trigger del file sono altamente personalizzabili e l'utente può cambiarlo in molti modi, inoltre, nella parte del lavoro, ci sono alcuni passaggi che sono necessari per il lavoro per accedere a Docker Hub, configurare BuildX (uno strumento che verrà utilizzato per creare l'immagine), configurare QEMU (uno strumento che consentirà build multipiattaforma), distribuire l'immagine costruita su Docker Hub, disconnettersi e pulire la macchina per garantire che nessun processo sia ancora in esecuzione.
Il codice del flusso di lavoro non ha quasi nessuna dipendenza esterna, dato che la creazione del nome dell'immagine Docker e dei suoi tag sono all'interno di questo codice, tuttavia, è necessario un paio di Segreti per accedere a Docker Hub, in questo caso, il nome utente utilizzato da Docker e un token per accedere all'hub Docker ( che può essere generato qui ). Con il nome utente e il token, l'utente deve solo andare al proprio repository, nella scheda Impostazioni e aggiungere il token nella sottopagina Segreti, come mostrato nell'immagine seguente:
Con questi passaggi, il progetto dovrebbe essere in grado di essere eseguito utilizzando le azioni GitHub per consentire l'automazione dei processi di compilazione, test e distribuzione.
Nell'esempio utilizzato da questo articolo, l'immagine finale può essere trovata su Docker Hub qui e testata localmente eseguendo il comando:
Fonte: towardsdatascience.com
