Hallo ihr lieben,

ich bin gerade dabei meine Webseite zu machen weil so langsam nur "Hallo Welt" da stehen zu haben mich nervt. :P
Und diesbezüglich wollte ich mal so ein paar Grundlegende Sachen fragen und wissen zu denn Rack Kompatiblen Application-Server.
Es gibt ja neben dem Test-server Webrick denn man ganz sicher nicht in Product verwenden sollte auch unzählige andere wie z.b.

-Thin
-Puma
-Unicore
-Passanger
-Mongrel
-und ganz viele andere

Aber auch neben bei gibt es ja die HTTP Server wie

-Apache
-Nginx
-Lighttpd

Aber die Frage die sich mir jetzt stellt welchen sollte ich einsetzte und wie sieht das ganze dann aus ?
Wie habt ihr denn euer Setup gemacht ?
Nur ein Application-Server am laufen oder mit einem HTTP-Server vorgeschaltet?

Lasst es mich mal wissen und was ihr mir so empfehlen könnt zu dem Thema.

mfg Manchotix

Die Antwort auf diese Frage ändert sich gefühlt jedes halbe Jahr. Hier mal ein Test der Rack-Server von vor ca. 1 Jahr.

Für das Ausliefern von statischen Assets ist der nginx mein Favorit.

Ansonsten unicorn mit haproxy als LB.

_________________
Grüße
Jack

Ja das habe ich leider auch schon gemerkt :/ habe mich ja schon versucht schlau zu machen via google aber leider gibt es 20000 verschiedene Meinungen und Ansätze dazu.

Ok werde mir das mal merken und auch mal haproxy anschauen kenne ich noch gar nicht danke schon mal :)

Aber wie sieht es eigentlich aus eine Web-App nur durch denn Applications-Server zu Hosten ? Bin da gerade so bei Puma und überlege schon denn einfach Standalone laufen zu lassen.
Ist das so eigentlich eine gute Idee oder sollte ich dort lieber einen anderen Ansatz angehen ?

Bei der Auslieferung der Assets sind die APP-Server bis jetzt immer langsamer als nginx oder apache.
Wenn das nicht stört, kenne ich keinen Grund, warum man puma nicht standalone betreiben soll (solange es sich nicht
um mehrere APP-Server handelt).

_________________
Grüße
Jack

Ich setze seit Jahren auf Apache httpd als Frontend-Server für statische Dateien und Thin dahinter. Hat mir noch nie Probleme verursacht, und die Seiten, die ich betreibe, weisen nicht genug Traffic auf, alsdass ich auf eine performantere Lösung umsteigen sollte.

Früher wurde noch oft Passenger propagiert, aber davon habe ich so lange nichts mehr gehört, dass davon wohl abzuraten ist. Außerdem ist die Konfiguration eines Reverse Proxy jetzt kein Hexenwerk und reduziert die Angreifbarkeit des Frontend-Servers.

slowjack2k hat Recht, was statische Dateien angeht: da sind die „richtigen“ HTTP-Server wie httpd, nginx, usw. schneller und wohl auch sinnvoller. Aus eigener Erfahrung kann ich sagen, dass Thin bei der Auslieferung von wirklich großen (mehrere GiB) Dateien die Waffen streckt und allen Arbeitsspeicher verbraucht, den es kriegen kann. Außerdem ermöglichen sie umfangreichere Konfigurationsmöglichkeiten. Möglicherweise willst du ja noch mehr auf deiner Seite machen als eine einzige Ruby-Anwendung? Da ist bei einem reinen Application Server (die nicht ohne Grund so heißen) schnell Schluss. Außerdem würde ich mich, bevor ich ein solches Setup fahre, über den Sicherheitsaspekt informieren. Um an Port 80 zu binden, musst du zumindest kurzzeitig root sein, und ich denke (Vorsicht, nicht mit Nachweisen unterlegt), dass Application Server nur selten offen an Port 80 das Internet geklemmt werden und daher nicht dieselbe Sicherheitswartung erfahren wie ein „echter“ HTTP-Server, der speziell dafür gemacht ist.

Welchen der zahlreichen Application- und Frontend-Server du nutzt, hängt von den Anforderungen deines Setups ab, außer natürlich WEBRick, den man niemals in production benutzen sollte. Mit lighttpd hatte ich irgendwelche Probleme, an die ich mich gerade nicht mehr recht erinnern kann, sodass ich für leichtgewichtige Seiten, die nicht viel Konfiguration benötigen, auf Hiawatha umgestiegen bin, den ich aber noch nicht zusammen mit einem Ruby-Application-Server benutzt habe (sondern nur für reinen statischen HTML-Content). Das muss aber nichts heißen, evtl. ist lighttpd auch das, was du suchst.

Generell wird es bei deiner persönlichen Website faktisch nicht ins Gewicht fallen, welche Kombination du nimmst. Es gibt Spezialserver für spezielle Anwendungsfälle (etwa den speziell für Seiten mit wenig Traffic entwickelten yahns von Eric Wong), aber für eine Website ohne viel Traffic sollte man die Kombination einsetzen, die einem am meisten zusagt. Sprich, verabschiede dich von Kriterien wie Performanz und suche dir solche, die deiner persönlichen Website, die wohl kaum tausende gleichzeitige Verbindungen aufweisen wird, angemessen sind. Etwa Komplexität der Konfigurationssyntax oder Verwendbarkeit für weitere Anwendungen. Oder Speicherverbrauch. Oder Plattenplatz. Kleine Server haben von beidem nicht viel, sodass hier etwas zum Kriterium wird, das die meisten Appserver-Entwickler nicht auf dem Schirm haben, weil sie für die großen Websites entwickeln, bei denen derartige Probleme naturgemäß nicht auftreten.

Das ist auch der Grund, warum ich als Frontend-Server bisher nicht auf nginx gewechselt bin — mein Blog besteht nur aus statischem HTML, mit der Kommentarfunktion als winzige CGI-Anwendung, weil mehr Flexibilität einfach nicht nötig ist und mir mehr Wartungsaufwand verursachen würde. nginx kann aber kein CGI (der Versuch, es trotzdem zu machen, endet gruselig). Damit entfiel nginx für mich und es läuft weiterhin Apache httpd, oder eben Hiawatha.

Vale,
Quintus

_________________
Habe den Mut, dich deines eigenen Verstandes zu bedienen! — Immanuel Kant

Ich bin freischaffender Softwareentwickler und freue mich über jedes neue Projekt. Kontaktinformation auf meiner Website.

Mein Blog | GitHub-Profil | Auf Twitter: @qquintilianus | PGP/GPG-Schlüssel: B1FE 958E D5E8 468E AA20 8F4B F1D8 799F BCC8 BC4F