Odoo và DevOps

Triển khai và quản lý Odoo trong môi trường sản xuất: Docker/Kubernetes, nâng cấp an toàn, CI/CD tự động

Khi Odoo đã đi vào production, “deploy được” chỉ là mức tối thiểu. Thứ doanh nghiệp cần là:

• Ổn định: ít downtime, ít lỗi ngẫu nhiên

• Lặp lại được: deploy ở đâu cũng giống nhau

• An toàn khi nâng cấp: không làm gián đoạn vận hành

• Tự động hóa: test/build/deploy có kiểm soát, rollback nhanh

Bài này sẽ đi theo lộ trình thực chiến:

1. Triển khai Odoo với Docker (chuẩn hóa môi trường)

2. Mở rộng lên Kubernetes (scale/HA/operations)

3. Quản lý cấu hình & secret đúng chuẩn

4. Nâng cấp Odoo an toàn (staging, blue-green/canary, migration)

5. Tích hợp CI/CD cho testing & deployment tự động

1) Kiến trúc production “chuẩn” cho Odoo

Odoo production thường gồm các khối sau:

• Reverse proxy / Ingress (Nginx/Traefik): SSL termination, gzip, caching tĩnh, rate limit

• Odoo Web: xử lý request HTTP

• Odoo Worker / Cron: xử lý background jobs, scheduled actions

• PostgreSQL: DB (khuyến nghị dùng managed DB)

• Redis (tuỳ chọn): session/cache/queue (tuỳ cách triển khai)

• Filestore: file đính kèm (volume/shared storage)

Ý tưởng quan trọng: tách “web request” và “background work”. Nếu cron/job nặng chạy chung process với web, user sẽ “ăn đủ”.

2) Triển khai Odoo với Docker (production-ready)

2.1 Nguyên tắc Docker cho production

• Image immutable: build 1 lần, chạy nhiều nơi (dev/staging/prod)

• Không sửa tay trong container (không pip install / sửa code trực tiếp)

• Secrets không nằm trong image

• Config tách khỏi code (env/config file mount)

2.2 Dockerfile gợi ý (custom addons)

Bạn có 2 cách phổ biến:

Cách A (copy addons vào image): phù hợp khi muốn “đóng gói” release hoàn chỉnh
Cách B (mount addons): phù hợp dev/staging, nhưng production nên hạn chế mount code “trôi nổi”

Ví dụ đơn giản:

• FROM odoo:16.0
• USER root
• COPY ./addons /mnt/extra-addons
• RUN chown -R odoo:odoo /mnt/extra-addons
• USER odoo

 

2.3 docker-compose (staging hoặc production nhỏ)

Tách tối thiểu 3 service: odoo, db, nginx. Nếu production thật, DB nên là managed (RDS/Cloud SQL).

Điểm cần lưu ý trong compose:

• volume cho /var/lib/odoo (filestore)

• healthcheck

• resource limits (CPU/RAM)

• logging

3) Odoo trên Kubernetes: scale & high availability

Docker giúp chuẩn hóa. Kubernetes giúp vận hành ở quy mô lớn: autoscaling, rolling update, self-healing, tách workload rõ ràng.

3.1 Khi nào nên dùng Kubernetes?

• Nhiều user đồng thời (traffic biến động)

• Nhiều background tasks (cron, queue)

• Yêu cầu HA, giảm downtime khi deploy

• Team cần quy trình CI/CD chuẩn hóa

3.2 Thiết kế workloads: Web vs Worker

Web Deployment

• Chạy Odoo với cấu hình web (workers phù hợp)

• Hạn chế/không chạy cron ở đây (tuỳ chiến lược)

Worker/Cron Deployment

• Chạy background jobs, cron, queue

• Scale độc lập (cần nhiều worker hơn web)

Tip thực chiến: Nếu bạn có job queue (OCA queue_job hoặc giải pháp nội bộ), worker pods scale theo queue depth.

3.3 Storage: Filestore là “điểm khó”

Odoo attachments nằm ở filestore. Trong K8s, filestore cần:

• PersistentVolume (NFS/CSI/EFS/Filestore managed)

• hoặc chuyển sang object storage (S3/GCS) bằng giải pháp phù hợp (tuỳ hệ sinh thái)

3.4 Ingress và proxy_mode

Odoo thường chạy sau reverse proxy. Bạn cần:

• proxy_mode = True

• cấu hình headers X-Forwarded-Proto, X-Forwarded-Host

3.5 ConfigMap & Secret

• ConfigMap: config không nhạy cảm

• Secret: DB password, SMTP password, API keys

4) Quản lý cấu hình production: “đúng chuẩn ngay từ đầu”

4.1 Cấu hình Odoo theo môi trường

Bạn nên chuẩn hóa config theo “12-factor”:

• config qua env vars / config file mount

• không hardcode domain, db credentials, keys

Nhóm config đáng chú ý:

• Performance: workers, limit_time_cpu, limit_time_real, max_cron_threads

