fix(docker): multi-arch image build (amd64+arm64) -- closes #223

[TheAuditorTool]

The published Docker image was linux/arm64 only because it was built on an ARM64 host. This caused >60s startup via QEMU emulation on amd64, breaking downstream CI (ZAP scans).

Changes:

• VMs/buildDockerImage.sh: rewrite to use docker buildx with --platform linux/amd64,linux/arm64 for multi-arch manifest; uses --file VMs/Dockerfile and build context VMs (mirrors the CI workflow paths)
• VMs/Dockerfile: collapse RUN layers, add EXPOSE 8443 and CMD for usability
• VMs/runDockerImage.sh: update image tag from benchmark to owasp/benchmark to match the new build script's output
• .github/workflows/docker-publish.yml: add CI workflow for automated multi-arch builds (workflow_dispatch only -- inactive until secrets and triggers are configured)
• PR_multi-arch-docker.md: changelog, guide, and activation steps

Summary

The published owasp/benchmark:latest Docker image was built on an ARM64 host,
making it linux/arm64 only. On amd64 machines (the vast majority of CI runners
and developer workstations), Docker falls back to QEMU emulation, causing
startup times over 60 seconds -- long enough to break downstream CI (e.g., ZAP
scans reported in #223).

This PR switches the build tooling from docker build to docker buildx build
with --platform linux/amd64,linux/arm64. Docker Hub receives a single manifest
list that serves the native image for each architecture automatically.

---

What Changed

VMs/Dockerfile

Change	Why
Collapsed 3 separate RUN apt-get layers into 1	Fewer layers = smaller image. Single RUN also ensures apt-get update and install share the same cache.
Added rm -rf /var/lib/apt/lists/*	Standard practice -- drops the apt cache from the final layer.
Collapsed BenchmarkUtils clone + build into 1 RUN	Fewer layers.
Collapsed BenchmarkJava clone + CVE-2022-24765 workaround + build into 1 RUN	Fewer layers, keeps related steps together.
Collapsed useradd + chpasswd into 1 RUN	Fewer layers.
Added EXPOSE 8443	Documents the port Benchmark listens on (Cargo/Tomcat). Informational only -- does not affect runtime behavior.
Added CMD ["./runBenchmark.sh"]	Container now starts the benchmark when run without arguments, instead of doing nothing.
Removed trailing whitespace on the useradd line	Housekeeping.

Base image remains ubuntu:latest per maintainer preference.

VMs/buildDockerImage.sh

Complete rewrite. The old script ran docker build -t benchmark . which
produces a single-architecture image matching the build host.

The new script:

1. Creates (or reuses) a docker buildx builder instance named
   benchmark-multiarch.
2. Runs docker buildx build --platform linux/amd64,linux/arm64 --push with
   explicit --file VMs/Dockerfile and context VMs (matching the paths
   used by .github/workflows/docker-publish.yml), which builds for both
   architectures and pushes a manifest list to Docker Hub in one atomic step.

Important: --push is required because multi-arch manifest lists cannot be
loaded into the local Docker daemon. The build and push happen together.

VMs/runDockerImage.sh

Single-token update: image tag changed from benchmark to owasp/benchmark
so docker run pulls the image that the new build script publishes.

.github/workflows/docker-publish.yml (NEW -- INACTIVE)

A GitHub Actions workflow that automates the multi-arch build and push.
This workflow is set to workflow_dispatch only -- it will never run
automatically until you activate it. See the activation section below.

---

How to Use the Build Script (Manual Build)

Prerequisites: Docker with buildx support (Docker Desktop 19.03+ or Docker
Engine with the buildx plugin). You must be logged in to Docker Hub:

docker login -u <your-dockerhub-username>

Then, from the repository root:

./VMs/buildDockerImage.sh

This builds for both amd64 and arm64 and pushes owasp/benchmark:latest to
Docker Hub. No separate docker push step is needed.

---

Running the Published Image

After publishing, run the image with:

./VMs/runDockerImage.sh

This pulls owasp/benchmark:latest from Docker Hub and starts the benchmark
inside the container.

---

How to Activate the GitHub Actions Workflow

The workflow file is already in place at
.github/workflows/docker-publish.yml, but it will only run when manually
triggered via the GitHub UI. To make it fully automatic:

Step 1: Add Docker Hub Secrets

Go to Settings > Secrets and variables > Actions in your GitHub repository
and add:

Secret name	Value
DOCKERHUB_USERNAME	Your Docker Hub username
DOCKERHUB_TOKEN	A Docker Hub access token (create one at https://hub.docker.com/settings/security)

Step 2: Add Automatic Triggers

Open .github/workflows/docker-publish.yml and uncomment the trigger lines:

on:
  workflow_dispatch:
  # Uncomment these when ready:
  push:
    branches: [master]
    paths: ['VMs/Dockerfile']
  release:
    types: [published]

This will automatically rebuild and push the image whenever:

• The Dockerfile is changed on master, or
• A new GitHub release is published.

Step 3: Test with Manual Trigger

Before enabling automatic triggers, test the workflow manually:

1. Go to Actions > Docker Publish in your repository
2. Click Run workflow
3. Verify the image appears on Docker Hub with both architectures

You can confirm multi-arch support with:

docker manifest inspect owasp/benchmark:latest

This should show entries for both amd64 and arm64.

---

What Was NOT Changed

Item	Reason
JDK version (17)	Tracked separately in #227
bench:bench user/password	This is a test image, not a production deployment
timeout 60 ./runBenchmark.sh; exit 0 warm-up trick	Functional and intentional -- caches runtime dependencies in the image

[davewichers]

Shouldn't this simply be latest, like it was previously?

[TheAuditorTool]

Shouldn't this simply be latest, like it was previously?

It can be, if you want it to be.
But its not standard.
Using latest is generally considered an anti-pattern for Docker builds, especially for benchmarks where reproducibility is critical. latest is a moving target, when Ubuntu rolls its LTS version forward (like updating latest from 22.04 to 24.04), it silently changes underlying system libraries, apt packages, and default Java/Python versions, which often breaks the build overnight.

Pinning it to 22.04 guarantees the environment builds exactly the same way every time. That said, if you strongly prefer it to track the bleeding edge and don't mind the occasional upstream breakage, I'm happy to change it back to latest! Let me know what you prefer.

[davewichers]

I'd prefer latest, but when it breaks, people can manually fix it by setting it to a previous version that works, and lets us know, so we can fix it again. Thanks

[TheAuditorTool]

Hello. Sorry for my slow reply, have a hell week this week, traveling the entire country, sadly quite literally :(
updated to "latest" in the last commit pushed. Please review.

[davewichers]

@TheAuditorTool - No worries. Thanks for the change. @darkspirit510 - Can you test this on your Mac to see if it works for you? And if you happen to have access to a Windows machine or VM test it there too? And let me know if it's all good (or not).

[darkspirit510]

@davewichers (how) do you publish docker images? https://hub.docker.com/r/owasp/benchmark this one is some months old. This workflow could help automating this, but if you prefer manual publish, we do not need it.

[darkspirit510]

@TheAuditorTool does not work on my test server:

root:BenchmarkJava/ (fix/multi-arch-docker✗) # VMs/buildDockerImage.sh                                                                                                                   [23:16:25]
Creating buildx builder: benchmark-multiarch
benchmark-multiarch
Building owasp/benchmark:latest for linux/amd64,linux/arm64 ...
[+] Building 15.1s (2/2) FINISHED                                                                                                                              docker-container:benchmark-multiarch
 => [internal] booting buildkit                                                                                                                                                               14.7s
 => => pulling image moby/buildkit:buildx-stable-1                                                                                                                                            13.0s
 => => creating container buildx_buildkit_benchmark-multiarch0                                                                                                                                 1.7s
 => [internal] load build definition from Dockerfile                                                                                                                                           0.1s
 => => transferring dockerfile: 2B                                                                                                                                                             0.0s
ERROR: failed to build: failed to solve: failed to read dockerfile: open Dockerfile: no such file or directory

[TheAuditorTool]

Thanks for catching this, and sorry for the slow turnaround.

Reproduced: from the repo root, VMs/buildDockerImage.sh ran docker buildx build … ., so buildx looked for ./Dockerfile (which doesn't exist) instead of VMs/Dockerfile. The fix switches the script to use --file VMs/Dockerfile with build context VMs, mirroring the paths in .github/workflows/docker-publish.yml so the local script and the CI workflow stay in sync.

I also noticed VMs/runDockerImage.sh still referenced the old benchmark tag, which would have given a "no such image" error after a successful build — that's fixed in the same commit (now owasp/benchmark). The PR description has been updated to reflect the new "run from repo root" invocation.

On your separate question to @davewichers about Docker Hub publish cadence: the workflow this PR adds (.github/workflows/docker-publish.yml) is designed to automate it, but it's intentionally inactive (workflow_dispatch only) until two Docker Hub secrets are added. The activation steps are documented in the workflow file's header comment and in PR_multi-arch-docker.md. That's @davewichers' call, but the wiring is in place if he wants it.

If you have a moment to try it again from the repo root after docker login, confirmation that the build succeeds would be very welcome.