Удельта

Пошаговая инструкция · Самостоятельная установка

Как установить Odoo Community на сервер

Пошаговая инструкция для самостоятельной установки. Установим Odoo Community для одной компании: шаг за шагом создадим базу, администратора и защищённый адрес. Отдельно проверим вложения, доступ сотрудника и комплект резервной копии.

Запуск системы управления бизнесом: заказ, склад и учёт соединены в рабочий процесс

Что подготовить #

Установим Odoo Community 20.0-20260926 для одной организации в базе company. PostgreSQL хранит записи, а filestore — отдельный каталог — вложения. Для восстановления нужны обе части. Enterprise-модули и перенос базы другой основной версии в эту инструкцию не входят.

Подготовьте Ubuntu 26.04 LTS, Docker Engine, Compose v2 и Nginx по общей инструкции. Зависимости Odoo находятся в официальном образе: системный Python Ubuntu не меняем. Команды выполняйте в SSH-терминале сервера от пользователя с sudo; если шаг завершился ошибкой, сначала исправьте её.

Создайте A-запись своего домена на IP сервера. Везде заменяйте erp.example.org этим доменом. Снаружи нужны 80/443 и ваш SSH-порт; 8069/8072/5432 не открывайте. Для первичной настройки используем туннель с компьютера читателя. Подготовьте почту администратора, SMTP-реквизиты и отдельное хранилище копий.

Настройка внешнего доступа использует обратный прокси Nginx и Certbot для Nginx. Приложение остаётся доступным на локальном порту; снаружи открыт его HTTPS-домен.

Шаг 1. Создайте каталоги Odoo #

Файлы запуска будут в /opt/odoo. config содержит настройки, addons — дополнительные модули, db-init — сценарий первого создания роли базы.

Создать каталог установки
sudo install -d -m 750 -o "$USER" -g "$USER" /opt/odoo
cd /opt/odoo
mkdir -p config addons db-init
chmod 700 config

Вы находитесь в /opt/odoo. При новом SSH-подключении сначала выполните cd /opt/odoo.

Шаг 2. Создайте три пароля #

Пароль PostgreSQL, пароль подключения Odoo и master password менеджера баз — разные значения. Команда сохраняет их в .env; выполняйте её один раз при новой установке.

Создать секреты
umask 077
printf 'DB_ADMIN_PASSWORD=%s\nODOO_DB_PASSWORD=%s\nODOO_MASTER_PASSWORD=%s\n' "$(openssl rand -hex 24)" "$(openssl rand -hex 24)" "$(openssl rand -hex 24)" > .env
chmod 600 .env

Все три параметра заполнены. Не добавляйте .env в Git и не заменяйте пароли уже созданной базы этой командой.

Шаг 3. Подготовьте роль приложения #

Сценарий создаст роль odoo без superuser. CREATEDB нужно лишь для первой базы: затем отнимем это право. Вставьте блок целиком в SSH-терминал.

Создать сценарий PostgreSQL
cat > db-init/10-odoo.sh <<'INIT'
#!/bin/bash
set -e
psql -v ON_ERROR_STOP=1 --username "$POSTGRES_USER" --dbname postgres --set=odoo_password="$ODOO_DB_PASSWORD" <<'SQL'
CREATE ROLE odoo LOGIN CREATEDB NOSUPERUSER NOCREATEROLE PASSWORD :'odoo_password';
SQL
INIT
chmod 755 db-init/10-odoo.sh

db-init/10-odoo.sh создан и доступен для исполнения. PostgreSQL выполняет его только при первом старте пустого тома.

Шаг 4. Сохраните Compose #

Выполните nano compose.yaml и вставьте файл ниже. Два постоянных тома сохраняют базу и вложения отдельно от заменяемых контейнеров.

