[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [atomic-devel] Systemd, containers, and pid=host





> On Mar 12, 2015, at 2:30 PM, Daniel J Walsh <dwalsh redhat com> wrote:
> 
> 
>> On 03/12/2015 02:05 PM, Clayton Coleman wrote:
>> Is there a technical path to not needing the cgroup?  Are we "hacking" systemd to run in a container, vs making it truly capable of letting that control go?
> This is in kernel land right now.  Systemd refuses to do away with
> needing systemd within the container.  There is some effort to add a
> cgroup namespace, which would allow us to have sys/fs/cgroup within the
> container but only have the processes in the container listed.  This
> would allow us to have containers run with this information always
> available.  And potentially be able to use cgroups within the container. 
> 
> Mounting /sys/fs/cgroup into the container automatically means you are
> leaking information into the container about processes outside the
> container.

Until this happens, I don't think systemd in a container is a real solution (and I'm also concerned about not communicating process restarts out).  We need a user space solution first and foremost (pure process management).  Being able to manage CGroups and the full functionality of the unit is good, but it has to be simple and easy to use.  What options do we have in the short term besides systemd as a container init?  At the core, being able to turn the unit file into the container process definition and properly handling our pid one duties (including forwarding stdout/err) is what the container init process needs to be managing.  I don't want to push people back into foreman or supervisord.

> 
> 
>>> On Mar 12, 2015, at 1:21 PM, Daniel J Walsh <dwalsh redhat com> wrote:
>>> 
>>> You could write a simple script for this now, as long as the rpm
>>> containing the unit file was availabel
>>> 
>>> FROM baseos
>>> RUN yum install PATHTOUNIT; systemctl enable unit
>>> CMD /usr/sbin/init
>>> 
>>> docker build -t MYUNIT .
>>> 
>>> docker run -d -v /sys/fs/cgroup:/sys/fs/cgroup -n MYUNIT MYUNIT
>>> 
>>> With docker-1.5.0 in rhel this should run systemd within a container
>>> 
>>> We are putting these patches into Fedora also.
>>> 
>>> machinectl MYUNIT
>>> and
>>> journactl -m MYUNIT
>>> 
>>> Should work, also.
>>> 
>>> Only ugliness is the mounting of the cgroup file system.
>>> 
>>> 
>>> This would end up with
>>>> On 03/12/2015 09:40 AM, Clayton Coleman wrote:
>>>> 
>>>> 
>>>>>> On Mar 12, 2015, at 9:30 AM, Joe Brockmeier <jzb redhat com> wrote:
>>>>>> 
>>>>>> On 03/12/2015 07:02 AM, Clayton Coleman wrote:
>>>>>> Also, we should have a tool that takes an rpm with a systemd init file
>>>>>> and ends up with a docker image that works.
>>>>> "should have" as in "we have that lying around somewhere" or "should
>>>>> have" as in "we should put this on a board for someone to work on"?
>>>> Latter - systemd unit defines the context of execution, and in both docker and rocket it should be possible to automatically "image" the package.  On the backend, we can use the process direct, insert a systemd container, or (in the long term) convert to rocket or direct systemd execution.
>>>> 
>>>>> Might be a good thing to spec out in Matt's repo as a proposal?
>>>>> 
>>>>> https://github.com/projectatomic/oversight
>>>>> 
>>>>> Best,
>>>>> 
>>>>> jzb
>>>>> -- 
>>>>> Joe Brockmeier | Principal Cloud & Storage Analyst
>>>>> jzb redhat com | http://community.redhat.com/
>>>>> Twitter: @jzb  | http://dissociatedpress.net/
> 


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]