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 22, 2014, at 7:29 AM, alambike < " target="_blank"> > 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
Archive powered by MHonArc 2.6.16.