Индекс журналаDockup / заметка с места
Note / self-host-dokuwiki

Как разместить DokuWiki самостоятельно в 2026 году: файловое хранилище, ACL и резервные копии

Практическое руководство по самостоятельному размещению DokuWiki: Docker, порты, постоянное хранение данных, TLS, безопасность, резервное копирование и проблемы, мешающие использованию в production. С проверками.

Рассматривайте DokuWiki как небольшую систему, а не как Docker image. Пользовательская цель DokuWiki понятна: wiki на основе файлов, которой не нужна база данных; deployment можно считать приемлемым только после того, как вы заменили учётные данные setup, отредактировали страницу, загрузили media-файл, применили ACL, просмотрели revision и восстановили старую версию.

Это различие позволяет выявить типичную проблему, с которой операторы сталкиваются после локального тестирования: права на файлы не позволяют сохранять страницы, хотя UI загружается. Кроме того, так план резервного копирования и upgrade становится достаточно конкретным для тестирования.

Порты, процессы и приватные сервисы

Начните с network namespace DokuWiki: его web listener использует порт 80, а не host port, скопированный из tutorial для ноутбука. Локальное runtime-требование — persistent config volume, содержащий страницы, media-файлы и ACL. Зафиксируйте ожидаемую capacity, владельца и failure mode, а не оставляйте их значениями по умолчанию image.

После выполнения требования запустите полный сценарий — замените учётные данные setup, отредактируйте страницу, загрузите media-файл, примените ACL, просмотрите revision и восстановите старую версию. Запишите logs и measurements для filesystem metadata, media volume, search indexing и PHP workers. Эти данные станут первой заведомо рабочей архитектурой и позволят тестировать последующие перемещения между Dockup compute и подключённым сервером.

Проверки отказоустойчивости DokuWiki

Работающий container необходима, но недостаточна. Service-level indicator — успешное выполнение сценария «заменить учётные данные setup, отредактировать страницу, загрузить media-файл, применить ACL, просмотреть revision и восстановить старую версию», а наиболее вероятные pressure signals — filesystem metadata, media volume, search indexing и PHP workers.

Change control важен, поскольку plugins и templates могут отставать от релизов DokuWiki, даже если обычные файлы страниц остаются читаемыми. Сохраните старый image, тестируйте migrations на скопированном state и задокументируйте, поддерживается ли rollback после изменения schema. Если права на файлы не позволяют сохранять страницы, хотя UI загружается, диагностируйте первую boundary, отличающуюся от рабочей среды.

Зафиксируйте заведомо рабочий deployment DokuWiki

Release candidate для DokuWiki заслуживает трафика после выполнения фиксированного сценария: заменить учётные данные setup, отредактировать страницу, загрузить media-файл, применить ACL, просмотреть revision и восстановить старую версию. Зафиксируйте image digest, effective non-secret configuration, public origin и timestamps этого сценария. Test data должны быть disposable, но достаточно реалистичными, чтобы задействовать тот же path, что и пользовательские операции.

Запустите его после замены runtime, затем пересоберите сервис из pages, media, metadata, users, ACLs и plugins. Recovery считается успешным, если восстановлены pages, revisions, media, users, ACLs и plugins, а защищённая страница остаётся защищённой. Сравните resource measurements для filesystem metadata, media volume, search indexing и PHP workers с предыдущим релизом и до promotion разберитесь с существенным drift.

Наконец, выполните контролируемый failure test: отправьте безопасный input рядом с resource или format limit, связанным с этой boundary: права на файлы не позволяют сохранять страницы, хотя UI загружается. Убедитесь, что DokuWiki объясняет failure, не повреждает существующий state и возобновляет работу после восстановления корректного условия. Сохраните redacted log excerpt и recovery time. Вместе эти проверки охватывают behavior, durability и operability, а не только uptime процесса.

Запустите первый instance, близкий к production

Используйте команду, в которой явно указаны все важные параметры. Этот baseline привязывает DokuWiki к host loopback, добавляет известные data mounts и передаёт первую обязательную настройку. Перед открытием доступа подтвердите локальное требование: persistent config volume, содержащий pages, media и ACLs.

docker run -d \
  --name dokuwiki \
  --restart unless-stopped \
  -p 127.0.0.1:80:80 \
  -v dokuwiki-data:/config \
  lscr.io/linuxserver/dokuwiki:latest

