Das Administrieren eines Servers ist ja immer so eine Sache die ich nicht gerade gern mache, aber halt immer nötig ist. Eigentlich wollte ich ja alles mit Nginx und nicht mit Apache machen und das war ja noch kein Problem als ich nur Rails und PHP hatte, aber jetzt will ich ja noch was mit Django machen und da wird es dann schon ein bisschen komplizert.

Im Moment bedient der Nginx server (3 Prozesse an etwa 5MB) alle statischen files, sprich HTML, CSS, etc. selbst und spielt für

• Rails (2x Mongral à 50MB)
• PHP (3x CGI bei 20MB)
• Django (1x 50MB)

nur den Proxy. Wie man sieht kommt da schon ein bisschen was zusammen. Die Frage wieso den Rails und dann noch Django, würde ich einfach so beantworten: Man will auch mal was ausprobieren. Ein weiters Problem ist, dass die Prozesse auch immer unabhängig voneinander laufen und man immer alle einzeln starten oder stoppen muss, was zwar nicht schwierig, aber auch nicht gerade schön ist. Wer jetzt sagt, da kann man ja ein Skript schreiben, dem muss ich entgegnen, dass ich im Moment einfach kein Skript schreiben mag.

Daher habe ich mir mal überlegt, alles bis auf Rails mit Apache zu machen (da müsste ich die ganze Rails Geschichte nicht umkonfigurieren).

Das ist leider auch nicht gerade so einfach: Mein Server läuft nähmlich mit Plesk (ich mag auch keine qmail Dinge konfigurieren) und ist ein uraltes 6.06 LTS Ubuntu. Der hat leider nur Apache 2.0 welches kein mod_proxy_balancer Modul hat. Dieses wird benötigt um die Requests an den Mongrel Cluster weiterzuleiten. Daher fällt dieser Ansatz leider aus dem Rennen, da es mir zu mühsam ist, Apache2.2 und alle Module wie PHP neu zu kompilieren.

So schaute ich mich nach dem ominösen mod_rails um, welches in Wirklichkeit eigentlich Passenger heisst und man hätte so eine alles-aus-einer-Hand-Lösung.

Hier musste ich aber zuerst mal ein bisschen in der Apache Config Landschaft von Plesk zurechtkommen: Da kann man im Verzeichnis der jeweiligen Domain im conf Verzeichnis ein vhost.conf anlegen und noch die Config ändern. Bei Passenger erweckt man so einen Spawn-Prozess zum Leben (so um die 5MB), der dann, wenn mal einer auf die Seite kommt (bei mir nicht so häufig der Fall), die richtigen Prozesse die den Request handeln von der Leine lässt. Die fressen dann so um die 40-50MB und benötigen auch ein Weilchen um zu starten. Aber es wäre schon eine ganz feine Sache. Leider funktionierten die Rewrite Regeln von WordPress nicht mehr so wie sie sollten, aber scheinbar gibt es eine Entwicklungsversion bei der man gewisse Locations vor dem mod_rails schützen kann. Aber die habe ich gerade eben nicht.

Nächste Idee: Man nimmt den nginx als Proxy welcher die Request für Rails an Mongrel und den Rest (HTML, PHP, Python) an den Apache weiterleitet.

Hier grätscht das Plesk wieder mal brutal rein, da es doch ein paar wunderliche Eigenschaften hat: Die Domains können nur auf Port 80 oder 443 laufen. Wenn man aber den Ursprung des Bösen, also Plesks Master-Konfiguration für Apache, aus dem /etc/apache2/conf.d/ Verzeichnis verschiebt und auch die Listen Ports im ports.conf file ändert, ist es möglich eine Domain auf einem anderen Port (aber immer noch der öffentlichen IP und nicht dem localhost) laufen zu lassen. Man ist dann allerdings einer gewissen Willkür ausgesetzt, da Plesk ohne Vorwarnung die Configs wieder herstellen kann.

Obwohl ich nun vor lauter Optionen das eigentliche Problem vergessen habe, sehe ich doch folgende Möglichkeiten für mein Setup:

• “Passt scho”: Wie gehabt läuft alles mit nginx
• “Woat mo”: Warten bis Passenger die PassengerEnabled Direktive in die offizielle Version aufnimmt
• “Pock mas on”: Die Django App in Rails schreiben

Aber bevor das Geschwafel sein Ende nimmt sollte doch noch was gesagt werden: Obwohl ich eigentlich nur einen Server mit 256MB Speicher habe und jede Menge von Prozessen laufen lasse, läuft das Ding 1A.