A FreshRSS saját üzemeltetése 2026-ban: feedfrissítés, mobil API és biztonsági mentések

Egy hibás FreshRSS-deployment nem feltétlenül omlik össze. Előfordulhat, hogy bejelentkezési oldalt szolgál ki, miközben a feedek soha nem frissülnek, mert a cron le van tiltva vagy a kimenő DNS-feloldás nem működik. Ehelyett kezdj teljes körű ellenőrzéssel: adj hozzá feedeket, futtass ütemezett frissítést, jelölj olvasottként egy elemet, majd szinkronizáld ezt az állapotot a mobil API-n keresztül.

Ez az ellenőrzés megfelel a FreshRSS dokumentált céljának: saját üzemeltetésű RSS-olvasó kompatibilis mobil API-val. Emellett korábban feltárja a hiányzó függőségeket, a hibás proxy-feltételezéseket és az ephemeral adatokat, mint egy uptime-probe.

Térképezd fel a FreshRSS-t a Docker használata előtt

Válaszd külön a FreshRSS négy területét: az ingress réteget, a 80-as porton figyelő listenert, a tartós állapotot, valamint a támogató szolgáltatásokat vagy a helyi kapacitást. A FreshRSS külső követelménye az ütemezett feedfrissítés és a feedeket kiszolgáló hostokhoz való kimenő hozzáférés. Teszteld a kimenő DNS-t, a TLS-t és a szolgáltató viselkedését anélkül, hogy újabb bejövő szolgáltatást publikálnál.

Futtasd le az ismert, működő tranzakciót — adj hozzá feedeket, futtass ütemezett frissítést, jelölj olvasottként egy elemet, majd szinkronizáld ezt az állapotot a mobil API-n keresztül — mielőtt késznek nyilvánítanád ezt a szétválasztást. Mérd meg a feedek számát, a frissítési időközt, a lassú publikálókat, az adatbázis-írásokat és az egyidejű API-klienseket, az eredményt pedig őrizd meg a deployment rekordjával együtt. Ez elfogadási kritériumot és az első kapacitásalapot is biztosítja.

Mentsd a FreshRSS által újra létre nem hozható állapotot

Készíts helyreállítási jegyzéket a FreshRSS-hez: adatokat, extensionöket és a kiválasztott adatbázist. A bootstrap előtt csatold a /var/www/FreshRSS/data könyvtárat, írj bele ártalmatlan mintaadatokat, majd cseréld le a containert annak bizonyítására, hogy az útvonal valóban perzisztens. Ellenőrizd most a tulajdonost és a szabad helyet, mert egy csatolt, de nem írható útvonal gyakorlatilag ugyanúgy viselkedik, mintha egyáltalán nem lenne perzisztencia.

A biztonsági mentéseket a futó szervertől külön failure domainbe készítsd. Hozd létre újra a FreshRSS-t a rögzített image-ből, majd ellenőrizd, hogy az előfizetések, a kategóriák, az olvasási állapot, a szűrők és az extensionök visszaállnak-e, illetve az ütemezett frissítés lekér-e egy új elemet. A perzisztens kötetekről szóló útmutató segít ezt a gyakorlatot snapshot- és megőrzési szabállyá alakítani.

Válaszd ki a FreshRSS trust boundary-jét

Ne csak a bejelentkezési űrlapot modellezd fenyegetések szempontjából, hanem azt a műveletet is, amelyet a FreshRSS végrehajt. Itt az a nagy kockázatú hiba, ha a kezdeti beállítás vagy az alapértelmezett felhasználó nyilvános hoston hozzáférhető marad. Alakítsd ki ezt a határt: fejezd be privát módon a beállítást, védd az API-jelszavakat, és a mobil szinkronizálás engedélyezése előtt konfiguráld a trusted proxykat.

A CRON_MIN a működést, nem pedig a bizalmasságot szabályozza; ellenőrizd a típusát és az értékét, a valódi FreshRSS-hitelesítő adatokat pedig külön tárold. Ne úgy oldj meg egy jogosultsági hibát, hogy rootként futtatod a containert, vagy túl széles körben csatolod a host fájlrendszerét. Az erőforrás-korlátok szintén a biztonsági tervezés részét képezik, ha a felhasználók kiválthatják a feedek számát, a frissítési időközt, a lassú publikálók kezelését, az adatbázis-írásokat és az egyidejű API-klienseket.

