Развёртывание Wiki.js на VPS: установка с Docker Compose, PostgreSQL и Nginx Proxy

Что мы настраиваем и зачем

В этом руководстве мы развернем Wiki.js — современную, мощную и гибкую вики-систему, предназначенную для командной работы, документирования проектов, создания баз знаний или личных заметок. Wiki.js предлагает интуитивно понятный пользовательский интерфейс, поддержку различных редакторов (Markdown, AsciiDoc, WYSIWYG), интеграцию с внешними сервисами аутентификации (LDAP, OAuth, SAML) и обширные возможности по настройке. Это идеальное решение для разработчиков, стартапов и всех, кто нуждается в централизованном и легкодоступном хранилище информации.

В итоге, вы получите полностью функциональную вики-систему, доступную по вашему доменному имени через HTTPS, работающую в изолированных контейнерах на вашем VPS. Это обеспечит высокую стабильность, безопасность и простоту обслуживания. Все компоненты — Wiki.js, база данных PostgreSQL и обратный прокси Nginx Proxy Manager — будут управляться с помощью Docker Compose, что значительно упрощает их развертывание и масштабирование.

Существуют различные подходы к созданию баз знаний. Можно использовать облачные сервисы, такие как Notion, Confluence Cloud, GitBook или даже Google Docs. Эти решения предлагают удобство "под ключ" с минимальными усилиями по администрированию. Однако они часто сопряжены с подписочной моделью, ограничениями по функционалу или объему данных, а также вопросами конфиденциальности, поскольку ваши данные хранятся на чужих серверах. Для небольших команд или личных проектов ежемесячные платежи могут оказаться неоправданно высокими, а контроль над данными — недостаточным.

Самостоятельное размещение (self-hosted) Wiki.js на VPS предоставляет полный контроль над данными, безопасностью и конфигурацией. Вы не зависите от тарифных планов сторонних провайдеров, можете настраивать систему под свои уникальные потребности и быть уверенными в конфиденциальности информации. Кроме того, это отличная возможность углубить свои знания в области администрирования серверов и контейнеризации, что является ценным навыком для любого технического специалиста.

Какой VPS-конфиг нужен под эту задачу

Выбор подходящего VPS-конфига критически важен для стабильной и быстрой работы Wiki.js. Хотя Wiki.js достаточно легковесен, база данных и обратный прокси также потребляют ресурсы. Мы будем ориентироваться на актуальные требования для 2026 года, учитывая рост сложности веб-приложений и операционных систем.

Минимальные требования

• CPU: 2 ядра. Современные процессоры с тактовой частотой 2.5 ГГц и выше обеспечат хорошую отзывчивость. Одно ядро может быть достаточно для очень маленьких инсталляций (1-2 пользователя), но для стабильной работы и обработки фоновых задач (поиск, индексация) лучше иметь два.
• RAM: 2 ГБ. Этого будет достаточно для Wiki.js, PostgreSQL и Nginx Proxy Manager. Wiki.js сам по себе может потреблять 300-500 МБ, PostgreSQL — 200-400 МБ, плюс ОС и Docker-демон. Если планируется активное использование или большое количество статей, лучше рассмотреть 4 ГБ.
• Диск: 40 ГБ SSD. SSD критически важен для производительности базы данных и скорости загрузки страниц. 40 ГБ дадут запас для операционной системы, Docker-образов, данных Wiki.js и потенциальных бэкапов. Если вы планируете хранить много изображений или файлов в вики, рассмотрите 80-100 ГБ.
• Сеть: 100 Мбит/с симметричный канал. Для большинства случаев этого более чем достаточно. Важнее стабильность канала и низкий пинг.

Конкретный VPS-план под задачу

Для развертывания Wiki.js с Docker Compose, PostgreSQL и Nginx Proxy Manager, оптимальным будет следующий конфиг:

• CPU: 2-4 vCPU (виртуальных ядра)
• RAM: 4 ГБ
• Диск: 80 ГБ NVMe SSD (предпочтительнее) или высокопроизводительный SATA SSD
• Сеть: 200-500 Мбит/с гарантированный канал

Такой конфигурации будет достаточно для команды из 10-30 активных пользователей, с возможностью хранения тысяч страниц и сотен медиафайлов. Для стабильной работы можно рассмотреть VPS с указанными характеристиками.

