Toggle navigation

Развертывание (Deploy) - Odoo 9.0

В этом документе описаны основные шаги по настройке Odoo на сервере. Их нужно делать после установки. Они обычно не нужны для окружения разработки, которые не видны в интернете.

dbfilter

Одна система Odoo может запускаться и обслуживать несколько экземпляров базы данных. Каждый из них имеет свои индивидуальные настройки (например установленные модули) в зависимости от базы данных, которая используется в данный момент.

Это не проблема при работе только с бэкэндом (веб-клиентом) в качестве зарегистрированного пользователя компании: при входе в систему можно выбрать базу данных и Odoo запомнит какую именно.

Однако это проблема проявляется для не зарегистрированных пользователей (портала, веб-сайта), которые не привязаны к базе данных: Odoo нужно знать, какая база данных должна использоваться для конкретных операций или для получения данных. Если используется одна база данных, то Odoo работает с ней, но если доступно несколько баз данных, то Odoo нуждается в правиле, чтобы узнать, какую из них нужно использовать.

Для этих целей используется --db-filter: он указывает базу данных по умолчанию для системы Odoo. Значение представляет собой регулярное выражение, включая динамически введенное имя хоста или поддомен, через который осуществляется обращение к системе Odoo.

Если Odoo содержит несколько баз данных на сервере, особенно если используется website, он должен использовать dbfilter, или некоторые функции не будут работать корректно или вообще не будут использоваться.

Пример конфигурации

  • фильтрация баз данных с именем, начинающимся на 'mycompany'

в /etc/odoo/odoo.conf установите:

[options]
dbfilter = ^mycompany.*$

  • фильтрация баз данных с именем, равным имени хоста без домена

в /etc/odoo/odoo.conf установите:

[options]
dbfilter = %d

PostgreSQL

По умолчанию PostgreSQL разрешает только подключение к UNIX-сокетам и loopback соединениям (из "localhost", той же машине, на которой установлен сервер PostgreSQL).

UNIX-сокет удобен, если вы хотите, чтобы Odoo и PostgreSQL выполнялись на одном компьютере, и по умолчанию не задаются адреса компьютеров, но если вы хотите, чтобы Odoo и PostgreSQL выполнялись на разных машинах 1, то необходимо listen to network interfaces 2, либо:

  • только принимать соединения loopback и use an SSH tunnel между машиной, на которой работает Odoo, и тем, на котором запускается PostgreSQL, а затем настроить Odoo для подключения к туннелю

  • принимать соединения с машиной, на которой установлен Odoo, возможно, поверх ssl (см. PostgreSQL connection settings для получения подробной информации), затем настройте Odoo для подключения по сети

Пример конфигурации

  • разрешить tcp-соединение с localhost

  • разрешить tcp-соединения из сети 192.168.1.x

в /etc/postgresql/9.5/main/pg_hba.conf пропишите:

# IPv4 local connections:
host    all             all             127.0.0.1/32            md5
host    all             all             192.168.1.0/24          md5

в /etc/postgresql/9.5/main/postgresql.conf пропишите:

listen_addresses = 'localhost,192.168.1.2'
port = 5432
max_connections = 80

Настройка Odoo

Из коробки Odoo подключается к локальному postgres через сокет UNIX и порт 5432. Эти параметры можно переопределить, используя параметры базы данных, если Postgres установлен не локально и/или не использует установки по умолчанию.

При установке с использовании инсталяторов автоматически создаст нового пользователя (odoo) и установит его как пользователя базы данных.

  • Экран управления базами данных защищен паролем, который устанавливается настройкой admin_passwd. Этот параметр можно установить только в файле конфигурации, и он используется перед выполнением изменений базы данных. Он должен быть произвольно сгенерированным значением, чтобы гарантировать, что из вне никто не получит доступ к вашим базам данных.

  • все операции с базой данных используют параметры базы данных, включая экран управления базой данных. Для корректной работы экрана управления базами данных роль пользователя PostgreSQL имеет createdb.

  • пользователь создавший базу данных имеет право ее удалить. Чтобы этого нельзя было сделать через экран управления базами данных, пользователь odoo должен быть создан с правами no-createdb, а база данных должна принадлежать другому пользователю.

Пример конфигурации

  • подключиться к серверу PostgreSQL по адресу 192.168.1.2

  • порт 5432

  • используется учетную запись 'odoo'

  • с 'pwd' в качестве пароля

  • фильтрация баз данных с именем, начинающимся на 'mycompany'

