Indeks dziennikaDockup / notatka terenowa
Note / self-host-etherpad

Jak hostować Etherpad samodzielnie w 2026 roku: pady, pluginy i kopie zapasowe bazy danych

Praktyczny przewodnik po samodzielnym hostowaniu Etherpad obejmujący Docker, porty, dane trwałe, TLS, bezpieczeństwo, kopie zapasowe oraz problemy blokujące użycie produkcyjne. Z testami.

Jeśli próbujesz już hostować Etherpad samodzielnie, prawdopodobnie znasz ten frustrujący scenariusz: interfejs się wyświetla, ale sesje są rozłączane, ponieważ timeouty proxy są zbyt krótkie. Ponowne utworzenie kontenera rzadko naprawia niezgodność między URL-ami, stanem i zależnościami.

Ten przewodnik opiera się na jednym konkretnym kryterium ukończenia — otwarciu jednego pada w dwóch przeglądarkach, jednoczesnej edycji, sprawdzeniu rewizji i wyeksportowaniu wyniku w wymaganym formacie. Każdy wybór konfiguracji oceniamy względem tego kryterium, a nie na podstawie zielonej plakietki kontenera.

Wybierz najmniejszą użyteczną topologię Etherpad

Najmniejsza odpowiedzialnie zaprojektowana topologia Etherpad obejmuje jeden prywatny listener na porcie 9001, trasę ingress oraz udokumentowaną granicę stanu. Kontrakt sieciowy Etherpad wymaga PostgreSQL lub innej obsługiwanej bazy danych do trwałego użycia przez wielu użytkowników. Prywatne endpointy umieść w wewnętrznym DNS, zezwól wyłącznie na wymagane połączenia wychodzące i nadaj Etherpad ograniczone uprawnienia poświadczenia usługi.

Zweryfikuj topologię, prosząc czystego klienta o otwarcie jednego pada w dwóch przeglądarkach, jednoczesną edycję, sprawdzenie rewizji i wyeksportowanie wyniku w wymaganym formacie. Obserwuj sesje WebSocket, liczbę rewizji, zapisy w bazie danych i wykonywanie pluginów podczas testu. Wynik pokaże, czy kolejnego usprawnienia należy szukać w pamięci, storage, sieci czy osobnym workerze, zamiast zachęcać do arbitralnego zwiększania zasobów kontenera.

Zbuduj wymienny kontener Etherpad

Traktuj kontener jako wymienny runtime, a nie jako miejsce przechowywania danych źródłowych.

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

Dodaj sprawdzone ustawienia połączenia z PostgreSQL lub inną obsługiwaną bazą danych do trwałego użycia przez wielu użytkowników; w przypadku prywatnych usług używaj prywatnych nazw. Przed udostępnieniem kontenera sprawdź użytkownika kontenera, ścieżki z prawem zapisu i zbindowany listener. Wykonaj pełną operację — otwórz jeden pad w dwóch przeglądarkach, edytuj go jednocześnie, sprawdź rewizje i wyeksportuj wynik w wymaganym formacie — a następnie zapisz dokładne oznaczenie obrazu, który dał ten rezultat.

Nie pozwól, aby poprawne działanie proxy maskowało awarię aplikacji

Przeglądarka, klient API i Etherpad muszą korzystać z jednego originu. Aby to zapewnić, ustaw publiczny URL i obsługę WebSocket w proxy. Zachowaj oryginalny host i protokół, jednocześnie nie udostępniając portu 9001 jako konkurencyjnego publicznego adresu.

Przewodnik rozwiązywania problemów z niedostępną witryną pomaga odróżnić nieosiągalną trasę od odpowiadającej aplikacji. To rozróżnienie ma tutaj znaczenie: sesje są rozłączane, ponieważ timeouty proxy są zbyt krótkie. Tylko pierwszy problem można naprawić zmianami w ingressie; drugi wymaga sprawdzenia logów Etherpad, stanu lub obciążenia.

Zaprojektuj odtwarzanie Etherpad przed uruchomieniem

Zabezpiecz stan Etherpad, zanim zaczniesz optymalizować jego kontener. Wymagany zestaw obejmuje bazę danych, przesłane pluginy i ustawienia. Zamontuj /opt/etherpad-lite/var przed bootstrapem, zapisz nieszkodliwe dane przykładowe i wymień kontener, aby potwierdzić, że ta ścieżka rzeczywiście jest trwała. Jeśli wiele magazynów musi zachować spójność, udokumentuj kolejność wstrzymywania zapisów i wykonywania kopii zapasowych.

Przechowuj kopie poza serwerem wdrożeniowym i szyfruj materiały zawierające poświadczenia lub prywatne treści. Odzyskiwanie kończy się powodzeniem, gdy wracają pady, autorzy, rewizje i pluginy, a jednoczesne edycje nadal się poprawnie synchronizują. Różnicę między trwałym montowaniem a niezależną kopią opisano w artykule trwały storage i snapshoty.

Wybierz granicę zaufania Etherpad

Zamknij okno bootstrapu, gdy tylko pojawi się pierwszy zaufany administrator. Konkretnym zagrożeniem w Etherpad jest użycie znanego hasła administratora lub pozostawienie padów z prawem zapisu dla wszystkich; bezpieczniejsza granica polega na ustawieniu rzeczywistego hasła administratora, określeniu, kto może tworzyć pady, i niezakładaniu, że nieoczywisty URL pada jest prywatny.

Natychmiast zastąp przykładową wartość ADMIN_PASSWORD, przechowuj ją poza obrazem i rotuj jak poświadczenie administratora, jeśli zostanie ujawniona. Prywatna sieć powinna przenosić poświadczenia zależności, a role wewnątrz Etherpad powinny przyznawać najmniejszy użyteczny zakres działania. Nie zapisuj w rutynowych logach wrażliwych treści żądań ani odpowiedzi dostawców.

