<p>These strategies have nothing to do with one another.</p>

<p><em>Containers</em> (like Docker) are a methodology for deploying and isolating applications. Containers are well liked because they're transportable. They can be developed on and previewed locally in most cases, so putting applications in them makes sense.</p>

<p><em>As for why Docker uses shell scripting</em>: A docker image is literally a linux container image. It's a linux operating system and the point of that container to be as lightweight and efficient as possible. If you started adding Chef, Ruby, Erlang, and all the other libraries required to have Chef as a provisioner on a Dockerfile you'd be eliminating the point of using containers.</p>

<p><em>Configuration Management</em> is for provisioning a compute node. Your configuration end state is usually reflected in code and has a central server for maintaining state. Tools like vagrant allow you to use chef to configure Vagrant machines, largely out of convenience for developers. While you can use most of these tools in a <em>local-only</em> mode, the maintenance of them becomes quite burdensome. Those central servers are for things like automatically sorting out versioning and dependency management.</p>

<p>Bash is not inherently a step back. For instance, many organizations building <em>fully immutable image pipelines</em> build their images using Bash. This ensures stability and predictability as well as a common language among engineers (Many engineers may come from different config management backgrounds).</p>

<p><strong>Immutable vs Config Management</strong>.
Immutable infrastructure does not change and must be entirely replaced in order to be updated. Config Management implies that the state of a machine is maintained by an agent or foreign connection (like with Ansible).</p>

<p>Docker containers are inherently immutable. You don't persist data on them and they must be rolled in order to be updated.</p>

CC BY-SA 3.0
2017-11-02T17:50:59.190Z
2017-11-02T17:58:05.207Z
2017-11-02T17:58:05.207Z
Matt O.
<p>The tool you need is <a href="https://www.packer.io/docs/builders/docker.html" rel="nofollow noreferrer">Packer</a> using Docker as the "builder" and Chef as the "provisioner". Then you can add the resulting image to your repo and reuse it without having to pack again, until your recipes change. </p>

CC BY-SA 3.0
2017-11-02T17:28:30.560Z
2017-11-02T18:49:01.077Z
2017-11-02T18:49:01.077Z
Gaius
<p>I'm pretty new to Docker and configuration management tools. </p>

<p>At first I started writing bash scripts to provision my Vagrant boxes for my development machines, but now I've switched to using Chef for that so that I can use the same source to provision both development and production environments to try and get them as similar as possible.</p>

<p>Since I've started using Chef I've come to enjoy the DRY aspect of not having to copy and paste shell script lines from project to project, the ability to provision machines running a variety of linux distributions using one consolidated source, and the convenience of using community provided cookbooks.</p>

<p>Now that I've been using Chef to provision my vm's it feels like taking a step backwards when I am adding RUN commands followed by shell commands to a Dockerfile to achieve what could be achieved by just running a Chef recipe.</p>

<p>I've googled and haven't found anything (but maybe I just missed it) but it doesn't look like there is an easy way to use Chef recipes to build Docker containers. Why is that?</p>

<p>I understand that containers are meant to be immutable and configuration management tools are commonly used to re-configure machines during their entire lifespan, but wouldn't they still offer a lot of benefits if used during the initial building of the container?</p>

CC BY-SA 3.0
2017-11-02T14:58:04.317Z
Configuration Management tools can still be used immutably to configure your server/docker container/etc after it is provisioned. Then simply don't change the configuration and deploy a new one.

