Nelle fasi iniziali della progettazione o dell'implementazione di GitOps, può essere scoraggiante pensare ai vari strumenti e pratiche di cui si potrebbe avere bisogno. Si vuole essere certi di progettare un flusso di lavoro robusto e scalabile per gestire l'infrastruttura e le distribuzioni delle applicazioni. E non si vuole introdurre nulla che complichi eccessivamente i processi o renda più difficile per il team rilasciare le modifiche al codice.
Un modo per restringere l'attenzione è quello di cercare strumenti e pratiche che supportino le vostre pratiche di distribuzione. La considerazione principale è se utilizzare un approccio basato su push o su pull. Entrambi hanno i loro pro e i loro contro e il tipo di approccio utilizzato avrà un impatto sugli strumenti e sui processi da includere nella vostra strategia GitOps.
Automazione dei flussi di lavoro e dell'infrastruttura
Innanzitutto, esaminiamo due pratiche DevOps fondamentali: Infrastruttura come codice (IaC) e automazione con Continuous Integration e Continuous Delivery (CI/CD).
L'IaC è una tecnica per distribuire e gestire l'infrastruttura attraverso il codice, invece di una serie di passaggi manuali o di processi interattivi. Questo approccio non è limitato alle sole primitive infrastrutturali o ai servizi cloud gestiti, ma è applicabile a tutti gli aspetti gestibili, come i file di configurazione, le installazioni software, le policy di rete e di sicurezza e così via. Comunemente definito "X as Code", questo tipo di gestione unificata fornisce uno stato desiderato templato e documentato per l'implementazione.
CI/CD è una metodologia e un insieme di pratiche comuni che consentono agli sviluppatori di fornire rapidamente e in modo affidabile applicazioni di qualità e codificate in modo sicuro. Adottare il CI/CD significa abbracciare una cultura in cui i team di sviluppo possono rimanere concentrati sui requisiti del business e dell'utente finale, implementando l'automazione nelle fasi giuste del ciclo di vita dello sviluppo del software.
Nello sviluppo del software, l'integrazione è il processo di commit delle modifiche al codice in un repository. L'integrazione continua (CI) è il processo di convalida automatica delle modifiche, attraverso la creazione, il test e il confezionamento del codice dell'applicazione aggiornato in modo affidabile e coerente. L'attivazione di un flusso di lavoro CI su ogni evento push consente un processo di sviluppo più fluido e veloce, poiché bug, vulnerabilità di sicurezza e conflitti possono essere scoperti prima che le modifiche vengano distribuite in un ambiente.
Un flusso di lavoro di Continuous Delivery (CD) subentra dopo il completamento positivo del flusso di lavoro CI. Può trattarsi di un flusso di lavoro che facilita la distribuzione dell'applicazione direttamente sui server di staging o di produzione, oppure la spedizione di una nuova release a un registro di container o a una piattaforma di distribuzione mobile.
Si tratta di temi centrali che riguardano l'automazione dei flussi di lavoro degli sviluppatori. Un approccio GitOps si basa su queste pratiche DevOps fondamentali e le mette in pratica. Sfruttando un repository git come unica fonte di verità per i file di definizione IaC e utilizzando le pipeline di automazione, è possibile controllare efficacemente lo stato desiderato della propria infrastruttura.
È qui che torniamo alle vostre pratiche di distribuzione: decidere se push o pull è la soluzione migliore per la vostra applicazione e la vostra strategia GitOps.
Confronto tra architettura push e pull
L'approccio push-based, o agentless, è quello più tradizionale, in cui le modifiche vengono inviate all'ambiente selezionato da un client CI/CD esterno, come Jenkins o CircleCI. Questo approccio può essere preferibile per gli ambienti non Kubernetes o per gli ambienti con un mix di carichi di lavoro che renderebbero ingombrante l'esecuzione di agenti e webhook separati per ogni componente.
Pro:
- Più semplice da implementare su più tipi di carichi di lavoro in un unico ambiente.
- Standardizzazione della metodologia di distribuzione tra ambienti diversi (ad esempio cloud-native e on-premise).
- Flessibilità degli strumenti, poiché la maggior parte dei framework CI/CD utilizza un modello basato sul push.
Contro:
- Il client CI/CD non ha la possibilità di osservare se le modifiche sono state distribuite con successo o se si sono verificati problemi sul lato server.
- Potrebbe essere necessario installare altri strumenti (ad esempio kubectl, Helm, Docker, Ansible, Terraform, SSH) affinché il client CI/CD possa distribuire le modifiche.
- Richiede l'accesso esterno del cliente CI/CD all'ambiente, il che aumenta il rischio di problemi di sicurezza e conformità.
L'approccio basato sui pull o sugli agenti funziona in senso opposto, rendendo l'ambiente parte della pipeline del CD. Un agente o un operatore osserva il repository git alla ricerca di modifiche, quindi le preleva e le applica. Questo compito viene svolto anche ogni volta che l'agente rileva una deriva della configurazione dalla singola fonte di verità. Questo approccio funziona particolarmente bene con gli ambienti nativi Kubernetes.
Pro:
- L'agente/operatore ha la possibilità di osservare lo stato attuale dell'ambiente e lo stato di distribuzione.
- Maggiore sicurezza e conformità semplificata, perché l'ambiente richiede solo l'autorizzazione a visualizzare l'origine.
- Rilevamento rapido della deriva della configurazione dovuta all'intervento umano manuale o ad altre fonti.
Contro:
- Più complesso per le distribuzioni non Kubernetes.
- Richiede strumenti progettati per lavorare con tipi di ambiente specifici.
Quando iniziate a pianificare la vostra strategia GitOps, considerate come le diverse strategie di distribuzione supporteranno la vostra applicazione. Sia l'approccio push che quello pull hanno i loro vantaggi e sono adatti a diversi scenari. Ci sono molti strumenti e pratiche da considerare, e con un po' di prospettiva saprete qual è la soluzione giusta per il vostro team e il vostro stack.
Volete maggiori informazioni? Scaricate il nostro ebook gratuito sulla strategia GitOps o richiedete una consulenza gratuita con un esperto di cloud computing Akamai.
Commenti