DokuWiki в Docker Compose: готовый файл

MAATRIX

Разворачивать MySQL или PostgreSQL ради небольшой внутренней вики — часто избыточно: ещё один процесс, которому нужен бэкап, ещё одна точка отказа, ещё один пароль в .env. DokuWiki решает это радикально просто — базы данных у неё нет вообще, каждая страница лежит на диске обычным текстовым файлом в синтаксисе, похожем на markdown. Восстановить вики из бэкапа — значит распаковать архив с файлами, а не гадать, совместим ли дамп SQL с новой версией движка. Ниже — рабочий docker-compose.yml, разбор установки через мастер и то, как устроены права доступа без единой SQL-таблицы.

Почему DokuWiki, а не MediaWiki или Wiki.js

MediaWiki (движок Википедии) и Wiki.js — оба завязаны на СУБД: MediaWiki на MySQL/MariaDB, Wiki.js — на PostgreSQL, MySQL или SQLite. Для сайта с миллионами страниц это оправдано, для внутренней документации команды из 10-30 человек — часто оверинжиниринг.

Плюс отсутствия БД — не только упрощённый бэкап. Перенос вики на другой сервер сводится к копированию одного каталога data/ и файла конфигурации, без экспорта-импорта дампа и без риска расхождения версий схемы между движком и базой. Минус — при очень большом количестве страниц (условно от нескольких десятков тысяч) полнотекстовый поиск по плоским файлам работает медленнее, чем по индексированной БД, хотя встроенный индексатор DokuWiki это частично компенсирует.

Если вместо файлового хранения важнее привычная структура «книга-глава-страница» с WYSIWYG-редактором на MySQL, стоит посмотреть на BookStack в Docker Compose — там компромисс сделан в обратную сторону.

Требования к серверу

DokuWiki — одно из самых лёгких self-hosted вики-решений: PHP без БД ест мало и памяти, и CPU.

Цифры ориентировочные — реальное потребление диска почти целиком определяется объёмом загруженных файлов и картинок в data/media, а не текстом страниц: тысяча текстовых страниц весит единицы мегабайт.

Готовый docker-compose.yml

Структура каталогов на сервере:

/opt/dokuwiki/
├── config/          # весь /config контейнера: конфиги, данные, плагины
├── .env
└── docker-compose.yml

Создаём каталог и файл переменных окружения:

mkdir -p /opt/dokuwiki/config
cd /opt/dokuwiki
nano .env

Содержимое .env:

PUID=1000
PGID=1000
TZ=Europe/Moscow

Сам docker-compose.yml — используем образ LinuxServer.io, который упаковывает Apache/PHP и саму DokuWiki в одном контейнере:

services:
  dokuwiki:
    image: lscr.io/linuxserver/dokuwiki:latest
    container_name: dokuwiki
    restart: unless-stopped
    environment:
      PUID: ${PUID}
      PGID: ${PGID}
      TZ: ${TZ}
    volumes:
      - ./config:/config
    ports:
      - "127.0.0.1:8095:80"

Никакого сервиса базы данных, никакого depends_on, никакого healthcheck для БД — файл сознательно короче, чем у любого вики-движка на СУБД. Порт по-прежнему смотрит только на 127.0.0.1: наружу вики отдаём через реверс-прокси с HTTPS, раздел ниже.

Поднимаем:

docker compose up -d
docker compose logs -f dokuwiki

Первый старт — 10-20 секунд, контейнер разворачивает файлы DokuWiki в /config/www/dokuwiki.

Первый запуск и установка мастером

DokuWiki не создаёт администратора автоматически — установку нужно пройти через веб-мастер. Открываем http://<IP-сервера>:8095/install.php.

Мастер запросит:

• Название вики — отображается в заголовке и письмах.
• Данные суперпользователя — логин, пароль, email. Это первый и главный админ-аккаунт.
• Политику ACL (Access Control List) — три варианта на выбор:
• «Открытая вики» — читать и редактировать может кто угодно, без регистрации;
• «Публичная вики» — читают все, редактируют только зарегистрированные;
• «Закрытая вики» — и чтение, и редактирование только для зарегистрированных пользователей.

