[Phần 2] Hướng dẫn config cơ bản trên Odoo

Trong [Phần 1] Hướng dẫn cài đặt Odoo trên môi trường Docker, mình đã hướng dẫn cách cài đặt Odoo và chạy trên môi trường Docker, vậy khi muốn config sâu hơn làm như thế nào?

Hôm nay hãy cùng mình bắt đầu tìm hiểu về chủ đề này nhé!!!

Giới thiệu tổng quan

File config của Odoo có tác dụng gì??

Trong Odoo, file cấu hình (config file) có vai trò rất quan trọng trong việc tùy chỉnh hệ thống Odoo cho phù hợp với môi trường và yêu cầu cụ thể của doanh nghiệp. Một số tác dụng chính của file cấu hình trong Odoo bao gồm:

1. Cấu hình kết nối cơ sở dữ liệu: File cấu hình cho phép bạn xác định thông tin kết nối đến cơ sở dữ liệu mà Odoo sẽ sử dụng, bao gồm loại cơ sở dữ liệu, tên máy chủ, tên cơ sở dữ liệu, tài khoản đăng nhập, và mật khẩu.
2. Cấu hình địa chỉ và cổng: Bạn có thể thiết lập địa chỉ IP và cổng mà Odoo sẽ lắng nghe các yêu cầu từ trình duyệt web hoặc các ứng dụng khác.
3. Cấu hình bộ nhớ và tài nguyên: File cấu hình cho phép bạn điều chỉnh số lượng bộ nhớ, số lượng tiến trình worker, và các tài nguyên khác mà Odoo sẽ sử dụng, giúp tối ưu hóa hiệu suất hệ thống.
4. Cấu hình module và ứng dụng: Bạn có thể kích hoạt hoặc vô hiệu hóa các module và ứng dụng nhất định trong Odoo thông qua file cấu hình, điều này giúp tùy chỉnh hệ thống phù hợp với nhu cầu của doanh nghiệp.
5. Cấu hình bảo mật: File cấu hình cho phép bạn thiết lập các chính sách bảo mật, như mật khẩu quản trị, giới hạn quyền truy cập, và các cài đặt an toàn khác.
6. Cấu hình ghi nhật ký: Bạn có thể điều chỉnh mức độ ghi nhật ký (logging level) và vị trí lưu trữ file nhật ký trong file cấu hình, giúp theo dõi và gỡ rối các sự cố một cách dễ dàng hơn. Tóm lại, file cấu hình trong Odoo đóng vai trò quan trọng trong việc tùy chỉnh và định cấu hình hệ thống Odoo để phù hợp với môi trường và nhu cầu của doanh nghiệp, giúp đảm bảo hiệu suất, bảo mật, và tính linh hoạt của hệ thống.

Cấu hình file config

PostgreSQL

admin_passwd = mysupersecretpassword
db_host = <host_db>
db_port = <port_db>
db_user = <user_db>
db_password = <pw_db>
dbfilter = ^mycompany.*$
db_sslmode = <‘disable’, ‘allow’, ‘prefer’, ‘require’, ‘verify-ca’ hoặc ‘verify-full’>
db_maxconn = <số_lượng_connect>

Trong đó,

