Aplikacja Capistrano do wdrażania szyn - jak radzić sobie z długimi migracjami?

Question

Więc używam Capistrano wdrożyć aplikację szyn na moim serwerze produkcyjnym (Apache + pasażera) oraz na wdrożeniu momencie zwykle idzie wzdłuż linii:

$cap deploy 
$cap deploy:migrations 

Zrobiło mi zastanawiając się, powiedzmy mojego db: migracje zabrało dużo czasu na wykonanie na serwerze produkcyjnym (duży refaktor schematu db) - w tym przypadku jaka jest najlepsza praktyka z Capistrano? Co się stanie, jeśli użytkownicy są podłączeni do mojej aplikacji w momencie wdrożenia? Czy powinienem wdzięcznie wysyłać użytkowników na statyczną stronę zastępczą podczas aktualizacji bazy danych? Czy Capistrano obsługuje to automagicznie? Czy muszę przepisać przepis, aby pomóc w tym? Czy też wewnętrzne mechanizmy szyn/pasażerów oznaczają, że nie muszę się w ogóle martwić o ten konkretny przypadek?

Dzięki.

Answer 1

Powinieneś umieścić stronę konserwacji, jeśli aplikacja nie będzie dostępna przez pewien czas. Używam tego zadania Capistrano:

namespace :deploy do 
    namespace :web do 
    desc <<-DESC 
     Present a maintenance page to visitors. Disables your application's web \ 
     interface by writing a "maintenance.html" file to each web server. The \ 
     servers must be configured to detect the presence of this file, and if \ 
     it is present, always display it instead of performing the request. 

     By default, the maintenance page will just say the site is down for \ 
     "maintenance", and will be back "shortly", but you can customize the \ 
     page by specifying the REASON and UNTIL environment variables: 

     $ cap deploy:web:disable \\ 
       REASON="a hardware upgrade" \\ 
       UNTIL="12pm Central Time" 

     Further customization will require that you write your own task. 
    DESC 
    task :disable, :roles => :web do 
     require 'erb' 
     on_rollback { run "rm #{shared_path}/system/maintenance.html" } 

     reason = ENV['REASON'] 
     deadline = ENV['UNTIL']  
     template = File.read('app/views/admin/maintenance.html.erb') 
     page = ERB.new(template).result(binding) 

     put page, "#{shared_path}/system/maintenance.html", :mode => 0644 
    end 
    end 
end 

Plik app/views/admin/maintenance.html.erb powinien zawierać:

<p>We’re currently offline for <%= reason ? reason : 'maintenance' %> as of <%= Time.now.utc.strftime('%H:%M %Z') %>.</p> 
<p>Sorry for the inconvenience. We’ll be back <%= deadline ? "by #{deadline}" : 'shortly' %>.</p> 

Ostatnim krokiem jest skonfigurowanie wirtualnego hosta Apache z niektórych dyrektyw w poszukiwaniu pliku maintenance.html i przekierować wszystkie żądania do to czy jest obecny:

<IfModule mod_rewrite.c> 
    RewriteEngine On 

    # Redirect all requests to the maintenance page if present 
    RewriteCond %{REQUEST_URI} !\.(css|gif|jpg|png)$ 
    RewriteCond %{DOCUMENT_ROOT}/system/maintenance.html -f 
    RewriteCond %{SCRIPT_FILENAME} !maintenance.html 
    RewriteRule ^.*$ /system/maintenance.html [L] 
</IfModule> 

aby umieścić aplikację w trybie konserwacji, uruchom cap deploy:web:disable i zrobić to na żywo ag ain do cap deploy:web:enable.

Answer 2

Moja produkcja wykorzystuje zazwyczaj śledzić ten proces:

1. cap production deploy:web:disable który kieruje wszystkie żądania do statycznej strony technicznego
2. cap production deploy
3. migracje itp, testując każdy z serwerów indywidualnie, aby upewnić się rzeczy są OK
4. cap production deploy:web:enable aby strona działała tak jak powinna

Odpowiedź Johna Topley'a dostarcza tutaj szczegółowych informacji.