Weitere Sites anlegen und entfernen

Bisher liess sich eine zweite Site nur importieren, nicht anlegen - der Entrypoint des Abbilds macht ausschliesslich die Site aus CMK_SITE_ID. Absicht war das nicht, es fehlte schlicht. site-create NAME [--password PW] [--expose] [--no-start] site-delete NAME [--force] Im Container laeuft "omd create --no-tmpfs"; ohne --no-tmpfs scheitert es, weil sich dort kein tmpfs einhaengen laesst. Laeuft der Container nicht im Host-Netz, wird der Apache der Site zusaetzlich auf 0.0.0.0 gebunden - im Host-Netz genuegt 127.0.0.1, und der Proxy kommt trotzdem hin. Das wird am Container nachgesehen, nicht geraten. Der eigentliche Punkt sind die Ports. omd vergibt sie selbst weiter, am laufenden Container nachgemessen: erste zweite dritte Oberflaeche 5000 5001 5002 Agent-Receiver 8000 8001 8002 Livestatus 6557 6558 6559 Die Agents einer zweiten Site sprechen also 8001 an, nicht 8000 - das faellt sonst erst auf, wenn niemand Daten liefert. "site-create" gibt deshalb beides fertig aus: den Proxy-Pfad mit der richtigen Portnummer und den Firewall-Eintrag fuer den Receiver, dazu den Hinweis auf den Standard-Server, falls er eingerichtet ist. Beim Loeschen war "omd rm" zuerst wirkungslos: es fragt selbst nach, die Site blieb stehen, waehrend hier Erfolg gemeldet wurde. Jetzt mit dem globalen -f, und danach wird nachgesehen, ob sie wirklich weg ist. Die Standard-Site ist geschuetzt - der Entrypoint legt sie ohnehin wieder an. In der Oberflaeche unter "Sites im Container verwalten": anlegen mit Namens- und Kennwortabfrage, entfernen mit Rueckfrage. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-20 22:20:21 +02:00
parent 4456f8c3ea
commit 7d9ed10e09
3 changed files with 360 additions and 28 deletions
@@ -2531,6 +2531,8 @@ A file chooser with directory navigation is built in.
 | `sites` | list the sites in the container |
 | `site-start SITE` / `site-stop SITE` | control a single site |
 | `start-all-sites` | start all sites (invoked by systemd) |
+| `site-create NAME` | create another site in the container – own ports (5001, 8001, …) |
+| `site-delete NAME` | remove a site and all its data |
 | `backup …` | backup as a `.tar.gz` bundle |
 | `list` / `verify` / `prune --keep N` | manage backups |
 | `job list\|add\|set\|del\|run\|auto` | scheduled backups (own target path per job) |
@@ -3038,24 +3040,81 @@ Then check in the interface:

 ## 18. Several sites in one container

-At startup the Checkmk entrypoint only creates – and only starts – the site
-from `CMK_SITE_ID`. Further sites (e.g. several imported ones) exist in the
-bind mount but are not brought up automatically after a restart.
+The image's entrypoint creates only the site from `CMK_SITE_ID` and starts only
+that one. Further sites can be created, though – and with the proxy in front
+they sit side by side behind a single port:

-Hence:
+```bash
+./scripts/cmk-manage.sh site-create zweite
+./scripts/cmk-manage.sh site-create kunde2 --password secret123
+./scripts/cmk-manage.sh sites
+./scripts/cmk-manage.sh site-delete zweite
+```
+
+### 18.1 Each site gets its own ports
+
+`omd` assigns the ports itself – everything else follows from that:
+
+| | first site | second | third |
+|---|---|---|---|
+| web UI (Apache) | 5000 | 5001 | 5002 |
+| **agent receiver** | 8000 | **8001** | **8002** |
+| Livestatus | 6557 | 6558 | 6559 |
+
+Two consequences:
+
+1. **In the proxy** every site gets its path:
+
+   ```bash
+   ./scripts/cmk-manage.sh proxy edit --domain <name> --location /zweite=127.0.0.1:5001
+   ./scripts/cmk-manage.sh proxy reload
+   ```
+
+   It then sits next to the first one: `https://<ip>/cmk/` and
+   `https://<ip>/zweite/`. Checkmk copes with the prefix because the site name
+   is part of every address anyway – see
+   [chapter 10.12](#1012-adding-more-services--grafana-as-an-example).
+
+2. **In the firewall** the agents of that site talk to a different port:
+
+   ```bash
+   ./scripts/cmk-manage.sh config set FW_EXTRA_PORTS "8001/tcp=Agent-Receiver zweite"
+   sudo ./scripts/cmk-manage.sh firewall open --apply
+   ```
+
+`site-create` prints exactly those two commands with the right port numbers,
+plus a reminder about the default server for IP access if it is set up.
+
+### 18.2 What happens during creation
+
+Inside the container `omd create --no-tmpfs` runs – without `--no-tmpfs` it
+fails, because no tmpfs can be mounted there. If the container does **not** run
+in the host network, the site's Apache is additionally bound to `0.0.0.0`,
+otherwise it would not be reachable from outside; in the host network
+`127.0.0.1` is enough and the proxy still reaches it. Without `--password`,
+`omd` generates one and prints it.
+
+### 18.3 After a restart

 ```bash
 sudo ./scripts/cmk-manage.sh start-all-sites
 ```

-This command is executed automatically by the systemd unit (`ExecStartPost`)
-or the Quadlet unit after the container starts, and starts every site present.
+The entrypoint starts only the default site. This command is run automatically
+by the systemd unit (`ExecStartPost`) or the Quadlet unit after the container
+starts, and brings up all existing sites.

-> **Recommendation:** for cleanly separated environments, run one project
-> directory with its own `.env` per site. Note that because both containers run
-> on the host network, only **one** Checkmk container per host can occupy ports
-> 5000/8000 – for genuinely multiple instances use separate hosts or a
-> bridge-network variant.
+### 18.4 When separate projects are better
+
+Several sites in one container share the image and version – one `omd update`
+affects all of them. For cleanly separated environments (different Checkmk
+versions, separate maintenance windows, different customers) a separate project
+directory with its own `.env` per site is better. Since both containers run in
+the host network, only **one** Checkmk container per host can occupy ports
+5000/8000 – for real multiple instances use separate hosts or a bridge-network
+variant.
+
+The GUI has all of it under **Sites im Container verwalten**.

 ---