Odoo на Ubuntu 24.04: пошаговая установка

MAATRIX

Odoo — модульная ERP/CRM-система: продажи, склад, бухгалтерия, HR и десятки других приложений в одной базе, без ежемесячной платы за пользователя, если разворачивать её self-hosted. Проблема в том, что сама установка — это не «скачал и запустил»: нужен правильно настроенный PostgreSQL, отдельный системный пользователь, systemd-сервис с лимитами памяти, reverse-proxy для HTTPS и вебсокетов. Ниже — рабочий пошаговый рецепт для Ubuntu 24.04, доведённый до состояния, в котором систему не стыдно показать пользователям.

Что понадобится и сколько ресурсов заложить

Odoo — это Python-приложение поверх PostgreSQL, и требования к серверу сильно зависят от числа одновременных пользователей и набора установленных модулей (бухгалтерия и склад с большими отчётами едят память заметно активнее, чем CRM).

Ориентировочно (именно ориентировочно — точные цифры зависят от ваших модулей и объёма данных):

Диск обязательно SSD/NVMe — PostgreSQL под Odoo активно пишет и делает много мелких запросов, на HDD интерфейс будет заметно тормозить уже на 5-10 пользователях. Если вы рассчитываете вырасти за пределы одного VPS, посмотрите сразу конфигурацию выделенного сервера для CRM на сотни пользователей — там правильнее выносить PostgreSQL на отдельную машину.

Дальше — установка на чистый Ubuntu 24.04 с рутовым (или sudo) доступом.

Готовим сервер: обновления, PostgreSQL, зависимости

Сначала система:

apt update && apt upgrade -y
apt install -y wget gnupg2 curl

PostgreSQL под Odoo не нужен экзотической версии — подойдёт та, что идёт в репозиториях Ubuntu 24.04:

apt install -y postgresql postgresql-contrib
systemctl enable --now postgresql

Odoo будет подключаться к PostgreSQL от отдельной роли, а не от суперпользователя postgres — это единственный вариант, который не превращает утечку конфига в компрометацию всей базы данных. Создайте роль с правом CREATEDB, но без SUPERUSER:

sudo -u postgres createuser --createdb --no-superuser --no-createrole odoo

Пароль этой роли отдельно не задаём — аутентификация пойдёт через peer/локальный сокет, что снимает вопрос хранения пароля БД в конфиге. Если PostgreSQL стоит на отдельном сервере, роли нужен пароль и md5/scram-sha-256 в pg_hba.conf — тогда пригодится статья про тюнинг PostgreSQL на VPS, она же пригодится позже, когда база разрастётся и запросы начнут тормозить.

Устанавливаем Odoo из официального репозитория

Самый предсказуемый способ — официальный apt-репозиторий Odoo, который сам подтягивает Python-зависимости, wkhtmltopdf (нужен для PDF-отчётов и печати документов) и создаёт системного пользователя odoo:

wget -O - https://nightly.odoo.com/odoo.key | gpg --dearmor -o /usr/share/keyrings/odoo-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/odoo-archive-keyring.gpg] https://nightly.odoo.com/19.0/nightly/deb/ ./" | tee /etc/apt/sources.list.d/odoo.list
apt update
apt install -y odoo

Вместо 19.0 можно подставить 18.0 или другую нужную ветку — команды идентичны, меняется только номер версии в пути. После установки пакет:

• создаёт системного пользователя odoo без прав на shell-логин;
• кладёт конфиг в /etc/odoo/odoo.conf;
• регистрирует systemd-юнит odoo.service;
• разворачивает код в /usr/lib/python3/dist-packages/odoo;
• слушает 8069 (веб-интерфейс) и 8072 (longpolling/websocket для чатов и уведомлений в реальном времени).

Проверьте, что сервис поднялся:

systemctl status odoo
ss -tlnp | grep 8069

Если хотите ставить и разрабатывать кастомные модули из исходников (git clone + venv), а не через deb-пакет — это отдельный, более гибкий путь, но для продакшена он оправдан в основном для агентств, которые сами пишут addons. Для обычного self-hosted развёртывания deb-пакет удобнее и надёжнее: меньше шансов разойтись версиями системных библиотек Python.

Правим конфиг: воркеры, лимиты памяти, addons_path

По умолчанию Odoo запускается в однопроцессном режиме (workers = 0) — это нормально для теста, но под реальной нагрузкой один процесс блокируется на каждом длинном запросе. Откройте /etc/odoo/odoo.conf:

[options]
admin_passwd = замените-на-длинный-случайный-пароль
db_host = False
db_port = False
db_user = odoo
db_password = False
addons_path = /usr/lib/python3/dist-packages/odoo/addons,/mnt/extra-addons
data_dir = /var/lib/odoo

; продакшен-режим: несколько воркеров вместо одного процесса
workers = 4
max_cron_threads = 1
limit_memory_soft = 671088640
limit_memory_hard = 1342177280
limit_time_cpu = 600
limit_time_real = 1200

; сервер за reverse-proxy
proxy_mode = True
logfile = /var/log/odoo/odoo.log

Число воркеров считается по стандартной формуле Odoo: workers = (число ядер × 2) + 1, минус 1 воркер под cron-задачи. Для 2-ядерного сервера это обычно 2-3 воркера, для 4-ядерного — 4-5. Лимиты памяти (limit_memory_soft/hard) — это защита от одного «убегающего» отчёта: при превышении soft-лимита воркер завершает текущий запрос и перезапускается, при hard — убивается принудительно. Значения в примере — 640 МБ / 1280 МБ на воркер, ориентир для сервера с 4-8 ГБ RAM; на слабой машине их стоит уменьшить, иначе воркеры начнут упираться в OOM killer ядра.