Aktualizuj Etherpad bez zgadywania

Obserwuj operacje wykonywane przez Etherpad: sesje WebSocket, liczbę rewizji, zapisy w bazie danych i wykonywanie pluginów. Ustaw limity z zapasem odpowiednim do tego obciążenia i unikaj probe'u liveness, który konkuruje z obsługą tych operacji. Kontrola operatorska powinna nadal zgodnie z harmonogramem próbować otworzyć jeden pad w dwóch przeglądarkach, edytować go jednocześnie, sprawdzić rewizje i wyeksportować wynik w wymaganym formacie.

Podczas aktualizacji pamiętaj, że wersje pluginów Etherpad, składnia ustawień i migracje bazy danych należy testować razem. Wdróż kandydującą wersję względem odtworzonej kopii i powtórz znany test. Jeśli sesje są rozłączane, ponieważ timeouty proxy są zbyt krótkie, użyj logów runtime i rzeczywistego żądania sieciowego, aby ustalić, które założenie uległo zmianie.

Co musi przejść przed pojawieniem się rzeczywistych danych Etherpad

W przypadku Etherpad zdefiniuj przed uruchomieniem znaną poprawną transakcję: otwórz jeden pad w dwóch przeglądarkach, edytuj go jednocześnie, sprawdź rewizje i wyeksportuj wynik w wymaganym formacie. Umieść jej wymagania wstępne, oczekiwaną odpowiedź i kroki czyszczenia w kontroli wersji, bez wartości sekretów. Przypnij obraz użyty do ustanowienia tego punktu odniesienia.

Użyj transakcji do zweryfikowania wymiany oraz niezależnego odtwarzania. Odtworzona usługa jest akceptowalna tylko wtedy, gdy wracają pady, autorzy, rewizje i pluginy, a jednoczesne edycje nadal się poprawnie synchronizują. Jednocześnie obserwuj sesje WebSocket, liczbę rewizji, zapisy w bazie danych i wykonywanie pluginów, a następnie przekształć najwolniejszy lub najbardziej ograniczony element w alert na poziomie usługi.

Bramka musi obejmować również przypadek negatywny: tymczasowo odbierz tożsamości testowej dostęp do PostgreSQL lub innej obsługiwanej bazy danych do trwałego użycia przez wielu użytkowników. Potwierdź, że Etherpad generuje możliwy do wykorzystania błąd, zachowując dane, przywróć prawidłowy stan i powtórz znaną poprawną transakcję. Zachowanie obu wyników zapobiega sytuacji, w której powierzchowny endpoint health staje się jedynym dowodem gotowości produkcyjnej.

Wdróż Etherpad na Dockup bez utraty jego granic

W przypadku Etherpad Dockup jest najbardziej użyteczny na granicy między obrazem a trwałą usługą. Utrzymuje trasę do portu 9001, TLS, wartości sekretów i storage podczas wymiany kontenerów, niezależnie od tego, czy obliczenia są realizowane przez Dockup, czy przez podłączony serwer.

Zakończ wdrożenie, wykorzystując wiedzę o aplikacji: ustaw publiczny URL i obsługę WebSocket w proxy; połącz się z PostgreSQL lub inną obsługiwaną bazą danych do trwałego użycia przez wielu użytkowników i przetestuj połączenie; następnie wykonaj tę weryfikację: otwórz jeden pad w dwóch przeglądarkach, edytuj go jednocześnie, sprawdź rewizje i wyeksportuj wynik w wymaganym formacie. Zachowaj wynik jako kontrolę wdrożenia, aby kolejna aktualizacja obrazu była oceniana na podstawie działania, a nie statusu kontenera.

Często zadawane pytania

Czego Etherpad potrzebuje do wdrożenia produkcyjnego?

Przekieruj kontener Etherpad na porcie 9001 przez jeden origin HTTPS. Wymaganiem sieciowym po stronie zaplecza jest PostgreSQL lub inna obsługiwana baza danych do trwałego użycia przez wielu użytkowników. Nie uznawaj Etherpad za gotowy, dopóki nie możesz otworzyć jednego pada w dwóch przeglądarkach, edytować go jednocześnie, sprawdzić rewizji i wyeksportować wyniku w wymaganym formacie.

Które dane Etherpad należy uwzględnić w kopii zapasowej?

Utrwal /opt/etherpad-lite/var i uwzględnij bazę danych, przesłane pluginy oraz ustawienia w tym samym manifeście odtwarzania. Czyste odtworzenie Etherpad kończy się powodzeniem tylko wtedy, gdy wracają pady, autorzy, rewizje i pluginy, a jednoczesne edycje nadal się poprawnie synchronizują.

Czy Etherpad wymaga HTTPS za reverse proxy?

Używaj HTTPS dla publicznego originu Etherpad i pozostaw port 9001 na trasie wewnętrznej. Zastosuj prawidłowo ustawienie Etherpad: ustaw publiczny URL i obsługę WebSocket w proxy. W przypadku Etherpad HTTPS chroni poświadczenia lub treści użytkowników podczas przesyłania i zapewnia spójne działanie klienta zależne od originu.

Jak testować aktualizację Etherpad?

Odtwórz bieżący stan Etherpad w odizolowanym wdrożeniu, zastosuj kandydującą wersję i powtórz transakcję akceptacyjną. Zwróć szczególną uwagę na to, że wersje pluginów Etherpad, składnia ustawień i migracje bazy danych należy testować razem. Zachowaj poprzedni obraz Etherpad do czasu poznania granic migracji danych i rollbacku.