От хаоса в 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.

  1. Создаем виртуальное окружение в папке нашего проекта:

    python3 -m venv venv_docs

    Мы назвали его venv_docs, чтобы не путать с venv от основного приложения.

  2. Активируем его (для интерактивной работы):

    source venv_docs/bin/activate

    После этого в начале строки терминала появится (venv_docs).

  3. Устанавливаем пакеты уже в "чистое" окружение:

    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)


  1. Tishka17
    06.07.2025 10:51

    Почему именно MkDocs, а не Docusaurus или VitePress?

    А почему не reStructuredText?


    1. cyberscoper Автор
      06.07.2025 10:51

      MkDocs — это просто. Markdown + YAML, без JS/React/Vue. Из коробки работает с GitHub Pages, быстрая сборка, Material for MkDocs — шикарная тема. Если нужна документация, а не мини-SPA с компонентами — MkDocs идеален.

      А почему не reStructuredText? Потому что reST — боль (хотя да не для всех). Сложный синтаксис, трудно читать, трудно писать. Markdown стал стандартом, и он везде.


  1. shadek
    06.07.2025 10:51

    А почему не Backstage?


    1. cyberscoper Автор
      06.07.2025 10:51

      Потому что это уже не "документация", а целый портал)

      Backstage — это как CMS + DevOps-панель + каталог микросервисов. Чтобы его поднять, нужен как минимум Kubernetes-энтузиазм и свободный вечер. MkDocs про, простенькую статичную доку.


      1. shadek
        06.07.2025 10:51

        Так показывать md документы и OpenAPI умеет gitlab, прямо рядом с кодом. Зачем тогда городить mkdocs? А если делать, то уже хорошо.

        ПС понимаю, что фломастеры у всех свои, но имхо ваше решение из разряда "потому что могу".


        1. cyberscoper Автор
          06.07.2025 10:51

          MkDocs — это как сделать из документации удобный сайт с меню, поиском и приятным дизайном. Людям так проще ориентироваться и искать нужное. Короче, если документация только для своих — GitLab сойдёт (и даже хороший вариант). Если хочешь, чтобы её реально читали и понимали — лучше сделать сайт, типа MkDocs. Просто и понятно.


          1. shadek
            06.07.2025 10:51

            чтобы её реально читали и понимали

            Не понял почему документация в Gitlab / Github не подходит для этого

            лучше сделать сайт

            В базовом варианте Backstage как раз просто сайт генерирует под каждый найденную репку (не знаю где вы там нашли "CMS+DevOps панель+микросервисы"). Плюс умеет все неплохо структурировать и строить поиск. И как раз поверх mkdocs с АВТОМАТИЧЕСКИМ обновление после каждого коммита в репку. Итого у вас одна точка входа в проект (в дополнение к git).


            1. baldr
              06.07.2025 10:51

              У нас, например, Github непубличный, а просить каких-нибудь продажников в нём регистрироваться чтобы дать доступ - странное решение. В Github у нас сейчас 120 репозиториев и тащить все доки из них всех нам не нужно, проще всё собрать в одном месте. Wiki из github мне лично кажется совершенно неудобным и не настраиваемым. Возможно, в gitlab оно всё как-то и лучше, но сейчас мы на него переезжать не будем точно, так что я даже сравнивать не пойду.

              MkDocs поднят в контейнере на сервере во внутренней сети за VPN. Все пользователи с VPN могут иметь доступ. Кажется, даже дополнительно авторизуются через SSO, но сейчас не помню. Если нужно будет что-то разграничить - придётся придумывать ещё варианты (или искать плагины).

              Заметьте - я с вами совершенно не спорю, а описываю отдельный случай когда github не является лучшим местом для доков. Ваше предложение вполне рабочее для другого случая.


              1. shadek
                06.07.2025 10:51

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


        1. baldr
          06.07.2025 10:51

          Если хватает базового Markdown - то можно и в gitlab.

          Но обычно всегда хочется чего-то ещё. Вот пример из официальной документации FastAPI.

          Табы
          Табы

          Вот есть, например, такие табы для кода или заметок. Удобно - да. Нужно ли - ну не всегда.

          Есть плагины для сворачивания части текста или выделения каких-то блоков отдельным цветом/заголовком (см в той же документации на страницу ниже). Удобно - да. Нужно ли - не всегда.


  1. baldr
    06.07.2025 10:51

    В целом, я поддержу статью, хотя это решение вполне может подойти не всем.

    Я тоже выбрал MkDocs для внутренней документации, но у меня совсем маленькая команда - 2-4 человека.

    Markdown - отдельные файлы, просто версионируются в репозитории. Если вам, например, нужно на странице видеть историю правок - можно, конечно, приделать интеграцию с git, но, наверное, лучше не нужно и лучше смотреть на тот же Confuence.

    Простой синтаксис Markdown стимулирует рисовать простые странички, без таблиц третьей степени вложенности и прочих сложных элементов. Плагины есть для всего, но, опять же, если хочется чего-то сложнее - лучше рассмотреть более сложные движки. Стили можно настраивать и html вставлять, в общем-то.

    Плагинов реально дофига, и поначалу глаза просто разбегаются, хочется попробовать половину из них. Другой вопрос - насколько часто они обновляются. Ну это как любой опенсорс.

    Confluence, например, тоже настраивается, но сложнее и дорого. Atlassian хочет чтобы всё было у них в облаке. Например, в онлайн-редакторе Jira постоянно вылезают какие-то баннеры и подсказки, что реально раздражает. И внешний вид настроить под себя довольно сложно, не говоря уж о том чтобы синтаксис MD немного расширить..


  1. serg-mizun
    06.07.2025 10:51

    А есть смысл развернуть все это в Docker?


    1. baldr
      06.07.2025 10:51

      На мой взгляд - всегда есть смысл развернуть что-то в Docker. Особенно на фоне борьбы автора с virtualenv и прочими пакетами - статья была бы немного короче, если дать ссылку на официальный Dockerfile.

      Правда, нужно учитывать, что ваши .md-файлики именно транслируются в html, а Dockerfile настроен на то, что он запускает development-сервер, который будет эти файлики раздавать, но и на лету конвертировать только что изменённые. Возможно, лучше будет в докере просто один раз их собирать в html и раздавать через nginx как автор.


  1. 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 по токену.
    Из недостатков - продукт новый, встречаются ошибки, но ребята довольно быстро все фиксят.