Open edX — это не своя Coursera, а платформа из восьми сервисов

MAATRIX

Если вы искали «как поднять свою Coursera», скорее всего вы наткнулись на Open edX — платформу, на которой действительно работают edx.org, курсы MIT и Harvard. И весь маркетинг вокруг неё звучит соблазнительно: open source, тот же движок, что у больших MOOC-платформ, ставь и учи. Реальность честнее и суровее: Open edX — это не одно приложение, а связка из десятка сервисов, каждый со своей базой, своим доменом и своей логикой отказов. Ниже — что на самом деле придётся развернуть, сколько это стоит по ресурсам и где новички теряют неделю, ожидая «просто установку».

Что скрывается за словом «платформа» — восемь сервисов вместо одного

Когда говорят «Open edX», чаще всего имеют в виду не одно приложение, а набор независимых сервисов (Independently Deployable Applications, IDA в терминологии самого проекта), которые вместе образуют платформу. В типичной production-инсталляции через Tutor (о нём ниже) одновременно поднимаются:

• LMS (Learning Management System) — то, что видит студент: курсы, видео, тесты, прогресс, форум обсуждений интегрирован сюда же по интерфейсу.
• CMS / Studio — редактор курсов для преподавателя: структура разделов, загрузка видео, настройка заданий с автоматической проверкой.
• Discovery — каталог курсов, поиск и фильтрация программ, если у вас больше одного курса и нужна витрина.
• Ecommerce — исторически отдельный сервис для платных курсов, верифицированных сертификатов и купонов; в разных релизах Open edX эта часть меняется активнее остальных, так что перед установкой стоит свериться с актуальной документацией именно вашей версии.
• Forum / Discussions — обсуждения под каждым уроком, отдельная база и API.
• Notes — заметки студента на полях курса, синхронизируются между устройствами.
• Credentials — выпуск и верификация сертификатов об окончании.
• MFE (Micro-Frontends) — с 2021 года большая часть интерфейса LMS вынесена из монолита в отдельные React-приложения: learning MFE (просмотр урока), authoring MFE (Studio), account, gradebook, discussions-MFE и другие. Каждый — отдельный node-проект, который надо собрать и раздавать отдельно.

Это уже восемь смысловых блоков, и это без учёта инфраструктурных зависимостей: MySQL хранит пользователей, оценки и структуру курсов; MongoDB — модульную структуру контента (modulestore); Elasticsearch или OpenSearch — полнотекстовый поиск по курсам и Discovery; Redis и/или RabbitMQ — брокер очередей для Celery; сами Celery-воркеры — отдельные процессы для фоновых задач (пересчёт оценок, рассылки, генерация сертификатов). Добавьте сюда Caddy или nginx как reverse proxy с автоматическим TLS — и получится 15-20 контейнеров на одну «платформу для курсов».

Разработчики Open edX не скрывают эту сложность — она прямо описана в их архитектурной документации как осознанное решение: каждый сервис масштабируется и обновляется независимо. Для edx.org с миллионами студентов это оправдано. Для курса на 200 человек — это накладные расходы, которые вы почувствуете на первом же docker compose up.

Tutor: обёртка, которая не отменяет сложность, а упаковывает её

С 2021 года официально рекомендуемый способ установки Open edX — проект Tutor (Overhang.io), пришедший на смену устаревшим Ansible-плейбукам и Devstack. Tutor — это Python CLI, который генерирует docker-compose файлы (или манифесты для Kubernetes) под все перечисленные сервисы и управляет их жизненным циклом одной командой:

pip install "tutor[full]"
tutor local quickstart

Это действительно снимает часть боли: не нужно вручную писать Dockerfile для каждого сервиса и следить за версиями зависимостей друг относительно друга — Tutor фиксирует совместимый набор. Но «одна команда» не значит «один контейнер». tutor local quickstart разворачивает базовый набор — LMS, CMS, MySQL, MongoDB, Redis, SMTP-заглушку и nginx — и именно на этом шаге у новичков возникает первое ложное ощущение «всё, готово». Базовый набор — это ещё не платформа для реальных курсов: без Discovery не будет каталога, без Forum — обсуждений, без MFE-плагина интерфейс останется на старом Django-шаблоне вместо современных React-экранов.

