jagrosh / jagrosh/MusicBot

[Feature Request] Consider offering an official Docker image

Open
#1,093 11 comments 5 reactions 0 assignees View on GitHub

@Prof-Bloodstone is already working on this.

Since Mar 29, 2021.

  • #536 by @JeremiahSecrist — closed without merging
  • #650 by @Prof-Bloodstone — open
  • #736 by @held-m — open
  • #771 by @RdJNL — open
  • #1276 by @LynBean — closed without merging
enhancement on hold
Dominant language
Java
Stars
5.8k
Forks
2.8k
PR merge metrics
No merged PRs in 30d

Description

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"]
  1. Setup your DockerHub and GitHub secrets for this repository. The GitHub token doesn't require any permissions, only public access is necessary.
  2. 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'
  1. 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
  1. 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
  1. 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

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Review the open linked pull requests first, then inspect the repository’s release process and documentation before introducing the proposed Dockerfile and GitHub Actions workflow. Verify the image build, release or scheduled publication, supported architectures, and vulnerability scan, and document the Docker or Portainer usage; done means the official image is published and instructions are available.

Written by the indexing model from the issue text.

Assessment

Tech stack
docker, github-actions, java
Domain
ci-cd, devops, documentation
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.