Distribuire il nuovo codice in tempo reale

Qual è la migliore pratica per distribuire un nuovo codice su un sito live (e-commerce)?

Per ora ho smesso di apache per +/- 10 secondi quando ho rinominato directory public_html_newin public_htmle vecchio a public_html_old. Questo crea un breve tempo di inattività, prima di riavviare Apache.

La stessa domanda vale se si utilizza Git per estrarre il nuovo repository nella directory live. Posso estrarre il repository mentre il sito è attivo? E se avessi bisogno di copiare anche un DB?

Durante la compressione tar (scopo di backup) del sito live ho notato che si sono verificati cambiamenti nella directory multimediale. Ciò mi ha indicato che i file continuano a cambiare periodicamente. E se queste modifiche possono interferire se Apache non viene arrestato durante la distribuzione.

L'uso di un bilanciamento del carico è una buona idea. Se il sito è abbastanza importante da preoccuparsi di alcuni secondi di inattività, è abbastanza importante preoccuparsi della tolleranza agli errori.

A parte questo, se questo è su un sistema UNIX, puoi mettere in attesa Apache durante la ridenominazione (o l'aggiornamento del collegamento simbolico, ecc.):

killall -STOP httpd  # Pause all httpd processes
mv public_html public_html_orig
mv public_html_new public_html
killall -CONT httpd  # Resume all httpd processes

Ciò impedirà ad Apache di accettare nuove richieste durante la ridenominazione. Se preferisci i symlink o qualche altro approccio, puoi usare la stessa idea:

killall -STOP httpd  # Pause all httpd processes
rm /var/www/html
ln -s /var/www/version/03 /var/www/html
killall -CONT httpd  # Resume all httpd processes

Si noti che eventuali connessioni o pacchetti in sospeso verranno messi in coda nel sistema operativo. Per un sito estremamente occupato, considerare l'ottimizzazione di ListenBacklog, se appropriato per il tipo di lavoratore httpd, e controllare le impostazioni del sistema operativo relative al backlog di ascolto TCP.

È inoltre possibile modificare DocumentRoot in httpd.conf ed eseguire un riavvio grazioso ( apachectl graceful). Lo svantaggio qui è l'aumento del rischio di errori, dal momento che dovresti aggiornare anche qualsiasi Directoryconfigurazione.

Il più semplice e veloce è usare una directory di versione come

/var/www/version/01
/var/www/version/02

e usa un link simbolico corrente come html_root:

/var/www/html -> /var/www/version/02

Questa tecnica si integra perfettamente in un sistema di controllo delle revisioni (svn, git, mercurial, ...) poiché puoi controllare rami e tag, modificare il collegamento simbolico e ricaricare Apache. Il tempo di inattività è minimo utilizzando questa tecnica e consente un rollback molto semplice .

Si integra bene anche con un sistema di distribuzione più complesso come pacchetti RPM o infrastruttura di gestione delle modifiche alla configurazione (cuoco, pupazzo, ecc.).

Anche la ridenominazione delle directory senza chiudere Apache dovrebbe funzionare. Ciò ridurrà significativamente la finestra. mv public_html public_html_old && mv public_html_new public_htmldovrebbe finire in una frazione di secondo.

Un paio di inconvenienti sono che questo approccio darà una risposta 404a qualsiasi richiesta che riesca ancora ad accadere durante la finestra. E se si esegue il comando sopra senza avere una public_html_newdirectory fallirà e ti lascerà con un sito che dà 404su ogni richiesta.

Farlo atomicamente con le directory non è supportato. Ma potresti farlo con i collegamenti simbolici. Invece di avere una directory denominata public_html, avere una directory denominata public_html.version-numbere un link simbolico chiamato che public_htmlpunta a quella directory. Ora puoi creare una directory chiamata public_html.new-version-numbere un nuovo symlink chiamato public_html.new.

Poi si può rinominare public_html.newa public_htmlpassare atomicamente. Si noti che mvè "troppo intelligente" per eseguire tale ridenominazione, ma potrebbe essere fatto utilizzando os.renameda Python o qualsiasi altra cosa che chiamerà ilrename chiamata di sistema senza cercare di essere intelligente.

Cosa fare con il database dipende dal database che si sta utilizzando e da cosa lo si sta utilizzando. Devi fornire molti più dettagli sul database prima di poterti dare una buona risposta a quella parte della tua domanda.

Symlink e mv sono i tuoi amici, tuttavia, se hai davvero bisogno di evitare che gli utenti finali ricevano una pagina di errore durante la distribuzione di una nuova versione, dovresti avere un proxy inverso o un bilanciamento del carico davanti ad almeno 2 server back-end (apache nel tuo caso).

Durante la distribuzione, è sufficiente arrestare un back-end alla volta, distribuire il nuovo codice, riavviarlo e quindi scorrere i restanti back-end.

Gli utenti finali saranno sempre indirizzati a buoni backend dal proxy.

Se si applicano regolarmente modifiche su un sistema di produzione, mi occuperei di un ciclo di vita strutturato. Una buona pratica è Capistrano http://capistranorb.com/ . Questa è una soluzione open source per la distribuzione di software su uno o più server su più piattaforme e configurazioni.

Per Magento esiste persino un plugin: https://github.com/augustash/capistrano-ash/wiki/Magento-Example

Per i singoli server e le transizioni quasi senza soluzione di continuità, consiglio di utilizzare i collegamenti simbolici.

Il modo in cui lo faccio è eseguire il commit delle mie modifiche dal mio ambiente di sviluppo locale a un repository Git online come Github. Il mio ambiente di produzione esegue un repository remoto, quindi tutto ciò che devo fare è ssh sul server ed eseguire git pullper annullare le ultime modifiche. Non è necessario arrestare il tuo server web.

Se nel progetto sono presenti file le cui impostazioni e / o contenuti differiscono dalla versione locale (come file di configurazione e caricamenti multimediali), è possibile utilizzare le variabili di ambiente e / o aggiungere questi file / directory a un .gitignorefile per impedire la sincronizzazione con il repository.

La mia prima idea è:

# deploy into public_html_new, and then:
rsync -vaH --delete public_html_new/ public_html/

Una buona soluzione era usare rsync. Ha cambiato solo i file realmente cambiati. Attenzione, le barre alla fine dei percorsi sono importanti.

Normalmente Apache non ha bisogno di un riavvio, non è il mondo Java. Controlla la modifica di ogni file php su richiesta e rilegge (e ri-tokenizza) la modifica automaticamente.

Git pull era simile, anche se era un po 'più difficile da scrivere. Ovviamente ha consentito un ampio spettro di diverse possibilità di rilevamento di fusioni / modifiche.

Questa soluzione funzionerà senza problemi solo se non ci sono cambiamenti davvero importanti - se ci sono grandi cambiamenti nella distribuzione, un po 'di pericolo non può essere chiuso, perché c'è un intervallo di tempo non trascurabile, quando il codice verrà parzialmente modificato e parzialmente no.

Se ci sono grandi cambiamenti, il mio suggerimento era la soluzione iniziale (due rinominare).

Ecco una soluzione atomica un po 'hardcore, ma al 100%:

(1) fai un mount alternativo del tuo filesystem, dove si svolge il tuo magento:

mount /dev/sdXY /mnt/tmp

(2) fai un --bindmount del tuo public_html_new in public_html:

mount --bind /path/to/public_html_new /path/to/public_html

Da questo punto, l'apache vedrà la tua nuova distribuzione. Qualsiasi cambiamento di 404 è impossibile.

(3) esegui la sincronizzazione con rsync, ma sul punto di montaggio alternativo):

rsync -vaH --delete /mnt/tmp/path/to/public_html_new/ /mnt/tmp/path/to/public_html/

(4) rimuovere il supporto di rilegatura

umount /path/to/public_html

Spostare / sostituire la http_publiccartella può essere ottenuto con semplice mvoln -s comandi o equivalenti mentre il server http continua a funzionare. È possibile eseguire alcuni script per ridurre significativamente i tempi di inattività, ma controllare attentamente i codici di ritorno dei comandi nello script se si automatizza il processo.

Detto questo, se non si desidera ottenere tempi di inattività, anche l' applicazione deve supportarlo. La maggior parte delle applicazioni utilizza un database per la persistenza. Avere la versione N della tua applicazione in disordine con la versione N + 1 (o viceversa) del tuo modello di dati può rompere le cose se non previsto dal team di sviluppo.

Per esperienza, mantenere tale coerenza attraverso gli aggiornamenti non è un dato di fatto per la maggior parte delle applicazioni. Un arresto corretto, nonostante i tempi di inattività, è un buon modo per evitare problemi di coerenza.