A Homepage saját üzemeltetése 2026-ban: engedélyezett hostok, widgetek és konfiguráció

A „Homepage futtatásának” kétféle értelmezése van: létezik egy container, vagy a service ténylegesen elvégzi a feladatát. Csak a második számít. Itt az ellenőrzés abból áll, hogy betöltjük a service-eket és a bookmarkokat, meghívunk több élő widgetet, teszteljük a keresést, majd egy YAML-konfigurációs fájl szerkesztése után újraindítunk.

A Homepage erre szolgál: kezdőoldal saját üzemeltetésű service-ekhez tartozó élő widgetekkel. A deploymentnek meg kell őriznie a működés mögött álló elemeket; egy port, egy volume és egy tanúsítvány bemenet, nem pedig a végeredmény.

Válaszd a legkisebb működőképes Homepage-topológiát

Egy hasznos Homepage-diagram feltünteti a publikus útvonalat, a privát 3000-es portot, az állapothatárt és minden támogató követelményt. Jelöld, mely nyilakon haladnak credentialök, és melyek szokásos felhasználói forgalmat továbbítanak. A Homepage külső követelménye a csak olvasható konfiguráció, valamint az opcionális service-widgetekhez szükséges credentialök. Teszteld a kimenő DNS-t, a TLS-t és a provider működését anélkül, hogy újabb bejövő service-t tennél közzé.

A diagramot egy valódi művelettel igazold: töltsd be a service-eket és a bookmarkokat, hívj meg több élő widgetet, teszteld a keresést, majd egy YAML-konfigurációs fájl szerkesztése után indítsd újra a rendszert. A legvalószínűbb terhelést a widgetek fan-outja, a lassú downstream API-k, a DNS-feloldás és a böngészős dashboard frissítési gyakorisága okozza; ezt az útvonalat figyeld, ne kezeld egyformán az összes HTTP-kérést.

Frissítsd a Homepage-et találgatás nélkül

A Homepage első hasznos operatív mérőszáma az, hogy képes-e betölteni a service-eket és a bookmarkokat, meghívni több élő widgetet, tesztelni a keresést, majd újraindulni egy YAML-konfigurációs fájl szerkesztése után. Ezt egészítsd ki a widgetek fan-outjára, a lassú downstream API-kra, a DNS-feloldásra és a böngészős dashboard frissítési gyakoriságára vonatkozó telítettségi jelekkel. Egy kizárólag a processzt vizsgáló probe ne hívjon drága függőségeket, és ne indítsa újra a containert csak azért, mert egy upstream átmenetileg nem érhető el.

Kezeld a frissítéseket adatváltozásként, mert a konfigurációs kulcsok és a widget-integrációk módosulhatnak, ezért egy image frissítése előtt validáld a YAML-t és a provider működését. Rögzítsd a verziókat, gyakorold a frissítést visszaállított állapoton, és tartsd elérhetően az előző image-et addig, amíg a rollback továbbra is érvényes. Ha a hostot elutasítja a rendszer, vagy a YAML behúzása miatt nem töltődik be a konfiguráció, őrizd meg az újraindítás előtti logokat; ezek általában tartalmazzák a kiváltó hibaüzenetet.

Éles elfogadási ellenőrzés a Homepage-hez

Mielőtt megérkeznek a valódi felhasználók, készíts release-ellenőrzőlapot a Homepage-hez. Nevezze meg a rögzített image-et, a 3000-es portot, a kanonikus origint, a perzisztens útvonalakat, valamint a csak olvasható konfiguráció és az opcionális service-widgetekhez szükséges credentialök felelősét. Csatold a tranzakció várt eredményét: a service-ek és bookmarkok betöltését, több élő widget meghívását, a keresés tesztelését, valamint az újraindítást egy YAML-konfigurációs fájl szerkesztése után.

