13

If I'm using immutable servers/containers, do I need tools like Chef, Puppet, Ansible, or Salt? Those config management tools are designed to establish a configuration and then maintain it.

If I'm deploying immutable servers, should I use configuration management tools only for initial provisioning?

Improve this question

2 Answers 2

Reset to default
13

There are a few answers to that:

  1. Something needs to build those immutable images. It is certainly easier to use old-school-style procedural scripting to build something when starting from a known starting state but this can still get very unwieldy over time (e.g. Dockerfiles), especially when you end up wanting a big matrix of different images for things like different versions of software, different environments, etc. Packer and other image build tools integrate nicely with Chef, Ansible, Puppet, Salt, and more.

  2. Immutability is a spectrum, not a binary. Even in a "very immutable" deploy it is not uncommon to have some configuration files that need runtime management. This is also a place where you can use CAPS tools, though lighter-weight options like Consul Templates or etcd might make more sense depending on the overall infra. If you're doing immutable app servers but your database servers are more traditionally managed using Chef, then it might make sense to use Chef even on the immutable side for minor management tasks.

  3. Zero-day management. Immutability is nice, but what are you going to do when the next OpenSSL 0day drops? If you have your build pipeline in a position to create immediate hotfix images and deploy them, then that's great. But many people will probably not have that kind of quick-turn ability.

  4. Things that can't be immutable. The un-answer, but a whole infra is rarely 100% immutable. Things like database servers and developer workstations (yes, those are part of your infra) are somewhere between difficult and impossible to make immutable.

Improve this answer
6
  • You are making quite a lot of assumptions about "many people". Those who cannot generate images for their immutable infrastructure, most probably don't have the immutable infrastructure to begin with.
    – Evgeny Zislis
    Commented Mar 2, 2017 at 21:06
  • There is a big gap between "can deploy using immutable containers" and "can rebuild and redeploy every container within 6 hours even with other deployments in progress".
    – coderanger
    Commented Mar 2, 2017 at 21:43
  • And in my experience, when you have that gap (of 6 hours), you are unable to have immutable infrastructure. Having immutable servers and building immutable servers quickly are not identical abilities, but they are closely related.
    – Evgeny Zislis
    Commented Mar 2, 2017 at 21:45
  • Many people that say "we run immutable containers" are not in that category. Hence, pointing out that it's a problem to address, which was the whole point of the question.
    – coderanger
    Commented Mar 2, 2017 at 21:53
  • You can define "immutable" to mean "no-one SSH's in and makes manual changes", because it cannot mean completely unchanging, as they change themselves during normal operations. Even writing a pidfile is a mutation.
    – Gaius
    Commented Aug 24, 2017 at 9:18
0

Absolutely immutable environment is a bad idea, i think.

CM tools like Ansible, Chef, Puppet can be useful in many cases including yours.

I'm using ansible for initial provisioning of VM instances in GCP.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.