IT knowledge base
CTRL+F per cercare la tua parola chiave

Distribuzione continua centralizzata in un anno vol 2

Nel nostro ultimo articolo abbiamo parlato di come abbiamo costruito una pipeline centralizzata, ma l'abbiamo descritta in modo piuttosto superficiale. Questo ha dato origine a molte domande che non possiamo lasciare senza risposta. Qui cercheremo di entrare il più in profondità possibile "sotto il cofano" e di raccontare come funziona il nostro trasportatore centralizzato.
Penso che sia meglio descrivere l'intero processo dal momento in cui inizi a lavorare su un'attività e fino a quando non metti in produzione le modifiche apportate. E nel corso del racconto cercherò di rispondere a tutte le domande rimaste senza risposta nell'ultimo articolo.
Permettetemi di fare subito una riserva che i nostri team di sviluppo godono di completa libertà nei processi di costruzione, quindi non si può dire che tutti i team lavorino in stretta conformità con la descrizione di seguito. Sebbene, ovviamente, l'insieme di strumenti imponga alcune restrizioni. Quindi, al punto.
In banca, il principale sistema di tracciamento dei bug è JIRA. Registra le attività per tutti i miglioramenti, le modifiche, ecc. Gli sviluppatori, avviando l'attività, "tagliano" il ramo dal repository principale e poi lo sviluppano. Di seguito è riportato un esempio di un'attività abbastanza tipica.

Dopo aver terminato l'attività, lo sviluppatore invia una richiesta pull a Bitbucket per apportare le modifiche al ramo principale. E qui per la prima volta si imbatte in una manifestazione della pipeline: una richiesta pull avvia il processo di revisione automatica del codice.
La nostra verifica viene eseguita utilizzando SonarQube, che è integrato nella pipeline tramite i plug-in Sonar for Bamboo e Sonar for Bitbucket. Quando registri una richiesta pull, Bamboo esegue automaticamente un piano di build che analizza il ramo che desideri aggiungere. Il risultato dell'analisi viene visualizzato direttamente nella richiesta pull in questo modo:

Nel modulo di richiesta pull, puoi vedere immediatamente quali nuovi commenti contiene il codice, la loro criticità, categoria, ecc. I commenti stessi possono essere visualizzati direttamente dal modulo di richiesta pull, basta andare alla scheda Diff.

Pertanto, il processo di revisione del codice è notevolmente accelerato e facilitato, inoltre un numero abbastanza elevato di impostazioni consente una regolazione molto flessibile del comportamento della pipeline sia durante la revisione che nei suoi risultati. Diciamo che la revisione ha avuto successo e possiamo andare avanti.
Il prossimo passo è costruire qualcosa di utile e utile dal nostro codice. Le build iniziano in Bamboo in vari modi. È possibile manualmente, è possibile automaticamente dopo un'unione o un commit nel repository, in base a una pianificazione o in generale tramite una chiamata all'API Bamboo Rest. Per semplicità e chiarezza, consideriamo l'opzione più comune: iniziare l'assemblaggio a mano. Per fare ciò, vai su Bamboo, seleziona il piano desiderato e premi start.
Dopo l'avvio, in base alle dipendenze specificate nel piano, viene selezionato un agente adatto su cui verrà eseguita la build. Al momento abbiamo 30 agenti Windows, 20 agenti Linux, 2 agenti iOS e ne manteniamo altri 5 per esperimenti e piloti. La metà degli agenti è distribuita nel nostro cloud interno, ma ne parleremo più avanti. Questo numero ci consente di servire senza problemi più di 500 piani di build attivi e circa un paio di centinaia di progetti di distribuzione.
Ma torniamo al nostro piano di montaggio. La pipeline supporta tutti i comuni strumenti di compilazione, il cui elenco può essere ampliato con i plug-in.

L'assemblaggio stesso avviene in modo standard: il codice viene salvato nell'agente, compilato in binari lì e compresso nei pacchetti appropriati. Qualsiasi test è opzionalmente connesso, fino alla modularità e all'integrazione. Alla fine della build, otteniamo un bellissimo report contenente molte informazioni utili su quali commit sono stati inseriti nella build, quali test sono stati eseguiti e con quale risultato, quali attività sono state inserite nella build, ecc.