Minek kell teljesülnie, mielőtt valódi FreshRSS-adatok érkeznek

Alakítsd át a FreshRSS smoke testjét ismételhető release-paranccsá vagy rövid runbookká. A kimenetének ezt az eredményt kell bizonyítania: feedek hozzáadása, ütemezett frissítés futtatása, egy elem olvasottként való megjelölése, majd ennek az állapotnak a szinkronizálása a mobil API-n keresztül. Az eredménnyel együtt rögzítsd az alkalmazás verzióját, a container digestjét, a route hostname-jét és a tesztadat azonosítóját.

Ugyanezt az ellenőrzést futtasd le egy szokásos containercsere után, valamint az adatok, az extensionök és a kiválasztott adatbázis máshová történő visszaállítása után is. A restore akkor sikeres, ha az előfizetések, a kategóriák, az olvasási állapot, a szűrők és az extensionök visszaállnak, az ütemezett frissítés pedig lekér egy új elemet. Hasonlítsd össze a feedek számához, a frissítési időközhöz, a lassú publikálókhoz, az adatbázis-írásokhoz és az egyidejű API-kliensekhez kapcsolódó időzítést és erőforrás-felhasználást; a jelentős eltérés akkor is vizsgálatra érdemes, ha a végső művelet továbbra is sikeres.

Ezután hajts végre egy biztonságos hibatűréstesztet: ideiglenesen tiltsd le az ütemezett feedfrissítéshez és a feedeket kiszolgáló hostokhoz való kimenő hozzáféréshez használt tesztútvonalat. Ellenőrizd, hogy a FreshRSS jelzi a hibát, majd destruktív manuális módosítások nélkül visszatér normál működésbe. Csak a szükséges, kitakart logrészletet őrizd meg. Ez a négy részből álló ellenőrzési pont lefedi az indulást, a perzisztenciát, a helyreállítást és a hibakezelést.

Docker-alap FreshRSS-hez

Egy production jellegű indítás szándékosan unalmas: named state, explicit port, és semmilyen secret nem kerül az image-be.

docker run -d \
  --name freshrss \
  --restart unless-stopped \
  -p 127.0.0.1:80:80 \
  -v freshrss-data:/var/www/FreshRSS/data \
  -e CRON_MIN=15 \
  freshrss/freshrss:latest

A példa kiindulási alap, nem pedig teljes supporting stack. Engedélyezd és ellenőrizd az ütemezett feedfrissítéshez és a feedeket kiszolgáló hostokhoz szükséges kimenő vagy kliensoldali útvonalat. Ellenőrizd a tényleges mountokat és a listenert, majd próbálj feedeket hozzáadni, futtass ütemezett frissítést, jelölj olvasottként egy elemet, és szinkronizáld ezt az állapotot a mobil API-n keresztül. A következő újraindítás előtt rögzítsd a működő image-et.

Ne hagyd, hogy a proxy sikere elfedje az alkalmazás hibáját

A böngészőnek, az API-kliensnek és a FreshRSS-nek ugyanabban az originben kell megegyeznie. Ennek biztosításához deklaráld a trusted proxykat és a kanonikus HTTPS-alapot. Őrizd meg az eredeti hostot és protokollt, miközben a 80-as port nem marad elérhető konkurens nyilvános címként.

A site-down hibakeresési útmutató segít megkülönböztetni az elérhetetlen route-ot a válaszoló alkalmazástól. Ez itt fontos különbség: a feedek azért nem frissülnek, mert a cron le van tiltva vagy a kimenő DNS-feloldás nem működik. Ingress-módosítás csak az előbbit javítja; az utóbbihoz a FreshRSS logjait, állapotát vagy a workloadot kell megvizsgálni.

A workloadot figyeld, ne csak a containert

