От хаоса в Markdown-файлах до стильного, быстрого сайта с поиском, темами и мультиязычностью за один вечер.
В жизни почти каждого IT-проекта наступает момент, когда количество файлов README.md
, GUIDE.md
, docs.txt
и заметок в Confluence достигает критической массы. Документация становится фрагментированной, поиск нужной информации превращается в квест, а новые члены команды тратят часы на то, чтобы просто понять, "что где лежит".
Мы в проекте Peakline (наш сервис для продвинутой аналитики тренировок на Strava) столкнулись ровно с такой же проблемой. Решением, которое превзошло все наши ожидания по скорости и качеству результата, стала связка MkDocs и темы Material for MkDocs.

В этой статье мы не будем пересказывать официальную документацию. Вместо этого мы покажем вам весь наш путь от А до Я: от установки на "голый" сервер до финального развертывания. Мы честно расскажем о всех граблях, на которые наступили, и поделимся готовыми конфигами, которые вы сможете адаптировать для своих проектов.
1. Почему именно MkDocs, а не Docusaurus или VitePress?
Наш стек в основном на Python, поэтому выбор инструмента, написанного на том же языке, был для нас естественным. Но даже если вы не пишете на Python, у MkDocs есть несколько неоспоримых преимуществ:
Феноменальная простота: Вы просто пишете текст в формате Markdown. Никаких JSX-компонентов, сложных структур или долгой компиляции. Это позволяет сосредоточиться на контенте, а не на инструменте.
Скорость: MkDocs генерирует набор статических HTML, CSS и JS файлов. Такой сайт не требует сложного бэкенда, летает даже на самом простом хостинге и отлично кэшируется.
-
Мощнейшая тема "из коробки": Честно говоря, основной причиной выбора стала тема Material for MkDocs. Это не просто "скин", а целый фреймворк поверх MkDocs, который дает:
Современный, чистый дизайн (абсолютно в трендах 2025 года).
Идеальную адаптивность для мобильных устройств.
Встроенный поиск, который просто работает.
Переключение между светлой и темной темой.
Простую настройку мультиязычности.
Огромное количество готовых UI-компонентов: блоки с подсказками, табы, красивые таблицы, подсветка синтаксиса и многое другое.
2. Установка: Первые грабли и боль с venv
Казалось бы, что может быть проще, чем pip install
? Но тут нас ждал первый сюрприз.
Попытка №1 (неудачная):
Мы, как и многие, начали с простой команды: pip install mkdocs mkdocs-material pymdown-extensions
. И тут же получили ошибку error: externally-managed-environment
.
Что это значит? Современные дистрибутивы Linux (в нашем случае Debian) защищают системный Python от изменений через pip
. Это сделано для того, чтобы вы случайно не сломали системные утилиты, которые зависят от определенных версий пакетов.
Правильное решение — виртуальное окружение:
Изоляция зависимостей — это святое правило хорошего тона в Python.
-
Создаем виртуальное окружение в папке нашего проекта:
python3 -m venv venv_docs
Мы назвали его
venv_docs
, чтобы не путать сvenv
от основного приложения. -
Активируем его (для интерактивной работы):
source venv_docs/bin/activate
После этого в начале строки терминала появится
(venv_docs)
. -
Устанавливаем пакеты уже в "чистое" окружение:
pip install mkdocs mkdocs-material pymdown-extensions
Теперь все пакеты установлены в папку
venv_docs
и не затрагивают систему.
Лайфхак для скриптов: При запуске команд в скриптах или CI/CD активация окружения не всегда удобна. Можно вызывать исполняемые файлы напрямую: ./venv_docs/bin/python
или ./venv_docs/bin/mkdocs
.
3. Создание и настройка проекта
-
Инициализация: Одна простая команда создает всю базовую структуру.
# Убедитесь, что вы находитесь в корне проекта, а не в venv_docs! ./venv_docs/bin/mkdocs new docs
Она создаст папку
docs
с конфигомmkdocs.yml
и одним файломindex.md
. -
Сердце проекта:
mkdocs.yml
: Это главный файл, где происходит вся магия. Вот наш финальный конфиг с комментариями:# Название сайта, отображается в шапке site_name: Peakline Docs # Описание для мета-тегов SEO site_description: 'Документация для проекта Peakline' # Настройка темы theme: name: material # Указываем, что используем Material # Включаем крутые фичи темы features: - navigation.tabs # Навигация в виде табов - navigation.sections # Секции в навигации - toc.integrate # Интегрировать оглавление страницы в навигацию - search.suggest # Подсказки при поиске - content.code.copy # Кнопка "копировать" для блоков кода # Настраиваем палитру и переключатель тем palette: - scheme: default # Светлая тема primary: 'indigo' accent: 'indigo' toggle: icon: material/brightness-7 name: Переключиться на темную тему - scheme: slate # Темная тема primary: 'indigo' accent: 'indigo' toggle: icon: material/brightness-4 name: Переключиться на светлую тему # Секция для мультиязычности extra: alternate: - name: English # Название в переключателе link: /en/ # Ссылка на английскую версию lang: en # Код языка - name: Русский link: ./ # Ссылка на текущую (русскую) версию lang: ru # Наша навигация по сайту nav: - 'Главная': 'index.md' - 'Начало работы': - 'Первые шаги': 'getting-started/first-steps.md' - 'Наша философия данных': 'getting-started/data-philosophy.md' - 'Ключевые возможности': - 'Анализ сегментов': 'core-features/segment-analysis.md' # ... и так далее # Расширения для Markdown markdown_extensions: - admonition # Блоки !!! note, !!! warning - pymdownx.details # Сворачиваемые блоки - pymdownx.superfences # Вложенные блоки кода - pymdownx.tabbed: # Табы alternate_style: true
4. Магия Material: Мультиязычность без боли
Это одна из самых крутых фич. Чтобы добавить поддержку второго языка, нам понадобилось всего лишь добавить блок extra.alternate
(показан в конфиге выше) и создать новую структуру папок.
MkDocs, видя эту конфигурацию, теперь понимает, что:
Контент по умолчанию (русский) лежит в
docs/
.Контент для языка
en
должен лежать вdocs/en/
.
Мы просто скопировали все наши .md
файлы из docs/
в docs/en/
и отдали их на перевод. Всё! Переключатель языков появился на сайте автоматически.
5. Развертывание: от локалхоста до продакшена на Nginx
Итак, у нас есть работающий сайт на локальной машине (mkdocs serve
). Как теперь выкатить его в мир?
Шаг 1: Сборка статики
Запускаем команду сборки:
./venv_docs/bin/mkdocs build --clean
Опция --clean
удаляет старые файлы перед сборкой, что помогает избежать проблем. Вся статика нашего сайта (HTML, CSS, JS, картинки) теперь лежит в папке /site
внутри нашей папки docs
.
Шаг 2: Настройка веб-сервера Nginx
На нашем сервере мы используем Nginx. Вот базовый конфиг, который мы создали в /etc/nginx/sites-available/
docs.thepeakline.com
:
server {
listen 80;
listen [::]:80;
# !!! ВАЖНО: Указываем полный путь к папке с собранной статикой
root /opt/strava-web/docs/site;
index index.html;
server_name docs.thepeakline.com;
location / {
# Стандартный блок для статических сайтов.
# Если файл не найден, Nginx вернет 404.
try_files $uri $uri/ =404;
}
}
Подводный камень №2: Ошибка 404 Not Found. Сначала мы по ошибке оставили в конфиге путь-заглушку вроде /var/www/html
. Nginx работал, но не мог найти файлы. Ключевой момент — директива root
должна указывать на папку site
, а не на docs
.
Шаг 3: HTTPS с помощью Certbot (обязательно!)
В 2025 году сайт без HTTPS — это дурной тон. К счастью, с Certbot это делается одной командой:
# Устанавливаем Certbot и плагин для Nginx
sudo apt install certbot python3-certbot-nginx -y
# Запускаем его для нашего домена
sudo certbot --nginx -d docs.thepeakline.com
Certbot сам найдет наш конфиг, получит SSL-сертификат, установит его и даже предложит настроить редирект с HTTP на HTTPS (настоятельно рекомендуем согласиться).
Ша-г 4: Финальные команды
После того как конфиг готов и сертификат получен, осталось только "включить" наш сайт и перезагрузить Nginx:
# Создаем символическую ссылку, чтобы "активировать" конфиг
sudo ln -s /etc/nginx/sites-available/docs.thepeakline.com /etc/nginx/sites-enabled/
# Проверяем, что в конфигах нет ошибок
sudo nginx -t
# Перезагружаем Nginx, чтобы применить все изменения
sudo systemctl reload nginx
Готово! Наша документация в сети.
Заключение
Переход на MkDocs стал для нас настоящим глотком свежего воздуха. Мы не только навели порядок в документации, но и получили современный, быстрый и удобный для пользователей портал, на создание которого ушло всего пара вечеров. Если вы все еще храните документацию в разрозненных файлах, очень рекомендуем попробовать этот подход.
А посмотреть, что у нас получилось в итоге, можно здесь: docs.thepeakline.com
Комментарии (14)
shadek
06.07.2025 10:51А почему не Backstage?
cyberscoper Автор
06.07.2025 10:51Потому что это уже не "документация", а целый портал)
Backstage — это как CMS + DevOps-панель + каталог микросервисов. Чтобы его поднять, нужен как минимум Kubernetes-энтузиазм и свободный вечер. MkDocs про, простенькую статичную доку.
shadek
06.07.2025 10:51Так показывать md документы и OpenAPI умеет gitlab, прямо рядом с кодом. Зачем тогда городить mkdocs? А если делать, то уже хорошо.
ПС понимаю, что фломастеры у всех свои, но имхо ваше решение из разряда "потому что могу".cyberscoper Автор
06.07.2025 10:51MkDocs — это как сделать из документации удобный сайт с меню, поиском и приятным дизайном. Людям так проще ориентироваться и искать нужное. Короче, если документация только для своих — GitLab сойдёт (и даже хороший вариант). Если хочешь, чтобы её реально читали и понимали — лучше сделать сайт, типа MkDocs. Просто и понятно.
shadek
06.07.2025 10:51чтобы её реально читали и понимали
Не понял почему документация в Gitlab / Github не подходит для этого
лучше сделать сайт
В базовом варианте Backstage как раз просто сайт генерирует под каждый найденную репку (не знаю где вы там нашли "CMS+DevOps панель+микросервисы"). Плюс умеет все неплохо структурировать и строить поиск. И как раз поверх mkdocs с АВТОМАТИЧЕСКИМ обновление после каждого коммита в репку. Итого у вас одна точка входа в проект (в дополнение к git).
baldr
06.07.2025 10:51У нас, например, Github непубличный, а просить каких-нибудь продажников в нём регистрироваться чтобы дать доступ - странное решение. В Github у нас сейчас 120 репозиториев и тащить все доки из них всех нам не нужно, проще всё собрать в одном месте. Wiki из github мне лично кажется совершенно неудобным и не настраиваемым. Возможно, в gitlab оно всё как-то и лучше, но сейчас мы на него переезжать не будем точно, так что я даже сравнивать не пойду.
MkDocs поднят в контейнере на сервере во внутренней сети за VPN. Все пользователи с VPN могут иметь доступ. Кажется, даже дополнительно авторизуются через SSO, но сейчас не помню. Если нужно будет что-то разграничить - придётся придумывать ещё варианты (или искать плагины).
Заметьте - я с вами совершенно не спорю, а описываю отдельный случай когда github не является лучшим местом для доков. Ваше предложение вполне рабочее для другого случая.
shadek
06.07.2025 10:51Спасибо за развернутый ответ. Я тоже не спорю, а пытаюсь понять логику. В любом случае, успехов и всего самого лучшего.
baldr
06.07.2025 10:51Если хватает базового Markdown - то можно и в gitlab.
Но обычно всегда хочется чего-то ещё. Вот пример из официальной документации FastAPI.
Табы Вот есть, например, такие табы для кода или заметок. Удобно - да. Нужно ли - ну не всегда.
Есть плагины для сворачивания части текста или выделения каких-то блоков отдельным цветом/заголовком (см в той же документации на страницу ниже). Удобно - да. Нужно ли - не всегда.
baldr
06.07.2025 10:51В целом, я поддержу статью, хотя это решение вполне может подойти не всем.
Я тоже выбрал MkDocs для внутренней документации, но у меня совсем маленькая команда - 2-4 человека.
Markdown - отдельные файлы, просто версионируются в репозитории. Если вам, например, нужно на странице видеть историю правок - можно, конечно, приделать интеграцию с git, но, наверное, лучше не нужно и лучше смотреть на тот же Confuence.
Простой синтаксис Markdown стимулирует рисовать простые странички, без таблиц третьей степени вложенности и прочих сложных элементов. Плагины есть для всего, но, опять же, если хочется чего-то сложнее - лучше рассмотреть более сложные движки. Стили можно настраивать и html вставлять, в общем-то.
Плагинов реально дофига, и поначалу глаза просто разбегаются, хочется попробовать половину из них. Другой вопрос - насколько часто они обновляются. Ну это как любой опенсорс.
Confluence, например, тоже настраивается, но сложнее и дорого. Atlassian хочет чтобы всё было у них в облаке. Например, в онлайн-редакторе Jira постоянно вылезают какие-то баннеры и подсказки, что реально раздражает. И внешний вид настроить под себя довольно сложно, не говоря уж о том чтобы синтаксис MD немного расширить..
serg-mizun
06.07.2025 10:51А есть смысл развернуть все это в Docker?
baldr
06.07.2025 10:51На мой взгляд - всегда есть смысл развернуть что-то в Docker. Особенно на фоне борьбы автора с virtualenv и прочими пакетами - статья была бы немного короче, если дать ссылку на официальный Dockerfile.
Правда, нужно учитывать, что ваши
.md
-файлики именно транслируются в html, а Dockerfile настроен на то, что он запускает development-сервер, который будет эти файлики раздавать, но и на лету конвертировать только что изменённые. Возможно, лучше будет в докере просто один раз их собирать в html и раздавать через nginx как автор.
KudryashovDA
06.07.2025 10:51Для себя и своей команды использую https://habr.com/ru/companies/gram_ax/articles/910716/ - в редакторе создаю статьи (как в word), которые под капотом являются md файлами (плюс их теги навигации). Из редактора изменения пушатся в Gitea, а из нее данные каждые 5 мин забирает (pull) докер контейнер с их докпорталом (веб сервер + конвертилка md->html). Все легко, быстро и красиво. Из настроек всего два yaml файла (Gitea и DocPortal) для docker compose и первичная настройка доступа к git по токену.
Из недостатков - продукт новый, встречаются ошибки, но ребята довольно быстро все фиксят.
Tishka17
А почему не reStructuredText?
cyberscoper Автор
MkDocs — это просто. Markdown + YAML, без JS/React/Vue. Из коробки работает с GitHub Pages, быстрая сборка, Material for MkDocs — шикарная тема. Если нужна документация, а не мини-SPA с компонентами — MkDocs идеален.
А почему не reStructuredText? Потому что reST — боль (хотя да не для всех). Сложный синтаксис, трудно читать, трудно писать. Markdown стал стандартом, и он везде.