Файл /opt/odoo/compose.yaml
services:
  db:
    image: postgres:17
    restart: unless-stopped
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: ${DB_ADMIN_PASSWORD:?}
      POSTGRES_DB: postgres
      ODOO_DB_PASSWORD: ${ODOO_DB_PASSWORD:?}
    volumes:
      - database:/var/lib/postgresql/data
      - ./db-init:/docker-entrypoint-initdb.d:ro
    healthcheck:
      test: [CMD-SHELL, 'pg_isready -h 127.0.0.1 -U postgres -d postgres']
      interval: 10s
      timeout: 5s
      retries: 10
  web:
    image: odoo:20.0-20260926
    restart: unless-stopped
    environment:
      HOST: db
      USER: odoo
      PASSWORD: ${ODOO_DB_PASSWORD:?}
    ports:
      - 127.0.0.1:8069:8069
      - 127.0.0.1:8072:8072
    volumes:
      - application:/var/lib/odoo
      - ./config/odoo.conf:/etc/odoo/odoo.conf:ro
      - ./addons:/mnt/extra-addons:ro
    depends_on:
      db:
        condition: service_healthy
volumes:
  database:
  application:

Сохраните Ctrl+O, Enter, Ctrl+X. Odoo подключается к PostgreSQL отдельной ролью odoo; база не опубликована наружу.

Шаг 5. Сохраните настройки Odoo #

Выполните nano .env, найдите ODOO_MASTER_PASSWORD и сохраните значение в менеджере паролей. Затем откройте nano config/odoo.conf и вставьте блок ниже. Замените ЗАМЕНИТЕ_MASTER_PASSWORD этим значением: INI-файл сам не читает переменные .env. workers=2 — начальная настройка, а list_db=True временно разрешает мастер базы.

Файл /opt/odoo/config/odoo.conf
[options]
admin_passwd = ЗАМЕНИТЕ_MASTER_PASSWORD
addons_path = /mnt/extra-addons
data_dir = /var/lib/odoo
proxy_mode = True
workers = 2
max_cron_threads = 1
gevent_port = 8072
dbfilter = ^company$
list_db = True

Сохраните Ctrl+O, Enter, Ctrl+X. Master password отличается от будущего пароля входа администратора. Имя базы в примере company.

Шаг 6. Разрешите контейнеру читать настройки #

Файл должен читаться пользователем Odoo внутри контейнера. Каталог config с правами 700 продолжает ограничивать доступ других пользователей хоста.

Установить права файла
chmod 644 config/odoo.conf

Команда завершилась без ошибки; настройки готовы для чтения в контейнере.

Шаг 7. Проверьте Compose #

До скачивания образов проверим YAML и обязательные пароли.

Проверить файл запуска
docker compose config --quiet

Нет ошибок или сообщений о пустых переменных. Если они есть, исправьте файлы до продолжения.

Шаг 8. Загрузите Odoo и PostgreSQL #

Docker скачает выбранный датированный образ Odoo и PostgreSQL 17.

Загрузить образы
docker compose pull

Загрузка завершилась без ошибок.

Шаг 9. Запустите локальную установку #

Nginx пока не публикуем: сначала создадим базу и её администратора.

Запустить Odoo
docker compose up -d

После короткого ожидания docker compose ps показывает db и web работающими. Постоянный перезапуск требует проверки docker compose logs --tail=80 web db.

Шаг 10. Откройте SSH-туннель с компьютера #

Команду ниже выполняйте во втором терминале на своём компьютере. Замените deploy SSH-пользователем, SERVER_IP — IP сервера. -N оставляет туннель без интерактивной сессии.

На вашем компьютере: открыть туннель
ssh -N -L 18069:127.0.0.1:8069 deploy@SERVER_IP

Терминал остаётся работающим без вывода. В браузере компьютера откройте http://127.0.0.1:18069/web/database/manager: появился мастер базы.

Шаг 11. Создайте базу company #

В мастере укажите master password из шага 5, имя company, личную почту и новый длинный пароль администратора Odoo. Выберите язык и страну; демонстрационные данные выключите. Дождитесь создания базы, не повторяя отправку формы.

Открылась Odoo, вход администратора работает. Пароль пользователя сохранён отдельно от master password.

Шаг 12. Закройте выбор базы #

На сервере откройте nano config/odoo.conf. Замените list_db=True на False и добавьте db_name=company, как ниже. Остальные настройки сохраните.

Изменённые строки config/odoo.conf
db_name = company
list_db = False

Сохраните Ctrl+O, Enter, Ctrl+X. Odoo теперь предназначена для одной известной базы.

Шаг 13. Отнимите право создавать базы #

Теперь роль приложения не должна создавать новые базы. Команда изменяет роль PostgreSQL, затем перезапуск web применяет изменённый odoo.conf.

