Difference between revisions of "Deployment research"
(Fixed the italicization) |
(Added an outline for the rest of the document) |
||
| Line 38: | Line 38: | ||
That's the deployment setup we ''don't'' want :) | That's the deployment setup we ''don't'' want :) | ||
| − | == Fabric | + | == Deployment == |
| + | |||
| + | Deployment covers: | ||
| + | * Server creation (spinning up a new server with our setup) | ||
| + | * Server management (which stuff is on which machine?) | ||
| + | * Server updating (update software / data on server) | ||
| + | |||
| + | The following tools are being considered: | ||
| + | |||
| + | === Fabric === | ||
| + | |||
| + | ==== Old stuff ==== | ||
(Old stuff from [http://teamspace.creativecommons.org/Jurisdiction_Management Jurisdiction Management]) | (Old stuff from [http://teamspace.creativecommons.org/Jurisdiction_Management Jurisdiction Management]) | ||
| − | + | '''On live''' | |
| − | |||
Perhaps in a future time, the follow will replace the above steps: | Perhaps in a future time, the follow will replace the above steps: | ||
<pre> | <pre> | ||
| Line 51: | Line 61: | ||
http://docs.fabfile.org/1.0/ | http://docs.fabfile.org/1.0/ | ||
| − | + | '''On staging''' | |
Perhaps in a future time, the following can replace the above steps: | Perhaps in a future time, the following can replace the above steps: | ||
| Line 58: | Line 68: | ||
$ fab idot imgsplat '''XXX It'd be nice to have this maintained in a fab file so we don't need extended instructions; maybe we need a repo of "deployment tools" that contain these scripts? Feels a bit like a inappropriate mixing of concerns''' | $ fab idot imgsplat '''XXX It'd be nice to have this maintained in a fab file so we don't need extended instructions; maybe we need a repo of "deployment tools" that contain these scripts? Feels a bit like a inappropriate mixing of concerns''' | ||
</pre> | </pre> | ||
| + | |||
| + | === Silver Lining === | ||
| + | === Puppet === | ||
| + | === Chef === | ||
| + | === bcfg2 === | ||
| + | |||
| + | === plain ol' ssh and bash === | ||
| + | |||
| + | |||
| + | == Where to deploy to == | ||
| + | |||
| + | This section is about what we might end up deploying to in the end. | ||
| + | |||
| + | Ideally our deployment system will ge generic enough to deploy to | ||
| + | multiple types of servers, but... | ||
| + | |||
| + | === generic metal servers === | ||
| + | |||
| + | === Linode === | ||
| + | |||
| + | === openstack === | ||
| + | |||
| + | Rackspace Cloud, for example, runs this. | ||
| + | |||
| + | == Load balancing == | ||
Revision as of 20:11, 17 March 2011
In the future, deployment will happen at the touch of a button. If you want a new server set up, you will just touch this button, several magical woodland fairies will be sacrificed to the elder gods, and a server will just appear set up for you, completely automagical. When something goes wrong, you just destroy the server, and maybe send apologetic cards to the families of the etherial woodland creatures. This will greatly improve our scalability.
However we have no idea how this will happen yet. Watch here for details as this is researched.
Contents
Goals
In short:
- Failover / load balancing.
- If a server goes down, another should pick it up.
- If things are slow, another server should be able to pick things up.
- Boot and shoot approach
- Quick and mindless spin-up of a new server
- Ability to just take down a server / node if it's not working well
- Still have the ability to step in and debug things as much as we like
- An approach for spinning up live & devel servers using mostly the same setup
The cc.engine stack has some advantages. For the most part, there simply is no "changing database"... everything is stored in RDF files that are in a git repository / in python packages.
We also need to support CC Wordpress, but this can also be checked out of an svn repository on the fly. Assuming we do edits somewhere else and just push to the server, no need to do backups of these "node" servers, even!
(However maybe we will eventually want to use this setup with things that *do* have a database that matters, like cc network?)
Cleanness is also a goal. It should be clear enough what's happening in the deployment setup and how to adjust / reproduce things. From the talk Continuous Deployment, by Laurens Van Houtven, he talks about a setup wherein anything goes, and perl scripts wrap scheme scripts alongside erlang alongside java and PHP...:
"And developers' sense of decency and morals just completely falter, and they start implementing just completely anything, and then you have some giant shambling lovecraftian horror of a deployment system..."
That's the deployment setup we don't want :)
Deployment
Deployment covers:
- Server creation (spinning up a new server with our setup)
- Server management (which stuff is on which machine?)
- Server updating (update software / data on server)
The following tools are being considered:
Fabric
Old stuff
(Old stuff from Jurisdiction Management)
On live Perhaps in a future time, the follow will replace the above steps:
$ fab staging deploy
On staging
Perhaps in a future time, the following can replace the above steps:
$ fab production deploy $ fab idot imgsplat '''XXX It'd be nice to have this maintained in a fab file so we don't need extended instructions; maybe we need a repo of "deployment tools" that contain these scripts? Feels a bit like a inappropriate mixing of concerns'''
Silver Lining
Puppet
Chef
bcfg2
plain ol' ssh and bash
Where to deploy to
This section is about what we might end up deploying to in the end.
Ideally our deployment system will ge generic enough to deploy to multiple types of servers, but...
generic metal servers
Linode
openstack
Rackspace Cloud, for example, runs this.
