Docker and its implementation.

[JeremiahSecrist]

This pull request...

• Introduces a new feature
• Fixes a bug
• Improves an existing feature
• Boosts code quality or performance

Description

In This pull request it is meant to add an easy implementation of docker to this project. More changes can be added as needed to suite the music bot at hand.

Purpose

As I have seen quite a few custom images made on docker hub I thought I could make a solution for future people that use docker and come across this awesome project. Docker has a lot OS useful features ad can reduce issues caused by running something on a host machine that has lots of configuration changes.

Related PR

Add docker support #349
While similar In nature the difference with this one is intended to be easily maintained by yourself without changing your work flow at all minus editing two files as I don't know your docker account info and other things will most likely need to be worked out.

Related Documentation

videos

https://www.youtube.com/watch?v=SzzwFauxK98
https://www.youtube.com/watch?v=Qw9zlE3t8Ko

links

https://docs.docker.com/docker-hub/builds/
https://docs.docker.com/compose/

---

Thanks for looking over this and I look forward to working things out with you to get this support up and running. I rather enjoy this bot and thought I could contribute something useful.

[jagrosh]

Correct me if I'm wrong, but this appears to have the version hard-coded. Ideally, the docker container would always check for the newest version and download it if applicable.

[JeremiahSecrist]

The reason its hard coded is due to the fact docker can store older images with tags so people can set it to auto update or stay on a version for whatever reason. I can add a script you run that changes the version information before / after you launch the next release. I am thinking I can make the same image do both if version is set to 0 it will pull the latest. If it is set to anything else it will pull that specific version. That way you can push all the older version. I have a few more adjustments to make for that but it wont take long when I get home.

[jagrosh]

Whenever I do a release, all of the previous releases are deprecated. I feel like the simplest way to handle a docker image would be to just have one image that will always check for, download (if necessary), and run the latest release. Having an optional flag to choose a specific release would be fine, but the default should request the latest.

[jagrosh]

I'd imagine that it would be implemented similarly to how the bot itself checks for new updates, by checking the version available from github's json: https://github.com/gitapi/repos/jagrosh/MusicBot/releases/latest

[JeremiahSecrist]

Absolutely. There is a thing called latest tag that can point to another built image ( latest supported ) the other images are there ( tagged with versions ) this way the older images stay up on docker hub but the latest and only supported one is linked. Also would you like this to be on its own branch? So you can keep it off your original code base?

[jagrosh]

Maybe I'm misunderstanding, but I would imagine there only needs to be one docker image; one that always downloads and uses whatever the latest jmusicbot release is when you run it.

[Sanduhr32]

I have the same understanding as jag.
I believe that the enviro of variable is a good way for storing the version, the tag_name seems like the best data available by the API.

The docker container should keep the bot updated, because that's what docker kinda is for, automated modular processes IMHO.

[JeremiahSecrist]

Okay let me try and explain tags can be used just like releases on github.

1. They snapshot the current configuration of your code and how to implement it onto a platform
2. They are mostly immutable and updates happen by pulling new images.
3. Just like on github you don't delete your old releases you don't delete old images on docker hub.

If needed I'll make step by step instructions on how to link docker and automate the building of the new docker image when a release happens. and it will use the jar from releases.

On docker you can tag your releases with many tags. so your Jagrosh/musicbot:latest image for example can be remapped / point to what ever release is the latest. In our case 0.3.1 the point of having the older tags / images is so when you update you have older releases to roll back on. this remapping of the latest tag can be Totally automatic
I will be making it so by default the image builds the latest version for automation reasons. I will add a simple manual method to push older versions up to docker in case a reason ever happens to revert.

Thanks for your time!
One other thing while I am here. what version of jre / jdk do you want this image to always ship with?

[JeremiahSecrist]

I guess I could clarify docker already has features for auto updates to images. Building a single image once that only runs the most up to date version of your project could cause issues for others using it and breaks the workflow of docker. This Image I setup can be configured to compile the new image version task and change the latest tag. with the correct tag through docker hub without any future interference. And it will use the current supported version. While not breaking older images.

[Sanduhr32]

What version of jre / jdk do you want this image to always ship with?

At least Java 8, but the vendor shouldn't be OpenJDK or AdoptJDK because both have flawed builds (Java 11 & 13 afaik) where SSL certificates don't work by default without additional work.

Building a single image once that only runs the most up to date version of your project could cause issues for others using it and breaks the workflow of docker.

I don't know anything that would and should depend on JMusicBot so i'ld expect it to be the last thing that depends on something.

[JeremiahSecrist]

I don't know anything that would and should depend on JMusicBot so i'ld expect it to be the last thing that depends on something.

With this i am more referring to if the project down the road decides to change something in configuration that makes their current set up non functional. Having the older images lets people update at whatever time is best for them and allows for version testing and so on. Plus having these extra images on docker hub is at no cost to you And will build automatically from the latest released jar. I'll add in the readme's the only actively supported image is :latest.

flawed builds (Java 11 & 13 afaik)

Then I'll lock it in at version 10! ;) jokes aside I can set it up to not use openjdk it will take a bit though. I will polish everything else up before that.

progress

The simple script so you can push versions manually if you want is almost done. The image now auto builds the latest by default unless specified otherwise ( latest at time of build ) some areas have been made more descriptive.

Todo

• Switch off openjdk if needed
• Show how to enable autobuilds on docker hub

[JeremiahSecrist]

Also would you be willing to tell me your docker hub account name so I can change pending names? I am assuming it would be jagrosh but you never know.

[JeremiahSecrist]

While its on my mind. Are these jar files GPG signed? I can add that into the build script so the image is not interfered with during builds.

[JeremiahSecrist]

Hey, It's been a while life got out of hand with covid amongst many other things. All that aside Ive finally gotten back to this project and modified it according to what you mentioned. the image is pretty much self maintaining now and will auto update on reboot. The only thing needed to apply the update is to restart the docker image. If you decided to start supporting pgp I can add verification methods into the project.
Thanks for your time!