[linux-elitists] Congruent Infrastructure (was: Re: Surveillance)

Marc MERLIN marc at merlins.org
Sun Sep 8 09:38:30 PDT 2013

On Sun, Sep 08, 2013 at 05:14:01PM +0100, Andy Bennett wrote:
> I notice you did this:
> http://marc.merlins.org/linux/talks/getupdates/
A while ago. 7 years was it? :)
> I'd be very interested in your views on things such as Puppet or Chef: I
> myself have been very skeptical of them. Some of the issues are outlined
> in this blog post (not by me):
> http://blog.thestateofme.com/2013/04/30/an-adventure-with-chef/
So, I know about cfengine, chef, and puppet. On of my coworkers replaced my
getupdates work with cfengine after I left.
Apparently everyone working with it hated it and removed it later.
Now they use puppet.

I haven't personally used puppet myself, but anything that requires to read
a long book and sometimes in line ruby programming in seems to deploy files
and packages, should really question if the tool is with the trouble.

For those who don't know, getupdates is very simple, it really just
retrieves a shell script and a tar file for each changeset you updated, and
runs that. The shell script has access to the tar file content, and lets you
install the files as you please (in shell, with a few helper functions).
>From there, you simply use apt-get to install/update packages.

It's not fancy, I wrote it in a few days, maybe a week of additional work to
add wrapper functions, logging, and so forth, but that's about it.

It is however designed to run on machines that are all the same by class
(you pull different shell scripts for other classes of machines).

I know puppet offers extra functionality, but IMO, it is not needed in many
cases and that adds complexity.
It may be possible to use puppet like I used getupdates and take advantage
of whatever collectors they have without having to learn a lot of extra
stuff, but I just don't know puppet, so I can't say.
> I'd be interested in your thoughts on "congruent infrastructure
> management" especially around the issues of avoiding divergence, proving
> convergence and recovery from failure that doesn't involve wiping the
> machine.

So the last thing I worked on, was production machines at google. Those are
much easier (and unusual because few people do this): they are all the same
for the maintained portion.
In other words it's pretty much like rsyncing all the entire filesystem with
an exclude list of files for stuff like network config.
I'm not going to give the talk via Email, you can read there
but basically that 100% takes care of divergence :)
(however, yes it means you cannot install your custom software on the
managed root filesystem, it needs to be outside of that, meaning that you
cannot use rpm/dpkg to install a package off the net and need to compile
your software to run with different pathnames if applicable, which is what
we do at google regardless)

"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  

More information about the linux-elitists mailing list