• admin_passwd = mysupersecretpassword: Đây là mật khẩu cho tài khoản quản trị của Odoo. Bạn nên thay đổi giá trị này bằng một mật khẩu mạnh và bảo mật.
• db_host = <host db>: Đây là địa chỉ máy chủ (host) của cơ sở dữ liệu PostgreSQL. Bạn cần thay <host db> bằng địa chỉ IP hoặc tên miền của máy chủ PostgreSQL.
• db_port = <port db>: Đây là cổng (port) mà máy chủ PostgreSQL đang lắng nghe. Thông thường, cổng mặc định của PostgreSQL là 5432. Bạn cần thay <port db> bằng cổng thực tế.
• db_user = <user db>: Đây là tên người dùng (user) có quyền truy cập vào cơ sở dữ liệu PostgreSQL. Bạn cần thay <user db> bằng tên người dùng thực tế.
• db_password = <pw db>: Đây là mật khẩu cho người dùng truy cập cơ sở dữ liệu PostgreSQL. Bạn cần thay <pw db> bằng mật khẩu thực tế.
• db_maxconn: Chỉ định số lượng kết nối vật lý tối đa đến PostgreSQL.
• dbfilter = ^mycompany.*$: Đây là một biểu thức chính quy (regular expression) để lọc các cơ sở dữ liệu mà Odoo có thể truy cập. Trong trường hợp này, biểu thức chính quy sẽ cho phép Odoo truy cập vào bất kỳ cơ sở dữ liệu nào có tên bắt đầu bằng "mycompany". Bạn có thể điều chỉnh biểu thức này theo yêu cầu của mình.
• Tham số db_sslmode trong file cấu hình của Odoo được sử dụng để xác định chế độ kết nối an toàn SSL/TLS giữa Odoo và máy chủ cơ sở dữ liệu PostgreSQL. Nó có thể nhận một trong các giá trị sau:
  1. 'disable': Không sử dụng kết nối an toàn SSL/TLS.
  2. 'allow': Kết nối sẽ cố gắng thiết lập kết nối an toàn SSL/TLS nếu máy chủ PostgreSQL hỗ trợ. Nếu không được, kết nối sẽ tiếp tục mà không sử dụng SSL/TLS.
  3. 'prefer': Ưu tiên kết nối an toàn SSL/TLS nếu máy chủ PostgreSQL hỗ trợ. Nếu không được, kết nối sẽ tiếp tục mà không sử dụng SSL/TLS.
  4. 'require': Luôn yêu cầu kết nối an toàn SSL/TLS. Nếu máy chủ PostgreSQL không hỗ trợ SSL/TLS, kết nối sẽ không thành công.
  5. 'verify-ca': Luôn yêu cầu kết nối an toàn SSL/TLS và xác minh chứng chỉ máy chủ được cấp bởi một Tổ chức cấp chứng chỉ đáng tin cậy.
  6. 'verify-full': Luôn yêu cầu kết nối an toàn SSL/TLS, xác minh chứng chỉ máy chủ được cấp bởi một Tổ chức cấp chứng chỉ đáng tin cậy và kiểm tra tên miền máy chủ. Lưu ý rằng bạn cần thay thế các giá trị <host db>, <port db>, <user db>, và <pw db> bằng thông tin thực tế của cơ sở dữ liệu PostgreSQL mà bạn muốn Odoo kết nối đến. Ngoài ra, bạn cũng nên đảm bảo rằng người dùng được cấu hình có đủ quyền truy cập vào cơ sở dữ liệu để Odoo có thể hoạt động đúng cách.

Lưu trữ filestore

Các file trên Odoo sẽ được lưu trữ dưới dạng tên đã được hash và lưu dạng binary. Mặc định, nó sẽ được lưu trữ bên trong container, do đó, nếu bạn khởi tạo lại một container mới, đồng nghĩa các dữ liệu cũ sẽ không thể được đọc, và thường xảy ra lỗi về css, js,... hoặc có thể gặp vấn đề trắng trang vì không tải được các file cần thiết.

Cấu trúc lưu trữ của Odoo:

data_dir = <nơi_lưu_trữ_file> | db

Bạn có thể định nghĩa một đường dẫn cụ thể đễ lưu trữ file, ví dụ: data_dir = /var/lib/odoo, lúc này, Odoo sẽ lưu các file binary tại đường dẫn /var/lib/odoo, trong trường hợp bạn muốn lưu trữ cả file binary vào database thì cần đặt thành data_dir = db, khi đó, Odoo sẽ tự define thêm các fields cần thiết và lưu trữ file binary vào database. Ở bài viết tiếp theo, mình sẽ hướng dẫn cách để lưu trữ file trên AWS S3.