Когда нужен dedicated, а не VPS

Dedicated-сервер становится необходим в следующих случаях:

• Очень высокая нагрузка: Если ваша Wiki.js будет обслуживать сотни или тысячи одновременных пользователей, обрабатывать огромные объемы данных, или вы планируете размещать на том же сервере другие ресурсоемкие приложения.
• Строгие требования к производительности: Для приложений, критичных к задержкам или требующих максимальной производительности дисковой подсистемы (например, большие базы данных с высокой частотой записи/чтения).
• Специализированное оборудование: Если вам нужны специфические аппаратные компоненты, например, GPU для машинного обучения, RAID-контроллеры для повышенной отказоустойчивости дисков, или очень большие объемы оперативной памяти (от 64 ГБ).
• Полный контроль над железом: Dedicated-сервер дает полный физический контроль над оборудованием, что может быть важно для некоторых специфических задач или политик безопасности.

Для большинства инсталляций Wiki.js VPS будет более чем достаточен и экономически выгоден. Если вы сомневаетесь, начните с VPS и масштабируйтесь до dedicated, когда возникнет реальная потребность. Для очень больших проектов можно рассмотреть подходящий dedicated.

Локация: на что влияет

Выбор локации VPS влияет на несколько ключевых факторов:

• Задержка (Latency/Ping): Чем ближе сервер к вашим основным пользователям, тем ниже будет пинг и быстрее загрузка страниц. Для команды, работающей в одном городе/регионе, выбирайте сервер в этом же регионе. Для распределенных команд выбирайте центральную локацию или используйте CDN (Content Delivery Network).
• Законодательство: Законы о хранении данных и конфиденциальности могут сильно различаться в зависимости от страны. Убедитесь, что выбранная локация соответствует требованиям вашего бизнеса или личным предпочтениям.
• Стоимость: Цены на VPS могут варьироваться в зависимости от локации из-за разницы в стоимости электроэнергии, инфраструктуры и налогов.

Всегда выбирайте локацию, которая максимально близка к большинству ваших пользователей, чтобы обеспечить наилучший пользовательский опыт.

Подготовка сервера

Перед тем как приступить к установке Wiki.js, необходимо выполнить базовую настройку и усиление безопасности вашего VPS. Мы будем использовать Ubuntu 24.04 LTS (Noble Numbat), актуальную на 2026 год, как основу для нашего сервера.

1. Подключение к серверу и обновление системы

Подключитесь к вашему серверу по SSH, используя данные, предоставленные вашим VPS-провайдером. Обычно это IP-адрес, имя пользователя (root) и пароль.

ssh root@ВАШ_IP_АДРЕС_VPS

После успешного входа обновите список пакетов и установленные пакеты до последних версий.

sudo apt update && sudo apt upgrade -y

Это обеспечит, что все системные компоненты актуальны и содержат последние исправления безопасности.

2. Создание нового пользователя с правами sudo

Работа под пользователем root небезопасна. Создадим нового пользователя и предоставим ему права sudo.

sudo adduser wikiuser

Следуйте инструкциям на экране, чтобы задать пароль и информацию о пользователе. Затем добавьте пользователя в группу sudo.

sudo usermod -aG sudo wikiuser

Теперь вы можете переключиться на нового пользователя и продолжить работу.

su - wikiuser

Или открыть новую SSH-сессию под этим пользователем.

ssh wikiuser@ВАШ_IP_АДРЕС_VPS

3. Настройка аутентификации по SSH-ключам (рекомендуется)

Для повышения безопасности рекомендуется использовать SSH-ключи вместо паролей. Сгенерируйте пару ключей на вашей локальной машине, если у вас их еще нет.

# На вашей локальной машине
ssh-keygen -t rsa -b 4096

Затем скопируйте публичный ключ на сервер для пользователя wikiuser.

# На вашей локальной машине
ssh-copy-id wikiuser@ВАШ_IP_АДРЕС_VPS

После этого отключите аутентификацию по паролю для SSH. Отредактируйте файл /etc/ssh/sshd_config.

sudo nano /etc/ssh/sshd_config

Найдите и измените следующие строки (или добавьте, если отсутствуют):

PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no
PermitRootLogin no

Перезапустите SSH-сервис.

