Qualche idea su come eseguire la manutenzione su un sito sempre in uso?

Sono d'aiuto con un grande sito di gioco in Australia. Organizziamo gare dalle 7:00 ora locale all'01: 00 del giorno successivo, tutti i giorni della settimana. Non saltiamo un giorno da quando il sito è stato rilasciato. Naturalmente, ciò rende la manutenzione estremamente difficile da eseguire e scopriamo che il nostro server di gestione temporanea ha fino a 50 commit prima del nostro ramo di produzione. Di solito, lo sviluppatore principale deve svegliarsi molto presto per unire i rami e assicurarsi che tutto funzioni correttamente.

Abbiamo cercato di rendere il nostro sito di staging il più simile possibile al sito di produzione, ma possiamo solo renderlo così simile.

Il nostro sito si basa su Laravel con un server Node.JS per tempo reale. Stiamo usando Laravel Forge.

Qualcuno ha qualche suggerimento su come potremmo inviare gli aggiornamenti più frequentemente? Siamo disponibili per ogni cosa.

Ci sono molte cose che potresti fare per migliorare il processo di implementazione. Alcuni di essi sono:

• Assicurati che il tuo codice sia ben testato.

  Idealmente, si dovrebbe avere una copertura unitaria del 100%, nonché test di integrazione per ogni scenario immaginabile.

  Se non lo hai, probabilmente dovresti lasciare tutto e occupartene.

  Analizza lo sviluppo guidato dal comportamento.

  Avere una suite di test completa ti permetterà di ...

• Esegui l'integrazione continua.

  Ogni volta che qualcuno commette una modifica, CI può quindi eseguire automaticamente la suite di test su di essa. Se la suite di test ha esito positivo, può quindi implementare immediatamente (o pianificare una distribuzione). Per le modifiche che non richiedono modifiche significative ai database, questo da solo ti farà risparmiare un sacco di tempo e mal di testa.

  In caso di problemi, CI può anche fornire un rollback con un clic.

  L'IC è molto meno utile se la suite di test non è completa e corretta, poiché l'intera premessa si basa sulla capacità di convalidare il codice in modo automatizzato.

• Effettua aggiornamenti atomici.

  Idealmente, non dovresti semplicemente copiare nuovi file sul vecchio sul server di produzione. Utilizzare invece uno strumento come capistrano, che copia ogni file in una nuova posizione e quindi utilizza un collegamento simbolico per puntare alla distribuzione desiderata. Il rollback è istantaneo in quanto comporta semplicemente la modifica del collegamento simbolico per puntare alla distribuzione precedente. (Anche se questo non copre necessariamente la migrazione del database.)

  Verifica anche se contenitori come Docker possono aiutarti.

• Apporta modifiche più piccole e più frequenti.

  Che tu abbia test, CI o niente, questo da solo può aiutarti in modo significativo. Ogni modifica dovrebbe avere il proprio ramo git e una distribuzione dovrebbe avere il minor numero possibile di modifiche. Poiché le modifiche sono più piccole, è meno probabile che si verifichino errori durante una distribuzione.

  In tale nota, rendere le modifiche più isolate quando possibile. Se hai apportato una modifica al gioco Omaha e non influisce su Texas Hold'em, 5 carte stud o altro, questo è l'unico gioco che deve essere sospeso per una manutenzione.

• Analizza qualsiasi cosa di lunga durata.

  Alcune parti delle distribuzioni sono state menzionate per molto tempo. Probabilmente si tratta di modifiche allo schema del database. Vale la pena dare un'occhiata al tuo database DBA, insieme a ogni modifica dello schema, per vedere cosa può funzionare meglio.

  Chiedi a un esperto in materia di esaminare qualsiasi altra parte di una distribuzione che richiede grandi blocchi di tempo.

• Lavora ore dispari.

  Forse lo stai già facendo, ma vale la pena menzionarlo. Gli sviluppatori (e gli amministratori di sistema!) Non dovrebbero più aspettarsi di lavorare "da 9 a 5", specialmente per un'operazione 24x7. Se si prevede che qualcuno trascorra le ore della notte facendo da babysitter a una distribuzione, risolvendo eventuali problemi e quindi mantenendo un programma diurno, le tue aspettative non sono realistiche e stai preparando quella persona per il burnout.

Sembra da quello che dici che hai una finestra di manutenzione dalle 1 alle 7 ogni giorno il problema non è tempo ma convenienza. Questo è normale e molte persone lo affrontano solo come parte del business.

Potresti avere un 2 (o più back-end) con un front-end che indirizza il traffico verso qualunque sia attualmente attivo. Una volta che sei felice che una versione funzioni, dici al front-end di passare al nuovo sistema. questo dovrebbe essere facile da scrivere in poco tempo.

Ora puoi scegliere di lasciare il vecchio sistema così com'è, così puoi tornare indietro o aggiornarlo in modo che possa essere usato come ricambio per il sistema live fino al momento di costruire / testare i prossimi aggiornamenti.

