[Feature Request] Consider offering an official Docker image

[alexandreteles]

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

Not directly linked to JMusicBot's code, no. Considering that there's a bunch of different Docker images available on DockerHub, the most popular of them having 50K downloads, but it being updated a year ago (!), having an official image for JMusicBot could provide a safer and up to date way for users to run the bot using Docker or Podman.

What is your ideal solution to the problem?

1. Select a good Java base image (ex.: eclipse-temurin:17-jre-focal);
2. Create a Dockerfile in this repository that catches the latest release and builds an image. Ex.:

FROM cycloid/github-cli as downloader
ARG GH_TOKEN
ENV GH_TOKEN=$GH_TOKEN
WORKDIR /app
RUN gh release download --pattern "JMusicBot-*.jar" --repo jagrosh/MusicBot
RUN mv JMusicBot-*.jar JMusicBot.jar

FROM eclipse-temurin:17-jre-focal
COPY --from=downloader /app/JMusicBot.jar /app/JMusicBot.jar
WORKDIR /app
ENTRYPOINT ["java", "-Dconfig=/app/config.txt", "-Dnogui=true", "-jar", "/app/JMusicBot.jar"]

4. Setup your DockerHub and GitHub secrets for this repository. The GitHub token doesn't require any permissions, only public access is necessary.
5. Use a GitHub Actions workflow to build the image periodically and as soon as a new release is published then push it to DockerHub for all architectures supported by the base image. You can include automatic vulnerability scanning for the image as a good measure. Ex.:

name: Build and push Docker image

on:
  schedule:
    - cron: '24 9 * * 6'
  release:
    types: [released]
  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Dockerfile
        id: checkout
        uses: actions/checkout@v2

      - name: Setup QEMU
        id: qemu
        uses: docker/setup-qemu-action@v1
        with:
          image: tonistiigi/binfmt:latest
          platforms: all
      
      - name: Setup Docker Buildx
        id: buildx
        uses: docker/setup-buildx-action@v1

      - name: Login to DockerHub
        id: login
        uses: docker/login-action@v1
        with:
          username: ${{ secrets.DOCKERHUB_USERNAME }}
          password: ${{ secrets.DOCKERHUB_TOKEN }}

      - name: Build and push Docker image
        id: build
        uses: docker/build-push-action@v2
        with:
          build-args: GH_TOKEN=${{ secrets.GH_TOKEN }}
          context: .
          file: ./Dockerfile
          platforms: linux/amd64,linux/arm64/v8,linux/arm/v7,linux/ppc64le,linux/s390x
          push: true
          tags: |
            jagrosh/jmusicbot:latest
            
      - name: Run Trivy vulnerability scanner
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: 'docker.io/jagrosh/jmusicbot:latest'
          format: 'template'
          template: '@/contrib/sarif.tpl'
          output: 'trivy-results.sarif'
          severity: 'CRITICAL,HIGH'

      - name: Upload Trivy scan results to GitHub Security tab
        uses: github/codeql-action/upload-sarif@v1
        with:
          sarif_file: 'trivy-results.sarif'

6. The image will be automatically published to DockerHub, so any user could run it as:

$ docker run --name jmusicbot -d -v /path/to/config.txt:/app/config.txt:ro \
-v /path/to/serversettings.json:/app/serversettings.json:ro --restart=always \
jagrosh/jmusicbot

7. If they want to use playlists, all they have to do is to set the playlistsFolder location in their config,txt relative to the /app path (ex.: playlistsFolder = "/app/playlists") and bind a local playlist folder to the bot container:

$ docker run --name jmusicbot -d -v /path/to/config.txt:/app/config.txt:ro \
-v /path/to/serversettings.json:/app/serversettings.json:ro \
-v /path/to/playlists:/app/playlists:ro --restart=always jagrosh/jmusicbot

8. Include the instructions on how to run the bot using Docker/Portainer in the documentation.

How would this feature be used?

Users wanting to host JMusicBot using Docker or Portainer would have easy of mind that the image they're running is secure. Additionally, users without much experience on server administration could easily host the bot with a single command.

Additional Info

All the steps mentioned above, with some changes, are being used on my repository (https://github.com/alexandreteles/jmusicbot_docker) to build and publish a Docker image (https://hub.docker.com/r/alexandreteles/jmusicbot) on those parameters. Please, go check it out if you have any questions on how the process works. Especial detail for the Security tab being populated with the relevant information about vulnerabilities in the image.

The code is under the WTFPL so, well, "Do What The F*ck You Want".

In any case, having it built and shipped by the project maintainer would make it much more trusted, especially if the build process is transparent and mentioned in the image description. Even if it should be just a bit of CTRL+C/CTRL+V for it to be setup, I could submit the necessary PRs. You would still need to setup the secrets, tho.

Checklist

• I have checked the documentation to make sure this feature doesn't already exist
• I have searched for similar feature requests
• I have confirmed that my requests is not on the list of things that will not be added
• I am running the latest version of the bot:

[Wobak]

I think there might be simpler ways to do this, unless I'm mistaken.

Instead of building an image, pulling the jar and running the openjdk image would be way faster to setup (imho), or as an
alternative.

I created the following:

├── data
│   ├── config.txt
│   ├── JMusicBot-0.3.7.jar
│   ├── JMusicBot-current.jar -> JMusicBot-0.3.7.jar
│   └── serversettings.json
└── docker-compose.yml

And the docker-compose.yml goes like this :

---
version: "3"
services:
  musicbot:
    image: openjdk
    container_name: musicbot
    volumes:
      - ./data:/usr/src/myapp
    working_dir: /usr/src/myapp
    restart: unless-stopped
    entrypoint: java
    command: "-Dnogui=true -jar JMusicBot-current.jar"

Doing that allows the last openjdk version to be pulled and used, and when a new version is released, just replace the symlink in the data folder, then restart the container and everything runs smoothly.

[Foxite]

That does work, but it prevents systems such as Watchtower from working, which automatically pull new image versions.

[Wobak]

True, but as the bot notifies you already about a new version, I just DL the new jar, replace the symlink and restart the container, which seems reasonable compared to creating github jobs etc... for people who might not be as familiar with such processes :)

[Wobak]

I think both approaches should be considered tbh. If people want automated updates with a current image, then your idea is better, if they don't care about updating manually, knowing that the bot updates might be quite rare, then maybe I should create a PR for documenting my method?

[Foxite]

If there will be a docker image for this bot then I'm not sure why one would choose your method, using the bot image is probably easier to set up even if you don't care about updating it.

[aazam476]

I do have Docker Hub Pro, which (I believe) allows me to configure an autobuild to run everytime this repo is updated. I am the developer of the docker "azamserver/pihole-doh" which has 1.5K pulls, and I would be glad to help out.

[aazam476]

Any update on this issue? I'm holding off updating my bots till this is resolved.

[alexandreteles]

@AzamServer The issue is on-hold, which means that the dev probably has an eye on it but isn't going to move with the changes too quickly. If you want, you can use the images I publish to Docker Hub (https://hub.docker.com/r/alexandreteles/jmusicbot), built and published thru my repository (https://github.com/alexandreteles/jmusicbot_docker).

Images are periodically rebuilt based on updates to the base image(s) or to this repository.

[aazam476]

@alexandreteles Thanks for the help, and I will be using your docker!