How to Manage LEBs (128MB): Puppet vs Chef vs Ansible vs Salt vs cfengine

Jonchun

@Silvenga said:

So much to learn!

nhocconan

I love this topic :-) Thanks for all of your sharing. Bookmarked :-)

Jonchun

@Silvenga said:

Just thought of a question. In your scenario with hundreds of states/transitions declarative is helpful, but in this specific scenario where you want to manage a bunch of smaller boxes, wouldn't it be better to take an imperative approach? There's only so much you can do with a LEB no?

Silvenga

Jonchun said: Just thought of a question. In your scenario with hundreds of states/transitions declarative is helpful, but in this specific scenario where you want to manage a bunch of smaller boxes, wouldn't it be better to take an imperative approach? There's only so much you can do with a LEB no?

Yeah, good point. As an example, many blogs won't ever use ReactJs (unless they're trying to show off) because of the inherent overhead. I would really say it's at the discretions of the owner.

That said, my standard SaltStack solution for every new box is something like 130 states - add something simple like ASSP and it jumps to 300. I have states for everything like fixing locales on some minimal Ubuntu images, replacing Postfix/Sendmail with nullmailer, fixing the time zone, remove help-text banner from login, etc. I run this state (along with some extra depending on the box) every hour (i.e. Ramnode likes to change my hostname for some reason).

Jonchun

@Silvenga said:
That said, my standard SaltStack solution for every new box is something like 130 states - add something simple like ASSP and it jumps to 300. I have states for everything like fixing locales on some minimal Ubuntu images, replacing Postfix/Sendmail with nullmailer, fixing the time zone, remove help-text banner from login, etc. I run this state (along with some extra depending on the box) every hour (i.e. Ramnode likes to change my hostname for some reason).

Will definitely be investigating this stuff more.

Speaking of assp, @Jarland have you ever used this following front end interface to it before? Ran across it today and thought it looked interesting.

http://www.grscripts.com/

jar

Jonchun said: have you ever used this following front end interface to it before?

Yeah, it seemed like it added a lot of interesting features, but it really didn't seem to change the end result enough to justify the added complexity.

Abdussamad

I don't see how you can say that ansible is not declarative? You want to install a package you just tell it you want the latest version and it figures out how to make that happen on its own.

bookstack

@mpkossen: I like constructive feedback, and I have a think skin.

@mpkossen said:
How is it fragile? Especially compared to something like Puppet, which you can break by forgetting it set a single dependency in a maze of sometimes thousands of jobs?

This is a very personal opinion: the ansible expects you to take a convention that you need to define you work in tasks/ and variables in defaults/ and so on. It is no unbearable, but why? Especially you just need a handful variables and you might end up look up in several files.

How so?

The ansible module to output a file with a template, http://docs.ansible.com/ansible/template_module.html, you have no way to override the value of variables on the fly. You need to follow their rules. Again, it is doable, but this is such a common use case, why not make the DevOps life a little bit easier?

To me that's the whole point. I want to tell a tool what I want it to do rather than telling it what I want, because in the latter case the documentation side-effect of defining your infrastructure as code gets diminished.

Again, this is yet another very opinionated argument. To me the provision software is just to bring whatever state my machine is to a clearly defined state regardless the magic is played under the hood. When I say a package MUST be installed, the underlying implementation may either

• install the package anyway, it may redo it or nop depends on the package manager.
• check the package whether is installed, and install it if it is missing.

I expect the provision software will handle this and most likely optimize for me. There is no point for me to handle the details in the provision script by myself. That is why I prefer the provision tool to be declarative, not imperative. I care only the end state, not the intermediate steps.

Termiet

Have been using cfengine for a while now. It is very adaptable and new versions of operating systems are quickly processed in the configs.
I use cf for setting up initial vps with VirtualMin and all the stuff that comes with it. CSF, php modules, nano, curl and such.
I use one 'master' server which pings the 'slaves', the slaves themselves keep updating until the scripts are satifisied and the state is what is described in the 'recipe'. But if the master is down I can still cp configs from other vps's.

Works fast, clean and is not totaly dependend on a central server.

vfuse

I used chef for a big adserver to setup large database and app clusters it worked pretty well but the chef server did need at least 1gb of ram. It did take me a while to setup the right recipes with private networking and all the right configuration files. I might give Puppet a try (hosted puppet on runabove, it's free).

dedicados

mpkossen

bookstack said: This is a very personal opinion: the ansible expects you to take a convention that you need to define you work in tasks/ and variables in defaults/ and so on. It is no unbearable, but why? Especially you just need a handful variables and you might end up look up in several files.

That's not a requirement but a best practice for most part. I think only the hosts files, host and group variables need to be in a specific place and the rest is up to you.

bookstack said: The ansible module to output a file with a template, http://docs.ansible.com/ansible/template_module.html, you have no way to override the value of variables on the fly. You need to follow their rules. Again, it is doable, but this is such a common use case, why not make the DevOps life a little bit easier?

You can by using a direct command rather than a playbook. I don't understand the use case, though, but if it's a common thing they're open to suggestions. It is open source after all. Someone may even build it (or you could do this yourself if this is the one obstacle of course).

bookstack said: I expect the provision software will handle this and most likely optimize for me. There is no point for me to handle the details in the provision script by myself. That is why I prefer the provision tool to be declarative, not imperative. I care only the end state, not the intermediate steps.

That's a preference, definitely.

The reason I personally don't like "magic" in these things is that when something goes wrong (or different than you expect), you'll have to investigate which part of magic did the trick and what that trick was. That could be even worse in the case the tool changes the magic without you knowing it, perhaps even causing undesirable side-effects (which may or may not be detected).

bookstack said: When I say a package MUST be installed, the underlying implementation may either

install the package anyway, it may redo it or nop depends on the package manager.

check the package whether is installed, and install it if it is missing.

FYI: that is exactly what ansible does when you tell it to make sure a package is installed.