Як самостійно розгорнути DokuWiki у 2026 році: файлове сховище, ACL і резервні копії

Розглядайте DokuWiki як невелику систему, а не як Docker-образ. Користувацька мета DokuWiki зрозуміла: wiki на основі файлів, якій не потрібна база даних; розгортання можна вважати прийнятним лише тоді, коли ви можете замінити облікові дані початкового налаштування, відредагувати сторінку, завантажити медіафайл, застосувати ACL, переглянути редакцію та відновити попередню версію.

Ця відмінність допомагає виявити проблему, з якою оператори стикаються після локального тестування: права власності на файли не дають зберігати сторінки, хоча UI завантажується. Вона також робить план резервного копіювання й оновлення достатньо конкретним для тестування.

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

Почніть із мережевого простору імен DokuWiki: його вебслухач працює на порту 80, а не на порту хоста, скопійованому з навчального матеріалу для ноутбука. Вимога локального середовища виконання — постійний том конфігурації, що містить сторінки, медіафайли та ACL. Задокументуйте очікувану місткість, права власності та сценарій відмови, а не залишайте їх значеннями за замовчуванням образу.

Після виконання вимоги запустіть повний сценарій — замініть облікові дані початкового налаштування, відредагуйте сторінку, завантажте медіафайл, застосуйте ACL, перегляньте редакцію та відновіть попередню версію. Зберігайте журнали й вимірювання для метаданих файлової системи, тому медіафайлів, індексування пошуку та PHP-воркерів. Ці дані стануть першою архітектурою, яка гарантовано працює, і зроблять подальше переміщення між обчислювальними ресурсами Dockup та підключеним сервером тестованим.

Перевірки відмов DokuWiki

Працюючий контейнер необхідний, але цього недостатньо. Індикатором на рівні сервісу є успішне виконання сценарію «замінити облікові дані початкового налаштування, відредагувати сторінку, завантажити медіафайл, застосувати ACL, переглянути редакцію та відновити попередню версію», а ймовірними сигналами перевантаження — метадані файлової системи, том медіафайлів, індексування пошуку та PHP-воркери.

Контроль змін має значення, оскільки плагіни й шаблони можуть відставати від релізів DokuWiki, навіть якщо звичайні файли сторінок залишаються читабельними. Збережіть старий образ, тестуйте міграції на копії стану й задокументуйте, чи підтримується rollback після зміни схеми. Якщо права власності на файли не дають зберігати сторінки, хоча UI завантажується, діагностуйте першу межу, яка відрізняється від робочого середовища.

Зафіксуйте розгортання DokuWiki, яке гарантовано працює

Кандидат на реліз для DokuWiki має отримати трафік, успішно виконавши фіксований сценарій: замінити облікові дані початкового налаштування, відредагувати сторінку, завантажити медіафайл, застосувати ACL, переглянути редакцію та відновити попередню версію. Зафіксуйте digest образу, ефективну конфігурацію без секретів, публічний origin і часові позначки цього сценарію. Тестові дані мають бути одноразовими, але достатньо реалістичними, щоб перевіряти той самий шлях, яким користуються користувачі.

Запустіть його після заміни середовища виконання, а потім відновіть сервіс зі сторінок, медіафайлів, метаданих, користувачів, ACL і плагінів. Відновлення вважається успішним, коли повернулися сторінки, редакції, медіафайли, користувачі, ACL і плагіни, а захищена сторінка залишилася захищеною. Порівняйте вимірювання ресурсів для метаданих файлової системи, тому медіафайлів, індексування пошуку та PHP-воркерів із попереднім релізом і дослідіть суттєві відхилення до просування.

Насамкінець виконайте контрольовану відмову: надішліть нешкідливі дані поблизу обмеження ресурсу або формату, пов’язаного з цією межею: права власності на файли не дають зберігати сторінки, хоча UI завантажується. Переконайтеся, що DokuWiki пояснює причину відмови, не пошкоджує наявний стан і відновлює роботу після повернення коректної умови. Збережіть знеособлений фрагмент журналу та час відновлення. Разом ці перевірки охоплюють поведінку, надійність даних і керованість, а не лише доступність процесу.

Запустіть перший production-подібний екземпляр

Використайте команду, яка явно показує всі важливі рішення. Ця базова конфігурація прив’язує DokuWiki до loopback хоста, додає відомі монтування даних і передає перше обов’язкове налаштування. Підтвердьте локальну вимогу до відкриття доступу: постійний том конфігурації, що містить сторінки, медіафайли та ACL.

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

Замініть плаваючі теги на протестовану версію або digest. Після запуску перевірте docker logs --tail 200 dokuwiki і переконайтеся, що процес слухає порт 80. Потім виконайте приймальну дію DokuWiki; відповідь для root-сторінки не може підтвердити успішність повного сценарію: замінити облікові дані початкового налаштування, відредагувати сторінку, завантажити медіафайл, застосувати ACL, переглянути редакцію та відновити попередню версію.

Томи — лише перший рівень відновлення

