Chef-init (chef-container)


#1

Hi,

Chef container, and specifically chef-init, is a promising solution for the
problem of converge chef inside containers.

I was facing the problem of managing services inside docker containers, and
was having to trap service resources in run list and rewrite to use an
specifical provider.

Thanks to chef init all of this could be avoided, just letting chef-init to
patch service resource, so recipes can be made without have to worry about
if convergence is happening inside a container, or in other ‘recipient’,
and the community cookbooks could work without modification.

Maybe would be cleaner if it was integrated into chef-client and maybe,
imho, runit shouldn’t be into omnibus installation, and instead be part of
the base image, or installed throught runit cookbook, with config files
outside omnibus directory, but anyway as it is solve some of my problems.

What are the plans about this project?, is chef-init going to be continued?

Thanks,

J.Gomez


#2

On Dec 22, 2014, at 7:29 AM, alambike alambike@gmail.com wrote:

Chef container, and specifically chef-init, is a promising solution for the problem of converge chef inside containers.
I was facing the problem of managing services inside docker containers, and was having to trap service resources in run list and rewrite to use an specifical provider.

Thanks to chef init all of this could be avoided, just letting chef-init to patch service resource, so recipes can be made without have to worry about if convergence is happening inside a container, or in other ‘recipient’, and the community cookbooks could work without modification.

Maybe would be cleaner if it was integrated into chef-client and maybe, imho, runit shouldn’t be into omnibus installation, and instead be part of the base image, or installed throught runit cookbook, with config files outside omnibus directory, but anyway as it is solve some of my problems.

What are the plans about this project?, is chef-init going to be continued?

We’re not sure right now. chef-init solved one problem — process supervision and running Chef Client inside a container — but after building it, we found that most folks don’t want to do that. (“I have a single-process container and you want me to run a Ruby process alongside it?”) Right now the future of the project is up for grabs.

Ideally I think there should be a Chef-fy way of managing the container state from outside the container, which might wind up being future work in Chef Provisioning.

  • Julian

#3

As an example use case of how to manage config and services inside a
container image and specifically Docker, we use chef to replace
Dockerfiles. Chef solo is used to build docker images and that’s it. That
let us re-use dozens of internal and all the open source cookbooks. That
let us manage our docker images just like VMs or other nodes, just
standalone and frozen after the build.
On Dec 23, 2014 5:17 PM, “Julian C. Dunn” jdunn@aquezada.com wrote:

On Dec 22, 2014, at 7:29 AM, alambike alambike@gmail.com wrote:

Chef container, and specifically chef-init, is a promising solution for
the problem of converge chef inside containers.

I was facing the problem of managing services inside docker containers,
and was having to trap service resources in run list and rewrite to use an
specifical provider.

Thanks to chef init all of this could be avoided, just letting chef-init
to patch service resource, so recipes can be made without have to worry
about if convergence is happening inside a container, or in other
’recipient’, and the community cookbooks could work without modification.

Maybe would be cleaner if it was integrated into chef-client and maybe,
imho, runit shouldn’t be into omnibus installation, and instead be part of
the base image, or installed throught runit cookbook, with config files
outside omnibus directory, but anyway as it is solve some of my problems.

What are the plans about this project?, is chef-init going to be continued?

We’re not sure right now. chef-init solved one problem — process
supervision and running Chef Client inside a container — but after building
it, we found that most folks don’t want to do that. (“I have a
single-process container and you want me to run a Ruby process alongside
it?”) Right now the future of the project is up for grabs.

Ideally I think there should be a Chef-fy way of managing the container
state from outside the container, which might wind up being future work in
Chef Provisioning.

  • Julian

#4

On Tue, 23 Dec 2014, Maxime Brugidou wrote:

As an example use case of how to manage config and services inside a
container image and specifically Docker, we use chef to replace
Dockerfiles. Chef solo is used to build docker images and that’s it. That
let us re-use dozens of internal and all the open source cookbooks. That
let us manage our docker images just like VMs or other nodes, just
standalone and frozen after the build.

Yep, and that’s a valuable use case and why ‘knife container’ was built.
But that’s not the same thing as ‘chef-init’?

  • Julian

#5

Thanks for responses,

I understand that to build docker images chef-init is a good start, but
maybe to run the services inside the container (as PID 1) is a bit
redundant, just because runit is enough to this task or because you dont
want to run any proccess manager at all.

Based on this I copy the patch to Chef service resource in my base cookbook
and modify the runit provider to pull from system installation. Converging
the image with this recipe in runlist works fine and if I want to rerun
convergence inside a new or running container always can with ‘docker exec’.

Anyway, having a standard form to converge inside containers or just simply
build docker images with chef I think would be useful. Chef provisioning
looks good, but maybe its objetives are more general and more focused in
cluster management, maybe chef-init could be a driver to docker/lxc
platform in this context but I think that a form to converge chef recipes
inside a container is still needeed.

Greetings.

El 24/12/2014 04:18, “Julian C. Dunn” jdunn@aquezada.com escribió:

On Tue, 23 Dec 2014, Maxime Brugidou wrote:

As an example use case of how to manage config and services inside a