Figyeld a FreshRSS által végzett munkát: a feedek számát, a frissítési időközt, a lassú publikálókat, az adatbázis-írásokat és az egyidejű API-klienseket. A limiteket úgy állítsd be, hogy legyen tartalék erre a munkára, és kerüld az olyan liveness probe-ot, amely versenyez vele az erőforrásokért. Az operator-ellenőrzésnek továbbra is meg kell kísérelnie a feedek hozzáadását, az ütemezett frissítés futtatását, egy elem olvasottként való megjelölését, valamint ennek az állapotnak az ütemezett szinkronizálását a mobil API-n keresztül.

Frissítéseknél ne feledd, hogy az extensionök, az adatbázis-migrációk és a feed-parser módosításai hatással lehetnek a frissítésekre akkor is, ha a bejelentkezés továbbra is működik. A candidate verziót egy visszaállított példányon telepítsd, majd ismételd meg az ismert tesztet. Ha a feedek azért nem frissülnek, mert a cron le van tiltva vagy a kimenő DNS-feloldás nem működik, a runtime logjai és a tényleges hálózati kérés segítségével keresd meg, melyik feltételezés változott.

Vidd át az ismételhető infrastruktúramunkát a Dockupra

A Dockup egykattintásos FreshRSS-deploymentjének biztonságossá kell tennie a cserét: a route továbbra is a 80-as portra mutat, a secretek nem kerülnek bele az image-be, a perzisztens útvonalak pedig visszatérnek az új containerben. Ugyanez a deployment futhat Dockup compute-on vagy egy csatolt gépen.

Végezd el az alkalmazásspecifikus feladatokat az ütemezett feedfrissítés és a feedeket kiszolgáló hostokhoz való kimenő hozzáférés engedélyezésével és ellenőrzésével, alkalmazd a kanonikus nyilvános címet, majd futtasd le ezt az elfogadási ellenőrzést: adj hozzá feedeket, futtass ütemezett frissítést, jelölj olvasottként egy elemet, és szinkronizáld ezt az állapotot a mobil API-n keresztül. A restore eredményét még a valódi felhasználók érkezése előtt add hozzá a runbookhoz.

Gyakran ismételt kérdések

Mire van szüksége a FreshRSS-nek production deploymenthez?

A FreshRSS containert egyetlen HTTPS-originen keresztül route-old a 80-as portra. A külső kiszolgálási követelmény az ütemezett feedfrissítés és a feedeket kiszolgáló hostokhoz való kimenő hozzáférés. Ne tekintsd késznek a FreshRSS-t addig, amíg nem tudsz feedeket hozzáadni, ütemezett frissítést futtatni, egy elemet olvasottként megjelölni, majd ezt az állapotot a mobil API-n keresztül szinkronizálni.

Mely FreshRSS-adatoknak kell szerepelniük a biztonsági mentésben?

Tedd perzisztenssé a /var/www/FreshRSS/data könyvtárat, és ugyanabba a helyreállítási jegyzékbe foglald bele az adatokat, az extensionöket és a kiválasztott adatbázist. A tiszta FreshRSS-restore csak akkor sikeres, ha az előfizetések, a kategóriák, az olvasási állapot, a szűrők és az extensionök visszaállnak, az ütemezett frissítés pedig lekér egy új elemet.

Szüksége van a FreshRSS-nek HTTPS-re reverse proxy mögött?

A nyilvános FreshRSS-originhez használj HTTPS-t, a 80-as portot pedig tartsd meg a belső route-on. Alkalmazd helyesen a FreshRSS-beállítást: deklaráld a trusted proxykat és a kanonikus HTTPS-alapot. A FreshRSS esetében a HTTPS védi a hitelesítő adatokat és a felhasználói tartalmat átvitel közben, valamint konzisztenssé teszi az originfüggő kliensviselkedést.

Hogyan kell tesztelni egy FreshRSS-frissítést?

Állítsd vissza a jelenlegi FreshRSS-állapotot egy izolált deploymentbe, alkalmazd a candidate verziót, majd ismételd meg az elfogadási tranzakciót. Különösen figyelj erre, mert az extensionök, az adatbázis-migrációk és a feed-parser módosításai hatással lehetnek a frissítésekre akkor is, ha a bejelentkezés továbbra is működik. Tartsd meg az előző FreshRSS-image-et addig, amíg nem tisztázod az adat-migráció és a rollback határát.