L'artefatto risultante viene automaticamente posizionato nell'Artefatto.

Da un lato, questo sistema viene utilizzato come repository centralizzato degli artefatti che abbiamo raccolto e, dall'altro, tramite Artifactory eseguiamo il proxy della maggior parte dei repository esterni, il che accelera notevolmente il processo di costruzione e riduce il carico sulla rete . Durante la compilazione, ci rivolgiamo ad Artifactory per tutte le dipendenze e non le scarichiamo da repository esterni, il che è molto positivo per la velocità e la stabilità dei piani di compilazione.
Dopo aver inserito un pacchetto in Artifactory, possiamo farci quello che vogliamo, inclusa l'installazione nell'ambiente di cui abbiamo bisogno. In genere, i team utilizzano tre ambienti per creare software. Ambiente di sviluppo: un ambiente di sviluppo utilizzato per lo sviluppo e il debug. Ambiente di test: utilizzato per test funzionali e di integrazione delle applicazioni. Ambiente di anteprima: utilizzato per l'accettazione da parte del cliente di funzionalità e test di carico; di regola, è il più vicino alle condizioni operative. È ancora consuetudine che alcuni team eseguano l'installazione sulla copia di ieri dell'ambiente di produzione prima dell'installazione in produzione, il che aiuta anche a identificare i problemi.
I team, insieme al supporto, decidono chi installa in quali ambienti, e qui usiamo quasi tutte le opzioni. Ci sono team in cui solo gli sviluppatori sono responsabili della distribuzione (ciao DevOps!); ci sono team in cui gli sviluppatori aggiornano solo dev e test e il supporto è preview e prod. Alcuni team generalmente hanno persone dedicate da installare in tutti gli ambienti.
Un progetto distribuito è un insieme di ambienti associati a un piano di compilazione specifico.

L'ambiente contiene variabili di ambiente configurate separatamente per ogni ambiente. Nei commenti all'ultimo articolo, c'era una domanda su come memorizziamo le password. Come puoi vedere nello screenshot, li memorizziamo nei parametri dei piani di build e distribuzione. Bamboo implementa un meccanismo di crittografia della password: basta usare la parola password nel nome di una variabile e verrà crittografata. Dopo il salvataggio, il valore di tale variabile non può più essere visualizzato tramite l'interfaccia o visualizzato nei log di esecuzione, verrà "mascherato" ovunque con asterischi.

Oltre alle variabili, l'ambiente contiene una parte eseguibile, implementata sotto forma di attività, che descrivono un insieme di azioni necessarie per installare un'applicazione sull'host o sugli host di destinazione. L'elenco supporta tutti gli strumenti standard e può essere ampliato con plug-in.

Sulla base dei risultati dell'esecuzione, otteniamo anche un registro di esecuzione dettagliato, con livelli di nidificazione e riferimenti incrociati a attività, commit, build, ecc.

Le installazioni in produzione dovrebbero probabilmente essere discusse separatamente. La banca ha un processo di registrazione delle modifiche (CM), in base al quale tutte le modifiche alla produzione devono essere annunciate e concordate in anticipo. Per registrare le modifiche, il comando avvia una richiesta di gestione delle modifiche (CRQ) almeno tre giorni prima dell'installazione. Tutti i tipi di rapporti di prova sono allegati a questo CRQ e viene formato un elenco impressionante di approvatori. Il processo è piuttosto lento e macchinoso... Ma sfatiamo i miti sull'informatica nelle banche
Abbiamo team che, insieme al business e al supporto, hanno deciso che stanno facendo tutto così bene da essere pronti ad apportare qualsiasi modifica alla produzione in qualsiasi momento, e questo non porterà a conseguenze disastrose. Soprattutto per tali team, è stato inventato un processo di registrazione e approvazione semplificata delle modifiche al sistema di produzione, all'interno del quale è possibile apportare modifiche alla produzione in qualsiasi momento e registrare CRQ dopo che il lavoro è stato eseguito. Ma che tipo di CI / CD è, se hai bisogno di avviare alcune richieste manualmente ... Pertanto, abbiamo scritto il nostro plug-in per Bamboo che ti consente di registrare automaticamente CRQ, che è integrato nel piano di distribuzione.

