Distribuzione di nuovo codice live

Qual è la pratica migliore per distribuire un nuovo codice in un sito web (e-commerce) in diretta?

Per ora ho arrestato apache per +/- 10 secondi quando rinominare la directory public_html_new a public_html e vecchio a public_html_old . Questo crea un breve periodo di inattività, prima di avviare nuovamente Apache.

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

Durante la compressione del sito (live) di tar (backup) ho notato che le modifiche apportte 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.

  • Direttiva Mappa di Nginx per varie variables
  • Ottima impostazione MySQL my.cnf per il sito di Magento di grandi size su un server dedicato
  • Compliance PCI Magento CE
  • Il collegamento di loopback tramite il formato getimage di PHP blocca il server (Magento's CMS)
  • Magento Errore 404 dopo aver passato da Apache a nginX
  • Magento Community - Hosting :: Avere bisogno di una consulenza che condivisione di hosting eseguirà magento veloce
  • Ottimizzazione di MySQL per piccoli VPS
  • Aggiungere la traccia di trailing quando manca in nginx
  • 8 Solutions collect form web for “Distribuzione di nuovo codice live”

    L'utilizzo di un bilanciatore di carico è una buona idea. Se il sito è abbastanza importnte da preoccuparsi per alcuni secondi di interruzioni, è abbastanza importnte preoccuparsi della tolleranza agli errori.

    A parte ciò, se si tratta di un sistema UNIX è ansible mettere Apache in attesa durante la ridenominazione (o l'aggiornamento di symlink, 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 

    Questo manterrà Apache ad accettare nuove richieste durante la ridenominazione. Se si preferisce i collegamenti simbolici o un altro approccio, la stessa idea può essere utilizzata:

     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 coda nel sistema operativo. Per un sito estremamente occupato, consideri la sintonizzazione di ListenBacklog se è appropriato per il tipo di lavoratore di httpd e controlla le impostazioni del tuo OS relative a TCP per ascoltare il backlog.

    Potresti anche cambiare DocumentRoot in httpd.conf e fare un grazioso riavvio ( apachectl graceful ). L'inconveniente qui è il rischio aumentato di errori, dal momento che dovresti aggiornare anche una configuration di Directory .

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

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

    e utilizzare un collegamento simbolico corrente come il tuo html_root:

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

    Questa tecnica si integra perfettamente in un sistema di controllo di revisione (svn, git, mercurial, …), in quanto puoi verificare rami e tag, modificare il collegamento simbolico e ricaricare Apache. Il tempo di inattività è minimo grazie a questa tecnica e consente un rollback molto semplice .

    Inoltre si integra bene con un sistema di distribuzione più complesso come i pacchetti RPM o l'infrastruttura di gestione delle modifiche di configuration (chef, fantoccio, ecc.).

    Rinominare le directory senza chiudere Apache in giù dovrebbe funzionare pure. Questo accorcerà notevolmente la window. mv public_html public_html_old && mv public_html_new public_html dovrebbe finire in una frazione di secondo.

    Un paio di inconvenienti è che questo approccio darà un 404 a qualsiasi richiesta che ancora riesca ad accadere durante la window. E se si esegue il command di cui sopra senza avere una directory public_html_new non riesce e ti lascerà un sito che dà 404 su each richiesta.

    Fare in modo atomico con le directory non è un supporto. Ma potresti farlo con i simboli. Invece di avere una directory denominata public_html , avere una directory denominata public_html.version-number e un symlink chiamato public_html indica la directory. Ora puoi creare una directory denominata public_html.new-version-number e un nuovo symlink chiamato public_html.new .

    Quindi puoi rinominare public_html.new a public_html per passare in modo atomico. Si noti che mv è "troppo intelligente" per eseguire quella ridenominazione, ma potrebbe essere fatto usando os.rename dal pitone o qualsiasi altra cosa che chiamerà la chiamata di sistema di rename senza cercare di essere intelligente.

    Cosa fare con la base di dati dipende da quale database si sta utilizzando e per quello che lo utilizzi. Devi fornire molto più dettagli sul database prima di poter dare una buona risposta a quella parte della tua domanda.

    I simboli e mv sono i tuoi amici, tuttavia, se hai davvero bisogno di evitare che gli utenti finali ottengano una pagina di errore durante la distribuzione di una nuova versione, dovresti avere un proxy di inversione o un bilanciatore di carico di fronte a alless 2 server back-end (apache nel tuo caso).

    Durante la distribuzione, devi solo arrestare un backend alla volta, distribuire il nuovo codice, riavviarlo e poi iterare sui restanti backend.

    Gli utenti finali saranno sempre indirizzati a un buon backend dal proxy.

    Se apporti modifiche regolarmente su un sistema produttivo, vorrei prendersi cura 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ù piattaforms e configurazioni.

    Per Magento c'è anche un plugin: https://github.com/augustash/capistrano-ash/wiki/Magento-Example

    Per singoli server e transizioni quasi perfette, raccommand di utilizzare i collegamenti simbolici.

    Il modo in cui faccio è fare i miei cambiamenti dal mio ambiente locale dev a un repository online Git come Github. Il mio ambiente di produzione esegue un repository remoto, quindi basta fare ssh al server e eseguire git pull per ridurre le ultime modifiche. Non c'è bisogno di fermare il tuo webserver.

    Se si dispone di file nel progetto le cui impostazioni e / o contenuti differiscono dalla versione locale (ad esempio file di configuration e caricamenti di supporti) è ansible utilizzare le variables di ambiente e / o aggiungere questi file / directory a un file .gitignore per impedire la sincronizzazione con repository.

    La mia prima idea è:

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

    Una buona soluzione è stata quella di utilizzare rsync. Ha cambiato solo i file veramente cambiati. Attenzione, le battute alla fine dei routes sono qui importnti.

    Normalmente Apache non ha bisogno di un riavvio, non è il mondo java. Controlla la modifica di each file php su richiesta e rileva (e re-tokenizes) la modifica automaticamente.

    Git pull erano simili efficacemente, anche se era un po 'più difficile da script. Naturalmente ha permesso un ampio spettro di diverse possibilità di rilevamento delle fusioni / cambiamenti.

    Questa soluzione sarà senza soluzione di continuità solo se non ci sono cambiamenti veramente importnti – se ci sono grandi cambiamenti nella distribuzione, un po 'di pericolo non può essere chiuso perché c'è un intervallo di tempo trascurabile quando il codice sarà parzialmente cambiato e in parte no.

    Se ci sono grandi cambiamenti, il mio suggerimento è stata la tua soluzione iniziale (due ridenominazioni).


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

    (1) fare un supporto alternativo del tuo filesystem, where avviene il magento:

     mount /dev/sdXY /mnt/tmp 

    (2) fare un --bind mount del tuo public_html_new a public_html:

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

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

    (3) eseguire la sincronizzazione con rsync, ma sul punto di assembly 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 

    Spostamento / sostituzione della cartella http_public può essere ottenuta con semplici comandi mv o ln -s o equivalenti mentre il server http continua a funzionare. È ansible eseguire script per ridurre significativamente i tempi di inattività, ma verificare attentamente i codici di return dei comandi nello script se si automatizza il process.

    Detto questo, se non si desidera get tempi di inattività, l' applicazione deve anche sostenerla. La maggior parte delle applicazioni utilizza un database per la persistenza. Avere la versione N della tua domanda che interferisce con la versione N + 1 (o il contrario) del tuo model di dati potrebbe rompere le cose se non previsto dal team di sviluppo.

    Dall'esperienza, mantenere una tale coerenza attraverso aggiornamenti non è un dato per la maggior parte delle applicazioni. Una chiusura adeguata, nonostante i tempi di inattività, è un ottimo modo per evitare problemi di coerenza.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.