Distribuzione del codice su più server front-end

Abbiamo una situazione in cui abbiamo più server con bilanciamento del carico che puntano a un database comune.

Nel normale corso delle cose questo funziona bene e dà ridondanza, scalabilità ecc.

Tuttavia, la distribuzione è un po 'noiosa.

Stiamo utilizzando ampiamente le funzionalità e stiamo cercando di automatizzare la distribuzione. La distribuzione al momento non è molto affidabile.

In una forma semplificata, lo script di distribuzione per ciascun server ha due fasi

1. Aggiorna file

2. Ripristina funzionalità (che gestirà dipendenze, modifiche alle impostazioni ecc.)

Esistono best practice per la distribuzione su più server senza causare uno stato incoerente?

Per quanto posso vedere se distribuisci i passaggi 1 e 2 sul server A, il server B si interromperà, se provi il passaggio 1 su entrambi i server prima di procedere al passaggio 2, entrambi verranno interrotti per un po '.

Probabilmente dovresti esaminare Aegir , che è di gran lunga il sistema di gestione / implementazione del sito Drupal più flessibile e potente. È in grado di gestire "piattaforme" che si estendono su più web head o "cluster", nonché una varietà di altre configurazioni.

Suggerirei di leggere la documentazione della loro comunità che è generalmente abbastanza buona, così come leggere l'eccellente panoramica e l'articolo introduttivo di mig5 e alcuni dei suoi altri articoli come questo .

Puoi anche ottenere un buon supporto nel canale IRC #aegir.

Sarà un po 'un cambiamento nel flusso di lavoro, che può sicuramente richiedere del tempo per girare la testa, ma una volta che sei lì non ti guarderai indietro.

Nella nostra azienda manteniamo MOLTI siti Drupal, la nostra configurazione attuale va in questo modo:

• La base di codice di ogni sito ha il proprio repository git
• Le nuove funzionalità che probabilmente non saranno abbastanza stabili per la prossima versione ottengono il loro ramo di funzionalità in git

Quanto sopra direi che è abbastanza comune per la maggior parte dei siti Drupal.

Quello che facciamo di speciale nella nostra azienda è il pacchetto debian dei siti per l'implementazione usando un comando drush personalizzato - ' Drush Debian Packaging '.

Drush Debian Packaging fornisce un comando Drush per la creazione di pacchetti Debian di siti Drupal come mezzo per distribuire siti Drupal su server Debian o Ubuntu.

Drush Debian Packaging utilizza il sistema di hook di Drupal per creare un pacchetto Debian più adatto alle esigenze dei tuoi siti. Le caratteristiche includono:

• Configurazione automatica dell'host virtuale per i server web Apache2 e Nginx
• Cron setup in /etc/cron.d
• Distribuzione automatica del codice con divisione delle partizioni per siti / default / file
• Configurazione automatizzata tramite lo strumento delle impostazioni di debponf di dpkg
• Processo di distribuzione automatizzato
• gestore Git VCS personalizzato per la creazione di pacchetti da Git

Cosa significa questo?

Per creare una versione:

cd /path/to/drupal-root
drush dh-make

Per distribuire una versione, innanzitutto SCP .deb su tutti i server Web nel cluster. Quindi su tutti i server Web in esecuzione (è possibile utilizzare il pacchetto linux cssh per digitare il comando su tutti i server della farm contemporaneamente):

sudo dpkg -i drupal-site-yoursitehere.2011.05.25-1.all.deb

Su un server Web eseguito:

cd /path/to/drupal-root
sudo -u drupal-site-yoursitehere drush updb && drush fra -y && drush cron

Fatto

Ovviamente ripristinare questo è ora banale dal punto di vista della base di codice, è sufficiente installare la versione precedente di .deb su tutti i server Web e ripristinare il database.

Felice di rispondere a qualsiasi domanda al riguardo

Quale parte del processo di distribuzione è un lavoro ingrato / inaffidabile?

Se si tratta del problema "aggiorna server A quindi B / incoerenza", che ne dici di installare la pagina di manutenzione per la durata delle tue spinte? Pagina di manutenzione su, aggiorna il codice su entrambi i web head, esegui update.php su uno di essi, pagina di manutenzione giù. È abbastanza facilmente programmabile.