Для DokuWiki безпека повторного розгортання починається зі сторінок, медіафайлів, метаданих, користувачів, ACL і плагінів. Змонтуйте /config до початкового завантаження, запишіть нешкідливі тестові дані та замініть контейнер, щоб довести фактичну постійність цього шляху. Перевірте шлях, замінивши контейнер, поки нешкідливі тестові дані ще існують; це виявляє монтування, спрямовані на один каталог вище або нижче.

Потім протестуйте аварійне відновлення на чистому хості. За потреби використовуйте узгоджений зі станом застосунку експорт бази даних і перевірте, що повернулися сторінки, редакції, медіафайли, користувачі, ACL і плагіни, а захищена сторінка залишилася захищеною. Посібник із резервного копіювання баз даних, для якого ви перевіряли відновлення задає надійнішу ціль, ніж проста перевірка створення файлу архіву.

Надайте DokuWiki одну канонічну адресу

Випуск TLS-сертифіката — лише половина маршруту DokuWiki. Обслуговуйте wiki через HTTPS і задайте її канонічну базову URL-адресу. Усередині спрямовуйте трафік на порт 80 і передавайте зовнішню схему, щоб згенеровані URL-адреси та secure cookies залишалися узгодженими.

Використовуйте повний сценарій DokuWiki з чистої мережі, а не лише root-сторінку. Помилку 502 або проблему із сертифікатом можна ізолювати за допомогою автоматичного налаштування домену й TLS. Якщо трафік доходить до процесу, а права власності на файли не дають зберігати сторінки, хоча UI завантажується, діагностуйте цю умову в місці її виникнення, а не нашаровуйте перенаправлення.

Закрийте тимчасовий доступ до налаштування

Моделюйте загрози для дій, які виконує DokuWiki, а не лише для її форми входу. У цьому випадку найнебезпечніша помилка — залишити відкритими інсталятор або налаштування реєстрації. Реалізуйте цю межу: приберіть доступ до інсталятора, перевірте реєстрацію та зберігайте ACL-файли разом із вмістом сторінок.

У цій базовій конфігурації DokuWiki не має обов’язкового bootstrap-секрету; захистіть фактичний обліковий запис адміністратора або upstream-аутентифікацію. Не виправляйте помилку доступу, запускаючи контейнер від root або широко монтуючи хост. Обмеження ресурсів також належать до дизайну безпеки, якщо користувачі можуть запускати операції з метаданими файлової системи, томом медіафайлів, індексуванням пошуку та PHP-воркерами.

Використовуйте Dockup для платформного рівня

Шаблон Dockup має кодувати образ, порт 80, монтування, таймінги health check, домен, TLS і доставку секретів. Dockup має зберігати налаштування середовища виконання DokuWiki, поки оператор підтверджує цю локальну вимогу: постійний том конфігурації, що містить сторінки, медіафайли та ACL. Те саме розгортання може бути націлене на сервери Dockup або підключені клієнтом ресурси.

Після запуску маршруту застосуйте публічне налаштування та спробуйте замінити облікові дані початкового налаштування, відредагувати сторінку, завантажити медіафайл, застосувати ACL, переглянути редакцію та відновити попередню версію. Створюйте резервні копії сторінок, медіафайлів, метаданих, користувачів, ACL і плагінів та включіть вправу з відновлення до операційного плану; це відповідальність DokuWiki, яка залишається видимою після підготовки інфраструктури.

Поширені запитання

Що потрібно DokuWiki для production-розгортання?

Спрямуйте контейнер DokuWiki на порт 80 через один HTTPS-origin. Вимога локального середовища виконання — постійний том конфігурації, що містить сторінки, медіафайли та ACL. Не вважайте DokuWiki готовою, доки не зможете замінити облікові дані початкового налаштування, відредагувати сторінку, завантажити медіафайл, застосувати ACL, переглянути редакцію та відновити попередню версію.

Які дані DokuWiki потрібно включати до резервної копії?

Забезпечте постійність /config і включіть сторінки, медіафайли, метадані, користувачів, ACL і плагіни до одного маніфесту відновлення. Відновлення DokuWiki з чистого стану вважається успішним лише тоді, коли повернулися сторінки, редакції, медіафайли, користувачі, ACL і плагіни, а захищена сторінка залишилася захищеною.

Чи потрібен DokuWiki HTTPS за reverse proxy?

Використовуйте HTTPS для публічного origin DokuWiki, а порт 80 залиште у внутрішньому маршруті. Коректно застосуйте налаштування DokuWiki: обслуговуйте wiki через HTTPS і задайте її канонічну базову URL-адресу. Для DokuWiki HTTPS захищає облікові дані або вміст користувачів під час передавання та забезпечує узгоджену поведінку клієнта, чутливу до origin.

Як тестувати оновлення DokuWiki?

Відновіть поточний стан DokuWiki в ізольованому розгортанні, застосуйте кандидатну версію та повторіть її приймальну транзакцію. Приділіть особливу увагу тому, що плагіни й шаблони можуть відставати від релізів DokuWiki, навіть якщо звичайні файли сторінок залишаються читабельними. Зберігайте попередній образ DokuWiki, доки не буде зрозумілою межа міграції даних і rollback.