Noi di True Engineering abbiamo impostato un processo di consegna continua degli aggiornamenti ai server del cliente e vogliamo condividere questa esperienza.
Per iniziare, abbiamo sviluppato un sistema online per il cliente e lo abbiamo distribuito nel nostro cluster Kubernetes. Ora la nostra soluzione ad alta disponibilità è stata trasferita sulla piattaforma del cliente, per cui abbiamo configurato un processo automatizzato di Continuous Deployment. Grazie a ciò, abbiamo accelerato il time-to-market – la consegna delle modifiche nell'ambiente di produzione.
In questo articolo parleremo di tutte le fasi del processo di Continuous Deployment (CD) o di consegna degli aggiornamenti sulla piattaforma del cliente:
- come inizia questo processo,
- sincronizzazione con il repository Git del cliente,
- compilazione del backend e del frontend,
- distribuzione automatica dell'applicazione in ambiente di test,
- distribuzione automatica in Prod.
Nel processo condivideremo i dettagli della configurazione.
1. Avvio del CD
Il Continuous Deployment inizia quando lo sviluppatore carica le modifiche nel ramo di rilascio del nostro repository Git.
La nostra applicazione si basa su un'architettura a microservizi e tutti i suoi componenti sono archiviati in un unico repository. Grazie a ciò, tutti i microservizi vengono compilati e installati anche se uno di essi è stato modificato.
Abbiamo organizzato il lavoro tramite un unico repository per diversi motivi:
- Comodità di sviluppo: l'applicazione è in continua evoluzione, quindi è possibile lavorare immediatamente su tutto il codice.
- Pipeline CI/CD unica che garantisce che l'applicazione, come un sistema unico, superi tutti i test e venga consegnata nell'ambiente di produzione del cliente.
- Escludiamo confusione nelle versioni: non dobbiamo mantenere una mappa delle versioni dei microservizi e descrivere la configurazione per ogni microservizio negli script Helm.
2. Sincronizzazione con il repository Git del codice sorgente del cliente
Le modifiche apportate vengono sincronizzate automaticamente con il repository Git del cliente. Qui è configurata la compilazione dell'applicazione, che viene eseguita dopo l'aggiornamento del ramo, e il deployment in produzione. Entrambi i processi avvengono nel loro ambiente dal repository Git.
Non possiamo lavorare direttamente con il repository del cliente poiché abbiamo bisogno di ambienti propri per lo sviluppo e il collaudo. Utilizziamo un nostro repository Git per questo scopo, che è sincronizzato con il loro repository Git. Non appena lo sviluppatore carica le modifiche nel ramo corrispondente del nostro repository, GitLab invia immediatamente tali modifiche al cliente.
Dopo ciò, è necessario effettuare la build. Essa consiste in diverse fasi: costruzione del backend e del frontend, collaudo e distribuzione in produzione.
3. Costruzione del backend e del frontend
La costruzione del backend e del frontend è costituita da due compiti paralleli che vengono eseguiti nel sistema GitLab Runner. La configurazione della build originale si trova nello stesso repository.
.
GitLab Runner preleva il codice dal repository corretto, compila l'applicazione Java con il comando di build e lo invia al Docker registry. Qui costruiamo backend e frontend, otteniamo immagini Docker che archiviamo nel repository sul lato del cliente. Per gestire le immagini Docker utilizziamo .
Sincronizziamo le versioni delle nostre immagini con il numero di versione del rilascio che sarà pubblicato in Docker. Per un funzionamento agevole, abbiamo apportato alcune configurazioni:
1. Tra l'ambiente di collaudo e il prodotto, i contenitori non vengono ricostruiti. Abbiamo effettuato parametrici in modo che lo stesso contenitore possa funzionare senza ricostruzione con tutte le configurazioni, le variabili ambientali e i servizi sia nell'ambiente di collaudo che in produzione.
2. Per aggiornare l'applicazione tramite Helm è necessario specificarne la versione. Abbiamo la costruzione del backend, del frontend e l'aggiornamento dell'applicazione, che sono tre attività diverse, pertanto è importante utilizzare sempre la stessa versione dell'applicazione. Per questa attività utilizziamo i dati dalla cronologia di Git, poiché abbiamo la configurazione del cluster K8S e dell'applicazione nello stesso repository Git.
La versione dell'applicazione la otteniamo dai risultati dell'esecuzione del comando
git describe --tags --abbrev=7.
4. Distribuzione automatica di tutte le modifiche nell'ambiente di collaudo (UAT)
Nella fase successiva di questo script di build, viene eseguito un aggiornamento automatico del cluster K8S. Questo avviene a condizione che l'intera applicazione sia stata compilata e tutti gli artefatti siano stati pubblicati nel Docker Registry. Dopodiché, viene avviato l'aggiornamento dell'ambiente di collaudo.
L'aggiornamento del cluster viene avviato tramite . Se qualcosa va storto, Helm annullerà automaticamente tutte le sue modifiche senza bisogno di controlli esterni.
Forniamo insieme all'assemblaggio la configurazione del cluster K8S. Pertanto, il passo successivo è l'aggiornamento di questa: configMaps, deployments, services, secrets e qualsiasi altra configurazione K8S che abbiamo modificato.
Successivamente, Helm avvia l'aggiornamento RollOut dell'applicazione stessa nell'ambiente di test. Prima che l'applicazione venga distribuita in produzione. Questo è fatto affinché gli utenti possano verificare manualmente le funzionalità aziendali che abbiamo implementato nell'ambiente di test.
5. Distribuzione automatica di tutte le modifiche in Prod
Per distribuire l'aggiornamento nell'ambiente di produzione, basta premere un pulsante in GitLab — e i contenitori vengono immediatamente consegnati nell'ambiente di produzione.
Lo stesso applicativo può funzionare senza ricompilazione in ambienti diversi — test e produzione. Utilizziamo gli stessi artefatti, senza modificare nulla nell'applicazione, mentre i parametri vengono definiti esternamente.
La flessibilità nella parametrizzazione delle impostazioni dell'applicazione dipende dall'ambiente in cui l'applicazione verrà eseguita. Abbiamo estratto tutte le configurazioni ambientali all'esterno: tutto è parametrizzato attraverso la configurazione K8S e i parametri Helm. Quando Helm distribuisce l'assemblaggio nell'ambiente di test, gli vengono applicati i parametri di test, mentre nell'ambiente di produzione — i parametri di produzione.
La parte più difficile è stata parametrizzare tutti i servizi e le variabili utilizzati, che dipendono dall'ambiente, e convertirli in variabili d'ambiente e nella descrizione/configurazione dei parametri ambientali per Helm.
Nei parametri dell'applicazione si usano variabili d'ambiente. I loro valori sono definiti nei contenitori tramite K8S configmap, che viene templateizzato tramite modelli Go. Ad esempio, per impostare una variabile d'ambiente per il nome di dominio, si può fare così:
APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}
.Values.global.env – in questa variabile è memorizzato il nome dell'ambiente (prod, stage, UAT).
.Values.app.properties.app_external_domain – in questa variabile specifichiamo il dominio desiderato nel file .Values.yaml
Durante l'aggiornamento dell'applicazione, Helm crea file configmap.yaml dai modelli e riempie il valore di APP_EXTERNAL_DOMAIN con il valore necessario a seconda dell'ambiente in cui viene avviato l'aggiornamento dell'applicazione. Questa variabile viene impostata già nel contenitore. L'accesso a essa è disponibile dall'applicazione, pertanto in ogni ambiente dell'applicazione ci sarà un valore diverso per questa variabile.
Recentemente in Spring Cloud è stata introdotta la supporto per K8S, compreso il lavoro con i configMaps: . Finché il progetto è in fase di sviluppo attivo e subisce cambiamenti radicali, non possiamo utilizzarlo in produzione. Ma monitoriamo attivamente il suo stato e lo utilizziamo nelle configurazioni DEV. Non appena si stabilizzerà, passeremo dall'utilizzo delle variabili d'ambiente a esso.
Totale
Quindi, il Continuous Deployment è configurato e funziona. Tutti gli aggiornamenti avvengono con un semplice tasto. La consegna delle modifiche nell'ambiente di produzione è automatica. E, cosa importante, gli aggiornamenti non fermano il funzionamento del sistema.
Piani per il futuro: migrazione automatica del database
Abbiamo considerato l'upgrade del database e la possibilità di annullare tali cambiamenti. Infatti, ci sono due diverse versioni dell'app in funzione: la vecchia è attiva, mentre la nuova viene avviata. La vecchia verrà disattivata solo quando saremo certi che la nuova versione funzioni. La migrazione del database deve consentire di lavorare con entrambe le versioni dell'app.
Pertanto, non possiamo semplicemente cambiare il nome di una colonna o altri dati. Ma possiamo creare una nuova colonna, copiare i dati dalla vecchia colonna in essa e scrivere dei trigger che copieranno e aggiorneranno i dati nella nuova colonna durante l'aggiornamento. E dopo il deploy riuscito della nuova versione dell'app, dopo un periodo di post launch support, potremo eliminare la vecchia colonna e il trigger divenuto inutile.
Se la nuova versione dell'app non funziona correttamente, possiamo tornare alla versione precedente, inclusa la versione precedente del database. In breve, le nostre modifiche consentiranno di lavorare contemporaneamente con più versioni dell'app.
Pianifichiamo di automatizzare la migrazione del database tramite un lavoro K8S, integrandolo nel processo di CD. E ci assicureremo di condividere questa esperienza su Habrahabr.
Fonte: habr.com
