RubyOnRails

Bestes Ruby on Rails Hosting bei Hostsharing

Rubyanwendungen laufen (wie alle Anwendungen bei Hostsharing) als Prozesse des jeweiligen Benutzersaccounts. Probleme mit Dateirechten und Sicherheitsrisiken, wie sie sonst bei der Ausführung durch den Webserver auftreten, sind so von vorne herein ausgeschlossen.

Standardmäßig erfolgt der Aufruf von Ruby Anwendungen durch den Apache Webserver über die FastCGI Schnittstelle. Dabei wird ständig eine Ruby Application Server Instanz des Users bereitgehalten, die somit jederzeit zur Bearbeitung von noch nicht gecacheten, oder gar nicht cachebaren, Anfragen zur Verfügung steht.

Für den Betrieb von noch anspruchsvolleren Anwendungen haben wir auch Tools wie haproxy, varnish, nginx etc. installiert. Wir können auch mod_passenger (mod_wsgi haben wir schon) oder mongrel oder Green Unicorn (gunicorn) installieren. Anwender, die damit auf unserer leistungsfähigen Infrastruktur (managed Plattform) z.B. einen Webserver Cluster mit load-balancing realisieren möchten, brauchen bei uns dafür nur eigene Daemons buchen, oder können (für größere Projekte) dafür natürlich auch eine beliebige Anzahl ganzer Server buchen.

Einrichtung ohne zusätzliche Daemons (ein Application Server)

Vorbereitungen

Einige Einstellungen für den Paketuser.

~/.gemrc

install: --no-rdoc --no-ri
update:  --no-rdoc --no-ri

~/.bashrc

alias gem="nice -n19 gem"

~/.profile

source "$HOME/.bashrc"

Ruby

Vorinstalliert

Soll nur die zentral installierte Ruby Version verwendet werden, ergänzt man man die ~/.profile:

# enable user's own ruby stuff below $HOME
export PATH="$HOME/bin:$HOME/.gem/bin:$PATH"
export GEM_PATH="$( gem env gempath )"
export GEM_HOME="$HOME/.gem/ruby/1.8"
export RUBYLIB="$HOME/.gem/ruby/1.8/lib:/usr/local/lib/site_ruby/1.8:/usr/lib/ruby/1.8"

# avoid to forget that extra parameter: ruby -rubygems prog_that_uses_gems
export RUBYOPT=rubygems

export RAILS_ENV=production

Eigene Installation

Um eine andere als die vorinstallierte Ruby Version zu verwenden, installiert man zunächst den Ruby Versions Manager (rvm),

curl -L https://get.rvm.io | bash -s stable
source ~/.rvm/scripts/rvm
rvm notes
rvm requirements
rvm pkg install openssl

und lässt dann die gewünschte Ruby Version installieren.

rvm install x.y.z

RVM passt die Umgebungsvariablen automatisch an die ausgewählt Version an. Die Version wählt man global per

rvm use x.y.z --default

oder nur für ein spezielles Verzeichnis:

cd ~/verzeichnis/mit/ruby-x.y.z-Anwendung
rvm use x.y.z-p??? --rvmrc

Zur Verwaltung von gems installiert man noch rubygems.

rvm rubygems current

Rails

Nun kann Rails durch installieren des gem-Pakets installiert werden (inklusive Abhängigkeiten).

gem install rails

Um spezielle versionen zu installieren kann man gem Befehle mit "-v=x.y.z" ergänzen.

Rails-Anwendung

Seine Rails-Anwendung kopiert man z.B. nach ~/rails, oder erstellt dort eine Neue (rails ~/rails, ...).

Datenbank

Mit hsadmin beispielsweise einen Postgres-User (z.B. 'xyz00_rails', Passwort sei 'geheim') sowie eine Datenbank anlegen (z.B. 'xyz00_rails'.

Die Datenbank in der Anwendung konfigurieren,

 cd ~/rails-app/config/
 nano database.yml

mit folgendem Inhalt:

 production:
   adapter: postgresql
   database: xyz00_rails
   host: localhost
   username: xyz00_rails
   password: geheim

E-Mail, Dateiablage

Beispielhafte Konfiguration:

 default:
   email_delivery:
     delivery_method: :smtp
     smtp_settings:
       address: localhost
       port: 25
       domain: example.org
   attachments_storage_path: /home/pacs/xyz00/users/rails/attach

Datenbankschema

Initialisieren und migrieren der Datenbank je nach Rails-Anwendung.

 cd ~/rails
 ...
 rake ...

Konfiguration von FastCGI

~/doms/rails.example.org/htdocs/.htaccess

 RewriteEngine On
 RewriteRule ^$ index.html [QSA]
 RewriteRule ^([^.]+)$ $1.html [QSA]
 RewriteCond %{REQUEST_FILENAME} !-f [OR]
 RewriteCond %{REQUEST_FILENAME} dispatch.fcgi$
 RewriteRule ^(.*)$ /fastcgi-bin/dispatch.fcgi [QSA,L]

Ältere Versionen von Rails, die noch nicht auf rack middleware aufbauen, laufen mit folgender ~/doms/www.example.org/fastcgi/dispatch.fcgi

 #!/usr/bin/env ruby
 require "/home/pacs/xyz00/users/meinuser/rails/config/environment" 
 require 'fcgi_handler'
 RailsFCGIHandler.process!

Für aktuelle Versionen von Rails, die auf der "rack" Middleware aufbauen, siehe https://github.com/dre3k/rails3_fcgi, ~/doms/www.example.org/fastcgi/dispatch.fcgi

 #!/usr/bin/env ruby

require_relative '../config/environment'

class Rack::PathInfoRewriter
  def initialize(app)
    @app = app
  end

  def call(env)
    env.delete('SCRIPT_NAME')
    parts = env['REQUEST_URI'].split('?')
    env['PATH_INFO'] = parts[0]
    env['QUERY_STRING'] = parts[1].to_s
    @app.call(env)
  end
end

Rack::Handler::FastCGI.run  Rack::PathInfoRewriter.new(HIER_APPLIKATIONSNAME_AUS_config/application.rb_EINTRAGEN::Application)

FastCGI-Skript ausführbar machen:

 chmod 755 ~/doms/rails.example.org/fastcgi/dispatch.fcgi

Am Anfang von ~/rails/config/environment.rb einfügen:

 ENV['RAILS_ENV'] ||= 'production'
 ENV['GEM_PATH'] ||= '/home/pacs/xyz00/users/meinuser/ruby/.gem/ruby/1.8:/var/lib/gems/1.8'

Evtl. können diese Einstellungen auch ohne eine Modifikation der Anwendung erfolgen, indem die Umgebungsvariablen in der .htaccess gesetzt werden (z.B. "SetEnv RAILS_ENV production").

Die Applikation ins Webroot einbinden:

 # ggf. vorhandene Dateien sichern (oder nach ~/rails/public kopieren)
 mv ~/doms/rails.example.org/htdocs ~/doms/rails.example.org/htdocs.old
 # Das rails/public Verzeichnis ins Webroot verlinken.
 ln -s ~/rails/public ~/doms/rails.example.org/htdocs

Konfiguration von SSL

Die Verzeichnisse ~/doms/rails.example.org/fastcgi-ssl/ und ~/doms/rail.example.org/htdocs-ssl/ werden analog zu bzw. anstelle von fastcgi und htdocs gefüllt.