Как да хоствате Etherpad самостоятелно през 2026 г.: падове, плъгини и резервни копия на базата данни

Ако вече сте опитвали да хоствате Etherpad самостоятелно, вероятно ви е познато това неприятно състояние: интерфейсът се зарежда, но сесиите прекъсват, защото timeout-ите на proxy са твърде кратки. Пресъздаването на контейнера рядко решава несъответствие между URL адреси, състояние и зависимости.

Това ръководство използва един конкретен критерий за завършеност — отваряне на един пад в два браузъра, едновременно редактиране, преглед на ревизиите и експортиране на резултата в изисквания формат. Всяко конфигурационно решение се оценява спрямо този критерий, а не спрямо зелената значка на контейнера.

Изберете минималната работеща топология на Etherpad

Минималната отговорна топология на Etherpad включва един частен listener на 9001, ingress route и документирана граница на състоянието. Мрежовото изискване за Etherpad е Postgres или друга поддържана база данни за надеждна работа с множество потребители. Дръжте частните endpoint-и във вътрешен DNS, разрешавайте само необходимите изходящи заявки и дайте на Etherpad service credential с ограничен обхват.

Валидирайте топологията, като накарате чист клиент да отвори един пад в два браузъра, да редактира едновременно, да прегледа ревизиите и да експортира резултата в изисквания формат. Наблюдавайте WebSocket сесиите, броя на ревизиите, записите в базата данни и изпълнението на плъгините, докато тестът протича. Резултатът ще покаже дали следващото подобрение трябва да бъде в паметта, storage-а, мрежата или в отделен worker, вместо да ви насърчава към произволно оразмеряване на контейнера.

Създайте заменяем Etherpad контейнер

Използвайте контейнера като заменяем runtime, а не като място, в което се съхранява истината.

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

Добавете прегледаните настройки за свързване с Postgres или друга поддържана база данни за надеждна работа с множество потребители; използвайте частни имена за частните услуги. Проверете потребителя на контейнера, пътищата с права за запис и bind-натия listener, преди да го изложите. Изпълнете цялото действие — отворете един пад в два браузъра, редактирайте едновременно, прегледайте ревизиите и експортирайте резултата в изисквания формат — и запазете точната референция към image-а, с който е получен резултатът.

Не позволявайте успехът на proxy да прикрива проблем в приложението

Браузърът, API клиентът и Etherpad трябва да използват един и същ origin. За да постигнете това, задайте публичния URL и активирайте proxy поддръжка за WebSocket. Запазете оригиналните host и protocol, като същевременно не допускайте порт 9001 да се превърне в конкуриращ публичен адрес.

Ръководството за отстраняване на проблеми при недостъпен сайт помага да разграничите недостъпен route от приложение, което отговаря. Това разграничение е важно тук: сесиите прекъсват, защото timeout-ите на proxy са твърде кратки. Само първият проблем се решава с промени в ingress; вторият изисква проверка на логовете, състоянието или натоварването на Etherpad.

Проектирайте възстановяването на Etherpad преди стартирането

Защитете състоянието на Etherpad, преди да оптимизирате контейнера. Необходимият набор включва базата данни, качените плъгини и настройките. Монтирайте /opt/etherpad-lite/var преди bootstrap, запишете безобидни примерни данни и заменете контейнера, за да докажете, че този път наистина е persistent. Ако няколко хранилища трябва да останат съгласувани, документирайте реда, в който се спират записите и се създават резервните копия.

Съхранявайте копия извън сървъра за deployment и криптирайте материалите, съдържащи credentials или private content. Възстановяването е успешно, когато падовете, авторите, ревизиите и плъгините се върнат и едновременните редакции продължат да се синхронизират коректно. Разликата между persistent mount и независимо копие е разгледана в persistent storage и snapshots.

Изберете границата на доверие за Etherpad

Затворете bootstrap прозореца веднага щом съществува първият доверен администратор. Конкретният капан при Etherpad е да доставите известна admin парола или да оставите падовете достъпни за запис от всички; по-сигурната граница е да зададете реална admin парола, да решите кой може да създава падове и да не приемате, че труден за отгатване URL на пад е частен.

Заменете примерната ADMIN_PASSWORD незабавно, съхранявайте я извън image-а и я сменяйте като admin credential, ако бъде разкрита. Частната мрежа трябва да пренася credentials за зависимостите, а ролите в Etherpad трябва да предоставят минималното необходимо действие. Не записвайте чувствителни request body-та и отговори от providers в стандартните логове.

Ъпгрейдвайте Etherpad без предположения

