Che cos'è GitOps? Una guida semplice per automatizzare la gestione dell'infrastruttura

Probabilmente hai sentito parlare di DevOps (Developer Operations), che automatizza i processi di distribuzione delle applicazioni. Se lavori con i dati, probabilmente conosci anche MLOps (Machine Learning Operations), che semplifica la messa in produzione dei modelli. Ma che dire di GitOps?

In questo blog esploreremo cos'è GitOps, perché è importante, i diversi modelli GitOps e, infine, come integrare GitOps in un progetto di large language model. 

Immagine dell'autore

Puoi anche approfondire la teoria alla base dei concetti di DevOps e MLOps seguendo due dei nostri migliori corsi brevi, DevOps Concepts e MLOps Concepts.

Che cos'è GitOps?

GitOps è un framework operativo che estende i principi DevOps all'automazione dell'infrastruttura. Sottolinea lezioni chiave di DevOps, come il controllo di versione, la collaborazione, la conformità, CI/CD e l'osservabilità, applicandole al provisioning e alla gestione dell'infrastruttura, soprattutto negli ambienti cloud moderni.

Alla base, GitOps automatizza la gestione dell'infrastruttura trattando le configurazioni come codice, spesso chiamato Infrastructure as Code (IaC). Proprio come i team di sviluppo usano il codice sorgente per creare in modo coerente i binari dell'applicazione, i team operativi usano file di configurazione archiviati in repository Git per garantire che ogni volta venga distribuito lo stesso ambiente infrastrutturale. Questo approccio garantisce coerenza, affidabilità e ripetibilità.

Componenti chiave di un workflow GitOps:

1. Repository Git: Archivia sia il codice sorgente dell'applicazione sia i file di configurazione dell'infrastruttura.
2. Pipeline di continuous delivery (CD): Automatizza la build, il test e la distribuzione dell'applicazione e delle modifiche all'infrastruttura.
3. Strumento di deployment dell'applicazione: Garantisce che le applicazioni vengano distribuite correttamente ed in modo efficiente in base alle configurazioni nel repository Git.
4. Sistema di monitoraggio: Tiene traccia delle prestazioni e dello stato di salute dell'applicazione per mantenere l'affidabilità del sistema.

GitOps vs DevOps vs MLOps

Perché usare GitOps?

La gestione dell'infrastruttura è stata tradizionalmente manuale, ma il cloud moderno richiede automazione per gestire velocità e scala delle applicazioni cloud-native. Con GitOps, l'infrastruttura diventa elastica e affidabile, consentendo ai team di distribuire modifiche in modo rapido e coerente. Elimina gli errori manuali, migliora l'efficienza e assicura che infrastruttura e applicazioni siano sempre allineate, supportando il ritmo serrato dei flussi di lavoro di sviluppo moderni.

Vantaggi principali di GitOps:

1. Controllo di versione: Tutte le modifiche a infrastruttura e applicazioni sono versionate in Git, consentendo rollback semplici e tracciabilità completa.
2. Collaborazione migliorata: I team possono collaborare in modo più efficace utilizzando workflow Git familiari, come le pull request.
3. Maggiore affidabilità: Le configurazioni dichiarative assicurano che lo stato desiderato del sistema possa essere ripristinato automaticamente in caso di guasto.
4. Automazione: Riduce al minimo la necessità di interventi manuali, diminuendo così il rischio di errore umano.
5. Sicurezza: La cronologia dei commit di Git fornisce un registro immutabile, migliorando sicurezza e tracciabilità.

Modello GitOps pull-based vs push-based

Nell'approccio GitOps esistono due modelli principali per distribuire e gestire le configurazioni di infrastruttura e applicazioni: pull-based e push-based. Questi modelli differiscono nel modo in cui gestiscono le modifiche alla configurazione e le applicano all'ambiente di destinazione.

Modello pull-based (GitOps tipico)

L'approccio pull-based si basa sull'archiviazione dello stato desiderato del sistema in un repository Git. Un operatore GitOps, come Flux o Argo CD, monitora continuamente il repository alla ricerca di modifiche. Quando vengono rilevati aggiornamenti, l'operatore esegue automaticamente il pull della configurazione aggiornata e la applica all'ambiente di destinazione. 

Il modello pull-based offre anche rilevamento del drift e self-healing, poiché il cluster "tira" continuamente lo stato desiderato da Git. Questo assicura che eventuali modifiche involontarie o drift di configurazione nell'ambiente vengano corretti automaticamente, mantenendo coerenza e stabilità

