Test docker build job

[tokheim]

Signed-off-by: Asmund Tokheim tokheim@outlook.com

*Issue number of the reported bug or feature request: #56

Describe your changes
This introduces a root level dockerfile to build a docker image along with github actions to release the container. Just like the author of #56 I'd really need a docker image to be published in order to make use of this very promising project. The docker job is mostly based on the plain example in https://github.com/docker/metadata-action, and should push versioned images whenever you tag the repo. Still there's a lot of customization options you might want to do, so merely a suggestion from me.

Testing performed
I've tested the new dockerfile locally to be working. I also tested the github action on my branch, but haven't published any images, as that seemed like I was overstepping. You can see the result in https://github.com/tokheim/amqpprox/runs/4061595492

Additional context
Before merging you will need to change the image name, and add DOCKERHUB_USERNAME and DOCKERHUB_TOKEN secrets.

[adamncasey]

Thanks for the PR Asmund. I agree that having a published Docker image (or any kind of published, built, artifact is going to make it easier for people to use this project.

We never asked around internally about using Dockerhub but we'll do that now.

One unanswered question here is how the docker image would allow configuring of the amqpprox instance. Did you have any thoughts on how this would work for you?

[tokheim]

So I hope to experiment a bit on how we could make use of this. But we would likely want to run it in kubernetes and want some way to dynamically change config across all the amqpproxies.

What I'd hope would work is to run amqpprox in one container, and some project that controls the proxy through amqpprox_ctl in another container (sidecar pattern). The two containers would communicate by both mounting a shared volume like https://stackoverflow.com/questions/45637587/connection-between-docker-containers-via-unix-sockets. TCP sockets would be a more standard docker-pattern and allow a bit more flexibility in the setup, but I'm still hopeful this should work well. What do you think?

By the way, you shouldn't feel any obligation to make use of this PR, I just wanted to do whatever I could to speed up the resolution for #56