On Fri, Oct 21, 2016 at 9:29 AM, Daniel J Walsh <dwa...@redhat.com> wrote:
> That might make the most sense. > > RHEL7 == Base Image > > RHEL7Systemd == BaseImage + Config to run systemd as pid1. > +1, maybe call it RHEL7-system image? > > > > On 10/21/2016 12:26 PM, Daniel Riek wrote: > > Question: should we separate a true minimal base image that as default > run's a shell and the default iamge that runs systemd and behaves more like > a linux system? > > On Fri, Oct 21, 2016 at 12:02 PM, Clayton Coleman <ccole...@redhat.com> > wrote: > >> This seems like a breaking API change (as you note) for downstream >> consumers. Seems more correct to create a new image for that. >> >> > On Oct 21, 2016, at 11:50 AM, Daniel J Walsh <dwa...@redhat.com> wrote: >> > >> > If we make this change, we would want to do it in Fedora and Centos >> also. >> > >> > https://bugzilla.redhat.com/show_bug.cgi?id=1387282 >> > >> > The benefits of making this change are that people new to containers >> > could follow a simple workflow similar to what the do on the OS, where >> > all they need to do is install an rpm service and enable and it is ready >> > to go. >> > >> > >> > # cat Dockerfile >> > >> > FROM rhel7 >> > >> > RUN dnf -y install httpd; systemctl enabled httpd >> > >> > ADD MYAPP / >> > >> > >> > # docker build -t MYAPP . >> > >> > >> > And they are done. Now if they run their container >> > >> > docker run -d MYAPP >> > >> > And their app runs with systemd/journald and httpd with their app runnin >> > inside of it. >> > >> > >> > For users who don't want to use systemd, they would just override the >> > CMD field and their container would work fine. >> > >> > Since the current default is bash, they would need to do this anyways. >> > >> > >> > A couple of things will break, >> > >> > docker run -ti rhel7 >> > >> > Currently runs a shell. With the new change, systemd would start up >> > inside of the contaienr. >> > >> > >> > Users who want a shell would need to execute >> > >> > docker run -ti rhel7 /bin/sh >> > >> > (I always do this anyways, but I guess some people do not) >> > >> > >> > The other big issue is on stopping of containers. docker stop currently >> > defaults to sending SIGTERM to the pid 1 of the container. >> > >> > systemd requires that SIGRTMIN+3 be sent to it to close down properly. >> > If we want to have systemd work by default, we would >> > >> > need to change the default SIGSTOP of the base image. This means any >> > application based on the base image that does not >> > >> > override the SIGSTOP would get SIGRTMIN+3. Most apps will die when they >> > get this signal, but if the App had a signal handler for >> > >> > SIGTERM, the signal handler will not work correctly. >> > >> > >> > Adding >> > >> > SIGSTOP SIGTERM >> > >> > to a Dockerfile would fix the issue, but it will cause unexpected >> > breakage. I don't see an easy solution for this. >> > >> > >> > >> >> > > > -- > Daniel Riek <r...@redhat.com> > * Sr. Director Systems Design & Engineering > * Red Hat Inc, Tel. +1-617-863-6776 > > >