• Security: proxy_mode, admin_passwd, db filter

• Logging: log level, log handler (SQL log khi debug)

• Email: SMTP (production hay lỗi vì SMTP/SSL)

4.2 Quản lý secret

Không để secret trong:

• git

• Docker image

• wiki/public notes

Dùng:

• K8s Secrets / Vault / Secret Manager (cloud)

5) Nâng cấp Odoo không ảnh hưởng hoạt động doanh nghiệp

5.1 Nâng cấp Odoo có những loại nào?

• Upgrade code custom module (same Odoo version)

• Upgrade Odoo minor (ví dụ 16.0.x)

• Upgrade major (15 -> 16) + migration DB

Mức rủi ro tăng dần theo thứ tự trên.

5.2 Nguyên tắc vàng: staging phải “giống production”

Bạn cần staging có:

• snapshot DB từ production

• snapshot filestore

• cùng config (trừ domain/secret)

• cùng addons versions

5.3 Chiến lược triển khai an toàn

(A) Rolling update (thường dùng, downtime thấp)

• Deploy pods mới

• healthcheck ok

• chuyển traffic dần

• pods cũ bị thay thế

Nhược: nếu migration DB nặng/không tương thích, rolling update có thể rủi ro.

(B) Blue–Green deployment (khuyến nghị khi nâng cấp lớn)

• Blue = version đang chạy

• Green = version mới, deploy song song

• test Green (smoke test)

• switch traffic sang Green

• có thể rollback về Blue nhanh

(C) Canary (phù hợp khi có phân luồng traffic)

• chỉ 1 phần traffic vào version mới

• quan sát metrics/log

• nếu ok tăng dần

5.4 Migration DB: cách làm để giảm downtime

• Chuẩn bị migration trên staging trước

• Với migration dài: cân nhắc maintenance window ngắn

• Tách bước:
  1. backup + verify restore

  2. migration

  3. smoke tests (login, create SO, confirm invoice, print report)

  4. switch traffic

Checklist “smoke test” tối thiểu sau upgrade

• Login + load main menus

• tạo Sale Order, confirm

• tạo Invoice, post

• chạy 1 cron quan trọng

• in 1 report PDF

• kiểm tra attachments

6) CI/CD cho Odoo: tự động hóa build – test – deploy

6.1 Pipeline chuẩn

Một pipeline hợp lý:

1. Lint/Static checks (tuỳ team)

2. Unit tests / module tests

3. Build Docker image (tag theo git SHA + semver)

4. Push image lên registry

5. Deploy staging (auto)

6. E2E/Smoke tests (auto hoặc manual gate)

7. Deploy production (manual approve hoặc auto theo policy)

6.2 Chạy test cho Odoo trong CI

Một cách phổ biến:

• tạo DB test

• install module cần test

• bật test mode

• stop after init

Ví dụ:

• odoo-bin -d test_db \
•   -i my_module \
•   –test-enable \
•   –stop-after-init

 

Tip thực chiến:

• chạy test theo module scope (không cần full DB)

• cache pip deps để CI nhanh hơn

• tách pipeline “quick checks” và “full regression” theo nhánh/tag

6.3 Deploy bằng Helm (Kubernetes)

Nếu dùng K8s, Helm giúp quản lý:

• values theo môi trường (staging/prod)

• versioning release

• rollback dễ

Chiến lược versioning

• image: my-odoo:<git_sha>

• release tag: v1.2.3

• rollback: đổi tag về bản trước

7) Monitoring/Logging/Alerting: phần hay bị bỏ quên

7.1 Metrics nên theo dõi

• response time (p95/p99)

• error rate (5xx)

• worker restarts

• DB connections

• slow queries (Postgres)

• cron/job failures

7.2 Logging

• log tập trung (ELK/Loki/Cloud Logging)

• correlation id cho request (nếu có)

• log riêng cho integration jobs (dễ trace)

7.3 Alert “thực sự hữu ích”

• worker crash liên tục

• cron quan trọng fail N lần

• latency tăng đột biến

• DB CPU/IO chạm ngưỡng

• disk/volume gần đầy (filestore)

8) Checklist production-ready cho Odoo DevOps

Deploy

• image immutable

• config/secret tách riêng

• web/worker tách deployment

• healthcheck rõ ràng

• resource limits/requests

Upgrade

• staging giống prod (DB + filestore)

• backup & restore test

• blue-green/canary cho thay đổi lớn

• smoke test checklist

CI/CD

• tự động test module quan trọng

• build & push image theo git SHA

• deploy staging tự động

• production có approval/rollback

Ops

• logging tập trung

• monitoring + alert

• theo dõi cron/job failures

9. Chia môi trường Odoo đúng cách: Dev – Staging – Production

9.1 Sai lầm rất phổ biến

Rất nhiều dự án chỉ có:

• 1 server dev

• 1 server production

➡️ Hệ quả:

• test không đủ

• bug chỉ lộ khi đã ảnh hưởng user thật

• nâng cấp rất rủi ro

