“Desplegado” en Dreamhost de una aplicación Sinatra utilizando Capistrano » Ruido blanco

Creacción de un nuevo usuario en Dreamhost

Este es un paso opcional, pero como DreamHost a veces mata a los procesos que consumen mucha CPU o memoria, si tenemos otras aplicaciones o páginas web corriendo en DreamHost, y esperamos que nuestra nueva aplicación tenga una carga moderada es recomendable crear otro usuario específico para cada nueva aplicación.

1. Accedemos a la gestión de usuarios del panel de DreamHost.
2. Creamos un nuevo usuario y nos fijaremos que para “Type of User Account” esté seleccionada la opción “Shell”.

Creación del nuevo dominio o subdominio

1. Entraremos en la gestión de dominios del panel de DreamHost.
2. Creamos un nuevo dominio o subdominio.
3. Es muy importante seleccionar el checkbox “Ruby on Rails Passenger (mod_rails)?”.
4. Si en el apartado anterior hemos creado un nuevo usuario lo utilizaremos aquí. En el caso de utilizar un usuario que ya teníamos debemos cerciorarnos de que podemos acceder por SSH con él.
5. En el cuadro de texto “Specify your web directory” aparecerá el nombre de nuestro dominio. Si pensamos utilizar Capistrano para hacer el deploy deberemos añadir al nombre del dominio /current/public. Si no vamos a utilizar Capistrano simplemente añadiremos /public.

En estos momentos DreamHost se pondrá a trabajar y en un tiempo tendremos nuestro nuevo dominio preparado. Si vamos a utilizar Capistrano es importante que accedamos al servidor ahora y borremos el directorio current que DreamHost haya creado (y junto con él, el directorio public que contiene). Capistrano creará estos directorios cuando sea necesario.

Utilizando Capistrano con nuestra aplicación

Voy a suponer que nuestra aplicación Sinatra está en un directorio llamado app, y dentro de él se encuentran el archivo app.rb, que es el archivo principal de nuestra aplicación, y varios directorios (algunos específicos a Sinatra como public y views, y otros que no lo son).

La herramienta de línea de mandatos de Capistrano (cap) busca en el directorio actual un archivo denominado Capfile donde podría encontrarse toda nuestra receta, pero para poder reutilizarla más sencillamente en otros proyectos vamos a crearla en recipes/sinatra.rb. Podéis descargar sinatra.rb y copiarlo a esa carpeta (cambiad la extensión .rbs por .rb).

La receta utiliza la receta original de Capistrano para Rails, por lo que hay muchas tareas que realizan la misma función (adaptadas a Sinatra y mod_rails, claro), y otras que han desaparecido (las de migraciones y las de start y stop).

Finalmente crearemos el archivo Capfile en el directorio raíz de nuestra aplicación con unos contenidos similares a los siguientes:

load 'recipes/sinatra'

# Nombre de nuestra aplicación
set :application, 'app'

# URL de nuestro repositorio.
# Personalmente utilizo Git, por lo que tengo un repositorio justo en
# el directorio de la aplicación.
# Gotcha/Actualización: La cadena original era
# "file://.", que desgraciadamente
# no funciona porque Git copia esa cadena
# directamente como URL al nuevo repositorio,
# haciendo que las actualizaciones posteriores
# sean respecto de ese directorio y no desde el
# correcto. Como solución construimos el path
# absoluto para no dejar lugar a equivocaciones.
set :repository, "file://#{File.expand_path(File.join(File.dirname(__FILE__),’..’))}"

# El nombre de usuario en el servidor remoto.
# Necesario si no vais a utilizar .ssh/config
set :user, 'usuario'

# Directorio de la máquina remota donde se encontrará la aplicación.
# Atención: sin la parte de current/public.
set :deploy_to, '/home/usuario/www.example.com/'

# El tipo de control de versiones que
# utilizamos (:subversion, :git, :mercurial, …)
set :scm, :git

# (Expecífico para Git) La rama de la que haremos deploy
set :branch, 'master'

