This is an automated email from the ASF dual-hosted git repository.
morningman pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/doris-website.git
The following commit(s) were added to refs/heads/master by this push:
new b28541fb0fc [doc](community) cover the multi-node and cloud compose
clusters in the all-in-one image guide; withdraw the 4.1.4 arm64 binary (#4133)
b28541fb0fc is described below
commit b28541fb0fc91425ab97c8324af5abd0f72d1ef0
Author: Mingyu Chen (Rayner) <[email protected]>
AuthorDate: Fri Sep 11 23:36:04 2026 +0800
[doc](community) cover the multi-node and cloud compose clusters in the
all-in-one image guide; withdraw the 4.1.4 arm64 binary (#4133)
## What
Two changes:
1. Update the all-in-one image guide (EN + zh-CN) for
[apache/doris#67875](https://github.com/apache/doris/pull/67875), which
taught the 4.1 all-in-one image to run one Doris process per container
via `DORIS_ROLE` and added two compose files under
`docker/runtime/all-in-one/4.1/compose/`.
2. Withdraw the 4.1.4 arm64 binary from the download page — that build
is broken.
## All-in-one image guide
- `community/developer-guide/all-in-one-image.md`
-
`i18n/zh-CN/docusaurus-plugin-content-docs-community/current/developer-guide/all-in-one-image.md`
- Open with a table of the three ways to run the same image — single
container, 3 FE + 3 BE multi-node cluster, compute-storage separated
cluster (FoundationDB + meta-service + recycler + MinIO + 1..3 FE + 3 BE
in two compute groups) — with how each is started and what it is for.
- New "Multi-node and compute-storage separated clusters" section:
`multi-node.yml` / `cloud.yml` commands, topology, host ports, knobs,
data retention (`stop`/`up` keeps, `down` wipes), Docker Desktop routing
(run stream load from the `client` service), memory (~9 GB, give Docker
Desktop 12 GB+), FoundationDB on Apple Silicon, `compose/smoke-test.sh`.
- `DORIS_ROLE` table (`all` / `fe` / `be` / `ms` / `recycler` /
`cloud-init` / `client`) for custom topologies; `FE_MASTER` accepting
several FEs; `FE_HEAP` / `BE_HEAP` and `MS_CONFIG_EXTRA`.
- Image overview: assembled from `fe` / `be` / `ms` images, meta-service
stripped too, sizes 2.7 / 3.2 GB (0.2 GB of which is the meta-service).
- Build section: `-s tarball --tarball-dir`, `-s local` needs a
`--cloud` build to serve the cloud compose file, using a self-built tag
with compose via `DORIS_IMAGE`.
- Single-container content is otherwise kept; the caution now says the
compose clusters are for feature work / demos, not a stand-in for the
regression pipelines.
The `all-in-one-4.1.3` / `-full` tags on Docker Hub were re-pushed right
before #67875 merged, so the compose defaults work out of the box and no
transitional note is needed.
## 4.1.4 arm64 binary
- `src/constant/download.data.ts`: drop the `CPUEnum.ARM64` entry of
4.1.4 (comment left in place to add it back once a fixed build is
published). The "All releases" form derives its architecture list from
the release's `items`, so ARM64 disappears there on its own.
- `src/components/download-form-next/DownloadFormNext.tsx` +
`download-page.scss`: the quick download card hard-codes the three
architecture buttons and used to fall back to the x64 tarball silently
when the selected release had no such build. The button is now disabled
(struck through, with a title saying why) for a release that ships no
build for that architecture; switching to such a release with ARM64
selected resets to x64, as before.
- The `--tarball-dir` example in the guide now points at the x64 package
instead of the withdrawn arm64 one.
## Verification
- Rendered both guide pages with `yarn start` (community plugin only, EN
and `--locale zh-CN`): headings, custom anchors (`#single-container`,
`#multi-node`, `#cloud`), the 6 tables and the two topology diagrams
render as intended; no new console errors beyond the pre-existing
site-wide ones.
- Drove `/download` with `LANDING_ONLY=true yarn start`: on 4.1.4 the
ARM64 button is disabled and clicking it does nothing (file stays
`apache-doris-4.1.4-bin-x64.tar.gz`); 4.0.8 + ARM64 still resolves to
`apache-doris-4.0.8-bin-arm64.tar.gz`; switching back to 4.1.4 with
ARM64 selected resets to x64; the "All releases" Architecture dropdown
for 4.1.4 lists only `x64 ( avx2 )` and `x64 ( no avx2 )`.
---
community/developer-guide/all-in-one-image.md | 162 +++++++++++++++++----
.../current/developer-guide/all-in-one-image.md | 159 ++++++++++++++++----
.../download-form-next/DownloadFormNext.tsx | 35 +++--
.../download-form-next/download-page.scss | 6 +
src/constant/download.data.ts | 12 +-
5 files changed, 294 insertions(+), 80 deletions(-)
diff --git a/community/developer-guide/all-in-one-image.md
b/community/developer-guide/all-in-one-image.md
index aba60bebd25..169e18590c3 100644
--- a/community/developer-guide/all-in-one-image.md
+++ b/community/developer-guide/all-in-one-image.md
@@ -1,8 +1,8 @@
---
-title: All-in-One Image for Integration Testing
+title: "All-in-One Image: Single Container, Multi-Node and Compute-Storage
Separated Clusters"
sidebar_label: All-in-One Image
language: en
-description: The official Apache Doris all-in-one image runs one FE and one BE
in a single container, giving ecosystem projects a real Doris instance for e2e
and CI.
+description: The official Apache Doris all-in-one image runs three ways - one
FE and one BE in a single container as an e2e / CI test fixture, a 3 FE + 3 BE
multi-node cluster via Docker Compose, and a compute-storage separated cluster
with Meta Service, FoundationDB and MinIO for local development and demos. Also
covers image tags, multi-architecture support, configuration and building the
image yourself.
keywords:
- Apache Doris
- all-in-one image
@@ -12,6 +12,9 @@ keywords:
- Docker
- Docker Compose
- GitHub Actions
+ - multi-node cluster
+ - compute-storage separation
+ - compute group
---
<!--
@@ -34,15 +37,21 @@ under the License.
-->
<!-- Knowledge Type: Tool Usage -->
-<!-- Applicable Scenarios: Ecosystem project integration testing / CI
environment setup -->
+<!-- Applicable Scenarios: Ecosystem project integration testing / CI
environment setup / local multi-node and compute-storage separated clusters -->
-Ecosystem projects around Apache Doris — connectors, SDKs, data integration
tools — usually need a real Doris instance in their e2e / CI runs rather than a
mock. The official all-in-one image is built for exactly that: one FE and one
BE in a single container, ready to use on startup, with a health check, so it
can be dropped in as a test fixture.
+The official Apache Doris all-in-one image,
`apache/doris:all-in-one-<version>`, packs the released FE, BE and Meta Service
into one image; the `DORIS_ROLE` environment variable decides what a container
runs at startup. The same image serves three purposes:
-This document describes what the image provides, how to use it, and how to
build it yourself.
+| Mode | How to start | What it is for |
+| --- | --- | --- |
+| **[Single container](#single-container)**<br />1 FE + 1 BE in one container,
healthy in about 20 s | `docker run apache/doris:all-in-one-4.1.3` | An e2e /
CI test fixture for ecosystem projects such as connectors, SDKs and data
integration tools: a real Doris instance instead of a mock |
+| **[Multi-node cluster](#multi-node)**<br />3 FE + 3 BE, one container per
node, healthy in about 35 s | `docker compose -f multi-node.yml up --wait` |
Exercising locally what a single container cannot show: FE election and
failover, three replicas, balancing, decommissioning |
+| **[Compute-storage separated cluster](#cloud)**<br />FoundationDB + Meta
Service + Recycler + MinIO + 1 to 3 FE + 3 BE in 2 compute groups, healthy in
about 50 s | `docker compose -f cloud.yml up --wait` | Local feature work and
demos of the compute-storage separated mode: compute groups, storage vaults, FE
failover in cloud mode, with no external cloud resources |
+
+The single container is meant for CI and needs nothing beyond `docker run`.
The two compose files live under
[`docker/runtime/all-in-one/4.1/compose/`](https://github.com/apache/doris/tree/master/docker/runtime/all-in-one/4.1/compose)
in the main Doris repository and are meant for local feature work and demos.
All three modes carry a health check: `healthy` means the cluster has formed,
so nothing downstream has to poll or `sleep`.
:::caution Note
-This image is a test fixture designed for integration testing: a single FE and
a single BE, one replica, memory settings tuned down for CI runners, and no
data persistence by default. Do not use it for production deployment.
+All three modes are test / development environments, not production
deployments: memory is tuned down to CI runner and workstation sizes, the
single container has a single replica, and nothing is persisted by default. The
multi-node and compute-storage separated clusters are also no stand-in for the
regression pipelines; the `docker()` suites under
`regression-test/suites/cloud_p0` still need `doris-compose`.
:::
@@ -50,30 +59,18 @@ This image is a test fixture designed for integration
testing: a single FE and a
Image tags look like `apache/doris:all-in-one-<version>`, for example
`apache/doris:all-in-one-4.1.3`. Every example below uses 4.1.3 — replace it
with the version you need. For the available tags, see the [apache/doris
repository on Docker
Hub](https://hub.docker.com/r/apache/doris/tags?name=all-in-one).
-The image is assembled from the official `apache/doris:fe-<version>` and
`apache/doris:be-<version>` images, so what runs inside it is the released
artifact itself. Only two things are done for the CI use case: debug info is
stripped from `doris_be` (`.symtab` is kept, so crash backtraces still resolve
function names), and the JNI scanner directories the tag does not need are
removed.
-
-The behaviors that matter for integration testing:
-
-| Feature | Description |
-| --- | --- |
-| Ready to use | FE startup, `ALTER SYSTEM ADD BACKEND` registration of the
BE, and waiting for the BE to come online all happen inside the container. No
external script is involved |
-| Health check | The image ships a `HEALTHCHECK` that turns `healthy` only
once FE is ready and the BE is online, usually within 20 seconds. CI can wait
on that status instead of calling `sleep` |
-| Single replica | `force_olap_table_replication_num = 1` is set, so `CREATE
TABLE` does not need `replication_num` |
-| Bounded resources | Memory is tuned down for CI runners: FE heap
`-Xmx2048m`, the BE-side JNI heap `-Xmx1024m`, and BE `mem_limit = 40%` |
-| Fail-fast | If either FE or BE exits, the container exits non-zero right
away instead of restarting silently, so a failure surfaces immediately in CI |
-| Graceful shutdown | `docker stop` stops BE first, then FE, and exits 0 |
-| Multi-architecture | One tag covers both linux/amd64 and linux/arm64 |
+The image is assembled from the official `apache/doris:fe-<version>`,
`be-<version>` and `ms-<version>` images, so what runs inside it is the
released artifact itself. Only two things are done for size: debug info is
stripped from `doris_be` and from the Meta Service's `doris_cloud` and
`libfdb_c.so` (`.symtab` is kept, so crash backtraces still resolve function
names), and the JNI scanner directories the tag does not need are removed.
### The two tags: base and -full
| Tag | Covers | Image size (4.1.3, uncompressed) |
| --- | --- | --- |
-| `apache/doris:all-in-one-<version>` | Internal tables, Hive, Iceberg
(including system tables), Paimon, JDBC catalogs, external table writeback,
Java UDF | About 2.5 GB |
-| `apache/doris:all-in-one-<version>-full` | Everything above, plus Hudi,
Trino connector, MaxCompute | About 3.0 GB |
+| `apache/doris:all-in-one-<version>` | Internal tables, Hive, Iceberg
(including system tables), Paimon, JDBC catalogs, external table writeback,
Java UDF | About 2.7 GB |
+| `apache/doris:all-in-one-<version>-full` | Everything above, plus Hudi,
Trino connector, MaxCompute | About 3.2 GB |
-The sizes were measured on 4.1.3. For reference, the same payload without
stripping and pruning is about 4.9 GB.
+The sizes are the uncompressed layer sum measured on 4.1.3; about 0.2 GB of
each is the Meta Service, which only the compute-storage separated cluster
uses. For reference, the same payload without stripping and pruning is about
5.6 GB.
-**Only pick `-full` if the tests actually read Hudi tables, go through the
Trino connector, or use MaxCompute.** Otherwise use the tag without the suffix.
+**Only pick `-full` if the tests actually read Hudi tables, go through the
Trino connector, or use MaxCompute.** Otherwise use the tag without the suffix.
None of the three modes requires a particular tag; the compose clusters switch
to `-full` or to a self-built tag through the `DORIS_IMAGE` environment
variable.
The difference between the two tags comes from how BE loads its scanners: at
startup BE enumerates the directories under `be/lib/java_extensions/` to load
JNI scanners. There is no list and no configuration key, so a tag supports
exactly the formats whose directory it ships. Note that Hive and Iceberg
**data** reads go through BE's native parquet / orc reader rather than these
JNI scanners, so both tags support them.
@@ -91,7 +88,21 @@ A Doris BE generally cannot run under cross-architecture
emulation. Starting the
:::
-## Using it in integration tests
+## Single container: an integration test fixture {#single-container}
+
+Ecosystem projects around Apache Doris — connectors, SDKs, data integration
tools — usually need a real Doris instance in their e2e / CI runs rather than a
mock. The single-container mode is built for exactly that: one FE and one BE in
one container, ready to use on startup, so it can be dropped in as a test
fixture.
+
+The behaviors that matter for integration testing:
+
+| Feature | Description |
+| --- | --- |
+| Ready to use | FE startup, `ALTER SYSTEM ADD BACKEND` registration of the
BE, and waiting for the BE to come online all happen inside the container. No
external script is involved |
+| Health check | The image ships a `HEALTHCHECK` that turns `healthy` only
once FE is ready and the BE is online, usually within 20 seconds. CI can wait
on that status instead of calling `sleep` |
+| Single replica | `force_olap_table_replication_num = 1` is set, so `CREATE
TABLE` does not need `replication_num` |
+| Bounded resources | Memory is tuned down for CI runners: FE heap
`-Xmx2048m`, the BE-side JNI heap `-Xmx1024m`, and BE `mem_limit = 40%` |
+| Fail-fast | If either FE or BE exits, the container exits non-zero right
away instead of restarting silently, so a failure surfaces immediately in CI |
+| Graceful shutdown | `docker stop` stops BE first, then FE, and exits 0 |
+| Multi-architecture | One tag covers both linux/amd64 and linux/arm64 |
### Connection information
@@ -157,13 +168,14 @@ jobs:
### Adjusting the configuration
-The image already carries a set of integration-test defaults. To change
something, use the two environment variables below to append configuration
items; they are appended to the end of `fe.conf` and `be.conf` respectively at
startup, and the last assignment wins:
+The image already carries a set of integration-test defaults. To change
something, use the environment variables below; they are written into `fe.conf`
/ `be.conf` at container start, and the last assignment wins:
```shell
docker run -d --name doris \
-p 9030:9030 -p 8030:8030 -p 8040:8040 \
-e BE_CONFIG_EXTRA="mem_limit = 80%" \
-e FE_CONFIG_EXTRA="qe_max_connection = 2048" \
+ -e FE_HEAP=4096m \
apache/doris:all-in-one-4.1.3
```
@@ -171,6 +183,7 @@ docker run -d --name doris \
| --- | --- |
| `FE_CONFIG_EXTRA` | Appended to `fe.conf`. Separate multiple items with
newlines |
| `BE_CONFIG_EXTRA` | Appended to `be.conf`. Separate multiple items with
newlines |
+| `FE_HEAP` / `BE_HEAP` | Override the `-Xmx` of the FE / BE-side JVM, e.g.
`4096m`; the defaults are `2048m` and `1024m` |
**Data persistence**: there is none by default, so the data is gone once the
container is removed, which is usually what CI wants. To keep the data, mount
`/opt/apache-doris/fe/doris-meta` and `/opt/apache-doris/be/storage`. The
startup path is idempotent, so the same data directory can be started again and
again.
@@ -181,23 +194,114 @@ docker run -d --name doris \
- A non-zero container exit means FE or BE died. The log right before the exit
names which one it was and which log file to read.
- Tests handling larger volumes of data may need `vm.max_map_count` raised
**on the host** (`sysctl -w vm.max_map_count=2000000`). It is not a namespaced
sysctl, so the container cannot set it, which is why the image skips
`start_be.sh`'s check for it.
+## Multi-node and compute-storage separated clusters
+
+The two compose files live under `docker/runtime/all-in-one/4.1/compose/` in
the main Doris repository and need Docker Compose v2 (the `docker compose`
subcommand). The image defaults to `apache/doris:all-in-one-4.1.3` and can be
changed through `DORIS_IMAGE`, set as an environment variable or in a `.env`
file next to the compose file; every other knob is passed the same way, and the
header comment of each file lists them all.
+
+```shell
+cd <doris repository>/docker/runtime/all-in-one/4.1/compose
+```
+
+Both files include a `client` service: it turns `healthy` only once every node
is alive, which is what `docker compose up --wait` blocks on. It then idles
inside the cluster network with `mysql` and `curl`, so `docker compose exec
client ...` reaches the cluster.
+
+### Multi-node cluster: multi-node.yml {#multi-node}
+
+```shell
+docker compose -f multi-node.yml up --wait # healthy in about 35 s
+docker compose -f multi-node.yml exec client mysql -uroot -hfe-1 -P9030
+docker compose -f multi-node.yml kill fe-1 # a new master in a few
seconds
+docker compose -f multi-node.yml start fe-1 # rejoins as a follower
+docker compose -f multi-node.yml down # tears the cluster down;
nothing persists
+```
+
+```
+fe-1 ─┬─ fe-2, fe-3
+ ├─ be-1, be-2, be-3
+ └─ client
+```
+
+- `fe-1` bootstraps the cluster and `fe-2`, `fe-3` join as followers;
`FE3_ROLE=observer` turns `fe-3` into an observer.
+- Tables default to three replicas, one per BE, as they would on a real
cluster.
+- Host ports: `9030` / `8030` for `fe-1`, `9031` / `8031` for `fe-2`, `9032` /
`8032` for `fe-3`, and `8040` for the HTTP port of `be-1`.
+- Knobs: `DORIS_IMAGE`, `SUBNET` (default `172.31.81`), the host ports,
`FE_HEAP` (default `1024m`), `BE_MEM_LIMIT` (default `25%`), `FE3_ROLE`.
+
+### Compute-storage separated cluster: cloud.yml {#cloud}
+
+```shell
+docker compose -f cloud.yml up --wait # 1 FE + 3 BE, healthy
in about 50 s
+docker compose -f cloud.yml --profile ha up --wait # ... plus two follower
FEs, 3 FEs in total
+docker compose -f cloud.yml exec client mysql -uroot -hfe-1 -P9030
+docker compose -f cloud.yml down # tears the cluster
down; nothing persists
+```
+
+```
+fdb ─ fdb-init ─┬─ ms ─ cloud-init ─ fe-1 ─┬─ be-1, be-2 (cg_a)
+ └─ recycler ├─ be-3 (cg_b)
+minio ─ minio-init ─┘ └─ client
+```
+
+- Every Doris process (FE, BE, Meta Service, Recycler) runs from the
all-in-one image; FoundationDB and MinIO come from their upstream images.
+- `cloud-init` is a one-shot container that creates the instance on the Meta
Service in storage-vault mode with MinIO as the vault (path-style, plain HTTP);
`fe-1` then marks `built_in_storage_vault` as the default vault, so `CREATE
TABLE` works without naming one. Both steps are idempotent.
+- The three BEs form two compute groups: `be-1` and `be-2` in `cg_a`, `be-3`
in `cg_b`. This gives `use @cg_b`, `SHOW COMPUTE GROUPS`, `ALTER SYSTEM ADD
BACKEND ... ("tag.compute_group_name" = ...)`, storage vaults, warm-up and FE
failover in cloud mode something to run against, and lets you watch objects
land in MinIO.
+- Host ports: `9030` / `8030` for `fe-1` (`9031` / `8031` and `9032` / `8032`
for `fe-2` and `fe-3` under the `ha` profile), `8040` for the HTTP port of
`be-1`, `15000` for the Meta Service HTTP API (`5000` is taken by AirPlay on
macOS), `9000` for MinIO and `9001` for the MinIO console (`minioadmin` /
`minioadmin`).
+- Knobs: `DORIS_IMAGE`, `SUBNET` (default `172.31.80`), the host ports,
`FE_HEAP`, `BE_MEM_LIMIT`, `CG_A` / `CG_B` (compute group names), `INSTANCE_ID`
(default `100001`, also the FEs' `cluster_id`), `S3_BUCKET` / `S3_AK` /
`S3_SK`, `FDB_IMAGE` / `FDB_PLATFORM`.
+- A cluster started with `--profile ha` should be stopped and torn down with
the same flag, so that `fe-2` and `fe-3` from the profile are handled together
with the rest.
+
+### Things to know
+
+- **Keeping data.** `docker compose stop` / `start` (or another `up`) keeps
the data; instance creation, the default vault and node registration are all
idempotent. `down` removes the containers and the network, and the data with
them.
+- **Node addresses.** Nodes get fixed IPs on a private subnet (`SUBNET`,
default `172.31.81` for multi-node and `172.31.80` for cloud), so a restarted
container keeps the identity Doris knows it by. The two files use different
subnets, so both clusters can run at once if one of them is given other host
ports.
+- **From the host.** Use the published ports. On Docker Desktop (macOS /
Windows) the container addresses are not routable from the host, so a stream
load started on the host cannot follow FE's redirect to a BE; run it from the
`client` service instead (`docker compose -f <file> exec client curl ...`).
Linux hosts can reach the nodes directly.
+- **Memory.** Defaults are `FE_HEAP=1024m` and `mem_limit = 25%` per BE. A
full compute-storage separated cluster takes around 9 GB; give Docker Desktop
12 GB or more, and do not expect both topologies to fit side by side on a 16 GB
VM.
+- **FoundationDB on Apple Silicon.** The upstream
`foundationdb/foundationdb:7.1.x` images are amd64 only, so on Apple Silicon
`fdb` runs under emulation, which is fine for this purpose; `FDB_IMAGE` /
`FDB_PLATFORM` switch it out. The Meta Service links the 7.1 client, so stay on
a 7.1 server.
+- **Smoke test.** `compose/smoke-test.sh <multi-node|cloud> [image:tag]`
brings the topology up under its own project name, subnet and host ports,
checks replicas or compute groups and the vault, stream loads through the
client, kills the master FE, restarts a BE while the old master is down, brings
the master back, and tears everything down. About two minutes per topology.
+
+### Container roles: DORIS_ROLE
+
+Both compose files are assembled from the roles of the same image; the
entrypoint dispatches on `DORIS_ROLE` to decide what a container runs. A custom
topology (say 1 FE + 5 BE) can be put together the same way:
+
+| `DORIS_ROLE` | Runs | Required variables |
+| --- | --- | --- |
+| `all` (default) | FE + BE in one container, i.e. the single-container mode |
none |
+| `fe` | One FE. Bootstraps a new cluster when `FE_MASTER` is empty; otherwise
registers as `FE_ROLE` (`follower` \| `observer`) and joins | `FE_MASTER` |
+| `be` | One BE, registered with `FE_MASTER`; in compute-storage separated
mode it joins the compute group named by `COMPUTE_GROUP` | `FE_MASTER` |
+| `ms` / `recycler` | The Meta Service / Recycler of the compute-storage
separated mode | `FDB_CLUSTER` |
+| `cloud-init` | One-shot: creates the compute-storage separated instance on
an S3-compatible object store, then exits | `MS_ENDPOINT`, `INSTANCE_ID`,
`S3_*` |
+| `client` | Waits for `EXPECT_FE` / `EXPECT_BE` live nodes, then idles with
`mysql` and `curl` | `FE_MASTER` |
+
+- `DEPLOY_MODE=cloud` turns `fe` and `be` into compute-storage separated nodes
(`deploy_mode`, `meta_service_endpoint`, file cache and so on are written
automatically); the FE takes `INSTANCE_ID` as its `cluster_id` and manages
nodes by SQL, so no `cloud_unique_id` has to be handed out.
+- `FE_MASTER` may list several FEs (`fe-1,fe-2,fe-3`): the first one that
answers is used, so a node restart does not wait on the one FE that happens to
be down. An FE that already has metadata rejoins on its own.
+- Every role honours `FE_CONFIG_EXTRA` / `BE_CONFIG_EXTRA` / `MS_CONFIG_EXTRA`
and `FE_HEAP` / `BE_HEAP`, and drops a ready flag once it is up, which the
image `HEALTHCHECK` keys on. That is why `docker compose up --wait` blocks
until the whole cluster has formed, and a dead process still turns into a
non-zero container exit.
+- Topology-dependent settings (`priority_networks`, replica count, balancing,
the compute-storage separated keys) are written by the entrypoint per role at
container start; the conf files baked into the image only carry the
size-related defaults.
+
## Building the image yourself
The Dockerfile and the build script live under
`docker/runtime/all-in-one/<release-line>/` in the main Doris repository, where
`4.1` is currently available. Release lines differ enough in artifact layout
that each gets its own directory instead of a version switch inside a single
Dockerfile.
-`build.sh` is the only entry point. The build context is always the repository
root, and the script itself can be run from any directory:
+`build.sh` is the only entry point, and the script itself can be run from any
directory:
```shell
# Build both the base and the -full tag from the official 4.1.3 component
images
-# (host architecture only)
+# (fe / be / ms), host architecture only
./build.sh -v 4.1.3
# Build base only, then run a smoke test against it
./build.sh -v 4.1.3 -f base -t
-# Build from a local ./output, which is handy for verifying your own changes
-# Requires a completed Doris build producing ./output/fe and ./output/be
+# Build from a local ./output, which is handy for verifying your own changes.
+# Build Doris with build.sh --fe --be --cloud first; without --cloud there is
no
+# ./output/ms and the resulting image cannot serve the compute-storage
separated cluster
./build.sh -v dev -s local
+
+# Build from an extracted release tarball, e.g. while the component images of a
+# new release are not on Docker Hub yet
+./build.sh -v 4.1.4 -s tarball --tarball-dir ~/apache-doris-4.1.4-bin-x64
+```
+
+The build context is always the repository root (narrowed to a few KB by
`Dockerfile.dockerignore`); a local `./output` or a tarball directory is passed
as BuildKit named contexts, so it can live anywhere, but this needs `docker
buildx`. A self-built image can be used with both compose files directly:
+
+```shell
+DORIS_IMAGE=apache/doris:all-in-one-dev docker compose -f multi-node.yml up
--wait
```
Without `--platform`, only the host architecture is built. Multi-architecture
builds need it spelled out, for example `./build.sh -v 4.1.3 --platform
linux/amd64,linux/arm64 --push`. Since a cross-architecture build goes through
emulation and takes a long time, building each architecture natively on its own
machine and then joining the results with `docker buildx imagetools create` is
the better choice for a release.
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs-community/current/developer-guide/all-in-one-image.md
b/i18n/zh-CN/docusaurus-plugin-content-docs-community/current/developer-guide/all-in-one-image.md
index 571230ae64e..363c3411708 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs-community/current/developer-guide/all-in-one-image.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs-community/current/developer-guide/all-in-one-image.md
@@ -1,8 +1,8 @@
---
-title: 集成测试用 all-in-one 镜像
+title: All-in-One 镜像：单容器、多节点与存算分离集群
sidebar_label: All-in-One 镜像
language: zh-CN
-description: 介绍 Apache Doris 官方 all-in-one 容器镜像，它在单个容器中运行一套 FE + BE，可供上下游生态项目在
e2e / CI 中作为真实 Doris 环境使用，并说明镜像能力、base 与 -full 标签的差异、多架构支持以及自行构建方式。
+description: 介绍 Apache Doris 官方 all-in-one 容器镜像的三种用法：单容器 FE + BE 作为 e2e / CI
测试夹具；通过 Docker Compose 拉起 3 FE + 3 BE 多节点集群；以及拉起带 Meta Service、FoundationDB 和
MinIO 的存算分离集群用于本地开发与演示。同时说明镜像标签、多架构支持、配置方式与自行构建方法。
keywords:
- Apache Doris
- all-in-one 镜像
@@ -12,6 +12,9 @@ keywords:
- Docker
- Docker Compose
- GitHub Actions
+ - 多节点集群
+ - 存算分离
+ - 计算组
---
<!--
@@ -34,15 +37,21 @@ under the License.
-->
<!-- 知识类型: 工具使用 -->
-<!-- 适用场景: 生态项目集成测试 / CI 环境搭建 -->
+<!-- 适用场景: 生态项目集成测试 / CI 环境搭建 / 本地多节点与存算分离集群 -->
-Connector、SDK、数据集成工具等 Apache Doris 上下游项目，在 e2e / CI 中往往需要一个真实的 Doris 实例，而不是
Mock。为此 Doris 官方提供了 all-in-one 镜像：单个容器内跑一套 FE + BE，启动即可用，带健康检查，可以直接当作测试夹具（test
fixture）使用。
+Apache Doris 官方提供 all-in-one 镜像 `apache/doris:all-in-one-<version>`，把正式发布的
FE、BE 和 Meta Service 打进同一个镜像，容器启动时由 `DORIS_ROLE` 环境变量决定里面跑什么。同一个镜像有三种用法：
-本文介绍这个镜像的能力和用法，以及如何自行构建它。
+| 用法 | 启动方式 | 适用场景 |
+| --- | --- | --- |
+| **[单容器](#single-container)**<br />1 FE + 1 BE，同一容器内，约 20 秒就绪 | `docker run
apache/doris:all-in-one-4.1.3` | Connector、SDK、数据集成工具等生态项目的 e2e / CI 测试夹具，用真实
Doris 实例代替 Mock |
+| **[多节点集群](#multi-node)**<br />3 FE + 3 BE，每个节点一个容器，约 35 秒就绪 | `docker
compose -f multi-node.yml up --wait` | 本地验证 FE
选举与故障切换、三副本、均衡、节点下线等单容器覆盖不了的多节点行为 |
+| **[存算分离集群](#cloud)**<br />FoundationDB + Meta Service + Recycler + MinIO +
1～3 FE + 3 BE（2 个计算组），约 50 秒就绪 | `docker compose -f cloud.yml up --wait` |
本地开发和演示存算分离特性：计算组、存储 Vault、云模式下的 FE 故障切换等，不依赖任何外部云资源 |
+
+单容器模式面向 CI，`docker run` 即可用；两个 Compose 文件位于 Doris 主仓库的
[`docker/runtime/all-in-one/4.1/compose/`](https://github.com/apache/doris/tree/master/docker/runtime/all-in-one/4.1/compose)
下，面向本地功能开发与演示。三种用法都带健康检查，`healthy` 即代表集群已经成形，不需要外部脚本轮询或 `sleep`。
:::caution 注意
-这个镜像是为集成测试设计的测试夹具：单 FE 单 BE、单副本、内存参数按 CI runner 调小、默认不持久化数据。请勿用于生产部署。
+三种用法都是测试 / 开发环境，不是生产部署：内存参数按 CI runner
和开发机的规格调小，单容器只有单副本，默认都不持久化数据。多节点和存算分离集群也不能替代回归测试流水线，`regression-test/suites/cloud_p0`
下的 `docker()` 用例仍然需要 `doris-compose`。
:::
@@ -50,30 +59,18 @@ Connector、SDK、数据集成工具等 Apache Doris 上下游项目，在 e2e /
镜像标签形如 `apache/doris:all-in-one-<version>`，例如
`apache/doris:all-in-one-4.1.3`。本文所有示例都以 4.1.3 为例，换成你需要的版本即可；可用标签见 [Docker Hub
上的 apache/doris 仓库](https://hub.docker.com/r/apache/doris/tags?name=all-in-one)。
-镜像由官方的 `apache/doris:fe-<version>` 和 `apache/doris:be-<version>`
组装而成，里面跑的就是正式发布的产物本身，只针对 CI 场景做了两处处理：对 `doris_be` 剥离调试信息（保留
`.symtab`，崩溃堆栈仍能解析出函数名），以及裁掉当前标签用不到的 JNI scanner 目录。
-
-面向集成测试的几个关键行为：
-
-| 特性 | 说明 |
-| --- | --- |
-| 开箱即用 | 容器内部已完成 FE 启动、`ALTER SYSTEM ADD BACKEND` 注册 BE、等待 BE 上线的全过程，不需要外部脚本介入
|
-| 健康检查 | 镜像自带 `HEALTHCHECK`，只有 FE 就绪且 BE 已上线时才会变为 `healthy`，通常在 20 秒内完成。CI
里直接等这个状态即可，不需要 `sleep` |
-| 单副本 | 已设置 `force_olap_table_replication_num = 1`，`CREATE TABLE` 不必再写
`replication_num` |
-| 资源可控 | 按 CI runner 的规格调小了内存：FE 堆 `-Xmx2048m`，BE 侧 JNI 堆 `-Xmx1024m`，BE
`mem_limit = 40%` |
-| fail-fast | FE 或 BE 任一进程退出，容器随即以非零状态退出，不会静默重启，故障会立刻在 CI 中暴露出来 |
-| 优雅停止 | `docker stop` 会先停 BE 再停 FE，正常退出 0 |
-| 多架构 | 同一个标签同时覆盖 linux/amd64 和 linux/arm64 |
+镜像由官方的 `apache/doris:fe-<version>`、`be-<version>` 和 `ms-<version>`
组装而成，里面跑的就是正式发布的产物本身，只针对体积做了两处处理：对 `doris_be` 以及 Meta Service 的
`doris_cloud`、`libfdb_c.so` 剥离调试信息（保留 `.symtab`，崩溃堆栈仍能解析出函数名），以及裁掉当前标签用不到的 JNI
scanner 目录。
### 两个标签：base 与 -full
| 标签 | 覆盖能力 | 镜像体积（4.1.3，未压缩） |
| --- | --- | --- |
-| `apache/doris:all-in-one-<version>` | 内表、Hive、Iceberg（含系统表）、Paimon、JDBC
Catalog、外表写回、Java UDF | 约 2.5 GB |
-| `apache/doris:all-in-one-<version>-full` | 在上述基础上增加 Hudi、Trino
Connector、MaxCompute | 约 3.0 GB |
+| `apache/doris:all-in-one-<version>` | 内表、Hive、Iceberg（含系统表）、Paimon、JDBC
Catalog、外表写回、Java UDF | 约 2.7 GB |
+| `apache/doris:all-in-one-<version>-full` | 在上述基础上增加 Hudi、Trino
Connector、MaxCompute | 约 3.2 GB |
-体积是在 4.1.3 上实测的，作为参照，未经剥离和裁剪的等价负载约为 4.9 GB。
+体积是在 4.1.3 上实测的各层未压缩之和，其中约 0.2 GB 是 Meta
Service，只有存算分离集群会用到；作为参照，未经剥离和裁剪的等价负载约为 5.6 GB。
-**只有测试确实要读 Hudi 表、走 Trino Connector 或 MaxCompute 时才需要 `-full`**，其余场景用不带后缀的标签即可。
+**只有测试确实要读 Hudi 表、走 Trino Connector 或 MaxCompute 时才需要
`-full`**，其余场景用不带后缀的标签即可。三种用法对标签没有要求，Compose 集群通过 `DORIS_IMAGE` 环境变量换用 `-full`
或自行构建的标签。
两个标签的差异来自 BE 的加载方式：BE 启动时通过枚举 `be/lib/java_extensions/` 下的目录来加载 JNI
scanner，既没有列表也没有配置项，因此镜像里保留了哪些目录，就支持哪些格式。需要注意的是，Hive 和 Iceberg 的**数据**读取走的是 BE
原生的 parquet / orc reader，不属于这套 JNI scanner，因此两个标签都支持。
@@ -91,7 +88,21 @@ Doris BE 通常无法在跨架构模拟下运行。例如在 Apple Silicon 上
:::
-## 在集成测试中使用
+## 单容器：集成测试夹具 {#single-container}
+
+Connector、SDK、数据集成工具等 Apache Doris 上下游项目，在 e2e / CI 中往往需要一个真实的 Doris 实例，而不是
Mock。单容器模式就是为此设计的：容器内跑一套 FE + BE，启动即可用，可以直接当作测试夹具（test fixture）使用。
+
+面向集成测试的几个关键行为：
+
+| 特性 | 说明 |
+| --- | --- |
+| 开箱即用 | 容器内部已完成 FE 启动、`ALTER SYSTEM ADD BACKEND` 注册 BE、等待 BE 上线的全过程，不需要外部脚本介入
|
+| 健康检查 | 镜像自带 `HEALTHCHECK`，只有 FE 就绪且 BE 已上线时才会变为 `healthy`，通常在 20 秒内完成。CI
里直接等这个状态即可，不需要 `sleep` |
+| 单副本 | 已设置 `force_olap_table_replication_num = 1`，`CREATE TABLE` 不必再写
`replication_num` |
+| 资源可控 | 按 CI runner 的规格调小了内存：FE 堆 `-Xmx2048m`，BE 侧 JNI 堆 `-Xmx1024m`，BE
`mem_limit = 40%` |
+| fail-fast | FE 或 BE 任一进程退出，容器随即以非零状态退出，不会静默重启，故障会立刻在 CI 中暴露出来 |
+| 优雅停止 | `docker stop` 会先停 BE 再停 FE，正常退出 0 |
+| 多架构 | 同一个标签同时覆盖 linux/amd64 和 linux/arm64 |
### 连接信息
@@ -157,13 +168,14 @@ jobs:
### 调整配置
-镜像里已经是一套面向集成测试的默认配置。需要改动时，用下面两个环境变量追加配置项，它们会在启动时分别附加到 `fe.conf` 和 `be.conf`
的末尾（后写的赋值生效）：
+镜像里已经是一套面向集成测试的默认配置。需要改动时，用下面的环境变量覆盖，它们会在容器启动时写入 `fe.conf` /
`be.conf`（后写的赋值生效）：
```shell
docker run -d --name doris \
-p 9030:9030 -p 8030:8030 -p 8040:8040 \
-e BE_CONFIG_EXTRA="mem_limit = 80%" \
-e FE_CONFIG_EXTRA="qe_max_connection = 2048" \
+ -e FE_HEAP=4096m \
apache/doris:all-in-one-4.1.3
```
@@ -171,6 +183,7 @@ docker run -d --name doris \
| --- | --- |
| `FE_CONFIG_EXTRA` | 追加到 `fe.conf`，多行配置用换行分隔 |
| `BE_CONFIG_EXTRA` | 追加到 `be.conf`，多行配置用换行分隔 |
+| `FE_HEAP` / `BE_HEAP` | 覆盖 FE / BE 侧 JVM 的 `-Xmx`，如 `4096m`；默认分别为 `2048m` 和
`1024m` |
**数据持久化**：默认不持久化，容器销毁后数据即消失，这通常正是 CI 想要的。需要保留数据时，挂载
`/opt/apache-doris/fe/doris-meta` 和 `/opt/apache-doris/be/storage`
即可，启动流程是幂等的，同一份数据目录可以反复拉起。
@@ -181,22 +194,112 @@ docker run -d --name doris \
- 容器非零退出，说明 FE 或 BE 挂了，退出前的日志里会指明是哪一个以及去看哪个日志文件。
- 数据量较大的测试可能需要在**宿主机**上调大 `vm.max_map_count`（`sysctl -w
vm.max_map_count=2000000`）。这不是 namespace 化的 sysctl，容器内改不了，因此镜像里跳过了
`start_be.sh` 对它的检查。
+## 多节点与存算分离集群
+
+两个 Compose 文件位于 Doris 主仓库的 `docker/runtime/all-in-one/4.1/compose/` 下，需要
Docker Compose v2（`docker compose` 子命令）。镜像默认为
`apache/doris:all-in-one-4.1.3`，可以通过环境变量或同目录下的 `.env` 文件里的 `DORIS_IMAGE`
更换，其他可调参数也都以同样方式传入，每个文件的头部注释里有完整列表。
+
+```shell
+cd <doris 仓库>/docker/runtime/all-in-one/4.1/compose
+```
+
+两个文件都带一个 `client` 服务：所有节点上线后它才变为 `healthy`，`docker compose up --wait`
等的就是它；之后它常驻在集群网络内，自带 `mysql` 和 `curl`，`docker compose exec client ...` 即可访问集群。
+
+### 多节点集群：multi-node.yml {#multi-node}
+
+```shell
+docker compose -f multi-node.yml up --wait # 约 35 秒后集群就绪
+docker compose -f multi-node.yml exec client mysql -uroot -hfe-1 -P9030
+docker compose -f multi-node.yml kill fe-1 # 几秒后选出新的 Master
+docker compose -f multi-node.yml start fe-1 # 以 Follower 身份重新加入
+docker compose -f multi-node.yml down # 销毁集群，数据不保留
+```
+
+```
+fe-1 ─┬─ fe-2, fe-3
+ ├─ be-1, be-2, be-3
+ └─ client
+```
+
+- `fe-1` 引导集群，`fe-2`、`fe-3` 以 Follower 身份加入；设置 `FE3_ROLE=observer` 可把 `fe-3`
改为 Observer。
+- 建表默认三副本，每个 BE 一份，和真实集群一致。
+- 宿主机端口：`fe-1` 为 `9030` / `8030`，`fe-2` 为 `9031` / `8031`，`fe-3` 为 `9032` /
`8032`，`be-1` 的 HTTP 端口为 `8040`。
+- 可调参数：`DORIS_IMAGE`、`SUBNET`（默认 `172.31.81`）、各宿主机端口、`FE_HEAP`（默认
`1024m`）、`BE_MEM_LIMIT`（默认 `25%`）、`FE3_ROLE`。
+
+### 存算分离集群：cloud.yml {#cloud}
+
+```shell
+docker compose -f cloud.yml up --wait # 1 FE + 3 BE，约 50 秒后就绪
+docker compose -f cloud.yml --profile ha up --wait # 再加两个 Follower FE，共 3
FE
+docker compose -f cloud.yml exec client mysql -uroot -hfe-1 -P9030
+docker compose -f cloud.yml down # 销毁集群，数据不保留
+```
+
+```
+fdb ─ fdb-init ─┬─ ms ─ cloud-init ─ fe-1 ─┬─ be-1, be-2 (计算组 cg_a)
+ └─ recycler ├─ be-3 (计算组 cg_b)
+minio ─ minio-init ─┘ └─ client
+```
+
+- 所有 Doris 进程（FE、BE、Meta Service、Recycler）都来自 all-in-one 镜像，FoundationDB 和
MinIO 使用各自的上游镜像。
+- `cloud-init` 是一次性容器，以 Storage Vault 模式在 Meta Service 上创建实例，MinIO 作为
Vault（path-style，明文 HTTP）；`fe-1` 启动后把 `built_in_storage_vault` 设为默认 Vault，因此
`CREATE TABLE` 不需要额外指定。两步都是幂等的。
+- 三个 BE 分属两个计算组：`be-1`、`be-2` 在 `cg_a`，`be-3` 在 `cg_b`。可以直接试 `use @cg_b`、`SHOW
COMPUTE GROUPS`、`ALTER SYSTEM ADD BACKEND ... ("tag.compute_group_name" =
...)`、存储 Vault、预热，以及云模式下的 FE 故障切换，还能在 MinIO 里观察对象写入。
+- 宿主机端口：`fe-1` 为 `9030` / `8030`（`ha` profile 下 `fe-2`、`fe-3` 为 `9031` /
`8031`、`9032` / `8032`），`be-1` 的 HTTP 端口为 `8040`，Meta Service HTTP API 为
`15000`（macOS 上 `5000` 被 AirPlay 占用），MinIO 为 `9000`，MinIO 控制台为
`9001`（`minioadmin` / `minioadmin`）。
+- 可调参数：`DORIS_IMAGE`、`SUBNET`（默认
`172.31.80`）、各宿主机端口、`FE_HEAP`、`BE_MEM_LIMIT`、`CG_A` /
`CG_B`（计算组名）、`INSTANCE_ID`（默认 `100001`，同时是 FE 的 `cluster_id`）、`S3_BUCKET` /
`S3_AK` / `S3_SK`、`FDB_IMAGE` / `FDB_PLATFORM`。
+- 用 `--profile ha` 启动的集群，后续的 `stop` / `down` 也带上同样的参数，profile 里的 `fe-2`、`fe-3`
才会一起处理。
+
+### 使用须知
+
+- **数据保留**：`docker compose stop` / `start`（或再次 `up`）会保留数据，实例创建、默认 Vault
和节点注册都是幂等的；`down` 会删除容器和网络，数据随之清空。
+- **节点地址**：节点在私有子网内使用固定 IP（`SUBNET`，multi-node 默认 `172.31.81`，cloud 默认
`172.31.80`），容器重启后 Doris 仍按原地址识别它。两套集群子网不同，只要给其中一套换一组宿主机端口，就可以同时运行。
+- **从宿主机访问**：使用映射出来的端口。在 Docker Desktop（macOS /
Windows）上，容器地址在宿主机上不可路由，因此从宿主机发起的 Stream Load 无法跟随 FE 到 BE 的重定向；请改在 `client`
服务内执行（`docker compose -f <file> exec client curl ...`）。Linux 宿主机可以直接访问各节点。
+- **内存**：默认 `FE_HEAP=1024m`，每个 BE `mem_limit = 25%`。一套完整的存算分离集群约占 9 GB
内存，Docker Desktop 请分配 12 GB 以上；16 GB 的虚拟机不要指望两套拓扑同时跑。
+- **Apple Silicon 上的 FoundationDB**：上游 `foundationdb/foundationdb:7.1.x` 镜像只有
amd64 版本，在 Apple Silicon 上 `fdb` 会通过模拟运行，对这个用途来说足够；`FDB_IMAGE` / `FDB_PLATFORM`
可以换用其他镜像。Meta Service 链接的是 7.1 客户端，服务端请保持 7.1。
+- **冒烟测试**：`compose/smoke-test.sh <multi-node|cloud> [image:tag]` 会用独立的
project 名、子网和宿主机端口拉起对应拓扑，检查副本或计算组与 Vault，通过 client 做 Stream Load，杀掉 Master
FE、在旧 Master 宕机期间重启一个 BE、再恢复 Master，最后清理，每个拓扑约两分钟。
+
+### 容器角色：DORIS_ROLE
+
+两个 Compose 文件都是用同一个镜像的不同角色拼出来的，镜像的 entrypoint 根据 `DORIS_ROLE`
决定容器里运行什么。需要自定义拓扑（例如 1 FE + 5 BE）时，可以按同样的方式组合：
+
+| `DORIS_ROLE` | 运行内容 | 必需变量 |
+| --- | --- | --- |
+| `all`（默认） | 同一容器内的 FE + BE，即单容器模式 | 无 |
+| `fe` | 一个 FE。`FE_MASTER` 为空时引导新集群；否则以 `FE_ROLE`（`follower` \|
`observer`）注册并加入 | `FE_MASTER` |
+| `be` | 一个 BE，向 `FE_MASTER` 注册；存算分离模式下加入 `COMPUTE_GROUP` 指定的计算组 | `FE_MASTER`
|
+| `ms` / `recycler` | 存算分离的 Meta Service / Recycler | `FDB_CLUSTER` |
+| `cloud-init` | 一次性任务：在 S3 兼容对象存储上创建存算分离实例，然后退出 |
`MS_ENDPOINT`、`INSTANCE_ID`、`S3_*` |
+| `client` | 等待 `EXPECT_FE` / `EXPECT_BE` 个节点在线后常驻，提供 `mysql` 和 `curl` |
`FE_MASTER` |
+
+- `DEPLOY_MODE=cloud` 把 `fe` 和 `be` 变成存算分离节点（自动写入
`deploy_mode`、`meta_service_endpoint`、file cache 等配置）；FE 以 `INSTANCE_ID` 作为
`cluster_id` 并通过 SQL 管理节点，不需要手工分配 `cloud_unique_id`。
+- `FE_MASTER` 可以列出多个 FE（如 `fe-1,fe-2,fe-3`），使用第一个有响应的，这样某个节点重启时不会卡在恰好宕机的那个 FE
上；已有元数据的 FE 会自行重新加入集群。
+- 所有角色都支持 `FE_CONFIG_EXTRA` / `BE_CONFIG_EXTRA` / `MS_CONFIG_EXTRA` 和
`FE_HEAP` / `BE_HEAP`，就绪后写入 ready 标记，镜像的 `HEALTHCHECK` 据此判断健康状态，所以 `docker
compose up --wait` 会一直阻塞到整个集群成形；任一进程退出，容器同样以非零状态退出。
+- `priority_networks`、副本数、均衡、存算分离相关的拓扑配置由 entrypoint
在容器启动时按角色写入，镜像里烘焙的配置文件只保留与资源规格有关的默认值。
+
## 自行构建镜像
Dockerfile 和构建脚本位于 Doris 主仓库的 `docker/runtime/all-in-one/<版本线>/` 下，目前提供
`4.1`。各版本线的产物布局差异较大，因此按版本线分目录，而不是在一份 Dockerfile 里做版本开关。
-`build.sh` 是唯一的入口，构建上下文固定为仓库根目录，脚本本身可以在任意目录下执行：
+`build.sh` 是唯一的入口，脚本本身可以在任意目录下执行：
```shell
-# 用官方 4.1.3 组件镜像构建 base 和 -full 两个标签（仅宿主机架构）
+# 用官方 4.1.3 组件镜像（fe / be / ms）构建 base 和 -full 两个标签（仅宿主机架构）
./build.sh -v 4.1.3
# 只构建 base，并跑一遍冒烟测试
./build.sh -v 4.1.3 -f base -t
# 用本地编译产物 ./output 构建，便于验证自己修改过的内核
-# 需先完成 Doris 编译，产出 ./output/fe 和 ./output/be
+# 需先用 build.sh --fe --be --cloud 完成 Doris 编译；不带 --cloud 就没有 ./output/ms，
+# 构建出的镜像无法用于存算分离集群
./build.sh -v dev -s local
+
+# 用解压后的发行包构建，例如新版本的组件镜像还没上 Docker Hub 时
+./build.sh -v 4.1.4 -s tarball --tarball-dir ~/apache-doris-4.1.4-bin-x64
+```
+
+构建上下文固定为仓库根目录（由 `Dockerfile.dockerignore` 裁到几 KB），本地 `./output` 或发行包目录以
BuildKit 命名上下文（named context）的方式传入，因此可以放在任意位置，但需要 `docker
buildx`。自行构建的镜像可以直接用于两个 Compose 文件：
+
+```shell
+DORIS_IMAGE=apache/doris:all-in-one-dev docker compose -f multi-node.yml up
--wait
```
不带 `--platform` 时只构建宿主机架构。多架构需要显式指定，例如 `./build.sh -v 4.1.3 --platform
linux/amd64,linux/arm64 --push`。跨架构构建走模拟，耗时很长，因此发布时更推荐在各架构的机器上分别构建，再用 `docker
buildx imagetools create` 合并成一个标签。
diff --git a/src/components/download-form-next/DownloadFormNext.tsx
b/src/components/download-form-next/DownloadFormNext.tsx
index c9e104875d6..f7d73b36680 100644
--- a/src/components/download-form-next/DownloadFormNext.tsx
+++ b/src/components/download-form-next/DownloadFormNext.tsx
@@ -175,20 +175,27 @@ export default function DownloadFormNext(): JSX.Element {
'is-muted': isSource,
})}
>
- {CPU_OPTIONS.map(option => (
- <button
- type="button"
- key={option}
- disabled={isSource}
- aria-pressed={cpu === option}
-
className={clsx('download-next__seg-item', {
- 'is-checked': cpu === option,
- })}
- onClick={() => setCpu(option)}
- >
- {option}
- </button>
- ))}
+ {CPU_OPTIONS.map(option => {
+ // A release may ship fewer builds
than there are buttons,
+ // e.g. when one architecture's binary
has been withdrawn.
+ const available = builds.some(item =>
item.value === option);
+ return (
+ <button
+ type="button"
+ key={option}
+ disabled={isSource ||
!available}
+ aria-pressed={cpu === option}
+ title={available ? undefined :
`No ${option} build for ${version}`}
+
className={clsx('download-next__seg-item', {
+ 'is-checked': cpu ===
option,
+ 'is-unavailable':
!available,
+ })}
+ onClick={() => setCpu(option)}
+ >
+ {option}
+ </button>
+ );
+ })}
</div>
</div>
diff --git a/src/components/download-form-next/download-page.scss
b/src/components/download-form-next/download-page.scss
index 855b5c4733d..3f71199ecd6 100644
--- a/src/components/download-form-next/download-page.scss
+++ b/src/components/download-form-next/download-page.scss
@@ -354,6 +354,12 @@
&:disabled {
cursor: not-allowed;
}
+
+ // The selected release ships no build for this architecture.
+ &.is-unavailable {
+ opacity: 0.45;
+ text-decoration: line-through;
+ }
}
.download-next__seg-tag {
diff --git a/src/constant/download.data.ts b/src/constant/download.data.ts
index f806178bd26..a7229599016 100644
--- a/src/constant/download.data.ts
+++ b/src/constant/download.data.ts
@@ -113,15 +113,9 @@ export const ALL_VERSIONS: AllVersionOption[] = [
source:
'https://dist.apache.org/repos/dist/release/doris/4.1/4.1.4/',
version: '4.1.4-rc04',
},
- {
- label: CPUEnum.ARM64,
- value: CPUEnum.ARM64,
- gz: `${ORIGIN}apache-doris-4.1.4-bin-arm64.tar.gz`,
- asc:
`${ORIGIN}apache-doris-4.1.4-bin-arm64.tar.gz.asc`,
- sha512:
`${ORIGIN}apache-doris-4.1.4-bin-arm64.tar.gz.sha512`,
- source:
'https://dist.apache.org/repos/dist/release/doris/4.1/4.1.4/',
- version: '4.1.4-rc04',
- },
+ // The 4.1.4 arm64 binary was withdrawn because the build
is
+ // broken; add the CPUEnum.ARM64 entry back once a fixed
+ // build is published.
],
},
{
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
