Az Etherpad saját üzemeltetése 2026-ban: padek, pluginek és adatbázis-mentések

Ha már próbáltad saját magad üzemeltetni az Etherpadet, valószínűleg ismerős ez a frusztráló állapot: a felület megjelenik, de a sessionök megszakadnak, mert a proxy time-outjai túl rövidek. A konténer újralétrehozása ritkán oldja meg az URL-ek, az állapot és a függőségek közötti eltérést.

Ez az útmutató egy konkrét befejezési feltételt használ: egy pad megnyitása két böngészőben, párhuzamos szerkesztés, a revíziók ellenőrzése és az eredmény exportálása az előírt formátumban. Minden konfigurációs döntést e feltétel alapján értékelünk, nem pedig egy zöld konténerjelzés alapján.

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

A legkisebb felelősen kialakított Etherpad-topológia egy 9001-es privát listenert, egy ingress útvonalat és egy dokumentált állapothatárt tartalmaz. Az Etherpad hálózati szerződésének része a Postgres vagy egy másik támogatott adatbázis a tartós, többfelhasználós használathoz. A privát végpontokat belső DNS-en tartsd, csak a szükséges kimenő hívásokat engedélyezd, és korlátozott hatókörű service credentialt adj az Etherpadnek.

A topológiát úgy validáld, hogy egy tiszta klienssel megnyitsz egy padet két böngészőben, párhuzamosan szerkesztesz, ellenőrzöd a revíziókat, majd az eredményt az előírt formátumban exportálod. Futás közben figyeld a WebSocket-sessionöket, a revíziók számát, az adatbázisba írt adatokat és a pluginek futását. Az eredmény megmutatja, hogy a következő fejlesztésnek a memóriát, a storage-ot, a hálózatot vagy egy külön workert kell-e érintenie, ahelyett hogy találomra növelnéd a konténer méretét.

Készíts cserélhető Etherpad-konténert

A konténert cserélhető runtime-ként használd, ne az igazság forrásaként.

docker run -d \
  --name etherpad \
  --restart unless-stopped \
  -p 127.0.0.1:9001:9001 \
  -v etherpad-data:/opt/etherpad-lite/var \
  -e ADMIN_PASSWORD=replace-with-a-long-random-value \
  etherpad/etherpad:latest

Add hozzá a Postgreshez vagy egy másik támogatott adatbázishoz szükséges, ellenőrzött kapcsolati beállításokat a tartós, többfelhasználós használathoz; privát szolgáltatások esetén használj privát neveket. Mielőtt elérhetővé tennéd, ellenőrizd a konténer felhasználóját, az írható útvonalakat és a bindolt listenert. Futtasd le a teljes műveletet — egy pad megnyitását két böngészőben, párhuzamos szerkesztést, a revíziók ellenőrzését és az eredmény exportálását az előírt formátumban —, majd mentsd el a pontos image-referenciát, amely az eredményt előállította.

Akadályozd meg, hogy a proxy sikere elfedje az alkalmazás hibáját

A böngészőnek, az API-kliensnek és az Etherpadnek ugyanabban az originben kell megegyeznie. Ennek biztosításához állítsd be a publikus URL-t és a proxy WebSocket-támogatását. Őrizd meg az eredeti hostot és protokollt, miközben a 9001-es port nem válik konkurens publikus címmé.

A site-down hibaelhárítási útmutató segít megkülönböztetni az elérhetetlen útvonalat a válaszoló alkalmazástól. Ez a különbség itt fontos: a sessionök azért szakadnak meg, mert a proxy time-outjai túl rövidek. Csak az előbbi problémát oldják meg az ingress módosításai; az utóbbihoz az Etherpad logjait, állapotát vagy workloadját kell vizsgálni.

Tervezd meg az Etherpad visszaállítását még az indulás előtt

Az Etherpad állapotát még a konténer optimalizálása előtt védd. A szükséges készlet az adatbázisból, a feltöltött pluginekből és a beállításokból áll. A bootstrap előtt mountold a /opt/etherpad-lite/var útvonalat, írj bele ártalmatlan mintaadatokat, majd a konténer cseréjével bizonyítsd, hogy az útvonal valóban perzisztens. Ha több store-nak kell összhangban lennie, dokumentáld, milyen sorrendben állítod le az írásokat és készíted el a mentéseket.

A másolatokat a deployment szerveren kívül tartsd, és titkosítsd a credentialeket vagy privát tartalmat tartalmazó anyagokat. A helyreállítás akkor sikeres, ha a padek, a szerzők, a revíziók és a pluginek visszatérnek, és a párhuzamos szerkesztések továbbra is konvergálnak. A perzisztens mount és a független másolat közötti különbséget a perzisztens storage-ról és snapshotokról szóló útmutató ismerteti.

Válaszd ki az Etherpad trust boundaryjét

Amint létrejön az első megbízható adminisztrátor, zárd le a bootstrap időablakát. Az Etherpad konkrét buktatója egy ismert adminjelszó használata vagy a padek mindenki számára írhatóvá tétele; a biztonságosabb határ egy valódi adminjelszó beállítása, annak eldöntése, hogy ki hozhat létre padeket, valamint annak elkerülése, hogy egy nehezen kitalálható pad URL-jét privátnak tekintsd.

Azonnal cseréld le a minta ADMIN_PASSWORD értékét, az értéket az image-en kívül tárold, és ha kiszivárog, adminisztrátori credentialként rotáld. A privát hálózat vigye a függőségek credentialjeit, az Etherpaden belüli role-ok pedig a legkisebb hasznos művelethez szükséges jogosultságot adják. Az érzékeny request bodykat és a provider-válaszokat ne írd a rutinlogokba.

