GeoServer production environment on Windows Server with IIS and Apache

In this post Andre explained how to set up a dev environment on win7 so Geoserver can coexist with IIS 7.5.

When it comes to deploying Geoserver to a machine that is exposed to the Internet things may go a bit more difficult. It actually took me a while to figure out how to make all the pieces work together so if you are in a similar situation - trying to run Geoserver on Windows Server - keep on reading.

We have decided to create a subdomain that will take all the traffic targeted at our Geoserver. Apart from looking unusual it certainly makes life easier when setting up rewrite rules for IIS. But let me explain it step by step.

 

1. Installing Apache Tomcat

I had some problems with Tomcat 7.0.6 and Geoserver 2.1RC1 (betas failed too) but luckily Tomcat 6.0.3 was ok. When installing the server it is worth to choose the service startup option so the Tomcat service starts automatically with WIndows. If you are running win x64 make sure you choose x64 JRE as well.

 

2. Making Tomcat pick a proper host name

By default Tomcat binds itself to the port 8080 an I have let it do so in this case as well. The problem though is that geoserver will pick the localhost:8080 for the capabilities documents and also for the example pages generated by the layer preview links. This is not a problem when working with geoserver locally but when accesssing it from another machine, the urls have to be resolved properly.

To make Tomcat know how of the host its pages are requested from I had to edit the tomcat/conf/server.xml file. By default the Connector tag does not have the proxyPort and proxyName properties so I needed to add them. proxyPort is the actual port the resource is requested through (the default is 80 and IIS listens at this port of course) and proxyName specifies the host name that will be used. Adding these two properties to the Connector section makes the geoserver report proxyName:proxyPort as the host name instead of localhost:8080 (in my case geoserver now uses http://geoserver.cartoninjas.net:80).

 

3. Deploying Geoserver

Since I have fixed the server.xml file I can start the Tomcat service and navigate to localhost:8080. After logging in I deployed Geoserver by using the war file available at the download page:

 

4. Setting a rewrite rule in IIS

Having installed Geoserver I was ready to route all the trafic to geoserver.cartoninjas.net to my Tomcat. I had the subdomain already created so there had to be a rewrite rule set appropriately. In my case I needed to have all the incoming traffic routed to localhost:8080:

 

5. Testing the geoserver from a remote computer

The final step was to test if everything worked ok. I have navigated to geoserver.cartoninjas.net/geoserver and tested the tiger ny layer group. It looked like everything was ok now ;-)

 

Why bothering with all the steps above? Initially I had the rewriting set in IIS and I could connect to geoserver through my subdomain. The actual problem though was with the capabilities documents but also with some of the automatically generated preview pages. Of course when knowing the actual resource location it was already possible to connect to the services exposed by geoserver. But clients trying to connect to the geoserver services automatically without knowing there was a problem with the host resolution would obviously fail. A dirty solution was to make the client application replace localhost:8080 with the actual host name and we had it working for quite a while. Luckily there was a bit more elegant way of fixng things and now we have our geoserver instance work as expected. I found that little proxy thing here.

blog comments powered by Disqus