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.
on 2009-03-09 16:43
on 2009-03-09 16:52
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. Stefan -- Stefan Tilkov, http://www.innoq.com/blog/st/
on 2009-03-09 17:05
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. Grüße, Niko.
on 2009-03-09 17:22
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 Tilkov schrieb:
on 2009-03-09 17:32
On 09.03.2009, at 17:22, Daniel Weinand wrote: > 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. Cheers, Mathias -- http://paperplanes.de http://twitter.com/roidrage
Please log in before posting. Registration is free and takes only a minute.
Existing account
(Switch to SSL-encrypted connection)
NEW: Do you have a Google/GoogleMail or Yahoo account? No registration required!
Log in with Google account | Log in with Yahoo account
Log in with Google account | Log in with Yahoo account
No account? Register here.