Каждый дополнительный сервис в Tutor — это отдельный плагин, который нужно поставить и включить осознанно:

pip install tutor-mfe tutor-discovery tutor-forum tutor-notes tutor-credentials
tutor plugins enable mfe discovery forum notes credentials
tutor config save
tutor local launch

После tutor plugins enable пересобираются образы и перезапускается весь стек — на слабом сервере это может занять от 20-30 минут и больше в зависимости от числа плагинов и мощности CPU: часть сборки (особенно MFE) — это полноценный webpack-билд внутри контейнера, а не просто docker pull готового образа.

Отдельная грабля — сборка MFE. Каждый micro-frontend собирается через Node.js/webpack, и это самая прожорливая по памяти часть установки: сборка может упасть с OOM на сервере, где формально «хватает» RAM для рантайма всех остальных сервисов, но не хватает пикового запаса под сборку фронтенда. Решение — либо временно выделить больше памяти на время tutor images build mfe, либо собирать MFE на отдельной более мощной машине и заливать готовые образы на продакшен-сервер.

Сколько ресурсов реально нужно

Точные цифры зависят от числа курсов, одновременных пользователей и того, сколько плагинов вы включили, поэтому ниже — ориентировочные диапазоны по опыту сообщества, а не гарантированные минимумы. Проверяйте актуальные рекомендации в документации Tutor перед покупкой сервера — требования меняются от релиза к релизу.

Ключевой нюанс: RAM съедают не столько LMS/CMS в рантайме (это довольно скромные Django-приложения), сколько Elasticsearch (любит держать индекс в памяти) и одновременная сборка нескольких Docker-образов при обновлении — CI-подобная нагрузка на сервер, который в остальное время простаивает вполовину. Если сомневаетесь в объёме, лучше взять план с запасом по RAM и возможностью апгрейда без переустановки — сколько ресурсов нужно вашему проекту, разбирали отдельно для docker-контейнеров, логика лимитов CPU/памяти там применима и к Open edX.

Домены, TLS и MFE — где стопорится большинство новичков

Open edX ожидает не один домен, а несколько поддоменов — по одному на каждый крупный сервис:

lms.example.com          — сама платформа для студентов
studio.example.com       — Studio для авторов курсов
apps.example.com         — micro-frontends (learning, account, gradebook...)
discovery.example.com    — каталог курсов (если включён)
ecommerce.example.com    — оплата и сертификаты (если включён)
notes.example.com        — заметки студента (если включён)
credentials.example.com  — сертификаты (если включён)

Каждый из них должен резолвиться в IP вашего сервера ДО первого запуска — иначе Caddy (встроенный в Tutor reverse proxy) не сможет получить сертификаты Let's Encrypt и часть сервисов не поднимется. На практике это значит: заранее создать все A-записи, подождать распространения DNS и только потом запускать tutor local launch — попытка сэкономить время и стартовать раньше почти гарантированно приводит к ошибкам получения TLS-сертификата и требует повторного запуска после того, как DNS всё-таки разошёлся.

Вторая частая ошибка — недооценка того, что MFE-приложения обращаются к LMS и друг к другу по этим доменам напрямую из браузера пользователя, а не только «внутри докера». Если вы поменяли домен после первичной настройки, недостаточно поправить .env — нужно пересобрать MFE-образы с новым значением LMS_HOST/CMS_HOST, иначе фронтенд продолжит стучаться по старому адресу и будет падать с CORS-ошибками в консоли браузера. Это одна из самых частых причин «всё установилось, но белый экран» в форумах поддержки Open edX.

Что с видео, хранилищем и почтой

