elico-corp/odoo-docker

Simple yet powerful Odoo image for Docker based on OCB code and maintained by Elico Corporation.

elicocorp/odoo

Simple yet powerful Odoo image for Docker maintained by Elico Corporation.

Table of Contents

• Usage
  • Run the image
  • Compose example
• Security
• Data persistency
• Host user mapping
  • Default host user mapping in Docker
  • Host user mapping and volumes
  • Impact
  • Solution
• Odoo configuration file
• Additional Odoo modules
  • Automatically fetch Git repositories
  • Fetch multiple independent repositories
  • Fetch private GitHub repositories
• Run a bash script at startup
• How to extend this image
• Roadmap
• Bug Tracker
• Credits
  • Contributors
  • Maintainer

Usage^

In order to use this image, a recent version of Docker must be installed on the host. For more information about Docker Engine, see the official documentation.

Run the image^

Running this image without specifying any command will display this help message:

$ docker run elicocorp/odoo:10.0

To display the user manual, run the image with the command man. Redirecting stdout to less is highly recommended:

$ docker run elicocorp/odoo:10.0 man | less

To start Odoo, run the image with the command start:

$ docker run elicocorp/odoo:10.0 start

The easiest way to use this image is to run it along with a PostgreSQL image. By default, Odoo is configured to connect with a PostgreSQL host named db.

Note: The PostgreSQL image of Elico Corp can be used as well.

Compose example^

Below is an example of a simple docker-compose.yml to use this image. For more information about Compose, see the official documentation.

version: '3.3'
services:

  postgres:
    image: postgres:9.5
    environment:
      - POSTGRES_USER=odoo

  odoo:
    image: elicocorp/odoo:10.0
    command: start
    ports:
      - 127.0.0.1:8069:8069
    links:
      - postgres:db
    environment:
      - ODOO_DB_USER=odoo

Once this file is created, simply move to the corresponding folder and run the following command to start Odoo:

$ docker-compose up

Note 1: With this configuration, Odoo will be accessible at the following URL only from the local host: http://127.0.0.1:8069

It is possible to publish it following one of these options:

1. map a reverse-proxy to 127.0.0.1:8069
2. remove the 127.0.0.1: prefix in order to publish the port 8069 outside the local host

Note 2: With this configuration:

1. Odoo is running without master password
2. odoo PostgreSQL user is a superuser who doesn't require any password

See Security section for more info.

Note 3: With this configuration, all the data will be lost once the containers are stopped.

See Data persistency section for more info.

Security^

In order to improve the security, it is recommended to:

1. set a master password for Odoo using ODOO_ADMIN_PASSWD
2. start PostgreSQL with a different superuser (e.g. postgres)
3. give the superuser a password using POSTGRES_PASSWORD
4. create a separate PostgreSQL user for Odoo (e.g. odoo) with his own password and specify it using ODOO_DB_PASSWORD

Note: Run below SQL queries with PostgreSQL superuser to create the odoo user:

CREATE user odoo WITH password 'strong_pg_odoo_password';
ALTER user odoo WITH createdb;

The docker-compose.yml should look like:

version: '3.3'
services:

  postgres:
    image: postgres:9.5
    environment:
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=strong_pg_superuser_password

  odoo:
    image: elicocorp/odoo:10.0
    command: start
    ports:
      - 127.0.0.1:8069:8069
    links:
      - postgres:db
    environment:
      - ODOO_ADMIN_PASSWD=strong_odoo_master_password
      - ODOO_DB_USER=odoo
      - ODOO_DB_PASSWORD=strong_pg_odoo_password

Note: If Odoo is behind a reverse proxy, it is also suggested to change the port published by the container (though this port is actually not opened to the outside). For instance:

    ports:
      - 127.0.0.1:12345:8069

Data persistency^

As soon as the containers are removed, all the modifications (e.g. database, attachments, etc.) will be lost. There are 2 main volumes that must be made persistent in order to preserve the data:

1. the PostgreSQL database in /var/lib/postgresql/data
2. the Odoo filestore in /opt/odoo/data/filestore

Optionally, it is also possible to map the Odoo sessions folder in /opt/odoo/data/sessions

In the following example, these volumes are mapped under the folder volumes which is in the same folder as the docker-compose.yml. This command will create the corresponding folders:

mkdir -p ./volumes/{postgres,odoo/filestore,odoo/sessions}

The docker-compose.yml should look like:

version: '3.3'
services:

  postgres:
    image: postgres:9.5
    volumes:
      - ./volumes/postgres:/var/lib/postgresql/data
    environment:
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=strong_pg_superuser_password

  odoo:
    image: elicocorp/odoo:10.0
    command: start
    ports:
      - 127.0.0.1:8069:8069
    links:
      - postgres:db
    volumes:
      - ./volumes/odoo/filestore:/opt/odoo/data/filestore
      - ./volumes/odoo/sessions:/opt/odoo/data/sessions
    environment:
      - ODOO_ADMIN_PASSWD=strong_odoo_master_password
      - ODOO_DB_USER=odoo
      - ODOO_DB_PASSWORD=strong_pg_odoo_password

Note: With this configuration, all the data created in the volumes will belong to the user whose UID matches the user running inside the container.

See Host user mapping section for more info.

Host user mapping^

Default host user mapping in Docker^

Each Docker image defines its own users. Users only exist inside the running container.

For instance:

• in elicocorp/odoo image, the default user that will run the Odoo process is odoo with UID 1000
• in postgres image, the default user that will run the PostgreSQL process is postgres with UID 999

Whenever those users are used inside the container, Docker will actually use the corresponding user on the host running Docker. The mapping is made on the UID, not on the user name.

If the user elico with UID 1000 exists on the host, when running the Odoo image with the default user, the Odoo process executed by the odoo user inside the container will actually be executed by the host user elico.

Note: The users don't have to actually exist on the host for the container to use them. Anonymous users with the corresponding UID will be created automatically.

If the with UID 999 doesn't exist on the host, when running the PostgreSQL image with the default user, the PostgreSQL process executed by the postgres user inside the container will actually be executed by the anonymous host user with UID 999.

Host user mapping and volumes^

When the user inside the container owns files that belong to a volume, the corresponding files in the folder mapped to the volume on the host will actually belong to the corresponding user on the host.

Following the previous example:

• in the Odoo container, the files created by the odoo user in the folder /opt/odoo/data/filestore will be stored on the host in the folder ./volumes/odoo/filestore and belong to the host user elico
• in the PostgreSQL container, the files created by the postgres user in the folder /var/lib/postgresql/data will be stored on the host in the folder ./volumes/postgres and belong to the anonymous host user with UID 999

Impact^

When having root privileges on the host, the default host user mapping behavior is usually not a big issue. The main impact is that the files mapped with a volume might belong to users that don't have anything to do with the corresponding Docker services.

In the previous example:

• the host user elico will be able to read the content of the Odoo filestore
• the anonymous host user with UID 999 will be able to read the PostgreSQL database files

It is possible to avoid this by creating host users with the corresponding UIDs in order to control which host user owns the files in a volume.

However, a user with limited system privileges (e.g. no sudo) will have a bigger issue. The typical use case is a user with limited system privileges that maps a volume inside his home folder. He would expect to own all the files under his home folder, which won't be the case.

Following the previous example, if the host user seb with UID 1001 starts the image from his home folder:

• the files in ./volumes/odoo/filestore will belong to the host user elico
• the files in ./volumes/postgres will belong to the anonymous host user with UID 999

The host user seb will not be able to access those files even though they are located under his own home folder. This can lead to very annoying situations where a user would require the system administrator to help him delete files under his own home folder.

Solution^

Each Docker image has its own way to deal with host user mapping:

• for PostgreSQL, see the official documentation (section "Arbitrary --user Notes")
• for this image, use the environment variable TARGET_UID as described below

First, the host user needs to find out his UID:

$ echo $UID

Then, simply assign this UID to the environment variable TARGET_UID.

After starting the Docker containers, all the files created in the volumes will belong to the corresponding host user.

The docker-compose.yml should look like:

version: '3.3'
services:

  postgres:
    image: postgres:9.5
    volumes:
      - ./volumes/postgres:/var/lib/postgresql/data
      - /etc/passwd:/etc/passwd:ro
    environment:
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=strong_pg_superuser_password
    user: 1001:1001

  odoo:
    image: elicocorp/odoo:10.0
    command: start
    ports:
      - 127.0.0.1:8069:8069
    links:
      - postgres:db
    volumes:
      - ./volumes/odoo/filestore:/opt/odoo/data/filestore
      - ./volumes/odoo/sessions:/opt/odoo/data/sessions
    environment:
      - TARGET_UID=1001
      - ODOO_ADMIN_PASSWD=strong_odoo_master_password
      - ODOO_DB_USER=odoo
      - ODOO_DB_PASSWORD=strong_pg_odoo_password