Закрыть создание баз и применить настройки
docker compose exec -T db psql -U postgres -d postgres -c "ALTER ROLE odoo NOCREATEDB;"
docker compose restart web

PostgreSQL ответила ALTER ROLE, web снова работает. Туннель на компьютере можно закрыть Ctrl+C.

Шаг 14. Сохраните сайт Nginx #

Установите Nginx и Certbot по подготовке Ubuntu, если ещё не установили. Откройте sudo nano /etc/nginx/sites-available/odoo и вставьте файл ниже. Замените все домены своими. Nginx передаёт приложению домен, адрес клиента и протокол; Upgrade и Connection сохраняют WebSocket. До получения сертификата условие $scheme блокирует обычные HTTP-запросы кодом 403, чтобы вход не происходил без шифрования. Обычные запросы идут на 8069, /websocket — на 8072; URI сохраняется целиком. Менеджер баз /web/database/ дополнительно закрыт ответом 403.

Файл /etc/nginx/sites-available/odoo
map $http_upgrade $odoo_connection_upgrade {
    default upgrade;
    "" close;
}

server {
    listen 80;
    server_name erp.example.org;
    client_max_body_size 100m;
    location ^~ /web/database/ { return 403; }
    location /websocket {
        if ($scheme = http) { return 403; }
        proxy_pass http://127.0.0.1:8072;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $odoo_connection_upgrade;
        proxy_read_timeout 3600s;
        proxy_send_timeout 3600s;
        proxy_buffering off;
    }
    location / {
        if ($scheme = http) { return 403; }
        proxy_pass http://127.0.0.1:8069;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $odoo_connection_upgrade;
        proxy_read_timeout 3600s;
        proxy_send_timeout 3600s;
        proxy_buffering off;
    }
}

Сохраните Ctrl+O, Enter, Ctrl+X. В файле пока нет путей к сертификатам: Nginx сможет проверить его до выпуска HTTPS.

Шаг 15. Подключите сайт и проверьте HTTP #

Ссылка подключает сохранённый сайт. nginx -t проверяет все настройки сервера; && разрешает перечитать их только при успешной проверке. curl проверяет ответ для вашего домена. При ошибке остановитесь, исправьте указанную строку и повторите проверку.

Подключите сайт и проверьте HTTP
sudo ln -sfn /etc/nginx/sites-available/odoo /etc/nginx/sites-enabled/odoo
sudo nginx -t && sudo systemctl reload nginx
curl -I http://erp.example.org/

Ожидается successful от nginx -t и HTTP 403 для обычного запроса: до HTTPS это намеренная блокировка. DNS должен указывать на сервер, TCP 80/443 — быть доступен у провайдера. Ничего не вводите в форму входа по HTTP.

Шаг 16. Получите сертификат и включите HTTPS #

Каждое имя из команды должно указывать на этот сервер. Certbot проверит домены, сам добавит сертификат в сайт Nginx и включит перенаправление HTTP → HTTPS. Укажите свою почту при запросе и подтвердите условия Let’s Encrypt. Это отдельное действие после успешной проверки HTTP.

Получите сертификат и включите HTTPS
sudo /snap/bin/certbot --nginx -d erp.example.org --redirect

Certbot сообщил об успешной установке. Откройте HTTPS-адрес со своего компьютера: браузер не должен предупреждать о сертификате. Для закрытой панели используйте разрешённый IP. При ошибке исправьте DNS, в том числе AAAA, либо доступ к TCP 80; не повторяйте запросы выпуска подряд.

Шаг 17. Проверьте продление сертификата #

Certbot из snap создаёт службу автоматического продления. Dry-run выполняет пробное продление: настоящие сертификаты не заменяются. Затем проверьте, что таймер планирует следующий запуск. Сохраняйте доступ к TCP 80 для следующих проверок домена.

Проверьте продление сертификата
sudo /snap/bin/certbot renew --dry-run
systemctl list-timers --all 'snap.certbot.renew*'

Пробное продление успешно, у таймера есть следующий запуск. Если тест не прошёл, проверьте /var/log/letsencrypt/letsencrypt.log; сначала исправьте причину. После этого можно создавать учётную запись и приглашать пользователей.

Шаг 18. Настройте организацию и почту #