Modifica delle altre risposte: è necessario seguire il modello di distribuzione blu-verde . Quando si desidera rilasciare una nuova versione, la si distribuisce in un sito Web di gestione temporanea interno. Quindi, è possibile eseguire test automatici sul sito di produzione della versione successiva. Quando i test vengono eseguiti, l'utente punta il bilanciamento del carico per utilizzare il nuovo sito Web.

Questo aiuta nel modo seguente:

1. Si riscontrano sempre gravi problemi con tempi di inattività pari a zero.
2. Il passaggio a una nuova versione ha esattamente zero tempi di inattività perché la nuova versione è già stata avviata e riscaldata.
3. Puoi tornare alla versione precedente in qualsiasi momento perché è ancora fisicamente in esecuzione.

Tutti gli altri problemi citati da te e dagli altri diventano meno gravi quando è possibile implementare in qualsiasi momento in modo privo di stress. Il modello di distribuzione blu-verde è una soluzione abbastanza completa per i problemi di distribuzione.

Cosa farai se il tuo data center principale subisce un'interruzione, che di tanto in tanto si verifica in tutti i data center? Potresti accettare i tempi di inattività, potresti eseguire il failover su un altro data center, potresti essere sempre in esecuzione in modalità active-active in più data center o potresti avere qualche altro piano. Qualunque sia uno di questi, fallo quando esegui i rilasci, quindi puoi rimuovere il tuo data center principale durante un rilascio. Se sei pronto ad avere tempi di inattività quando il tuo data center ha un'interruzione, allora sei pronto ad avere tempi di inattività, quindi non dovrebbe essere un problema durante un rilascio.

Per aggiungere alle risposte precedenti:

• Utilizzare una strategia di distribuzione che consenta il rollback e il passaggio istantaneo, Capistrano o praticamente qualsiasi altro sistema di distribuzione aiuterà in questo. È possibile utilizzare elementi come snapshot di database e collegamenti simbolici di codice per poter tornare rapidamente a uno stato precedente.

• Utilizza la gestione completa della configurazione, non lasciare nulla gestito manualmente. Sistemi come SaltStack, Ansible e Puppet sono esempi. Possono essere applicati anche alle configurazioni del contenitore Docker e alle scatole vagabonde.

• Utilizzare HA per assicurarsi di poter distribuire le richieste durante l'aggiornamento di un nodo. Se l'aggiornamento non riesce, semplicemente giù per il nodo e quando viene ripristinato, ripristinalo e la tua soluzione HA noterà e invierà nuovamente le richieste a detto nodo. HAProxy è un esempio, ma anche nginx funziona bene.

• Assicurati che l'applicazione sia in grado di gestire istanze simultanee, utilizza repository di dati con versione centralizzata per i dati non di codice che devono essere archiviati su disco, come la cache. In questo modo, non sarà mai possibile eseguire l'applicazione aggiornata per memorizzare nella cache i file da una versione diversa. Ciò verrebbe fatto in aggiunta all'eliminazione delle cache e ovviamente al riscaldamento della cache. (La cosa della cache è solo un esempio)

Di solito imposto flussi di lavoro in cui i team manager possono approvare le richieste di unione in un ramo speciale che esegue tutte le normali operazioni di CI, ma come ultimo passaggio aggiuntivo inizia anche a passare ai nodi di produzione. In pratica, esegui una distribuzione CI manuale in un'istanza di produzione. Se tale istanza non genera risposte non valide, interruzioni o azioni strane sui tuoi dati, esegui l'upgrade di massa di tutti i nodi utilizzando la tua soluzione di scelta rapida CI. In questo modo, se una distribuzione funziona, sai che tutte le distribuzioni funzioneranno per un tag / commit specifico.

In questo momento, sembra che si stia eseguendo un'applicazione di produzione su un singolo nodo, con un processo di distribuzione, un'origine e una destinazione. Ciò significa praticamente che ogni singolo passaggio di quel flusso di lavoro è un punto di errore che di per sé può interrompere il sito Web. Garantire che una cosa del genere non possa accadere è la base di tutti i processi di CI, HA e failover. Non eseguire solo un nodo, non eseguire solo un processo HA, non eseguire solo un indirizzo IP, non eseguire solo un CDN ecc. Potrebbe sembrare costoso, ma mettere un duplicato di ciò che già si possiede in un rack su un server con la propria connessione di solito costa meno di un'ora di inattività in un sito aziendale.

Concordo globalmente con Michael su ciascuno dei suoi punti ( /server//a/739449/309477 ).

Secondo me, il primo miglioramento che dovresti fare è usare uno strumento di distribuzione (Capistrano).

Ti consentirà di distribuire in modo pacifico, quindi passare immediatamente alla versione più recente. Se qualcosa va storto, puoi tornare immediatamente alla versione funzionante, semplicemente cambiando il link corrente in una versione funzionante.

E Capistrano è piuttosto veloce da gestire per primo (rispetto a iniziare a usare test e CI che saranno un investimento di tempo maggiore).

In secondo luogo, se il denaro non è il problema principale , è necessario disporre di un server di sviluppo iso-prod per testare l'app prima di distribuirla in produzione. Utilizzare una soluzione industriale (Ansible, Chef, Puppet) per gestire le istanze VPS.