How do you run the wiremock/wiremock image so it serves your committed scaffolding-inspection stubs?
answer
- the image decides where here is
- two things to supply: port, files
- mount the parent, not mappings/
- trailing arguments reach the launcher
- /home/wiremock is the image's root
basics
~20 sBind-mount the directory holding mappings and __files onto /home/wiremock, the root the wiremock/wiremock image uses, and publish the server's port. Launcher flags added after the image name reach WireMock itself. No image of your own is needed.
solid answer
~40 sThe image already contains the standalone server, so you supply two things: a port and the files. `-p 8089:8080` maps a host port onto the port WireMock listens on inside the container, and `-v "$PWD/scaffolding-inspection-stubs:/home/wiremock"` puts your `mappings/` and `__files/` where the image roots them. Everything after the image name is handed to the same launcher `java -jar wiremock-standalone.jar` would have run, so `--verbose` and `--disable-banner` behave identically, while `--root-dir` would override the mount rather than complement it. Keep the mount target the *parent* of `mappings/` and `__files/`; mounting `mappings/` itself is the commonest way to lose every body file. Because the set is read as the process starts, the container is the unit of reload. In MockServer, the `mockserver/mockserver` image is instead pointed at a start-up expectation file by `MOCKSERVER_INITIALIZATION_JSON_PATH`.
code
bash · 9 linesSTUBS="$PWD/scaffolding-inspection-stubs"
ls "$STUBS/mappings" "$STUBS/__files"
docker run --rm -d --name wiremock-scaffolding \
-p 8089:8080 \
-v "$STUBS:/home/wiremock" \
wiremock/wiremock --verbose --disable-banner
curl -si http://localhost:8089/v1/scaffolds/SC-4471/inspections | head -1go deeper
Know the two moving parts of the command: publish a port with -p, and bind-mount the directory holding mappings/ and __files/ onto /home/wiremock. Nothing else is required to serve a committed stub set.
Explain why the mount target is the parent directory rather than mappings/, and what happens to flags written after the image name. Both answers come from the image running the same launcher as the jar.
Talk about operating it: one named container, a fixed published port the suite already knows, the whole invocation in a script beside the stub directory so the mount target cannot drift from the layout.
Weigh the container against an embedded or shared instance for the fleet, and set the convention that makes stub sets portable between them — layout, port and reload story chosen once rather than per team.
## What the image already decides The `wiremock/wiremock` image ships the standalone server and starts it for you, which means three decisions are made before your command line begins: - the server listens on WireMock's default HTTP port inside the container; - the root directory is `/home/wiremock`, so `mappings/` and `__files/` are expected directly beneath it; - the container's start-up command is the same launcher `java -jar wiremock-standalone.jar` would run, so anything appended after the image name becomes its arguments. Everything else — which stubs exist, which address the outside world uses, how chatty the logs are — is yours to supply. ## The two things you supply **A published port.** `-p 8089:8080` maps a host port you choose onto the port WireMock listens on inside the container. This is the address the code under test must be pointed at: a scaffolding-inspection client still holding its production base URL will never reach the stub server, however well the mapping is written. **The stub set.** `-v "$PWD/scaffolding-inspection-stubs:/home/wiremock"` puts the directory that *contains* `mappings/` and `__files/` at the root the image uses. The layout inside the mounted directory is the contract: - `mappings/scaffold-inspections-list.json` — the stub that answers `GET /v1/scaffolds/SC-4471/inspections`. - `mappings/file-inspection-created.json` — the stub that answers the filing call with `201` and an `inspectionId`. - `__files/scaffold-SC-4471-inspections.json` — the body the first mapping serves. ## Arguments after the image name This is the part that surprises people, and it is the part worth demonstrating. `docker run ... wiremock/wiremock --verbose --disable-banner` does not need a wrapper script, a custom entrypoint or an image of your own: the flags land on the launcher. Useful ones for a container: - `--verbose` — WireMock's verbose logging on stdout, which is where the container's log stream already points. - `--disable-banner` — suppresses the start-up banner, which is noise in a build log. - `--port` — changes the port *inside* the container, which usually only complicates the `-p` mapping and is better left alone. - `--root-dir` — overrides the image's root, so passing it while also mounting on `/home/wiremock` is how teams accidentally serve an empty set. ## The layout mistake that costs the most time Mounting `scaffolding-inspection-stubs/mappings` onto `/home/wiremock/mappings` looks tidier and half-works: the stub definitions load, and every response that references a body file by name fails, because `__files/` never came along. The failure is worse than a total outage because it is partial — some scaffolding-inspection calls answer correctly and the ones serving a recorded inspection body do not. Mount the parent directory and both halves travel together. ## Reload is a restart The standalone launcher builds its set from the root as the process starts. Editing `mappings/scaffold-inspections-list.json` on the host changes the file inside the container immediately — a bind mount is not a copy — but the server keeps serving what it read at start-up. Restarting the container is the straightforward way to pick the change up; changing a running instance without a restart is a call on the server's own admin API rather than a file-system event. ## The same knob in the other two products Each row below names its own product's surface; do not mix them. | product | started as | what it reads at start-up | |---|---|---| | WireMock | the `wiremock/wiremock` image, or `java -jar wiremock-standalone.jar` | `mappings/` and `__files/` under the root directory, which the image fixes at `/home/wiremock` | | MockServer | the `mockserver/mockserver` image, or the `mockserver-netty` artifact | the expectation file named by `mockserver.initializationJsonPath` or `MOCKSERVER_INITIALIZATION_JSON_PATH` | | Mountebank | `mb` with `--configfile` | the imposter definitions in the file `--configfile` names | The shape of that input differs per product, and a team moving between them keeps hunting for the other one's shape and concluding the feature is missing. Read each row as its own product's answer and carry no vocabulary across. ## Practical habits - Give the container a name so logs and a restart are one command away. - Publish a port your suite already knows, and keep the container-side port at the default. - Put the whole invocation in a script beside the stub directory, so the mount target and the directory layout cannot drift apart. - Treat the stub directory as reviewable source: it is the contract the tests run against, not scratch data.
- Why is mounting the mappings directory itself worse than mounting its parent?Because only half the set arrives. WireMock reads stub definitions from `mappings/` and response bodies from `__files/`, both beneath one root. Mount `mappings/` alone and the definitions load while every `__files` body is missing, so some scaffolding-inspection calls answer and the ones serving a stored body do not. A partial failure costs far more to diagnose than an empty set.
- You need one extra launcher flag only in CI. Where does it go?After the image name on the container's command line. Those arguments reach the same launcher the jar would have run, so the CI invocation can add `--verbose` while the local one stays quiet, with no image build, no entrypoint override and no wrapper script. Keep the mount and the port identical between the two so the only difference is the flag.
saying these in an interview costs you the question
- Mounting mappings/ itself and losing every body file under __files/
- Expecting the container to pick up an edited mapping without a restart
- Assuming you must build your own image to add stub files
- Passing --root-dir after the image name and wondering why the mount is ignored
- Publishing no port, then pointing the test at the container's internal address