magus v0.4.3 is out. See what's new
¶ View markdown source · ✎ Suggest an edit
2 min read

MGS5001: near-duplicate services

Two or more long-running service ops in the resolved run look like copies of the same service: they share an image repository and a container port, but differ in some detail (an environment variable, an image tag, a volume), so magus does not silently merge them. Left as-is they run as separate processes.

[MGS5001] 3 services share image "postgres" on container port 5432 but will run as separate processes:
  billing/db  (tag=15, POSTGRES_DB=billing)
  search/pg   (tag=16, POSTGRES_DB=search)
  web/api-db  (tag=15, POSTGRES_DB=api)
if these are meant to be one shared service, extract a shared target both need; otherwise mark them distinct with a reason.
  see: .../MGS5001.md

Why

When several projects each define "their own" Postgres (or app), each service is a distinct target, nothing deduplicates them, and bringing up the whole stack runs one process per project. That is the sprawl foot-gun: a machine drowning in near-identical, resource-hungry containers nobody meant to run separately.

Magus deduplicates services by a fingerprint of their configuration. Two services with an identical fingerprint are auto-shared silently. But these services are only nearly identical, and the difference may be load-bearing (a different POSTGRES_DB means a different database), so magus refuses to merge them on its own and surfaces them to you instead.

The comparison is deliberately conservative: the container port is the identity ("5432 means Postgres") while the host-port binding and the image tag are ignored for grouping, so version skew (postgres:15 vs postgres:16) still clusters and is reported as a difference rather than hidden. Services on different container ports are treated as intentionally separate and are not flagged at run time (they appear only in the magus doctor audit).

Fix

  • If they are meant to be one instance, extract a single shared service target and have each project magus\needs it, so the dependency graph runs it once.
  • If the difference is intentional (for example, a test that pins a different Postgres major version), mark the service distinct with a reason so the warning stays meaningful and the decision is auditable.
MGS5001servicesservice opsharingdedupdoctordocker
Last updated (353014be)
Earlier changes on this page (2)

Full history ↗ · Blame source ↗

Glossary

Project

A directory magus recognizes as a unit of work (it has a magusfile); the unit of caching, scheduling, and dependency tracking. Project in full.

Target

A named operation (build, test, ...) you invoke with magus run <target>; it may compose a spell's tool-native operations and depend on other targets. Target in full.

Op

A single tool-native command a target composes (long form: operation); the middle of the work hierarchy (Spell to Op to Target). Op in full.

Service

A long-running or shared process magus manages across runs, distinct from a one-shot target. Service in full.

CI

An ordinary target you compose yourself with ctx.needs; magus does not hardcode its stages. It is the anchor magus affected ci keys off, and ci strips the rw charm. CI in full.

Run

One target executing under one magus invocation, such as magus run test web or magus affected ci. A run keeps its captured output behind an output reference. Every magus run is a run whether or not any job asked for it; see Job for how the two relate. Run in full.

Conventions

This page uses none of the site's convention markers. The full set is on the conventions page.