Note: For a more dynamic UID mapping, you can use Compose variable substitution. Simply export the environment variable UID before starting the container and replace the UID with $UID in the docker-compose.yml.

Odoo configuration file^

The configuration file is generated automatically at startup. Any available Odoo parameter can be provided as an environment variable, prefixed by ODOO_.

Note: As a convention, it is preferrable to use only big caps but this is not mandatory. The parameters will be converted to small caps in the configuration file.

In the previous docker-compose.yml examples, the following Odoo parameters have already been defined:

• admin_passwd: environment variable ODOO_ADMIN_PASSWD
• db_user: environment variable ODOO_DB_USER
• db_password: environment variable ODOO_DB_PASSWORD

For a complete list of Odoo parameters, see the documentation.

It is also possible to use a custom Odoo configuration file. The most common ways are:

1. ADD the configuration file in /opt/odoo/etc/odoo.conf using a Dockerfile
2. Map the /opt/odoo/etc/odoo.conf using a volume

Additional Odoo modules^

This image allows to load additional Odoo modules through the volume /opt/odoo/additional_addons. When adding modules manually in that folder, the Odoo parameter addons_path must be defined accordingly:

addons_path = /opt/odoo/additional_addons,/opt/odoo/sources/odoo/addons

Note: The previous configuration assumes that all the modules are at the root of the folder /opt/odoo/additional_addons. Depending on the folder structure, the parameter might need to be adapted.

Automatically fetch Git repositories^

This image is able to automatically fetch (e.g. git clone) a Git repository containing a set of modules. It is based on the cross repository dependency management system introduced by the OCA.

Basically, this image is able to recursively fetch Git repositories in the /opt/odoo/additional_addons volume. Once all the repositories have been fetched, the addons_path parameter will be generated automatically.

The cross repository dependency is based on the oca_dependencies.txt syntax.

Note: This image integrates a Git repositories cache system. If some of the repositories already exist in the volume (e.g. when restarting the container), the container will pull (e.g. git pull) them instead of cloning them, which allows for much faster boot.

The easiest way to clone a Git repository is to set the environment variable ADDONS_REPO with the URL of the repository.

For instance, in order to fetch the OCA Project Git repository, as well as all the Git repositories it depends on, you can use the following docker-compose.yml:

version: '3.3'
services:

  postgres:
    image: postgres:9.5
    volumes:
      - ./volumes/postgres:/var/lib/postgresql/data
      - /etc/passwd:/etc/passwd:ro
    environment:
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=strong_pg_superuser_password
    user: 1001:1001

  odoo:
    image: elicocorp/odoo:10.0
    command: start
    ports:
      - 127.0.0.1:8069:8069
    links:
      - postgres:db
    volumes:
      - ./volumes/odoo/addons:/opt/odoo/additional_addons
      - ./volumes/odoo/filestore:/opt/odoo/data/filestore
      - ./volumes/odoo/sessions:/opt/odoo/data/sessions
    environment:
      - ADDONS_REPO=https://github.com/OCA/project.git
      - TARGET_UID=1001
      - ODOO_ADMIN_PASSWD=strong_odoo_master_password
      - ODOO_DB_USER=odoo
      - ODOO_DB_PASSWORD=strong_pg_odoo_password

Note: After the repositories have been fetched, it might not be required to pull them every time the container is restarted. In that case, simply set the environment variable FETCH_OCA_DEPENDENCIES to False (default value is True) in order to boot much faster, e.g.:

environment:
  - FETCH_OCA_DEPENDENCIES=False

Fetch multiple independent repositories^

It might be necessary to fetch more than one Git repository (and the repositories it depends on). In that case, instead of using the ADDONS_REPO environment variable, simply create one oca_dependencies.txt file and put it at the root of the /opt/odoo/additional_addons volume.

For instance, if you want to fetch the OCA account payment modules repository along with the OCA project repository, put the following oca_dependencies.txt in the /opt/odoo/additional_addons volume:

# list the OCA project dependencies, one per line
# add a github url if you need a forked version
project https://github.com/OCA/project.git
account-payment https://github.com/OCA/account-payment.git

Fetch private GitHub repositories^

