[chef] Re: chef-init (chef-container)


Chronological Thread 
  • From: "Julian C. Dunn" < >
  • To:
  • Subject: [chef] Re: chef-init (chef-container)
  • Date: Tue, 23 Dec 2014 11:16:41 -0500

On Dec 22, 2014, at 7:29 AM, alambike < " class=""> > 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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail




Archive powered by MHonArc 2.6.16.

§