Docker Entrypoint

May 3, 2017
docker engineering development

This is a companion post to Kubernetes Pods Lifecyle

As you should know, Docker runs the entrypoint for your container as PID 1 this means a lot of different things, one of which is explained in detail here and here

It’s important to know that the Kernel treats PID 1 in a special way, normally when you send SIGTERM to a process and your application does not have registered a handler for SIGTERM the kernel will fall back to default behavior (killing the process) however, if your application happens to be PID 1 the kernel won’t fallback to default behavior and sending SIGTERM would mean nothing at all.

For this reason is very useful to use some kind of init system, luckily for us the great Engineer at Yelp! have a project i used a lot called dumb-init this is part of my base docker image and becomes the entry point for my dockerfiles

FROM lacion/docker-alpine:latest

ARG GIT_COMMIT
ARG VERSION
LABEL REPO="https://github.com/lacion/foo"
LABEL GIT_COMMIT=$GIT_COMMIT
LABEL VERSION=$VERSION

# Because of https://github.com/docker/docker/issues/14914
ENV PATH=$PATH:/opt/foo/bin

WORKDIR /opt/foo/bin

COPY bin/foo /opt/foo/bin/
RUN chmod +x /opt/foo/bin/foo

ENTRYPOINT ["/usr/bin/dumb-init", "--"]
CMD ["/opt/foo/bin/foo"]

one super useful feature of dumb-init is the ability to rewrite signals --rewrite 15:3 rewriting SIGTERM (number 15) to SIGQUIT (number 3) for example this is useful in the case of nginx where if you’re running in lets say Kubernetes means the scheduler will send a default SIGTERM signal but internally we will send the process SIGQUIT effectively doing a graceful shutdown.

all of this setup is super important when managing your Kubernetes pods lifecycles as making sure your applications are terminating in a way you need is crucial for running scalable docker containers.

comments powered by Disqus