This image is able to pull multiple private GitHub repositories when provided a valid SSH key that has read access to these repositories. The URL for GitHub SSH authentication is available under the "Clone with SSH" option.

Simply put the SSH private key whose name must be id_rsa in the volume /opt/odoo/ssh. Since Odoo doesn't need to write in that volume, you can use the ro option to mount a read-only volume.

The docker-compose.yml should look like:

version: '3.3'
services:

  postgres:
    image: postgres:9.5
    volumes:
      - ./volumes/postgres:/var/lib/postgresql/data
      - /etc/passwd:/etc/passwd:ro
    environment:
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=strong_pg_superuser_password
    user: 1001:1001

  odoo:
    image: elicocorp/odoo:10.0
    command: start
    ports:
      - 127.0.0.1:8069:8069
    links:
      - postgres:db
    volumes:
      - ./volumes/odoo/addons:/opt/odoo/additional_addons
      - ./volumes/odoo/filestore:/opt/odoo/data/filestore
      - ./volumes/odoo/sessions:/opt/odoo/data/sessions
      - ./volumes/odoo/ssh:/opt/odoo/ssh:ro
    environment:
      - [email protected]:Elico-Corp/odoo-private-addons.git
      - TARGET_UID=1001
      - ODOO_ADMIN_PASSWD=strong_odoo_master_password
      - ODOO_DB_USER=odoo
      - ODOO_DB_PASSWORD=strong_pg_odoo_password

Note: If the host user has a valid SSH key under the .ssh folder of his home folder, he can map his .ssh folder instead, e.g.:

volumes:
  - ~/.ssh:/opt/odoo/ssh:ro

Run a bash script at startup^

In some cases, it might be useful to run some commands in the container before starting Odoo. After the Odoo target user has been created, the container will execute a bash script with the container user root.

The script is located at /opt/scripts/startup.sh and can be mapped with a volume or added via a Dockerfile.

How to extend this image^

This image comes with all the dependencies required to run the standard version of Odoo. However, some additionnal modules might require an extra setup.

While the startup script is a way to achieve this, the changes it operates in the OS of the container are not persistent. Such setup would be performed every time the container is restarted, which could induce long delay in the boot process.

In order to make those changes persistent, simply create a child Docker image by extending this image.

The below example shows how to install the dependencies captcha and simplecrypt for the Odoo v8 module website_captcha_nogoogle.

This is how the Dockerfile would look like:

FROM elicocorp/odoo:8.0
MAINTAINER Elico Corp <[email protected]>
RUN pip install --upgrade cffi
RUN pip install captcha simple-crypt recaptcha-client
RUN pip install --upgrade pillow

Save it as ./build/odoo/Dockerfile. Then, in docker-compose.yml, replace the image instruction with a build instruction, e.g.:

odoo:
  build: ./build/odoo

When starting the container with docker-compose up, Docker will first build the image. In order to re-build the odoo image, use:

$ docker-compose build odoo

Note: Extend an image is an extremely versatile feature of Docker. The only limit is your imagination! For instance, check out the Elico Corp Odoo Docker image localized for China.

Roadmap^

• Use the code of maintainer-quality-tools to pull the oca_dependencies.txt

Bug Tracker^

Bugs are tracked on GitHub Issues. In case of trouble, please check there if your issue has already been reported. If you spotted it first, help us smash it by providing detailed and welcomed feedback.

Credits^

Contributors^

• Sebastien Maillard [email protected]
• Eric Caudal [email protected]
• Noah Wang [email protected]
• Augustin Cisterne-Kaas [email protected]

Maintainer^

This project is maintained by Elico Corporation.

Elico Corp is an innovative actor in China, Hong-Kong and Singapore servicing well known international companies and as well as local mid-sized businesses. Since 2010, our seasoned Sino-European consultants have been providing full range Odoo services:

• Business consultancy for Gap analysis, BPM, operational work-flows review.
• Ready-to-use ERP packages aimed at starting businesses.
• Odoo implementation for manufacturing, international trading, service industry and e-commerce.
• Connectors and integration with 3rd party software (Magento, Taobao, Coswin, Joomla, Prestashop, Tradevine etc...).
• Odoo Support services such as developments, training, maintenance and hosting.

Our headquarters are located in Shanghai with branch in Singapore servicing customers from all over Asia Pacific.

Contact information: Sales [email protected]

odoo-docker's Issues

When a repository fails to pull the docker cannot start

One has to manually delete the directory in the extra addons directory and restart the docker.

