96d5c814f2
kb/services/nextcloud.md (Stack, WebDAV dla ingestu, Storage i backup) kb/decisions/nextcloud-host-piha.md (decyzja: host = PIHA) kb/runbooks/nextcloud-cutover.md (OIDC przez Forgejo + cutover checklist) Tresc sekcji nietknieta; kontrola multizbioru linii == oryginal. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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ł.
|
||
|