acts_as_blog

Mephisto per Capistrano deployen

Nach dem Ausfall des Servers letzte Woche, mußte ich dieses Blog auf einem neuen Server aufsetzen. Ein passender Augenblick, das ganze sauber mit Capistrano zu machen. Dies ist eine kurze Zusammenfassung, wie auch du Mephisto auf einem Server mit openSuSE 10.2 und Plesk 8.4 (wie sie bei 1&1 angeboten werden) deployen kannst. Die Beispiele haben “acts-as-blog.net” als Beispieldomain. Du solltest entsprechend die Daten deinen Anforderungen anpassen.

Als allererstes solltest du eine Domain inklusive Webspace über Plesk anlegen. Plesk erzeugt daraufhin in /srv/www/vhosts/$DOMAIN unter anderem ein httpdocs- sowie ein conf-Verzeichnis. Die übrigen Verzeichnisse sind für das Deployment selbst uninteressant. Natürlich darf auch Ruby und die Rubygems auf dem Server nicht fehlen. Auch ein passendes Gem für deine Datenbank (MySQL, PostgreSQL) solltest du installieren. Dies kannst du über yast erledigen. Ich hatte ursprünglich auch Rails 2.1 installiert, doch wie sich später herausstellte, läuft Mephisto derzeit nur mit Rails 2.0.x, so daß ich Mephisto mit Rails 2.0.2 im Vendor-Verzeichnis deployen mußte. Das tzinfo-gem kannst du auch entweder direkt auf dem Server installieren oder im Vendor-Verzeichnis mitliefern. Zu guter Letzt habe ich auch noch den Mongrel mitinstalliert. Dies ist kein Muß, vermutlich würde es mit Webrick genauso funktionieren.

Der Apache (Version 2.2) muß natürlich als Proxy arbeiten. Dazu müssen die entsprechenden Proxy-Module geladen werden. Ich fand keinen Menüpunkt in Plesk, um diese Einstellung vorzunehmen, also habe ich in der /etc/sysconfig/apache2-Datei die Zeile, die mit APACHE_MODULES anfängt um ”proxy proxy_http proxy_balancer” erweitert. Spätestens jetzt sollte auch dir klargeworden sein, daß du ohne sudo nicht auskommen wirst. Einen sudo-losen Weg habe ich bislang nicht weiter ausprobiert.

Da Capistrano das Projekt unbedingt aus einem SCM-Repository deployen möchte, kannst du entweder das Vanilla-Mephisto von GitHub damit deployen, Mephisto auf GitHub forken oder ein komplettes eigenes Repository auf einer eigenen Maschine einrichten. Letztenendes ist es egal, für welchen Weg du dich entscheidest, solange du die korrekte URL für das Repository in der config/deploy.rb angibst.

Mephisto benötigt eine Datenbank, um deine Artikel zu speichern. Lege eine Datenbank und einen Benutzer für diese Datenbank mit Plesk an. Die Zugangsdaten für diese Datenbank solltest auch in den Production-Abschnitt der database.yml-Datei eintragen. Damit wäre die Datenbankverbindung konfiguriert.

Das Skript, was zuständig für das Starten des Mongrel ist, heißt script/spin. Bei mir sieht dieses Skript so aus:

#!/bin/sh
script/process/spawner -a 127.0.0.1 -p 8010 -i 3

Damit werden 3 Mongrels auf Port 8010-8012 gestartet. Wie viele Mongrels tatsächlich benötigt werden, ist abhängig davon, wie stark besucht die Webseite ist. Da ein Mongrel mit ca. 64MB Speicherverbrauch zu buche schlägt, sollte man auch nicht zu viele Mongrels auf einmal starten. Vergiß nicht, dieses Skript ausführbar (chmod +x script/spin) zu machen und es wieder einzuchecken!

Der Apache muß noch als Proxy für den Mongrel konfiguriert werden. Hierzu bietet Plesk an, daß man die Konfiguration der einzelnen virtuellen Hosts um eigene Konfigurationseinstellungen erweitern kann. Diese Einstellungen gehören in die /srv/www/vhosts/$DOMAIN/conf/vhost.conf-Datei. Ich habe eine entsprechende vhost.conf-Datei vorbereitet, die beim Deployment mithochgeladen und aktiviert wird. Hierzu habe ich in meinem Verzeichnis mit der Working-Copy von Mephisto die Datei config/vhost.conf mit folgendem Inhalt erstellt:

# Mongrel cluster configuration
<Proxy balancer://actsasblog_mongrel>
        BalancerMember http://127.0.0.1:8010
        BalancerMember http://127.0.0.1:8011
        BalancerMember http://127.0.0.1:8012
        Order deny,allow
        Allow from all
</Proxy>

RewriteEngine On

# Check for maintenance file and redirect all requests
RewriteCond %{DOCUMENT_ROOT}/current/system/maintenance.html -f
RewriteCond %{SCRIPT_FILENAME} !maintenance.html
RewriteRule ^.*$ /current/system/maintenance.html [L]

