Nun hatte ich mich die letzten Tage wieder etwas mit dem Thema RoR Deployment befasst und herausgefunden, dass sich hier in der Zwischenzeit viel getan hat. Dank dem Phusion Passenger (aka mod_rails) Projekt.  Habe es vorhin direkt mal ausprobiert und bin davon sehr begeistert. Super performant, super einfach, super super.

Werde demnächst dann wohl wieder etwas mehr mit Ruby on Rails machen

Ähnliche Artikel

• Debian: Von Apache zu Nginx – Teil 4: Einen Tomcat anbinden
• Debian: Von Apache zu Nginx – Teil 1: Vorwort
• Wordpress unter Nginx

• Teil 1: Vorwort
• Teil 2: Installation und Konfiguration
• Teil 3: PHP
• Teil 4: Einen Tomcat anbinden
• Teil 5: Basic Authentication

Ich möchte den Nginx auch auf meinem Notebook verwenden um dort die gleiche Umgebung wie auf dem Server zu haben. Und auch die gleiche Performance.

Da ich aber in der Firma mit dem Tomcat arbeite (den ich zur Zeit über mod_proxy an den Apachen angeklingt habe), muss ich meinen Nginx auch entsprechen konfigurieren. Da die Proxy-Funktionen im Nginx kein Modul sind, sondern der Nginx selbst ein Proxy-Server ist, ist das spielend einfach:

server {
    server_name ci.itws.de;
    root /var/www/itws.de/ci;

    index index.jsp index.html index.htm;

    proxy_pass http://localhost:8080;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;
}

Ähnliche Artikel

• Debian: Von Apache zu Nginx – Teil 1: Vorwort
• Deployment von Ruby on Rails Applikationen
• Wordpress unter Nginx

• Teil 1: Vorwort
• Teil 2: Installation und Konfiguration
• Teil 3: PHP
• Teil 4: Einen Tomcat anbinden
• Teil 5: Basic Authentication

In diesem und den folgenden Beiträgen (es gibt jeden Tag einen) berichte ich euch ein wenig über meine Migration von Apache zu Nginx. Es war eigentlich nicht beabsichtigt, dass da ganze fünf Beiträge draus werden, aber irgendwie wurde es doch ziemlich viel Text und das war dann für einen einzelnen Artikel etwas zu viel. Da könnte man ja fast den Eindruck bekommen, ich würde gerne schreiben … Keine Angst, das einzige was ich gerne in großen Mengen schreibe ist Programmcode

However, ich hatte meinen VPS (Debian 6) bisher immer mit dem apache2 betrieben und auch meine Entwicklungsumgebung auf meinem Desktop und dem Notebook ebenfalls. Das hatte mehrere Gründe. Zum Einen bin ich mit dem Apache aufgewachsen und hatte eigentlich nie etwas anderes verwendet. Ich war auch immer sehr zufrieden mit dem Apachen. Es ist ein guter Webserver mit einer großen Auswahl an mächtigen Modulen und er ist sehr leicht zu konfigurieren. Da ich aber ab und an gerne etwas Neues ausprobiere und immer Spaß daran habe, an meinem Server zu schrauben (auf Software-Ebene), wollte ich mal einen anderen Webserver ausprobieren. Genaugenommen war das Projekt yaana.de einer der Auslöser. Ich möchte da noch etwas Performance aus dem Server quetschen. Und dafür sollte ich mich zu allererst vom Apachen verabschieden.

Zur Auswahl stehen also – neben dem Apachen – Lighttpd und Nginx (ausgesprochen: engine-x).

Zu allererst ein kurzer Überblick der Vor- und Nachteile der drei Kontrahenten: Apache, Lighttpd und Nginx:

Der Apache

Vorteile

• Open Source & Kostenlos
• Community. Apache ist der am meist verbeiteste Webserver, die Community dahinter ist entsprechend gigantisch.
• Module. Es gibt unzählige Module für den Apache um praktisch jede Funktionalität abzudecken

Nachteile

• Performance. Der Apache ist um einiges langsamer als seine Konkurenten. Vor Allem wenn es um das Ausliefern von statischen Dateien geht.
• Stabilität. Der Webserver hat schon mit schwachen DoS/DDoS Attacken Probleme, der Arbeitsspeicher (und das Logverzeichnis) verbrauchen innerhalb kurzer Zeit viel Speicher.
• Veraltet und überfüllt. Außerdem ist die Standard Konfiguration meistens nicht optimal und muss angepasst werden.
• Die Entwicklung läuft vergleichsweise langsam.

Der Lighttpd

Vorteile

