Filed under: 1
You can’t always control your environment. I had to live with windows. And a 10-years-old system that deserve to be called legacy. Here’s how it went to add Rails into the mix
Setup to integrate with
Context matters. The full environment is Windows server 2003 running IIS 6 which is making available some C++ executable through plain CGI. These exe “controllers” are talking to and through MS SQL server 2000-2005. Yes that’s a web application in C++. So adding Rails to the mix is really bringing happiness into this.
Getting requests to Rails
IIS 6 doesn’t have any built-in way to redirect request to our friend mongrel. There’s an ISAPI filter that helps with this : ISAPI Rewrite 3. It mimicks Apache’s mod_proxy and mod_rewrite. It works well, is easy to setup and its stable, just like advertised as the recommended solution for windows in pragprog’s Deploying Rails application. It was very useful to boot our integration as first but it’s a 99$ commercial application and that was a deal breaker in the long run since the app needed to be deployed on many servers. That and the fact that it was impossible to reach anyone at that company willing to make a bigger deal that their set-in-advance volume discount.
OSS to the rescrue, Apache is available under Windows. So the real mod_proxy won. It ended up with a pretty standard configuration plus these line for the redirection
ProxyPass /legacy_path http://127.0.0.1:8080/legacy_path ProxyPassReverse /legacy_path http://127.0.0.1:8080/legacy_path ProxyPass /rails http://127.0.0.1:3000 ProxyPassReverse /rails http://127.0.0.1:3000
This effectively proxy and reverse proxy all request made for anything under /legacy_path to IIS, which is now listening on the 8080 port. All request made to /rails to our mongrel listening on the 3000 port. Luckily the legacy app was already scoped down under a single URL prefix. For the Rails app adding
ActionController::AbstractRequest.relative_url_root = '/rails''
after the Rails::Initializer.run block (inside environment.rb) was sufficient.
MS SQL server, not the typical first-class citizen in Rails world. The default connection to it was through ODBC. Not the fastest but with integration like this, the path of least resistance is the one to take. So here you go with two gems
gem install activerecord-odbc-adapter gem install odbc-rails
and a database.yml config (username & password should be removed for windows-based auth)
production: adapter: "odbc" dsn: "my_dsn_name" username: "username" password: "password"
Deployment and other integration tidbits
No fancy Capistrano for us, locked-in-windows-user. I needed to deploy the same app on multiple servers often without an internet connection. Freezing Rails did easily solved a good share of it but not all. The other native gems could not be vendored. I finally gathered the needed gems files and the one-click ruby installer. Here’s the shell food that turns them alive along with their dependencies.
install ruby silently ruby186-26.exe" /S Install mongrel gem install gem_plugin-0.2.3.gem --no-ri --no-rdoc gem install cgi_multipart_eof_fix-2.5.0.gem --no-ri --no-rdoc gem install mongrel-1.1.5-x86-mswin32-60.gem --no-ri --no-rdoc Install mongrel service gems gem install win32-api-1.2.0-x86-mswin32-60.gem --no-ri --no-rdoc gem install windows-api-0.2.4.gem --no-ri --no-rdoc gem install windows-pr-0.9.2.gem --no-ri --no-rdoc gem install win32-service-0.5.2-mswin32.gem --no-ri --no-rdoc gem install mongrel_service-0.3.4-i386-mswin32.gem --no-ri --no-rdoc Install ODBC support gem install activesupport-2.1.0.gem --no-ri --no-rdoc gem install activerecord-2.1.0.gem --no-ri --no-rdoc gem install activerecord-odbc-adapter-2.0.gem --no-ri --no-rdoc gem install odbc-rails-1.5.gem --ignore-dependencies --no-ri --no-rdoc Install mongrel as a service mongrel_rails service::install -N "service_name" / -p 3000 -e production -c "C:\path\to\rails\app" set it to auto-start sc config "service_name" start= auto
Having the database password in a non-clear text manner was requested for more or less rational security reason. This blog post showed me a nice solution. Not what I would call army-level-security but it fulfilled the request. It might also be useful to know that you can <% require some_file%> inside the yummy-yaml as well
I’m sure I’ve missed some details but the big picture is there. Wish it’ll be useful in some way to someone. If it’s the case please “comment-down” (as in the price is right) to bring more humanity here.
Leave a Comment so far
Leave a comment