sudo systemctl restart sshd

Теперь вы сможете подключаться только по SSH-ключам, и пользователь root не сможет залогиниться напрямую.

4. Настройка брандмауэра (UFW)

UFW (Uncomplicated Firewall) — это простой в использовании интерфейс для настройки правил iptables. Разрешим только необходимые порты.

sudo apt install ufw -y # Установка UFW, если еще не установлен
sudo ufw default deny incoming # Запретить все входящие соединения по умолчанию
sudo ufw default allow outgoing # Разрешить все исходящие соединения по умолчанию
sudo ufw allow ssh # Разрешить SSH (порт 22)
sudo ufw allow http # Разрешить HTTP (порт 80)
sudo ufw allow https # Разрешить HTTPS (порт 443)
sudo ufw enable # Включить брандмауэр
sudo ufw status verbose # Проверить статус брандмауэра

Теперь ваш сервер защищен от нежелательных входящих подключений.

5. Установка Fail2Ban

Fail2Ban сканирует логи на наличие подозрительной активности (например, многократных неудачных попыток входа SSH) и автоматически блокирует IP-адреса злоумышленников. Это дополнительный уровень защиты.

sudo apt install fail2ban -y
sudo systemctl enable fail2ban # Включить автозапуск Fail2Ban при старте системы
sudo systemctl start fail2ban # Запустить Fail2Ban

Fail2Ban по умолчанию настроен на защиту SSH. Вы можете проверить его статус:

sudo fail2ban-client status
sudo fail2ban-client status sshd

На этом базовая подготовка сервера завершена. Теперь можно приступать к установке программного обеспечения.

Установка ПО — пошагово

Мы будем использовать Docker и Docker Compose для развертывания Wiki.js, PostgreSQL и Nginx Proxy Manager. Это обеспечивает изоляцию приложений, упрощает управление зависимостями и облегчает масштабирование.

1. Установка Docker Engine

Сначала установим необходимые пакеты для Docker.

sudo apt update # Обновить список пакетов
sudo apt install ca-certificates curl gnupg lsb-release -y # Установить зависимости

Добавим официальный GPG-ключ Docker.

sudo install -m 0755 -d /etc/apt/keyrings # Создать директорию для ключей, если не существует
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg # Загрузить и добавить GPG-ключ
sudo chmod a+r /etc/apt/keyrings/docker.gpg # Установить правильные права доступа

Добавим репозиторий Docker в APT-источники.

echo \
  "deb [arch="$(dpkg --print-architecture)" signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  "$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Обновим список пакетов снова и установим Docker Engine, Docker CLI и containerd.

sudo apt update # Обновить список пакетов после добавления репозитория
sudo apt install docker-ce docker-ce-cli containerd.io -y # Установить Docker Engine (версия будет актуальной на 2026 год, например, 25.0.x или 26.0.x)

Проверим статус Docker-сервиса.

sudo systemctl status docker # Убедиться, что Docker запущен и активен

Добавим вашего пользователя в группу docker, чтобы не использовать sudo при каждой команде Docker.

sudo usermod -aG docker ${USER} # Добавить текущего пользователя в группу docker
newgrp docker # Применить изменения группы без перезахода (или просто перезапустите SSH-сессию)

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

docker run hello-world # Запустить тестовый контейнер для проверки установки Docker

2. Установка Docker Compose

Docker Compose — это инструмент для определения и запуска многоконтейнерных Docker-приложений. Мы установим его как плагин Docker CLI.

sudo apt install docker-compose-plugin -y # Установить Docker Compose как плагин для Docker CLI (версия будет актуальной на 2026 год)

Проверим версию Docker Compose.

docker compose version # Проверить, что Docker Compose установлен корректно

3. Подготовка структуры каталогов

Создадим директорию для нашего проекта Wiki.js и поддиректории для данных.

mkdir -p ~/wiki # Создать основную директорию для проекта
cd ~/wiki # Перейти в созданную директорию
mkdir -p data/wiki # Директория для данных Wiki.js (файлы, uploads)
mkdir -p data/db # Директория для данных PostgreSQL

4. Создание файла docker-compose.yml

Этот файл будет определять наши сервисы: Wiki.js, PostgreSQL и Nginx Proxy Manager.

nano docker-compose.yml # Открыть редактор для создания файла

