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

Distribuisci sul lato sviluppatore: come abbiamo costruito Heroku per esigenze interne

Oggi vogliamo parlare delle complessità della distribuzione in un ambiente in cui è necessario distribuire regolarmente un gran numero di servizi, sia nella produzione che nei componenti dell'infrastruttura. Noi di Uchi.ru un tempo abbiamo dovuto affrontare la necessità di semplificare il più possibile la procedura di distribuzione in modo che quasi tutti gli sviluppatori potessero gestirla. Abbiamo creato una soluzione che si è rivelata conveniente e con la quale continueremo a convivere fino a quando non la supereremo completamente. Come funziona, quali difficoltà sorgono, leggi sotto il taglio.

Gli sviluppatori possono distribuire i servizi da soli e devono farlo? Queste domande vengono poste attivamente in molte aziende e anche negli stessi specialisti. Di recente mi sono imbattuto in un post che discuteva attivamente dell'impatto negativo dell'elevato carico di lavoro e di un'ampia gamma di responsabilità sugli sviluppatori.

In un'azienda delle dimensioni di un team, ogni membro di solito ha molti compiti, e questo va bene. Tuttavia, con la crescita del business e la complessità del prodotto, la specializzazione di ogni persona si restringe. Naturalmente, una specializzazione ristretta non significa che non sia necessario conoscere altro al di fuori dell'area di competenza. Ma è anche impossibile sovraccaricare gli sviluppatori, soprattutto se comporta rischi per la stabilità del sistema.

Pertanto, a nostro avviso, la risposta alla domanda "Gli sviluppatori dovrebbero implementare?" dipende dalla complessità del processo. Se distribuisci regolarmente aggiornamenti per lo stesso numero di sistemi di Uchi.ru (tenendo conto di tutte le infrastrutture e soluzioni di servizio, produzione di marchi russi, anglofoni e di altre lingue straniere, abbiamo più di cento applicazioni, che , in media, hanno più rilasci ogni giorno), il processo di implementazione dovrebbe essere semplificato il più possibile, pur rimanendo nel quadro dei requisiti per la sicurezza e l'integrità dei servizi.

Solo se il processo è semplificato a tal punto che il 95% dei rollout non richiede alcuna conoscenza speciale, puoi affidare la distribuzione agli sviluppatori. L'abbiamo presa per noi come una soluzione temporanea, che era (e rimane per molti versi) necessaria e utile in una certa fase dello sviluppo dell'azienda. Ma anche in questo caso, è necessario tenere il passo con il polso, il che implica la possibilità in qualsiasi momento di connettersi alla domanda di quelle persone che hanno questa conoscenza molto speciale. Considerando che tale esperienza può essere utile per le aziende in crescita, ti diremo come è stato risolto questo problema in Uchi.ru.

Spostandoci dai binari Ruby standard

Fin dall'inizio, abbiamo utilizzato e ancora attivamente sviluppiamo in Ruby on Rails. Lo strumento di distribuzione standard nell'era pre-contenitore era Capistrano, in generale un insieme di script che si collegano a server remoti ed eseguono i passaggi necessari per la distribuzione: scaricare le modifiche dal repository, ricostruire le statistiche, riavviare il server Web e così via su ogni ospite.

L'approccio è assolutamente normale (ci conviviamo da diversi anni), e si giustifica pienamente per squadre di piccole e medie dimensioni. Ma con la crescita del numero di sviluppatori, del numero di server utilizzati e con il passaggio a lavorare in un cluster, sorgono vari ostacoli.

Ad esempio, con l'aumentare delle implementazioni, è emerso un altro svantaggio di Capistrano. Durante la distribuzione lato client, si è rivelato difficile garantire la correttezza dello script in ogni caso specifico.
Nello stesso periodo, siamo giunti alla necessità di impacchettare le nostre applicazioni con tutte le loro dipendenze in contenitori.

La prima fase della transizione può essere definita una sorta di simbiosi di queste tecnologie: uno script molto simile a Capistrano, che raccoglie un'immagine docker nel cloud e la distribuisce agli host. Certo, questa è una soluzione intermedia, ma ci ha permesso di assicurarci di poter confezionare un'applicazione solida in un contenitore e che funzionerà come prima.

I container nel cloud dovevano essere monitorati: c'era bisogno di clustering e allocazione delle risorse. Per questo abbiamo scelto l'Hashicorp Nomad Orchestrator. Tornando alla domanda all'inizio dell'articolo: gli sviluppatori avevano bisogno di un'interfaccia semplice per implementare nuove funzionalità, quindi la parte dell'interfaccia relativa alla gestione dei server e del cluster docker è stata nascosta. Ma in quel momento non c'erano risorse per un team separato di ingegneri sul campo. È così che è nata l'idea di semplificare il più possibile il processo di distribuzione in modo che fosse disponibile per ogni sviluppatore, e si è verificata completamente anche sul lato server dopo aver premuto il pulsante.

Piattaforma propria

