Habt Ihr schon einmal versucht, HTTP-Server und ColdFusion-Server auf getrennten Maschinen laufen zu lassen? Wie das manchmal so ist, man liest eine TechNote zu dem Thema und hat dann direkt auch einen echten Grund, das mal auszuprobieren
Maschine A (192.168.1.1)
Win 2k, installierter Apache 2.0.45 in d:\apache2
Maschine B (192.168.1.2)
Win 2k, installierter CFMX, Updater 3 in c:\CFusionMX (mit Stand-alone Webserver auf Port 8500)
Auf beiden Maschinen muss mind. eine JRE 1.3.1 installiert sein. Auf Maschine B ist das sowieso der Fall, da ja CFMX darauf lÀuft.
1. B: Man kopiert die Datei c:\CFusionMX\runtime\lib\wsconfig.jar in einen beliebigen Ordner auf A, diese Datei wird benötigt, um auf A den HTTP-Server Connector zu ColdFusion MX auf B einzurichten. Hier ist der beliebige Ordner d:\CFMXConnector
2. A: Einrichten des Connectors:
c:\Programme\JavaSoft\JRE\1.3.1_03\bin\java -jar d:\CFMXConnector\wsconfig.jar -ws Apache -conf d:\Apache2\conf -map .cfm,.cfc,.cfml -v -host 192.168.1.2
Hierbei unterstelle ich mal, dass die JRE auf A unter c:\Programme\JavaSoft\JRE\1.3.1_03 installiert wurde.
3. B: Kopieren des /CFIDE-Ordners aus c:\CFusionMX\wwwroot in das Webroot von Apache auf A (d:\Apache2\htdocs)
4. Jetzt sollte man auf A den ColdFusion-Administrator ausfĂŒhren können (http://192.168.1.1/CFIDE/administrator/index.cfm), was durchaus nicht selbstverstĂ€ndlich ist, da dort ja kein CFMX-Server lĂ€uft.
5. Im ColdFusion-Administrator sollten man nun das /-Mapping des CFMX-Servers auf den entsprechenden neuen physikalischen Pfad des Apache-Webroots setzen (von c:\CFusionMX\wwwroot auf d:\Apache2\htdocs)
Wichtig dabei ist, dass das Verzeichnis auf beiden Servern existieren muss, d.h. man muss auf B das Verzeichnis d:\Apache2\htdocs anlegen.
6. B: In der Datei c:\CFusionMX\runtime\servers\default\SERVER-INF\jrun.xml
muss der interne Stand-alone Webserver deaktiviert werden. Das erreicht man, indem man in der Datei den Block mit
<service class=âjrun.servlet.http.WebServiceâ name=âWebServiceâ>
sucht und darunter den Parameter
<attribute name=âdeactivatedâ>false</attribute>
von false auf true umsetzt.
Fertig
Nun hat man folgendes erreicht. Anfragen an die Anwendung (bestehend aus HTML- und ColdFusion-Elementen gehen an Maschine A, diese ist der Webserver. Auf dieser Maschine liegen im Ordner d:\Apache2\htdocs auch alle statischen Dateien, die nicht von ColdFusion compiliert werden mĂŒssen, d.h. alles ausser .cfm und .cfc. Trifft der Apache auf A auf eine solche Datei reicht er den Request an B weiter, dieser bearbeitet ihn und liefert die Response ĂŒber A an den Client zurĂŒck.
Das setzt natĂŒrlich voraus, dass man auf A und auf B identische Ordnerstrukturen vorhĂ€lt und die Files der Anwendung entsprechend verteilt.
Ein Beispiel:
Vorher: Apache und CFMX auf einer Maschine
d:\Apache2\htdocs\App1\
index.cfm
bilder.html
test1.jpg
Nachher:
Maschine A
d:\Apache2\htdocs\App1
bilder.html
test1.jpg
Maschine B
d:\Apache2\htdocs\App1
index.cfm
Obwohl die Datei index.cfm auf A (dem Webserver) also physikalisch nicht vorliegt, kann man http://192.168.1.1/App1/index.cfm aufrufen, alle internen Pfade zu Verlinkungen, Bildern, Includes etc. bleiben erhalten â natĂŒrlich nur unter der Voraussetzung, dass die Ordnerstruktur auf A und B identisch ist.
Was bringt das ganze? Durch die Trennung der statischen und dynamischen Teile einer Applikation nimmt man Last vom eigentlichen Application Server, der nur noch die reinen ColdFusion-Requests bearbeiten muss.
Und im nĂ€chsten Teil (irgendwann demnĂ€chst) gibtâs dann eine EinfĂŒhrung in ClusterCats mit ColdFusion
TechNotes zum Thema:
Comments on this entry are closed.