Modello push-based (utilizzando strumenti CI/CD)

L'approccio push-based si affida a strumenti come GitHub Actions o altri servizi CI/CD per inviare aggiornamenti al cluster ogni volta che vengono eseguiti commit. A differenza del modello pull-based, l'approccio push-based non prevede riconciliazione continua, il che significa che non esiste un rilevamento del drift integrato né un rollback automatico. Questo lo rende meno resiliente a modifiche indesiderate nell'ambiente. Tuttavia, il modello push-based è spesso più semplice da implementare e offre un controllo granulare sui deployment.

Integrare GitOps nel progetto LLM 

Ci concentreremo su un approccio GitOps push-based utilizzando GitHub Actions, perché è più semplice da configurare e richiede conoscenze pregresse minime. Sebbene un sistema push-based non offra tutti i vantaggi di un approccio pull-based, fornisce comunque caratteristiche GitOps essenziali come configurazioni versionate, deployment automatizzati e rollback semplificati.

In questa sezione applicheremo i principi GitOps al progetto del tutorial How to Deploy LLM Applications Using Docker: A Step-by-Step Guide. Questo progetto include il codice per un'applicazione Gradio, un Dockerfile e il file requirements.txt. Mostra come distribuire un'applicazione di IA sul cloud utilizzando Docker.

Fonte: How to Deploy LLM Applications Using Docker: A Step-by-Step Guide

Adotta una mentalità MLOps per addestrare, documentare, mantenere e scalare in modo efficace i tuoi modelli di machine learning iscrivendoti al corso Developing Machine Learning Models for Production with an MLOps Mindset.

Struttura del progetto

Questo progetto GitOps è pensato per distribuire applicazioni di Large Language Model (LLM) utilizzando Docker, Kubernetes e GitHub Actions. Il progetto organizza tutti i file LLM nella cartella app, crea una cartella infra per le configurazioni Kubernetes e utilizza .github/workflows/ per l'automazione CI/CD con GitHub Actions.

• Docker assicura che l'app giri in modo coerente tra ambienti, impacchettandola con tutte le dipendenze.
• Kubernetes automatizza distribuzione, scalabilità e gestione dell'app.
• GitHub Actions automatizza test, build e distribuzione dell'app.

Segui il corso Introduction to Kubernetes e impara le basi di Kubernetes per distribuire e orchestrare container usando Manifest e istruzioni kubectl.

Questa struttura garantisce deployment automatizzati, scalabili e specifici per ambiente per la tua applicazione LLM, seguendo i principi moderni di GitOps.

Deploying-LLM-Applications-with-Docker/
├── app/
│   ├── requirements.txt      <-- Python dependencies for your LLM app
│   ├── main.py               <-- Your LLM application code
│   └── Dockerfile            <-- Docker instructions for building the app
├── infra/
│   ├── dev/                  <-- Dev environment configs (YAML or Helm)
│   ├── staging/              <-- Staging environment configs
│   └── production/           <-- Production environment configs
└── .github/
    └── workflows/
        ├── ci.yaml           <-- GitHub Actions workflow for continuous integration
        └── cd.yaml           <-- GitHub Actions workflow for continuous deploymentOfferto da

Ecco una semplice spiegazione:

• app/: Contiene il codice dell'applicazione (main.py), le dipendenze (requirements.txt) e un Dockerfile per creare il container dell'app.
• infra/: Contiene le configurazioni Kubernetes per i diversi ambienti:
• cartelle dev/, staging/ e production/ per le impostazioni specifiche di ciascun ambiente.
• .github/workflows/: Automatizza CI/CD con GitHub Actions:
• ci.yaml: crea l'app e l'immagine Docker.
• cd.yaml: distribuisce l'app inviando le immagini Docker e applicando le configurazioni Kubernetes.

Scopri la differenza tra Kubernetes e Docker leggendo il tutorial Kubernetes vs Docker.

Panoramica del workflow GitHub Actions

Ecco cosa succede nel workflow di GitHub Actions:

Developer commits code + config to GitHub
               |
               v
      GitHub Actions CI (ci.yaml)
       - Builds Docker image
       - (Optional) pushes Docker image
               |
               v
     GitHub Actions CD (cd.yaml)
       - Deploys updated app/config
       - kubectl apply or helm upgrade
               |
               v
      Kubernetes Cluster UpdatedOfferto da

