Add Dockerfile

[s-ol]

there is a couple of community-maintained dockerfiles and images out there, but they all seem to be terribly outdated. I managed to put this one together finally; it is based on alpine linux, which makes it very tiny.

[s-ol]

Hm, maybe it is missing python-ctags3 though. That is not in the apk repos, maybe it could be installed via pip?

[jonashaag]

Thanks for the PR! Quick questions because I'm not too familiar with Alpine.

Why do we need testing repos?

Why do we need to specify all dependencies?

You can install python-ctags3 via pip.

Edit: We should probably use Docker tags that point to exact klaus pip version requirement and have latest point to latest klaus tag.

[s-ol]

@jonashaag

Why do we need testing repos?

Some of the dependencies are only in testing (as of yet), this may change in the future

Why do we need to specify all dependencies?

I put all the direct dependencies in so they can be installed with the system package manager. Most of the dependencies (or their dependencies recursively) require a full compiler toolchain and some libraries to be built from source (with pip) and this blows up the image size and/or build time. Right now the image builds in <15s for me.

You can install python-ctags3 via pip.

I will give it a shot!

[jonashaag]

Sorry second question was not clear; does Alpine not have dependency resolution? For example jinja2 should be a dependency of Flask.

[s-ol]

Sorry second question was not clear; does Alpine not have dependency resolution? For example jinja2 should be a dependency of Flask.

ah! it does, I took the dependencies from setup.py and loosely cross-referenced that with another Dockerfile. I can double-check and remove redundant packages.

[s-ol]

Added a build argument that can be used to control the version of klaus that is installed. You can use it like this:

$ docker build -t jonashaag/klaus . # build klaus:latest
$ docker build -t jonashaag/klaus:1.0.0 . --build-arg KLAUS_VERSION=1.0.0

I also moved python-ctags3 into it's own build step, so that all the devel dependencies can be removed in the same layer. This way they stay out of the image size as well.
The image is now 6MB of alpine base, ~90MB of dependencies and the 220kB of klaus. Pretty neat :)

EDIT: for reference, without removing python3-dev, gcc and musl-dev, the image becomes 150MB bigger. Glad I made that change.

[jonashaag]

Very very nice!

Two things I’m wondering:

Does the cleanup also remove all the dependencies (like GCC dependencies)?

What’s the best practice regarding CMD and ENDPOINT?

[s-ol]

Does the cleanup also remove all the dependencies (like GCC dependencies)?

according to the alpine docs it should, and looking into the image the only wasted files added in that layer are pip cache files. That layer is 771kB in total.

What’s the best practice regarding CMD and ENDPOINT?

both of these can be overriden by users if they want to, the main difference is that CMD is even easier to override, e.g. with docker run jonashaag/klaus .... the ... will replace CMD if anything is added.
I divided it like this so that the wsgi script to run is easiest to change. It also means that you can easily build your own variant on top of this image by adding a start file and running your container with --wsgi-file ....py.

[jonashaag]

Thank you!

This is very very nice.

Will merge now. Maybe we can even suggest this as the main way to run klaus in the README.

[jonashaag]

Do you also happen to know about automatic image building when a release is tagged and pushing it to a Docker registry? Otherwise I’ll look into that.

[s-ol]

I just pushed a change that disables pip caching, but it only removes 70kB. You can force-pull that in if you want, or let it be.

docker hub offers that as a free service for public repositories iirc. When you set up the repository there you can link it to the github repo, and it will build on pushes for master by default, and you can set it to build on tag pushes as well. However I don't see a way to make it put the tag into the build arg...

[s-ol]

Ah, apparently that's possible by adding more configuration to the repo: https://docs.docker.com/docker-hub/builds/advanced/

At that point the process is more or less equivalent to setting up a simple bash script that runs docker build && docker push on any other CI provider (travis, jenkins, circle). I find the dockerhub-github OAuth permissions a bit extreme personally.

[jonashaag]

I've changed Docker image to use the klaus script (easier for new users). Image still contains uwsgi so it's also a good basis for production deployment.

Also added Travis auto builds!