• Open Source & Kostenlos
• Leichtgewichtig. In Version 1.4.13 benötigt der Lighty nicht mehr als 2Mb RSS auf einem VPS. Ein einzelner Prozess erledigt alles, selbst wenn 100 Connections eingehen.
• Geschwindigkeit. Die Auslieferung von statischen Dateien geschieht mit einer unglaublichen Geschwindigkeit. Das FastCGI und das Proxy Serving ist ebenfalls rasant schnell.
• Module. Es gibt gefühlt unendlich viele Module mit einer guten Dokumentation.
• Mod_magnet ist eine Scripting Engine direkt im Webserver. Das Modul integriert Lua in lighttpd.
• Community. Einen Blog, ein Wiki/bug tracker und ein Forum. Hier findet man immer Hilfe

Nachteile

• Geringe Stabilität gerade was HTTPS+Proxy in Kombination mit Python oder Ruby angeht.
• Kein Mod_rewrite. Die Built-in rewriting engine ist Schrott, und das Portieren der Apache mod_rewrite Regeln ist nicht ganz einfach.
• Memory leaks. Und diese wurden seither nicht gefixed.
• Die Entwicklung läuft vergleichsweise langsam.

Nginx

Vorteile

• Open Source & Kostenlos
• Leichtgewichtig. Zwar nicht ganz so leicht wie der Lighty, aber dennoch nicht so Ressourcenhungrig wie der Apache.
• Schnell. Einie benchmarks haben gezeigt, dass Nginx deutlich schneller ist als der Lighty und der Apache. Gerade was die Auslieferung von statischen Inhalten angeht.
• Module. Ähnlich wie bei den beiden anderen Kontrahenten gibt es auch hier mehr Module als man benötigt. Während Lighttpd eine Lua scripting engine besitzt, kann man den Nginx mit dem Perl Interpreter aufmotzen.
• Besseres Rewrite Modul. Ein sehr viel besseres Rewrite Modul als Lighttpd mit komplexen Bedinungen. Das Portieren von mod_rewrite Regeln vom Apache ist vergleichsweise einfach.
• Stabil und keine leaks. Keine Probleme bekannt.
• Sehr schnelle Entwicklung: Es gibt fast monatlich Updates
• Die Konfiguration ist einfach und übersichtlich.

Nachteile

• Kleine Community. Es gibt einen IRC und ein Wiki. Dann wirds auch schon eng.
• Nginx kann keine FastCGI Prozesse erstellen. Das muss dann über einen externen fcgi spawner geschehen.

Der Lighttpd kam bei mir eigentlich nie wirklich in Frage. Das hatte zwei Gründe:

1. Ist die Konfiguration wirklich hässlich Sorry aber ich bin da etwas sensibel.
2. Weil der Lighttpd ein paar Memory Leaks hat, die seit Jahren nicht gefixt werden.
3. Hatte ich mir bereits vor längerer Zeit die Rewrite Rules vom Lighty angesehen – eher durch Zufall darauf gestoßen und dann aus Neugierde recheriert – das hat mich direkt abgeschreckt.

Also fällt auf meine Wahl auf den hochangepriesenen Nginx Proxy-/WebServer, mit dem mittlerweile rund 7% des World Wide Webs betrieben werden. Darunter high-visibility Platformen wie WordPress.com, Github, Ohloh, SourceForge, Golem.de uvm. Außerdem verspricht dieser nicht nur mehr Performance sondern auch eine einfachere Konfiguration.

Auch wenn mich der Part mit dem FastCGI Prozessen etwas nerven wird. Mal sehen vielleicht finde ich dafür ja noch eine saubere Lösung.

Anforderungen

Ich habe natürlich einige Anforderungen an den Webserver. Damit ich meinen Server migrieren kann, benötige ich folgende Funktionen:

• RewriteRules für .htaccess files
• Basic Authentication
• Virtuelle Hosts
• PHP
• Einen Proxy um den Java Webserver dahinter anzubinden

Nginx ist nicht nur ein Webserver sondern auch ein POP3/IMAP-Proxy und ein reverse Proxy. Letzteres Problem war also schonmal gar kein Thema weil der Server einfach exakt für solche Dinge designed wurde. Auch Mongrel lässt sich sehr sehr gut mit Nginx betreiben, wie ich gelesen habe.

PHP lässt sich über FastCGI anbinden, was deutlich performanter ist als mod_php für den Apachen, da PHP somit nicht bei jedem Request mitgestartet wird. Was mir hier noch etwas Sorgen bereitet, ist das nicht vorhandene Feature vom Nginx, FastCGI Prozesse zu starten. Glücklichwerweise bringt PHP5 einen eigenen FastCGI Prozess Manager mit sich: PHP-FPM. Das erleichtert die Anbindung von PHP ungemein.