1. Commit delle modifiche da parte dello sviluppatore: Il codice e gli aggiornamenti di configurazione vengono pushati su GitHub.
2. Pipeline CI (ci.yaml):
• Crea l'immagine Docker.
• Opzionalmente invia l'immagine al registry dei container.
• Esegue i test per validare l'applicazione.
3. Pipeline CD (cd.yaml):
• Distribuisce l'app o la configurazione aggiornata.
• Esegue kubectl apply o helm upgrade per aggiornare i manifest Kubernetes.
4. Cluster Kubernetes aggiornato: Il cluster esegue la nuova versione dell'applicazione.

Impara ad automatizzare addestramento, valutazione, versioning e deployment dei modelli utilizzando GitHub Actions seguendo il tutorial A Beginner's Guide to CI/CD for Machine Learning.

Vantaggi chiave e compromessi dell'uso di un approccio GitOps push-based

Se hai già esperienza con GitHub Actions, impostare una metodologia GitOps con un approccio push-based può essere semplice. Ti basta aggiungere i file di configurazione dell'infrastruttura, configurare le pipeline CI/CD e sei pronto. Tuttavia, pur essendo semplice, questo approccio comporta alcuni compromessi importanti da considerare.

Vantaggi

• Semplicità: Per implementare questo approccio ti serve solo GitHub Actions: non è necessario un operatore GitOps aggiuntivo come Argo CD o Flux.
• Piattaforma unica: GitHub Actions offre un'unica piattaforma per creare, testare e distribuire la tua applicazione, razionalizzando l'intero processo.

Compromessi

• Non è un vero pull-based: A differenza degli strumenti GitOps pull-based come Argo CD, questo approccio manca della "riconciliazione continua". Significa che lo stato del cluster non viene monitorato e riconciliato automaticamente con lo stato desiderato in Git.
• Nessun rilevamento del drift: Se qualcuno modifica manualmente le risorse nel cluster, queste modifiche non verranno ripristinate automaticamente per corrispondere al repository Git. Questo può portare a drift di configurazione nel tempo.
• Sicurezza: Per consentire a GitHub Actions di distribuire sul tuo cluster, devi archiviare le credenziali del cluster nei secret di GitHub o usare un metodo di autenticazione basato su OIDC. Entrambi richiedono una gestione attenta per evitare rischi di sicurezza.

Passare a un modello pull-based

Man mano che il tuo progetto cresce o i requisiti diventano più esigenti, passare a un modello GitOps pull-based può offrire vantaggi significativi. Se il tuo team ha bisogno di funzionalità come self-healing, riconciliazione continua o una dashboard visiva, adottare uno strumento pull-based come Argo CD o Flux potrebbe essere il passo successivo più logico.

• Self-healing: Ripristina automaticamente gli stati del cluster in caso di drift.
• Riconciliazione continua: Monitora il tuo repo Git per cambi di configurazione 24/7.
• Dashboard visiva: Per verificare stati e log delle app.

Puoi passare a uno strumento pull-based come Argo CD o Flux. Monitoreranno costantemente il tuo repository e garantiranno che il cluster corrisponda sempre a ciò che è in Git, senza passaggi di "push" manuali dopo il commit iniziale.

Conclusione

Per implementare efficacemente GitOps, è meglio iniziare in piccolo e adottarne gradualmente le tecnologie. Parti da un semplice Dockerfile per containerizzare la tua applicazione e distribuirla nel cloud. Poi introduci Kubernetes per abilitare scalabilità e affidabilità tramite distribuzione e gestione automatizzate. 

Quando ti sentirai a tuo agio, adotta un approccio GitOps push-based usando strumenti come GitHub Actions per automatizzare sia l'infrastruttura cloud sia il deployment dell'applicazione. Infine, man mano che il progetto matura e richiede stabilità a livello di produzione, passa a un modello pull-based con strumenti come Argo CD o Flux per ottenere riconciliazione continua, rilevamento del drift e funzionalità di self-healing. 

Questa progressione graduale assicura una curva di apprendimento fluida, sfruttando al massimo GitOps per le moderne applicazioni cloud-native.

In questo blog abbiamo esplorato GitOps, la sua importanza, i vari modelli GitOps e come integrare GitOps in un progetto di IA. Se sei alle prime armi con l'IA, ti consigliamo vivamente di seguire il percorso di competenze AI Fundamentals che copre le basi dell'IA, approfondendo modelli come GPT-4o e svelando i segreti dell'IA generativa per orientarti nel panorama in evoluzione.