4 ms·
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 somethin
by hbogert 11y ago
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 11y agoSlight 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.
- mwpmaybe 11y ago> You can verify that something is set, but this guarantees nothing about the things you haven't set. This is a serious problem, but it's a problem whether you're using a CM tool, packaging, using shell scripts, or doing nothing at all. If users are jumping in as root on random boxen, setting tunables, adding firewall rules, etc., and not capturing those changes elsewhere, it's going to bite you.