Un'altra opzione: a seconda del tipo di sito che si esegue, è possibile creare una "modalità di sola lettura" che elimina tutti gli utenti offline e disabilita l'accesso / registrazione. Clona il tuo DB su un secondo DB nella stessa casella db, clona il tuo front-end su un nuovo docroot, esegui gli aggiornamenti lì, quindi collega il docroot di Apache al nuovo docroot di front-end. Il flusso di lavoro è simile a:

1. Modalità sola lettura attivata
2. SELEZIONA current_db INTO new_db
3. cp -R current_docroot new_docroot
4. new.yourdomain.com ==> / new_docroot
5. aggiorna il codice in new_docroot
6. update.php
7. symlink / new_docroot ==> current_docroot
8. Modalità di sola lettura disattivata.

Dipenderà dalle modifiche che stai apportando, come suggerisce Entendu. Quale percentuale di aggiornamenti di codice può essere eseguita senza causare errori se il database non è ancora aggiornato? Per tutto ciò che non dipende dagli aggiornamenti del database (e forse puoi cambiare un po 'il processo di sviluppo per renderlo più comune) non c'è davvero niente di speciale da fare. Suppongo che tu voglia eseguire implementazioni con tempi di inattività minimi, altrimenti ciò richiederebbe solo alcune operazioni di sincronizzazione di base. In questo caso ci sarà sempre qualche finestra temporale con effetti indesiderati (anche se il sito è in sola lettura) ma penso che potrebbe essere abbastanza piccolo per la maggior parte del tempo.

Puoi fare l'ottimizzazione di base come impostare una "nuova" directory su ciascun server in anticipo e poi cambiarli tutti per puntare contemporaneamente alla nuova directory (magari usando i collegamenti simbolici come nella risposta di Entendu) in modo da poter ottenere tutti i i server sono passati ai nuovi file entro 5-10 secondi.

Ciò lascia il problema degli aggiornamenti del database. Se sono del tipo che deve essere fatto da un solo server, potresti voler mettere gli altri in modalità di manutenzione o regolare il bilanciamento del carico per non usarli mentre ciò accade. Ovviamente se non possono essere eseguiti mentre gli utenti sono attivi sul sito, dovrai solo avere tutto in modalità di manutenzione, ma per semplici aggiornamenti questo potrebbe essere qualcosa che puoi fare in circa 30 secondi o meno.

Potrebbe valere la pena avere diversi script di distribuzione per diversi tipi di modifiche, quindi è possibile eseguire il processo minimo necessario, sia che si tratti di copiare file, eseguire un piccolo aggiornamento del database o apportare una modifica sostanziale al database.

Se riesci a ottimizzare i tuoi aggiornamenti di file e database e vedi se ci sono semplici modifiche che puoi apportare al modo in cui le cose vengono sviluppate, ciò potrebbe portarti più vicino ma non so se nulla di tutto ciò sia nuovo per te :)

Aegir è utile per gestire una rete di siti. L'ho usato per distribuire e gestire oltre 2000 siti per un singolo client.

La tua domanda suggerisce che desideri gestire un singolo sito con più webhead. In tal caso, Aegir potrebbe essere meno utile per te. Invece suggerirei di guardare usando un file system che supporta la rete. Questo non solo garantisce che il codice sia mantenuto sincronizzato, ma significa che i tuoi caricamenti sono disponibili su tutti i nodi.

Storicamente le persone hanno usato NFS che consente di condividere il file system di un server con altri nodi. Sfortunatamente questo introduce un singolo punto di errore, perché se il server NFS si blocca o muore il tuo sito non può essere servito.

Se sei disposto a scendere a compromessi sulle prestazioni di io in favore di un server più affidabile, consiglierei GlusterFS . Ho usato in alcuni ambienti di produzione. Non è perfetto ma è meglio di NFS. Gluster consente al webhead di leggere sempre localmente e le scritture vengono quindi replicate negli altri nodi.

In termini di strategia di implementazione dovresti avere drush come primo strumento sulla tua lista. Con drush dovresti essere in grado di automatizzare i passaggi della distribuzione. Dovresti prendere in considerazione l'aggiunta di Jenkins al mix in modo da poter tracciare i tuoi processi di distribuzione e identificare i modelli se le cose falliscono. Capistrano può essere utile per automatizzare le fasi coinvolte nella distribuzione. Se fai le cose correttamente puoi farlo in modo che i tuoi utenti non sappiano nemmeno che hai fatto una distribuzione.