docker-internal-inventory: 3-tier model with per-container recommendation
Lists all containers without LAN-published ports across CT 104/105/109/110/111/112/113. Recommends keep-internal vs expose for each. Confirms the public/LAN/docker-internal tiering is clean across the fleet.
This commit is contained in:
@@ -0,0 +1,76 @@
|
||||
# Docker-internal inventory
|
||||
|
||||
Live at <http://192.168.1.8:13080/docker-internal-inventory/>.
|
||||
|
||||
Containers that have **no LAN-published port** — reachable only on their Docker bridge network. This is the third tier of our access model:
|
||||
|
||||
1. **public** — Zoraxy-routed via `*.nuclide.systems` (internet-reachable)
|
||||
2. **LAN** — `192.168.1.0/24` direct (host port mapping)
|
||||
3. **docker-internal** — only via container-to-container bridge (this doc)
|
||||
|
||||
Default per [[feedback_internal_only]]: keep new things at tier 2 or 3 unless there's a real external-access reason. **Most of what is on tier 3 should stay there** — that's the point of having three tiers.
|
||||
|
||||
## Recommendation legend
|
||||
|
||||
- 🟢 **Keep internal** — sidecar / backend / engine, must not be exposed
|
||||
- 🟡 **Maybe** — admin UI exists; could be useful to reach directly but low value
|
||||
- 🔴 **Expose to LAN** — broken access pattern, fix recommended
|
||||
|
||||
## CT 104 (docker host) — 43 internal-only
|
||||
|
||||
### AI / MCP plumbing — all 🟢 keep internal
|
||||
Backend MCP servers consumed only by the MCP gateway. Exposing them would bypass auth + audit.
|
||||
- `mcp-proxmox`, `gitea-mcp`, `mcp-immich`, `mcp-fetch`, `mcp-time`, `mcp-git`, `mcp-gotify`, `mcp-unifi`, `mcp-ntfy`, `mcp-markitdown`, `mcp-context7`, `mcp-youtube-transcript`, `mcp-sequential-thinking`, `mcp-wikipedia-mcp`, `mcp-gitlab`, `mcp-crawl4ai`, `coder-mcp`, `ariel-mcp`, `paperless-mcp`, `claude-max-bridge`
|
||||
- Plus the ephemeral `crazy_colden`/`stoic_kirch`/etc. (auto-spawned MCP one-shots — Docker name collisions, no static port).
|
||||
|
||||
### Backends for exposed services — 🟢 keep internal
|
||||
- `karakeep_meilisearch`, `karakeep_chrome` (Karakeep search + headless browser)
|
||||
- `immich_postgres`, `immich_redis`, `immich_machine_learning` (Immich backends)
|
||||
- `immich_power_tools` — 🟡 **maybe**. Power-user UI for Immich. Bind to LAN if you ever want to use it directly.
|
||||
- `paperless-ngx-tika-1`, `paperless-ngx-gotenberg-1`, `paperless-ngx-broker-1` (Paperless OCR/PDF/redis)
|
||||
- `redis-searxng`, `rdtclient` (auxiliary)
|
||||
|
||||
### Diagrams — 🟢 keep internal
|
||||
- `kroki`, `kroki-mermaid`, `kroki-excalidraw` — rendered via MCP, no UI to expose.
|
||||
|
||||
### Monitoring agents — 🟢 keep internal
|
||||
- `node-exporter` (scraped by Prometheus on `:9100` over container network; LAN exposure not needed since Prometheus is on the same LAN already)
|
||||
- `arcane-agent` (talks back to Arcane server on CT 109)
|
||||
|
||||
## CT 105 (nextcloud) — 8 internal-only
|
||||
|
||||
🟢 **All keep internal** — Nextcloud AIO architecture.
|
||||
- `nextcloud-aio-nextcloud` (fronted by AIO apache proxy on `:11000`)
|
||||
- `nextcloud-aio-database` (Postgres), `nextcloud-aio-redis`, `nextcloud-aio-imaginary`, `nextcloud-aio-notify-push`, `nextcloud-aio-collabora`, `nextcloud-aio-docker-socket-proxy`
|
||||
- `arcane-agent`
|
||||
|
||||
Exposing the AIO backends directly would break Nextcloud's auth model and crash backups.
|
||||
|
||||
## CT 109 (ops) — 1 internal-only
|
||||
|
||||
- `node-exporter` — 🟢 keep internal. Scraped via `host.docker.internal` from Prometheus on the same host.
|
||||
|
||||
## CT 110 / 111 / 112 / 113 — `arcane-agent` only
|
||||
|
||||
🟢 **All keep internal**. The Arcane agent on each Docker host calls back to the Arcane server on `192.168.1.8:10002`; no inbound LAN traffic needed.
|
||||
|
||||
Plus:
|
||||
- CT 111: `act-runner` 🟢 (Gitea Actions runner — outbound to Gitea API; never needs inbound)
|
||||
- CT 112: `infisical-db`, `infisical-redis` 🟢 (Infisical app on `:8200` is the only intended entry)
|
||||
|
||||
## Cross-tier issues spotted
|
||||
|
||||
None. The 3-tier model is clean across the fleet:
|
||||
- No backend Postgres/Redis is accidentally LAN-bound
|
||||
- No MCP server is double-exposed
|
||||
- No admin UI is bound to LAN when it shouldn't be
|
||||
|
||||
## Candidate LAN-bind, if you want them
|
||||
|
||||
If you ever want direct LAN access to one of the 🟡 services, the pattern is to add a `ports:` line to its compose entry:
|
||||
|
||||
| Service | Suggested port | Why you might |
|
||||
|---|---|---|
|
||||
| `immich_power_tools` | `:3001` on CT 104 | Bulk Immich operations (album merge, dedup) the main UI doesn't expose |
|
||||
|
||||
Everything else: leave at tier 3.
|
||||
Reference in New Issue
Block a user