Használd az ellenőrzőlapot egy normál cserét és egy tiszta visszaállítást követően is. A helyreállítás csak akkor fogadható el, ha a service-ek, bookmarkok, widgetek és egyéni assetek visszatérnek, és minden kritikus widget láthatóan kezeli a downstream hibákat. Gyűjts rövid erőforrás-trace-t is, amely lefedi a widgetek fan-outját, a lassú downstream API-kat, a DNS-feloldást és a böngészős dashboard frissítési gyakoriságát; tartsd ezt a release mellett, hogy a későbbi kapacitásváltozásokat ugyanazzal a workloaddal lehessen összehasonlítani.

Építs be egy kontrollált hibát is: ideiglenesen tiltsd le a csak olvasható konfigurációhoz és az opcionális service-widgetekhez szükséges credentialök által használt tesztútvonalat. Ellenőrizd, hogy a Homepage a megfelelő határon jelenti-e a problémát, állítsd vissza a helyes állapotot, majd futtasd újra a tranzakciót. Ez nem pusztán a sikerességet, hanem a hibák láthatóságát ellenőrzi, és megakadályozza, hogy egy egészségesnek tűnő felület elrejtsen egy hibás workert, callbacket vagy adatbázis-kapcsolatot.

Tedd reprodukálhatóvá a Homepage indulását

A containert cserélhető runtime-ként kezeld, ne az igazság forrásaként.

docker run -d \
  --name homepage \
  --restart unless-stopped \
  -p 127.0.0.1:3000:3000 \
  -v homepage-data:/app/config \
  -e HOMEPAGE_ALLOWED_HOSTS=home.example.com \
  ghcr.io/gethomepage/homepage:latest

Engedélyezd és ellenőrizd a csak olvasható konfigurációhoz és az opcionális service-widgetekhez szükséges credentialök által igényelt kimenő vagy kliensoldali útvonalat. Ellenőrizd a container felhasználóját, az írható útvonalakat és a bindolt listenert, mielőtt közzéteszed a service-t. Futtasd le a teljes műveletet — a service-ek és bookmarkok betöltését, több élő widget meghívását, a keresés tesztelését, valamint az újraindítást egy YAML-konfigurációs fájl szerkesztése után —, és mentsd el a pontos image-referenciát, amely az eredményt produkálta.

Válaszd külön a cserélhető containereket és a tartós adatokat

A tartós helyreállítási készletet a konfigurációs fájlok, a bookmarkok, a service-ek és az egyéni assetek alkotják. A bootstrap előtt mountold az /app/config útvonalat, írj bele ártalmatlan mintaadatokat, majd cseréld le a containert annak bizonyítására, hogy az útvonal valóban perzisztens. Egy volume megvédi az adatokat a container cseréjétől, de nem védi meg őket a host elvesztésétől, a véletlen törléstől vagy az alkalmazásszintű korrupciótól.

Olyan biztonsági mentéseket készíts, amelyek értik az adatforrást: szükség esetén használj logikai dumpokat az élő adatbázisokhoz, a fájlokat pedig csak konzisztens állapotból másold. Tarts egy titkosított példányt a Homepage hostjától elkülönítve. A visszaállítás elfogadási kritériuma konkrét: a service-ek, bookmarkok, widgetek és egyéni assetek visszatérnek, és minden kritikus widget láthatóan kezeli a downstream hibákat. A visszaállítással tesztelt biztonsági mentésekről szóló útmutató bemutatja, miért nem elegendő önmagában a job sikeres lefutása.

Domainek, proxy headerek és a 3000-es port

A böngészőnek, az API-kliensnek és a Homepage-nek ugyanabban az originben kell megegyeznie. Ennek biztosításához állítsd be az engedélyezett hostokat a pontos domainre és a proxy hostnevére. Őrizd meg az eredeti hostot és protokollt, miközben a 3000-es portot elérhetetlenné teszed versengő publikus címként.

A site-down hibakeresési útmutató segít megkülönböztetni az elérhetetlen útvonalat a válaszoló alkalmazástól. Ez itt fontos különbség: a hostot elutasítja a rendszer, vagy a YAML behúzása miatt nem töltődik be a konfiguráció. Csak az előbbi javítható ingress-módosításokkal; az utóbbihoz a Homepage logjait, állapotát vagy workloadját kell vizsgálni.

A Homepage-re jellemző biztonsági döntések