container image and specifically Docker, we use chef to replace
Dockerfiles. Chef solo is used to build docker images and that’s it. That
let us re-use dozens of internal and all the open source cookbooks. That
let us manage our docker images just like VMs or other nodes, just
standalone and frozen after the build.

Yep, and that’s a valuable use case and why ‘knife container’ was built.
But that’s not the same thing as ‘chef-init’?

  • Julian

#6

On Sat, 27 Dec 2014, alambike wrote:

I understand that to build docker images chef-init is a good start, but
maybe to run the services inside the container (as PID 1) is a bit
redundant, just because runit is enough to this task or because you dont
want to run any proccess manager at all.

Based on this I copy the patch to Chef service resource in my base cookbook
and modify the runit provider to pull from system installation. Converging
the image with this recipe in runlist works fine and if I want to rerun
convergence inside a new or running container always can with ‘docker exec’.

Anyway, having a standard form to converge inside containers or just simply
build docker images with chef I think would be useful. Chef provisioning
looks good, but maybe its objetives are more general and more focused in
cluster management, maybe chef-init could be a driver to docker/lxc
platform in this context but I think that a form to converge chef recipes
inside a container is still needeed.

Right, one of the things we were contemplating was to implement a way to
have Chef Provisioning do the container convergence operations from
outside the container, as you say, so the container itself is not
burdened with the Chef client. We’ll definitely be doing more research
& development in this area in the new year.

  • 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 ]


#7

Ranjib has this type of "converge inside the container, from the host"
type of thing working, using Fork if I’m not mistaken – it forks into
the container process then converges, all with native ruby. Maybe ping
him about it?

I assume something similar could be done with Docker Exec, although
the FD’s may get a little tricky, as might any FD’s the
child/grandchildren create/destroy/leak.

2c cheers,

–aj

On Sun, Dec 28, 2014 at 8:06 AM, Julian C. Dunn jdunn@aquezada.com wrote:

On Sat, 27 Dec 2014, alambike wrote:

I understand that to build docker images chef-init is a good start, but
maybe to run the services inside the container (as PID 1) is a bit
redundant, just because runit is enough to this task or because you dont
want to run any proccess manager at all.

Based on this I copy the patch to Chef service resource in my base
cookbook
and modify the runit provider to pull from system installation. Converging
the image with this recipe in runlist works fine and if I want to rerun
convergence inside a new or running container always can with ‘docker
exec’.

Anyway, having a standard form to converge inside containers or just
simply
build docker images with chef I think would be useful. Chef provisioning
looks good, but maybe its objetives are more general and more focused in
cluster management, maybe chef-init could be a driver to docker/lxc
platform in this context but I think that a form to converge chef recipes
inside a container is still needeed.

Right, one of the things we were contemplating was to implement a way to
have Chef Provisioning do the container convergence operations from outside
the container, as you say, so the container itself is not burdened with the
Chef client. We’ll definitely be doing more research & development in this
area in the new year.

  • 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 ]


#8

:slight_smile: i was just planning to respond. I use the attach method from liblxc. I
am not sure about docker’s attach semantics, but kernel allows entering a
different namespace via standard clone(2) [1], so you should be able to do
irrespective of whether docker provides that or not, if you have the
container pid.
You can take a look at the chef-lxc implementation here[2]

As AJ mentioned, you have to clean up FDs, I might add this on lxc-extra
(something that emulate close_on_exec flag of posix spawn)
Take a look at the chef-lxc README for usage examples.

cheers
ranjib
[1] http://man7.org/linux/man-pages/man2/clone.2.html
[2] https://github.com/ranjib/chef-lxc

On Sat, Dec 27, 2014 at 11:17 AM, AJ Christensen <
aj@junglistheavy.industries> wrote:

Ranjib has this type of "converge inside the container, from the host"
type of thing working, using Fork if I’m not mistaken – it forks into
the container process then converges, all with native ruby. Maybe ping
him about it?

I assume something similar could be done with Docker Exec, although
the FD’s may get a little tricky, as might any FD’s the
child/grandchildren create/destroy/leak.

2c cheers,

–aj

On Sun, Dec 28, 2014 at 8:06 AM, Julian C. Dunn jdunn@aquezada.com
wrote:

On Sat, 27 Dec 2014, alambike wrote:

I understand that to build docker images chef-init is a good start, but
maybe to run the services inside the container (as PID 1) is a bit
redundant, just because runit is enough to this task or because you dont
want to run any proccess manager at all.

Based on this I copy the patch to Chef service resource in my base
cookbook
and modify the runit provider to pull from system installation.
Converging

the image with this recipe in runlist works fine and if I want to rerun
convergence inside a new or running container always can with ‘docker
exec’.

Anyway, having a standard form to converge inside containers or just
simply
build docker images with chef I think would be useful. Chef provisioning
looks good, but maybe its objetives are more general and more focused in
cluster management, maybe chef-init could be a driver to docker/lxc
platform in this context but I think that a form to converge chef
recipes

inside a container is still needeed.

Right, one of the things we were contemplating was to implement a way to
have Chef Provisioning do the container convergence operations from
outside
the container, as you say, so the container itself is not burdened with
the
Chef client. We’ll definitely be doing more research & development in
this
area in the new year.

  • 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 ]