Deployment research - Revision history

Christopher Webber: /* Puppet */

2011-03-24T21:17:09Z

‎Puppet

2011-03-21T21:21:38Z

Added a note about amazon cloudformation

2011-03-21T21:14:14Z

Added stuff on libcloud

2011-03-21T20:06:43Z

Added Proog & Kirjuri milestone descriptions

2011-03-21T17:02:03Z

Removed the milestone numbering, which is redundant ;)

2011-03-21T17:01:12Z

I don't think we need this old stuff from jurisdiction management anymore.

2011-03-21T17:00:15Z

Added a summary, the milestone outline, and explained Proog (milestone 1)

2011-03-18T23:30:59Z

‎bcfg2

2011-03-18T22:54:58Z

‎bcfg2

2011-03-18T22:54:18Z

Thoughts on bcfg2

← Older revision		Revision as of 21:17, 24 March 2011
Line 129:		Line 129:

	Oh yeah, and something cool... apparently [http://devstructure.com/ blueprint] is great for reverse-engineering a puppet setup.		Oh yeah, and something cool... apparently [http://devstructure.com/ blueprint] is great for reverse-engineering a puppet setup.
		+
		+
		+	==== puppet advice from the FSF ====
		+
		+	<pre>
		+	<cure> paroneayea: yes, it's awesome
		+	<cure> if you keep a few things in mind, that is
		+	<cure> 1. don't run it as a daemon, run it in cron
		+	<cure> (on the managed hosts)
		+	<cure> 2. run the server with passenger
		+	<cure> 3. enable stored config mode from the start
		+	<cure> 4. build your config out gradually
		+	<cure> 5. set up a test environment from day one
		+	<cure> that last one is really important
		+	<paroneayea> cure: cool, thanks, noted! :)
		+	<cure> that way you can test on one node (puppetd -t
		+	--environment=name-of-your-test-env)
		+	<cure> without risking having faulty rules being pushed out to a lot of
		+	machines
		+	</pre>

	=== Chef ===		=== Chef ===

@@ Line 181: / Line 181: @@
 even shows an example at the bottom of starting a new server and
 pushing your puppet setup over to it.
 == Where to deploy to  ==

@@ Line 172: / Line 172: @@
 individually and think, "Oh this isn't so confusing, but also no
 wonder I was confused."
 == Where to deploy to  ==

@@ Line 221: / Line 221: @@
 <pre>
-  $ fab update_live
+  $ fab update_ccengine
-  $ fab clear_cache_live
+  $ fab clear_cache
   $ fab update_images
 </pre>
-... maybe some of these commands will execute multiple subcommands at once for convenience?
+... maybe some of these commands will execute multiple subcommands at
 Working on these tools first means a few positive things, I think:
@@ Line 236: / Line 237: @@
 ''Also from Elephants Dream, Proog is an older and possibly experienced man claiming to lead Emo through this same world of automations and magic.  The world appears to form to his whims.  Is it all in his head?''
 === Kirjuri (self-typing typewriter) ===
 ''Also from Elephants Dream, Kirjuri is a typewriter that types itself.  Automatically automate the automation!''

@@ Line 211: / Line 211: @@
 though, I'll restrict myself to stuff the Blender Institute puts out.
-=== Emo (Milestone 1) ===
+=== Emo ===
 ''From the film Elephants Dream, Emo is a young man stumbling into a possibly imaginary (and possibly someone else's...) world of automations and magic.''
@@ Line 233: / Line 233: @@
 * We'll develop a good idea of what working with fabric is like before we jump into the next big step
-=== Proog (Milestone 2) ===
+=== Proog ===
 ''Also from Elephants Dream, Proog is an older and possibly experienced man claiming to lead Emo through this same world of automations and magic.  The world appears to form to his whims.  Is it all in his head?''
-=== Kirjuri [self-typing typewriter] (Milestone 3) ===
+=== Kirjuri (self-typing typewriter) ===
 ''Also from Elephants Dream, Kirjuri is a typewriter that types itself.  Automatically automate the automation!''

@@ Line 85: / Line 85: @@
 But back to the first hand, automagic is sometimes just not nice, and
 generally confusing and hard to debug anyway!
 === Silver Lining ===

@@ Line 197: / Line 197: @@
 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
+Originally I was going to flesh this out with more detail, but since
-multiple types of servers, but...
+then I think that really our system should be capable of deploying to
-=== generic metal servers ===
+== load balancing ==
-=== Linode ===
+I'm not sure what load balancing system we'll use exactly.
-== Load balancing ==
+[http://wiki.nginx.org/LoadBalanceExample nginx, maybe?]
 == Milestones ==

@@ Line 161: / Line 161: @@
 === bcfg2 ===
-Looks a lot like puppet/chef except it uses Python?
+Looks a lot like puppet/chef except it uses Python?  You describe goals for what your server should look like, it installs to those goals, upgrades when not matching those goals, validates on server goals.
 http://trac.mcs.anl.gov/projects/bcfg2/

← Older revision		Revision as of 22:54, 18 March 2011
Line 166:		Line 166:

	Also apparently not as many users, way less hip, less people running it also riding fixie bikes.		Also apparently not as many users, way less hip, less people running it also riding fixie bikes.
		+
		+	The ChiPy video on this page is pretty good:
		+	http://trac.mcs.anl.gov/projects/bcfg2/wiki/AudioVideo

	=== openstack ===		=== openstack ===

← Older revision		Revision as of 22:54, 18 March 2011
Line 160:		Line 160:

	=== bcfg2 ===		=== bcfg2 ===
		+
		+	Looks a lot like puppet/chef except it uses Python?
		+
		+	http://trac.mcs.anl.gov/projects/bcfg2/
		+
		+	Also apparently not as many users, way less hip, less people running it also riding fixie bikes.

	=== openstack ===		=== openstack ===