[feat](docker) run the 4.1 all-in-one image as multi-node and cloud compose clusters

[morningman]

Proposed changes

#66983 added a single-container Doris for downstream CI. The next things one
wants from the same box are a cluster with several FEs and BEs, and a
compute-storage separated (cloud) cluster — for local feature work and demos,
not for the regression pipelines. This PR makes the same image serve both,
via two compose files under docker/runtime/all-in-one/4.1/compose/. No
second image, no Python, no cloud credentials.

cd docker/runtime/all-in-one/4.1/compose
docker compose -f multi-node.yml up --wait            # 3 FE + 3 BE, ~35 s to healthy
docker compose -f cloud.yml up --wait                 # fdb + ms + recycler + minio + FE + 3 BE, ~50 s
docker compose -f cloud.yml --profile ha up --wait    # ... with 3 FEs
docker compose -f cloud.yml exec client mysql -uroot -hfe-1 -P9030

One image, three ways to run it

The entrypoint now dispatches on DORIS_ROLE: all (the single container,
unchanged), fe, be, ms, recycler, cloud-init (one-shot, creates the
instance) and client (waits for the expected nodes, then idles with mysql
and curl inside the network). Each role is plain Doris under --console
with the same start → probe → register → ready-flag → fail-fast shape as
before, so docker compose up --wait blocks until the whole cluster is formed
and a dead process still turns into a non-zero exit.

Topology-dependent settings — priority_networks, replica count, balancing,
the cloud keys — moved from the conf files baked into the image to the
entrypoint, written per role at container start. The baked conf keeps only
the size-related defaults.

Cloud mode with nothing external

cloud.yml is FoundationDB + meta-service + recycler + MinIO + one to three
FEs + three BEs in two compute groups (cg_a × 2, cg_b × 1), so
use @cg_b, SHOW COMPUTE GROUPS, storage vaults and FE failover in cloud
mode all have something to run against.

• Nodes are managed by SQL: the FE gets cluster_id = <instance id> and
  derives its cloud_unique_id itself; BEs are added with
  ALTER SYSTEM ADD BACKEND ... ("tag.compute_group_name" = ...).
• cloud-init creates the instance in storage-vault mode with MinIO as the
  vault — use_path_style in the create_instance payload is enough, no
  virtual-host aliasing — and the first FE marks built_in_storage_vault as
  default, so CREATE TABLE works as is. Both steps are idempotent.
• The meta-service payload joins both tags. It is 664 MB as shipped, 456 MB
  of which is an unstripped libfdb_c.so; strip --strip-debug brings the
  whole thing to 183 MB, so the tags grow from 2.46 / 2.99 GB to 2.68 / 3.21 GB.

Also in here

• FE_MASTER may list several FEs (fe-1,fe-2,fe-3): the first one that
  answers is used, so a BE or follower restart does not wait on the one FE
  that is down. An FE that already has metadata rejoins on its own.
• A local ./output or an extracted release tarball is passed to the build
  as BuildKit named contexts. The previous --tarball-dir path could not
  work: Dockerfile.dockerignore only let output/fe and output/be into
  the context. This also means a tarball can build the image before the
  component images of a release reach Docker Hub.
• Node probes use SHOW FRONTENDS / SHOW BACKENDS with header-based column
  lookup. The frontends() / backends() table functions look handier but
  are queries, and a query needs a live BE — which is what the FE probe runs
  before.

Things a user should know (all in the README)

• Nodes get fixed IPs on a private subnet so a restart keeps their identity.
  From the host, use the published ports; on Docker Desktop the container
  addresses are not routable, so a stream load from the host cannot follow
  FE's redirect to a BE — run it from the client service. The meta-service
  HTTP API is published on 15000, since 5000 is AirPlay on macOS.
• foundationdb/foundationdb:7.1.x upstream images are amd64 only; on Apple
  Silicon fdb runs under emulation, which is fine for this purpose.
• A cloud cluster is ~9 GB; give Docker Desktop 12 GB or more.

Testing

All on 4.1.3 official component images, arm64 (Apple Silicon):

• resource/smoke-test.sh apache/doris:all-in-one-4.1.3 base — the existing
  single-container test, unchanged and green.
• compose/smoke-test.sh multi-node (1 min 40 s) and compose/smoke-test.sh cloud (2 min 7 s): bring the topology up under its own project name,
  subnet and host ports; assert 3 FE / 3 BE alive; create / insert / read;
  three replicas over three BEs, or two compute groups + default vault +
  objects in MinIO; stream load through the client; kill the master FE and
  write through the new one (elected in 3–9 s); restart a BE while the old
  master is down; bring the old master back; tear down.
• docker compose stop / up on the cloud cluster keeps the data (instance
  creation, vault default and node registration are all idempotent).
• build.sh -s tarball --tarball-dir <dir> from outside the repository,
  with fe/be/ms extracted from the component images.

Not verified here: amd64 (same caveat as #66983 — the BE does not survive
emulation on an Apple Silicon host).

Notes

• Publishing: the compose files default to apache/doris:all-in-one-4.1.3,
  which on Docker Hub still lacks the meta-service payload and the role-aware
  entrypoint. Once this is merged, the 4.1.3 tags need a rebuild and re-push
  (single-container behaviour is unchanged; the tags gain ~0.2 GB), or the
  default image moves to the next release's tag.
• This is a demo / feature-work environment. The docker() suites under
  regression-test/suites/cloud_p0 still need doris-compose.

🤖 Generated with Claude Code

https://claude.ai/code/session_01CvUCjtaEi5tgy89ABkhgMh

[hello-stephen]

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
3. What features were added. Why was this function added?
4. Which code was refactored and why was this part of the code refactored?
5. Which functions were optimized and what is the difference before and after the optimization?

[morningman]

skip buildall