Lưu ý: Trong trường hợp bạn gặp lỗi CSS, JS,... chúng ta cần phải re-generate (tạo lại) các thông tin assets cần thiết cho Odoo. Ở giao diện debug (<url>?debug=assets), bạn có thể sử dụng chức năng Regenerate assets bundles để Odoo có thể tạo lại các assets.

Dĩ nhiên, có thể bạn không thể truy cập được vào trang Dashboard này, khi đó chúng ta có thể thực hiện lệnh tạo lại bằng cách sử dụng database:

DELETE FROM ir_attachment WHERE res_model='ir.ui.view' and name LIKE '%assets_%';

Khi thực hiện lệnh trên, các file assets đã bị xoá, và Odoo sẽ tự hiểu và tự generate lại và chúng ta có thể truy cập lại một cách bình thường.

Để khắc phục vấn đề này, chúng ta có thể sử dụng Docker named volume, thông tin các file này sẽ được lưu trữ lại dưới volume của Docker. Tuy nhiên, khi bạn thực thi ở một máy khác thì các file này lại không tồn tại. Vì thế, odoo cho phép chúng ta có thể config được nơi lưu trữ các file cần thiết này.

Máy chủ

Odoo bao gồm các máy chủ HTTP, cron và trò chuyện trực tiếp (live-chat) tích hợp sẵn, sử dụng hoặc đa luồng hoặc đa xử lý.

Đa luồng(multi-thread) là một dạng xử lý đơn giản, chủ yếu sử dụng cho môi trường develop và tương thích với các hệ điều hành khác nhau (bao gồm cả Windows). Một luồng mới sẽ được tạo ra cho mỗi HTTP request mới, ngay cả cho các kết nối như websocket. Thêm các luồng cron daemon cũng sẽ được tạo ra. Do giới hạn của Python (GIL), nó không sử dụng tối đa hiệu suất của phần cứng.

Máy chủ đa luồng sẽ được chọn mặc định sử dụng, cũng áp dụng cho các container docker. Nó được chọn bằng cách không đặt tùy chọn --workers hoặc đặt nó bằng 0.

Đa xử lý(multi-processing) là một máy chủ đầy đủ, chủ yếu được sử dụng cho môi trường production. Nó không bị giới hạn bởi Python (GIL) về sử dụng tài nguyên và do đó nó có thể sử dụng tối đa hiệu suất của phần cứng. Một nhóm worker sẽ được tạo ra khi khởi động máy chủ. Các HTTP request mới sẽ vào hàng đợi của hệ điều hành và chờ cho đến khi có worker sẵn sàng để xử lý chúng. Các worker cron bổ sung cũng sẽ được tạo ra. Một tiến trình giám sát tài nguyên có thể tùy chỉnh sẽ giám sát việc sử dụng tài nguyên và có thể dừng/khởi động lại các worker bị lỗi.

Bạn có thể đặt option để sử dụng multi-processing. Nó được chọn bằng cách đặt tùy chọn --workers thành một số nguyên dương.

Lưu ý: Do được tùy chỉnh đặc biệt cho máy chủ Linux, máy chủ đa xử lý không khả dụng trên Windows.

Tính toán số lượng worker

