[NEW FEATURE] Publish as Docker image

[Dominik Nakamura]

Is your feature request related to a problem? Please describe.

Would be great to have this tool published as a Docker image on the main Docker registry, and maybe ghcr.io and quay.io as well. This would allow running it anywhere where Docker is installed, without having to install any additional machinery.

Describe the solution you'd like

Having automated builds and publishing to popular Docker image registries.

Describe alternatives you've considered

None really 🤷

Additional context

Currently using another popular Docker container dashboard called ctop, and find oxker much nicer actually. Just would love to have it available as image so I could run it as follows:

docker run --rm -it --volume /var/run/docker.sock:/var/run/docker.sock:ro ghcr.io/mrjackwills/oxker:latest

[Jack Wills]

This sounds interesting, I have set up a dockerhub account, but have never published to it before.

How would you envision the docker container being created? And how could I test that on my home computer.

Even though oxker is based around Docker environments, I am clearly lacking some knowledge regarding it all.

EDIT: Ok, so I have a basic version running, but I am running into an error, in that when oxker shows the logs for the oxker container (as in itself), I get an out of bounds error regarding a &str. My guess is that the tui terminal characters are playing havoc with the text formatter that oxker is using.

So, will need more time to look at it, or work out how to disable logging for a single container. Or if oxker finds a container called "oxker" it ignores it - but I can imagine all manner of trouble if such a basic, and dirty, method, was implemented.

I'll look at this week and see what I can come up with, will push a new branch, feat/docker, and then anyone can take a look at it.

EDIT 2 : yup, running with docker run --rm ---log-driver none ... seems to solve the issue, maybe that's the simplest solution?

[Dominik Nakamura]

Thanks for looking into it so quickly 🚀

Not sure how (yet), but seems ctop is able to not show anything when viewing its own logs through their UI. Probably they do some heuristic detection for this as well (like checking that the image has a specific name or the ENTRYPOINT is a specific value).

I'll let you know once I find out how ctop does it, so maybe we can copy the method for oxker.

[Jack Wills]

I can exclude the oxker container from being listed, didn't realise that ctop did that, and in oxker would be easy enough to do, by just ignoring any container that uses ./oxker as a command (as in CMD ["./oxker"] or ENTRYPOINT ["./oxker"])

Next up, need to read up on how to create a multi-arch docker build.

Have made a feat/docker branch, with a working example, using a build step and then an alpine runtime step, means the images is only 9mb is size. However, when using alpine, I was unable to correctly get oxker to start, unless I sleep before hand, no idea why, if using a debian-slim container, the sleep is not needed, but the image size jumps up to 80mb.

EDIT: have published this first attempt, based on the feat/docker branch, to dockerhub, should be able to run with docker run --rm -it --volume /var/run/docker.sock:/var/run/docker.sock:ro mrjackwills/oxker:latest

[Dominik Nakamura]

Tried it out today and works like a charm! Thank you so much.

[Jack Wills]

Sounds good, have created a github action to build a multi arch build on each release, so should all be kept up to date without having to think about it now.

I'll close this issue once the next release comes out, and hopefully the Docker Hub image will be updated automatically.

[Jack Wills]

build for v0.1.5 correctly updated the dockerhub image, so closing now, thanks