
Configuration (mis)management or why I hate puppet, ansible, salt, etc. - ayi
http://www.scriptcrafty.com/configuration-mismanagement-or-why-i-hate-puppet-ansible-salt-etc/
======
dozzie
> So that ladies and gentlemen is why I hate anything and everything that uses
> YAML or some other weird custom DSL to do the obvious.

Sure, because I would trust a random clueless programmer to do system
administration or to even know what is necessary there. Your rant is totally
justified.

> Everything that seems intuitive and obvious to me is either an anti-pattern
> or straight-up impossible to do with any of those tools.

The same can be said about functional languages from a perspective of
imperative programmer. You just don't understand the paradigm. There's really
nothing to brag about here.

> Somehow I’m the only one that ended up with the right set of experiences
> that taught me to avoid all the things these tools champion.

Yes, somehow you're the only one smart out there. All the other people are
just plain stupid.

> [...] but not before a whole bunch of hair is lost trying to figure out why
> some snippet of YAML is not creating the right unix user (this by the way
> has happened more than enough times now that I’ve stopped counting).

As previously, there's nothing to brag about. You just don't understand the
paradigm.

------
mwpmaybe
> The stuff I had built at my first job taught me that my intuitions about
> software systems in general were mostly correct

Oh boy. Here we go.

> The guy that had built this part was pretty smart .. He probably should have
> trusted his intuitions a bit more and not bowed to peer pressure

Or maybe he knew enough to understand how Puppet could fit into the overall
architecture and strategy at this company that is now the second company
you've ever worked for.

> Why the fuck are build/ops folks making decisions about how the application
> should be deployed and configured?

Because that's what build/ops folks are there to do, and congratulations,
you've just discovered dev ops. Not every application is nginx, node.js, and
mongodb running on a single VM. Sometimes deployments get complicated.

> How is it that these things are obvious to me but not obvious to others?

Wow.

This person hates on Puppet for "reasons" and decries all configuration
management tools as awful pieces of garbage, then says Chef is great while
consistently asserting that people are sheep for using configuration
management tools, then throws in digs at Ansible and Salt with absolutely no
context. It seems like he/she extrapolated one bad example of one Puppet use
case into a general flaw with the whole lot. It's like he/she drove a Pinto
for a bit, had trouble going around one corner one time, and deduces that all
motor vehicles are bad and anyone who drives a car is an idiot.

------
w_t_payne
Yup.

I'm trying to create a build-and-configuration-management system for
distributed embedded systems development.

The product will have some physical components with embedded software, and
some back-end components running on some sort of server somewhere. Some of the
embedded devices may be networked. Some may not.

I want to use Continuous Integration to ensure that the front & back end (and
all the various testing tools) play nice together, and Continuous Deployment
to reduce the risk of manual missteps.

So ... I'm trying to create the build scripts that build the system components
(including cross-compiling the embedded SW), run tests and deploy the various
components to UAT / HIL / SIL & simulation environments, orchestrate overnight
and over-the-weekend simulation runs & generally provide tools to help manage
deployment -- I also want to make the whole thing enforce DO-178B-style
process compliance, requirements traceability etc.. etc...

Most of this is done in Python, 'cos I want to be able to reproduce the
process on my workstation. Moreover, I want it to be portable (Linux, OSX &
Windows), location-agnostic (works in any directory), and free from all but
the most essential dependencies.

------
voidr
You can run Puppet in a decentralised way:

    
    
        sudo puppet apply --verbose --debug --modulepath=./system system.pp
    

You can also use BASH/Python whatever _with_ Puppet and still take advantage
of Puppet's declarative semantics if that's what you need:

    
    
         exec { "install_node":
            require => Package[["build-essential", "openssl", "libssl-dev", "pkg-config"]],
            command => "${settings::modulepath}/main/install_node.sh v0.12.7",
            creates => "/usr/local/bin/node",
            logoutput => true,
            timeout => 1800
        }

------
hbogert
On another blog I read a very wise notion, which captured the underpinnings
which are "wrong" with tools like ansible/salt/puppet.

You can verify that something is set, but this guarantees nothing about the
things you haven't set.

Now, this is fine if you purely use the above tools as provisioning, i.e. run
the configuration tools on an immutable image. However, often these
configuration tools are run on long running machines. And then we're back to
pets vs. cattle. With all the faults and difficulties of Docker - at least it
does that right.

~~~
mpdehaan2
Slight clarification, this isn't new in Docker, you're describing "Immutable
Systems". It's also not mutually exclusive with configuration management
tools.

The systems management tools have been doing this a long time with baked cloud
images, most prominently Packer invoking configuration-tools-of-choice for
baking cloud images straight (which I'd say STILL has a wider adoption than
Docker) and this can also be done inside Docker files, just like it can be
done for AWS image baking.

You're still going to have some things that need to be done in runtime,
especially in managing your stateful servers.