Вставьте следующее содержимое (актуальные версии образов будут подобраны для 2026 года):

version: '3.8'

services:
  wiki:
    image: ghcr.io/requarks/wiki:2.5.300 # Актуальная стабильная версия Wiki.js на 2026 год
    container_name: wiki-js
    restart: unless-stopped
    environment:
      NODE_ENV: production
      DB_TYPE: postgres
      DB_HOST: db
      DB_PORT: 5432
      DB_USER: wikiuser
      DB_PASS: ${DB_PASSWORD} # Пароль из .env
      DB_NAME: wiki
      DB_SSL: 'false' # Использовать SSL только если база данных находится на отдельном сервере или в другом Docker-сети
      # Дополнительные настройки Wiki.js, например, URL
      WIKI_URL: https://wiki.example.com # Замените на ваш домен
    volumes:
      - ./data/wiki:/var/wiki # Сохраняем данные Wiki.js на хосте
    depends_on:
      - db
    networks:
      - wiki-network
      - npm-network # Сеть для Nginx Proxy Manager

  db:
    image: postgres:16-alpine # Актуальная стабильная версия PostgreSQL на 2026 год
    container_name: wiki-db
    restart: unless-stopped
    environment:
      POSTGRES_DB: wiki
      POSTGRES_USER: wikiuser
      POSTGRES_PASSWORD: ${DB_PASSWORD} # Пароль из .env
    volumes:
      - ./data/db:/var/lib/postgresql/data # Сохраняем данные БД на хосте
    networks:
      - wiki-network

  npm:
    image: 'jc21/nginx-proxy-manager:latest' # Nginx Proxy Manager (версия будет актуальной на 2026 год)
    container_name: nginx-proxy-manager
    restart: unless-stopped
    ports:
      - '80:80' # HTTP порт для Let's Encrypt и перенаправления
      - '443:443' # HTTPS порт
      - '81:81' # Порт для админ-панели Nginx Proxy Manager
    volumes:
      - ./data/npm/data:/data # Данные Nginx Proxy Manager
      - ./data/npm/letsencrypt:/etc/letsencrypt # Сертификаты Let's Encrypt
    networks:
      - npm-network

networks:
  wiki-network:
    driver: bridge
  npm-network:
    driver: bridge

Сохраните файл (Ctrl+O, Enter, Ctrl+X).

5. Создание файла .env для секретов

Для хранения паролей и других чувствительных данных используем файл .env, который Docker Compose автоматически загружает.

nano .env # Открыть редактор для создания файла

Вставьте следующее содержимое, заменив YOUR_STRONG_DB_PASSWORD на надежный пароль.

DB_PASSWORD=YOUR_STRONG_DB_PASSWORD_12345

Сохраните файл (Ctrl+O, Enter, Ctrl+X). Убедитесь, что файл .env не будет добавлен в систему контроля версий, если вы используете Git.

6. Запуск сервисов Docker Compose

Теперь, когда все файлы готовы, можно запустить наши сервисы.

docker compose up -d # Запустить все сервисы в фоновом режиме

Эта команда загрузит необходимые Docker-образы (Wiki.js, PostgreSQL, Nginx Proxy Manager), создаст контейнеры и запустит их. Процесс может занять несколько минут в зависимости от скорости вашего интернет-соединения.

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

docker compose ps # Показать статус запущенных контейнеров

Вы должны увидеть, что все три контейнера (wiki-js, wiki-db, nginx-proxy-manager) находятся в статусе running.

На этом этапе основные компоненты установлены и запущены. Далее перейдем к их конфигурации.

Конфигурация

После установки контейнеров необходимо настроить Nginx Proxy Manager для маршрутизации трафика к Wiki.js и получения SSL-сертификата, а также выполнить первичную настройку самой Wiki.js.

1. Настройка Nginx Proxy Manager

Nginx Proxy Manager (NPM) предоставляет удобный веб-интерфейс для управления обратным прокси и SSL-сертификатами Let's Encrypt. Доступ к админ-панели NPM осуществляется через порт 81 вашего VPS.

Откройте в браузере: http://ВАШ_IP_АДРЕС_VPS:81

Первичный вход

При первом входе вам будут предложены стандартные учетные данные:

• Email: [email protected]
• Пароль: changeme

