Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using the --init flag #81

Closed
andyneff opened this Issue Apr 3, 2017 · 3 comments

Comments

Projects
None yet
3 participants
@andyneff
Copy link

andyneff commented Apr 3, 2017

  1. Now that docker 1.13 has added a --init flag, is this a good way to use tini now?
  2. It looks like it will automatically add (tini version 0.13.0 - git.949e6fa) as /dev/init for you. Does this mean there is no need to download tini anymore?
  3. Which method do you suggest as the "preferred method"?
@crosbymichael

This comment has been minimized.

Copy link
Contributor

crosbymichael commented Apr 3, 2017

@andyneff yes, Docker ships with tini and Docker automatically inject it into your containers if you enable the feature with the --init flag.

I would have made it the default but for backwards compatibility we couldn't.

@andyneff

This comment has been minimized.

Copy link
Author

andyneff commented Apr 4, 2017

@crosbymichael Thanks for the reply.

Is the --init-path option supposed to go with this, so I could in theory use a different init binary?

For example, since tini 0.13.0 is the init shipped with docker today, and I say I add tini 0.10.0 and want to point to that? Because when I tried this today, that feature did not appear to work to change which version tini it ran. It was always 0.13.0 (I realize that if this is indeed a problem, it belongs on the docker issues, I'm just trying to understand how to use tini with all these new features :) )

FROM alpine
RUN apk add --update tini

and then docker run -it --rm --init --init-path=/sbin/tini my_image bash and it shows up to still run /dev/init which was still tini 0.13.0, intead of 0.10.0 I expected at /sbin/tini

@krallin

This comment has been minimized.

Copy link
Owner

krallin commented Apr 4, 2017

@andyneff One of the Docker folks (@crosbymichael or @tianon) would be able to confirm, but I believe the --init-path argument is here to select a path to the init binary on the "daemon-side", i.e. the path on your actual system and not the path in the container (I'm note sure what happens when that path doesn't exist, though).

Now, to answer your initial questions:

Now that docker 1.13 has added a --init flag, is this a good way to use tini now?

Yes, definitely!

It looks like it will automatically add (tini version 0.13.0 - git.949e6fa) as /dev/init for you. Does this mean there is no need to download tini anymore?

I think it depends on who's going to use your image.

If your image is meant to be used by other people (e.g. you push it to the Docker Hub, or expect people to clone your repo and build it, etc.), then you probably want to include Tini in your image and use it as the ENTRYPOINT, considering your image could be used by users that:

  • Are using an older version of Docker without support for running Tini via /dev/init.
  • Aren't passing the --init argument when running a container.

Tini can be chained with itself without any issue, so if you embed it and someone also uses the --init argument, you'll have two Tinis chained together, but nothing will break. However, one thing that might happen is you'll get a warning indicating that Tini isn't running as PID 1 (coming from the non-Docker-provided Tini). If this bothers you, can fix it by setting the TINI_VERBOSITY environment variable to 0, which will silence this warning (errors will still be reported, of course).

All that being said, if your image is something you're only using for yourself (or your organization), and you always run your containers on a recent version of Docker using the --init argument, then using the --init flag will make your life easier so take advantage of it! 😄

Which method do you suggest as the "preferred method"?

Should be answered above 😄

One caveat though: that's just my opinion; @crosbymichael, who worked on the feature on the Docker side, may have a better claim at providing the "preferred" method!

@andyneff andyneff closed this Apr 4, 2017

jakirkham referenced this issue in dask/dask-docker Dec 7, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.