Adds a multi-stage Dockerized build-from-source of mcPortKnock.

docker build -t localbuild/mc-port-knock .
docker run -it --rm -v $(pwd)/config.json:/config.json localbuild/mc-port-knock

This provides an amd64 arch statically-linked binary. I tested and you can run this from a scratch image if desired (you need to run as root or copy a passwd file over in that case). By-default this build goes-on to add mcPortKnock to a debian:11-slim image (BASE is configurable build-arg).

Other than the built binary, the final image on its own isn't super valuable, as there's no local MC server installed and possibly not the commands to operate on a remote one, but this image could serve as a base. With a little more work (mostly around environment-as-config) this makes a mcPortKnock image that can be hosted in a container environment - this can also be done as-is with a volume-mount for config.json.

Currently mcPortKnock implements a:

• monitor (real mc server is running, detect idle and run stopCommand) ->
• listen/be-fake-mc-server (port knock listener and run startCommand on client join-server knock) ->
• monitor etc.

... loop. This is ideal when mcPortKnock runs on the same server as Minecraft and would typically listen on the same TCP port, so both mcPortKnock and Minecraft can't listen simultaneously.

mcPortKnock can actually work quite well already in a different scenario, where it runs on a different server to the Minecraft server it monitors. In this case, mcPortKnock can run on a tiny server with startCommand and stopCommand controlling a remote mc server running on bigger hardware, which can then be completely shutdown when idle, since it isn't hosting mcPortKnock.

In this scenario, an enhancement would be for mcPortKnock to always-listen e.g. 25565/tcp, since it won't ever have to yield that port for a local real mc server. Additionally, it can always-monitor, allowing it to stopCommand the mc server when it is idle, even when it is in "listen" mode, where currently I don't expect it would be monitoring mc or expect it to be running.

If implemented, this enhancement could improve tiny/off-mc-host mcPortKnock to improve responsiveness and avoid any out-of-sync states where mc is not shutdown when idle.

Networking for above usage: there are a number of great ways to incorporate mcPortKnock as a port-knock with mc-direct when running - I've used DNS with health-checks and failover rules, but other DNS and load-balancing options also work.

Thanks for the nifty utility and project.