docker: update to to debian-based container

Closes #410 (closed)

changed the description

added 1 commit

• 6fab3091 - fixup! Dockerfile: update image

Compare with previous version

marked as a Work In Progress from 6fab3091

added 4 commits

• 3d6eeb3e - Dockerfile: update image
• 208f1a41 - doc: remove bootstrap-depends.sh example
• f07e4ae5 - gitlabci: test container build in CI
• 13a0ec24 - README: update docker command to expose ports

Compare with previous version

unmarked as a Work In Progress

mentioned in merge request !696 (merged)

added 2 commits

• 379b5722 - gitlabci: test container in CI
• c002e642 - README: update docker command to expose ports

Compare with previous version

added 18 commits

• c002e642...fef3868e - 13 commits from branch master
• 364b05c6 - Dockerfile: update image
• 3d1bf637 - doc: remove bootstrap-depends.sh example
• 8e20104a - gitlabci: test container in CI
• ffceffe8 - README: update docker command to expose ports
• a238b00c - fixup! Dockerfile: update image

Compare with previous version

marked as a Work In Progress from a238b00c

added 1 commit

• 1dd404f4 - fixup! Dockerfile: update image

Compare with previous version

@tkrizek: running without trust anchors wasn't intentional, right? (see fixup!)

I tested it does validate now, and overall the MR looks good to me. @tkrizek: let me know if you think the fixup! commit is OK.

My initial intent was to use trust_anchors.file = '/etc/knot-resolver/root.keys' in config, but I've forgot to add that :) It's sort of anti-debian way, but I think it might be more suitable for the container, so it's easier for people to turn off DNSSEC validation, if they want to play with that for some reason.

added 4 commits

• acd7ffec - Dockerfile: update image
• fa28e001 - doc: remove bootstrap-depends.sh example
• 3f0f20e5 - gitlabci: test container in CI
• b9f8fa1d - README: update docker command to expose ports

Compare with previous version

unmarked as a Work In Progress

merged

mentioned in commit f68ca757

Hi

This PR introduced some serious regressions.

The change from CMD ["/usr/local/sbin/kresd", "-c", "/data/config.docker"] to CMD ["/usr/local/sbin/kresd", "-c", "/etc/knot-resolver/kresd.conf"] breaks existing configurations (mounting a custom config.docker). This has not been announced.

The switch from Alpine to Debian is actually a regression too, since Debian has a slightly bigger footprint (according to https://hub.docker.com/r/cznic/knot-resolver/tags it's three times bigger). It also breaks custom modifications (images using FROM cznic/knot-resolver).

And last but not least, the Debian image supports less hardware architectures than the Alpine variant.

Why do you not support multiple variants (Alpine and Debian) like other images do?

I'd love to see you supporting Docker best practices and the official image library. Please consider adding it.

@sedi

Hi. Changing the path to the config file was indeed a breaking change, and perhaps that could've been communicated better, sorry for the inconvenience.

Switching from Alpine to Debian,however, was intentional. It was a decision we made to reduce the maintenance cost, which is much greater concern than a 31 MB image size instead of 10 MB one. Alpine container will not be supported.

Are there any specific best practices you're hinting at? Please feel free to open a merge request if you have a specific suggestion.

@tkrizek what exactly are the additional maintenance costs on Alpine compared with Debian?

Quoting from best practices:

We recommend the Alpine image as it is tightly controlled and small in size (currently under 5 MB), while still being a full Linux distribution.

Some other points:

• MAINTAINER is deprecated in favor of LABEL
• Use a ENTRYPOINT for the main command, allow to pass other commands/flags/run as custom user (see recomandation)
• CMD should be the last instruction
• Multistage builds are not supported in the official library (https://github.com/docker-library/official-images/issues/3383)
• Support multiple architectures (https://github.com/docker-library/official-images#multiple-architectures)
• imgaes in the official library are constantly scanned for vulnerable libraries and rebuilt if necessary (maintenance is automated)
• some upstream version updates are also automated

A merge request would revert most changes here, so I assume that this won't be accepted. For the official library, you need to be associated with the project to request inclusion. So this can't be done by the community.