First shot at Dockerizing + getMacLinux() function fixes

[trinitronx]

Changes:

• Created Dockerfile to install & get debian:stretch SystemD-based docker container with Minera up and running, found and fixed the following issue:
• Fixed getMacLinux() function to always return first thing that looks like a MAC address from netstat -ie output. (Some Unix* flavors do not always have HWAddr or ether in front, so pattern matching works best).
• Detect if running inside docker via the container=docker environment variable (must be set for SystemD to work inside Docker)
• Use an external linked container named 'redis' (for future Redis cluster scalability & ability to start / stop the Minera container independently while leaving up redis container to save Redis data)

If you appreciate the work, I do accept tips:

[michelem09]

Thanks man! Really appreciate, I hope to test it quickly to release with the next Minera version.

[trinitronx]

Probably easiest way to test:

• Linux:
  • Install Docker for the docker Container Engine Daemon and CLI docker command to interact with the daemon.
  • Run ./docker/build.sh && ./docker/run.sh
  • Access via your Linux Docker Host's IP & port 80 or 443: http://192.168.x.x/minera
• Mac / Windows (Install docker-machine + VirtualBox to run a Docker VM with):
  • Install VirtualBox
  • Mac (Install via .dmg or via brew-cask: brew cask install virtualbox)
  • Windows
  • Install [Docker Engine][docker-engine] for the docker CLI (to interact with Docker Daemon inside VM)
  • Mac (Install via link instructions or via homebrew: brew install docker)
  • Windows
  • Install Docker Machine (for creating a minimal Tiny Core Linux VM running Docker daemon)
  • docker-machine create --driver virtualbox dm
  • eval $(docker-machine env dm)
  • Run ./docker/build.sh && ./docker/run.sh
  • Access via your Docker Machine VM's Docker Host IP on port 80 or 443:
  • curl -vL http://$(docker-machine ip dm)/minera

EDIT: Instead of doing the build yourself, you may opt to just run the docker/run.sh script once you have a Docker Host up and running. I've already built an image for testing and pushed to Docker Hub @ trinitronx/minera:latest. Note that I've separated out the Redis dependency so it can be run in it's own container, and am using the official redis image.

[trinitronx]

Note: I think I hardcoded my Docker Hub repo name in the docker/build.sh and docker/run.sh scripts... but that can be changed... I must've missed that last night trying to go fast. Anyway.. the image is pushed already so you can pull if you don't wish to build yourself. It was built off of the tip of this PR branch: trinitronx/minera:v0.7.1-pre-35150a9 == trinitronx/minera:latest.

[alberttwong]

It seems like it got merged but I don't see a dockerfile in the current master branch.

[alberttwong]

I tried the image in docker hub. Didn't work for me.

ovpn-117-51:sandbox alwong$ docker run -t -i --privileged trinitronx/minera
mount: /sys/fs/cgroup is busy
Failed to insert module 'autofs4': No such file or directory
systemd 230 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN)
Detected virtualization docker.
Detected architecture x86-64.

Welcome to Debian GNU/Linux stretch/sid!

Set hostname to <b2308a939c50>.
Cannot determine cgroup we are running in: No medium found
Failed to allocate manager object: No medium found
[!!!!!!] Failed to allocate manager object, freezing.
Freezing execution.

[michelem09]

Don't know it was made by @trinitronx I just merged it in the master branch.

[trinitronx]

@alberttwong : Sorry about the lack of documentation, I realized that this particular container needs a bit of extra options in order to start.

Because it uses SystemD inside the container, you need to run it with a couple options:

• -v /sys/fs/cgroup:/sys/fs/cgroup - to pass in the host kernel's cgroup hierarchy (SystemD is throwing an error about this in your comment's log). It needs at least readonly access, so you may opt to use -v /sys/fs/cgroup:/sys/fs/cgroup:ro to limit the container's permissions.
• -v /var/run/dbus:/var/run/dbus - in order to start services that require DBus (Ubuntu has some of these), you need to pass in the host's DBus daemon socket. You may be able to get by with running minera without this, but if you expect all the stock Debian services to function, you might need it. Default is: /var/run/dbus/system_bus_socket
• -e 'container=docker' - A bit peculiar, but apparently in some versions of SystemD, this environment variable tells it that it is running inside a container so it can handle starting in this special case.
• --privileged - Initially, I did not have time to track down exactly what permissions or kernel capabilities SystemD needed. Because it's an init system, it presumes that it's pid 1 on the system and enjoys full access to system level resources. Later, it was reported that it can be run in a less privileged mode with --cap-add=SYS_ADMIN, but I did not test this thoroughly with this container. This may depend on the version of SystemD running inside the container also, as the user reporting this finding was running CentOS 7. This container is based on Debian. This just scratches the surface of the issues with running SystemD inside a container, so depending on the particular OS you're using, your mileage may vary. However for a multi service container use case like minera (node.js minera service + lighttpd), it works and should avoid any issues with zombie processes for daemons that were not designed to handle them.

I put a comment on the appropriate docker issue #7459 detailing my testing & findings on how to get SystemD working inside a docker container.

So to start this, you need to do something like this:

docker run -t -i --privileged -v /sys/fs/cgroup:/sys/fs/cgroup -v /var/run/dbus:/var/run/dbus -e 'container=docker' trinitronx/minera

Note that you may also opt to avoid the -ti options for interactive mode, and just pass in -d instead to run it in daemon mode.

You may also wish to check out the run script I added to this repo under minera/docker/run.sh.