Indexul jurnaluluiDockup / notă de teren
Note / self-host-etherpad

Cum găzduiești singur Etherpad în 2026: pad-uri, pluginuri și backup-uri pentru baza de date

Un ghid practic pentru găzduirea proprie a Etherpad, care acoperă Docker, porturi, date persistente, TLS, securitate, backup-uri și problemele care împiedică utilizarea în producție. Include verificări.

Dacă ai încercat deja să găzduiești singur Etherpad, probabil îți este familiară situația frustrantă: interfața apare, dar sesiunile se deconectează deoarece timeout-urile proxy-ului sunt prea scurte. Recrearea containerului rezolvă rareori o neconcordanță între URL-uri, stare și dependențe.

Acest ghid folosește un singur criteriu concret de finalizare — deschiderea unui pad în două browsere, editarea simultană, inspectarea reviziilor și exportul rezultatului într-un format obligatoriu. Fiecare alegere de configurare este evaluată în raport cu acest criteriu, nu în funcție de o insignă verde a containerului.

Alege cea mai mică topologie Etherpad viabilă

Cea mai mică topologie Etherpad responsabilă conține un listener privat pe portul 9001, o rută de ingress și o limită de stare documentată. Contractul de rețea pentru Etherpad este Postgres sau o altă bază de date acceptată, necesară pentru utilizarea durabilă de către mai mulți utilizatori. Păstrează endpoint-urile private în DNS intern, permite doar apelurile outbound necesare și oferă Etherpad un service credential cu permisiuni limitate.

Validează topologia cerând unui client curat să deschidă un pad în două browsere, să editeze simultan, să inspecteze reviziile și să exporte rezultatul într-un format obligatoriu. Monitorizează sesiunile WebSocket, numărul de revizii, scrierile în baza de date și execuția pluginurilor în timpul rulării. Rezultatul îți arată dacă următoarea îmbunătățire trebuie făcută la nivel de memorie, stocare, rețea sau într-un worker separat, în loc să te încurajeze să dimensionezi arbitrar containerul.

Construiește un container Etherpad care poate fi înlocuit

Folosește containerul ca runtime care poate fi înlocuit, nu ca sursă a adevărului.

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

Adaugă setările de conexiune verificate pentru Postgres sau o altă bază de date acceptată, necesară pentru utilizarea durabilă de către mai mulți utilizatori; folosește nume private pentru serviciile private. Inspectează utilizatorul containerului, căile care permit scrierea și listenerul asociat înainte de a-l expune. Rulează acțiunea completă — deschide un pad în două browsere, editează simultan, inspectează reviziile și exportă rezultatul într-un format obligatoriu — și salvează referința exactă a imaginii care a produs rezultatul.

Împiedică succesul proxy-ului să ascundă o defecțiune a aplicației

Browserul, clientul API și Etherpad trebuie să folosească aceeași origine. Pentru a garanta acest lucru, setează URL-ul public și suportul proxy pentru WebSocket. Păstrează host-ul și protocolul originale, menținând în același timp portul 9001 indisponibil ca adresă publică alternativă.

Ghidul de depanare pentru site-uri indisponibile te ajută să diferențiezi o rută inaccesibilă de o aplicație care răspunde. Această distincție contează aici: sesiunile se deconectează deoarece timeout-urile proxy-ului sunt prea scurte. Doar primul caz se rezolvă prin modificări în ingress; al doilea necesită inspectarea logurilor Etherpad, a stării sau a încărcării de lucru.

Proiectează restaurarea Etherpad înainte de lansare

Protejează starea Etherpad înainte de a optimiza containerul. Setul necesar este format din baza de date, pluginurile încărcate și setări. Montează /opt/etherpad-lite/var înainte de bootstrap, scrie date de test inofensive și înlocuiește containerul pentru a demonstra că acea cale este într-adevăr persistentă. Dacă mai multe sisteme de stocare trebuie să rămână sincronizate, documentează ordinea în care sunt suspendate scrierile și realizate backup-urile.

Păstrează copii în afara serverului de deployment și criptează materialele care conțin credentiale sau conținut privat. Recuperarea este reușită atunci când pad-urile, autorii, reviziile și pluginurile revin, iar editările concurente continuă să convergă. Diferența dintre un mount persistent și o copie independentă este prezentată în stocarea persistentă și snapshot-urile.

Alege limita de încredere pentru Etherpad

Închide fereastra de bootstrap imediat ce există primul administrator de încredere. Capcana concretă în Etherpad este să livrezi o parolă de administrator cunoscută sau să lași pad-urile editabile de oricine; limita mai sigură este să setezi o parolă reală de administrator, să decizi cine poate crea pad-uri și să nu presupui că un URL de pad greu de ghicit este privat.

Înlocuiește imediat valoarea de exemplu pentru ADMIN_PASSWORD, stocheaz-o în afara imaginii și rotește-o ca pe un credential de administrator dacă este expusă. Rețeaua privată ar trebui să transporte credentialele dependențelor, iar rolurile din Etherpad ar trebui să acorde cea mai mică permisiune utilă. Nu păstra în logurile obișnuite body-urile sensibile ale request-urilor și răspunsurile furnizorilor.

