On Thu, Feb 26, 2015 at 8:31 AM, Gorka Lertxundi <glertxundi_at_gmail.com> wrote:
> Hi,
>
> My name is Gorka, not Gornak! It seems like suddenly I discovered that I was
> born in the eastern europe! hehe :)
>
> I'll answer to both of you, mixed, so try not to get confused.
>
> Lets go,
>
>> > But Gornak - I must say that your new ubuntu base image really seem *a
>> > lot* better than the phusion/baseimage one. It is fantastic and an
>> > excellent job you have done there and you continue to update with new
>> > versions of s6, etc. Can't really say thank you enough for that.
>
>
> Thanks!
>
>> I think if anybody were to start up a new baseimage project, Alpine is
>> the way to go, hands-down. Tiny, efficient images.
>
>
> Wow, I didn't hear about Alpine Linux. What would differentiate from, for
> example, busybox with opkg? https://github.com/progrium/busybox. Busybox is
> battle-tested and having a package manager in it seems the right way.
>
> The problem with these 'not as mainstream as ubuntu' distros is the smaller
> community around it. That community discovers things that you probably
> didn't be aware of, bugfixes, fast security updates, ... . So my main
> concern about the image is not its size but the
> keep-easily-up-to-date-and-secure no matter it size. Even so, although you
> probably know that, docker storages images incrementally so that just the
> base images is stored once and all app-specific images will be on top of
> this image.
>
> It is always the result of a commitment to easy of use, size and
> maintainability.
>
>>
>> > Great work Gorka for providing these linux x86_64 binaries on Github
>> > releases.
>> > This was exactly the kind of thing I was hoping for / looking for in
>> > regards to that aspect.
>
>
> As I said in my last email, I'll try to keep them updated
>
>> > Right so I was half-expecting this kind of response (and from John
>> > Regan too). In my initial post I could not think of a concise-enough
>> > way to demonstrate and explain my reasoning behind that specific
>> > request. At least not without entering into a whole other big long
>> > discussion that would have detracted / derailed from some of the other
>> > important considerations and discussion points in respect to docker.
>> >
>> > Basically without that capability (which I am aware goes against
>> > convention for process supervisors that occupy pid 1). Then you are
>> > forcing docker users to choose an XOR (exclusive-OR) between either
>> > using s6 process supervision or the ability to specify command line
>> > arguments to their docker containers (via ENTRYPOINT and/or CMD).
>> > Which essentially is like a breakage of those ENTRYPOINT and CMD
>> > features of docker. At least that is my understanding how pretty much
>> > all of these process supervisors behave. And not any criticism
>> > levelled at s6 alone. Since you would not typically expect this
>> > feature anyway (before we had containerisation etc.). It is very
>> > docker-specific.
>> >
>> > Both of you seem to have stated effectively that you don't really see
>> > such a pressing reason why it is needed.
>> >
>> > So then it's another thing entirely for me to explain why and convince
>> > you guys there are good reasons for it being important to be able to
>> > continue to use CMD and ENTRYPOINT for specifying command line
>> > arguments still remains an important thing after adding a process
>> > supervisor. There are actually many different reasons for why that is
>> > desirable (that I can think of right now). But that's another
>> > discussion and case for me to make to you.
>> >
>> > I would be happy to go into that aspect further. Perhaps off-the
>> > mailing list is a better idea. To then come back here again when that
>> > discussion is over and concluded with a short summary. But I don't
>> > want to waste anyone's time so please reply and indicate if you would
>> > really like for me to go into more depth with better justifications
>> > for why we need that particular feature.
>
>
> I don't think it must be one or another. With CMD [ "/init" ] you can:
^^ Okay so this is what I have been trying to say but Gorka has put
more elegantly here. So you kindda have to try to support both.
> * start your supervisor by default: docker run your-image
> * get access to the container directly without any s6 process started:
> docker run your-image /bin/bash
> * run a custom script and supervise it: docker run your-image /init
> /your-custom-script
>
>>
>> > Would appreciate coming back to how we can do this later on. After I
>> > have made a more convincing case for why it's actually needed. My
>> > naive assumption, not knowing any of s6 yet: It should be that simply
>> > passing on an argv[] array aught to be possible. And perhaps without
>> > too many extra hassles or loops to jump through.
>
>
> Would appreciate that use-cases! :-)
To make an overview
* Containers that provide Development tools / dev environments - often
those category of docker images take direct cmd line args.
* Here are some examples of complex single-shot commands that often
take command line arguments:
* To run a complex build of something (which may spawn out to many cores)
* It is very desirable to build software in docker containers.
* To launch a dev sandbox local web server (e.g. when hacking on a
Ruby on Rails website, or nodjs / python / whatever)
* Like I run 'ruhoh serve -9595' for my web development (where
the argument specifies the TCP port number.
* Those above examples ^^ are not an isolated case - that is a whole
category of docker images.
* It is not uncommon for people to just make a shell `alias
myalias=docker run <docker opts> image name` shortcut for these
single-shot commands.
* Then passing across the 'myalias <extra args>' which just get
appended to the full `docker run imagename …` command.
Another, entirely different example:
* If a new docker user even just wants to write the simplest of shell
scripts in a container.
* And they decide to make it POSIX compliant (#!/bin/sh shebang line)
* And they decided to use the ubuntu base image.
* Then their default /bin/sh shell will point to DASH (not bash).
* Because ubuntu officially decided upon dash, which is 2x
faster than 'bash' for POSIX compliant scripts.
* Well guess what I found out guys? Dash subshells are ALWAYS
orphaned children.
* Everything except for & backgrounding
* So if the user's script is busy or hung during a ``
backpacks or $() or pipe |
* Then docker stop won't kill it - 'error: no such
process'. Buggers up the docker daemon.
* This may also be true of other images that have a /bin/sh such
as debian and busybox. I haven't investigated.
^^ And that was just a simple system shell script. Nevermind whatever
hideously complex java, python and so on tool which other people try
to use.
My point being that a good way to save grief of new users who are not
aware of things like this. Then it should be possible to convert any
existing docker images to use FROM: baseimage-s6 whatever, and Gorka's
init. And this is something deserved of even the simplest of docker
containers.
Process supervision can be needed even on the simplest of docker
containers, never mind running persistent services like mysql etc.
Some people just want to run a single-shot command. However that
command may be unknown to the user and shell out etc. So let them
change their FROM: line and pre-pend s6 init to their existing
CMD/ENTRYPOINT combination. And they can make safe their existing
containers.
Even non-services things, and the simplest docker images (which may be
single-shot commands) deserve to be able to have this as a simple
modification. To get the .s6 stop script which will TERM any zombies.
It is something we can do more generally for the docker community.
Rather than being only concerned with out own direct and immediate
needs. As having such a feature makes easier for other people to
universally make use of. So I can recommend people universally use
this solution without having to ask them: oh but let me first check
BTW how actually to you use CMD and ENTRYPOINT in your docker images?
It sounds like we should not have to impose that restriction.
And like Gorka said it's possible to have both ways and not impose a
restriction of one way over the other.
Anyway, to make my point more pointedly, Here are some real-world examples…
These docker images already use docker's CMD feature for letting users
pass in cmdline args. But they are also all sufficiently complex
software to benefit from being run under a process supervisor such as
s6.
* maven:
https://registry.hub.docker.com/_/maven/
* consul:
https://github.com/progrium/docker-consul
* pipework:
https://github.com/dreamcat4/docker-images/blob/master/pipework/2.%20Usage.md#run-modes
* tvheadend: (not published yet)
dockerfile: tvheadend
run:
cmd: --satip_xml
http://192.168.1.22:8080/desc.xml --bindaddr 192.168.2.2
Now we could do what John suggests, and try to modify all those images
to use -e ENV vars instead. But overall (for the community) I believe
it is less work to try to implement the proposed feature once in s6
base image / derivatives thereof. Than to do it many times over on
many individual people's images. And then have the users of those
images have to learn to change the way then use them.
Also: you can't ever make a shell alias of `docker run -e arg1 -e arg2
image` which was something of John's proposed to "just switch
everything to using '-e' ENV solution". So that buggers that up too.
So Gorka (sorry for getting your name wrong earlier!). Would you
consider pull requests on your base image for such feature? I mean,
providing if we can find a way to make it work that is feasible, and
doesn't upset other workings?
Many thanks.
>
>>
>> > >>
>> > >> https://github.com/glerchundi/container-base/blob/master/rootfs/etc/s6/.s6-svscan/finish#L23-L31
>> >
>> > That is awesome ^^. Like the White Whale of moby dick. It really felt
>> > good to see this here in your base image. Really appreciate that.
>
>
> With some changes to fit my docker base image needs but that was taken from
> Laurent examples in the s6 tarball, so thanks Laurent :-)
>
>>
>> > Nope. At least for the initial guildelines I gave - the container has
>> > only 1 supervised process (not 2). As per the official docker
>> > guidelines. Having a 2nd or 3rd etc supervised process means optional
>> > behaviour...
>> >
>> So this is something I actually disagree with - it seems like
>> everybody gets hung up on how many processes the container is running.
>> Like I mentioned in a previous email, people start talking about "the
>> Docker way" means "one container, one process."
>>
>> I think the correct approach is one *task* per container. The
>> container should do one thing - serve web pages, be a chat service,
>> run a webapp, and so on. Who cares if you need one process or many
>> processes to get the task done?
>>
>> A pretty good example is running something like GitLab. You wind up
>> running a web server and an SSH daemon in the same container, but
>> they form a single, logical service.
>>
>> To clarify, I'm against running ssh as a "let the user log in and poke
>> around" service like Phusion does. But in GitLab, it makes sense - the
>> users add their SSH keys via the web interface, and only use it for
>> cloning/pushing/pulling/etc, not interactively.
>>
>> There is a limit to what kinds of processes should be in a container.
>> Again, using GitLab - you need to run a MySQL or PostgreSQL database
>> for GitLab, but that's really a whole different task and should be in
>> a different container.
>>
>> I *do* agree with implementing optional features, though. In my
>> images, if you link a container to a logstash container, then the
>> logstash-forwarder will kick in and collect logs. If you don't, it
>> doesn't start the logstash-forwarder process.
>
>
> Totally agree. I'm with John.
>
> One docker container means one service, not one process. For example, php
> web server, which is composed by: nginx and php-fpm.
>
> This is a great discussion!
Received on Thu Feb 26 2015 - 12:00:38 UTC