9.2 Mô hình môi trường khuyến nghị

Môi trường	Mục đích
Dev	Code, debug, thử nhanh
Staging	Giả lập production, test nâng cấp
Production	User thật

Nguyên tắc vàng

Staging phải giống production về kiến trúc, chỉ khác dữ liệu và domain.

10. Thiết kế Docker image cho Odoo: quyết định ảnh hưởng lâu dài

10.1 Một image cho nhiều môi trường

Image Odoo nên:

• dùng chung cho dev / staging / prod

• khác nhau ở config & secret, không phải code

10.2 Tag image thế nào cho đúng?

Best practice:

• my-odoo:git_sha

• my-odoo:v1.2.3

Tránh:

• latest (khó rollback, khó debug)

11. Scale Odoo đúng cách: đừng chỉ “tăng workers”

11.1 Hiểu đúng bottleneck của Odoo

Khi Odoo chậm, nguyên nhân thường là:

• DB quá tải

• cron/job chiếm CPU

• IO (filestore, network)

• code ORM chưa tối ưu

➡️ Scale web không giải quyết hết mọi vấn đề.

11.2 Chiến lược scale chuẩn

Thành phần	Cách scale
Web	tăng replica
Worker	scale theo job
DB	vertical + tuning
Redis	cluster / managed

12. Cron & background jobs – “kẻ phá hoại thầm lặng”

12.1 Vì sao cron hay gây sự cố production?

• chạy lâu

• lock DB

• ăn CPU

• chạy cùng process với web

12.2 Best practices

• chạy cron trên worker riêng

• giới hạn max_cron_threads

• chia job lớn thành batch nhỏ

• log & alert khi cron fail

13. Quản lý filestore – vấn đề đau đầu nhất khi lên Kubernetes

13.1 Vì sao filestore khó?

• Odoo lưu attachment vào filesystem

• K8s pod là ephemeral

13.2 Các hướng giải quyết

Giải pháp	Khi dùng
NFS	on-prem
Cloud Filestore	GCP
EFS	AWS
Object storage	scale lớn

Lưu ý: backup filestore quan trọng không kém database.

14. Chiến lược nâng cấp Odoo – đi sâu hơn

14.1 Phân loại nâng cấp

1. Code-only (custom module)

2. Minor version (16.0.x)

3. Major version (15 → 16)

Mỗi loại cần chiến lược khác nhau.

14.2 Nâng cấp code custom module (an toàn nhất)

• chạy CI test

• deploy rolling update

• rollback nhanh bằng image tag

14.3 Nâng cấp minor version

• test trên staging

• kiểm tra report, cron, integration

• rolling update thường đủ an toàn

14.4 Nâng cấp major version (rủi ro cao)

Best practice:

1. clone prod → staging

2. migration DB

3. fix custom module

4. test nghiệp vụ

5. blue–green deploy

15. CI/CD nâng cao cho Odoo (không chỉ build & deploy)

15.1 Các tầng test nên có

Tầng	Mục tiêu
Unit test	logic Python
Module install	tránh lỗi phụ thuộc
ORM test	query, compute
Integration test	API ngoài
Smoke test	sau deploy

15.2 Pipeline CI/CD nâng cao

Push code

   ↓

Static check

   ↓

Unit & module test

   ↓

Build image

   ↓

Deploy staging

   ↓

Smoke test

   ↓

Manual approval

   ↓

Deploy production

16. Rollback – thứ phải nghĩ trước khi deploy

16.1 Rollback code

• quay lại image tag cũ

• redeploy trong vài phút

16.2 Rollback database (khó hơn)

• cần backup snapshot

• test restore định kỳ

• tránh migration không reversible

Nguyên tắc:

Nếu không rollback được, đừng deploy.

17. Monitoring & Alert – để biết hệ thống “đang đau ở đâu”

17.1 Metric quan trọng với Odoo

• request latency

• worker restart

• cron fail

• DB slow query

• disk filestore

17.2 Alert nên “ít nhưng đúng”

• không spam

• tập trung vào lỗi ảnh hưởng business

18. Checklist DevOps Odoo – bản đầy đủ

Trước khi go-live

• Docker image immutable

• Config/secret tách riêng

• Web/worker tách process

• Backup DB + filestore

• CI chạy test cơ bản

Khi nâng cấp

• Staging giống prod

• Có plan rollback

• Smoke test checklist

• Maintenance window (nếu cần)

Khi vận hành lâu dài

• Monitoring & alert

• Review cron/job định kỳ

• Review performance DB

• Dọn data cũ

Kết luận

Odoo + DevOps không phải để “cho vui”, mà để:

• Bảo vệ hoạt động kinh doanh

• Giảm rủi ro khi thay đổi

• Team làm việc chuyên nghiệp

• Giúp hệ thống sống lâu (5–10 năm)

Nếu làm đúng:

• deploy không còn căng thẳng

• nâng cấp không còn ám ảnh

• Chuyện chạy tốt ở local lỗi ở production gần như biến mất