Installing Odoo in the production phase is not very different from installing Odoo for development. While there are several possible approaches, this recipe proposes a set up that is close to the development installation explained in Chapter 1, Installing the Odoo Development Environment, in the recipe Easy installation from source, and in Chapter 2, Managing Odoo Server Instances, in the recipe Standardize your instance directory layout.
We expect that you have a development instance ready. In this recipe, we assume the following:
https://github.com/login/project.git
. This repository should contain the configuration file of the instance used during development, the specific addons of the instance, and any helper script that you may have created in the context of the project.root
access to the final server using ssh
or sudo
. If you don't, you will have to find a system administrator to assist you in the configuration.To install Odoo for production, you need to carry out the following steps:
# apt-get install git python2.7 postgresql nano python-virtualenv gcc python2.7-dev libxml2-dev libxslt1-dev libevent-dev libsasl2-dev libldap2-dev libpq-dev libpng12-dev libjpeg-dev node-less node-clean-css xfonts-75dpi xfonts-base # wget http://nightly.odoo.com/extra/wkhtmltox-0.12.1.2_linux-jessie-amd64.deb # dpkg -i wkhtmltox-0.12.1.2_linux-jessie-amd64.deb
odoo
:# adduser odoo
# sudo -u postgres createuser odoo # sudo -u postgres createdb -O odoo odoo_project
odoo
, clone the project repository:# su odoo $ mkdir ~/odoo-prod $ cd ~/odoo-prod $ git clone https://github.com/login/project.git project $ mkdir -p project/src
odoo
user, clone the Odoo source code:$ cd project/src $ git clone -b 9.0 --single-branch https://github.com/odoo/odoo.git odoo
virtualenv
and install the dependencies:$ virtualenv ~/env-odoo-9.0 $ source ~/env-odoo-9.0/bin/activate $ pip install -r odoo/requirements.txt
project/src
subdirectory:$ git clone -b 9.0 https://github.com/OCA/partner-contact.git
~/odoo-prod/project/bin
directory:$ mkdir ~/odoo-prod/project/bin
odoo-prod/project/bin/start-odoo
:#! /bin/sh PYTHON=~odoo/env-odoo-9.0/bin/python ODOO=~odoo/odoo-prod/project/src/odoo/odoo.py CONF=~odoo/odoo-prod/project/production.conf ${PYTHON} ${ODOO} -c ${CONF} "$*"
$ chmod +x ~/odoo-prod/project/bin/start-odoo
root
, uninstall gcc
:# apt-get remove gcc
Most of the recipe is identical to what is described in Chapter 1, Installing the Odoo Development Environment, but there are a few key differences.
We are using a dedicated system user with login odoo
. This enables us to control who has access to the account, for example, by configuring the sudo
or ssh
authorized keys. It also allows us to give this user as few permissions as possible, in case the instance is compromised.
The database user linked to this account does not have any privilege, not even database creation. We create the database externally, just once. In case the instance is compromised, an attacker won't be able to create additional databases on the server.
The Odoo script we are creating will be used in the recipe Set up Odoo as a system service later in this chapter. It uses the production.conf
configuration file, which is explained in the next recipe, Adapting the configuration file for production.
We uninstall gcc
at the end of the process so that if an attacker gains access, he will not be able to use this to recompile executables locally.
At the end of this recipe, your server is not ready yet. You will need to refer to the recipes Adapting the configuration file for production, Set up Odoo as a system service, and Configure a reverse proxy and SSL, which are described in this chapter.
Here are a few more important points to consider when preparing the deployment of your instance.
What should you use for a server? Pretty much any physical server these days is more than enough to handle an average sized Odoo instance with about 10 simultaneous users. Since virtual machines typically have fewer resources provisioned, you will need to pay a little more attention to this if you are planning to run on a VM. Here are a few key figures to get you started. Obviously, they will need fine tuning to match your use of Odoo.
A small Odoo instance needs at least 1 GB of RAM. Don't be shy on this; the last thing you want to happen is your server swapping. 2 to 4 GB is a good starting point. Give your server, at the very least, two CPU/cores. If you are running the PostgreSQL server on the same host, provision at least four CPU/cores, and add 1 GB of RAM for the database. The additional CPU/cores will be used by the Odoo workers that are covered in the next recipe, Adapting the configuration file for production.
The source code of your instance will eat up 1 to 2 GB of hard disk if you are keeping the Git history, which we recommend in this recipe. The file store (data_dir
in the configuration file) will grow as the instance is used, and the growth heavily depends on what you are doing in the instance. Start with 5 GB, which should give you plenty of time before getting full, and monitor the disk usage. If you are running the database on the same host, give plenty of disk space to the partition that will contain the database working files, starting at 50 GB.
You will also need space for the on-site backups, both of the database and the file store. A lot can depend on your backup plan; 200 GB is a good starting point.
Discussing PostgreSQL tuning is beyond the scope of this book. You may want to check out the books PostgreSQL 9 Admin Cookbook or PostgreSQL 9.0 High Performance, both from Packt Publishing, for an in-depth coverage of these topics.
The default configuration of PostgreSQL is generally very conservative and meant to prevent the database server from hogging all the system resources. On production servers, you can safely increase some parameters in the postgresql.conf
file to get better performance. Here are some settings you can use to get started:
max_connections = 100 shared_buffers = 256MB effective_cache_size = 768MB work_mem = 10MB maintenance_work_mem = 64MB checkpoint_segments = 16 wal_buffers = 8MB checkpoint_completion_target = 0.9
You will need to restart PostgreSQL after modifying these settings.
The pgtune
utility can help in finding a suitable configuration. You can install it by running the following:
sudo apt-get install pgtune
To get a suitable configuration, you can run the following:
$ pgtune -T OLTP -i /etc/postgresql/9.4/main/postgresql.conf -M 1073741824 -c 100
The options we use are as follows:
-T OLTP
to get a configuration for an on line translation processing database-i
to get the original configuration file -M
to specify the amount of memory for PostgreSQL (in kB); our example uses 1 GB-c
to specify the maximum number of connectionsIf your instance is heavily loaded, you will benefit from separating the database server and the Odoo server onto two different hosts. Don't use two virtual machines running on the same physical server if you are getting down to this; use two physical servers with a high speed network connection between both. In that case, you will need to ensure that the pg_hba.conf
file on the database server host allows password authenticated connections on the database from the Odoo server, and that the postgresql.conf
file lets the PostgreSQL server listen in on the network interface connecting both servers.
When cloning Odoo and the third-party dependencies, you may want to ensure that you are using the exact same revision as the one you had in developments. There are several ways to do this:
git submodule
to tie these revisions to the repository of your projectWhy not use the Linux distribution packages provided by Odoo?
You can do that and you will get started much faster because a lot of things are handled for you by the packages. However, there are a few issues with using the packaged source; most importantly, you cannot easily patch the source code of Odoo, which is easier if you run from the source. Granted, this is not something you have to do every day, but being able to use the standard development tools to achieve this, rather than manually applying and tracking patches on production servers, is a precious help and a gain of time. You may also be using the Odoo Community Association branch of Odoo, (https://github.com/OCA/OCB) for which no packages are provided.
The recipe does not cover backups. At the very least, you should have the cron task on the server running a daily backup. A simple and basic solution is to edit the crontab
file as root by running crontab -e
and to add the following lines:
@daily su postgres -c pg_dumpall | gzip > /backups/postgresql-$(date +%u).dump.gz @daily tar czf /backups/odoo-data-$(date +%u).tgz /home/odoo/odoo-prod/project/data
Don't forget to create the /backups
directory. The backup files should not be stored on the same hard disk, and ideally, they would be mirrored on a server in a different physical location. Check these backups on a regular basis; having backups that you can't restore when you need them is useless.
The proposed solution is to keeps daily backups of the last 7 days, which means you will lose one day of work in case of a problem. There are more advanced solutions available for PostgreSQL that allow point-in-time recovery. You will find more information about this in the book PostgreSQL 9 Admin Cookbook, Packt Publishing. Similarly, there are many Linux tools, such as duplicity (http://duplicity.nongnu.org/), which you can use for file backups allowing easy management.
For more information on the Odoo Community Association branch of Odoo, see the recipe Easy installation from source in Chapter 1, Installing the Odoo Development Environment.