Mir ist kein besserer Titel eingefallen. Es geht um die Fragte wie man
unter folgenden
Gegebenheiten eine Apache/Mongrel Umgebung am besten konfiguriert.
Aufbau ganz “klassisch”:
Webserver nimmt Anfragen entgegen und gibt diese aktuell per ProxyPass
und ProxyPassReverse an einen app-Server im internen Netz weiter. Wie
performant das
ist wenn der mongrel alles abarbeitet dürfte sich wohl jeder vorstellen
können. Aber
fürstaging Zwecke aktuell noch ausreichend.
Was ich jetzt gerne möchte ist dass die statischen Dateien alle direkt
per Apache ausgeliefert,
und die dynamischen Anfragen per mongrel_cluster bedient werden.
Gibt da auch jede Menge Infos im Netz, allerdings beziehen sich diese
immer auf eine
“1-Server Lösung”. Also die Anwendung liegt unter /var/www/railsapp und
somit können
ja die statischen Anfragen z.B. per RewriteCond per lokalem Apache
umgeschrieben werden.
Aktuell sehe ich jetzt verschiedene Möglichkeiten um das Problem in den
Griff zu bekommen.
Weiss aber nicht ob und welche da am besten umsetzbar ist.
a.) mounten des Rails Verzeichnisses vom app-Server auf dem Webserver,
und dann per
DocumentRoot und RewriteCond auf dem share arbeiten.
b.) Bei deployen zusätzlich eine aktuelle Programmversion auf dem
Webserver (nur public?)
zur Verfügung stellen und die statischen Dateien von dort ausliefern.
c.) Die ganz grobe Kelle, mit memcached oder sonstigem die statischen
Dateien zur Verfügung stellen.
Denke dank Capistrano sollte doch die Möglichkeit b.) relativ einfach
umsetzbar sein. Ist aber dann
allerdings ganz und gar nicht DRY.
Wie macht ihr das? Bzw. wie würdet ihr das umsetzen? Vielelicht habe ich
auch gerade nur ein Brett
vorm Kopf. Habe aufjedenfall nichts gefunden was ein solches Setup kurz
und bündig erklären
würde.
Die statischen Inhalte auf den Web-Server zu deployen, finde ich gar
nicht un-DRY - sie müssen ja dann nur noch dort verfügbar sein und
nicht mehr auf dem Mongrel-Knoten.
Ansonsten wäre ich für eine weitere Option, nämlich Squid, Varnish
oder mod_cache - damit werden nicht nur die statischen, sondern auch
die dynamischen (mit korrekten Headern ausgestatteten) Inhalte
performant ausgeliefert.
Wir benutzen einen Apache mit Passenger hinter einem Nginx (je auf
einer eigenen VM), der die statischen Inhalte ausliefert und Proxy
spielt. Beim Deployment bekommt der Nginx die statischen Files mit
deployed. Wenn wir wachsen, packen wir einfach mehr Apaches dahinter.
Stimmt auch wieder. Daran hatte ich jetzt natürlich nicht gedacht,
dass
die Dateien
in dem Fall ja auch nur auf einem Server vorgehalten werden müssen.
Denke
damit werde ich jetzt erstmal mein Glück versuchen. Erstmal Danke fürs
“zuhören”
und die Tips.
Die Frage ist doch, wieso ueberhaupt unterscheiden? Versuch es mit
Fire and forget. Deploy einfach auf deinen Web-Server wie du auf deine
App-Server auch deployen wuerdest. Entscheidend ist natuerlich nur das
public-Verzeichnis, aber wozu die Muehe? Der Platz sollte kaum eine
Rolle spielen, und beim Deployment, gerade bei diesem Thema ist DRY
eigentlich voellig unwichtig. Der einfachste Weg und der des
geringsten Widerstandes. In Capistrano eine neue Role fuer :web und
schwupps wird auch der sauber bedient.
Sharing ueber NFS ist schlichtweg evil, gerade wenn du eigentlich
performante, statische Inhalte schnell ausliefern willst, es sei denn,
das ganze kommt von einem SAN. Andernfalls ist es nur unnoetige Last,
die dein App-Server durchaus fuer andere Dinge gebrauchen koennte.
Im Uebrigen brauchst du auch bei dieser Version ordentliche Rewrites,
die entsprechend die statischen Inhalte ausliefern und nicht ins Proxy-
Backend reinreichen. Apache-Hausmittel reichen da insgesamt voellig
aus, bevor du gross mit Caches anfangen musst.
Stimmt auch wieder. Daran hatte ich jetzt natürlich nicht gedacht, dass
die Dateien
in dem Fall ja auch nur auf einem Server vorgehalten werden müssen. Denke
damit werde ich jetzt erstmal mein Glück versuchen. Erstmal Danke
fürs"zuhören"
und die Tips.
Stefan T. schrieb:
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
