Difference between revisions of "Deployment research"
(Fixing "jurisdiction management" link to point to teamspace) |
(Added the "goals" section) |
||
| Line 2: | Line 2: | ||
However we have no idea how this will happen yet. Watch here for details as this is researched. | However we have no idea how this will happen yet. Watch here for details as this is researched. | ||
| + | |||
| + | == 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 | ||
| + | [http://pycon.blip.tv/file/4881000/ 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 :) | ||
== Fabric? == | == Fabric? == | ||
Revision as of 18:50, 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 :)
Fabric?
(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'''