Ora l'intero processo di registrazione e approvazione delle modifiche richiede diversi minuti e non richiede l'intervento manuale. A proposito, abbiamo già più di una dozzina di team che lavorano su questo nuovo processo e il loro numero è in costante crescita. Quindi, anche in organizzazioni così ingombranti e conservatrici come una banca, è possibile implementare con successo le migliori pratiche dalla sfera IT.
Nelle realtà moderne, parlando del processo di distribuzione, non si può ignorare una cosa come le nuvole. Come abbiamo già scritto, abbiamo un cloud interno basato su VMWare vRealize. Viene utilizzato sia in ambienti non industriali che in produzione. Abbiamo anche integrato il cloud nella pipeline utilizzando un altro nostro plugin. Ora tramite Bamboo possiamo creare o eliminare server nel cloud.

Ad esempio, ricreiamo i server per gli agenti Bamboo sopra menzionati nel cloud ogni due settimane semplicemente avviando un piano di distribuzione che crea il numero richiesto di server, installa su di essi tutto il software necessario, li registra nel sistema di monitoraggio, ecc. Questa operazione richiede circa due ore, e anche allora solo perché sono installate più di cento applicazioni.

Così, grazie alle integrazioni in scatola e un po' di personalizzazione, siamo stati in grado di costruire una pipeline CI/CD in grado di risolvere tutti i compiti. Ma niente sta fermo. Ora noi (come tutta l'umanità progressista) ci stiamo attivamente muovendo verso l'integrazione della pipeline con gli strumenti di chatops, utilizzando container e automatizzando i processi associati alla pipeline stessa.
Nei commenti all'articolo precedente sono state poste una serie di domande che, a nostro avviso, non hanno nulla a che vedere né con CI/CD né con la pipeline. Quindi risponderemo loro in un formato di domanda e risposta. Probabilmente troverai le risposte monotone. Ma la banca ha più di 700 applicazioni scritte in tempi diversi, per diversi sistemi operativi e utilizzando tecnologie diverse, quindi è impossibile dare una risposta definitiva, nella maggior parte dei casi tutto è determinato dall'applicazione e dal suo team.
Quali schemi di distribuzione vengono utilizzati? (verde/blu, rolling, canarino, ecc.). E se hai bisogno di tornare indietro?
Dipende dall'applicazione specifica. Per quanto ne so, ci sono sicuramente verde/blu e rotolamento, non sono sicuro del resto. I team scelgono da soli la migliore opzione di distribuzione. Se è necessario eseguire il rollback ed è possibile, eseguire il rollback.
Come e da chi viene effettuata una distribuzione di successo? In base a quali parametri?
Non è del tutto chiaro di cosa si tratti. Se riguarda il processo di distribuzione stesso, la decisione viene presa da Bamboo Il piano ha funzionato senza errori - beh, non ha funzionato - un errore. Se la domanda riguarda il componente funzionale delle modifiche installate, la decisione viene presa dai clienti aziendali durante il test del fumo dopo l'installazione.
E se il carico aumenta? È facile aggiungere più server per supportare il carico? C'è la scalabilità automatica?
Dipende dall'applicazione e da molti, molti altri fattori, come sempre quando si tratta di caricare. La scalabilità automatica non viene utilizzata.
Ogni nuova distribuzione viene eseguita su server appena creati o sugli stessi?
Dipende dall'applicazione. Il nostro team ricostruisce i server ogni due settimane e ne distribuiamo solo di nuovi. Gli altri team si distribuiscono sempre sugli stessi server. I team scelgono il proprio approccio.
E le patch del sistema operativo?
Dipende dall'applicazione, dal sistema operativo e dall'aggiornamento. Ma, alla fine, abbiamo tutte le correzioni critiche installate e non ci sono vulnerabilità.
Che dire del monitoraggio e delle metriche di applicazioni e sistemi (SO)?
L'argomento del monitoraggio merita un ampio articolo separato, che, forse, sarà scritto dai nostri specialisti del monitoraggio. Posso dire che c'è monitoraggio, gli avvisi funzionano, gli incidenti vengono registrati ed elaborati, parte dell'elaborazione è automatizzata.
Cosa usi per bilanciare il carico tra le copie delle applicazioni? nginx / haproxy / ecc?
Dipende dall'applicazione Ci sono nginx, haproxy e NLB e iron Cisco.