run_locally.sh: refactor to run any number of nodes, defaults to two

[mickmis]

This extends the existing run_locally.sh deployment to run with a chosen number of nodes instead of a unique one. By default it runs two nodes, which is the case in the CI after this change.

Notable changes:

• compose file is now templated and needs to be orchestrated from run_locally.sh
• networks are now defined within run_locally.sh
• compose profiles: created crdb and renamed with-yugabyte into ybdb out of consistency
• added crdb-init which is now required with multiple nodes
• revisited some hostnames
• assigned fixed IP address for each DB container (useful for simulations with tc in upcoming PR)
• can deploy an arbitrary number of nodes, defaults to 2, because we want to replicate behavior of having two DSS running, even though before it was simulated with a network alias
• some ports mappings are changed to accomodate the forwarding of ports of all nodes

[BenjaminPelletier]

It looks like there's a problem for later versions of docker:

pelletierb@pelletierb:~/IdeaProjects/OpenSource/monitoring$ ./build/dev/run_locally.sh up -d
service "rid_bootstrapper" can't be used with `extends` as it declare `depends_on`
pelletierb@pelletierb:~/IdeaProjects/OpenSource/monitoring$ make start-locally
build/dev/run_locally.sh up -d
service "rid_bootstrapper" can't be used with `extends` as it declare `depends_on`
make: *** [Makefile:60: start-locally] Error 15
pelletierb@pelletierb:~/IdeaProjects/OpenSource/monitoring$ docker --version
Docker version 29.4.0, build 9d7ad9f

Asking Gemini, it says:

---

It looks like you’ve run into a regression or a strict enforcement change in the Docker Compose spec that was reintroduced in very recent versions (late 2025/early 2026).

The error service "rid_bootstrapper" can't be used with extends as it declare depends_on happens because, according to the formal Compose specification, a service is not allowed to be a "base" for extension if it defines its own dependencies.

Why this is happening now
Historically, there has been a "tug-of-war" in Docker Compose development regarding this rule:

Docker Compose v1: Strictly forbade extending a service that had depends_on.

Early Docker Compose v2: Relaxed this rule (often accidentally), allowing users to extend services with dependencies, though it often led to "ghost" dependencies or broken startup orders.

Docker 29.x (Your version): This version has moved to a more rigid validation of the Compose Spec. It throws a hard error to prevent the ambiguity that occurs when you extend a service but don't necessarily have its dependencies (like a database or network) defined in your local file.

The reason your CI (v28.0.4) isn't failing is simply that it hasn't received the update that turned this "best practice" warning into a "hard block" error.

The standard way to handle this is to create a "template" service that has everything except the depends_on field, then have both your bootstrapper and your other services extend that.

Before (Invalid in v29):

services:
  rid_bootstrapper:
    image: my-image
    depends_on:
      - db  # <--- This "poisons" the service for extension
    environment:
      - FOO=bar

  another_service:
    extends: rid_bootstrapper # <--- Error!

After (Recommended):

services:
  rid_base:
    image: my-image
    environment:
      - FOO=bar

  rid_bootstrapper:
    extends: rid_base
    depends_on:
      - db

  another_service:
    extends: rid_base  # Works perfectly!

[mickmis]

It looks like there's a problem for later versions of docker

The latest specs read differently to me:

When a service is referenced using extends, it can declare dependencies on other resources. These dependencies may be explicitly defined through attributes like volumes, networks, configs, secrets, links, volumes_from, or depends_on.

Also, note that Docker Compose has its own release cycle. Locally I have:

(monitoring) misbach@mickael-fedora-x1-gen9:~/Development/InterUSSIdeaProject/monitoring$ docker compose version
Docker Compose version v5.1.3

And the CI has:

Docker Compose version v2.38.2

Do you have maybe locally an in-between version that does not support it?

[the-glu]

Just a thought, would it make sense to have it parameterized somehow?

I would keep the default as light, with only one instances of databases, to keep them in the single, quick case and have limited resources usage, and use the case with N database only for load tests.

[mickmis]

Just a thought, would it make sense to have it parameterized somehow?

I think you are right. I wanted to do that initially but could not find a not-too-complex way of doing so. However on a second thought I think there is. I will update this PR accordingly.

[BenjaminPelletier]

When I check out this branch and run make down-locally, I get:

pelletierb@pelletierb:~/IdeaProjects/OpenSource/monitoring$ make down-locally
build/dev/run_locally.sh down
service "rid_bootstrapper" can't be used with `extends` as it declare `depends_on`
service "rid_bootstrapper" can't be used with `extends` as it declare `depends_on`
Removing networks...
Error response from daemon: error while removing network: network dss_internal_network has active endpoints (name:"local_infra-crdb-1" id:"c9b6f410be92")
exit status 1
interop_ecosystem_network

If I take down all my containers on the main branch and then try to start them up from this branch:

pelletierb@pelletierb:~/IdeaProjects/OpenSource/monitoring$ make start-locally
build/dev/run_locally.sh up -d
Creating networks...
86c97cd8b774a78606b52c953ebdb5aad6173c281ef2f17a68a7f1884efc85b0
efc001c427c229c462d4a67fac335c216c7a9fcc0ab6e4dcc3e3dafb7114bc71
Starting containers...
service "rid_bootstrapper" can't be used with `extends` as it declare `depends_on`
service "rid_bootstrapper" can't be used with `extends` as it declare `depends_on`

My docker versions are:

pelletierb@pelletierb:~/IdeaProjects/OpenSource/monitoring$ docker version
Client: Docker Engine - Community
 Version:           29.4.1
 API version:       1.54
 Go version:        go1.26.2
 Git commit:        055a478
 Built:             Mon Apr 20 16:32:52 2026
 OS/Arch:           linux/amd64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          29.4.1
  API version:      1.54 (minimum version 1.40)
  Go version:       go1.26.2
  Git commit:       6c91b92
  Built:            Mon Apr 20 16:32:52 2026
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v2.2.3
  GitCommit:        77c84241c7cbdd9b4eca2591793e3d4f4317c590
 runc:
  Version:          1.3.5
  GitCommit:        v1.3.5-0-g488fc13e
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0
pelletierb@pelletierb:~/IdeaProjects/OpenSource/monitoring$ docker compose version
Docker Compose version v2.24.6

Even if it takes somewhat more effort to implement in a way that can be used by more versions of docker, I think that's worthwhile as we want to minimize friction to spin up users. docker is intended to remove the friction of setting up an environment just right, and we lose some of that benefit if a user has to fiddle with getting just the right version of docker before things will work. There are also many corporate restrictions around what versions of what software can be run -- upgrading docker is not necessarily an easy task for all users.