Files
janssen/SeaweedFS/README.md
T
2026-06-11 21:49:04 +02:00

100 lines
4.0 KiB
Markdown

# SeaweedFS na Unraidu — S3-kompatibilní úložiště
Vyladěný Docker stack proti původnímu příkladu. Hlavní rozdíly a proč:
| Změna | Proč |
|---|---|
| Pin verze image `:4.32` místo `:latest` | reprodukovatelnost, žádné překvapení po `pull` |
| Master má `-mdir=/data` + namapovaný volume | **metadata masteru** (kde co leží) jinak po restartu zmizí |
| Filer má namapovaný `/data` | leveldb s metadaty souborů musí persistovat |
| `-config=config_s3.json` u s3 | bez něj je S3 **bez autentizace, otevřené komukoliv** v síti |
| `healthcheck` + `depends_on: service_healthy` | služby nestartují dřív, než je master skutečně nahoře |
| `restart: unless-stopped` | přežije restart Unraidu |
| `-ip.bind=0.0.0.0` | dostupnost z LAN, ne jen z kontejneru |
| Data pod `/mnt/user/appdata/...` | zálohovatelné, ne v anonymním volume |
## Kam se ukládají data (DŮLEŽITÉ pro Unraid)
Klíčové pravidlo Unraidu: **cache není pod paritou** → patří tam jen to, co jde
snadno obnovit. Rozhoduje tedy ne velikost, ale obnovitelnost:
| Co | Obnovitelné? | Kam | Cesta |
|---|---|---|---|
| volume (vlastní obsah) | ne (to jsou ta data) | **POLE (parita)** | `/mnt/user/seaweedfs/volume` |
| **filer metadata** | **NE** — bez nich jsou bloby slepé | **externí DB** (Mongo/PG) | `filer.toml` |
| master metadata | ano — poskládá se z heartbeatů | cache / appdata | `/mnt/user/appdata/seaweedfs/master` |
| config_s3.json | trivální | vedle compose | `./config_s3.json` |
### Proč filer metadata nesmí na cache
filer drží mapu *název souboru → které chunky na kterém volume*. Volume servery ji
**neumí zrekonstruovat** — bloby na poli přežijí, ale ztratíš informaci, co je co.
Proto je dáváme do tvé existující DB na 192.168.1.76 (viz `filer.toml`):
- **MongoDB (doporučeno)** — kolekce v DB `seaweedfs` se vytvoří sama, žádné schéma.
- **PostgreSQL** — vytvoř DB a tabulku:
```sql
CREATE DATABASE seaweedfs;
-- v DB seaweedfs:
CREATE TABLE IF NOT EXISTS filemeta (
dirhash BIGINT,
name VARCHAR(65535),
directory VARCHAR(65535),
meta BYTEA,
PRIMARY KEY (dirhash, name)
);
```
Master metadata na cache nechávám schválně — po ztrátě cache si je master poskládá
z hlášení volume serverů, takže spadají do „snadno obnovitelné".
### Nejdřív založ share na poli
Settings → Shares → Add Share:
- Název: `seaweedfs`
- **Primary storage: Array** (NE cache), Secondary: none — jinak by data tekla zpět na cache a zaplnila ji
- Allocation/split dle libosti
Tím vznikne `/mnt/user/seaweedfs`, kam míří volume vrstva. (Alternativa: napřímo na
konkrétní ZFS disk, `/mnt/diskX/seaweedfs/volume`, když chceš obejít user share.)
> Pozn.: Disk 8 (sdd) má v poli **14 223 čtecích chyb** — než tam pustíš nová data,
> mrkni na SMART / zvaž jeho vyřazení. Na takový disk bych volume dir nesměroval.
## Spuštění
```bash
cd /boot/config/plugins/compose/... # nebo kamkoliv stack uložíš
docker compose -p seaweedfs up -d
docker compose -p seaweedfs ps
```
## Endpoints (nahraď `UNRAID-IP`)
- Master UI: `http://UNRAID-IP:9333`
- Filer/web: `http://UNRAID-IP:8888`
- **S3 API:** `http://UNRAID-IP:8333`
## Před produkcí
1. **Změň klíče** v `config_s3.json` (admin i readonly). Dlouhé náhodné secret keys.
2. Soubor `config_s3.json` drž s právy `600`.
3. Zvaž reverzní proxy (SWAG/NPM) s TLS, pokud má být S3 dostupné mimo LAN.
4. `defaultReplication=000` = bez replikace (1 kopie). Pro odolnost přes víc disků/serverů zvyš (např. `001`, `010`) a přidej volume servery.
## Test
```bash
# AWS CLI
S3=http://UNRAID-IP:8333 AK=admin SK=tajne ./test_s3.sh
```
Nebo přes `s3cmd`, `rclone`, MinIO client (`mc`) — vše funguje proti `:8333`.
## Škálování později
Tohle je single-node setup (test / menší nasazení). Pro distribuovaný cluster přidej
další `volume` servery (klidně na jiných strojích) mířící na stejný master a zvyš
replikaci. Master + filer mohou zůstat, volume vrstva se škáluje horizontálně.