Use alpine for docker image base & pre-install bind-utils for debugging failures

[karlkfi]

@lloesche What do you think about this? It includes a bunch of tools to make debugging easier (nsupdate, nslookup, host, dig, delv).

[karlkfi]

I'm not sure what side-effects this has, with musl instead of glibc. Tho since it's statically compiled I'm hoping it doesn't interact.

Another benefit of using alpine (more than just having bind-utils) is that having a package manager allows for installing new packages for debugging other production failures.

[lloesche]

This tarball would need to be adjusted then as well. Otherwise it will overwrite files like

/etc/group
/etc/hostname
/etc/hosts
/etc/nsswitch.conf
/etc/passwd
/etc/resolv.conf
/lib64/ld-linux-x86-64.so.2
/lib64/libc.so.6
/lib64/libnss_compat.so.2
/lib64/libnss_dns.so.2
/lib64/libnss_files.so.2
/lib64/libpthread.so.0

which I add to the rootfs tarball that's being generated by the docker-rootfs target. The assembly of the tarball is done in common/Makefile.

[karlkfi]

So worst case, the alpine install is kinda borked and the bind utils don't work as expected, but mesos-dns works fine because the tarball brings all its dependencies?

[lloesche]

Maybe it would make sense to build mesos-dns inside an alpine container then as well? Like, build it in a alpine 'junk' container like I'm using for the other build targets and then add the resulting binary to a clean alpine based image using a COPY. That way the number of layers stays minimal resulting in a smaller image transfer.

Easiest way I see to do that would be to change docker-rootfs/Dockerfile to be FROM alpine, adjust the RUN and COPY commands and the tarball assembly in common/Makefile for the docker-rootfs target.

[karlkfi]

That's definitely an option. I have no idea what side-effects there would be using musl tho.

[lloesche]

Me neither, I've never worked with Alpine. My standard Docker containers are either FROM scratch or centos:7 😄