Push linux/amd64 Docker image

[thc202]

The latest Docker image pushed is now linux/arm64 which makes it very slow when running from linux/amd64, so much that the initial start up is longer than 1 minute and breaks our tests, e.g.: https://github.com/zapbot/zap-mgmt-scripts/actions/runs/8370459364/job/22917853473#step:3:1

We can increase the wait time but it would be better if it was still provided linux/amd64 as before, which is the most common.

[thc202]

We ended up disabling the scans in CI it takes too long to start.

[davewichers]

I'm happy to fix it if you explain how. The Docker file is build using these two files in the VMs folder: Dockerfile and buildDockerImage.sh. How do I change this to use linux/amd64 rather than linux/arm64? Or, I could create a different Docker file for ZAPs use to use amd64. I'd like to track down who/when this was changed and if it was a 'contribution' ask them author why. Or maybe the latest ubuntu is now arm64??

[thc202]

You can create the image with different architectures: https://docs.docker.com/build/building/multi-platform/
I'd suggest that as it would be faster when running in both amd64 and arm64. You could also create a GitHub workflow to build/publish the images (e.g.: https://github.com/zaproxy/zaproxy/blob/59a6ccab8b210b953e0348bfb337b3416e6c4329/.github/workflows/release-main-docker.yml).

I think a different host was used (with different processor) to build/publish the image.

[davewichers]

@thc202 - Please try to the new Docker image I pushed out. It should be specific to AMD64. I'm working on pushing out an ARM64 version too, but need permission to create/push a new Docker image at docker.io.

[thc202]

A separate image should not be needed, the same image can have different architectures.

[davewichers]

@thc202 - you said that before but I couldn't figure out how to do that. If you know how, and can implement via a pull request, that would be great. Regardless, did you confirm the AMD64 image works for you?

[thc202]

What type of changes are you looking for? A workflow to publish them?

I did not yet, will do that in the following days.

[davewichers]

@thc202 - no, the command line commands required to create one docker image that supports BOTH architectures. I can then publish that one image to docker.io like I do now.

[TheAuditorTool]

@thc202 - no, the command line commands required to create one docker image that supports BOTH architectures. I can then publish that one image to docker.io like I do now.

I have fixed it the way you wanted AND i have added a git workflows yaml (the standard way) but IT IS NOT WIRED UP...
The git workflows IS dead code until you wire it up yourself or tell me to do it.

---

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
FROM ubuntu:latest -> FROM ubuntu:22.04	Pin the base image for reproducible builds. latest silently rolls forward and has caused breakage before.
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.

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 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.

.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 VMs/ directory:

cd 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.

---

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