Recently released Helicon Zoo is a repository of popular web frameworks for Microsoft IIS. It makes installing and running Django, Ruby on Rails and Mojolicious on Windows Servers a piece of cake.
THIS ARTICLE IS OUTDATED
Please read following articles to find information how to run Django, Rails and other popular web engines on IIS:
- Running Django on Windows (with performance tests)
- Node.js on Windows (with performance tests)
- Ruby on Rails on Windows in production
- Deploying Java Servlet applications on Windows with IIS
- Running Railo on IIS in production
And you can find usage examples for various web engines on a usage page.
How it works
Helicon Zoo utilizes Microsoft Web Platform Installer (WebPI) to make installation of web frameworks and all required dependencies easy and smooth. At first, you need to download and install WebPI from Microsoft web site here. This is a great tool that is already packed with many ASP.NET and PHP applications and dependencies to install a whole technology stack on your server. And the greatest thing about WebPI is that it can be extended by adding custom repositories. So copy this link – http://www.helicontech.com/zoo/feed/, open WebPI options
put it into the Display additional scenarios field and click Add feed.
Now if you select Applications, Tools at the bottom of the list, you will find new applications: Blank Django Project, Blank Rails Project, Blank Perl Project, Blank Mojolicious Project
These are all empty “Hello World!” applications used to install all required dependencies which you can stuff with your code later.
So let’s choose Blank Django Project, click Add and Install. This will create new IIS application with pre-defined configuration. After download and installation are completed you can use Launch application in browser link:
What’s inside
The core of Helicon Zoo is a native IIS 7 (or IIS Express) module that provides FastCGI support. This module differs from Microsoft FCGI module generally developed to provide PHP support for IIS. Helicon Zoo Module is built using super capacitive asynchronous I/O Completion Port technology. It supports Pipe and TCP transports and additional level of configuration to run many different FastCGI-enabled frameworks. These includes flup tor Python, Rack for Ruby on Rails, FCGI and Plack for Perl and Mojolicious.
The core configuration of Helicon Zoo Module is located in the <heliconZooServer>
section of applicationHost.config file. This section defines all FastCGI engines that will work with Zoo. Here is an example of Django FastCGI engine definition using pipe transport; zoofcgi.py is our Python worker with pipe transport support:
<engine name="python.2.7.pipe"
fullPath="c:\python27\python.exe"
arguments="-O %SystemDrive%\Zoo\Workers\python\zoofcgi.py"
transport="pipe" />
How to deploy Django projects
Helicon Zoo offers simple way to deploy your Django applications on the server or test machine. First you install Blank Django Project in desired location using Web Platform Installer, then you overwrite this project content with your project files and set up deployment into this forlder. Blank Django Project installs all required dependencies on target machine and puts web.config (the only file needed for your application) in the root directory of application.
Web.config
Configuration of Zoo-powered applications is done with web.config file. Here is an example of such file to configure Django application for 32-bit.
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<heliconZoo>
<application name="django.project.x86" >
<environmentVariables>
<add name="PYTHONPATH" value="%APPL_PHYSICAL_PATH%;%PYTHONPATH%" />
<add name="DJANGO_SETTINGS_MODULE" value="settings" />
</environmentVariables>
</application>
</heliconZoo>
<handlers>
<add name="django.project.x86"
scriptProcessor="python.2.7.pipe" path="*" verb="*"
modules="HeliconZoo_x86" preCondition="bitness32"
resourceType="Unspecified" requireAccess="Script" />
</handlers>
</system.webServer>
</configuration>
Several important things are defined here:
scriptProcess="python.2.7.pipe"
— a reference to FastCGI engine defined in the applicationHost.config;- environment variable
PYTHONPATH
— a path where Python will check to load modules. Here path to this IIS application is appended to allow Python to load additional modules directly from the directory of your application without installing them globally in the system. - environment variable
DJANGO_SETTINGS_MODULE
— a Python path to the configuration file settings.py of your Django project, for example ‘mysite.settings’.
Static content
It is recommended to serve static content omitting Django to save processor time and increase performance. You can easily do this by putting all static files into a directory with the following web.config in it. This will disable Django module in directory:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<handlers>
<remove name="django.project.x86" />
</handlers>
</system.webServer>
</configuration>
Django configuration example
Let’s assume our Django project consists of three applications:
site
— a site itself with pages templates, static files, urls.py and settings.py;blog
;store
.
Static files are located in site/media and are available as /media/ virtual directory (i.e. MEDIA_URL='/media/'
).
After we install Blank Django Project in the root of web site and copy our Django application project in it we will have the following directory structure:
/media/
— is a virtual directory which is mapped to site/media
and Django is disabled there using web.config file example above. In the root web.config PYTHONPATH
points to the site root directory and DJANGO_SETTINGS_MODULE
is set to site.settings
:
...
<heliconZoo>
<application name="django.project.x86" >
<environmentVariables>
<add name="PYTHONPATH" value="%APPL_PHYSICAL_PATH%" />
<add name="DJANGO_SETTINGS_MODULE" value="site.settings" />
</environmentVariables>
</application>
</heliconZoo>
...
That’s all!
Sincerely, Helicon Tech team.
The default Python project works fine but I have a problem with a more complex project that I’m trying to launch with IIS7. The same project launches in the development server but in IIS it returns an error:
Unhandled Exception
An unhandled exception was thrown by the application.
How can I know what went wrong? It looks like the error happens before Python captures the exception. Could that be a problem with the pipe?
Alex,
please write letter to [email protected] and we will investigate your case.
Thanks.
Try running python ./manage.py syncdb on the server from the commandline. I did this and found I had a dependency missing.
In two words: bril jant.
After pulling my hair out for weeks trying to get Python to work on IIS on any protocol but old cgi, you finally solved that part of my problem by really enabling FastCGI..
There remains a challenge though: debugging. I use WingIDE to step through code etc but I can’t get it up and running nor hook into it within the IIS embedded process. I guess I can tweak things by loading a nix server, pointing it at tcp port X not listening to it, while in reality having a long running process (manually started) listening to that port. It’s not trivial to set up from where I stand so if somebody has a better idea or pointers towards it I’m eager for it.
I have to say: I used some php and I can really understand why so many people are drawn to it because of the zend-debugger and ease of setup. If Python would reach that ease it would pull in a lot more of serious programmers and give it really the momentum it deserves.
Hello Robert,
Helicon Zoo was developed as solution for running python and django projects in production.
The right common way is debugging your project locally, inside your IDE. All modern Python IDE (WingIDE, Komodo, PyCharm and PyDev) have good debugging tools.
Debugging python applications running in IIS via Helicon Zoo is unsuitable way.
Thanks for your answer. I resolved my issue.
Personally I think this HeliconZoo dll beats all other solutions including pyIsapi which isn’t even rightly compiled for Python27 and then I couldn’t get it to work anyway *shrug*
I’m trying to understand how the connection, port communication etc with IIS works so I wanted to step through flup code etc. I can now do that.
I use WingIDE and found out it was actually a well justified security block that was resolved with a minor tweak . I can debug like a champ now, easy as sliced bread. It’s actually kind of logical since the IIS process runs as a different user.
I have IIS on my local laptop to mimic as must as possible a live server, I think it’s suitable to develop that way, but that’s a whole different discussion.
I think you should promote this dll more, right now it’s well hidden in the products you deliver but it could be more of a flag on your ship.
Another thing is, the moment I ever encounter a problem on my live windows server I can now easily hook into the live process and troubleshoot a Python request. I understand that it’s not the ‘proper’ way but this way of working helped me out tons of times in my life. The database on my server is about 1 terrabyte and the functionality of my application is largely dynamically steered by the contents of my database, including code snippets and the evaluation of logical expressions that are in the database. No way I can copy and reproduce everything 1 on 1 to my development machine.
Thanks. I’ll leave php behind and never look back.
Can you give more information about how you were able to look at the live process? I am having a file upload problem and would love some visibility into what’s going on. I usually develop for linux but this client has windows service level agreement : (.
Thanks for any help you can provide!
Thank you guys for an amazing product
really good job.. thanks
Fantastically useful bless you, I reckon your visitors will probably want further stories such as this keep up the excellent content.