Для внутренней документации компании обычно выбирают «Закрытая вики» — доступ появится только после того, как администратор заведёт учётные записи или подключит внешний каталог пользователей.

После завершения мастер сам создаёт conf/local.php с настройками и просит удалить или переименовать install.php — оставленный файл позволяет кому угодно повторно запустить установку и переписать конфиг:

docker exec dokuwiki rm /config/www/dokuwiki/install.php

Дальше вход — по адресу http://<IP-сервера>:8095/doku.php?do=login под созданным суперпользователем.

Синтаксис страниц, неймспейсы и права доступа

Страницы в DokuWiki объединяются в неймспейсы — аналог папок, задаются двоеточием в имени страницы: hr:otpuska физически лежит в файле data/pages/hr/otpuska.txt. Создать новую страницу — просто перейти по несуществующей ссылке [[hr:otpuska]] в тексте другой страницы и нажать «Создать эту страницу».

Разметка простая и без HTML:

====== Заголовок первого уровня ======
===== Заголовок второго уровня =====

**жирный текст**, //курсив//, __подчёркнутый__

  * маркированный список
  * второй пункт

[[hr:otpuska|Ссылка на страницу об отпусках]]
{{wiki:image.png?400|Подпись к картинке}}

Права доступа настраиваются файлом conf/acl.auth.php — редактировать его вручную не обязательно, есть админ-панель Управление правами доступа (Admin → ACL), где для группы или пользователя выставляется уровень доступа (нет доступа / чтение / редактирование / загрузка файлов / создание страниц / удаление) на конкретный неймспейс. Например, неймспейс finance:* можно открыть только группе buhgalteriya, оставив остальную вики доступной всем сотрудникам.

Пользователи и группы по умолчанию хранятся в плоском файле conf/users.auth.php (формат логин:хеш_пароля:имя:email:группы) — заводятся через Admin → Управление пользователями. Если в компании уже есть LDAP или Active Directory, DokuWiki поддерживает LDAP-аутентификацию через плагин authldap, который настраивается в том же разделе админки — тогда пароли и группы синхронизируются из каталога, а не дублируются вручную.

HTTPS, резервное копирование и обновление

Логин и пароль по обычному HTTP отправлять нельзя — куки сессии и учётные данные будут ходить открытым текстом. Проще всего закрыть это Caddy с автоматическим Let's Encrypt:

# /etc/caddy/Caddyfile
wiki.your-domain.example {
    reverse_proxy 127.0.0.1:8095
}

Если Caddy ещё не настроен на сервере, есть отдельный разбор установки Caddy с авто-SSL на VPS. Вариант с Traefik тоже рабочий — логика описана в статье про Traefik как реверс-прокси для Docker.

Бэкап — главное преимущество безбазового движка: достаточно заархивировать один каталог config, где лежат и страницы, и медиа, и конфиги, и права доступа:

tar czf /opt/dokuwiki/backups/dokuwiki-$(date +%F).tar.gz -C /opt/dokuwiki config

Восстановление — обратная операция, распаковать архив на место каталога config и перезапустить контейнер:

docker compose down
rm -rf /opt/dokuwiki/config
tar xzf /opt/dokuwiki/backups/dokuwiki-2026-08-15.tar.gz -C /opt/dokuwiki
docker compose up -d

Никакого отдельного дампа SQL, никакой рассинхронизации между версией схемы и версией движка — файлы читаемы движком любой более новой версии DokuWiki без миграций. Если на сервере уже настроен регулярный бэкап других сервисов, логично включить каталог config в общий пайплайн, например через BorgBackup в Docker Compose, а не держать отдельный cron только под вики.

Обновление — стандартный pull + up:

docker compose pull dokuwiki
docker compose up -d dokuwiki

DokuWiki также умеет проверять обновления сама через Admin → Проверить обновления и предлагать установку прямо из админки — на Docker-развёртывании этим лучше не пользоваться: правильный путь именно pull нового образа, иначе версия внутри контейнера разойдётся с тем, что ожидает базовый образ при следующем пересоздании.

Частые вопросы