Add initial docker-compose implementation

.dockerignore

@@ -0,0 +1,6 @@
+target/
+.git/
+.ruff_cache/
+.vscode/
+services/ws-server/storage/
+**/.DS_Store

README.md

@@ -101,13 +101,28 @@ command to start the demo scenario:
 mise run generated-scenario
 ```
 
+To generate a Docker Compose deployment instead, pass
+`--output-type docker-compose` or set `deployment_type: docker-compose` in the
+scenario input YAML. This writes `compose.yaml` to the output directory:
+
+```bash
+et-cli generate-deployment \
+  --input-file verification/local/input/facility-security-scenario.yaml \
+  --output-dir verification/local/output/facility-security-scenario \
+  --output-type docker-compose
+cd verification/local/output/facility-security-scenario
+docker compose up --build
+```
+
 The generated scenario config only selects which prebuilt modules `ws-server`
 serves. Module builds are expected to be handled separately from the repository
 root.
 
 To regenerate all checked-in verification outputs from
 `verification/*/input`, writing each scenario to
-the matching `verification/*/output/<input-file-stem>` folder:
+the matching `verification/*/output/<input-file-stem>` folder. This generates
+all supported deployment files for each scenario, currently `mise.toml` and
+`compose.yaml`:
 
 ```bash
 mise run regen-verification

services/ws-server/Dockerfile

@@ -0,0 +1,43 @@
+FROM rust:1-bookworm AS builder
+
+RUN apt-get update \
+    && apt-get install -y --no-install-recommends \
+        ca-certificates \
+        clang \
+        cmake \
+        npm \
+        pkg-config \
+        protobuf-compiler \
+    && rm -rf /var/lib/apt/lists/*
+
+WORKDIR /workspace
+
+COPY . .
+
+RUN npm install --omit=dev --prefix /workspace/runtime-deps onnxruntime-web
+RUN cargo build -p et-ws-server --release --locked
+
+FROM debian:bookworm-slim AS runtime
+
+RUN apt-get update \
+    && apt-get install -y --no-install-recommends ca-certificates \
+    && rm -rf /var/lib/apt/lists/* \
+    && useradd --create-home --uid 10001 --user-group app
+
+WORKDIR /app
+
+COPY --from=builder /workspace/target/release/et-ws-server /usr/local/bin/et-ws-server
+COPY --from=builder /workspace/services/ws-server/static ./services/ws-server/static
+COPY --from=builder /workspace/services/ws-wasm-agent/pkg ./services/ws-wasm-agent/pkg
+COPY --from=builder /workspace/services/ws-modules ./services/ws-modules
+COPY --from=builder /workspace/data/model-modules ./data/model-modules
+COPY --from=builder /workspace/runtime-deps/node_modules/onnxruntime-web ./node_modules/onnxruntime-web
+
+RUN mkdir -p /app/storage \
+    && chown -R app:app /app
+
+USER app
+
+EXPOSE 8080 8443
+
+CMD ["et-ws-server"]

utilities/cli/README.md

@@ -43,21 +43,50 @@ the scenario's selected workflow modules plus `ws-wasm-agent`, using the
 configurable module-path logic in `ws-server`. The generated `mise.toml` does
 not build modules; it assumes builds are handled externally.
 
+## Generate a Docker Compose Deployment
+
+Run `generate-deployment` with `--output-type docker-compose` to generate a
+`compose.yaml` file:
+
+```bash
+et-cli generate-deployment \
+  --input-file verification/local/input/<some-scenario>.yaml \
+  --output-dir verification/local/output/<some-scenario> \
+  --output-type docker-compose
+```
+
+Then, to run the deployment from the output directory:
+
+```bash
+docker compose up --build
+```
+
+The generated compose stack starts OpenObserve and builds `ws-server` from the
+repository Dockerfile. Native build dependencies such as `protoc` are installed
+in the image build stage, so the runtime container does not depend on host Rust,
+Cargo caches, or `mise` tools. The generated service sets `MODULES_PATHS`,
+OpenTelemetry auth, and the in-compose OpenObserve collector URL for the
+selected scenario.
+
 ## Regenerate Verification Outputs
 
 Run `regen-verification` to regenerate all checked-in verification outputs from
-the verification root. By default it reads `verification`, discovers
-scenario files under `verification/*/input`, and writes each output set to the
-matching `verification/*/output/<input-file-stem>` folder.
+the verification root. By default it reads `verification`, discovers scenario
+files under `verification/*/input`, and writes every supported deployment type
+to the matching `verification/*/output/<input-file-stem>` folder.
+
+Currently this writes both `mise.toml` and `compose.yaml`. Future deployment
+types should be added to the shared supported output type list so
+`regen-verification` picks them up automatically.
 
 ```bash
 et-cli regen-verification
 ```
 
 For example, `verification/local/input/facility-security-scenario.yaml`
-regenerates into `verification/local/output/facility-security-scenario`, and a
-scenario under `verification/ci/input/...` would regenerate into
-`verification/ci/output/...`.
+regenerates all deployment outputs into
+`verification/local/output/facility-security-scenario`, and a scenario under
+`verification/ci/input/...` would regenerate into `verification/ci/output/...`.
 
 ## Input YAML
 
@@ -82,22 +111,21 @@ Required fields:
 
 Optional fields:
 
-- `deployment_type`: currently only `mise`; defaults to `mise` when omitted.
+- `deployment_type`: `mise` or `docker-compose`; defaults to `mise` when
+  omitted.
 
-The generated `mise.toml` uses `agents[].resources[].type` values to decide
-which module directories to expose through `MODULES_PATHS`. It only serves
-`ws-wasm-agent` and the selected workflow modules for that scenario, without
-adding any build tasks.
+The generated deployment config uses `agents[].resources[].type` values to
+decide which module directories to expose through `MODULES_PATHS`. It only
+serves `ws-wasm-agent` and the selected workflow modules for that scenario,
+without adding any module build tasks.
 
 #### Notes on deployment_type
 
-The input YAML can also choose the output type with `deployment_type`. `mise` is
-the only supported value for now; the field and CLI option are present so more
-deployment types can be added later.
+The input YAML can also choose the output type with `deployment_type`.
 
 ```yaml
 cluster_name: example
-deployment_type: mise
+deployment_type: docker-compose
 agents:
   - name: camera
     resources:
@@ -115,7 +143,7 @@ You can also run the CLI through Cargo from the repository root:
 cargo run -p et-cli -- generate-deployment \
   --input-file verification/local/input/<some-file>.yaml \
   --output-dir verification/local/output/<some-folder> \
-  --output-type mise
+  --output-type docker-compose
 ```
 
 To regenerate all convention-defined verification outputs through Cargo: