Idealer Rails-Server

Question

Was ist der ideale Rails-Server? Nehmen wir an, seine auf einem VPS, wie Linode. Gehen wir davon aus, dass keine der Seiten das nächste Twitter werden wird, aber sie sollten gut skalieren. Er muss auch mehrere Sites unterstützen und alle Sites sind Rails 3. Und die Datenbank muss auf dem gleichen Server sein (für jetzt).

Sollte es Apache oder Nginx verwenden?

Ruby Enterprise Edition oder nur normales Ruby?

Ideale Linux-Distribution?

MySQL, PostgreSQL oder etwas anderes?

Wie sollten die Verzeichnisse aufgebaut sein (wohin mit den Rails-Sites oder sonstigem)?

Einsatzmöglichkeiten?

Sonst noch etwas?

Answer 1

Sollte es Apache oder Nginx verwenden? Nginx scheint hier der bevorzugte Weg zu sein, es sei denn, Sie benötigen spezielle Apache-Funktionen. Wenn Sie Passenger verwenden, werden sowohl Apache als auch Nginx unterstützt. Mehr über Passenger aquí .

Ruby Enterprise Edition oder nur normales Ruby? Ich bin mir ziemlich sicher, dass REE nur für Ruby 1.8 verfügbar ist, was nicht mehr die bevorzugte Version für Rails 3 ist. Rails 3 hatte einige Probleme mit 1.8, aber sie könnten sie inzwischen behoben haben. Im Allgemeinen läuft Ruby 1.9.2 jedoch gut mit Rails 3.

Ideale Linux-Distribution? Das spielt wirklich keine Rolle. Wenn Sie sich nicht sicher sind, ist Ubuntu eine gute Wahl, da es eine Menge Wissen gibt und es ziemlich einfach zu bedienen ist. Slicehost hat eine Reihe von großartigen Artikeln über die ersten Schritte mit einem VPS, und viele davon konzentrieren sich speziell auf Ubuntu: http://articles.slicehost.com/ .

MySQL, PostgreSQL oder etwas anderes? Dies ist definitiv subjektiv. MySQL ist auf jeden Fall am weitesten verbreitet, und wenn Sie sich wirklich unsicher sind, ist es ein guter Ausgangspunkt. Allerdings wird oft argumentiert, dass PostgreSQL sauberer und einfacher zu bedienen ist als MySQL. Wenn Sie gerade erst anfangen, würde ich MySQL empfehlen, allein schon wegen der Menge an Informationen, die es bereits gibt.

Wie sollten die Verzeichnisse aufgebaut sein (wohin mit den Rails-Sites oder sonstigem)? Sie können Ihr Rails-Projekt an einem beliebigen Ort ablegen, ich lege es am liebsten in meinem Home-Verzeichnis ab. Stellen Sie nur sicher, dass Ihr Webserver Zugriff auf Ihre statischen Assets hat.

Optionen für den Einsatz? Capistrano ist beliebt. Sie übertragen einfach Ihre Änderungen und cap deploy und schon kann's losgehen.

Sonst noch etwas? Wenn Ihnen das alles zu viel ist, sollten Sie sich eine einfachere Lösung wie Heroku . Sie richten alles für Sie ein, und obwohl Sie etwas an Flexibilität einbüßen, müssen Sie sich um nichts davon kümmern. Die Preise sind nicht allzu schlecht, und sie bieten eine kostenlose Option.

Answer 2

Ich denke, Kyl hat es ziemlich gut zusammengefasst. Aber ich dachte, ich würde Sie genau wissen lassen, was ich seit Schienen beta4 (und jetzt mit RC) verwendet habe. Dieses Setup hat gut für mich gearbeitet:

Rackspace Cloud-Server - Ermöglicht Ihnen die volle Kontrolle über den Server. Sie können die Größe Ihrer Server im laufenden Betrieb ändern. Sie können auch Schnappschüsse machen, wenn Sie Ihre Einrichtung für eine andere Website duplizieren wollen. Es ist billig und meiner Meinung nach besser als Amazon Cloud.

CentOS 5.4 - solide, aber wie kyl erwähnte, wird wahrscheinlich jede Distro gut funktionieren.

Ruby 1.9.2RC 2 - bisher keine Probleme mit Rails 3 bei mir. Wird auf jeden Fall Ruby Enterprise verwenden, wenn sie es auf 1.9.2 portieren (nicht sicher, ob das in den Werken ist, obwohl??)

Nginx - schnell und leicht. Ich mag es viel besser als Apache. Funktioniert gut vor Passagier, Mischling und dünn.

MySQL - Das ist eine persönliche Vorliebe. Ich benutze es schon seit Jahren. Es ist einfach, eine Master/Slave- oder Master/Master-Konfiguration einzurichten, wenn Sie skalieren müssen. Manche Leute haben Erfolg mit Sqlite, aber ich bevorzuge etwas, das etwas robuster ist.

Github - ein Muss für mich bei der Quellcodekontrolle. Bundler funktioniert sehr gut mit Github

Anwendungsserver - Ich bin immer noch am Überlegen, was ich damit anfangen soll. Ich war mit Passenger 2.2.15 zufrieden, bis ich sah, wie lange es dauerte, neue Ruby-Prozesse zu erzeugen, um Gleichzeitigkeit zu behandeln. Es dauert bis zu 30 Sekunden, um einen neuen Prozess für mich zu starten, und die Anwendung ist gesperrt, so dass keine Anfragen durchgehen können, während sie gestartet wird. Ich untersuche gerade, ob es meine App oder Rails 3 ist, die so lange zum Laden braucht. Dieses Problem ist jedoch mit Passenger 3 behoben. Hoffentlich wird das bald veröffentlicht. Als Folge davon werde ich wahrscheinlich Thin oder Mongrel verwenden, bis Passenger 3 herauskommt.

Capistrano - funktioniert hervorragend für Rails 3. Ich würde empfehlen, einige Rezepte für die Versionierung Ihrer App mit Git-Tags zu finden... oder schreiben Sie einfach Ihre eigenen.

Sonst noch etwas? Es hat zwar nicht wirklich etwas mit dem Server zu tun, aber ich würde empfehlen, die neue Plugin-API für jeden wiederverwendbaren Teil Ihrer Anwendung zu verwenden. Lesen Sie mehr über railties und engines. Es ist einfach, ein Gem mit Jeweler zu erstellen und es mit Github unter Verwendung von Jeweler Rake Tasks zu versionieren. Dann können Sie von einem Github-Tag oder von Master aus deployen, indem Sie das Gem und die Github-Quelle in Ihr Gemfile einfügen und es per Bundle installieren oder aktualisieren. Ich habe vor kurzem alle meine gemeinsamen App-Code (Blog, Authentifizierung, etc..) zu Rails 3 Motoren portiert und es funktioniert hervorragend. Und jedes Mal, wenn ich diesen Code wiederverwenden muss, füge ich ihn einfach in das Gemfile der neuen App ein.