feat(compose): opt-in one-shot alert-bootstrap service for the secure 3-rack stack

[digiserg]

Summary

Add an optional, one-shot Docker Compose service to
docker-compose/03-secure-3-rack-cluster/ that runs the published
axonops-alert-bootstrap-ee image to create the default AxonOps alert rules
after the stack is up, then exits.

This issue covers only the Compose wiring, configuration surface, and
documentation. The alert profile, bootstrap playbook, readiness logic,
idempotency behaviour, and the Execution Environment image itself are owned by
the collection repo and tracked in the parent issue.

Motivation

The 03 stack brings up a full self-hosted AxonOps platform and a 3-node
Cassandra cluster, but starts with no alert rules, so nothing in the demo
actually alerts. Wiring in the collection's bootstrap image gives a
ready-to-observe environment for local development, demos, and evaluation
without duplicating any alert logic here.

Scope

Compose service

Add to docker-compose/03-secure-3-rack-cluster/docker-compose.yaml:

axonops-alert-bootstrap:
  profiles:
    - alert-bootstrap
  image: <registry>/axonops-alert-bootstrap-ee:<pinned tag>
  container_name: axonops-alert-bootstrap
  restart: "no"
  networks:
    - cassandra_network
  depends_on:
    axon-server:
      condition: service_healthy
  environment:
    - AXONOPS_URL=http://axon-server:8080
    - AXONOPS_ORG=${AXONOPS_ORG_NAME:-example}
    - AXONOPS_CLUSTER=${CASSANDRA_CLUSTER_NAME:-secure-cluster}
    - AXONOPS_ALERT_PROFILE=${AXONOPS_ALERT_PROFILE:-demo}
    - AXONOPS_ALERT_TIMEOUT=${AXONOPS_ALERT_TIMEOUT:-300}

Exact variable names must match whatever the parent issue settles on. Follow
the existing conventions in the file: pinned image tag (digest pin documented
as the option, as CASSANDRA_IMAGE already does), ${VAR:-default} for every
tunable, and a comment block explaining the service.

Requirements:

• Not started by a plain docker compose up — the alert-bootstrap profile
  gates it. Existing deployments are unchanged unless explicitly opted in.
• depends_on axon-server service_healthy. Note this is necessary but not
  sufficient; the API readiness check inside the image is what actually
  guarantees the API will accept writes.
• One-shot: runs, logs, exits. restart: "no", never long-lived.
• Non-zero exit on unrecoverable failure, so docker compose ps/CI can detect
  it.
• No Docker socket, no host mounts, no extra capabilities.

Expected usage:

docker compose --profile alert-bootstrap up -d
docker compose logs -f axonops-alert-bootstrap

Configuration

• Add the new variables to env.example with commented defaults and the same
  explanatory tone as the surrounding entries.
• The 03 stack's axon-server is self-hosted and reachable in-network on
  http://axon-server:8080 with no API token; the org comes from
  AXONOPS_ORG_NAME. Do not introduce a SaaS-style AXONOPS_API_TOKEN unless
  the parent issue establishes that it is actually required here.
• No real tokens, passwords, or webhook URLs committed. .env stays gitignored.
• Support Docker secrets if the image supports them; otherwise document the
  env-var-only limitation.

Which stacks

Start with 03-secure-3-rack-cluster only. If the service generalises cleanly,
01-cassandra-cluster is a follow-up — out of scope here. 02-saas-* uses SaaS
auth and is explicitly out of scope.

Documentation

Update docker-compose/03-secure-3-rack-cluster/README.md (and README.fr.md)
with:

• How to enable the bootstrap service and what the profile gate does.
• The variables it reads and how credentials are handled.
• That readiness is checked at the API level with a bounded timeout, and what a
  timeout failure looks like.
• A link to the collection's documentation of the exact rules each profile
  creates — do not duplicate the rule list here; it will drift.
• Explicitly: no alert endpoints, routes, routing policies, or notification
  integrations are created, and the user configures notification delivery
  themselves in AxonOps afterwards.
• How to read the logs, and how to re-run the bootstrap manually.
• That re-running is safe and will not duplicate rules or touch
  user-created ones.
• How to disable it again.

Explicit non-goals

• No alert rule definitions in this repo — they live in the collection.
• No Ansible playbooks, roles, or ansible-builder definitions in this repo.
• No alert endpoints, routes, routing policies, or notification integrations.
• No change to the default behaviour of any existing Compose stack.
• No provisioning of AxonOps itself.

Testing

• docker compose config validation of the 03 stack, asserting the service is
  absent without the profile and present with it.
• An end-to-end check: bring up the 03 stack, run the profile, assert the
  bootstrap container exits 0 and the expected alert rules exist.
• A re-run confirming exit 0 with no duplicates.
• Confirm a plain docker compose up -d still starts exactly the services it
  did before this change.

Acceptance criteria

• An opt-in one-shot axonops-alert-bootstrap service exists in the 03 stack,
  gated behind the alert-bootstrap profile.
• It is not started by a default docker compose up.
• It runs the published Execution Environment image at a pinned tag; no alert
  logic lives in this repo.
• It depends on axon-server health and exits after completing.
• It exits non-zero on unrecoverable failure.
• It needs no Docker socket or elevated host access.
• env.example documents every new variable; no secrets committed.
• Both READMEs document enablement, variables, log inspection, re-running,
  idempotency, and the absence of routes/endpoints/integrations.
• CHANGELOG.md updated.

Related

• Original request: feat(compose): bootstrap default AxonOps alert rules with a one-shot Ansible Execution Environment #186
• Blocked on: feat(alerts): default alert-rule bootstrap profile, playbook and Execution Environment axonops-ansible-collection#130