# Rewrite index to check for static
RewriteRule ^/$ /current/index.html [QSA]

# Rewrite to check for Rails cached page
RewriteRule ^([^.]+)$ $1.html [QSA]

# Redirect all non-static requests to cluster
RewriteCond %{DOCUMENT_ROOT}/current/%{REQUEST_FILENAME} !-f
RewriteRule ^/(.*)$ balancer://actsasblog_mongrel%{REQUEST_URI} [P,QSA,L]

Damit wäre alles bereit, mit Capistrano auf den Server hochgeschossen zu werden. Hierzu mußt du deine working copy capifien. Gib im Hauptverzeichnis deiner Working-Copy einfach capify . ein und Capistrano erzeugt zwei neue Dateien in deiner Working-Copy. (Capfile und config/deploy.rb) Es ist eine Glaubensfrage, ob du diese Dateien ins Repository einchecken solltest. Letztere ist bei Mephisto sogar explizit in der .gitignore aufgeführt.

Die config/deploy.rb-Datei solltest du nun an deine Anforderungen anpassen. Als Vorlage kannst du meine Datei benutzen:

set :application, "acts_as_blog"
set :repository, "git://meinrepository/acts_as_blog.git"

role :web, "acts-as-blog.net"
role :app, "acts-as-blog.net"
role :db,  "acts-as-blog.net", :primary => true

default_run_options[:pty] = true
set :deploy_to, "/srv/www/vhosts/acts-as-blog.net/httpdocs"
set :user, "actsasbloguser"
set :scm, :git
set :ssh_options, { :forward_agent => true }
set :use_sudo, false

set :common_dirs, ['public/assets']

namespace :deploy do
  desc "upload database configuration"
  task :upload_database_configuration, :roles => :app do
    run "mkdir -p #{shared_path}/config"
    config = File.read(File.join(File.dirname(__FILE__), "database.yml"))
    put config, "#{shared_path}/config/database.yml"
    run "ln -nfs #{shared_path}/config/database.yml #{latest_release}/config/database.yml"
  end

  desc "update virtual host configuration"
  task :update_vhost_conf, :roles => :web do
    run "mkdir -p #{shared_path}/config"
    config = File.read(File.join(File.dirname(__FILE__), "vhost.conf"))
    put config, "#{shared_path}/config/vhost.conf"
    sudo "ln -nfs #{shared_path}/config/vhost.conf #{deploy_to}/../conf/vhost.conf"
    sudo "/usr/local/psa/admin/bin/websrvmng --vhost-name=acts-as-blog.net"    # update plesk
    sudo "/usr/sbin/rcapache2 configtest"   # test apache configuration
    sudo "/usr/sbin/rcapache2 reload"      # reload apache configuration
  end

  desc "symlink common directories on server"
  task :symlink_common_dirs, :roles => :web do
    unless fetch(:common_dirs, []).empty?
      fetch(:common_dirs).each do |dir|
        run "rm -rf #{release_path}/#{dir} &&\
              ln -nfs #{shared_path}/#{dir} #{release_path}/#{dir}"
      end
    end
  end

  desc "set up common directories on server"
  task :setup_common_dirs, :roles => :web do
    unless fetch(:common_dirs, []).empty?
      dirs = fetch(:common_dirs).map { |d| File.join(shared_path, d)}
      run "umask 002 && mkdir -p #{dirs.join(' ')}"
    end
  end

  after "deploy:finalize_update", "deploy:symlink_common_dirs"
  after "deploy:setup", "deploy:setup_common_dirs"

  after "deploy:finalize_update", "deploy:upload_database_configuration"
  after "deploy:upload_database_configuration", "deploy:update_vhost_conf"
end

Da ich sowohl die config/database.yml als auch die config/vhost.conf explizit von der Revisionsverwaltung ausgeklammert habe, muß ich diese separat auf dem Server ablegen. Das erledigen die upload_database_configuration- und update_vhost_conf-Tasks. Die setup_common_dirs- und symlink_common_dirs-Tasks hatte ich bereits schon mal hier vorgestellt.

Damit wäre alles zum Deployment vorbereitet. Das eigentliche Deployment läuft dann so ab:

cap deploy:setup  # Verzeichnisse vorbereiten
cap deploy:check  # Prüfen, ob alle Schreibrechte ausreichen
cap deploy:cold   # Hoch damit!

Beim letzten Befehl sollte ein Haufen Zeilen vorbeiscrollen. Dies ist normal und kein Grund zur Besorgnis. Irgendwann wird sudo nach dem Paßwort fragen, um die vhost.conf einzubinden. Danach wird der Apache reloaded und die Mongrels gestartet. Damit sollte nun ein frisches Mephisto auf dem Server laufen. Sollten Probleme auftreten, so solltest du dir die Ausgaben von cap deploy:cold genau anschauen. Oft ist in den Meldungen das Problem klar zu erkennen.

Spätere Updates von Mephisto kannst du mit cap deploy durchführen. Alles weitere findest du in der Dokumentation auf der Capistrano-Website.