10 ms·

Dockerfiles can build off of other Dockerfiles (the FROM) directive. What you'd want to do in this situation is probably build a base Docker image that apps bui

Dockerfiles can build off of other Dockerfiles (the FROM) directive. What you'd want to do in this situation is probably build a base Docker image that apps build off of, with this base Docker image containing your "standard things." If you have a lot of Chef, you can get this up and running pretty quickly by using Packer (http://www.packer.io http://www.packer.io). Packer can build Docker images using Chef to provision them. The next version of Packer (already in git) can tag and push those images to a registry, too, if you want. You probably do, if you want downstream to use Dockerfiles. Using Packer for the creation of the containers has helped a lot of organizations we work with use Docker while maintaining existing workflows and tools that their employees are trained to use well and that they're happy with. Its a good balance, and easy to replace things with Dockerfiles if you feel the need. In terms of "allowing dev & ops to layer", the way this looks is you separate what layers you need: clearly you need a base layer (OS), then you want a standard layer (monitoring agents and so on), then maybe you want a stack-specific layer (rails vs node vs whatever), then finally maybe you want devs to be able to put in their application. Dockerfiles are great and concise for apps (put files here, start by running this command, etc.). Chef/Puppet are great for pretty much the rest of the stack upwards. Packer comes into play there. It is just an option, at the end of the day, but it can provide a smoother adoption process without having to disrupt too much.

shykes 13y ago
> Dockerfiles are great and concise for apps (put files here, start by running this command, etc.). Chef/Puppet are great for pretty much the rest of the stack upwards. Packer comes into play there. You really don't need packer to use Chef in a docker build. Just install Chef as part of your build, add your cookbooks, and run chef with the arguments of your choice. That's 3 extra lines in your Dockerfile. As a bonus, you get to manage the exact build and version of chef to use, using the exact same syntax and toolbox as for the rest of your software stack. At the end day, chef is just that - software. Why make it a hardcoded special case? See for example this blog post: http://tech.paulcz.net/2013/09/creating-immutable-servers-with-chef-and-docker-dot-io.html http://tech.paulcz.net/2013/09/creating-immutable-servers-wi...
- mitchellh 13y ago
  That's very true, although there is usually quite a lot more to configuring Chef, I can see that it can be done without too much complication using Dockerfiles. I apologize for not mentioning this. I prefer Chef (or some other provisioners) as a special case because it is a common case. It is just software, but if all your servers (or a majority) are configured using Chef, its nice to have an abstraction to make this easy. The same argument could've been said for Vagrant early on, probably: I could've just supported shell scripts, because shell scripts could install Chef, then run Chef. Perhaps so, but having the "just set this one to handful of options and you get Chef for free" functionality was a big win for both Vagrant and Chef adoption (as well as other provisioners, I'm just using Chef as an example here). Likewise, I'm finding that having Docker as a special case in Packer/Vagrant is doing the same: it is educating more people about Docker with a low barrier and bringing more people into an ecosystem I like (VMs, containerization, immutability, or any mix there-in). I'm super excited about where Docker is headed, and glad containers are finally reaching a point where they're friendlier for laypeople (as in... not super experienced Linux sysadmins) can use them. :)

shykes 13y ago

> Dockerfiles are great and concise for apps (put files here, start by running this command, etc.). Chef/Puppet are great for pretty much the rest of the stack upwards. Packer comes into play there. You really don't need packer to use Chef in a docker build. Just install Chef as part of your build, add your cookbooks, and run chef with the arguments of your choice. That's 3 extra lines in your Dockerfile. As a bonus, you get to manage the exact build and version of chef to use, using the exact same syntax and toolbox as for the rest of your software stack. At the end day, chef is just that - software. Why make it a hardcoded special case? See for example this blog post: http://tech.paulcz.net/2013/09/creating-immutable-servers-with-chef-and-docker-dot-io.html http://tech.paulcz.net/2013/09/creating-immutable-servers-wi...

mitchellh 13y ago
That's very true, although there is usually quite a lot more to configuring Chef, I can see that it can be done without too much complication using Dockerfiles. I apologize for not mentioning this. I prefer Chef (or some other provisioners) as a special case because it is a common case. It is just software, but if all your servers (or a majority) are configured using Chef, its nice to have an abstraction to make this easy. The same argument could've been said for Vagrant early on, probably: I could've just supported shell scripts, because shell scripts could install Chef, then run Chef. Perhaps so, but having the "just set this one to handful of options and you get Chef for free" functionality was a big win for both Vagrant and Chef adoption (as well as other provisioners, I'm just using Chef as an example here). Likewise, I'm finding that having Docker as a special case in Packer/Vagrant is doing the same: it is educating more people about Docker with a low barrier and bringing more people into an ecosystem I like (VMs, containerization, immutability, or any mix there-in). I'm super excited about where Docker is headed, and glad containers are finally reaching a point where they're friendlier for laypeople (as in... not super experienced Linux sysadmins) can use them. :)