Use tini in Docker images.

[mccheah]

Closes #317.

[ash211]

LGTM -- @foxish did you have any questions about this since you were asking about it during the weekly video call today?

[foxish]

@tnachen PTAL

[erikerlandson]

Is there a reason it's using tini as an entrypoint in some, but exec /sbin/tini ... in others?

[mccheah]

The exec ones have to do more complex bash environment variable substitution at execution time, so those more comfortably fit in the exec form of the Docker command. It would be good to unify these, but for another time.

[erikerlandson]

This is a bit tangential and not a bug, but multiple RUN statements can be combined to reduce the number of image layers:

RUN apk upgrade --update
RUN apk add --update bash tini
RUN mkdir -p /opt/spark
RUN touch /opt/spark/RELEASE

Can be combined like:

RUN apk upgrade --update && \
    apk add --update bash tini && \
    mkdir -p /opt/spark && \
    touch /opt/spark/RELEASE

[ash211]

@erikerlandson what are the advantages to having fewer image layers?

[tnachen]

LGTM, but I also suggest having few layers. It's generally a best practice to have fewer layers, as the more layers you have the more work registry/daemon/client will have to do to download and manage.
Also depending on the filesystem you end up using with Docker, fewer layers could also help performance as some filesystems requires copying and traversing layers on writes/reads.

[erikerlandson]

Another potential benefit to consolidated RUN is you can do file cleanup in the same layer, which is another way to decrease image size. This post describes some examples:

https://blog.codeship.com/reduce-docker-image-size/

I don't quite follow the exec distinction, but I have no doubt it solves the pid problem either way.

[ash211]

Let's squash those layers in a separate PR -- it definitely sounds like a good idea and I don't see a downside to it.

#323