Chef-metal vs chef-container?


#1

Hello,

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
merge?

(1) https://github.com/opscode/chef-metal
(2) http://docs.getchef.com/containers.html

Can a Chef person bring some enlightenment?

Greetz,

Ringo


#2

On Fri, Aug 29, 2014 at 12:54 PM, Ringo De Smet ringo.desmet@gmail.com wrote:

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
merge?

(1) https://github.com/opscode/chef-metal
(2) http://docs.getchef.com/containers.html

Can a Chef person bring some enlightenment?

Chef Metal is intended to orchestrate a cluster, or an entire pile of
infrastructure, independent of the underlying machine technology (VMs
on EC2, VMs on Azure, VMWare VMs, containers, even bare metal). You
can mix and match.

For using containers with Chef Metal, it’s likely that there will be
some crossover. For example, the chef-metal driver for containers may
use or integrate with some of the code we developed for containers. We
aren’t totally sure yet as we haven’t gotten there.

If you don’t care about cluster orchestration, then you can ignore
Metal. But we still have folks interested in containers generally,
particularly application devs that don’t care about a cluster, they
just want a runtime. Chef for Containers (chef-init and
knife-container specifically are the software components) helps bring
configuration management to containers, because a Dockerfile and
golden images aren’t configuration management. That’s the pitch.

HTH,

  • Julian


[ Julian C. Dunn jdunn@aquezada.com * Sorry, I’m ]
[ WWW: http://www.aquezada.com/staff/julian * only Web 1.0 ]
[ gopher://sdf.org/1/users/keymaker/ * compliant! ]
[ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9 ]


#3

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 :slight_smile: (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
not chef-metal :slight_smile:

cheers
ranjib

On Fri, Aug 29, 2014 at 9:54 AM, Ringo De Smet ringo.desmet@gmail.com
wrote:

Hello,

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
merge?

(1) https://github.com/opscode/chef-metal
(2) http://docs.getchef.com/containers.html

Can a Chef person bring some enlightenment?

Greetz,

Ringo


#4

On Fri, Aug 29, 2014 at 2:50 PM, Ranjib Dey dey.ranjib@gmail.com wrote:

Chef-metal does not support bare metal provisioning yet :slight_smile: (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.

There is some chef-metal bare metal work going on, like a Hanlon driver.


Bryan


#5

On Fri, Aug 29, 2014 at 2:50 PM, Ranjib Dey dey.ranjib@gmail.com wrote:

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-init (part of the container offering) also provides “PID 1” and
process supervision for the container processes you launch within the
container.

Chef-metal does not support bare metal provisioning yet :slight_smile: (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

We wouldn’t rule out support for things other than Docker, but let’s
see how things play out. Maybe not WPAR though :stuck_out_tongue:

  • Julian


[ Julian C. Dunn jdunn@aquezada.com * Sorry, I’m ]
[ WWW: http://www.aquezada.com/staff/julian * only Web 1.0 ]
[ gopher://sdf.org/1/users/keymaker/ * compliant! ]
[ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9 ]


#6

I found it baffling why chef-metal (which is not at all bare metal but rather an orchestration tool) wasn’t named something more intention-revealing.

Chef-metal may have been a better name for chef-hanlon.

And chef-metal could have been called something like chef-orchestration.

Not sure what the names would be better as, and I appreciate tools evolve, but I do feel ambiguity causes extra tools to spring up when attention could be better focused if names helped with the wayfinding.

Cheers, M.

Sent from my iPhone

On Aug 29, 2014, at 2:58 PM, Bryan McLellan btm@loftninjas.org wrote:

On Fri, Aug 29, 2014 at 2:50 PM, Ranjib Dey dey.ranjib@gmail.com wrote:
Chef-metal does not support bare metal provisioning yet :slight_smile: (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.

There is some chef-metal bare metal work going on, like a Hanlon driver.

https://github.com/opscode/chef-metal-hanlon
https://github.com/csc/Hanlon

Bryan