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

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

Това разграничение разкрива проблема, с който операторите се сблъскват след локално тестване: правата върху файловете не позволяват запис на страници, въпреки че UI се зарежда. То прави и плана за backup и upgrade достатъчно конкретен за тестване.

Портове, процеси и частни услуги

Започнете с network namespace на DokuWiki: неговият web listener е на порт 80, а не на host port, копиран от tutorial за лаптоп. Локалното runtime изискване е persistent config volume, съдържащ страници, media и ACL. Документирайте очаквания капацитет, ownership и failure mode, вместо да ги оставяте като image defaults.

След като изискването е изпълнено, изпълнете целия сценарий — заменете setup credentials, редактирайте страница, качете media, приложете ACL, вижте revision и възстановете по-стара версия. Запишете logs и измервания за filesystem metadata, media volume, search indexing и PHP workers. Тези данни се превръщат в първата известна добра архитектура и правят последващото преместване между Dockup compute и прикачен server тестируемо.

Тестове за откази при DokuWiki

Работещият container е необходим, но не е достатъчен. Service-level indicator е успешното изпълнение на „заменете setup credentials, редактирайте страница, качете media, приложете ACL, вижте revision и възстановете по-стара версия“, докато вероятните pressure signals са filesystem metadata, media volume, search indexing и PHP workers.

Контролът на промените е важен, защото plugins и templates може да изостават от DokuWiki releases, въпреки че обикновените файлове на страниците остават четими. Запазете стария image, тествайте migrations върху копирано състояние и документирайте дали rollback се поддържа след промяна на schema. Ако правата върху файловете не позволяват запис на страници, въпреки че UI се зарежда, диагностицирайте първата boundary, която се различава от работещата среда.

Документирайте известен добър DokuWiki deployment

Release candidate за DokuWiki заслужава трафик, като изпълни фиксиран сценарий: заменете setup credentials, редактирайте страница, качете media, приложете ACL, вижте revision и възстановете по-стара версия. Запишете image digest, ефективната non-secret конфигурация, public origin и timestamps за този сценарий. Тестовите данни трябва да могат да бъдат изхвърлени, но да са достатъчно реалистични, за да упражняват същия път като потребителите.

Изпълнете го след подмяна на runtime, след което възстановете услугата от страници, media, metadata, потребители, ACL и plugins. Възстановяването е успешно, когато страниците, revisions, media, потребителите, ACL и plugins се върнат и защитената страница остане защитена. Сравнете resource measurements за filesystem metadata, media volume, search indexing и PHP workers с предходния release и проучете съществените отклонения преди promotion.

Накрая изпълнете този контролиран отказ: подайте безвреден input близо до resource или format limit, свързан с тази boundary: правата върху файловете не позволяват запис на страници, въпреки че UI се зарежда. Проверете дали DokuWiki обяснява проблема, не поврежда съществуващото състояние и възобновява работа, когато валидното условие се върне. Запазете редактиран откъс от log и времето за възстановяване. Заедно тези проверки обхващат поведението, устойчивостта на данните и operability, а не само uptime на процеса.

Стартирайте първата production-shaped инстанция

Използвайте команда, която показва всеки важен избор. Тази baseline конфигурация свързва DokuWiki към host loopback, добавя известните data mounts и задава първата необходима настройка. Потвърдете локалното изискване преди публичното излагане: persistent config volume, съдържащ страници, media и 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

Заменете floating tags с тествана версия или digest. След стартирането прегледайте docker logs --tail 200 dokuwiki и потвърдете, че процесът слуша на 80. След това изпълнете acceptance action за DokuWiki; отговор от root page не може да докаже, че целият сценарий работи: заменете setup credentials, редактирайте страница, качете media, приложете ACL, вижте revision и възстановете по-стара версия.

Volumes са само първият recovery слой

При DokuWiki безопасността при redeploy започва със страници, media, metadata, потребители, ACL и plugins. Монтирайте /config преди bootstrap, запишете безвредни примерни данни и заменете container-а, за да докажете, че този път наистина е persistent. Тествайте пътя, като замените container-а, докато безвредните примерни данни съществуват; така се откриват mounts, насочени с една директория твърде нагоре или надолу.

След това тествайте disaster recovery върху празен host. Където е необходимо, използвайте application-consistent database export и проверете дали страниците, revisions, media, потребителите, ACL и plugins се връщат и защитената страница остава защитена. Ръководството за database backup, който сте възстановили предоставя по-силна цел от простата проверка дали е създаден archive file.

Дайте на DokuWiki един каноничен адрес

Издаването на TLS сертификат е само половината от DokuWiki route-а. Сервирайте wiki през HTTPS и задайте canonical base URL. Насочвайте вътрешния трафик към 80 и препращайте външната схема, така че генерираните URL адреси и secure cookies да останат съгласувани.

Използвайте целия DokuWiki сценарий от чиста мрежа, а не само root page. Грешка 502 или проблем със сертификата може да бъде изолирана чрез автоматична настройка на domain и TLS. Ако трафикът достига до процеса и правата върху файловете не позволяват запис на страници, въпреки че UI се зарежда, диагностицирайте условието там, където възниква, вместо да трупате redirects.

Затворете временния setup достъп

Моделирайте заплахите според действието, което изпълнява DokuWiki, а не само според login формата му. Тук високорисковата грешка е да оставите installer-а или registration settings отворени. Реализирайте тази boundary: премахнете достъпа до installer-а, прегледайте registration и запазете ACL files заедно със съдържанието на страниците.

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

Използвайте Dockup за platform слоя

Dockup template трябва да кодира image, порт 80, mounts, health timing, domain, TLS и secret delivery. Dockup трябва да запазва runtime settings на DokuWiki, докато операторът потвърждава това локално изискване: persistent config volume, съдържащ страници, media и ACL. Същият deployment може да бъде насочен към Dockup servers или към капацитет, прикачен от клиента.

След като route-ът е активен, приложете public setting и опитайте да замените setup credentials, да редактирате страница, да качите media, да приложите ACL, да видите revision и да възстановите по-стара версия. Архивирайте страници, media, metadata, потребители, ACL и plugins и включете упражнението за restore в operational plan-а; това са отговорности на DokuWiki, които остават видими и след provisioning-а на инфраструктурата.

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

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

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

Кои данни на DokuWiki трябва да бъдат включени в backup?

Запазете /config и включете страници, media, metadata, потребители, ACL и plugins в един и същ recovery manifest. Чистият restore на DokuWiki е успешен само когато страниците, revisions, media, потребителите, ACL и plugins се върнат и защитената страница остане защитена.

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

Използвайте HTTPS за public origin на DokuWiki и запазете порт 80 във вътрешния route. Приложете правилно настройката на DokuWiki: сервирайте wiki през HTTPS и задайте canonical base URL. При DokuWiki HTTPS защитава credentials или потребителското съдържание при пренос и запазва съгласуваното поведение на клиента, зависещо от origin-а.

Как трябва да бъде тестван upgrade на DokuWiki?

Възстановете текущото състояние на DokuWiki в изолиран deployment, приложете candidate версията и повторете acceptance transaction. Обърнете специално внимание, защото plugins и templates може да изостават от DokuWiki releases, въпреки че обикновените файлове на страниците остават четими. Запазете предишния DokuWiki image, докато границите на data migration и rollback не бъдат изяснени.