oskar 96d5c814f2 feat(kb): SPLIT nextcloud -> service + decision + runbook

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>

2026-08-04 16:58:46 +02:00

1.4 KiB

Raw Blame History

okf

type

visibility

status

updated

links

0.1

decision

private

active

2026-07-09

../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ł.

1.4 KiB Raw Blame History Unescape Escape

Nextcloud — decyzja: host = PIHA

Decyzja: host = PIHA

1.4 KiB

Raw Blame History