-- markdown --
A WSGI deployment tool - stop being a sysadmin
By formalizing some project conventions and the server stack, in theory large chunks of the deployment process can be automated.
"How does it work?" - With configuration files and a command line interface.
"What can I do?" - Create servers with your cloud provider and deploy all your WSGI applications in very few steps.
"What more can I do?" - You define main domains and forward domains, number of server workers per project, and which services you want kraftwerk to provide.
"What are kraftwerk services?" - They're SQL databases, key-value storages and good old writable folders. Kraftwerk defines them programmatically so you can setup and teardown per project automatically.
"Okay cool - what else can I do?" - Projects can dump and load all the data for each service. So you can backup and restore from the command line. Not just SQL. Also user uploaded files for example.
"Anything else?" - If you have the same project on two nodes you can transfer the services state of one node to another. So if you have interesting live data on one node you can load that into a stage node for example, with one command.
For examples and documentation see http://www.kraftwerk-wsgi.com/
Design notes, terminology
The admin installs kraftwerk on his own computer. The admin pushes projects to nodes. Server nodes do not require a kraftwerk library. Server nodes are referred to by their hostname (can be anything because kraftwerk appends your /etc/hosts).
Kraftwerk also helps you start WSGI projects (although it is completely agnostic to frameworks or library requirements). Project root folders are virtualenvs. Project root folders contain a Python package which would be your webapp. Projects include a kraftwerk.yaml config too where you can specify domains and various things.
The kraftwerk cli (command line interface) is path aware. If executed inside a project directory it interacts with that project.
Most server scripts and files in the project skeleton can be tailored and changed by supplying a secondary template directory in the admin config. This means you can tweak default parameter and add packages to the system install procedure among other things. Currently there is no way to change the project skeleton structure although this is a possible planned feature.
Kraftwerk supplies additional services to projects that request them.
These are databases, key-value storages, cache, queues and certain
I/O. Services are coupled with a
setup.sh template script run each
time a new project is deployed. Each service dumps and loads data. See
Development vs. stage vs. live
The goal of a stage deployment is to mirror "real-world" application conditions to decrease the chances of fucking up once an application is deployed to a live server. To this end kraftwerk provides the plumbing for a convenient and quick stage test. Secondarily stage deployments are useful for client previews and internal testing.
Kraftwerk is agnostic to the development environment. Kraftwerk only cares about config and a Python WSGI codebase. Additionally kraftwerk wants to make it easy to bundle website data for easy backup and restore (refer to "Services" section).
You may run the setup-node against any ubuntu box with root SSH access. You are not stuck with libcloud. (I even have it running on Debian Squeeze and a local VirtualBox for local testing).
runit, nginx, gunicorn, virtualenv Python stack: Crypto, PIL, DB drivers
Of these gunicorn is the most interesting choice. Kraftwerk is making a big bet on this horse. It simplifies configuration and setup drastically. It also performs well with long-requests (WebSockets).
web user and a
/web directory to contain project code and uploads
node_setup.sh script template for details.
setup.py doesn't pick up the libcloud development
dependency automatically. To install all dependencies run
pip install -r kraftwerk/REQUIREMENTS.
- This project is very similar to Silver Lining by Ian Bicking - See FAQ section on kraftwer-wsgi.com
- Markdoc's argparse / YAML config