Actualizează Etherpad fără presupuneri

Monitorizează activitatea desfășurată de Etherpad: sesiunile WebSocket, numărul de revizii, scrierile în baza de date și execuția pluginurilor. Setează limite cu suficient headroom pentru această activitate și evită un liveness probe care concurează cu ea. Verificarea operatorului ar trebui în continuare să încerce, periodic, să deschidă un pad în două browsere, să editeze simultan, să inspecteze reviziile și să exporte rezultatul într-un format obligatoriu.

Pentru actualizări, reține că versiunile pluginurilor Etherpad, sintaxa setărilor și migrările bazei de date trebuie testate împreună. Fă deployment pentru candidat folosind o copie recuperată și repetă testul cunoscut. Dacă sesiunile se deconectează deoarece timeout-urile proxy-ului sunt prea scurte, folosește logurile runtime și request-ul de rețea efectiv pentru a identifica presupunerea care s-a schimbat.

Ce trebuie să treacă înainte ca datele Etherpad reale să ajungă în sistem

Pentru Etherpad, definește o tranzacție cunoscută ca funcțională înainte de lansare: deschide un pad în două browsere, editează simultan, inspectează reviziile și exportă rezultatul într-un format obligatoriu. Pune în version control precondițiile, răspunsul așteptat și pașii de curățare, fără valori secrete. Fixează imaginea folosită pentru stabilirea acestei referințe.

Folosește tranzacția pentru a valida o înlocuire și o restaurare independentă. Serviciul restaurat este acceptabil doar atunci când pad-urile, autorii, reviziile și pluginurile revin, iar editările concurente continuă să convergă. În același timp, monitorizează sesiunile WebSocket, numărul de revizii, scrierile în baza de date și execuția pluginurilor și transformă componenta cea mai lentă sau mai constrânsă într-o alertă la nivel de serviciu.

Poarta de validare are nevoie și de un caz negativ: refuză temporar identității de test accesul la Postgres sau la o altă bază de date acceptată, necesară pentru utilizarea durabilă de către mai mulți utilizatori. Confirmă că Etherpad produce o eroare utilă, păstrând în același timp datele, restabilește condiția validă și repetă tranzacția cunoscută ca funcțională. Păstrarea ambelor rezultate împiedică un endpoint superficial de health să devină singura dovadă pentru producție.

Implementează Etherpad pe Dockup fără să-i pierzi limitele

Pentru Etherpad, Dockup este cel mai util la granița dintre o imagine și un serviciu durabil. Păstrează asociate ruta către portul 9001, TLS, valorile secrete și stocarea pe durata înlocuirilor de containere, indiferent dacă procesarea aparține Dockup sau serverului tău atașat.

Finalizează cu cunoștințe despre aplicație: setează URL-ul public și suportul proxy pentru WebSocket; conectează și testează Postgres sau o altă bază de date acceptată, necesară pentru utilizarea durabilă de către mai mulți utilizatori; și rulează această verificare: deschide un pad în două browsere, editează simultan, inspectează reviziile și exportă rezultatul într-un format obligatoriu. Păstrează rezultatul ca verificare de deployment, astfel încât următoarea actualizare a imaginii să fie evaluată prin comportament, nu prin starea containerului.

Întrebări frecvente

De ce are nevoie Etherpad pentru un deployment în producție?

Direcționează containerul Etherpad de pe portul 9001 printr-o singură origine HTTPS. Cerința de rețea pentru serviciul auxiliar este Postgres sau o altă bază de date acceptată, necesară pentru utilizarea durabilă de către mai mulți utilizatori. Nu considera Etherpad pregătit până când nu poți deschide un pad în două browsere, edita simultan, inspecta reviziile și exporta rezultatul într-un format obligatoriu.

Ce date Etherpad trebuie incluse într-un backup?

Persistă /opt/etherpad-lite/var și include baza de date, pluginurile încărcate și setările în același manifest de recuperare. O restaurare Etherpad curată trece doar atunci când pad-urile, autorii, reviziile și pluginurile revin, iar editările concurente continuă să convergă.

Are Etherpad nevoie de HTTPS în spatele unui reverse proxy?

Folosește HTTPS pentru originea publică Etherpad și păstrează portul 9001 pe ruta internă. Aplică corect setarea Etherpad: setează URL-ul public și suportul proxy pentru WebSocket. Pentru Etherpad, HTTPS protejează credentialele sau conținutul utilizatorilor în tranzit și menține consecvent comportamentul clientului dependent de origine.

Cum trebuie testat un upgrade Etherpad?

Restaurează starea actuală Etherpad într-un deployment izolat, aplică versiunea candidată și repetă tranzacția de acceptanță. Acordă o atenție deosebită acestui aspect, deoarece versiunile pluginurilor Etherpad, sintaxa setărilor și migrările bazei de date trebuie testate împreună. Păstrează imaginea Etherpad anterioară până când limitele migrării datelor și ale rollback-ului sunt clare.