コンテナ¶

概要¶

各ビルドは、独自のコンテナ(Linux ネームスペースコンテナ)内に分離されています。

基盤はUbuntuシステムであり、Odooに必要な依存関係、および一般的な有用な梱包が全てインストールされています。

プロジェクトで追加のPython依存関係やより新しいリリースが必要な場合は、それらを列挙した requirements.txt をブランチのルートに定義できます。プラットフォームがこれらの依存関係をコンテナにインストールします。pip要件の規定者 <https://pip.pypa.io/en/stable/reference/pip_install/#requirement-specifiers>`_ のドキュメントは、requirements.txt ファイルの記述に役立ちます。具体的な例として、requirements.txt file of Odoo を確認して下さい。

サブモジュールの requirements.txt ファイルも同様に考慮されます。プラットフォームは、Odooモジュールを含む各フォルダで requirements.txt ファイルを探します。モジュールフォルダ自体ではなく、その親フォルダで探します。

ディレクトリ構成¶

コンテナはUbuntuベースのため、ディレクトリ構造はLinuxファイルシステム階層標準に従っています。Ubuntuファイルシステムツリー概要 <https://help.ubuntu.com/community/LinuxFilesystemTreeOverview#Main_directories> では、主なディレクトリについて説明しています。

以下は、Odoo.shに関連するディレクトリです:

.
├── home
│    └── odoo
│         ├── src
│         │    ├── odoo                Odoo Community source code
│         │    │    └── odoo-bin       Odoo server executable
│         │    ├── enterprise          Odoo Enterprise source code
│         │    ├── themes              Odoo Themes source code
│         │    └── user                Your repository branch source code
│         ├── data
│         │    ├── filestore           database attachments, as well as the files of binary fields
│         │    └── sessions            visitors and users sessions
│         └── logs
│              ├── install.log         Database installation logs
│              ├── odoo.log            Running server logs
│              ├── update.log          Database updates logs
│              └── pip.log             Python packages installation logs
└── usr
     ├── lib
     │    ├── python2.7
     │         └── dist-packages       Python 2.7 standard libraries
     │    ├── python3
     │         └── dist-packages       Python 3 standard libraries
     │    └── python3.5
     │         └── dist-packages       Python 3.5 standard libraries
     ├── local
     │    └── lib
     │         ├── python2.7
     │         │    └── dist-packages  Python 2.7 third-party libraries
     │         └── python3.5
     │              └── dist-packages  Python 3.5 third-party libraries
     └── usr
          └── bin
               ├── python2.7           Python 2.7 executable
               └── python3.5           Python 3.5 executable

Python 2.7と3.5の両方がコンテナにインストールされています。ただし、

プロジェクトが Odoo 10.0 を使用するように設定されている場合、Odoo サーバは Python 2.7 で実行されます。
プロジェクトが Odoo 11.0 以上を使用するように設定されている場合、Odoo サーバは Python 3.5 で実行されます。

データベースシェル¶

シェルでコンテナにアクセスしている間、psql を使用してデータベースにアクセスできます。

odoo@odoo-addons-master-1.odoo.sh:~$ psql
psql (9.5.2, server 9.5.11)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.

odoo-addons-master-1=>