Similarly, there is near-immutability with [idempotency](https://puppet.com/blog/idempotence-not-just-a-big-and-scary-word).
James Shewey
CC BY-SA 3.0
2017-11-02T17:54:37.067Z
@JamesShewey Idempotent does not mean immutable. Immutable machines must be rolled in order to be updated.
Matt O.
CC BY-SA 3.0
2017-11-02T22:28:04.663Z
@Matt O. Correct. But you can use an idempotent configuration management system to roll an immutable server. Once the rolled machine is brought back online, the configuration management system configures the system to the final, immutable state - installing packages, setting configuration files and starting services and such. Just because a system is idempotent does not mean it cannot also be immutable. It's just a matter of whether you decide to burn it down and redeploy when you make a change to the configuration, or whether you push that change out and update the existing system.
James Shewey
<docker><chef><configuration-management>
Why not use configuration management tool instead of Dockerfile?
David Eugene Pratt
# Why not use configuration management tool instead of Dockerfile?

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

I'm pretty new to Docker and configuration management tools.

At first I started writing bash scripts to provision my Vagrant boxes for my development machines, but now I've switched to using Chef for that so that I can use the same source to provision both development and production environments to try and get them as similar as possible.

Since I've started using Chef I've come to enjoy the DRY aspect of not having to copy and paste shell script lines from project to project, the ability to provision machines running a variety of linux distributions using one consolidated source, and the convenience of using community provided cookbooks.

Now that I've been using Chef to provision my vm's it feels like taking a step backwards when I am adding RUN commands followed by shell commands to a Dockerfile to achieve what could be achieved by just running a Chef recipe.

I've googled and haven't found anything (but maybe I just missed it) but it doesn't look like there is an easy way to use Chef recipes to build Docker containers. Why is that?

I understand that containers are meant to be immutable and configuration management tools are commonly used to re-configure machines during their entire lifespan, but wouldn't they still offer a lot of benefits if used during the initial building of the container?

**Tags:** docker, chef, configuration-management

> **Comments:**
> **username_1**: Configuration Management tools can still be used immutably to configure your server/docker container/etc after it is provisioned. Then simply don't change the configuration and deploy a new one.  Similarly, there is near-immutability with [idempotency](https://puppet.com/blog/idempotence-not-just-a-big-and-scary-word).  
> **username_2**: @JamesShewey Idempotent does not mean immutable. Immutable machines must be rolled in order to be updated.  
> **username_1**: @username_2 Correct. But you can use an idempotent configuration management system to roll an immutable server. Once the rolled machine is brought back online, the configuration management system configures the system to the final, immutable state - installing packages, setting configuration files and starting services and such. Just because a system is idempotent does not mean it cannot also be immutable. It's just a matter of whether you decide to burn it down and redeploy when you make a change to the configuration, or whether you push that change out and update the existing system.  

---

## 2 answers

### Answer by username_3 on 2017-11-02. Score: 5 | Accepted answer

The tool you need is [Packer](https://www.packer.io/docs/builders/docker.html) using Docker as the "builder" and Chef as the "provisioner". Then you can add the resulting image to your repo and reuse it without having to pack again, until your recipes change.


---

### Answer by username_2 on 2017-11-02. Score: 5

These strategies have nothing to do with one another.

*Containers* (like Docker) are a methodology for deploying and isolating applications. Containers are well liked because they're transportable. They can be developed on and previewed locally in most cases, so putting applications in them makes sense.

*As for why Docker uses shell scripting*: A docker image is literally a linux container image. It's a linux operating system and the point of that container to be as lightweight and efficient as possible. If you started adding Chef, Ruby, Erlang, and all the other libraries required to have Chef as a provisioner on a Dockerfile you'd be eliminating the point of using containers.

*Configuration Management* is for provisioning a compute node. Your configuration end state is usually reflected in code and has a central server for maintaining state. Tools like vagrant allow you to use chef to configure Vagrant machines, largely out of convenience for developers. While you can use most of these tools in a *local-only* mode, the maintenance of them becomes quite burdensome. Those central servers are for things like automatically sorting out versioning and dependency management.

Bash is not inherently a step back. For instance, many organizations building *fully immutable image pipelines* build their images using Bash. This ensures stability and predictability as well as a common language among engineers (Many engineers may come from different config management backgrounds).

**Immutable vs Config Management**.
Immutable infrastructure does not change and must be entirely replaced in order to be updated. Config Management implies that the state of a machine is maintained by an agent or foreign connection (like with Ansible).

Docker containers are inherently immutable. You don't persist data on them and they must be rolled in order to be updated.


---