После входа система попросит вас изменить эти данные. Обязательно установите надежный пароль и свой реальный email.

Добавление прокси-хоста для Wiki.js

Перейдите в раздел "Hosts" -> "Proxy Hosts" и нажмите "Add Proxy Host".

• Domain Names: wiki.example.com (замените на ваш реальный домен, который вы настроили в DNS-записях, указывающий на IP вашего VPS).
• Scheme: http
• Forward Hostname / IP: wiki-js (это имя сервиса Wiki.js из файла docker-compose.yml)
• Forward Port: 3000 (стандартный порт Wiki.js)
• Block Common Exploits: Включите (рекомендуется)
• Websockets Support: Включите (обязательно для Wiki.js)

Перейдите на вкладку "SSL".

• SSL Certificate: Выберите "Request a new SSL Certificate".
• Force SSL: Включите.
• Email Address for Let's Encrypt: Введите ваш email.
• I Agree to the Let's Encrypt Terms of Service: Отметьте.

Нажмите "Save". NPM попытается получить SSL-сертификат для вашего домена. Убедитесь, что DNS-запись (тип A) для wiki.example.com указывает на IP-адрес вашего VPS до начала этого шага.

После успешного получения сертификата ваш Wiki.js будет доступен по HTTPS.

2. Первичная настройка Wiki.js

Теперь откройте в браузере ваш домен: https://wiki.example.com

Wiki.js предложит вам пройти процесс первичной настройки.

• Database Type: PostgreSQL (должно быть выбрано по умолчанию)
• Database Host: db
• Database Port: 5432
• Database Name: wiki
• Database User: wikiuser
• Database Password: Введите тот же пароль, что вы указали в файле .env (DB_PASSWORD).

Нажмите "Connect". Wiki.js проверит соединение с базой данных.

Далее вам будет предложено создать учетную запись администратора Wiki.js:

• Email: Введите ваш email.
• Password: Задайте надежный пароль для администратора Wiki.js.
• Name: Ваше имя.

Завершите установку. После этого вы будете перенаправлены на страницу входа в Wiki.js.

3. Проверка работоспособности

После всех настроек убедимся, что все работает корректно.

Проверка контейнеров

docker compose ps # Убедиться, что все контейнеры запущены

Все контейнеры должны быть в статусе running.

Проверка логов Wiki.js

docker compose logs wiki # Просмотреть логи контейнера Wiki.js

Убедитесь, что нет критических ошибок и Wiki.js успешно подключился к базе данных.

Проверка доступности через curl

Выполните запрос к вашему домену с сервера, чтобы убедиться, что Nginx Proxy Manager перенаправляет трафик.

curl -I https://wiki.example.com # Замените на ваш домен

Вы должны увидеть HTTP-заголовки, указывающие на успешный ответ (например, HTTP/2 200).

На этом этапе ваша Wiki.js полностью настроена и доступна через HTTPS. Вы можете начать создавать страницы и приглашать пользователей.

Бэкапы и обслуживание

Регулярное резервное копирование и своевременное обслуживание являются ключевыми аспектами для обеспечения надежности и доступности вашей Wiki.js. Потеря данных может быть катастрофической, поэтому важно иметь проверенную стратегию бэкапов.

Что бэкапить

Для Wiki.js необходимо бэкапить два основных компонента:

1. База данных PostgreSQL: Содержит все статьи, пользователей, настройки и метаданные Wiki.js. Это самый критичный компонент.
2. Файлы Wiki.js: Включают загруженные изображения, файлы, а также потенциально пользовательские темы или плагины. В нашем случае это директория ./data/wiki на хосте.
3. Конфигурация Nginx Proxy Manager: Хотя NPM можно настроить заново, бэкап его данных (сертификатов, настроек прокси) значительно ускорит восстановление. Это директория ./data/npm на хосте.

Простой скрипт автобэкапа

Создадим простой скрипт, который будет выполнять бэкап базы данных и файлов, а затем архивировать их. Для хранения можно использовать локальный диск, а затем переносить на удаленное хранилище.

Создайте директорию для бэкапов на сервере, например, /var/backups/wiki.

sudo mkdir -p /var/backups/wiki
sudo chown wikiuser:wikiuser /var/backups/wiki # Дать права вашему пользователю

