RubyOnRails: Unterschied zwischen den Versionen

Aus Hostsharing Wiki
Zur Navigation springen Zur Suche springen
KKeine Bearbeitungszusammenfassung
 
(27 dazwischenliegende Versionen von 5 Benutzern werden nicht angezeigt)
Zeile 3: Zeile 3:
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.
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. Dieser hält dabei nach einem Aufruf die Ruby Application Server Instanz des Users noch für einige Zeit bereit, die dann sofort zur Bearbeitung von weiteren noch nicht gecacheten, oder gar nicht cachebaren, Anfragen zur Verfügung steht.
Standardmäßig erfolgt der Aufruf von Ruby Anwendungen durch den Apache Webserver über die FastCGI Schnittstelle. Dabei wird die Ruby Application Server Instanz des Users nach einem Aufruf noch für einige Zeit bereit gehalten, um sofort zur Bearbeitung von weiteren noch nicht gecacheten, oder gar nicht cachebaren, Anfragen zur Verfügung zu stehen.


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, können dies aber auch (für größere Projekte) mit einer beliebigen Anzahl ganzer Server realisieren.
Für den Betrieb von noch anspruchsvolleren Anwendungen haben wir auch Tools wie haproxy, varnish, nginx etc. installiert. Auf Anfrage können wir auch mod_passenger oder mongrel 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 zu buchen, können dies aber auch (für größere Projekte) mit einer beliebigen Anzahl ganzer Server realisieren.


== Einrichtung ohne zusätzliche Daemons (ein Application Server) ==
== Einrichtung ohne zusätzliche Daemons (ein Application Server) ==
Zeile 28: Zeile 28:
==== Vorinstalliert ====
==== Vorinstalliert ====


Soll nur die zentral installierte Ruby Version verwendet werden, ergänzt man man die ~/.profile:
Soll nur die zentral installierte Ruby Version 1.8 verwendet werden, ergänzt man man in ~/.profile:
# enable user's own ruby installations, keeping all stuff below $HOME/.gem
<syntaxhighlight lang=shell line>
export PATH="$HOME/bin:$HOME/.gem/ruby/1.8/bin:$PATH"
# enable user's own ruby installations, keeping all stuff below $HOME/.gem
export GEM_PATH="$( gem env gempath )"
export PATH="$HOME/bin:$HOME/.gem/ruby/1.8/bin:$PATH"
export GEM_HOME="$HOME/.gem/ruby/1.8"
export GEM_PATH="$HOME/.gem/ruby/1.8:$( gem env gempath )"
export GEM_HOME="$HOME/.gem/ruby/1.8"
   
   
# Disabled for now, because using system libs caused undefined method error.
# 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"
#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
# avoid to forget that extra parameter: ruby -rubygems prog_that_uses_gems
export RUBYOPT=rubygems
export RUBYOPT=rubygems
   
   
export RAILS_ENV=production
export RAILS_ENV=production
</syntaxhighlight>


==== Eigene Installation ====
==== Eigene Installation ====


Um eine andere als die vorinstallierte Ruby Version zu verwenden, installiert man zunächst den Ruby Versions Manager (rvm),
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
<syntaxhighlight lang=shell>
source ~/.rvm/scripts/rvm
curl -L https://get.rvm.io | bash -s stable
rvm notes
source ~/.rvm/scripts/rvm
rvm requirements
rvm notes
rvm pkg install openssl
rvm requirements
 
rvm pkg install openssl
</syntaxhighlight>


und lässt dann die gewünschte Ruby Version installieren.
und lässt dann die gewünschte Ruby Version installieren.
Zeile 65: Zeile 68:


=== Rails ===
=== Rails ===
Falls man die Ruby-Umgebung gerade erst eingerichtet hat, ohne sich zwischenzeitlich abzumelden, muß man zunächst die Umgebung manuell laden.
source ~/.profile


