<p>Absolutely immutable environment is a bad idea, i think.</p>

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

<p>I'm using ansible for initial provisioning of VM instances in GCP.</p>

CC BY-SA 3.0
2017-08-22T19:04:52.537Z
2017-08-22T19:04:52.537Z
Quarind
<p>There are a few answers to that:</p>

<ol>
<li><p>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.</p></li>
<li><p>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.</p></li>
<li><p>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.</p></li>
<li><p>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.</p></li>
</ol>

CC BY-SA 3.0
2017-08-24T09:18:58.063Z
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
CC BY-SA 3.0
2017-03-02T21:06:33.687Z
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
CC BY-SA 3.0
2017-03-02T21:43:00.687Z
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
CC BY-SA 3.0
2017-03-02T21:45:18.353Z
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
CC BY-SA 3.0
2017-03-02T21:53:56.050Z
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
CC BY-SA 4.0
2019-03-08T07:51:53.750Z
Re #4...exactly what I was thinking.  It seems like stateful applications running on a compute infrastructure like Compute Engine (GCP) or EC2 (AWS) is almost impossible (or incredibly difficult) to accomplish. Not to mention putting your data at risk if you have to make a change to the configuration of the VM resulting in a re-deployment.
GregH
CC BY-SA 3.0
2017-02-28T23:49:09.623Z
2017-02-28T23:49:09.623Z
coderanger
<p>If I'm using <strong>immutable</strong> 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. </p>

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

<containers><immutable-servers>
What role do Configuration Managment tools play in immutable infrastructure?
Dave Swersky
# What role do Configuration Managment tools play in immutable infrastructure?

(Asked by: username_0 on 2017-02-28)

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?

**Tags:** containers, immutable-servers


---

## 2 answers

### Answer by username_2 on 2017-02-28. Score: 13 | Accepted answer

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.

> **Comments:**
> **username_4**: 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.  
> **username_2**: 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".  
> **username_4**: 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.  
> **username_2**: 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.  
> **username_3**: 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.  
> **username_5**: Re #4...exactly what I was thinking.  It seems like stateful applications running on a compute infrastructure like Compute Engine (GCP) or EC2 (AWS) is almost impossible (or incredibly difficult) to accomplish. Not to mention putting your data at risk if you have to make a change to the configuration of the VM resulting in a re-deployment.  

---

### Answer by username_1 on 2017-08-22. Score: 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.


---