Видео — отдельная головная боль self-hosted MOOC-платформы. «Из коробки» Open edX умеет отдавать видео из нескольких источников: прямая ссылка на файл, YouTube-встройка или интеграция с внешним video pipeline для транскодирования в HLS с разными разрешениями под разную скорость соединения. Полноценный self-hosted транскодер — это отдельная инфраструктура (обычно на базе внешних сервисов или собственного pipeline с ffmpeg и очередями), которую Tutor из коробки не разворачивает. Для небольшого курса практичнее не гнаться за адаптивным битрейтом с первого дня, а начать с одного разрешения видео или встройки с YouTube/аналогичного сервиса, и добавлять транскодирование по мере роста аудитории.

Загруженные файлы (документы, изображения в курсах, экспортированные архивы курсов) по умолчанию хранятся на диске сервера. Это нормально для одного сервера, но плохо масштабируется и усложняет бэкапы — стоит сразу настроить S3-совместимое хранилище (через плагин tutor-contrib для внешнего storage backend), чтобы медиафайлы не росли бесконтрольно на системном диске и не блокировали снапшоты.

Почта нужна для сброса паролей, уведомлений о новых обсуждениях и рассылок от Ecommerce — без настроенного SMTP-релея часть функций платформы (регистрация, восстановление доступа) будет работать некорректно уже на этапе тестирования, а не только в продакшене. Tutor позволяет указать внешний SMTP через переменные SMTP_HOST/SMTP_PORT/SMTP_USER в конфиге — эти данные нужно получить у вашего почтового провайдера заранее, до финальной настройки.

Когда переходить с docker-compose на Kubernetes (или не переходить)

Базовый режим Tutor — tutor local — генерирует docker-compose и держит все сервисы на одном сервере. Для курса на десятки и сотни одновременных студентов этого достаточно, и не нужно усложнять инфраструктуру раньше времени. Официально поддерживаемый альтернативный режим — tutor k8s, разворачивающий тот же набор сервисов в Kubernetes с горизонтальным масштабированием отдельных компонентов (например, отдельное число реплик LMS под пиковую нагрузку записи на курс, без масштабирования остального).

Сигналы, что пора задуматься о Kubernetes, а не «просто добавить сервер помощнее»:

• LMS регулярно упирается в CPU в момент дедлайнов или открытия курса, а остальные сервисы простаивают — то есть надо масштабировать конкретный компонент, а не всё сразу;
• у вас несколько окружений (staging + production) и хочется единообразного деплоя без ручного повторения docker-compose команд;
• команда уже умеет администрировать k8s и это не создаёт новую точку отказа само по себе.

Если ничего из этого не про вас — миграция на Kubernetes ради самого факта «это же современно» добавит операционной сложности больше, чем снимет. Общие критерии перехода — не специфичные для Open edX — разобраны в статье из docker-compose в Kubernetes: когда это оправдано, и они применимы напрямую: единственный сервер под Tutor local можно держать годами, если нагрузка предсказуема.

Open edX vs Moodle: разные задачи, разная сложность

Open edX и Moodle часто сравнивают как взаимозаменяемые LMS, но это не совсем так — они решают разные задачи. Moodle исторически заточен под традиционный формат: курс с преподавателем, группой студентов, расписанием, оценками в стиле «электронного журнала» школы или вуза — это одна монолитная PHP-система с одной базой данных, которую реально поднять как один сервис плюс СУБД. Open edX спроектирован под MOOC-формат: массовые открытые онлайн-курсы с тысячами анонимных студентов, видео-лекциями, автоматической проверкой заданий и минимальным участием преподавателя в процессе прохождения — отсюда и микросервисная архитектура, рассчитанная на нагрузку и масштаб edx.org, а не на курс одного школьного класса.

Практический вывод: если вам нужна платформа для группы с преподавателем, знакомым интерфейсом «как в вузе» и минимумом инфраструктурной возни — начинать с Open edX ради «своей Coursera» избыточно, присмотритесь к более простой традиционной LMS. Если же вы действительно строите MOOC — публичные курсы для широкой аудитории с автоматизированной проверкой и видео как основным форматом — сложность Open edX окупается функциональностью, которую в простой LMS придётся дописывать самостоятельно.

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