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.
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
Archive powered by MHonArc 2.6.16.