# Chef-init (chef-container)

**URL:** <https://discourse.chef.io/t/chef-init-chef-container/6103>\
**Category:** Chef Infra (archive)\
**Created:** [December 22, 2014, 12:29pm UTC](https://discourse.chef.io/t/chef-init-chef-container/6103 "2014-12-22T12:29:59Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![alambike](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/alambike/32/183_2.png) [@alambike](https://discourse.chef.io/u/alambike)\
**Post date:** [December 22, 2014, 12:29pm UTC](https://discourse.chef.io/t/chef-init-chef-container/6103/1 "2014-12-22T12:29:59Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![jdunn](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/jdunn/32/1800_2.png) [@jdunn](https://discourse.chef.io/u/jdunn)\
**Post date:** [December 23, 2014, 4:16pm UTC](https://discourse.chef.io/t/chef-init-chef-container/6103/2 "2014-12-23T16:16:41Z")

</div>

On Dec 22, 2014, at 7:29 AM, alambike [alambike@gmail.com](mailto: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

---

<div class="post-metadata">

**Author:** ![Maxime\_Brugidou](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/maxime_brugidou/32/55_2.png) [@Maxime\_Brugidou](https://discourse.chef.io/u/Maxime_Brugidou)\
**Post date:** [December 23, 2014, 9:57pm UTC](https://discourse.chef.io/t/chef-init-chef-container/6103/3 "2014-12-23T21:57:04Z")

</div>

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](mailto:jdunn@aquezada.com) wrote:

> On Dec 22, 2014, at 7:29 AM, alambike [alambike@gmail.com](mailto: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

---

<div class="post-metadata">

**Author:** ![jdunn](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/jdunn/32/1800_2.png) [@jdunn](https://discourse.chef.io/u/jdunn)\
**Post date:** [December 24, 2014, 3:18am UTC](https://discourse.chef.io/t/chef-init-chef-container/6103/4 "2014-12-24T03:18:18Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![alambike](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/alambike/32/183_2.png) [@alambike](https://discourse.chef.io/u/alambike)\
**Post date:** [December 27, 2014, 1:15pm UTC](https://discourse.chef.io/t/chef-init-chef-container/6103/5 "2014-12-27T13:15:07Z")

</div>

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](mailto: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

---

<div class="post-metadata">

**Author:** ![jdunn](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/jdunn/32/1800_2.png) [@jdunn](https://discourse.chef.io/u/jdunn)\
**Post date:** [December 27, 2014, 7:06pm UTC](https://discourse.chef.io/t/chef-init-chef-container/6103/6 "2014-12-27T19:06:24Z")

</div>

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](mailto:jdunn@aquezada.com) \* Sorry, I'm ]  
[WWW: [Julian Dunn's Blog - Commentary on media, technology, and everything in between.](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]

---

<div class="post-metadata">

**Author:** ![AJ\_Christensen2](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/aj_christensen2/32/42_2.png) [@AJ\_Christensen2](https://discourse.chef.io/u/AJ_Christensen2)\
**Post date:** [December 27, 2014, 7:17pm UTC](https://discourse.chef.io/t/chef-init-chef-container/6103/7 "2014-12-27T19:17:23Z")

</div>

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](mailto: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](mailto:jdunn@aquezada.com) \* Sorry, I'm ]  
> [WWW: [Julian Dunn's Blog - Commentary on media, technology, and everything in between.](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]

---

<div class="post-metadata">

**Author:** ![Ranjib](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/ranjib/32/1040_2.png) [@Ranjib](https://discourse.chef.io/u/Ranjib)\
**Post date:** [December 27, 2014, 7:33pm UTC](https://discourse.chef.io/t/chef-init-chef-container/6103/8 "2014-12-27T19:33:45Z")

</div>

🙂 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] [clone(2) - Linux manual page](http://man7.org/linux/man-pages/man2/clone.2.html)  
[2] [GitHub - ranjib/chef-lxc: Build LXC using Chef](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](mailto: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](mailto:jdunn@aquezada.com) \* Sorry, I'm ]  
> > [WWW: [Julian Dunn's Blog - Commentary on media, technology, and everything in between.](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]