4 ms·
I was recently on a podcast panel that discussed if Docker was a replacement or complement to Puppet/Chef. http://theshipshow.com/2014/03/deciphering-the-docke
by i386 13y ago
I was recently on a podcast panel that discussed if Docker was a replacement or complement to Puppet/Chef.
http://theshipshow.com/2014/03/deciphering-the-docker-lifestyle/ http://theshipshow.com/2014/03/deciphering-the-docker-lifest...
- d23 13y agoI've seen Puppet Fabric Chef Vagrant and Docker pop up in popularity over the last couple of years, but I've never really been clear on what the use cases are for each. It'd be a nice to see an easily digestible comparison somewhere.
- btgeekboy 13y agoPuppet and Chef do basically the same things: they let you define how a server should be configured, and the respective applications make changes to the server so that they converge upon that definition. Fabric is a "library and command-line tool for streamlining the use of SSH for application deployment or systems administration tasks." In other words, it's shell scripting in Python that makes it easy for the author to switch contexts between local and remote commands, or run a series of tasks. It makes no attempt to converge to a known state like Puppet or Chef; it simply runs what you tell it to. Vagrant is a bit different; it connects to VirtualBox or VMware to give you disposable VM for use as a development environment. So, if your application is deployed on Debian configured a certain way, someone on your team can make a Vagrantfile that tells your local computer to fire up a Debian VM and configure it a certain way that is similar to how it is in production. (That configuration might actually be done by Puppet or Chef - Vagrant just builds the VM and fires it off.) It prevents various cross-platform issues from being an issue during development, aka "it works on my machine!" syndrome. Finally, Docker is a way to run a super lightweight container, like a VM, but taking advantage of various Linux kernel capabilities, preventing you from needing the overhead of yet another OS. Your Docker images might have a full VMs worth of content for libraries and such, but they'll not need to actually run as an OS. (Only the libraries needed for your app will be loaded.) With the exception of Puppet and Chef (which are directly competing products), all are very different tools that can be used simultaneously at various parts of the product lifecycle. Does this help clear things up a bit?
- sambabu9 13y agoSo are you saying we can use docker to create VMs which means it is competing with Vagrant and Openstack. If we use docker to deploy containers(war, mysql) then it is competing with Chef and Puppet. I am still confused what is the best use of docker. Do people really use docker to create VMs I doubt this
- imperialWicket 13y agoPacker really belongs in that list, or will soon be a bigger part of it, imo. Packer is another HashiCorp (vagrant) product and in the same way vagrant lets you use your config mgmt to launch and provision a vm, packer lets you use your config mgmt to build an image for various target platforms (ami, vbox, docker, etc.).
- haraball 13y agoWhat were your conclusions?
- i386 13y agoThat they are ultimately complementary. Something still needs to manage what docker images run on a physical node and manage the contents of the Docker image. On the latter point, the Dockerfile is just a glorified shell script. Puppet/Chef have proven that declarative descriptions of systems is the way to go for a number of reasons and a return to imperative management of machines is a step backward. That all said Docker is fantastic. Definitely a step in the right direction (your deployable artefact is the container) but we need the dust to settle before the workflows that really work appear.