Push linux/amd64 Docker image #223

Activity

1. thc202 commented on Mar 21, 2024

   

   thc202

   on Mar 21, 2024

   ContributorAuthor

   More actions

   We ended up disabling the scans in CI it takes too long to start.
2. davewichers commented on Mar 21, 2024

   

   davewichers

   on Mar 21, 2024

   Contributor

   More actions

   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??
3. thc202 commented on Mar 25, 2024

   

   thc202

   on Mar 25, 2024

   Last edited by thc202

   ContributorAuthor

   More actions

   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.
4. davewichers commented on May 7, 2024

   

   davewichers

   on May 7, 2024

   Contributor

   More actions

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

   👍React with 👍1Reacted by thc202
5. thc202 commented on May 7, 2024

   

   thc202

   on May 7, 2024

   ContributorAuthor

   More actions

   A separate image should not be needed, the same image can have different architectures.
6. davewichers commented on May 7, 2024

   

   davewichers

   on May 7, 2024

   Contributor

   More actions

   @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?
7. thc202 commented on May 7, 2024

   

   thc202

   on May 7, 2024

   ContributorAuthor

   More actions

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

   I did not yet, will do that in the following days.
8. davewichers commented on May 7, 2024

   

   davewichers

   on May 7, 2024

   Contributor

   More actions

   @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.
9. TheAuditorTool

   added a commit that references this issue on Apr 13, 2026

   fix(docker): multi-arch image build (amd64+arm64) -- closes OWASP-Ben…

   ...

   This issue will close once commit c68a62b is merged into the 'master' branch.

   c68a62b
10. TheAuditorTool commented on Apr 13, 2026

    

    TheAuditorTool

    on Apr 13, 2026

    Last edited by TheAuditorTool

    Contributor

    More actions

    @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