Создайте файл скрипта backup_wiki.sh в домашней директории пользователя wikiuser:

nano ~/backup_wiki.sh

Вставьте следующее содержимое:

#!/bin/bash

# --- Настройки ---
BACKUP_DIR="/var/backups/wiki"
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
COMPOSE_PROJECT_DIR="/home/wikiuser/wiki" # Путь к вашей директории docker-compose.yml
DB_CONTAINER_NAME="wiki-db"
DB_USER="wikiuser"
DB_NAME="wiki"
WIKI_DATA_DIR="${COMPOSE_PROJECT_DIR}/data/wiki"
NPM_DATA_DIR="${COMPOSE_PROJECT_DIR}/data/npm"
RETENTION_DAYS=7 # Сколько дней хранить бэкапы

# --- Проверка директории бэкапов ---
if [ ! -d "$BACKUP_DIR" ]; then
  echo "Директория бэкапов $BACKUP_DIR не существует. Создание..."
  sudo mkdir -p "$BACKUP_DIR"
  sudo chown wikiuser:wikiuser "$BACKUP_DIR"
fi

echo "Начинаем процесс бэкапа Wiki.js в $TIMESTAMP"

# --- 1. Бэкап базы данных PostgreSQL ---
echo "Бэкап базы данных PostgreSQL..."
docker exec $DB_CONTAINER_NAME pg_dump -U $DB_USER -d $DB_NAME > "$BACKUP_DIR/wiki_db_$TIMESTAMP.sql"
if [ $? -eq 0 ]; then
  echo "Бэкап БД успешно создан: $BACKUP_DIR/wiki_db_$TIMESTAMP.sql"
else
  echo "ОШИБКА: Не удалось создать бэкап БД."
  exit 1
fi

# --- 2. Бэкап файлов Wiki.js и Nginx Proxy Manager ---
echo "Архивирование данных Wiki.js и NPM..."
tar -czf "$BACKUP_DIR/wiki_data_$TIMESTAMP.tar.gz" -C "$WIKI_DATA_DIR" .
if [ $? -eq 0 ]; then
  echo "Архив данных Wiki.js успешно создан: $BACKUP_DIR/wiki_data_$TIMESTAMP.tar.gz"
else
  echo "ОШИБКА: Не удалось создать архив данных Wiki.js."
  exit 1
fi

tar -czf "$BACKUP_DIR/npm_data_$TIMESTAMP.tar.gz" -C "$NPM_DATA_DIR" .
if [ $? -eq 0 ]; then
  echo "Архив данных NPM успешно создан: $BACKUP_DIR/npm_data_$TIMESTAMP.tar.gz"
else
  echo "ОШИБКА: Не удалось создать архив данных NPM."
  exit 1
fi

# --- 3. Удаление старых бэкапов ---
echo "Удаление старых бэкапов (старше $RETENTION_DAYS дней)..."
find "$BACKUP_DIR" -type f -name "wiki_db_.sql" -mtime +$RETENTION_DAYS -delete
find "$BACKUP_DIR" -type f -name "wiki_data_.tar.gz" -mtime +$RETENTION_DAYS -delete
find "$BACKUP_DIR" -type f -name "npm_data_.tar.gz" -mtime +$RETENTION_DAYS -delete
echo "Очистка старых бэкапов завершена."

echo "Процесс бэкапа завершен."

chmod +x ~/backup_wiki.sh

~/backup_wiki.sh

crontab -e

0 3    /home/wikiuser/backup_wiki.sh >> /var/log/wiki_backup.log 2>&1

Эта строка запускает скрипт каждый день в 03:00 и перенаправляет вывод в лог-файл /var/log/wiki_backup.log.

Куда складывать бэкапы (внешнее хранилище)

Хранение бэкапов на том же сервере, что и рабочие данные, не обеспечивает полной защиты. В случае выхода из строя VPS, вы потеряете и данные, и бэкапы. Рекомендуется использовать внешнее хранилище:

• S3-совместимое хранилище: Облачные сервисы, такие как AWS S3, Backblaze B2, DigitalOcean Spaces, предоставляют надежное и недорогое хранение. Вы можете использовать утилиты вроде s3cmd, rclone или aws cli для автоматической синхронизации локальных бэкапов с S3.
• Отдельный VPS: Вы можете настроить второй, менее мощный VPS, и использовать rsync или scp для копирования бэкапов на него. Это обеспечивает географическое разделение.
• Сетевое хранилище (NAS): Если у вас есть собственное сетевое хранилище, можно настроить монтирование по NFS/SMB и копировать бэкапы туда.

