Últimamente al “deployar” mi pet-project dejaba de funcionar la aplicación, passenger no arrancaba. Mirando los logs me di cuenta de que la dependencia de prawn y prawn-labels me estropeaban el deploy.
Recomiendan instalar prawn (y prawn-labels) como submódulo y eso por suerte está contemplado en los despliegues con Capistrano, al menos parcialmente, añadiendo la siguiente variable a nuestro deploy.rb:
set :git_enable_submodules, true
Ver fichero: capistrano/lib/capistrano/recipes/deploy/scm/git.rb
De todos modos al hacer un nuevo despliegue la cosa seguía fallando. Siguiendo el proceso a mano resulta que Capistrano solo hace el init y update de los submódulos “raíz”. Quiero decir que si estos tienen mas submódulos no son tenidos en cuenta.
Finalmente dándome un paseo por Internet encontré la solución, se trata de la gema capistrano-deepmodules de morhekil. La cosa es muy simple:
- Instalamos la gema “morhekil-capistrano-deepmodules”
- Añadimos en nuestro deploy.rb: “require ‘capistrano/deepmodules’”
- (Opcional) podemos quitar de nuestro deploy.rb: “set :git_enable_submodules, true”
That’s all folks!
Mientras veía caer los copos de nieve por la ventana, observando como cuajaban en el patio, me vino a la mente que este “viernes de Capistrano” tenía que ser diferente, no estaba/estoy lo suficiente inspirado para corregir bugs. Entonces he recordado que tengo una deuda pendiente con la gente que vino al taller de Capistrano en la Conferencia Rails. Hubo varios temas que quería haber tocado pero que tuve que eliminar por falta de tiempo. Así que vamos a por uno de esos temas, el multistaging.
Leer más…
La mayor parte de la documentación que hay por ahí sobre como configurar Apache para poder usar la tarea de Capistrano deploy:web:disable es usar la directiva RewriteRule para ver si existe la página de mantenimiento.
Aparentemente está bien, pero no es así porque no cambia el código de la respuesta. Los clientes recibirán un 200 OK, indicando de que el servidor está funcionando como debe. El código de estado correcto debiera ser 503 Service Unavailable. Con un 503, conseguiremos prevenir que los motores de búsqueda indexen nuestra página de mantenimiento, a los que usan nuestra API les haremos la vida mas fácil, las peticiones AJAX pueden ser tratadas correctamente cuando el site se ha caído, etc.
La configuración de apache para realizar esto es la siguiente:
Leer más…