В Odoo заполните данные своей компании. В исходящих почтовых серверах задайте SMTP-реквизиты и проверьте соединение. Проверьте web.base.url на ваш HTTPS-домен; если ссылки возвращаются к туннелю, зафиксируйте адрес параметром web.base.url.freeze в режиме разработчика.

Тестовое письмо получено, ссылки ведут на правильный домен. Рабочие модули устанавливайте по одному и проверяйте их совместимость с Odoo 20.

Шаг 19. Проверьте запись и вложение #

Создайте обычного сотрудника и одну тестовую карточку контакта. Добавьте небольшой файл, затем откройте карточку сотрудником. Если используете чат, отправьте сообщение между двумя браузерами.

Контакт и файл читаются с разрешёнными правами; чат обновляется без перезагрузки. Так проверены база, filestore и WebSocket.

Шаг 20. Подготовьте каталог копии #

В SSH вернитесь в /opt/odoo и создайте новый каталог. Следующие шаги выполняйте в той же сессии.

Создать каталог резервной копии
cd /opt/odoo
umask 077
ODOO_BACKUP="$HOME/odoo-backup-$(date +%F-%H%M)"
mkdir -p "$ODOO_BACKUP/application"

Каталог готов. Согласуйте короткую остановку Odoo: база и вложения копируются при остановленной записи приложения.

Шаг 21. Выгрузите базу company #

Остановим только web и выгрузим PostgreSQL. На время шага сотрудники не смогут работать в Odoo.

Создать дамп company
docker compose stop web
docker compose exec -T db pg_dump -U odoo -Fc company > "$ODOO_BACKUP/company.dump"

pg_dump завершился без ошибки; дамп не пуст. База остаётся работающей.

Шаг 22. Сохраните вложения и верните Odoo #

Скопируем постоянный каталог Odoo, конфигурацию и модули, затем возобновим работу. Эти файлы составляют одну копию с дампом предыдущего шага.

Сохранить filestore, настройки и запустить web
sudo docker compose cp -a web:/var/lib/odoo/. "$ODOO_BACKUP/application/"
cp -a config addons db-init .env compose.yaml "$ODOO_BACKUP/"
docker compose up -d web

Вход, контакт и вложение снова доступны. Перенесите комплект в закрытое хранилище вне сервера.

Как проверить восстановление #

На отдельной машине используйте ту же сборку Odoo и те же модули. Восстановите PostgreSQL и каталог application вместе: вложения должны оказаться в filestore/company. До запуска тестовой копии отключите почту и задания, которые меняют внешние системы. Проверьте вход, права, контакт, вложение и нужный PDF. Сначала подтвердите копию на исходной версии; перенос на новую основную версию — отдельная миграция.

Если шаг не работает и как обновлять #

В /opt/odoo проверьте docker compose logs --tail=80 web db. Ошибка базы требует сверить роль и пароль; редактирование .env не меняет пароль существующего PostgreSQL-тома. Пропавшие файлы требуют проверки application и имени company; проблемы чата — маршрута /websocket и порта 8072.

Для обновления внутри 20.0 сначала испытайте копию и конкретный датированный тег с вашими модулями. После обновления повторите вход, контакт, файл, PDF, чат и почту. Переход с другой основной версии требует миграции; простая замена образа её не выполняет. Не запускайте массовое обновление всех модулей без проверки на копии.

Настройки внешнего доступа храните вместе с копией приложения: /etc/nginx/sites-available/odoo и /etc/letsencrypt содержат сайт и сертификаты с закрытыми ключами. Архивируйте их с sudo в закрытое хранилище. После восстановления подключите сайт через sites-enabled, выполните sudo nginx -t, затем перечитайте Nginx. Для ошибки 502 сначала проверьте локальное приложение и /var/log/nginx/error.log; для сертификата — /var/log/letsencrypt/letsencrypt.log и таймер продления.

Обсудить установку и настройку

Материал был полезен?

Сообщить об ошибке или задать вопрос редакции

Сообщение увидит редакция. Не указывайте пароли и личные данные. Текст удаляется через 180 дней.

О материале

ИнфраструктураРуководствоЗадача: установитьУровень: практикаOdoo

Последнее обновление:

Обсуждение

Комментарии проходят подтверждение адреса и проверку редакцией.