rails::Notes

Mit diesen allgemeinen Apache2-Optionen lässt sich relativ schnell und schmerzlos eine Verbesserung der Ladezeiten erreichen: Kompression und Expiration-Headers.

Die beiden verantwortlichen Module müssen aktiviert werden:

a2enmod expires
a2enmod deflate

und die globale Sektion der apache2.conf erweitert:

# gzip html, css and js
AddOutputFilterByType DEFLATE text/html text/css application/x-javascript application/javascript

# far future expires headers
<FilesMatch ".(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)?d{10}$">
  ExpiresDefault "access plus 10 years" 
</FilesMatch>

Zu beachten wäre, dass die statischen Dateien aufgrund der langen Lebensdauer nicht aus dem Cache der Browser verschwinden werden – es sei denn, man zwingt sie dazu!

Weblinks

speed-up-your-apachepassenger-rails-app-in-2min

Grade ist die neue Passenger-Version 2.2.0 erschienen, die nun auch Nginx unterstützt. Das war für mich die Schwelle, Nginx anzutesten und insgesamt ist es alles einfach, wie bei Phusion gewohnt:

# gem install passenger

# passenger-install-nginx-module

Das war’s schon – fast. Das install-nginx-module lädt die Nginx-Source herunter, kompiliert sie und schreibt die Installation nach /opt/nginx. Das Passengermodul wird direkt eingebunden und man muss nur noch seine Hosts einpflegen:

Konfiguration

/opt/nginx/conf/nginx.conf:

passenger_pool_idle_time 0;

  server {
    listen 80;
    root /var/www/tracks/public;
    server_name tracks.int.bm.net tracks;
    rails_env production;
    passenger_enabled on;
  }

Ein

/opt/nginx/sbin/nginx

startet den Server.

X-Accel-Redirect

Anders als der Apache unterstützt Nginx direktes Filestreaming über den “X-Accel-Redirect”-Header. FIXME: die Konfiguration für mein laufendes Railsprojekt klemmt an dieser Stelle leider noch – die folgende Konfiguration führt zu einer Fehlermeldung:

server {
  listen 80;
  root /var/www/pplpool/current/public;
  server_name marsexpress.int.bm.net marsexpress;
  rails_env production;
  passenger_enabled on;
  location /uploads/ {
    internal;
    root /;
  }
}

1
2
3
4
5
6
7
8
9
10

def attachments
  @asset = QAttachment.find(params[:id])
  if
    head(:x_accel_redirect => "#{@asset.public_filename}", :content_type => 
      @asset.content_type, :content_disposition => 
      "attachment; filename=#{URI.encode(@asset.filename)}")
  else
    send_file(@asset.public_filename, :type => @asset.content_type)
  end
end

Update vom 20.4.: Aus unklaren Gründen läuft meine mephisto-Installation (dieser Blog) mit der aktuellen nginx-Passenger-Combo nicht einwandfei – ich steige erstmal wieder auf den Apache um.

Weblinks

1. using-nginx-to-send-files-with-x-accel-redirect
2. wiki.nginx.org/NginxXSendfile

Nach dem Upgrade auf Mephisto 8.1 funktionierte das Assetupload nicht mehr. Die Recherche ergab, dass das neu eingeführte Multisite-Feature in der Datei config/initializers/custom.rb

Site.multi_sites_enabled = true

auskommentiert werden muss, um die Thumbnails am gewohnten Ort zu plazieren, sodass Passenger sie wieder findet. Dieses Verhalten kommt mit Mongrel offenbar nicht vor [ungeprüft].

Weblink: gitting-started-with-mephisto

text ergänzen…

# apt-get install apache2-mpm-worker 

# apt-get autoremove

# passenger-install-apache2-module 

# service apache2 restart

aber: unter Ubuntu wird php5 deinstalliert!

FIXME

Will man eine Railsanwendung mit Capistrano an einen Webserver übertragen, der Passenger verwendet, so gibt es ein paar Kniffe, die einem das Leben leichter machen:

freeze Rails

Es hat sich gelegentlich als günstig erwiesen, Rails einzubetten:

> rake rails:freeze:gems

Capify

Nun erzeugt man die Capistrano-Konfiguration:

> capify .

Die u.a. entstandene deploy.rb-Datei verändert man wie folgt (hier für die Verwendung von git):

set :application, "anwendung" 
set :repository, "." 
set :user, "username" 
set :deploy_to, "/var/www/#{application}" 
set :use_sudo, false
set :scm, :git
set :deploy_via, :copy
set :copy_remote_dir, "/home/#{user}/tmp" 

role :app, application
role :web, application
role :db, application, :primary => true

namespace :deploy do
  desc "Restarting passenger with restart.txt" 
  task :restart, :roles => :app, :except => { :no_release => true } do
    run "touch #{current_path}/tmp/restart.txt" 
  end

  [:start, :stop].each do |t|
    desc "#{t} task is a no-op with passenger" 
    task t, :roles => :app do ; end
  end
end

lokales git-Repo

Wenn man Subversion nicht benötigt, kann man das Deployment einfach aus einem lokalen git-Repo heraus starten, das man sich zu diesem Zweck anlegt:

> git init
> git add .
> git commit -m "Initial deployment" 
> svn ps svn:ignore .git .

Die Daten werden dann mit der copy-Methode kopiert und der Server muss kein externes SVN-Repo kontaktieren.

Das Deployment

Nun kann man den eigentlichen Auslieferungsvorgang starten. Einmalig wird ein Setup aufgerufen, das die Ordnerbasis auf dem Server anlegt und danach wird ein cold-Deploy gestartet, das die Applikation kopiert und die Datenbank erstmalig anlegt:

> cap deploy:setup
> cap deploy:cold

Hat man die Datenbank auf der Serverseite noch nicht angelegt, so benötigt der ausführende ssh-User genug Rechte, um dies zu tun.

Webserverkonfiguration

Durch die Ordnerstruktur der Versionierungen muss das Basisverzeichnis des Apache auf /var/www/ANWENDUNG/current/public verweisen.

Folgende Deployments

Vor jedem neuen Deployment ist es erforderlich, das git-Repo zu aktualisieren:

> git add .
> git commit -a  -m "Änderungen"

Danach sorgt ein

> cap deploy:migrations

für ein neuerliches Kopieren, Migrieren und Neustarten der Applikation.