commercialhaskell / stack

The Haskell Tool Stack
http://haskellstack.org
BSD 3-Clause "New" or "Revised" License
3.98k stars 842 forks source link

Use a proper init for Docker images #2498

Open Blaisorblade opened 8 years ago

Blaisorblade commented 8 years ago

@borsboom wrote:

for the Docker case, maybe we should go back to having a separate 'init' process. We used to use phusion/baseimage's my_init in the containers but eliminated that for faster startup and compatibility with non-FP Complete-generated images. At that time we considered whether we should introduce our own extra 'init' process but decided to try without and see how it went.

I agree. IMHO Docker images should always use a proper init process. Even if you run GHC directly:

Minimal init binaries include dumb-init (used in the past by @snoyberg) and tini (used by me). I'll favor the smallest/most portable/possibly statically linked one.

2474 was about a container launched manually, but IIUC the issue is still there for Stack Docker containers (to verify).

borsboom commented 8 years ago

I'd like to avoid needing the Docker image to contain anything special (like dumb-init or tini), because that makes it harder to use arbitrary images (like the official Haskell images). Also, in my experience, those init processes tend to interfere with Stack's somewhat complex re-launching of itself in a container (although I haven't tried either dumb-init or tini).

Rather, stack can act as its own init process (basically detect that it's pid 1 in a container and if so fork itself and let the original process just reap zombies).

Blaisorblade commented 8 years ago

Rather, stack can act as its own init process (basically detect that it's pid 1 in a container and if so fork itself and let the original process just reap zombies).

Are you describing existing code or suggesting that somebody writes it?

borsboom commented 8 years ago

The code doesn't exist yet. It's what I was thinking of implementing.

Blaisorblade commented 8 years ago

Sounds doable though not immediate. tini is ~500 lines of subtle C (which might have more than we need) (https://github.com/krallin/tini/blob/master/src/tini.c); dumb-init is ~300 lines (https://github.com/Yelp/dumb-init/blob/master/dumb-init.c). At least if all libraries have wrappers (which sounds plausible).

My 2 cents: I'd say make it a lib (exposing initMain :: IO ()) that can be linked in stack and used externally (with main = initMain), so this can be leveraged elsewhere.