Add a Dockerfile that supports buildx for amd64/arm64

[TrueBrain]

Not sure if you are interested in this, so feel absolutely free to close this PR.

I was trying to build arm64 Docker images via buildx, as I normally do. Sadly, because the Dockerfile has hardcoded references to x86_64, this failed.

So, I added some glue in the Dockerfile, allowing it to pick the right folders depending on the platform you are building for. I only added support for amd64 and arm64, as those are my target / and what I can test.
I put it in another Dockerfile, as the normal docker build doesn't understand this redirect via $TARGETARCH. They couldn't make this easy, ofc.

But, with that, buildx happily builds FlashMQ, and it even works on arm64 just fine :)

[halfgaar]

Thanks, I'll take a look. Contributions for Docker are certainly welcome. I spent a fair amount of time on getting packaging in order (not an easy task), but Docker I haven't done much on.

It'd be best if there was one Docker file, and depending how wide-spread buildx is (it's new to me), I may replace the original Dockerfile.

A little background on the architecture BTW: FlashMQ primarily targets x64 because it has SSE4.2 instructions for string handling, making it faster. There's a fallback for ARM builds, but it's good to be aware of somewhat reduced performance. ARM has various SSE/SIMD instructions, but not all.

[TrueBrain]

A little background on the architecture BTW: FlashMQ primarily targets x64 because it has SSE4.2 instructions for string handling, making it faster. There's a fallback for ARM builds, but it's good to be aware of somewhat reduced performance. ARM has various SSE/SIMD instructions, but not all.

Tnx for that background info; explains why I had to disable see4.2 from the main CMake-file before I could build it for arm64 ;) Builds otherwise fine without that statement btw.
Maybe funny for you to know: mostly why I picked FlashMQ is because of the websocket implementation. The others I tried had very shitty implementation, that failed in weird ways when put behind an (SSL) proxy :)

[halfgaar]

That's very interesting to know. Also note that it supports websocket TLS natively (no need for proxy, unless you want to of course).

Websockets remain hard to test thoroughly, because of the lack of clients out there (it's mostly PAHO), and some are buggy themselves. HiveMQ's client incorrectly assumes websocket frames align with MQTT frames for instance, something that should not be assumed, as mentioned explicitly in the specs.

Should you run into weird behavior, I'd even do an interactive debugging session.

BTW, I hope you have the newest version, because of this.