# Como el código será descargado en el servidor.
# Personalmente utilizo :copy, que descarga en la máquina local el
# repositorio, lo comprime y lo envía a la máquina remota.
# En la documentación Rdoc de Capistrano se encuentran todas las
# posibilidades y sus opciones.
set :deploy_via, :copy
set :copy_cache, true

# Las URL de cada uno de nuestros servidores y que rol desempeñan.
# Algunas tareas de las recetas solo se ejecutan en para ciertos roles.
# En este caso nuestro servidor tiene dos roles.
role :app, 'www.example.com'
role :web, 'www.example.com'

# DreamHost no nos deja utilizar sudo, así que lo desactivamos.
set :use_sudo, false


Instalando gemas en DreamHost

Para instalar gemas en DreamHost necesitaremos un directorio local para almacenarlas y escribir un par de archivos de configuración:

1. Entramos con SSH a la cuenta del usuario que vaya a ejecutar la aplicación (el que hemos creado en el primer apartado o el que ya existia).
2. Creamos el directorio para las gemas: $ mkdir ~/.gems
3. Editamos el archivo ~/.bash_profile y le añadimos la línea: export GEM_PATH=$HOME/.gems:/usr/local/lib/ruby/gems/1.8
4. Editamos el archivo ~/.gemrc:
   gemhome: /home/usuario/.gems
gempath:
- /home/usuario/.gems
- /usr/local/lib/ruby/gems/1.8
gem: –no-ri –no-rdoc
5. Instaleremos las gemas necesarias, por ejemplo, Sinatra:
   gem install sinatra.

Preparando nuestra aplicación para Passenger

Passenger utiliza Rack para comunicarse como muchos framework Ruby que no sean Rails, por lo que necesitamos crear un archivo config.ru en el directorio raíz de nuestra aplicación que le diga a Passenger como servir nuestra aplicación. El archivo es casi identico al que viene en la documentación de Passenger (hay que felicitarles por tener una documentación tan buena).

# Le decimos a Rubygems donde debe buscar las gemas
ENV['GEM_PATH'] = '/home/usuario/.gems:/usr/local/lib/ruby/gems/1.8'

require 'rubygems'
require 'sinatra'

Sinatra::Application.default_options.merge!(
  :run => false,
  :env => :production
)

require 'app.rb' # Nuestro archivo con la aplicación
run Sinatra.application

Preparando el servidor con Capistrano

En este punto hay que cerciorarse que todos los archivos necesarios están bajo control de versiones, porque nada que no lo esté será copiado al servidor. El archivo de la aplicación app.rb, el archivo config.ru, y los directorios public y views, deberían estar bajo control de versiones.

Para preparar el servidor debemos situarnos en el directorio raíz y ejecutar:

$ cap deploy:setup

Depende de como tengamos configurado nuestro acceso mediante SSH al servidor puede que Capistrano nos pida una contraseña o no (si tenemos la clave pública y privada correctamente configuradas Capistrano no debería pedir contraseñas).

Quizá en este punto sería recomendable comprobar que en el servidor está todo correcto. La estructura de directorios que se debería haber creado es la siguiente:

/home/usuario/www.example.com/
/home/usuario/www.example.com/releases/
/home/usuario/www.example.com/shared/
/home/usuario/www.example.com/shared/system/

Realizando el despliege

Tanto si es el primer deploy, como si es uno de los posteriores lo único que tenemos que hacer para enviar al servidor la nueva versión de nuestro código es lo siguiente:

1. Nos situamos en el directorio raíz de nuestro proyecto.
2. Comprobamos que todos los archivos que queremos enviar están en el repositorio
3. Ejecutamos: $ cap deploy

En este momento se habrá creado un nuevo directorio dentro del directorio releases del servidor, y se habrá creado un enlace simbólico desde current a él.

Si no hay problemas nuestra nueva web con Sinatra debería estar funcionando en nuestro dominio.

Ver entradas relacionadas

• Wet Floor se renueva
• Si todo ha ido bien… (y II)
• Rails: moviendo el código al servidor
• Si todo ha ido bien…
• Dreamhost capitula