Implementazione a caldo su Heroku senza tempi di inattività

Question

Un lato negativo del push su Heroku è che devo inserire il codice (e il server si riavvia automaticamente) prima di eseguire le mie migrazioni di db.

Ciò può ovviamente causare circa 500 errori negli utenti che navigano nel sito Web con il nuovo codice senza le nuove tabelle/attributi: la soluzione proposta da Heroku è quella di utilizzare la modalità di manutenzione, ma voglio un modo senza alcun svantaggio che consenta alla mia webapp correre ogni volta!

C'è un modo? Ad esempio, con Capistrano:

• mi preparo il codice per implementare in una nuova directory
• corro (indietro) migrazioni e il vecchio codice continuerà a funzionare perfettamente
• ho swith esempio bastardino al nuovo dir e riavviare il server

... e non ho tempi di inattività!

Answer 1

Heroku non può schierare da capistrano. Sei bloccato dallo strumento rilasciato da heroku.

Nessun sistema di fermo macchina è impossibile in tutti i casi. Come cambiare il tuo schema con grandi cambiamenti senza fermare il tuo server. Se non lo interrompi, puoi evitare alcune modifiche e il tuo database può essere incoerente. COSÌ, l'utilizzo della pagina di manutenzione è una soluzione normale.

Se si desidera una piccola soluzione per evitare problemi è un bilanciamento in due server. Uno con solo leggere il database durante la migrazione. È possibile passare a questa istanza durante la migrazione evitando la pagina di manutenzione. Dopo la tua migrazione torni dal tuo padrone.

Answer 2

L'unico metodo per migliorare il processo in qualche modo è quello che suggerisce questo tizio. Questo non è ancora uno scenario di deploy calda però:

http://casperfabricius.com/site/2009/09/20/manage-and-rollback-heroku-deployments-capistrano-style/

Una cosa vorrei suggerire sta spingendo soltanto i vostri migrazioni fino a Heroku prima e in esecuzione prima di spingere il vostro codice di base. Ciò comporterebbe il commit delle migrazioni come commit standalone e la loro pressione manuale ogni volta (che non è l'ideale). Sono molto sorpreso che non ci sia una soluzione migliore a questo problema con tutte le grandi app ospitate su Heroku ora.

Answer 3

È possibile impostare una seconda app Heroku che punta allo stesso DB dell'app di produzione principale e utilizzare l'app secondaria per eseguire le migrazioni di DB senza interrompere la produzione (presupponendo che le migrazioni non interrompano la versione precedente della app) .

Chiamiamo il Heroku apps PRODUZIONE e STAGING.

La sequenza implementare sarebbe diventato qualcosa di simile:

1. Deploy nuovo codice a STAGING
   git push heroku staging
2. migrazioni di database Esegui STADIAZIONE (per aggiornare CODICE db)
   heroku run -a staging-app rake db:migrate
3. Distribuire il nuovo codice a PRODUZIONE
   git push heroku production

L'applicazione messa in scena non vi costa nulla dal momento che non sarà necessario superare il livello gratuito di Heroku e sarebbe piuttosto banale per impostare uno script rastrello deploy di fare questo per voi automaticamente.

Buona fortuna!

Answer 4

Se sei in grado di vivere contemporaneamente con due versioni della stessa app in diretta, Heroku ora dispone di una funzione di preavvio.

https://devcenter.heroku.com/articles/preboot

Answer 5

In realtà avrà qualche tempo morto quando Heroku riavvia l'app. Hanno una nuova funzionalità denominata Preavvio che avvia nuovi lanci prima di prendere quelli vecchi: https://devcenter.heroku.com/articles/labs-preboot/

Per quanto riguarda le migrazioni di database, che collega articolo per questo uno su come affrontare questo problema: http://pedro.herokuapp.com/past/2011/7/13/rails_migrations_with_no_downtime/

Answer 6

ho impegnare le migrazioni, eseguirle, quindi spingere il resto del codice. Aggiungere un singolo file in questo modo:

git commit -m 'added migration' -- db/migrate/2012-your-migration.rb