Наблюдавайте работата, която Etherpad извършва: WebSocket сесиите, броя на ревизиите, записите в базата данни и изпълнението на плъгините. Задайте лимити с достатъчен headroom за тази работа и избягвайте liveness probe, която се конкурира с нея. Операторската проверка трябва по график да се опитва да отвори един пад в два браузъра, да редактира едновременно, да прегледа ревизиите и да експортира резултата в изисквания формат.

При обновявания помнете, че версиите на плъгините на Etherpad, синтаксисът на настройките и миграциите на базата данни трябва да се тестват заедно. Deploy-вайте кандидата върху възстановено копие и повторете познатия тест. Ако сесиите прекъсват, защото timeout-ите на proxy са твърде кратки, използвайте runtime логовете и реалната мрежова заявка, за да откриете кое предположение се е променило.

Какво трябва да премине успешно, преди да постъпят реални данни в Etherpad

За Etherpad дефинирайте позната успешна транзакция преди стартирането: отворете един пад в два браузъра, редактирайте едновременно, прегледайте ревизиите и експортирайте резултата в изисквания формат. Поставете нейните prerequisites, очаквания отговор и стъпките за почистване под version control, без secret стойности. Фиксирайте image-а, използван за създаването на този reference.

Използвайте транзакцията, за да валидирате замяна и независимо възстановяване. Възстановената услуга е приемлива само когато падовете, авторите, ревизиите и плъгините се върнат и едновременните редакции продължат да се синхронизират коректно. Същевременно наблюдавайте WebSocket сесиите, броя на ревизиите, записите в базата данни и изпълнението на плъгините и превърнете най-бавната или най-ограничената част в alert на ниво услуга.

Gate-ът трябва да включва и негативен сценарий: временно откажете на тестовата identity достъп до Postgres или друга поддържана база данни за надеждна работа с множество потребители. Потвърдете, че Etherpad генерира полезна грешка, като същевременно запазва данните, възстановете валидното състояние и повторете познатата успешна транзакция. Съхраняването и на двата резултата не позволява един повърхностен health endpoint да се превърне в единственото production доказателство.

Deploy-вайте Etherpad в Dockup, без да губите границите му

При Etherpad Dockup е най-полезен на границата между image и durable услуга. Той запазва route-а към 9001, TLS, secret стойностите и storage-а свързани при замяна на контейнерите, независимо дали compute ресурсите са в Dockup или на вашия attached server.

Завършете с познания за приложението: задайте публичния URL и активирайте proxy поддръжка за WebSocket; свържете и тествайте Postgres или друга поддържана база данни за надеждна работа с множество потребители; и изпълнете следната проверка: отворете един пад в два браузъра, редактирайте едновременно, прегледайте ревизиите и експортирайте резултата в изисквания формат. Запазете резултата като deployment check, така че следващото обновяване на image-а да се оценява по поведението, а не по статуса на контейнера.

Често задавани въпроси

Какво е необходимо на Etherpad за production deployment?

Насочете контейнера на Etherpad през един HTTPS origin на порт 9001. Поддържащото мрежово изискване е Postgres или друга поддържана база данни за надеждна работа с множество потребители. Не обявявайте Etherpad за готов, преди да можете да отворите един пад в два браузъра, да редактирате едновременно, да прегледате ревизиите и да експортирате резултата в изисквания формат.

Кои данни на Etherpad трябва да бъдат включени в резервното копие?

Направете /opt/etherpad-lite/var persistent и включете базата данни, качените плъгини и настройките в един и същ recovery manifest. Чистото възстановяване на Etherpad е успешно само когато падовете, авторите, ревизиите и плъгините се върнат и едновременните редакции продължат да се синхронизират коректно.

Необходим ли е HTTPS за Etherpad зад reverse proxy?

Използвайте HTTPS за публичния origin на Etherpad и оставете порт 9001 във вътрешния route. Приложете настройката на Etherpad коректно: задайте публичния URL и активирайте proxy поддръжка за WebSocket. При Etherpad HTTPS защитава credentials или потребителското съдържание при пренос и поддържа съгласувано client поведение, зависимо от origin-а.

Как трябва да се тества ъпгрейд на Etherpad?

Възстановете текущото състояние на Etherpad в изолирана среда, приложете кандидат-версията и повторете acceptance транзакцията. Обърнете специално внимание, защото версиите на плъгините на Etherpad, синтаксисът на настройките и миграциите на базата данни трябва да се тестват заедно. Запазете предишния Etherpad image, докато не изясните границите на миграцията на данните и rollback-а.