Замените floating tags на протестированную версию или digest. После запуска проверьте docker logs --tail 200 dokuwiki и убедитесь, что процесс слушает порт 80. Затем выполните acceptance action для DokuWiki; response корневой страницы не доказывает успешность полного сценария: замены учётных данных setup, редактирования страницы, загрузки media-файла, применения ACL, просмотра revision и восстановления старой версии.

Volumes — только первый уровень восстановления

Для DokuWiki безопасность redeploy начинается с pages, media, metadata, users, ACLs и plugins. Подключите /config до bootstrap, запишите безопасные sample data и замените container, чтобы доказать фактическую persistence этого path. Проверьте path, заменив container, пока безопасные sample data существуют; это выявляет mounts, указанные на каталог на один уровень выше или ниже.

Затем протестируйте disaster recovery на чистом host. Где необходимо, используйте application-consistent database export и убедитесь, что восстановлены pages, revisions, media, users, ACLs и plugins, а защищённая страница остаётся защищённой. В руководстве по резервному копированию базы данных с проверенным восстановлением задана более строгая цель, чем простая проверка создания archive file.

Назначьте для DokuWiki один canonical address

Выпуск TLS — только половина DokuWiki route. Обслуживайте wiki по HTTPS и задайте её canonical base URL. Направляйте traffic внутри на порт 80 и передавайте внешнюю scheme, чтобы generated URLs и secure cookies оставались согласованными.

Проверяйте полный сценарий DokuWiki из чистой network environment, а не только root page. Ошибку 502 или certificate failure можно изолировать с помощью автоматической настройки домена и TLS. Если traffic достигает процесса, а права на файлы не позволяют сохранять страницы, хотя UI загружается, диагностируйте это условие там, где оно возникает, вместо добавления новых redirects.

Закройте временный доступ к setup

Моделируйте угрозы для выполняемого DokuWiki действия, а не только для login form. Здесь главная опасность — оставить открытыми installer или настройки регистрации. Установите эту boundary: удалите доступ к installer, проверьте регистрацию и сохраняйте ACL files вместе с содержимым страниц.

В этом baseline DokuWiki не требует обязательного bootstrap secret; защитите фактическую administrator account или upstream authentication. Не устраняйте permission error, запуская container от root или предоставляя широкий mount host. Resource limits также относятся к security design, если пользователи могут создавать нагрузку на filesystem metadata, media volume, search indexing и PHP workers.

Используйте Dockup для platform layer

Template Dockup должен описывать image, порт 80, mounts, health timing, domain, TLS и secret delivery. Dockup должен сохранять runtime settings DokuWiki, пока оператор подтверждает это локальное требование: persistent config volume, содержащий pages, media и ACLs. Один и тот же deployment может использовать Dockup servers или capacity, подключённую заказчиком.

После того как route заработал, примените public setting и попробуйте заменить учётные данные setup, отредактировать страницу, загрузить media-файл, применить ACL, просмотреть revision и восстановить старую версию. Создавайте резервные копии pages, media, metadata, users, ACLs и plugins и включите recovery exercise в operating plan; эти обязанности DokuWiki остаются актуальными после provisioning infrastructure.

Часто задаваемые вопросы

Что нужно DokuWiki для production deployment?

Направьте container DokuWiki через один HTTPS origin на порт 80. Локальное runtime-требование — persistent config volume, содержащий pages, media и ACLs. Не объявляйте DokuWiki готовой, пока не сможете заменить учётные данные setup, отредактировать страницу, загрузить media-файл, применить ACL, просмотреть revision и восстановить старую версию.

Какие данные DokuWiki должны входить в backup?

Сохраняйте /config и включайте pages, media, metadata, users, ACLs и plugins в один recovery manifest. Чистое восстановление DokuWiki считается успешным только после возврата pages, revisions, media, users, ACLs и plugins, при этом защищённая страница должна оставаться защищённой.

Требуется ли DokuWiki HTTPS за reverse proxy?

Используйте HTTPS для public origin DokuWiki, а порт 80 оставьте во внутреннем route. Корректно примените настройку DokuWiki: обслуживайте wiki по HTTPS и задайте её canonical base URL. Для DokuWiki HTTPS защищает credentials или пользовательские данные при передаче и обеспечивает согласованное поведение клиентов, зависящее от origin.

Как тестировать upgrade DokuWiki?

Восстановите текущий state DokuWiki в isolated deployment, примените candidate version и повторите acceptance transaction. Учитывайте, что plugins и templates могут отставать от релизов DokuWiki, даже если обычные файлы страниц остаются читаемыми. Сохраняйте предыдущий DokuWiki image, пока не будут понятны границы data migration и rollback.