ruby on rails - app - Capistrano desplegará la aplicación de rieles: ¿cómo manejar migraciones largas?

passenger rails app nginx

Question

Así que estoy usando Capistrano para implementar una aplicación de rieles en mi servidor de producción (apache + pasajero) y en este momento la implementación generalmente va de la siguiente manera:

$cap deploy
$cap deploy:migrations

Me pregunto, digamos que mi db: migrations tardó mucho tiempo en ejecutarse en el servidor de producción (un gran refactor del esquema db). En este caso, ¿cuál es la mejor práctica con Capistrano? ¿Qué sucede si los usuarios están conectados a mi aplicación en el momento de la implementación? ¿Debo enviar a los usuarios con gracia a una página de marcador de posición estática mientras se actualiza la base de datos? ¿Capistrano maneja esto automágicamente? ¿Necesito codificar una receta para ayudar con esto? ¿O los mecanismos internos de rieles / pasajeros significan que no tengo que preocuparme en absoluto por este caso en particular?

Gracias.

Answer 1

Debe colocar una página de mantenimiento si la aplicación no va a estar disponible por un tiempo. Yo uso esta tarea de 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

El archivo app/views/admin/maintenance.html.erb debe contener:

<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>

El último paso es configurar el host virtual de Apache con algunas directivas para buscar el archivo maintenance.html y redirigir todas las solicitudes a él si está presente:

<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>

Para poner la aplicación en modo de mantenimiento, ejecute cap deploy:web:disable y para que vuelva a estar en funcionamiento.

Answer 2

Mis implementaciones de producción generalmente siguen este proceso:

1. cap production deploy:web:disable que dirige todas las solicitudes a una página de mantenimiento estático
2. cap production deploy
3. migraciones, etc., probando cada uno de los servidores individualmente para asegurarse de que todo está bien
4. cap production deploy:web:enable para hacer que el sitio funcione como debería

La respuesta de John Topley te da una buena información en profundidad aquí.