37 lines
1.4 KiB
Markdown
37 lines
1.4 KiB
Markdown
|
---
|
|||
|
|
okf: "0.1"
|
|||
|
|
type: decision
|
|||
|
|
visibility: private
|
|||
|
|
status: active
|
|||
|
|
updated: 2026-07-09
|
|||
|
|
links:
|
|||
|
|
- ../services/nextcloud.md
|
|||
|
|
- ../runbooks/nextcloud-cutover.md
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
# Nextcloud — decyzja: host = PIHA
|
|||
|
|
|
|||
|
|
## Decyzja: host = PIHA
|
|||
|
|
|
|||
|
|
Moduł 4 skłaniał się ku SOLARIA (mocniejszy host, bez wpływu na KB — patrz
|
|||
|
|
niżej), ale Oskar zdecydował inaczej: **Nextcloud jest używany aktywnie**
|
|||
|
|
(telefon, sync, rodzina) — sesyjna dostępność SOLARII (sync dogania się
|
|||
|
|
dopiero po wybudzeniu hosta) nie jest akceptowalna dla tego workloadu.
|
|||
|
|
Nextcloud musi być **always-on**, więc ląduje na PIHA mimo ciaśniejszego
|
|||
|
|
RAM/CPU.
|
|||
|
|
|
|||
|
|
| | PIHA (wybrane) | SOLARIA |
|
|||
|
|
|---|---|---|
|
|||
|
|
| Dostępność | 24/7 (sync zawsze działa) | sesyjna — sync dogania się po wybudzeniu |
|
|||
|
|
| RAM/CPU | ciasno nawet po module 0 (Nextcloud+PHP ≈ 0.5–1 Gi+) | 62 Gi RAM, 24 rdzenie — bez znaczenia |
|
|||
|
|
| Storage | NVMe 477 G (dzielone z resztą) | NVMe 2 T |
|
|||
|
|
| Ingress | npm lokalnie (ten sam host) | npm@PIHA proxuje po LAN do 192.168.31.70:8220 |
|
|||
|
|
| Wpływ na KB | żaden — KB czyta własną kopię z archiwum na PIHA w obu wariantach | jw. |
|
|||
|
|
|
|||
|
|
`service.yaml` ma `owner_node: piha`; `env.example` ma `LAN_BIND_IP` PIHA
|
|||
|
|
(192.168.31.5) i `TRUSTED_PROXIES` pod docker bridge (npm i nextcloud na
|
|||
|
|
tym samym hoście — patrz komentarz w `env.example`). Compose zostaje
|
|||
|
|
przenośne (ścieżki po konwencji `/opt/homelab/data`), gdyby host kiedyś
|
|||
|
|
się zmienił.
|
|||
|
|
|