Ideas for shorter, quicker Dockerfile

[cuu508]

Hello,

I played around a bit with the Dockerfile at https://github.com/cuu508/docker-healthchecks and came up with a few semi-related improvement ideas. I'm not experienced with Docker stuff, and there may be good reasons why you've done things a certain way, but here goes...

• instead of gosu, use uwsgi --uid and --gid parameters to drop privileges
• don't install postgres, mysql libraries and uwsgi with pip. Install them with apt-get. This speeds things up as you don't need to install development libraries and compile. I changed the base image to ubuntu:yakkety to have recent versions
• use dumb-init as entrypoint so Ctrl+C works
• grab the project's source code with svn export instead of git clone, this exports a clean tree without the .git directory
• do manage.py collectstatic at build time not startup

[cuu508]

It would be good to get rid of the chown -R hc:hc /src line. All the files can be owned by root, but used by hc. This way the hc user cannot rewrite its own code. At runtime, the hc user should only need write access to the sqlite database file.

[so0k]

@cuu508 great web app & service!
@haswalt nice docker image

I agree the image can be optimised and I started off from python:3-alpine as I usually base off alpine. Moreover, I prefer to base off the official docker images to ensure:

• We base of an up to date Python image,
• We benefit from the automated CVE scanning on the docker hub, ....

I had already started by moving asset compilation out of the container boot-phase to the image build-phase as well... until I came across this thread started by @cuu508 and I've applied other changes suggested here as well.

I still believe it is best to start with official Python image, and preferably alpine based as this allows for optimal image size.

atm the alpine based image is about half the size of the current ubuntu-based image.

docker images | grep health
quay.io/honestbee/healthcheck   latest      013227dca503      10 minutes ago      159 MB
haswalt/docker-healthchecks     latest      2d9459e6554a      2 weeks ago         329 MB

I'm not sure if we need an init system as bash provides the exec built-in command to replace itself and do proper signal forwarding... (this by itself fixes the issue of the container not exiting on CTRL+C.

But if an init system is required because uwsgi may create zombie processes(?)... then I suggest we use krallin/tini as it is the same init system Docker integrated in 1.13.

I do not recommend running the send-alerts process within the same container, I suggest to split these off so process supervision is external to the container. (We use Kubernetes as a container orchestration system and I would gladly create a Helm chart to simplify the deployment of a multi container architecture).

Finally, why does the docker file have to live in a separate repository and can't it just be included in the main repo?

I've created a fork of the main repository and if you think it is a good idea, please add your comments on my PR

PS: At the moment all Docker images are based on Alpine 3.4, which does not have pre-compiled python packages - forcing me to do the compilation with pip install. another option is to base off alpine:3.5 and run

apk add --no-cache python3 \
  && python3 -m ensurepip \
  && rm -r /usr/lib/python*/ensurepip \
  && pip3 install --no-cache-dir --upgrade pip setuptools

as well as use the alpine py3-* packages (only available for alpine 3.5 and no mariadb packages).

[haswalt]

@so0k @cuu508 Thanks for your feedback.

I don't think running the send-alerts process inside the container is great however, this was created as a very small setup for minimal users to the send-alerts process never did much and I only ever had 1 of these containers running. Secondly it meant I could get everything running with a very minimal setup.

My thoughts would be adjust the entrypoint to allow a user to specify that the container should run that command rather than the main uwsgi process.

uwsgi does spawn zombies without cleaning up properly so something like tini would be ideal.

Originally I had the static content collection at boot time as I think I had some issues with the URL not being known at build. Might be wrong, was a while ago.

About the Dockerfile living in another repo, when I created this I didn't have weeks to wait for a response to a PR to get this ready for use so I simply did this quickly to get up and running.

Initially the pre-built python image didn't exist using alpine when I created this which is why I rolled my own since the "official" python was simply huge.

Finally, I don't use this image anymore so happy to accept PR's on these.

[haswalt]

@cuu508 couple of points to cover up your questions.

The reason for gosu is that if you need to run commands and interact with items inside the container thne I prefer it be run as a user not just as root.
yakkety isn't LTS so I don't use that for production servers
svn export involves installing the svn packages, it's simpler just to remove the .git folder. In an ideal world the docker file would be in the main repo as @so0k said and so .git would be in the .dockerignore file.