Question
JHipster Docker Compose relies on mutable latest tags for services
Sky Atlas
0 reputation · 11 May 2024, 21:59 UTC
45.6K views1
Loading…
0 reputation · 11 May 2024, 21:59 UTC
When generating a repeatable development environment, JHipster creates a docker‑compose.yml that uses the latest tag for the application, database, and monitoring containers.
This configuration depends on Docker Hub's mutable latest tag, which can change between pulls and lead to inconsistent images across machines or CI runs. The goal is to guarantee that the same binary images are used each time the environment starts, but the generated file does not include explicit version pins or digest references, and the standard documentation does not describe a preferred way to override these tags.
What versioning strategy should be adopted for the generated compose file? Should JHipster provide a mechanism to pin image versions without complicating upgrades? Is there a recommended practice for teams to enforce reproducible images while keeping the getting‑started guide simple?
35275 reputation · 12 May 2024, 03:48 UTC
Replace the mutable latest tag with a fixed version or digest, optionally using an .env file or a Compose override so that upgrades remain simple.
jhipsterdocker-compose.yml currently uses image: :latest for the app, database, and monitoring services.latest tag on Docker Hub is mutable; pulling it later may give a different image.mysql:8.0.36) or a digest (mysql@sha256:…) guarantees the same binary image each time.The generator chooses latest for developer convenience, assuming you want the newest base images while iterating locally. It does not anticipate the need for reproducible builds in CI or production without extra steps.
docker-compose.yml.latest to the desired version tag (e.g., postgres:15) or to a digest if you prefer an immutable reference..env file with variables like APP_VERSION=0.0.1-SNAPSHOT, DB_VERSION=8.0.36, and reference them in the compose file: image: app:${APP_VERSION}.docker compose pull to fetch the exact images.docker images that the IDs match the specified tags/digests.When a new version is needed, update the version in the .env file (or directly in the compose file) and re‑run docker compose pull. This keeps the getting‑started guide simple while making the composition reproducible.
Note: If you are using custom images built from your own registry, you must know the repository name and tag; otherwise the steps above apply to official Docker Hub images.
Use comments to ask for clarification. Post a solution as an answer.
35,275 reputation · 12 May 2024, 05:51 UTC
One detail worth adding to the pinning approaches already described: after you introduce an .env file or a docker-compose.override.yml, run docker compose config before committing. It renders the fully resolved compose file, so you can confirm in code review that no service still resolves to latest — this catches typos in variable names that would otherwise silently fall back to an empty tag.
For teams worried about pin maintenance, tools like Renovate or Dependabot can open pull requests to bump image tags in compose files and .env files automatically, which removes most of the upgrade friction without giving up reproducibility.
Also note that digest pinning (image@sha256:…) is the only fully immutable option; version tags like postgres:15 are still mutable and can be republished, so for strict CI reproducibility prefer digests and let the automation update them.