Add Alpine linux Dockerfile in addition to the existing Debian one

[ghost]

This PR replaces original Dockerfile with a re-worked version. New version builds a docker image based on Alpine Linux, which significantly reduces image size (to ~8.5MiB).

---

This change is 

[nurupo]

The image size reduction is good. I'm not familiar with Alpine Linux, so it might be harder for me to maintain the Dockerfile, but Alpine Linux looks simple enough and even has a web interface to look up packages, so I will give it a try.

I have only quickly glanced over the Dockerfile, still need to double-check it and test it, which I will do sometime this week.

[nurupo]

other/bootstrap_daemon/docker/Dockerfile, line 61 at r1 (raw file):

	sed -i 's/enable_lan_discovery = true/enable_lan_discovery = false/' /etc/tox-bootstrapd.conf && \
# Modify relay ports, 443/tcp is often already in use
	sed -i 's/tcp_relay_ports = \[443, 3389, 33445\]/tcp_relay_ports = \[8080, 33445\]/' /etc/tox-bootstrapd.conf && \

You shouldn't remove ports 443 and 3389, we want the bootstrap node to listen on them because these ports are often open in firewalls. In particular the firewalls a user is behind when trying to connect to your bootstrap node (e.g. university firewall), not the firewall that is on the machine running the bootstrap node.

---

Comments from Reviewable

[ghost]

@nurupo, I would agree on leaving 3389 enabled, but not about 443. From https://nodes.tox.chat/json we can see that there are only 2-3 hosts out of 72, who have 443 open and have Tox network node service running on it. Quick nmap shows that 32 hosts out of those 72 use port 443/tcp for https service.

[nurupo]

I think the port 443 should be used by default. Having a node running on port 443 is a big win for tox users, as they could connect to the tox network in a network with restrictive firewall. If you remove port 443 from the default configuration, how are the bootstrap node maintainers supposed to know that they should add it if they don't run a https service? But if they do run a https service, they would see during the daemon setup that the daemon uses port 443 and would remove it. Simply removing -p 443:443 from the docker run command should be sufficient to disable use of that port, I think (my Docker knowledge is somewhat limited).

[ghost]

OK, left with default ports.

[nurupo]

I'm having hard time finding documentation for adduser used in Alpine Linux. It doesn't seem to like any of long options.

[nurupo]

Thinking about it more, I'd like to keep the image use Debian. If you want smaller size, you can change it from debian:jessie to debian:jessie-slim, which should bring the size down from 120MiB to about 80MiB.

[ghost]

All up to you. Smaller image - smaller attack surface, smaller footprint, smaller downloads. Additional benefit - bootstrap daemon on Alpine is compiled and running with musl libc.

It doesn't seem to like any of long options.

Yes, only short options. It's BusyBox utils, not something unknown/third-party/specific: https://www.busybox.net/downloads/BusyBox.html#adduser

[iphydf]

Check the checkbox that allows collaborators to push to the PR branch. Also, rebase on master.

@nurupo can you provide a rationale for your preference?

[iphydf]

@romik-g can you rename your file to Dockerfile.alpine and keep the original one intact? That way, users can choose.

[iphydf]

Also, squash all the commits.

[nurupo]

Uh, I'm just reminding that I have said that I don't want replacing the Debian Jessie image with the Alpine one, e.g. I'm against this PR.

[CLAassistant]

All committers have signed the CLA.

[iphydf]

@nurupo we won't replace it, just add another Dockerfile.alpine with this one in it. @romik-g can you do that?

[ghost]

@iphydf tell me how to do that, please. Should I rename file in my repo and create another pull request to this one?

[robinlinden]

@romik-g I went ahead and did it for you.
@nurupo Can you have a look at the Dockerfile now that it isn't replacing the Debian one?

[nurupo]

@nurupo we won't replace it, just add another Dockerfile.alpine with this one in it.

So, who is going to maintain it? I'm committed to fixing the Debian Dockerfile if anything breaks in it, but if Alpine Dockerfile breaks it will either be left broken or will be deleted from the repository due to being broken.

[iphydf]

@nurupo it'll be left broken or deleted. If anyone cares about it, they will step up and fix it.

[iphydf]

I'll add a travis job for it to the nightly build later.

---

Review status: 0 of 1 files reviewed at latest revision, 1 unresolved discussion, some commit checks failed.

---

Comments from Reviewable