4 ms·
Appreciate the comment. The point I was hoping to get across wasn't that Docker would completely replace CM (or that CM is a bad thing), but that it could help
by alvinchow86 12y ago
Appreciate the comment. The point I was hoping to get across wasn't that Docker would completely replace CM (or that CM is a bad thing), but that it could help reduce the amount of work in the CM world. As mentioned, we still needed to use Chef anyway (and using Opsworks to get a head start), so at least in this kind of environment CM is still necessary. That said I can see how the article could be slightly misleading =)
- eshamow 12y agoI appreciate your response, but - When you discuss CM being necessary, you are talking about using it on the host and not within the container. Ultimately, operability and proper configuration inside the container is critical. Using a Dockerfile with no CM inside it is not much of an improvement on not using CM anywhere. You don't need stateful CM inside the container. It's fine to fire and forget - use Puppet in apply mode or Chef solo. But there's a reason these tools are used in building AMIs and containers over scripting languages - we've come a long way over the past 10 years, and I still feel that switching to the Dockerfile as a configuration mechanism is like moving back to configure/make/make install.
- Gigablah 12y agoWhat else do you think is happening under the hood when you use a CM tool like, say, Ansible? Ansible translates your configuration to small Python scripts, uploads them to the remote host and runs them. What I'd like to see is a "script dump" output that still lets you create your yml configuration but converts it into shell scripts that you can call from your Dockerfile without any dependencies. Of course, now you have an additional build step... and what could you use to tie everything together? make/make build :)
- eshamow 12y agoWhat happens under the hood is almost irrelevant, because it's predictable and repeatable.