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 installations, keeping all stuff below $HOME/.gem export PATH="$HOME/bin:$HOME/.gem/ruby/1.8/bin:$PATH" export GEM_PATH="$( gem env gempath )" export GEM_HOME="$HOME/.gem/ruby/1.8" # Disabled for now, because using system libs caused undefined method error. #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 per "gem install <Paketname>" installiert werden (inklusive Abhängigkeiten). Um spezielle versionen zu installieren kann man den gem Befehl mit "-v=x.y.z" ergänzen.
Zum Testen ein Beispiel das auch noch ein fertiges CMS Framework installiert (http://zenadmin.org), inklusive automatischer Einrichtung einer sqlite Datenbankdatei:
gem install rails -v=2.3.11 gem install i18n sexp_processor sqlite3 zena zena new ~/rails # Legt eine Rails-Anwendung an. cd ~/zena-test rake db:create # Datenbank anlegen. zena migrate # Datenbank Tabellen einrichten. zena mksite LANG=en RAILS_ENV=production PASSWORD=geheim HOST=rails.example.org # Webseite anlegen.
Rails-Anwendung
Seine eigene 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/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/.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.