в /etc/odoo/odoo.conf установите:

[options]
admin_passwd = mysupersecretpassword
db_host = 192.168.1.2
db_port = 5432
db_user = odoo
db_password = pwd
dbfilter = ^mycompany.*$

Встроенный сервер

Odoo включает в себя встроенный HTTP-сервер, который использует многопоточность и многопроцессорность.

Для использования на продакшене рекомендуется использовать многопроцессорность на сервере, поскольку это повышает стабильность, улучшает использование вычислительных ресурсов и может быть лучше контролироваться.

  • Многопроцессорность включается путем настройки ненулевое число рабочих процессов, количество workers должно быть равно количеству ядер процессора (возможно, в некоторых случаях стоит учесть сколько ядер процессора выделено для Cron)

  • Ограничения Worker настраиваются основываясь на конфигурации оборудования, чтобы избежать исчерпания ресурсов

Расчет количества worker

  • Рассчитывается по формуле: (#CPU * 2) + 1

  • Cron Workers используют процессор

  • 1 worker ~ 6 конкурентных пользователей

расчет размера необходимого ОЗУ

  • Мы считаем, что 20% запросов - это тяжелые запросы, а 80% - более простые

  • "Тяжелый" worker, когда все вычисляемые поля хорошо ортимизированы, SQL-запросы хорошо разработаны, ... оценивается примерно в 1Gb ОЗУ

  • "Более легкий" worker, в том же сценарии, по оценкам, потребляет около 150 МБ ОЗУ

Необходимое кол-во ОЗУ = #worker * ((light_worker_ratio * light_worker_ram_estimation) + (heavy_worker_ratio * heavy_worker_ram_estimation))

Живой чат

При многопроцессорной работе автоматически запускается выделенный LiveChat worker и слушает порт longpolling, но клиент не подключается к нему.

Вместо этого у вас должны быть перенаправленные прокси-запросы, URL которых начинается с /longpolling/ на порт longpolling. Остальные запросы должен быть проксирован на обычный HTTP порт

Пример конфигурации

  • Сервер с 4 процессорами, 8 потоков

  • 60 одновременных пользователей

  • 60 пользователей / 6 = 10 <- теоретическое число worker

  • (4 * 2) + 1 = 9 <- теоретическое максимальное число worker

  • Мы будем использовать 8 worker + 1 для cron. Мы также будем использовать систему мониторинга для измерения нагрузки процессора и проверим, составляет ли она от 7 до 7.5.

  • RAM = 9 * ((0,8 * 150) + (0,2 * 1024)) ~ 3Gb ОЗУ для Odoo

в /etc/odoo/odoo.conf:

[options]
limit_memory_hard = 1677721600
limit_memory_soft = 629145600
limit_request = 8192
limit_time_cpu = 600
limit_time_real = 1200
max_cron_threads = 1
workers = 8

HTTPS

Независимо от того, используете ли вы Odoo как веб-сайт, или как веб-клиент, или как веб-сервис, Для безопасной передачи информацию аутентификации нужно использоваться HTTPS[#switching] _. SSL может быть реализован с помощью любого прокси-сервера, но для этого потребуются следующие настройки:

  • включить Odoo's proxy mode. Это настройка нужна тогда, когда Odoo находится за обратным прокси-сервером

  • настроить прокси-сервер для работы по SSL (Nginx termination example)

  • настроить прокси сервер (Nginx proxying example)

  • ваш прокси-сервер должен автоматически перенаправлять незащищенные обращения на защищенный порт

подключения к защищенному порту

Пример конфигурации

  • перенаправить HTTP-запросы на https

  • проксирование запросов в Odoo

в /etc/odoo/odoo.conf установите:

proxy_mode = True

в /etc/nginx/sites-enabled/odoo.conf:

#odoo server
upstream odoo {
 server 127.0.0.1:8069;
}
upstream odoochat {
 server 127.0.0.1:8072;
}

# http -> https
server {
   listen 80;
   server_name odoo.mycompany.com;
   rewrite ^(.*) https://$host$1 permanent;
}

server {
 listen 443;
 server_name odoo.mycompany.com;
 proxy_read_timeout 720s;
 proxy_connect_timeout 720s;
 proxy_send_timeout 720s;

 # Add Headers for odoo proxy mode
 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;

 # SSL parameters
 ssl on;
 ssl_certificate /etc/ssl/nginx/server.crt;
 ssl_certificate_key /etc/ssl/nginx/server.key;
 ssl_session_timeout 30m;
 ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
 ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
 ssl_prefer_server_ciphers on;

 # log
 access_log /var/log/nginx/odoo.access.log;
 error_log /var/log/nginx/odoo.error.log;

 # Redirect requests to odoo backend server
 location / {
   proxy_redirect off;
   proxy_pass http://odoo;
 }
 location /longpolling {
     proxy_pass http://odoochat;
 }

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

Odoo как приложение WSGI

Также возможно установить Odoo в качестве стандартного приложения WSGI. Odoo предоставляет базу для сценария запуска WSGI - openerp-wsgi.py. Этот скрипт должен быть настроен (возможно, после его копирования из каталога установки), чтобы правильно настроить конфигурацию непосредственно в openerp.tools.config, а не через командную строку или файл конфигурации.

Сервер WSGI будет работать для веб-клиента, веб-сайта и API веб-сервиса, но Odoo не будет контролировать создание workers, он не сможет настроить workers cron или livechat workers

Задания Cron

Для выполнения заданий cron при развертывании Odoo в качестве приложения WSGI требуется

  • классический Odoo (запускается как odoo.py)

  • подключение к базе данных, в которой должны выполняться задания cron (через odoo.py -d)

  • если нужно обеспечить, чтобы задания cron не были доступны для сети, можно полностью отключить встроенный HTTP-сервер с помощью опции odoo.py --no-xmlrpc или настройкой xmlrpc = False в файле конфигурации.

Живой чат

Второй проблемной подсистемой при развертывании Odoo, как приложения WSGI, является LiveChat: где большинство HTTP-соединений относительно короткие и быстро освобождают рабочий процесс для следующего запроса, LiveChat требует долговременного подключения для каждого клиента, чтобы внедрять уведомления в режиме реального времени.

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

Решения для поддержки живого чата и уведомлений в приложении WSGI:

  • deploy a threaded version of Odoo (instread of a process-based preforking one) and redirect only requests to URLs starting with /longpolling/ to that Odoo, this is the simplest and the longpolling URL can double up as the cron instance.
  • deploy an evented Odoo via openerp-gevent and proxy requests starting with /longpolling/ to the longpolling port.

Хранение статических файлов

Для удобства разработки Odoo хранит все статические файлы в своих модулях. Это не идеально с точки зрения производительности. Статические файлы обычно должны обслуживаться HTTP-сервером.

Статические файлы Odoo живут в папке static/ каждого модуля, поэтому статические файлы могут отдаваться веб-сервером путем перехвата всех запросов /MODULE/static/FILE и поиска правильного модуля (и файла) по всем путям хранения аддонов.

Безопасность

Пароль "супер-админа"

admin_passwd мимоходом упоминается в Настройка Odoo

Этот параметр используется для всех действий над базами данных (для создания, удаления, сброса или восстановления баз данных).

Если экраны управления не должны быть доступны или должны быть доступны только из выбранного набора компьютеров, используйте функции прокси-сервера для блокировки доступа ко всем адресам, начинающимся с /web/database, за исключением (возможно) /web/database/selector, который отображает экран выбора базы данных.

Если экран управления базой данных должен быть доступен, параметр admin_passwd` должен быть изменен с ``admin по умолчанию: этот пароль проверяется перед тем, как совершить операцию изменения базы данных.

Он должен храниться надежно и должен генерироваться случайным образом, например

$ python -c 'import base64, os; print(base64.b64encode(os.urandom(24)))'

этот код выведет 32-символьную псевдослучайную строку.

[1]

чтобы несколько установок Odoo использовали одну и ту же базу данных PostgreSQL или обеспечивали больше вычислительных ресурсов для обоих программ.

[2]

технически такой инструмент, как socat, может использоваться для прокси UNIX-сокетов по сетям, но это в основном для программного обеспечения, которое можно использовать только для UNIX сокетов

[3]

или быть доступным только через внутреннюю сеть с коммутацией пакетов, но для этого требуются защищенные коммутаторы, с защитой от [UNKNOWN NODE title_reference] и отключенным Wi-Fi. Даже над защищенными сетями с коммутацией пакетов рекомендуется развертывание по HTTPS, а возможные затраты снижаются, поскольку «самоподписанные» сертификаты легче развертывать в контролируемой среде, чем в Интернете.