Frissítsd az Etherpadet találgatás nélkül

Figyeld meg, milyen munkát végez az Etherpad: WebSocket-sessionöket, a revíziók számát, az adatbázisba írt adatokat és a pluginek futását. A limiteket ehhez a munkához elegendő tartalékkal állítsd be, és kerüld az olyan liveness probe-ot, amely versenyez vele. Az operátori ellenőrzésnek ütemezetten továbbra is meg kell próbálnia egy pad megnyitását két böngészőben, a párhuzamos szerkesztést, a revíziók ellenőrzését és az eredmény exportálását az előírt formátumban.

Frissítéskor ne feledd, hogy az Etherpad pluginverzióit, a beállítások szintaxisát és az adatbázis-migrációkat együtt kell tesztelni. A candidate-et egy visszaállított másolaton telepítsd, majd ismételd meg az ismert tesztet. Ha a sessionök azért szakadnak meg, mert a proxy time-outjai túl rövidek, runtime-logokkal és a tényleges hálózati requesttel keresd meg, melyik feltételezés változott.

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

Az Etherpad esetében indulás előtt határozz meg egy ismert módon működő tranzakciót: egy pad megnyitását két böngészőben, a párhuzamos szerkesztést, a revíziók ellenőrzését és az eredmény exportálását az előírt formátumban. Az előfeltételeit, a várt választ és a takarítási lépéseket titkos értékek nélkül tedd verziókezelésbe. Rögzítsd az image-et, amellyel ezt a referenciát létrehoztad.

A tranzakcióval validáld a cserét és egy független visszaállítást. A visszaállított szolgáltatás csak akkor fogadható el, ha a padek, a szerzők, a revíziók és a pluginek visszatérnek, és a párhuzamos szerkesztések továbbra is konvergálnak. Közben figyeld a WebSocket-sessionöket, a revíziók számát, az adatbázisba írt adatokat és a pluginek futását, a leglassabb vagy leginkább korlátozott részt pedig alakítsd service-level alertté.

A kapunak negatív esetet is tartalmaznia kell: ideiglenesen vond meg a tesztidentitás hozzáférését a Postgreshez vagy egy másik támogatott adatbázishoz a tartós, többfelhasználós használathoz. Ellenőrizd, hogy az Etherpad jól használható hibát ad, miközben megőrzi az adatokat, állítsd vissza az érvényes állapotot, majd ismételd meg az ismert módon működő tranzakciót. A két eredmény megőrzésével elkerülhető, hogy egy felszínes health endpoint legyen az egyetlen éles környezeti bizonyíték.

Telepítsd az Etherpadet Dockupon a határok elvesztése nélkül

Az Etherpad esetében a Dockup leginkább az image és a tartós szolgáltatás közötti határon hasznos. A 9001-es útvonalat, a TLS-t, a titkos értékeket és a storage-ot a konténerek cseréje során is együtt tartja, függetlenül attól, hogy a compute a Dockupon vagy a csatolt szervereden fut.

Az alkalmazásismerettel zárd a folyamatot: állítsd be a publikus URL-t és a proxy WebSocket-támogatását; csatlakoztasd és teszteld a Postgrest vagy egy másik támogatott adatbázist a tartós, többfelhasználós használathoz; majd futtasd le ezt az ellenőrzést: nyiss meg egy padet két böngészőben, szerkeszd párhuzamosan, ellenőrizd a revíziókat, és exportáld az eredményt az előírt formátumban. Az eredményt tartsd meg deployment-ellenőrzésként, hogy a következő image-frissítést a viselkedés, ne pedig a konténer állapota alapján ítéld meg.

Gyakran ismételt kérdések

Mire van szüksége az Etherpadnek éles deploymenthez?

A 9001-es porton futó Etherpad-konténert egyetlen HTTPS-origin mögött irányítsd. A támogató hálózati követelmény a Postgres vagy egy másik támogatott adatbázis a tartós, többfelhasználós használathoz. Ne tekintsd késznek az Etherpadet addig, amíg nem tudsz egy padet megnyitni két böngészőben, párhuzamosan szerkeszteni, ellenőrizni a revíziókat és az eredményt az előírt formátumban exportálni.

Mely Etherpad-adatok tartoznak a mentésbe?

Tedd perzisztenssé a /opt/etherpad-lite/var útvonalat, és ugyanabba a recovery manifestbe vedd fel az adatbázist, a feltöltött plugineket és a beállításokat. Egy tiszta Etherpad-visszaállítás csak akkor sikeres, ha a padek, a szerzők, a revíziók és a pluginek visszatérnek, és a párhuzamos szerkesztések továbbra is konvergálnak.

Szüksége van az Etherpadnek HTTPS-re reverse proxy mögött?

A publikus Etherpad-originhez használj HTTPS-t, a 9001-es portot pedig tartsd a belső útvonalon. Helyesen alkalmazd az Etherpad beállítását: állítsd be a publikus URL-t és a proxy WebSocket-támogatását. Az Etherpad esetében a HTTPS védi a credentialeket vagy a felhasználói tartalmat átvitel közben, és konzisztenssé teszi az originérzékeny kliensviselkedést.

Hogyan kell tesztelni az Etherpad frissítését?

Állítsd vissza az aktuális Etherpad-á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 Etherpad pluginverzióit, a beállítások szintaxisát és az adatbázis-migrációkat együtt kell tesztelni. Tartsd meg az előző Etherpad-image-et addig, amíg nem tisztázod az adat-migráció és a rollback határát.