I’m looking for a PaaS provider that isn’t going to cost me very much (or anything at all) and supports Flask and PostGIS. Based on J5’s recommendation in my blog the other day, I created an OpenShift account.
A free account OpenShift gives you three small gears ((small gears have 1GB of disk and 512MB of RAM allocated)) which are individual containers you can run an app on. You can either run an app on a single gear or have it scale to multiple gears with load balancing. You then install components you need, which OpenShift refers to by the pleasingly retro name of cartridges. So for instance, Python 2.7 is one cartridge and PostgreSQL is another. You can either install all cartridges on one gear or on separate gears based on your resource needs ((I think if you have a load balancing (scalable) application, your database needs to be on its own gear so all the other gears can access it.)).
You choose your base platform cartridge (i.e. Python-2.6) and you optionally give it a git URL to do an initial checkout from (which means you can deploy an app that is already arranged for OpenShift very fast). The base cartridge sets up all the hooks for setting up after a git push (you get a git remote that you can push to to redeploy your app). The two things you need are a root setup.py containing your pip requirements, and a wsgi/application file which is a Python blob containing an WSGI object named application. For Python it uses virtualenv and all that awesome stuff. I assume for node.js you’d provide a package.json and it would use npm, similarly RubyGems for Ruby etc.
There’s a nifty command line tool written in Ruby (what happened to Python-only Redhat?) that lets you do all the sort of cloud managementy stuff, including reloading cartridges and gears, tailing app logs and SSHing into the gear. I think an equivalent of dbshell would be really useful based on your DB cartridge, but it’s not a big deal.
There are these deploy hooks you can add to your git repo to do things like create your databases. I haven’t used them yet, but again it would make deploying your app very fast.
There are also quickstart scripts for deploying things like WordPress, Rails and a Jenkins server onto a new gear. Speaking of Jenkins there’s also a Jenkins client cartridge which I think warrants experimentation.
So what’s a bit crap? Why isn’t my app running on OpenShift yet? Basically because the available cartridges are a little antique. The supported Python is Python 2.6, which I could port my app too; or there are community-supported 2.7 and 3.3 cartridges, so that’s fine for me (TBH, I thought my app would run on 2.6) but maybe annoying for others. There is no Celery cartridge, which is what I would have expected, ideally so you can farm tasks out to other gears, and although you apparently can use it, there’s very little documentation I could find on how to get it running.
Really though the big kick in the pants is there is no cartridge for Postgres 9.2/PostGIS 2.0. There is a community cartridge you can use on your own instance of OpenShift Origin, but that defeats the purpose. So either I’m waiting for new Postgres to be made available on OpenShift or backporting my code to Postgres 8.4.
Anyway, I’m going to keep an eye on it, so stay tuned.
The idea of dbshell seems like a good one, and this would be a nice report ( even if there is already lots of features asked )
For celery, it requires a broker and for now, there is no cartridge broker ( there was people working on redis cartridge however ). The format of cartridge have been updated some weeks ago ( now, 2.0 ), and there is plan to let people integrate community cartridge on the online version, so not all hope is lost for you.
The issue of communication between cartridge is also a little bit complex because all gears are isolated containers, and by definition, they cannot communicate with each others ( namespace, selinux, firewall ). So poking a few holes in the protection need to think about a system that do stuff without ruining security.
Regarding a new version of postgresql and postgis, that’s the same. Online is based on RHEL 6 and so use RHEL6 package for support, and until there is a paying tier for hosting, I do not think the team want to increase the list of supported frameworks ( at least, not without a way to have it sustainable ). But again, there is plan for community supported cartridges.
Thanks, I think I was more positive. Maybe because of DIY where you’re able to deploy a website through netcat 🙂
But yet I could not clarify what OpenStack is and what role it would play compared to OpenShift.
Anyway: OpenShift is open source, so maybe others will also set up a service 🙂
Nice post. I agree about the Postgresql/postgis version and believe I am working on getting us to the newer version.
In terms of OpenStack versus OpenShift – OpenStack is infrastructure as a service while OpenShift is platform as a service. OpenShift could (and does) run on top of OpenStack.
Kai: OpenStack is IaaS (infrastructure as a service); OpenShift is PaaS (platform as a service). Different levels of the stack. In fact, the aim is for us to be able to run OpenShift on OpenStack (although at present, the free public instance of OpenShift is running on EC2).
You can indeed set up your own instance of OpenShift, if you like: https://github.com/openshift
RE: the dbshell stuff. I worked on the command line tools quite a bit and one of the changes that I was in charge of was making it super simple to drop in commands with full documentation fairly easily.
https://github.com/openshift/rhc/blob/master/lib/rhc/commands/ADDING_COMMANDS.md
Sorry about the Ruby, you know I’m a huge Python fan but I have to say, Ruby made it super simple to add declarative hooks and hide some of the complexity even if there are some ugly duck typing hacks in the backend. I still haven’t found a python equivalent to the commander module.
There was a request at some point to make it easy to drop in user commands in a local directory instead of requiring them to be in the source tree. I’m not sure it ever got implemented but it would be nice for users who want to integrate their own commands and then submit them upstream.
I think (optionally) distributing celery between gears would be very powerful. Particularly where your background tasks are significantly more computationally intensive than your WSGI.
I understand not wanting to increase your maintenance surface by having to support more stuff, but there’s a certain irony to PaaS requiring you to target a legacy platform :-p