Расширьте скрипт backup_wiki.sh для автоматической загрузки бэкапов на выбранное внешнее хранилище после их создания.

Обновления: rolling vs maintenance window

Поддержание ПО в актуальном состоянии критически важно для безопасности и получения новых функций.

• Обновление Docker-образов (Wiki.js, PostgreSQL, Nginx Proxy Manager):
  • Maintenance window: Это рекомендуемый подход. Выделяйте определенное время (например, раз в месяц), чтобы остановить сервисы, обновить образы и протестировать.

    
    cd ~/wiki # Перейдите в директорию с docker-compose.yml
    docker compose pull # Загрузить последние версии образов
    docker compose down # Остановить и удалить текущие контейнеры
    docker compose up -d # Запустить новые контейнеры с обновленными образами
    

  • Тестирование: Всегда проверяйте работоспособность Wiki.js после обновления. Новые версии могут содержать изменения, требующие ручной адаптации, хотя для минорных версий это редкость.
• Обновление ОС (Ubuntu):
  • Раз в несколько месяцев выполняйте полное обновление системы: sudo apt update && sudo apt upgrade -y. Это также лучше делать в "окно обслуживания", так как может потребоваться перезагрузка сервера.

Избегайте "rolling updates" для продакшн-систем без надлежащей автоматизации и тестирования, так как это может привести к неожиданным простоям.

Troubleshooting + FAQ

В этом разделе мы рассмотрим распространенные проблемы, которые могут возникнуть при развертывании Wiki.js, и дадим ответы на часто задаваемые вопросы.

Не удается подключиться к Wiki.js по доменному имени (ошибка 502 Bad Gateway или Connection Refused)

Что проверить:

1. DNS-запись: Убедитесь, что ваша A-запись для wiki.example.com (или вашего домена) правильно указывает на IP-адрес вашего VPS. Используйте dig wiki.example.com или nslookup wiki.example.com.
2. Контейнеры Docker: Проверьте, что все контейнеры (wiki-js, wiki-db, nginx-proxy-manager) запущены и находятся в статусе "running".

   
   docker compose ps
               

3. Логи Nginx Proxy Manager: Проверьте логи NPM на наличие ошибок.

   
   docker compose logs npm
               

   Ошибки, связанные с Let's Encrypt, часто указывают на проблемы с DNS или брандмауэром.
4. Конфигурация Proxy Host в NPM: Убедитесь, что "Forward Hostname / IP" установлен как wiki-js и "Forward Port" как 3000. Также проверьте, включена ли опция "Websockets Support".
5. Брандмауэр (UFW): Убедитесь, что порты 80 и 443 открыты.

   
   sudo ufw status verbose
               

Как фиксить: Исправьте DNS-запись, перезапустите контейнеры, если они упали, или скорректируйте настройки в NPM и брандмауэре.

Wiki.js не может подключиться к базе данных (ошибка "Database connection failed")

Что проверить:

1. Логи Wiki.js: Проверьте логи контейнера Wiki.js.

   
   docker compose logs wiki
               

   Ищите сообщения об ошибках подключения к БД.
2. Контейнер базы данных: Убедитесь, что контейнер wiki-db запущен и в его логах нет ошибок.

   
   docker compose logs db
               

3. Переменные окружения: Проверьте файл .env и секцию environment для сервиса wiki в docker-compose.yml. Убедитесь, что DB_HOST установлен как db, DB_USER, DB_PASS и DB_NAME соответствуют данным, используемым в PostgreSQL.
4. Пароль: Убедитесь, что пароль в .env точно совпадает с тем, который вы ввели при первичной настройке Wiki.js.

Как фиксить: Исправьте опечатки в переменных окружения или пароле. Если вы изменили .env или docker-compose.yml, вам нужно перезапустить сервисы: docker compose down && docker compose up -d.

Какой VPS-конфиг минимально подойдёт?

