When we were making Helicon Zoo our main goal, aside from technology integration, was to create simple and unified solution for hosting providers to offer all mainstream web technologies and application engines to users. And now with better integration into WebsitePanel 2.0 we are even closer to that goal. This article will show how to build the most advanced and technology-rich hosting and PaaS solution on a market.
Helicon Zoo is a solution to host web applications written on multiple technologies inside Microsoft IIS and as regular IIS web sites. These technologies include: PHP, Perl, Java, Ruby, Python, Node.js, Erlang and ColdFusion. And when we say, for example, Ruby we mean everything-Ruby. This includes Ruby on Rails, Sinatra, Thin, Goliath, simple Rack or FastCGI applications, etc. The same variety applies to other technologies like Java, Python, etc. Add here native IIS support for ASP and ASP.NET and you’ll get the most technology-packed hosting service available.
All these technologies can be installed on the same server, shared by all users and even mixed within one web site. Consider, for example, users may have their main web site content running on ASP.NET, blog made with WordPress (PHP), forum on DjangoBB (Python), online chat with Node.js, Git repositories with Java, helpdesk solution with Perl and e-commerce solution with Ruby on Rails – all running within the same IIS web site on the same server. Sounds hardly possible? Well, this is nearly how Helicon Tech web site works. Below please find instructions on how to set the same technology on your hosting.
Installing components
Helicon Zoo is delivered as a custom Microsoft Web Platform Installer repository, so all parts of the solution can be installed from one place and you can be sure that everything is tightly integrated and tested to work together.
New WebsitePanel 2.0 includes support for Web Platform Installer and Helicon Zoo repository is also enabled by default. So if you are using this hosting control panel, you need to simply select the server where you wish to install components and click on Web Platform Installer in the Server tools menu.
This will open Web Platform Installer interface where you can install many useful tools and components on your server, like MySQL, MongoDB, PostgreSQL and various IIS components like WebDeploy, URL Rewrite, etc. But we are here to install web application engines. In the Packages tab you can find complete and ready to use hosting packages for various web technologies.
Each of these packages includes everything needed to host applications of specific technology on your server and thanks to Web Platform Installer all required dependencies will be detected, downloaded and installed automatically. So select for example PHP Hosting Package, Java Hosting Package and Ruby Hosting Package and click install, then accept licenses and this will start installation process.
To install Java Hosting Package you will need to download and install Oracle JDK 7. Unfortunately, Oracle prohibits direct downloads of Java packages, this means we cannot include JDK into our repository and you will have to go to Oracle web site and run JDK installation manually. Other packages will install dependencies automatically. Ruby package, for example, includes Ruby 1.8, Ruby 1.9, Ruby DevKit, Thin, Sinatra, Goliath and of course Ruby on Rails 2 & 3, plus it depends on IIS itself and Helicon Zoo Module.
If you don’t plan to use WebsitePanel 2.0 to manage your server you can install Helicon Zoo hosting packages using Microsoft Web Platform Installer. Simply add this feed in Options dialog and install packages you need: http://www.helicontech.com/zoo/feed/
After installation is completed your server is ready to run selected technologies immediately. No other components or configurations are necessary. If you need to configure engines further or restrict customer access to some engines or maybe create custom configurations for running web applications, please read the next chapter.
Configuring Helicon Zoo
Helicon Zoo was designed with shared hosting environment in mind and is capable of functioning in a fully automatic mode. It delivers concept of web engines and applications: where web application is something that resides within user’s web site folder and that is executed by web engine, while web engines are declared globally by server administrator and are located in applicationHost.config. Each engine declares commands, options and environment settings which are used to execute application of particular technology. Hosting users can’t change engines; they can only run applications using them.
There is no need to enable Helicon Zoo engines anywhere after installation. The concept is the same as you normally expect from PHP or ASP applications – simply put the application files into the web site folder and they run. But with Helicon Zoo these files also include web.config file which is used to actually configure the application in a folder, so user web.config files should be enabled for this concept to work.
Applications are executed in the context of IIS Application Pool. This means that if you run each user’s web site in a dedicated Application pool (which is default in WebsitePanel), each application is executed in an isolated user’s environment and with restricted permissions. When user creates a web site or application and uses Helicon Zoo new backend application will be created.
Helicon Zoo can talk to backends using FastCGI or HTTP protocols. “Backends” are for example php.exe or ruby.exe processes. Helicon Zoo will manage backend processes automatically. By default one backend process is started for each application when IIS application starts. Helicon Zoo can then increase the number of backend workers as the load to the application increases to keep response times within reasonable boundaries. It will then shut down excessive workers automatically as load decreases to save server resources.
Engines are configured in applicationHost.config file as <heliconZooServer> <engines> and <userEngines> sections. If you want to edit some engine settings, copy it’s content from <engines> section to <userEngines> section first as engines section can be overwritten when Helicon Zoo Module is upgraded. You can read more about Helicon Zoo Module configuration in the product documentation.
User scenario
So now we have a web server that supports multiple web application technologies, but how will users actually install their applications to use on your servers? There are several options to do that:
Web Application Gallery
If you have WebsitePanel 2 on your hosting services, users can simply use Web Application Gallery to install applications and application templates for particular web technology. For example, assume that user is going to create new Ruby on Rails application. Since we already have Ruby Hosting Package installed on a server, user will open Web App Gallery:
Select Templates:
Scroll down to the Ruby on Rails project and click Install.
During installation user will have to choose a web site where to install the application and whether to put application into subfolder or web site’s root. After installation is completed application can be launched immediately right from WebsitePanel. After first application launch user can then edit and create files and scripts using normal development techniques for the applications of this type. It will be more convenient to download application files locally and work with them on client’s machine, then uploading files using FTP or WebDeploy.
Helicon Zoo provides templates for various web application technologies. List of these templates is constantly growing and updated. The content of each template project depends on the technology used. These projects usually include configuration files required to run application, some basic folder structure to hold static files, modules, etc., some scripts for application deployment and other useful components. We strongly recommend to use these application templates as a starting point for application development as these templates already include pre configurations and patterns for best development experience. If users already have some applications they want to host on your services, they can use application template available with Web Application Gallery to create a new application and then overwrite files in the template by the files of their actual application.
Web Platform Installer and WebMatrix
Another option for the user is to use Web Platform Installer to create a new application or template. The first thing to do here is to get Web Platform Installer from Microsoft. In Options add Helicon Zoo repository feed and select IIS Express as a target web server.
After that user can install any of the Hosting Packages on the client machine and get exactly the same environment as installed on a remote server that will run these applications online. Or user can bypass this step and install project template (like Ruby on Rails project) without installing hosting package, as all required components to run this application template will be downloaded and installed automatically, including WebMatrix and IIS Express itself. This will not probably allow user to run other types of Ruby applications, but the selected applications will run as expected.
After installation is completed WebMatrix will be launched running web application and providing file editors. It is possible to use Visual Studio or any other preferred web application IDE to work with these files.
Then use WebDeploy, FTP access or any other convenient way to upload application to the remote server.
Helicon Zoo applications are normally portable – you can move application from one machine to another simply by copying web application’s folder content, and as long as corresponding Hosting Package is installed on both machines application will run. Obviously if the application connects to a database or other remote services, this has to be taken into account.
One more thing to remember is folder permissions. With IIS Express and WebMatrix applications are usually executed with local user’s permissions (which has full permissions to the application folder), but on remote server applications are run in a restricted environment. Most of the applications require Write permissions to the web site folder for various reasons – write logs, store data, cache, intermediate pre-compiled scripts, save additional modules and components. We recommend enabling Write permissions for entire web site or application folder unless you know exactly which folder permissions should be given to your particular application. Insufficient Write permissions is the most frequent cause of the application failure. With WebsitePanel you can enable Write permissions in the web site’s security options.
Custom modules
The application template is installed and running but what happens if we need to install something more complex than a “Hello world” app? Many applications require additional modules to run. With Helicon Zoo we now have a concept where all modules and requirements of the application are installed inside the application work folder, which is usually user’s web site folder.
Previously web hosting administrators had to install a number of modules globally on the server and maintain up-to-date versions of every component, but with growth of web technologies variety, when new modules and versions are released every day, this becomes an overwhelming task. Different applications may require different versions of components and some of these components may conflict with each other. There definitely has to be a way to isolate application environments. Most modern web application frameworks support an ability to isolate applications and Helicon Zoo actively uses this technique. Each application template project available from Zoo repository includes code examples of how to install modules and components into local application folders.
Users have to be aware of these techniques and appropriate documentation has to be available. For example for Python applications users need to list all application dependencies in the requirements.txt file, instead of installing components globally on the development machine. This is a standard technique for application deployment and all components listed in these requirements.txt files will be installed automatically by deployment script. Users only need to understand that they have no permissions to install components on the server, instead they need to install everything inside the application folder.
Is it safe?
Frequent question from hosting providers – is it safe to allow users to install their custom components? The short answer is: there’s not more threat than allowing users to run their custom (PHP/ASP) scripts. Helicon Zoo executes everything in the context of IIS Application pool, there are no privileged processes or something that users can hack to gain more permissions than they already have. If you restrict permissions for IIS users on your hosting, then running custom modules is the same as running custom scripts on sites. Modules are installed inside user’s web site folder and executed with App pool permissions, no other user environment or global server settings can be affected.
Application deployment
One of the highly important features of Helicon Zoo is Application deployment. Complex applications usually require executing some operations before they could be launched on a server. These operations may include check for installed modules and their versions, download and installation of missing requirements, executing database scripts for data migrations, initialization of application files configurations and data structures. All these operations have to be executed outside of the main application context and before first request to the application will be handled.
Helicon Zoo provides means to execute deployment tasks on a remote server without having RDP or command line access and in restricted user environment. For example if you install one of the web applications available from Zoo repository, like Redmine or DjangoBB, you will see the “Application deployment in progress” message on the first request to the web site:
This application deployment process actually installs the application. You can see as various modules (gems) are installed, as database is created and configured, etc. And all these steps are taken in a local user’s environment with restricted user’s permissions. These application deployment scripts can configure only things inside web application folder or other resources available to user, but they are safe because they cannot change global components or write into shared or system folders.
Web application templates also include deploy script examples which can be used in the client’s applications. To learn more about application deployment with Helicon Zoo please read this documentation chapter.
Advantages of Helicon Zoo over existing solutions
Some of the web engines listed in this article can be executed on Windows and IIS without Helicon Zoo services. PHP is traditionally installed on IIS using Microsoft FCGI module, Node.js can run as a separate server or can be configured using iisnode, ColdFusion server supports Windows platform and can proxy sites into IIS using Jakarta connector. We don’t count other old solutions, like running apps as ISAPI modules (PyISAPIe) or executing scripts with CGI protocol as these solutions can’t be treated seriously because of their very poor performance. Here is a list of reasons why we think Helicon Zoo solution is better for providing shared hosting services:
- Unified environment. Helicon Zoo is a single tool to run all these technologies and it provides single administration point.
- Ability to run multiple technologies and versions on the same server and even same web site. For example you may have PHP 5.2, 5.3 and 5.4 installed and used on the same server at the same time.
- Better isolation. Every application is executed in the restricted environment with credentials of application pool user. There are no privileged processes (like with traditional ColdFusion). No data, processes or settings are shared between different hosting users.
- Custom modules. Users can have their custom modules installed into the application directory. No pain for administrators to maintain modules on the server. Additionally PHP users may have their custom php.ini files to configure PHP engine for their needs.
- Automatic process management. Backend processes are created and recycled automatically to satisfy demand of the application and free resources for other users when possible.
- Slow client optimization. With growth of the number of slow mobile clients this problem is becoming more significant. Synchronous web engines (like PHP) are very vulnerable to unbuffered slow connections and this vulnerability is often used as a DOS attack. Helicon Zoo buffers client communications protecting backends from slow connection problems.
- Application deployment. Ability to execute deployment tasks without having command line or RDP access to the server.
Other things to consider
Many free and open source web applications where designed with Apache environment in mind as it is currently the most popular web server, especially when it comes to open source. While Helicon Zoo provides environment for running numerous applications on IIS, you can make application fall into thinking that it is executed on Apache by emulating Apache environment inside IIS. Helicon Ape product does exactly this thing by bringing support for .htaccess and .htpasswd files and emulating most Apache modules inside IIS environment.
These modules are very useful, not only for URL rewriting, proxying or permission control. There are usage scenarios that can improve user experience significantly. Consider, for example, following articles illustrating some basic applications of Helicon Ape product:
- Search Engine Friendly (SEF) URLs for phpBB – doing search friendly URLs for phpBB with only several rules while phpBB does not support SEF URLs at all.
- Make your websites work faster – with caching and performance improvements.
- IIS reverse proxy and load balancer with web admin panel.
- Counting downloads from your site – how to make comprehensive counters for specific resources.
- Enabling site authentication not using Windows users.
- Prevent DoS attacks with Helicon Ape mod_evasive module.
- Protecting image gallery with Helicon Ape mod_hotlink.
Conclusion
Integration of Helicon Zoo and WebsitePanel is constantly improving. Our future plans are to integrate web application engines management into WebsitePanel interfaces. So the administrators will be able to choose which web engines users are allowed to run and manage restrictions in hosting plans. While it is possible to do this now by manually editing applicationHost.config files, web interface can significantly improve administrator performance. Users will also be able to turn web engines on or off for particular locations which can also add flexibility to the solution.
We will upgrade this article as new things come out and new questions get answered. Please stay tuned. You can read more articles about Helicon Zoo here.
While other companies invest hundreds of thousand dollars into development of their own cloud management solutions, you can already benefit from using free and powerful solution for running web applications on your facilities.
Please send your feedback to our support service or community forum.