Nun kann Rails per "gem install rails" installiert werden (inklusive Abhängigkeiten).
Nun kann Rails per "gem install rails" installiert werden (inklusive Abhängigkeiten).
Um spezielle versionen zu installieren kann man den gem Befehl mit "-v=x.y.z" ergänzen.
Um spezielle versionen zu installieren kann man den gem Befehl mit "-v=x.y.z" ergänzen.


Zum Testen hier ein Beispiel das auch noch ein fertiges CMS installiert (http://zenadmin.org), und dieses mit einer eifachen sqlite Datenbankdatei einrichtet:
Zum Testen hier ein Beispiel das eine Content und Daten Management Anwendung installiert (http://zenadmin.org) und mit einer sqlite Datenbankdatei eingerichtet:
gem install rails -v=2.3.11
 
gem install i18n sexp_processor sqlite3 zena
<syntaxhighlight lang=shell>
zena new ~/rails      # Zena Rails-Anwendung anlegen.
gem install rails -v=2.3.11
cd ~/zena-test
gem install i18n sexp_processor rmagick sqlite3 zena
rake db:create        # Datenbank anlegen.
zena new ~/doms/www.example.org/rails      # Zena Rails-Anwendung anlegen.
zena migrate          # Datenbank Tabellen einrichten.
cd ~/doms/www.example.org/rails
zena mksite LANG=en RAILS_ENV=production PASSWORD=geheim HOST=rails.example.org # Webseite anlegen.
rake db:create        # Datenbank anlegen.
zena migrate          # Datenbank Tabellen einrichten.
zena mksite HOST_LANG=de RAILS_ENV=production PASSWORD=geheim HOST=www.example.org # Webseite anlegen.
</syntaxhighlight>


=== Rails-Anwendung ===
=== Rails-Anwendung ===


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


=== Datenbank ===
=== Datenbank ===
Zeile 88: Zeile 97:
Die Datenbank in der Anwendung konfigurieren,
Die Datenbank in der Anwendung konfigurieren,


  cd ~/rails/config/
  cd ~/doms/www.example.org/rails/config/
  nano database.yml
  nano database.yml


mit folgendem Inhalt:
mit folgendem Inhalt:


production:
<syntaxhighlight lang=yaml>
    adapter: postgresql
production:
    database: xyz00_rails
  adapter: postgresql
    host: localhost
  database: xyz00_rails
    username: xyz00_rails
  host: localhost
    password: geheim
  username: xyz00_rails
  password: geheim
</syntaxhighlight>


=== E-Mail, Dateiablage ===
=== E-Mail, Dateiablage ===
Zeile 104: Zeile 115:
Beispielhafte Konfiguration:
Beispielhafte Konfiguration:


<syntaxhighlight lang=yaml>
  default:
  default:
     email_delivery:
     email_delivery:
Zeile 110: Zeile 122:
         address: localhost
         address: localhost
         port: 25
         port: 25
         domain: example.org
         domain: www.example.org
     attachments_storage_path: /home/pacs/xyz00/users/rails/attach
     attachments_storage_path: /home/doms/www.example.org/rails/attach
</syntaxhighlight>


=== Datenbankschema ===
=== Datenbankschema ===
Zeile 117: Zeile 130:
Initialisieren und migrieren der Datenbank (je nach Rails-Anwendung).
Initialisieren und migrieren der Datenbank (je nach Rails-Anwendung).


  cd ~/rails
  cd ~/doms/www.example.org/rails
  ...
  ...
  rake ...
  rake ...
Zeile 124: Zeile 137:
=== Konfiguration von FastCGI ===
=== Konfiguration von FastCGI ===


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


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


Ältere Versionen von Rails, die noch nicht auf der "rack" Middleware aufbauen (wie obiges zena Beispiel), laufen mit folgender ~/doms/www.example.org/fastcgi/dispatch.fcgi
Ältere Versionen von Rails, die noch nicht auf der "rack" Middleware aufbauen (wie obiges zena Beispiel), laufen mit folgender ~/doms/www.example.org/fastcgi/dispatch.fcgi


#!/usr/bin/env ruby
<syntaxhighlight lang=ruby>
require "/home/pacs/xyz00/users/meinuser/rails/config/environment"  
#!/usr/bin/env ruby
require 'fcgi_handler'
require "/home/doms/www.example.org/rails/config/environment"  
RailsFCGIHandler.process!
require 'fcgi_handler'
RailsFCGIHandler.process!
</syntaxhighlight>


Für aktuelle Versionen von Rails, die auf "rack" aufbauen, siehe https://github.com/dre3k/rails3_fcgi, ~/doms/www.example.org/fastcgi/dispatch.fcgi
Für aktuelle Versionen von Rails, die auf "rack" aufbauen, siehe https://github.com/dre3k/rails3_fcgi, ~/doms/www.example.org/fastcgi/dispatch.fcgi
  #!/usr/bin/env ruby
 
<syntaxhighlight lang=ruby>
#!/usr/bin/env ruby
   
   
require_relative '../config/environment'
require_relative '../config/environment'
   
   
class Rack::PathInfoRewriter
class Rack::PathInfoRewriter
  def initialize(app)
  def initialize(app)
    @app = app
    @app = app
  end
  end
   
   
  def call(env)
  def call(env)
    env.delete('SCRIPT_NAME')
    env.delete('SCRIPT_NAME')
    parts = env['REQUEST_URI'].split('?')
    parts = env['REQUEST_URI'].split('?')
    env['PATH_INFO'] = parts[0]
    env['PATH_INFO'] = parts[0]
    env['QUERY_STRING'] = parts[1].to_s
    env['QUERY_STRING'] = parts[1].to_s
    @app.call(env)
    @app.call(env)
  end
  end
end
end
 
Rack::Handler::FastCGI.run  Rack::PathInfoRewriter.new(HIER_APPLIKATIONSNAME_AUS_config/application.rb_EINTRAGEN::Application)
Rack::Handler::FastCGI.run  Rack::PathInfoRewriter.new(HIER_APPLIKATIONSNAME_AUS_config/application.rb_EINTRAGEN::Application)


</syntaxhighlight>




FastCGI-Skript ausführbar machen:
FastCGI-Skript ausführbar machen:


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


Am Anfang von ~/doms/www.example.org/rails/config/environment.rb einfügen:


Am Anfang von ~/rails/config/environment.rb einfügen:
<syntaxhighlight lang=ruby>
ENV['RAILS_ENV'] ||= 'production'
ENV['GEM_PATH'] ||= '/home/pacs/xyz00/users/meinuser/.gem/ruby/1.8:/var/lib/gems/1.8'
</syntaxhighlight>


ENV['RAILS_ENV'] ||= 'production'
ENV['GEM_PATH'] ||= '/home/pacs/xyz00/users/meinuser/.gem/ruby/1.8:/var/lib/gems/1.8'
Evtl. könnten 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:
Die Applikation ins Webroot einbinden:


  # ggf. vorhandene Dateien sichern (oder nach ~/rails/public kopieren)
cd ~/doms/www.example.org
  mv ~/doms/rails.example.org/htdocs ~/doms/rails.example.org/htdocs.old
  # ggf. vorhandene Dateien sichern (oder nach ~/doms/www.example.org/rails/public kopieren),
# Das rails/public Verzeichnis ins Webroot verlinken.
  mv htdocs htdocs.old
  ln -s ~/rails/public ~/doms/rails.example.org/htdocs
# und das entsprechende public/ Verzeichnis der Rails-Anwendung im Webroot verlinken.
# Standardmäsig /home/doms/www.example.org/rails/public,
# bei multi-site Anwendungen wie zena aber z.B. /home/doms/www.example.org/rails/site/www.example.org/public
  ln -s /home/doms/www.example.org/rails/public htdocs


=== Konfiguration von SSL ===
=== 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.
Die Verzeichnisse ~/doms/www.example.org/fastcgi-ssl/ und ~/doms/www.example.org/htdocs-ssl/ werden analog zu bzw. anstelle von fastcgi und htdocs gefüllt.


[[Kategorie:HSDoku]]
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Software]]
[[Kategorie:RubyOnRails]]
[[Kategorie:Glossar]]
[[Kategorie:Glossar]]

