Cloud Silverling

1. 1. Can create and destroy virtual servers, using a Cloud service API (something supported by libcloud).
   2. Sets up an Ubuntu server to a known configuration.
   3. Deploys Python web applications to these servers.
      (Also it can deploy PHP applications, maybe other languages in the future.)

You shouldn’t concern yourself too much with the server at this point. Instead, let us ask: what does the application look like?

The Application

Silver Lining is inspired by Google App Engine in this respect; an application is a bunch of files that are uploaded to the server. You don’t “build” an application on the server. To upload or update an application, you run:

$ silver update path/to/app/ myapp.com

This uploads your files, makes sure requests to myapp.com go to your new application. Your application has a file app.ini (located, in this example, in path/to/app/app.ini) which describes the basics of the application.

This also sets up any services that you need for your application (which you have listed in app.ini). Services include any kind of persistence your application requires. This would be a database, or even just a location where you can store files (which isn’t available unless you ask for it). These services then inject their configuration into your application though environmental variables. So when you start your application you might look for os.environ[‘CONFIG_PG_DBNAME’] to see what PostgreSQL database you should connect to. (What each service adds to the environment is covered in the services document.)

You might also ask: what about binary packages? For instance, lxml. With Silver Lining only portable files can go in your application directory; typically .py files, templates, and other plain-text data files. So if you want lxml you have to have the Ubuntu package installed; you’d add (to app.ini) the configuration packages = lxml.

A lot of this is covered in application configuration.

And what kind of frameworks can you use with Silver Lining? Anything really. The only real exception is Zope 2, which has strict Python version requirements, lots of C extensions, and all sorts of other complexities. Repoze will work fine though, and a ZEO service is easy to imagine (though not yet implemented).

The Server

The server is setup thusly:

Ubuntu Jaunty (Karmic seems to work too).
Python 2.6.
Apache with mod_wsgi.
But you don’t directly interact with either of these.
Right now the persistence handling is minimal; this is where the most additional support needs to be added to the system (backups, migration, cloning, separating servers, and eventually stuff like replication). Currently there is basic setup for:
PostgreSQL with the PostGIS extensions.
CouchDB served locally
MongoDB served locally
Nothing cron-like has been implemented yet, though probably it will be implemented very similar to App Engine (with internal requests). App setup and migration has to be hand-coded, but can be configured to be run.
Each app lives at its own domain; per-directory applications are not currently implemented (but would be nice). Multiple hostnames pointing to a single application is not implemented, but would be easy. Wildcards require some more thought (simply in terms of Apache configuration).

Provider support

This package currently has only been tested with Rackspace Cloud. The only specific Rackspace extension is the use of “files” on server creation (this is part of the node-creation API that uploads files on the newly created node/server). The use of the files extension is minimal at this point (just setting up /root/.ssh/authorized_keys), and it is usable without that. If you are signing up for an account by clicking through this affiliate link you can throw a few bucks my way.

Silver Lining uses libcloud, which is a library abstracting several provider APIs. It should be usable with other providers, but it’s only been tried with Rackspace, expect bumps with other services.

Language Support

There is some experimental support for PHP; it’s not incredibly graceful, but it has many of the same deployment advantages as with Python.

Other languages would also be possible. Ruby is a prime candidate of course, probably using Passenger instead of mod_wsgi. If I had any clue how Perl was best deployed, it might also seem reasonable. But I (Ian) only have a personal interest in the two supported platforms and maybe Java.

Installing

Window clients are not supported. The only way Windows will be supported is if someone volunteers to maintain the Windows support. Individual patches won’t be accepted until that time – it would only be a disappointment to Windows users to get a half-working and unsupported client.

If you don’t want to install from the zip file, you can install Silver Lining into a virtualenv environment pretty easily too:

First get virtualenv, which also gives you pip. Also be sure you have Mercurial (hg) and Subversion (svn) installed. Then run:

$ virtualenv -p python2.6 silver
$ silver/bin/pip install -r http://bitbucket.org/ianb/silverlining/raw/tip/requirements.txt

This installs a bunch of stuff, most importantly silver/bin/silver. Your applications will go in a separate environment, so you should be sure that silver works regardless of what virtualenv environment is activated. I recommend:

$ alias silver=”/path/to/silver/bin/silver”

Cloud Server Management

There’s several commands just to manage servers (also called nodes). These are really just frontends to what libcloud provides.

Each “node” has a hostname, which is the name of the node, and also the hostname setup in /etc/hosts.