Прежде чем настраивать хотя бы одно приложение, нужно решить, где будет размещена ваша база данных Odoo 19 Enterprise. Выбор размещения определяет, что можно доработать, кто управляет сервером, как часто нужно обновляться и кто отвечает за резервное копирование.
Odoo предлагает три варианта размещения: Odoo Online, Odoo.sh и собственный сервер (on-premise). Все три работают с одними и теми же стандартными приложениями Enterprise, но резко различаются, как только вам понадобится собственный код, доступ к серверу или определённый график обновлений.
Об источниках: это руководство опирается на официальную документацию Odoo для версии 19.0. Правила и политика размещения могут меняться, поэтому каждый важный для вашего проекта пункт проверьте в тестовой базе данных и сверьте с условиями своей подписки, прежде чем принимать решение.
Три варианта за одну минуту
- Odoo Online: программное обеспечение Odoo как услуга (SaaS). Odoo обслуживает серверы и платформу, а вы работаете в стандартных приложениях и Studio.
- Odoo.sh: официальная облачная платформа Odoo для размещения и управления Odoo с вашим собственным кодом, подключённая к репозиторию GitHub и организованная по веткам разработки, staging и production.
- Собственный сервер: вы устанавливаете и эксплуатируете Odoo на своём сервере или на арендованном облачном сервере и регистрируете базу данных с кодом подписки Enterprise.
Доработки: решающий фактор для большинства проектов
В документации Odoo прямо сказано, что Odoo Online несовместим с собственными модулями и с модулями из Odoo Apps Store. В Online вы настраиваете стандартные приложения и можете делать доработки в Studio, но установить собственные модули на Python нельзя.
Odoo.sh создан для работы с собственным кодом. Вы отправляете модули в ветку своего репозитория GitHub, и платформа автоматически находит папки с модулями Odoo. Можно добавлять и общедоступные модули сообщества, например как подмодули Git.
Собственный сервер даёт ту же свободу в отношении собственных модулей, что и Odoo.sh, поскольку вы управляете сервером и загружаемыми им дополнениями. Разница в том, что всё окружение вокруг кода никто за вас не обслуживает.
Практическое правило: если в требованиях есть любая собственная разработка на Python или любое стороннее приложение из Apps Store, Odoo Online исключается, и реальный выбор идёт между Odoo.sh и собственным сервером.
Контроль и доступ
В Odoo Online вы управляете базой данных через менеджер баз данных Odoo. Там можно создать её копию для тестирования, переименовать, скачать резервную копию, запустить доступное обновление, управлять доменными именами и передать права владения. Доступа к серверу или командной оболочке нет.
В Odoo.sh у каждой ветки есть инструменты разработчика в браузере: веб-оболочка для базовых команд Linux и psql, онлайн-редактор с консолями Python и Odoo shell, доступ по SSH с вашим собственным ключом и перехватчик почты, который задерживает письма из сборок, не относящихся к production.
Собственный сервер даёт полный контроль над операционной системой, PostgreSQL, обратным прокси и конфигурационным файлом Odoo. Руководство Odoo по развёртыванию рассматривает безопасность как непрерывный процесс и перечисляет такие задачи, как работа Odoo по HTTPS за обратным прокси, настройка фильтра баз данных на серверах с несколькими базами, использование пользователя PostgreSQL без прав суперпользователя и отключение менеджера баз данных на системах, доступных из интернета.
Обязательные обновления
Для каждого типа размещения действует своё правило обновления. При выборе его часто упускают из виду, а позднее оно становится срочным, поэтому обсуждайте его с первого дня.
- Odoo Online: согласно документации Odoo по обновлениям, базу данных на основной версии необходимо обновлять каждые два года, а базу данных на промежуточной версии — через несколько недель после выхода следующей версии. Если до установленного срока ничего не предпринято, Odoo обновляет базу данных автоматически.
- Odoo.sh: после первоначальных трёх лет поддержки версии у вас есть ещё два года на завершение обновления, и вы получаете уведомление, когда обновление становится обязательным.
- Собственный сервер: можно оставаться на одной версии сколь угодно долго. Odoo этого не рекомендует: чем меньше разрыв между версиями, тем проще обновление.
Собственные модули влияют на все варианты, кроме Online. Odoo указывает, что базу данных с собственными модулями нельзя обновить, пока эти модули не будут доступны для целевой версии, а обеспечение их совместимости — ответственность того, кто сопровождает модуль.
Для Odoo Enterprise услуга обновления охватывает стандартные приложения, доработки в Studio (пока Studio установлен и подписка активна), а также разработки, на которые оформлена подписка на сопровождение доработок. Собственные или сторонние модули без такого договора, очистка существующих данных и обучение не входят.
Рекомендуемый порядок одинаков на любой платформе: запросите обновлённую тестовую базу данных, обновите собственные модули, тщательно протестируйте, сообщите Odoo о проблемах, а затем спланируйте обновление production, во время которого база данных недоступна.
Резервные копии и тестовые копии
Odoo Online: в документации указано, что резервные копии создаются ежедневно в рамках SLA Odoo Cloud Hosting. Также можно скачать ZIP-архив резервной копии из менеджера баз данных; если база данных для этого слишком велика, служба поддержки Odoo предоставит другой способ.
Odoo.sh: база данных production автоматически копируется каждый день, и каждая копия включает дамп базы данных, хранилище файлов (filestore), журналы и сеансы. В документации указано хранение семи ежедневных, четырёх еженедельных и трёх ежемесячных копий, а выделенные серверы резервного копирования хранят дополнительные ежемесячные копии. Можно также создавать резервные копии вручную для сборок production и staging.
Сборки staging и разработки в Odoo.sh автоматически не копируются. Базы данных staging — это нейтрализованные копии production, которые через некоторое время удаляются, а базы разработки живут недолго и создаются на демонстрационных данных, поэтому никогда не храните реальную работу только там.
Собственный сервер: резервное копирование полностью на вас. Настройте регулярное копирование и базы данных PostgreSQL, и хранилища файлов, храните копии вне сервера и регулярно проверяйте восстановление.
Какой бы вариант вы ни выбрали, тестовые базы данных для обновления и базы данных staging в Odoo.sh нейтрализуются: запланированные действия отключаются, исходящая почта перехватывается или подменяется, а коннекторы платежей и доставки переводятся в тестовый режим. Это защищает production, но интеграции, которые вы хотите протестировать, нужно включать осознанно.
Факторы стоимости, которые можно сравнить без прайс-листа
Цены зависят от вашего договора и со временем меняются, поэтому сравнивайте не итоговые цифры, а то, из чего складывается стоимость.
- Объём подписки: для Odoo.sh нужен код подписки Enterprise, включающий размещение в Odoo.sh, а на собственном сервере используется подписка Enterprise, зарегистрированная на вашем сервере, причём к одной подписке привязывается одна база данных.
- Пользователи: база данных на собственном сервере должна оставаться в пределах числа пользователей по подписке; при превышении появляется предупреждение и даётся ограниченный срок на исправление, после чего срок действия базы данных истекает.
- Инфраструктура: в Odoo.sh вы подбираете число воркеров, объём хранилища и сборки staging в рамках платформы; на собственном сервере вы сами оплачиваете серверы, хранилище, трафик и мониторинг, а сервер должен сохранять сетевой доступ к службе проверки Odoo.
- Люди: для собственного сервера нужен специалист, умеющий администрировать Linux, PostgreSQL, HTTPS и обновления безопасности; для Odoo.sh нужны разработчики, уверенно работающие с Git; для Odoo Online не нужно ни того, ни другого.
- Жизненный цикл доработок: каждый собственный модуль нужно сопровождать и переносить при каждом обновлении, что становится регулярными расходами в Odoo.sh и на собственном сервере, если это не покрыто подпиской на сопровождение.
Кому подходит каждый вариант
Odoo Online подходит компаниям, которым достаточно стандартного Odoo и Studio, которые хотят быстрее всего начать работу и готовы следовать графику обновлений Odoo. Типичные кандидаты — торговые, сервисные и розничные компании со стандартными процессами.
Odoo.sh подходит проектам, которым нужны собственные модули или сторонние приложения, но которые не хотят обслуживать серверы и ценят возможность проверять каждое изменение на staging-копии production перед запуском.
Собственный сервер подходит организациям со своей ИТ-командой, строгими требованиями к месту хранения данных или к сети, интеграциями с локальным оборудованием или потребностью самим точно определять, когда проводить обновления.
Если вы рассматриваете Odoo Community, учтите, что для Odoo.sh нужен код подписки Enterprise, а описанная выше бесплатная услуга обновления — преимущество Enterprise, поэтому Community обычно размещают на собственном сервере и обновляют своими силами.
Enterprise — не отдельная кодовая база: в документации Odoo по установке репозиторий Enterprise описан как набор дополнительных модулей поверх Community, поэтому для установки Enterprise на собственном сервере нужны оба. Переход с Community на Enterprise в будущем — отдельный проект, поскольку документация Odoo по обновлениям не рассматривает смену редакции как часть обновления.
Переход между типами размещения в будущем
Выбор не окончательный, но в одних направлениях переход проще, чем в других.
- Из Odoo Online в Odoo.sh или на собственный сервер: скачайте резервную копию из менеджера баз данных и импортируйте или восстановите её. Промежуточные версии Online за пределами Online не поддерживаются, поэтому сначала может потребоваться обновление до следующей основной версии.
- Из Odoo.sh или с собственного сервера в Odoo Online: сначала нужно удалить все нестандартные приложения в сборке staging или в копии базы данных, а саму миграцию запрашивают через обращение в службу поддержки Odoo.
- С собственного сервера в Odoo.sh: используйте импорт на вкладке «Резервные копии» ветки production. Для импорта нужно свободное хранилище объёмом в четыре раза больше дампа, он перезаписывает текущие данные ветки и отключает серверы исходящей почты и запланированные действия, пока вы не включите нужные снова.
Контрольный список для принятия решения
- Нужен ли нам сейчас или в обозримом будущем какой-либо собственный модуль на Python или модуль из Apps Store? Если да, исключаем Odoo Online.
- Готовы ли мы принять обязательный график обновлений Odoo Online или нам нужно больше контроля над сроками смены каждой версии?
- Нужна ли нам staging-копия production для проверки каждого изменения перед запуском?
- Есть ли у нас или можем ли мы нанять специалистов для обслуживания Linux, PostgreSQL, HTTPS, мониторинга и безопасности собственного сервера?
- Есть ли ограничения по месту хранения данных, сети или оборудованию, требующие собственного сервера?
- Кто отвечает за проверку резервных копий и тестирование восстановления и как часто это будет делаться?
- Кто сопровождает и переносит наши собственные модули при каждом обновлении и покрыто ли это подпиской на сопровождение?
Чем может помочь 1CBMS
1CBMS помогает компаниям в Египте и Ираке выбрать подходящее размещение Odoo до начала внедрения. Мы сопоставляем ваши требования с возможностями каждой платформы, заранее выявляем потребность в собственных модулях, настраиваем проекты Odoo.sh или собственные серверы с надёжными практиками резервного копирования и безопасности и планируем обновления, чтобы ваша система Odoo 19 Enterprise оставалась на поддержке. Свяжитесь с нами через www.1cbms.com, чтобы обсудить вашу ситуацию.