Aktuelle Version vom 31. Mai 2024, 14:08 Uhr

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 die Ruby Application Server Instanz des Users nach einem Aufruf noch für einige Zeit bereit gehalten, um sofort zur Bearbeitung von weiteren noch nicht gecacheten, oder gar nicht cachebaren, Anfragen zur Verfügung zu stehen.

Für den Betrieb von noch anspruchsvolleren Anwendungen haben wir auch Tools wie haproxy, varnish, nginx etc. installiert. Auf Anfrage können wir auch mod_passenger oder mongrel 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 zu buchen, können dies aber auch (für größere Projekte) mit einer beliebigen Anzahl ganzer Server realisieren.

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 1.8 verwendet werden, ergänzt man man in ~/.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="$HOME/.gem/ruby/1.8:$( 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

Falls man die Ruby-Umgebung gerade erst eingerichtet hat, ohne sich zwischenzeitlich abzumelden, muß man zunächst die Umgebung manuell laden.

source ~/.profile

Nun kann Rails per "gem install rails" installiert werden (inklusive Abhängigkeiten). Um spezielle versionen zu installieren kann man den gem Befehl mit "-v=x.y.z" ergänzen.

Zum Testen hier ein Beispiel das eine Content und Daten Management Anwendung installiert (http://zenadmin.org) und mit einer sqlite Datenbankdatei eingerichtet:

gem install rails -v=2.3.11
gem install i18n sexp_processor rmagick sqlite3 zena
zena new ~/doms/www.example.org/rails      # Zena Rails-Anwendung anlegen.
cd ~/doms/www.example.org/rails
rake db:create        # Datenbank anlegen.
zena migrate          # Datenbank Tabellen einrichten.
zena mksite HOST_LANG=de RAILS_ENV=production PASSWORD=geheim HOST=www.example.org # Webseite anlegen.

Rails-Anwendung

Seine eigene Rails-Anwendung kopiert man z.B. nach ~/doms/www.example.org/rails, oder erstellt dort eine Neue (rails ~/doms/www.example.org/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 ~/doms/www.example.org/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: www.example.org
    attachments_storage_path: /home/doms/www.example.org/rails/attach

Datenbankschema

Initialisieren und migrieren der Datenbank (je nach Rails-Anwendung).

cd ~/doms/www.example.org/rails
...
rake ...


Konfiguration von FastCGI

~/doms/www.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 der "rack" Middleware aufbauen (wie obiges zena Beispiel), laufen mit folgender ~/doms/www.example.org/fastcgi/dispatch.fcgi

#!/usr/bin/env ruby
require "/home/doms/www.example.org/rails/config/environment" 
require 'fcgi_handler'
RailsFCGIHandler.process!

Für aktuelle Versionen von Rails, die auf "rack" 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/www.example.org/fastcgi/dispatch.fcgi


Am Anfang von ~/doms/www.example.org/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'


Die Applikation ins Webroot einbinden:

cd ~/doms/www.example.org
# ggf. vorhandene Dateien sichern (oder nach ~/doms/www.example.org/rails/public kopieren),
mv htdocs htdocs.old
# und das entsprechende public/ Verzeichnis der Rails-Anwendung im Webroot verlinken.
# Standardmäsig /home/doms/www.example.org/rails/public,
# bei multi-site Anwendungen wie zena aber z.B. /home/doms/www.example.org/rails/site/www.example.org/public
ln -s /home/doms/www.example.org/rails/public htdocs

Konfiguration von SSL

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