Rails-Hosting auf Uberspace

Uberspace - Hosting on Asteroids Ich bin großer Fan der einladenden Atmosphäre, Einfachheit und dem großartigen Support auf Uberspace. Konsequenterweise hab ich nun auch meine letzten privaten Projekte dorthin umgezogen und mich dabei auch mit dem Rails-Deployment auf Uberspace auseinander gesetzt.

Für die ersten Schritte findet man im Wiki eine Anleitung mit allen generellen Einzelheiten zum Aufsetzen einer Rails-Anwendung auf Uberspace. Der dort beschriebene Ansatz setzt der Einfachheit halber auf das manuelle Ausführen der einzelnen Schritte und das Ausliefern der Anwendung über FastCGI. Da das nicht unbedingt etwas ist, was man aus dem täglichen Rails-Kontext kennt, hier ein paar Hinweise und Learnings zur Automatisierung des Deployments und zur Verwendung alternativer Applikationsserver.

Automatisierung des Deployments

Wer seine Anwendungen mit Capistrano deployed, sollte einen Blick auf uberspacify werfen, ein Gem das alle nötigen Capistrano-Scripte mitbringt, um den eigenen Uberspace startklar für das Rails-Hosting zu machen. Als Fan von Vlad habe ich mich von uberspacify inspirieren lassen und die nötigen Uberspace-Tasks für Vlad geschrieben. Das Script enthält die wichtigsten Anmerkungen und Konfigurationshinweise, hier noch ein paar generelle Dinge:

Die von Vlad/Capistrano benutzte Shell ist nicht die interaktive Shell, die man selbst beim Login über SSH bekommt. Um sicherzustellen, dass auch diese Tools die gleiche Konfiguration (bspw. den Pfad zu einer angepassten Ruby-Version) haben, sollten die Anweisungen dafür in die .bashrc statt in die .bash_profile geschrieben werden.

Die Anwendung selbst muss unterhalb /var/www/virtual/username/ liegen, damit der Apache darauf zugreifen kann. Im einfachsten Fall würde man einfach in das html-Verzeichnis dort deployen, was aber mit der von den Deployment-Tools generierten Struktur (current, releases, shared) ungünstig ist, da diese dann im DocumentRoot des Webservers liegen. Ich mache es daher so, die Anwendung in /var/www/virtual/username/rails/myapp zu deployen und einen Symlink mit dem Hostnamen der Domain auf das darin liegende current/public zu setzen. Damit funktioniert dann auch der Zugriff aus die Assets der Anwendung problemlos, ohne weitere Einstellungen in der .htaccess machen zu müssen. Im Zusammenhang mit den so verwendeten Domains sollte man den Hinweis zum angepassten DocumentRoot beachten.

Alternative Applikationsserver

Statt FastCGI benutze ich Thin, generell treffen die nachfolgenden Dinge aber auch zu, sollte man sich für die Verwendung von Unicorn, Puma, Mongrel oder Passenger Standalone entscheiden. Wichtig ist eigentlich nur, dass man den Applikationsserver auf hohen Port laufen lässt und ihn mittels Daemontools überwacht, so dass er auch unabhängig von Webserver-Restarts persistent läuft.

Das run-Script dafür, sieht dann beispielsweise folgendermaßen aus:

#!/bin/bash
export HOME=/home/username
source $HOME/.bash_profile
cd /var/www/virtual/username/rails/myapp/current
exec /home/username/.gem/ruby/1.9.1/bin/bundle exec thin start -p 43862 -e production 2>&1

Zu guter letzt benötigt man unter current/public noch eine .htaccess-Datei, die eine RewriteRule enthält, um die Requests an den Applikationsserver-Proxy weiterzuleiten. Im einfachsten Fall reicht folgendes:

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ http://localhost:43862/$1 [P]

Darüber hinaus gibt es hier auch noch eine Variante der .htaccess mit Asset-Caching und Wartungsmodus.

Sowohl uberspacify als auch das Vlad-Script kümmern sich darum diese Dateien entsprechend der gegebenen Konfiguration zu generieren. Sollte jemand das Vlad-Script ausprobieren oder Anmerkungen zu den hier gegebenen Tipps haben freue ich mich natürlich über Feedback dazu :)

Bitte beachten!

Uberspace hat ein SSH-Connection Limit, was auch gut so ist. Vlad wiederum öffnet für jedes Kommando eine neue SSH-Verbindung, so dass man schnell mit dem Connection Limit kollidiert. Daher ist es sinnvoll, SSH-Multiplexing zu aktivieren, was man mit folgenden Zeilen in der ~/.ssh/config tun kann:

Host *
  ControlMaster auto
  ControlPath /tmp/ssh-master-%r@%h:%p
  ControlPersist 15m

Dies führt dazu, dass bei jedem weiteren Befehl die bereits bestehende SSH-Verbindung genutzt wird. Man hat somit auch gleich ein schnelleres Deployment, daher wird auch in der Vlad FAQ generell dazu geraten, SSH-Multiplexing zu verwenden.

iOS app for GitHub

iOctocat

ist GitHub für die Hosentasche - deine Projekte und das was dort passiert immer dabei mit deinem iPhone und iPod Touch.
Die App ist