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


Chronological Thread 
  • From: AJ Christensen < >
  • To: " " < >
  • Subject: [chef] Re: Re: Re: Re: Re: Re: chef-init (chef-container)
  • Date: Sun, 28 Dec 2014 08:17:23 +1300

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



Archive powered by MHonArc 2.6.16.

§