Для небольшой команды (до 5-10 человек) или личного использования, минимально достаточным будет VPS с 2 vCPU, 2 ГБ RAM и 40 ГБ SSD. Этого хватит для стабильной работы Wiki.js, PostgreSQL и Nginx Proxy Manager. Однако, если вы планируете активное использование, хранение большого количества медиафайлов или рост команды, рекомендуется сразу рассмотреть конфигурацию с 4 ГБ RAM и 80 ГБ SSD. Это обеспечит лучший запас производительности и уменьшит вероятность замедлений в будущем.

Что выбрать — VPS или dedicated для этой задачи?

Для развертывания Wiki.js практически всегда достаточно VPS. Dedicated-серверы требуются для очень больших проектов с сотнями или тысячами активных пользователей, экстремально высокими требованиями к производительности дисковой подсистемы, или если вам нужен полный физический контроль над оборудованием и его специфическими компонентами. Для большинства команд и предприятий VPS является более экономичным и гибким решением, которое легко масштабировать по мере роста потребностей. Начните с VPS, и если вы столкнетесь с постоянной нехваткой ресурсов, тогда рассмотрите переход на dedicated-сервер.

Не удается получить SSL-сертификат Let's Encrypt в Nginx Proxy Manager

Что проверить:

1. DNS-запись: Домен, для которого вы запрашиваете сертификат, должен быть корректно настроен в DNS и указывать на IP вашего VPS. Проверьте это через dig или онлайн-инструменты.
2. Брандмауэр: Порты 80 и 443 должны быть открыты для входящих соединений. Let's Encrypt использует порт 80 для HTTP-01 челленджа.
3. Логи NPM: Просмотрите логи контейнера Nginx Proxy Manager. Ошибки от Certbot (используется Let's Encrypt) будут там.
4. Лимиты Let's Encrypt: Если вы часто запрашивали сертификаты для одного домена, возможно, вы достигли лимитов Let's Encrypt. Подождите некоторое время.

Как фиксить: Убедитесь в правильности DNS и открытых портах. Если проблема в лимитах, используйте тестовый сервер Let's Encrypt (Staging) в NPM для отладки, прежде чем снова пытаться получить реальный сертификат.

Как обновить Wiki.js до новой версии?

Что проверить:

1. Наличие новой версии: Проверьте официальный репозиторий Wiki.js на GitHub или Docker Hub для актуальных версий.
2. Бэкап: Всегда делайте полный бэкап базы данных и данных Wiki.js перед обновлением.

Как фиксить: Перейдите в директорию ~/wiki на вашем сервере, измените номер версии образа Wiki.js в файле docker-compose.yml (например, с 2.5.300 на 2.5.301 или 3.0.0). Затем выполните:

docker compose pull # Загрузить новый образ
docker compose up -d # Пересоздать контейнер с новой версией

После обновления проверьте логи Wiki.js и убедитесь, что все работает корректно. Иногда могут потребоваться дополнительные шаги по миграции, описанные в релиз-ноутах Wiki.js.

Выводы и следующие шаги

Поздравляем! Вы успешно развернули Wiki.js на своем VPS, используя Docker Compose для оркестрации сервисов. Теперь у вас есть мощная, безопасная и легко управляемая вики-система, доступная по HTTPS, которая готова стать центральным хранилищем знаний для вашей команды или личных проектов. Вы получили полный контроль над данными и инфраструктурой, что является значительным преимуществом по сравнению с облачными решениями.

Вот несколько следующих шагов, которые можно предпринять для дальнейшего развития вашей Wiki.js:

• Настройка аутентификации: Интегрируйте Wiki.js с вашим существующим LDAP, Active Directory, GitHub, Google OAuth или другими поставщиками аутентификации для удобного управления пользователями.
• Мониторинг производительности: Установите инструменты мониторинга (например, Prometheus + Grafana) для отслеживания состояния сервера, использования ресурсов Docker-контейнерами и производительности Wiki.js.
• Масштабирование хранилища: Если вы планируете хранить очень большие объемы файлов, рассмотрите возможность интеграции Wiki.js с внешними объектными хранилищами (S3-совместимыми) для медиафайлов, чтобы не перегружать дисковое пространство VPS.
• Изучение функций Wiki.js: Погрузитесь в богатый функционал Wiki.js, настройте темы, плагины, права доступа и рабочие процессы для максимальной адаптации под ваши нужды.