• Quy tắc thực tế: (#CPU * 2) + 1
• Worker cron cần CPU
• 1 worker ~= 6 người dùng đồng thời

Tính toán kích thước bộ nhớ

• Chúng ta coi 20% yêu cầu là yêu cầu nặng, trong khi 80% là yêu cầu đơn giản hơn
• Một worker nặng được ước tính tiêu thụ khoảng 1GB RAM
• Một worker nhẹ được ước tính tiêu thụ khoảng 150MB RAM

Bộ nhớ cần thiết = #worker * ((tỷ_lệ_worker_nhẹ * ước_tính_ram_worker_nhẹ) + (tỷ_lệ_worker_nặng * ước_tính_ram_worker_nặng))

Cấu hình mẫu

• Máy chủ với 4 CPU, 8 luồng
• 60 người dùng đồng thời
• 60 người dùng / 6 = 10 <- số lượng worker lý thuyết cần thiết
• (4 * 2) + 1 = 9 <- số lượng worker tối đa lý thuyết
• Chúng ta sẽ sử dụng 8 worker + 1 cho cron. Chúng ta cũng sẽ sử dụng một hệ thống giám sát để đo tải CPU, và kiểm tra xem nó có nằm trong khoảng từ 7 đến 7,5 không.
• RAM = 9 * ((0,8150) + (0,21024)) ~= 3Gb RAM cho Odoo

trong file cấu hình:

[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

Trong đó,

• limit_memory_hard: Đây là giới hạn bộ nhớ tối đa (theo byte) mà một tiến trình worker của Odoo có thể sử dụng. Nếu vượt quá giới hạn này, tiến trình sẽ bị hệ điều hành kill. Giá trị 1677721600 byte tương đương với 1.6GB.
• limit_memory_soft: Đây là ngưỡng cảnh báo bộ nhớ (theo byte). Nếu lượng bộ nhớ sử dụng của một tiến trình worker vượt quá giới hạn này, Odoo sẽ ghi một cảnh báo vào nhật ký. Giá trị 629145600 byte tương đương với 600MB.
• limit_request: Đây là số lượng yêu cầu tối đa mà một worker có thể xử lý trước khi tự động khởi động lại. Việc khởi động lại này giúp ngăn ngừa rò rỉ bộ nhớ và đảm bảo ổn định lâu dài của hệ thống. Giá trị 8192 có nghĩa là một worker sẽ xử lý tối đa 8192 yêu cầu trước khi khởi động lại.
• limit_time_cpu: Đây là giới hạn thời gian CPU tối đa (theo giây) mà một worker có thể sử dụng để xử lý một yêu cầu đơn lẻ. Nếu vượt quá thời gian này, yêu cầu sẽ bị hủy bỏ. Giá trị 600 giây tương đương với 10 phút.
• limit_time_real: Đây là giới hạn thời gian thực tế tối đa (theo giây) mà một worker có thể sử dụng để xử lý một yêu cầu đơn lẻ. Nếu vượt quá thời gian này, yêu cầu sẽ bị hủy bỏ. Giá trị 1200 giây tương đương với 20 phút.

Các config khác

• addons_path: Chỉ định đường dẫn đến thư mục addons và chúng được thêm vào theo thứ tự ưu tiên.
• csv_internal_sep: Chỉ định ký tự phân cách sử dụng trong các file CSV.
• email_from: Chỉ định địa chỉ email SMTP để gửi email.
• http_port: Chỉ định cổng HTTP cho Odoo.
• list_db: True/False. Nếu False, ẩn danh sách cơ sở dữ liệu.
• log_db: True/False. Nếu True, cũng ghi log vào bảng 'ir_logging' trong cơ sở dữ liệu.
• log_level: Có thể gán các giá trị: info, debug_rpc, warn, test, critical, debug_sql, error, debug, debug_rpc_answer.
• log_handler: Chỉ định cặp giá trị từ danh sách cặp 'module:log_level'. Giá trị mặc định là ':INFO', có nghĩa mức log mặc định cho tất cả module là 'INFO'.
• logfile: Chỉ định tên file log. Nếu không đặt, sử dụng stdout.
• logrotate: True/False. Nếu True, tạo file log hàng ngày và giữ lại tối đa 30 file log.
• interface: Chỉ định địa chỉ IP mà máy chủ sẽ bind (hoặc localhost). Nếu trống, nó sẽ bind tất cả các interface. Mặc định là trống.
• port: Chỉ định cổng TCP mà máy chủ sẽ lắng nghe. Giá trị mặc định là 8069.
• secure: Chỉ định có khởi chạy máy chủ trên HTTPS thay vì HTTP không. Giá trị mặc định là False.
• secure_cert_file: Chỉ định file chứng chỉ, được sử dụng cho kết nối SSL.
• secure_pkey_file: Chỉ định file khóa bí mật, được sử dụng cho kết nối SSL.
• longpolling_port: Chỉ định cổng TCP sử dụng cho các kết nối longpolling trong chế độ đa xử lý hoặc gevent. Giá trị mặc định là 8072. Không được sử dụng trong chế độ đa luồng (threaded mode) mặc định.
• max_cron_threads: Chỉ định số worker chuyên dụng cho các tác vụ cron. Giá trị mặc định là 2.
• osv_memory_age_limit: Chỉ định giới hạn tuổi tối đa của các bản ghi được giữ trong bảng ảo osv_memory. Đây là giá trị float, tính bằng giờ, mặc định là 1 giờ.
• osv_memory_count_limit: Chỉ định giới hạn số lượng bản ghi tối đa được giữ trong bảng ảo osv_memory. Giá trị mặc định là False, có nghĩa không giới hạn số bản ghi.
• pidfile: PID của máy chủ sẽ được lưu trong file này. Giá trị mặc định là False. Script init sẽ tạo pid.
• proxy_mode: Đặt True nếu triển khai ứng dụng sau proxy. Giá trị mặc định là True.
• server_wide_modules: Chỉ định danh sách module toàn hệ thống, phân cách bằng dấu phẩy. Giá trị mặc định là 'web'.
• smtp_password: Chỉ định mật khẩu SMTP để gửi email.
• smtp_port: Chỉ định cổng SMTP.
• smtp_server: Chỉ định máy chủ SMTP để gửi email. Giá trị mặc định là 'localhost'.
• smtp_ssl: True/False. Nếu True, kết nối SMTP sẽ được mã hóa bằng SSL (STARTTLS).
• smtp_user: Chỉ định người dùng SMTP để gửi email. Giá trị mặc định là False.
• syslog: True/False, ghi log vào hệ thống logger syslog.
• test_enable: True/False, kích hoạt các test YAML và unit test.
• test_file: Dùng để chạy một file test python hoặc YML. Giá trị mặc định là False.
• test_report_directory: Chỉ định thư mục để lưu mẫu của tất cả các báo cáo. Giá trị mặc định là False.
• test_commit: Dùng để commit các thay đổi cơ sở dữ liệu được thực hiện bởi các test YAML hoặc XML. Giá trị mặc định là False.
• translate_modules: Chỉ định các module cần xuất. Sử dụng kết hợp với --i18n-export. Giá trị mặc định là ['all'].
• without_demo: Dùng để vô hiệu hóa tải dữ liệu demo cho các module được cài đặt. Có thể chỉ định các module cách nhau bằng dấu phẩy và dùng "all" để áp dụng cho tất cả module. Giá trị mặc định là False.
• workers: Chỉ định số lượng worker. Giá trị mặc định là 0.
• xmlrpcs: Dùng để kích hoạt hoặc vô hiệu hóa giao thức XML-RPC Secure. Đặt False để vô hiệu hóa.
• xmlrpcs_interface: Chỉ định địa chỉ IP TCP cho giao thức XML-RPC Secure. Có thể sử dụng chuỗi rỗng để bind tất cả các interface.
• xmlrpcs_port: Chỉ định cổng TCP cho giao thức XML-RPC Secure.
• xmlrpc: Dùng để kích hoạt hoặc vô hiệu hóa giao thức XML-RPC. Đặt False để vô hiệu hóa.
• xmlrpc_interface: Chỉ định địa chỉ IP TCP cho giao thức XML-RPC. Có thể sử dụng chuỗi rỗng để bind tất cả các interface.
• xmlrpc_port: Chỉ định cổng TCP cho giao thức XML-RPC.
• timezone: Chỉ định múi giờ tham chiếu cho máy chủ. Ví dụ Europe/Berlin. Giá trị mặc định là False.