Expected behavior: if a repo cannot be pulled (because the directory is corrupted for example), the directory should be mv for archiving or deleted

cc @seb-elico

ODOO_ADDONS_PATH is wrongly parsed in odoo 14

Version 14 of the docker container parses the ODOO_ADDONS_PATH variable wrong and delivers a non functional odoo.
Steps to reproduce:

1. Create docker container.
2. Download addittional addons to the container.
3. use ODOO_ADDONS_PATH enviroment variable in commandline or docker-compose.
4. start the container.

The addons path get parsed like this:

odoo: addons paths: ['/opt/odoo/sources/odoo/odoo/addons', '/opt/odoo/data/addons/14.0', '/home/target-odoo-user/\/opt\/odoo\/sources\/odoo\/addons\', '/home/target-odoo-user/\/opt\/odoo\/additional_addons\/web

It gets an extra \ for every /. Odoo 12 container works fine.

`oca_dependencies.txt` ignored if `FETCH_OCA_DEPENDENCIES=False`

When cloning multiple independent GH repos (see https://github.com/Elico-Corp/odoo-docker#fetch_multiple_repos), in case ENV var FETCH_OCA_DEPENDENCIES=False is used, the addons path will be the Odoo default one (i.e. it doesn't include the repos listed in oca_dependencies.txt as well as their child repos).

To be noted that if there's only 1 master repo cloned (i.e. using ENV var ADDONS_REPO), there's no such bug.

Randomly cloning default branch instead of inherited branch from parent repo

By default, if no branch is specified for a repo in oca_dependencies.txt, the branch of the parent repo should be used (or the default branch of the repo if there's no parent repo).

For instance, when cloning account-financial-reporting 10.0, the following repos will be cloned:

• account-financial-reporting 10.0
• account-financial-tools 10.0
• connector 10.0
• queue 10.0
• reporting-engine 10.0
• server-tools 10.0
• web 10.0

However, it can happen that the default branch of a child repo would be cloned, for instance reporting-engine 11.0.

It seems like the root cause was a network issue during cloning, which has triggered a "retry" of the clone. Below is the log of when that happenned for reference:

Cloning: account-financial-reporting 10.0
Cloning into '/opt/odoo/additional_addons/account-financial-reporting'...
Cloning: account-financial-tools
Cloning into '/opt/odoo/additional_addons/account-financial-tools'...
Cloning: reporting-engine
Cloning into '/opt/odoo/additional_addons/reporting-engine'...
error: RPC failed; curl 56 GnuTLS recv error (-9): A TLS packet with unexpected length was received.
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed
Cloning: reporting-engine
Cloning into '/opt/odoo/additional_addons/reporting-engine'...
Cloning: connector
Cloning into '/opt/odoo/additional_addons/connector'...
error: RPC failed; curl 56 GnuTLS recv error (-9): A TLS packet with unexpected length was received.
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed
Cloning: connector
Cloning into '/opt/odoo/additional_addons/connector'...
Cloning: queue
Cloning into '/opt/odoo/additional_addons/queue'...
Cloning: server-tools
Cloning into '/opt/odoo/additional_addons/server-tools'...
Cloning: web
Cloning into '/opt/odoo/additional_addons/web'...

Odoo 8 - Oca Add-on added in container but not shown in odoo

Hi,

I did start and odoo 8 using your example docker-compose but if I add server-tools in oca-dependencies.txt, I saw the git clone while starting the docker, if I go in (docker exec bash) I can saw all the directory under /opt/odoo/additional_addons/server-tools

I also saw "openerp: addons paths: ['/opt/odoo/data/addons/8.0', u'/opt/odoo/additional_addons/server-tools', u'/opt/odoo/sources/odoo/addons', '/opt/odoo/sources/odoo/openerp/addons']" but if I go in the module menu to install, even if I update the module list, I can not find any of those OCA modules.

btw: I am admin and I have enable technical feature...

Any help is welcome

docker-compose部署后无法直接访问

使用docker-compose部署后，访问出现一下内部服务器错误，错误日志：

odoo_1_d98fc96cac19 | 2018-11-15 06:30:19,712 63 INFO ? odoo.http: HTTP Configuring static files
odoo_1_d98fc96cac19 | 2018-11-15 06:30:19,748 63 ERROR odoo odoo.modules.loading: Database odoo not initialized, you can force it with -i base
odoo_1_d98fc96cac19 | 2018-11-15 06:30:19,752 63 INFO odoo werkzeug: 172.20.0.1 - - [15/Nov/2018 06:30:19] "GET / HTTP/1.1" 500 - 10 0.011 0.022
odoo_1_d98fc96cac19 | 2018-11-15 06:30:19,756 63 ERROR odoo werkzeug: Error on request:
odoo_1_d98fc96cac19 | Traceback (most recent call last):
odoo_1_d98fc96cac19 | File "/usr/local/lib/python3.5/dist-packages/werkzeug/serving.py", line 205, in run_wsgi
odoo_1_d98fc96cac19 | execute(self.server.app)
odoo_1_d98fc96cac19 | File "/usr/local/lib/python3.5/dist-packages/werkzeug/serving.py", line 193, in execute
odoo_1_d98fc96cac19 | application_iter = app(environ, start_response)
odoo_1_d98fc96cac19 | File "/opt/odoo/sources/odoo/odoo/service/server.py", line 350, in app
odoo_1_d98fc96cac19 | return self.app(e, s)
odoo_1_d98fc96cac19 | File "/opt/odoo/sources/odoo/odoo/service/wsgi_server.py", line 128, in application
odoo_1_d98fc96cac19 | return application_unproxied(environ, start_response)
odoo_1_d98fc96cac19 | File "/opt/odoo/sources/odoo/odoo/service/wsgi_server.py", line 117, in application_unproxied
odoo_1_d98fc96cac19 | result = odoo.http.root(environ, start_response)
odoo_1_d98fc96cac19 | File "/opt/odoo/sources/odoo/odoo/http.py", line 1317, in call
odoo_1_d98fc96cac19 | return self.dispatch(environ, start_response)
odoo_1_d98fc96cac19 | File "/opt/odoo/sources/odoo/odoo/http.py", line 1290, in call
odoo_1_d98fc96cac19 | return self.app(environ, start_wrapped)
odoo_1_d98fc96cac19 | File "/usr/local/lib/python3.5/dist-packages/werkzeug/wsgi.py", line 599, in call
odoo_1_d98fc96cac19 | return self.app(environ, start_response)
odoo_1_d98fc96cac19 | File "/opt/odoo/sources/odoo/odoo/http.py", line 1470, in dispatch
odoo_1_d98fc96cac19 | ir_http = request.registry['ir.http']
odoo_1_d98fc96cac19 | File "/opt/odoo/sources/odoo/odoo/modules/registry.py", line 176, in getitem
odoo_1_d98fc96cac19 | return self.models[model_name]
odoo_1_d98fc96cac19 | KeyError: 'ir.http' - - -

用官方的docker-compose demo直接运行后出现错误

version: '3.3'
services:

postgres:
image: postgres:9.5
environment:
- POSTGRES_USER=postgres
- POSTGRES_PASSWORD=strong_pg_superuser_password

odoo:
image: elicocorp/odoo:10.0
command: start
ports:
- 127.0.0.1:8069:8069
links:
- postgres:db
environment:
- ODOO_ADMIN_PASSWD=strong_odoo_master_password
- ODOO_DB_USER=odoo
- ODOO_DB_PASSWORD=strong_pg_odoo_password
用这个直接运行出现下面错误， 应该好似没有添加 odoo用户和role的缘故，应该要写在 compose配置文件里面比较合理吧

odoo_1 | 2019-03-16 15:15:25,889 54 INFO ? odoo.sql_db: Connection to the database failed
odoo_1 | 2019-03-16 15:15:25,891 54 INFO ? werkzeug: 172.23.0.1 - - [16/Mar/2019 15:15:25] "GET / HTTP/1.1" 500 -
odoo_1 | 2019-03-16 15:15:25,900 54 ERROR ? werkzeug: Error on request:
odoo_1 | Traceback (most recent call last):
odoo_1 | File "/usr/local/lib/python3.5/dist-packages/werkzeug/serving.py", line 205, in run_wsgi
odoo_1 | execute(self.server.app)
odoo_1 | File "/usr/local/lib/python3.5/dist-packages/werkzeug/serving.py", line 193, in execute
odoo_1 | application_iter = app(environ, start_response)
odoo_1 | File "/opt/odoo/sources/odoo/odoo/service/server.py", line 260, in app
odoo_1 | return self.app(e, s)
odoo_1 | File "/opt/odoo/sources/odoo/odoo/service/wsgi_server.py", line 166, in application
odoo_1 | return application_unproxied(environ, start_response)
odoo_1 | File "/opt/odoo/sources/odoo/odoo/service/wsgi_server.py", line 154, in application_unproxied
odoo_1 | result = handler(environ, start_response)
odoo_1 | File "/opt/odoo/sources/odoo/odoo/http.py", line 1319, in call
odoo_1 | return self.dispatch(environ, start_response)
odoo_1 | File "/opt/odoo/sources/odoo/odoo/http.py", line 1293, in call
odoo_1 | return self.app(environ, start_wrapped)
odoo_1 | File "/usr/local/lib/python3.5/dist-packages/werkzeug/wsgi.py", line 599, in call
odoo_1 | return self.app(environ, start_response)
odoo_1 | File "/opt/odoo/sources/odoo/odoo/http.py", line 1456, in dispatch
odoo_1 | self.setup_db(httprequest)
odoo_1 | File "/opt/odoo/sources/odoo/odoo/http.py", line 1388, in setup_db
odoo_1 | httprequest.session.db = db_monodb(httprequest)
odoo_1 | File "/opt/odoo/sources/odoo/odoo/http.py", line 1540, in db_monodb
odoo_1 | dbs = db_list(True, httprequest)
odoo_1 | File "/opt/odoo/sources/odoo/odoo/http.py", line 1507, in db_list
odoo_1 | dbs = odoo.service.db.list_dbs(force)
odoo_1 | File "/opt/odoo/sources/odoo/odoo/service/db.py", line 369, in list_dbs
odoo_1 | with closing(db.cursor()) as cr:
odoo_1 | File "/opt/odoo/sources/odoo/odoo/sql_db.py", line 637, in cursor
odoo_1 | return Cursor(self.__pool, self.dbname, self.dsn, serialized=serialized)
odoo_1 | File "/opt/odoo/sources/odoo/odoo/sql_db.py", line 178, in init
odoo_1 | self._cnx = pool.borrow(dsn)
odoo_1 | File "/opt/odoo/sources/odoo/odoo/sql_db.py", line 520, in _locked
odoo_1 | return fun(self, *args, **kwargs)
odoo_1 | File "/opt/odoo/sources/odoo/odoo/sql_db.py", line 588, in borrow
odoo_1 | **connection_info)
odoo_1 | File "/usr/local/lib/python3.5/dist-packages/psycopg2/init.py", line 130, in connect
odoo_1 | conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
odoo_1 | psycopg2.OperationalError: FATAL: role "odoo" does not exist

add docker-compose & many workers remark to readme

Hey Sébastien (ça me semble français),

I'm currently investigating how I can install in the most reproducable way a fast responding odoo on a small server (2 cores, 4GB, SSD) for an NGO with few money. As migration from 8.0 to 9.0 is a complicated thing, I thougt about going with 9.0 and also tried your template.

It woud be cool if you could include an example docker-compose.yml in the readme.
I would be interested as well if your image supports settings with workers > 0. The official docker odoo/odoo:9.0 is missing some dependencies odoo/docker#42 .

This is my take on a docker-compose.yml:

db:
  container_name: odoo-db-server
  environment:
    POSTGRES_USER: odoo
    POSTGRES_PASSWORD: odoo
  image: postgres:9.4
  volumes_from:
    - db-data

# PostgreSQL data files
db-data:
  container_name: odoo-db-data
  image: postgres:9.4
  command: "true"

# Odoo server
app:
  container_name: odoo-app-server
  ports:
    - 0.0.0.0:80:8069/tcp
  restart: always
  image: elicocorp/odoo:9.0
  links:
    - db:db
#  volumes:
#     - ./etc:/opt/odoo/etc
#     - ./addons:/opt/odoo/additional_addons:ro
#  volumes_from:
#    - app-data

# app-data:
#   container_name: odoo-app-data
#   image: elicocorp/odoo:9.0
#   command: "true"

When restart docker, the container fails to restart cleanly

Following message:
Mar 20 14:06:41 elico-1DSG docker/demo_o-e10_1[1804]: mkdir: cannot create directory '/opt/odoo/.ssh': File exists
Mar 20 14:06:41 elico-1DSG docker/demo_o-e10_1[1804]: cp: cannot create regular file '/opt/odoo/.ssh/id_rsa': Permission denied

Expected: possibility to restart the container without removing it.
cc @seb-elico