chef-container is chef-docker integration. while chef-metal is a common
abstraction of a VM or machine. chef-container allows managing docker
instances via chef’s ecosystem (attributes, run list etc). It also allows
you to add run time changes to docker containers (IP for example).
Chef metal on the other hand, gives you a machine resource . and several
providers (fog, docker, lxc, vagrant etc), you can run normal chef recipes
with machine resource and plugin in different drivers for different
environments (create development environment with containers/vagrant,
create production environment on aws / linode etc.
Chef-metal does not support bare metal provisioning yet (not sure an
iPXE driver may be on its way ). While chef-container does not support LXC,
openvz, solaris, WPAR, systemd-nspawn, lmctfy or any other containers, and
i think by design it will only support docker. Also, note, philosophically
docker ecosystem does not like changing container images post creation.
Chef based containers does not violate this, but makes it easy to do so.
Chef-metal recently added image resource which can be used as a software
abstraction across ami, lxc images etc.
So, in short, the difference is more like fog vs aws-sdk. In future, docker
specific things might be easy to provide via chef-container, chef-metal
may be able to reuse chef-container’s code for its docker driver. If you
are building docker specific stuff chef-container might be preferred, if
On Fri, Aug 29, 2014 at 9:54 AM, Ringo De Smet email@example.com
There is a lot going on with Chef and containers. More specifically, I see
chef-metal (1) and chef-container (2) popping up. However, it’s not quite
clear how these 2 compare to each other. Are they complementary? Will they
Can a Chef person bring some enlightenment?