Ne örököld meg egy helyi tutorial biztonsági feltételezéseit. A Homepage sajátos kockázata, hogy a widget API-kulcsai bekerülnek egy publikus repositoryba. Éles környezetben ezért pontosan állítsd be az engedélyezett hostokat, a widget API-kulcsait pedig environmentben vagy secret-alapú konfigurációban tartsd, ne publikus repositoryban.

A HOMEPAGE_ALLOWED_HOSTS a működést, nem pedig a bizalmasságot szabályozza; validáld a típusát és az értékét, a valódi Homepage credentialöket pedig külön tárold. Korlátozd a fájlrendszer- és hálózati hozzáférést, védd a setup endpointokat, és határozz meg upload-, request- vagy execution-limitet a widgetek fan-outja, a lassú downstream API-k, a DNS-feloldás és a böngészős dashboard frissítési gyakorisága körül.

Ahol a Dockup munkát takarít meg a Homepage esetében

A Homepage esetében a Dockup az image és a tartós service közötti határon a leghasznosabb. A 3000-es porthoz vezető útvonalat, a TLS-t, a secret értékeket és a storage-ot a containercserék során is együtt tartja, függetlenül attól, hogy a compute a Dockuphoz vagy a csatlakoztatott szerveredhez tartozik.

A befejezéshez alkalmazásszintű ismeretekre van szükség: állítsd be az engedélyezett hostokat a pontos domainre és a proxy hostnevére; engedélyezd és ellenőrizd a csak olvasható konfigurációt, valamint az opcionális service-widgetekhez szükséges credentialöket; majd futtasd le ezt az ellenőrzést: töltsd be a service-eket és a bookmarkokat, hívj meg több élő widgetet, teszteld a keresést, majd egy YAML-konfigurációs fájl szerkesztése után indítsd újra a rendszert. Az eredményt deployment-ellenőrzésként őrizd meg, hogy a következő image-frissítést a működés, ne pedig a container állapota alapján lehessen megítélni.

Gyakran ismételt kérdések

Mire van szüksége a Homepage-nek éles deploymenthez?

Vezesd át a Homepage containert a 3000-es porton egyetlen HTTPS-originre. A külső kézbesítés követelménye a csak olvasható konfiguráció, valamint az opcionális service-widgetekhez szükséges credentialök. Ne tekintsd késznek a Homepage-et addig, amíg nem tudod betölteni a service-eket és bookmarkokat, meghívni több élő widgetet, tesztelni a keresést, majd egy YAML-konfigurációs fájl szerkesztése után újraindítani.

Mely Homepage-adatoknak kell bekerülniük a biztonsági mentésbe?

Tedd perzisztenssé az /app/config útvonalat, és ugyanabba a helyreállítási manifestbe vedd fel a konfigurációs fájlokat, a bookmarkokat, a service-eket és az egyéni asseteket. A tiszta Homepage-visszaállítás csak akkor sikeres, ha a service-ek, bookmarkok, widgetek és egyéni assetek visszatérnek, és minden kritikus widget láthatóan kezeli a downstream hibákat.

Szükséges HTTPS a Homepage számára reverse proxy mögött?

Használj HTTPS-t a publikus Homepage-originhez, a 3000-es portot pedig tartsd a belső útvonalon. Helyesen alkalmazd a Homepage-beállítást: állítsd be az engedélyezett hostokat a pontos domainre és a proxy hostnevére. A Homepage esetében a HTTPS védi a credentialöket és a felhasználói tartalmakat az átvitel során, valamint konzisztenssé teszi az originérzékeny kliensoldali működést.

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

Állítsd vissza a jelenlegi Homepage-állapotot egy izolált deploymentbe, alkalmazd a jelölt verziót, majd ismételd meg az elfogadási tranzakciót. Fordíts különös figyelmet arra, hogy a konfigurációs kulcsok és a widget-integrációk módosulhatnak, ezért egy image frissítése előtt validáld a YAML-t és a provider működését. Tartsd meg az előző Homepage-image-et addig, amíg nem érted annak adat-migrációs és rollback-határát.