addons_path — куда Odoo смотрит за модулями. Если планируете ставить сторонние addons (например, с сайта Odoo Apps) или свои, создайте отдельную папку и добавьте её в этот путь:

mkdir -p /mnt/extra-addons
chown odoo:odoo /mnt/extra-addons

После правок — перезапуск:

systemctl restart odoo
journalctl -u odoo -n 50 --no-pager

Если в логе ошибки подключения к базе — проверьте, что роль odoo в PostgreSQL действительно существует и что db_host/db_port в конфиге соответствуют вашей схеме (локальный сокет — False, отдельный сервер БД — его адрес).

Nginx как reverse-proxy и SSL через Let's Encrypt

Отдавать Odoo напрямую на 8069 в интернет — плохая идея: нет HTTPS, нет ограничения тела запроса, нет разделения обычных запросов и websocket-соединений. Ставим Nginx:

apt install -y nginx

Домен должен уже указывать A-записью на IP сервера — если ещё не настраивали, сначала пройдите настройку домена и DNS с нуля. Конфиг /etc/nginx/sites-available/odoo:

upstream odoo {
    server 127.0.0.1:8069;
}
upstream odoo-chat {
    server 127.0.0.1:8072;
}

server {
    listen 80;
    server_name erp.example.com;

    proxy_read_timeout 720s;
    proxy_connect_timeout 720s;
    proxy_send_timeout 720s;
    client_max_body_size 100m;

    location /websocket {
        proxy_pass http://odoo-chat;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;
    }

    location / {
        proxy_pass http://odoo;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;
    }

    gzip on;
    gzip_types text/css text/plain application/xml application/json application/javascript;
}

client_max_body_size 100m — иначе импорт CSV или загрузка вложений упрётся в стандартный лимит Nginx в 1 МБ. Активируем и выпускаем сертификат:

ln -s /etc/nginx/sites-available/odoo /etc/nginx/sites-enabled/
nginx -t && systemctl reload nginx

apt install -y certbot python3-certbot-nginx
certbot --nginx -d erp.example.com

Certbot сам допишет блок listen 443 ssl и настроит редирект с 80 на 443. Подробный разбор шагов и типичных ошибок — в статье про установку Let's Encrypt SSL на VPS. Не забудьте закрыть 8069/8072 от внешнего мира в фаерволе (ufw deny 8069, ufw deny 8072), оставив только 80/443 — снаружи Odoo должен быть виден исключительно через Nginx.

Первый запуск: мастер-пароль, база данных, модули

Открывайте https://erp.example.com — попадёте на экран управления базами данных (Database Manager). Здесь вводится admin_passwd (мастер-пароль) — тот, который вы прописали в /etc/odoo/odoo.conf, — плюс:

• имя базы данных (латиницей, без пробелов, например company);
• email и пароль первого администратора;
• язык и страна — от этого зависят локализация и план счетов по умолчанию;
• галочка «Load demo data» — для продакшена её нужно снять, демо-данные полезны только на тесте.

После создания базы вы попадаете в интерфейс Odoo и можете ставить приложения: Sales, Inventory, Accounting, CRM и остальные — через меню Apps, по одному клику на каждый модуль. Ставьте только то, что реально нужно: чем больше активных приложений, тем тяжелее становится каждый запрос к базе (больше вычисляемых полей, больше связанных моделей).

Важный шаг безопасности после того, как база создана: отключите публичный доступ к Database Manager, иначе кто угодно сможет создавать или удалять базы на вашем сервере. В /etc/odoo/odoo.conf:

list_db = False
dbfilter = ^company$

dbfilter ограничивает, какие базы вообще видны через веб — полезно и для мультибазовых инсталляций (например, dbfilter = ^%h$, если поддомен должен совпадать с именем базы).

Бэкапы и обновления

У Odoo два места, которые нужно бэкапить синхронно: сама база PostgreSQL и filestore (вложения, картинки товаров, PDF) на диске. Дамп базы:

sudo -u postgres pg_dump -Fc company > /backup/company_$(date +%F).dump

Filestore лежит в data_dir из конфига (в примере выше — /var/lib/odoo), в подпапке filestore/<имя_базы>. Простой скрипт для крон-задачи:

#!/bin/bash
DATE=$(date +%F)
mkdir -p /backup/odoo
sudo -u postgres pg_dump -Fc company > /backup/odoo/company_$DATE.dump
tar -czf /backup/odoo/filestore_$DATE.tar.gz -C /var/lib/odoo/filestore company
find /backup/odoo -mtime +14 -delete

Положите его в /etc/cron.daily/ и сделайте исполняемым (chmod +x). Восстановление — pg_restore для дампа плюс распаковка filestore обратно в ту же папку.

Обновление минорных версий (18.0 → 18.0 с новым патчем) идёт штатным apt upgrade odoo — пакет обновится, сервис перезапустится сам через post-install хук. Обновление между мажорными версиями (18.0 → 19.0) — это уже миграция данных: меняются модели, могут ломаться кастомные модули, и делать это нужно на копии базы, а не на проде. Перед любым мажорным апгрейдом — обязательно снимите полный бэкап (дамп + filestore) и проверьте апгрейд на тестовом сервере.

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