注意して下さい ! 変更につながるすべての *sql* ステートメント (*UPDATE*, *DELETE*, *ALTER*, ...) に対して、特に本番データベースに対しては、`トランザクション (BEGIN...COMMIT/ROLLBACK) を使用してください。

取引メカニズムは、ミスが発生した場合の安全策となります。変更をロールバックするだけで、データベースを以前の状態に戻すことができます。

例えば、WHERE 条件の設定を忘れてしまうことがあります。

odoo-addons-master-1=> BEGIN;
BEGIN
odoo-addons-master-1=> UPDATE res_users SET password = '***';
UPDATE 457
odoo-addons-master-1=> ROLLBACK;
ROLLBACK

このような場合、誤って行った不要な変更を元に戻すためにロールバックし、ステートメントを書き直すことができます。

odoo-addons-master-1=> BEGIN;
BEGIN
odoo-addons-master-1=> UPDATE res_users SET password = '***' WHERE id = 1;
UPDATE 1
odoo-addons-master-1=> COMMIT;
COMMIT

ただし、トランザクションを実行した後は、コミットまたはロールバックすることを忘れないで下さい。オープンなトランザクションは、テーブル内のレコードをロックし、実行中のデータベースがそれらのリリースを待つ場合があります。これにより、サーバが永久にハングする可能性があります。

さらに、可能であれば、まずステージングデータベースを使用してステートメントをテストして下さい。これにより、安全性がさらに高まります。

Odooサーバを実行する¶

コンテナシェルから Odoo サーバインスタンスを起動することができます。外部からブラウザでアクセスすることはできませんが、例えば次のようにすることができます:

Odooシェルを使用

$  odoo-bin shell
>>> partner = env['res.partner'].search([('email', '=', 'asusteK@yourcompany.example.com')], limit=1)
>>> partner.name
'ASUSTeK'
>>> partner.name = 'Odoo'
>>> env['res.partner'].search([('email', '=', 'asusteK@yourcompany.example.com')], limit=1).name
'Odoo'

モジュールをインストールする、

$  odoo-bin -i sale --without-demo=all --stop-after-init

モジュールをアップデートする、

$  odoo-bin -u sale --stop-after-init

モジュールのテストを実行する、

$  odoo-bin -i sale --test-enable --log-level=test --stop-after-init

上記のコマンドでは、引数は:

--without-demo=all 全てのモジュールでデモデータの読み込みを防止します。
--stop-after-init は依頼したオペレーションが完了すると、直ちにサーバインスタンスをシャットダウンします。

さらに多くのオプションが利用可能で、CLI ドキュメントに詳細が記載されています。

Odoo.shがサーバを実行する際に使用したアドオンのパスは、ログ (~/logs/odoo.log) から確認できます。"odoo: addons paths" を探します:

2018-02-19 10:51:39,267 4 INFO ? odoo: Odoo version 18.0
2018-02-19 10:51:39,268 4 INFO ? odoo: Using configuration file at /home/odoo/.config/odoo/odoo.conf
2018-02-19 10:51:39,268 4 INFO ? odoo: addons paths: ['/home/odoo/data/addons/18.0', '/home/odoo/src/user', '/home/odoo/src/enterprise', '/home/odoo/src/themes', '/home/odoo/src/odoo/addons', '/home/odoo/src/odoo/odoo/addons']

特にプロダクトデータベースには注意して下さい。このOdooサーバインスタンスを実行するオペレーションは分離されていません。変更はデータベースに反映されます。テストは常にステージングデータベースで行って下さい。

Odoo.shでのデバッグ¶

Odoo.shのビルドのデバッグは、他のPythonアプリとそれほど変わりません。この記事では、Odoo.shプラットフォームの特性と制限についてのみ説明し、デバッガーの使用方法についてはすでに理解していることを前提としています。

注釈

Pythonアプリケーションのデバッグ方法がまだわからない場合は、インターネット上で簡単に検索できる入門コースがいくつか提供されています。

Odoo.sh上でコードをデバッグするには、pdb, pudb または ipdb を使用できます。サーバはシェル外で実行されるため、デバッガがオペレーションにシェルを必要とするため、Odooインスタンスのバックエンドから直接デバッガを起動することはできません。

pdb がデフォルトで全てのコンテナにインストールされています。
pudb または ipdb を使用したい場合は、事前にインストールしておく必要があります。

それを行うには、以下の2つの方法があります:
- 一時的(現在のビルドのみ):
  $ pip install pudb --user
  又は
  $ pip install ipdb --user
- 恒久的: プロジェクト``requirements.txt`` ファイルに pudb または ipdb を追加。

次に、デバッガをトリガしたいコードを編集し、以下を追加します。

import sys
if sys.__stdin__.isatty():
    import pdb; pdb.set_trace()

条件 sys.__stdin__.isatty() は、シェルから Odoo を実行しているかどうかを検出するハックです。

ファイルを保存し、Odooシェルを実行します:

$ odoo-bin shell

最後に、Odooシェルを経由して、デバッグしたいコード/関数/メソッドのトリガを起動することができます。

Odoo.shシェルで ``pdb`` が実行されている様子を示すコンソール画面のスクリーンショット。

Edit on GitHub