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.