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: > 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 09.03.2009, at 16:42, Daniel Weinand wrote: > >> 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ür >> staging 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. >> _______________________________________________ >> rubyonrails-ug mailing list >> [email protected] >> http://mailman.headflash.com/listinfo/rubyonrails-ug >> > > _______________________________________________ > rubyonrails-ug mailing list > [email protected] > http://mailman.headflash.com/listinfo/rubyonrails-ug > _______________________________________________ rubyonrails-ug mailing list [email protected] http://mailman.headflash.com/listinfo/rubyonrails-ug