Virtuelle Hosts, Basic Authtentication und RewriteRules sind für moderne Webserver ohnehin bereits Standardumfang. Und die Rewrite Rules von Nginx sehen sogar ganz brauchbar aus (wenn es um das Portieren von  mod_rewrite Regeln geht). Sollte also alles kein Thema sein.

Bleibt noch eine kleine Anforderung: Die Verzeichnis-Struktur. Meine bisherige Verzeichnis-Struktur sieht wie folgt aus:

/var/www/hostname/subdomain/

Entsprechend gibt es folgende Verzeichnisse:

• /var/www/itws.de/blog
• /var/www/itws.de/ci
• /var/www/yaana.de/www
• /var/www/yaana.de/blog

Und einige mehr.

Diese Struktur will ich natürlich beibehalten. Es hätte mich nun gewundert, wenn das nicht gehen würde. Nach kurzer Recherche, war ich mir sicher, dass das kein Thema sein wird.

Es kann also los gehen.

Ähnliche Artikel

• Debian: Von Apache zu Nginx – Teil 3: PHP
• Debian: Von Apache zu Nginx – Teil 4: Einen Tomcat anbinden
• Debian: Von Apache zu Nginx – Teil 2: Installation und Konfiguration

Schritt 1: Das Arbeitsverzeichnis

Zuerst legen wir uns ein Arbeitsverzeichnis an, der Eclipse-Workspace. Hier werden später die Projekte abgelegt. Außerdem dient das Verzeichnis als DocumentRoot für den Apache:

ghost@spacebox:~$ mkdir workspace

Fertig. Langweilig, ich weiß

Schritt 2: Der Apache

Installieren des Apachen mit mod_php5:

ghost@spacebox:~$ sudo aptitude install apache2 libapache2-mod-php5

Einrichten der DocumentRoot:

ghost@spacebox:~$ sudo vim /etc/apache2/sites-avilable/default

Es öffnet sich der vim mit der default site, welche wir wie folgt anpassen ([i] zum Bearbeiten):

<VirtualHost *:80>
    DocumentRoot /home/ghost/workspace

    <Directory />
        Options FollowSymLinks
        AllowOverride None
    </Directory>

    <Directory /home/ghost/workspace>
        Options Indexes FollowSymLinks MultiViews
        AllowOverride All
        Order allow,deny
        allow from all
    </Directory>

    (...)
</VirtualHost>

[esc], ":wq", [enter] speichert und schließt die Datei.

Anschließend muss der Apache reloaded werden, das funktioniert wie folgt:

ghost@spacebox:~$ sudo /etc/init.d/apache reload

Zum Testen legen wir innerhalb des workspace-Verzeichnisses eine index.php an:

ghost@spacebox:~$ cd workspace
ghost@spacebox:~/workspace$ echo 'Hallo Welt!'  > index.php

Im Anschluss dazu rufen wir im Browser die URL "http://localhost/index.php" auf.
Wir erhalten eine weiße Seite und ein "Hallo Welt!".

Schritt 3: Der MySQL-Server

Zuerst den MySQL-Server und den Client installieren:

ghost@spacebox:~$sudo aptitude install mysql-client-5.1 mysql-server-5.1

Während der Installation wird man dazu aufgefordert ein root-Passwort für den MySQL-Server festzulegen, dort ein beliebiges Passwort eingeben und selbiges bitte merken

anschließend ein Verbindungstest zum Server:

ghost@spacebox:~$ mysql -h localhost -u root -p

Nach der Eingabe des korrekten Passworts, welches wir eben bei der Installation festgelegt haben, startet die mysql-Shell:

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 34
Server version: 5.1.41-3ubuntu12 (Ubuntu)

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql>
 

Schritt 4: Die PDT

Die PHP Development Tools ist eine auf Eclipse basierende Entwicklungsumgebung für PHP.

Zuerst laden wir uns das tar.gz-Archiv, welches wir auf der offiziellen Website finden und entpacken dieses anschließend nach /opt/eclpse:

ghost@spacebox:~/Desktop$ sudo tar xvzf eclipse.tar.gz -C /opt/

Über einen Rechtsklick auf das Gnome bzw KDE-Menü kann mit Hilfe des "Menü bearbeiten"-Tools ein Menü-Eintrag für Eclipse angelegt werden. Der Befehl zum starten von Eclipse lautet:

/opt/eclipse/eclipse

Nun stehen  Apache und MySQL zusammen mit PDT zur Verfügung. Der Apache und der MySQL-Server starten bei jedem Booten des Systems automatisch und müssen daher nicht manuell gestartet werden.

Ähnliche Artikel

• Debian: Von Apache zu Nginx – Teil 1: Vorwort
• [PHP] Der include path
• Debian: Von Apache zu Nginx – Teil 4: Einen Tomcat anbinden