I servizi di Heroku ci hanno ispirato all'idea della distribuzione automatica. Quando ottieni un'istanza nel cloud Amazon, lavori con l'infrastruttura (IaaS) e quando ti rivolgi a Heroku, lavori con la piattaforma (PaaS). Per un po', Heroku è stato il punto di riferimento per il passaggio a implementazioni automatizzate nel cloud. Quando lavori con Heroku, non hai bisogno di ingegneri di rilascio, perché il software viene distribuito automaticamente. Tuttavia, l'hosting di applicazioni di qualsiasi dimensione decente in soluzioni PaaS come Heroku è già abbastanza indecente.

Pertanto, abbiamo deciso di creare la nostra piattaforma per un'esecuzione semplificata di container docker nella nostra infrastruttura. Di conseguenza, è stato creato un frontend per Nomad, che ha svolto le seguenti attività:

  • la massima riduzione del numero di "twist" per lo sviluppatore, esclusi i momenti non ovvi, nonché i valori universali per i nostri cloud;
  • trasferimento del lancio della distribuzione dai laptop al cloud;
  • gestione della configurazione;
  • gestione dei segreti.

Lo strumento creato si chiamava Shaman e lo usiamo ancora. Lui, ovviamente, è tutt'altro che ideale. Ad esempio, Heroku ha una completa astrazione del lavoro con i data warehouse. La configurazione lì funziona anche meglio della nostra, almeno in termini di esperienza utente.

Immagine

Ma Shaman, progettato per noi stessi, soddisfa le esigenze specifiche dell'azienda. È orientato alla creazione rapida di un'applicazione che si inserisca immediatamente nell'intera infrastruttura: monitoraggio, routing, mesh di servizi .

Immagine

Shaman differisce da altre soluzioni CI / CD in quanto non è praticamente necessario configurare il processo di distribuzione stesso, le nuove versioni vengono implementate secondo lo stesso script hard-coded. Questo strumento è il più conveniente e comprensibile per lo sviluppatore. Pertanto, invece di scegliere le pipeline di consegna della produzione e altri parametri in Shaman, devi solo guidare i valori desiderati nell'insieme di campi e fare clic sul pulsante verde.

I problemi? Noi decidiamo!

Usando Shaman, gli sviluppatori distribuiscono sia le loro applicazioni che vari software ausiliari: archivi di dati, bus, cache. Puoi distribuire qualsiasi cosa per cui è presente un'immagine docker. E nel 95% dei casi non serve l'intervento di “persone speciali” per schierare un altro, diciamo, Redis.

Immagine

Per il restante 5%, ci sono diverse opzioni:

In caso di problemi con l'hardware, il team della piattaforma si connette immediatamente alla soluzione. A causa del monitoraggio configurato, di solito veniamo a conoscenza delle difficoltà anche prima della richiesta dello sviluppatore e aiutiamo a farvi fronte il più rapidamente possibile.

Quando si verificano problemi con l'assemblaggio dell'applicazione (il processo non è ancora ideale e i bug sono possibili), molto spesso qualcuno del team dell'infrastruttura viene in soccorso, principalmente gli stessi sviluppatori Shaman.

E in caso di problemi con il codice non rilevati dai test, l'applicazione verrà restituita allo sviluppatore. La distribuzione automatizzata in Uchi.ru è progettata in modo tale che se si verifica un errore critico, l'aggiornamento si interromperà immediatamente. Allo stesso tempo, il traffico degli utenti non va a contenitori "cattivi".

Immagine

In generale, il ripristino più rapido è possibile per la maggior parte dei problemi. Per questo, viene fornito un meccanismo per il rollback alla versione precedente dell'applicazione. Questo può essere fatto in pochi minuti cambiando il tag dell'immagine della finestra mobile con uno più vecchio. Le immagini non vengono eliminate dai registri per un po' di tempo.

Basta premere un pulsante

Poiché Shaman è il nostro sistema interno, non ci siamo preoccupati troppo dell'involucro del prodotto. Se fosse un prodotto, sarebbe possibile lavorare ulteriormente sulla sua usabilità, migliorare l'interfaccia e scrivere istruzioni aggiuntive. Ma nel nostro caso, è sufficiente che in termini di distribuzione, tutto sia fatto in modo molto semplice. Dopo un breve briefing, la stragrande maggioranza degli sviluppatori che non sanno nulla della distribuzione può fare clic sul pulsante verde e il sistema stesso farà ciò che è necessario.

Pertanto, i nostri sviluppatori non ricevono ulteriori responsabilità allo stesso tempo, ma possono distribuire facilmente e facilmente servizi aggiornati da soli, sul lato server e secondo lo schema standard. Considerando che possiamo lanciare diverse dozzine di aggiornamenti al giorno in modalità normale e l'intero ecosistema Uchi.ru ha più di cento componenti, tutto ciò porta a un grande risparmio di tempo e senza la partecipazione dei tecnici di rilascio.

A proposito, sarebbe molto interessante sapere se pratichi la distribuzione indipendente nella produzione, come viene implementata nella tua azienda e anche quali pro e contro di questo processo sono visibili dalla tua parte. Lo scambio di esperienze in questa materia è molto importante, perché aiuta a stabilire condizioni di lavoro ottimali per gli sviluppatori.