Add Docker container with qlever-control tools and host Docker access

[Copilot]

Containerized environment for running qlever-control with all required dependencies and the ability to execute Docker commands on the host VM.

Implementation

• Dockerfile: Based on Debian Bookworm (slim), installs OpenJDK 17, jq, pipx, qlever (via pipx), and Docker CLI (docker.io package for build reliability)
• docker-compose.yml: Mounts Docker socket at /var/run/docker.sock and workspace directory
• entrypoint.sh: Verifies tool installation on startup; optional Docker connectivity test via TEST_DOCKER=true environment variable
• GitHub Actions: Automated builds and pushes to ghcr.io/gipplab/qlever-control on push, PR, and release events

Usage

# Pull pre-built image from GitHub Container Registry
docker pull ghcr.io/gipplab/qlever-control:latest

# Or build locally
docker build -t qlever-control:latest .

# Direct Docker
docker run -it --rm \
  -v /var/run/docker.sock:/var/run/docker.sock \
  qlever-control:latest

# Docker Compose
docker compose up -d
docker compose exec qlever-control bash

# Test Docker connectivity
docker run -it --rm \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -e TEST_DOCKER=true \
  qlever-control:latest

Notes

• Base image: Debian Bookworm (slim) for better stability and smaller size
• Docker socket mount provides root-equivalent host access; use in trusted environments only
• All packages consolidated into single layer for optimal image caching
• Workspace directory at /workspace for persistent files
• Automated builds push images to GitHub Container Registry with proper tagging (latest, semver, PR refs)

Original prompt

Create a docker container that runs docker commands on the host vm and install tools needed by qlever-control including java, jq, and more from the history
2025-12-18 14:17:51 sudo apt-get install pipx
2025-12-18 14:18:02 pipx install qlever
2025-12-18 14:18:43 pipx ensurepath
2025-12-18 14:18:53 source ~/.bashrc

optional add a test if the system can execute a test docker command such as

2025-12-18 14:29:15 docker run hello-world

on the host os.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[physikerwelt]

@copilot can you change the base image from ubuntu to debian. Also add a github compile and push action that pushes the github to ghcr.io sdimilar to https://github.com/gipplab/D-LOCKSS/blob/main/.github/workflows/build.yml

[physikerwelt]

@copilot discuss if debian or busyboxis the better base image

[Copilot]

@copilot can you change the base image from ubuntu to debian. Also add a github compile and push action that pushes the github to ghcr.io sdimilar to https://github.com/gipplab/D-LOCKSS/blob/main/.git...

Done! Changed base image from Ubuntu 22.04 to Debian Bookworm (slim) and added GitHub Actions workflow to build and push to ghcr.io/gipplab/qlever-control.

Changes in commit 48f8621:

• Base image: debian:bookworm-slim
• Java updated to OpenJDK 17 (Debian's default)
• GitHub Actions workflow at .github/workflows/build.yml that builds on push/PR/release and pushes to ghcr.io
• Workflow includes Docker layer caching and proper tagging (latest, semver, PR refs)
• Updated README with new base image info and pull instructions

All tools verified working with Debian base.

[Copilot]

@copilot discuss if debian or busyboxis the better base image

Debian vs BusyBox - Analysis:

Debian (current choice) is better for this use case. Here's why:

Requirements Analysis:

• OpenJDK 17 (large, ~200MB+)
• Python3 + pip + pipx + qlever
• Docker CLI
• jq, git, curl, wget
• Full bash shell (needed for entrypoint script)

Debian Advantages:

1. ✅ Package availability: All required packages (openjdk-17-jdk, pipx, docker.io, jq) are directly available via apt
2. ✅ Stability: Well-tested package versions with security updates
3. ✅ Compatibility: Standard glibc environment - no musl-related issues
4. ✅ Development tools: Full toolchain for Python packages that may need compilation
5. ✅ Less complexity: No need to manually build/install Java or manage dependencies

BusyBox Limitations:

1. ❌ No package manager: Would need to manually compile/install everything
2. ❌ No Java: OpenJDK not available - would need multi-stage build or external download
3. ❌ No Python: Would need to build Python from source
4. ❌ Limited shell: Basic shell lacking features needed for complex scripts
5. ❌ Size gain minimal: After installing Java (~200MB), Python (~50MB), and tools, final image would be similar size

Size Comparison (estimated):

• BusyBox base: ~2MB
• BusyBox + dependencies: ~350-400MB (due to manual builds)
• Debian slim base: ~75MB
• Debian slim + dependencies: ~450-500MB

Recommendation: Keep Debian Bookworm (slim)
The ~50MB base size difference becomes negligible given the large dependencies required (Java, Python ecosystem). Debian provides better maintainability, security updates, and reliability without significantly increasing final image size.

[physikerwelt]

The docker.io from the host should be used why would we want to install it. That might create confusion.

[physikerwelt]

@copilot

[Copilot]

We need the Docker CLI client installed in the container to communicate with the host's Docker daemon via the socket mount.

What we install: docker.io package (provides /usr/bin/docker CLI binary)
What we DON'T install/run: Docker daemon (dockerd service)

How it works:

1. Container has Docker CLI binary (/usr/bin/docker)
2. Socket mount (-v /var/run/docker.sock:/var/run/docker.sock) connects CLI to host's daemon
3. When you run docker ps in the container, the CLI sends commands to the host's daemon via the socket

Without docker.io installed:

• docker command wouldn't exist in the container
• entrypoint.sh line 22 (docker run --rm hello-world) would fail
• Users couldn't run docker ps or any docker commands from inside the container

The docker.io installation is only for the CLIENT tool, not the daemon. The host's Docker daemon does all the actual work.

[physikerwelt]

can't we use the docker command from the host os?