Docker.github.io: Need documentation on new docker-compose feature "init"

[jamshid]

The releases page on github mentions the "init" feature of docker-compose 1.13 but the docs are not up yet and I can't find any mention in blogs. When documenting please mention whether it works with swarm (docker stack deploy -c docker-compose.yml).
File: compose/compose-file/compose-versioning.md, CC @londoncalling

[londoncalling]

@jamshid , --init is documented for Compose v.2.2 here, but the reason it is _not_ documented in the Compose v.3 file reference is that --init _does not yet work with_ docker stack deploy and swarm services.

Closing this issue, as currently no updates to docs are needed. Feel free to use this thread for follow-up questions if needed, though. Hope this helps.

cc @shin-

[batjko]

It also does not work without swarm.
If I just run docker-compose up, I get the "Unsupported config option" error for all my mentions of init.

And I'm using compose file version 3.1.

[kleijnweb]

I now have to fall back to using manual docker run invocations when I need zombie reaping, which is, to put it mildly, a PITA.

[thaJeztah]

it's being worked on, and will come in a future release.

As an alternative, set the --init daemon option (or {"init":true} in your daemon.json), to enable the option by default.

Note that reaping child processes should already be handled by any proper process; if not, it may be worth looking into the process you're running in your container.

[kleijnweb]

@thaJeztah : thanks for the daemon option tip, I will try that. In another setting I do not have access to the daemon settings / invocation though.

I agree in an ideal world processes would manage their children properly but the reality is a little less ideal.

[thaJeztah]

I agree in an ideal world processes would manage their children properly but the reality is a little less ideal.

Yes, unfortunately, there are still examples that don't behave well. If you know of specific cases where it _is_ needed, and you don't control the image, the --init option is indeed good. Unfortunately, some people lead to believe it's needed in _every_ container, resulting in full-fledged init systems (upstart, systemd) to be added to each container, which, well, isn't ideal 😅.

In another setting I do not have access to the daemon settings / invocation though.

A good approach for that (assuming you have control over the images you deploy), is to make sure that images that _don't_ behave well have an init added; the --init option basically just mounts the tini init to the container, and sets it as entrypoint. While the --init option is not yet supported for services, you can add the tini binary to your images (see the README for tini).

If you want to track progress on having this feature added to docker service and docker stack deploy; The SwarmKit side of things was implemented in https://github.com/docker/swarmkit/pull/2350, unfortunately had to be reverted in https://github.com/docker/swarmkit/pull/2383, but re-implemented in https://github.com/docker/swarmkit/pull/2386.

That code didn't find its way yet into the daemon, but will probably get merged soon (through https://github.com/moby/moby/pull/35326).

After that's done; an update to the API will be needed (in the https://github.com/moby/moby repository), and after that's implemented, an update to the CLI to use this API option (work in progress PR here: https://github.com/docker/cli/pull/479), and a pull request to update the docker-compose specs, and parser in the CLI (Support in the Docker Compose 3.x format is being tracked through https://github.com/docker/cli/issues/51).

So, yes, work is in progress, but it takes some time to get all the bits in place :sweat_smile:

[thaJeztah]

compose v3 support for init in stacks was merged in https://github.com/docker/cli/pull/1129

[FranklinYu]

Unfortunately, some people lead to believe it's needed in every container

@thaJeztah Not just some people, this even applies for the official Node.js image. Due to nodejs/docker-node#848 I have to either add --init to all my Node.js containers (what you're against), or change entrypoint in all my Node.js Dockerfile (not DRY at all). No wonder users think that --init should be default.

[k8-scalar]

@franklinyu I think @thaJeztah meant that it is not good practice if people copy an entire service init system like upstart in their container images. Moreover, the --init option is only needed when container applications fork child processes but don't reap child processes. A common case is Jenkins and probably Node.js as well.

[FranklinYu]

Moreover, the --init option is only needed when container applications fork child processes but don't reap child processes.

@k8-scalar In the Node.js case it is not about child processes, but Node.js doesn't handle SIGINT. I know it's not good practice so I myself won't use --init everywhere; I'm just pointing out why others use it (the "some people" from quote). I understand them because I know "copy an entire service init system like upstart in their container images" is still easier than finding out which one does not work without --init, especially when even some official guys don't care about it.