簡(jiǎn)介這是一份圍繞 Odoo SaaS Kit 的 PDF 技術(shù)文檔重點(diǎn)講解基于 Docker 的多租戶(hù) Odoo 實(shí)例管理系統(tǒng)面向已有服務(wù)器管理和 Odoo 使用經(jīng)驗(yàn)、負(fù)責(zé)企業(yè)級(jí)應(yīng)用部署與運(yùn)維的 IT 專(zhuān)業(yè)人員。文檔覆蓋部署鏈路安裝 docker、erppeek、paramiko 等 Python 庫(kù)規(guī)劃 Odoo-SAAS-Data、docker_vhosts、common_addons 目錄構(gòu)建基礎(chǔ) Odoo Docker 鏡像配置 Nginx 虛擬主機(jī)與 PostgreSQL并為 Odoo 用戶(hù)授權(quán) Docker 與 Nginx 控制權(quán)限。隨后說(shuō)明如何配置 SaaS 服務(wù)器、創(chuàng)建訂閱計(jì)劃使客戶(hù)自助生成實(shí)例同時(shí)設(shè)置計(jì)費(fèi)周期、試用期與模塊列表還特別提醒構(gòu)建鏡像時(shí)須保持主機(jī)與容器內(nèi) Odoo 用戶(hù) ID 和組 ID 一致避免共享文件夾權(quán)限問(wèn)題。針對(duì)實(shí)際運(yùn)維文檔整理模塊上傳、域名管理、日志查看、備份恢復(fù)和重啟客戶(hù)端進(jìn)程等常見(jiàn)問(wèn)題解法便于快速排障。資源包共 1 個(gè) PDF 文件大小 3.99MB適合作為部署參考與運(yùn)維手冊(cè)。目前已有 140 人瀏覽學(xué)習(xí)適合有 Docker 與 Nginx 基礎(chǔ)的技術(shù)人員直接借鑒。1. Odoo SaaS Kit為什么多租戶(hù)實(shí)例管理是Odoo商業(yè)化繞不開(kāi)的一道坎做Odoo實(shí)施的團(tuán)隊(duì)遲早會(huì)遇到同一個(gè)問(wèn)題客戶(hù)從3家漲到30家不可能給每家單獨(dú)買(mǎi)一臺(tái)服務(wù)器也不可能在一套Odoo里塞三十個(gè)互不相干的業(yè)務(wù)庫(kù)。Odoo SaaS Kit這個(gè)方向解決的就是這件事——用Docker把每個(gè)租戶(hù)的Odoo實(shí)例、數(shù)據(jù)庫(kù)、資源配額管起來(lái)做到開(kāi)新客戶(hù)像開(kāi)賬號(hào)一樣快。它不是某個(gè)插件而是一整套“部署配置管理”的方案容器編排管實(shí)例生命周期PostgreSQL隔離租戶(hù)數(shù)據(jù)反向代理按域名分發(fā)請(qǐng)求再加一套運(yùn)維流程做備份、升級(jí)和擴(kuò)容。適合正在做Odoo實(shí)施交付的顧問(wèn)、小團(tuán)隊(duì)SaaS創(chuàng)業(yè)者以及要給客戶(hù)提供Odoo訂閱服務(wù)的技術(shù)負(fù)責(zé)人。2. 先搭地基Odoo SaaS Kit 的架構(gòu)選型與Docker最小拓?fù)?.1 多租戶(hù)的三種隔離方式為什么最終選“一實(shí)例一庫(kù)一容器組”O(jiān)doo做多租戶(hù)隔離方式大致有三條路共享數(shù)據(jù)庫(kù)共享Schema、共享數(shù)據(jù)庫(kù)獨(dú)立Schema、獨(dú)立數(shù)據(jù)庫(kù)。第一條路在Odoo里基本走不通因?yàn)镺doo的模塊安裝在數(shù)據(jù)庫(kù)級(jí)別不同客戶(hù)裝了不同模塊之后公共表結(jié)構(gòu)根本沒(méi)法統(tǒng)一。第二條路要改造ORM層動(dòng)到Odoo框架底子風(fēng)險(xiǎn)大且升級(jí)時(shí)每次都要打補(bǔ)丁不適合長(zhǎng)期維護(hù)。SaaS Kit走的是第三條路每個(gè)租戶(hù)一個(gè)獨(dú)立PostgreSQL數(shù)據(jù)庫(kù)前端可以共用一套Odoo容器也可以每個(gè)租戶(hù)獨(dú)立容器組。新手階段建議從“共用Odoo容器獨(dú)立租戶(hù)庫(kù)”起步成本和運(yùn)維量最低等某個(gè)租戶(hù)的負(fù)載明顯影響其他人時(shí)再把這個(gè)租戶(hù)拆成獨(dú)立容器組。這套方案依賴(lài)Odoo官方就支持的多數(shù)據(jù)庫(kù)機(jī)制PostgreSQL里建了庫(kù)Odoo通過(guò)db_filter參數(shù)自動(dòng)識(shí)別可用的租戶(hù)庫(kù)不需要改Odoo源碼。隔離性、升級(jí)靈活性、交付速度三個(gè)維度上它都是最穩(wěn)的折中。2.2 最小容器拓?fù)淅锩總€(gè)角色的職責(zé)與關(guān)鍵參數(shù)一套能跑起來(lái)的SaaS Kit最小拓?fù)涫撬膫€(gè)容器PostgreSQL、Odoo、Redis、Nginx。數(shù)據(jù)庫(kù)負(fù)責(zé)租戶(hù)數(shù)據(jù)隔離Odoo負(fù)責(zé)應(yīng)用邏輯Redis在Odoo里做session存儲(chǔ)和緩存Nginx負(fù)責(zé)按域名把請(qǐng)求路由到Odoo。四個(gè)容器放在同一個(gè)自定義bridge網(wǎng)絡(luò)里互相通過(guò)容器名通信。容器角色鏡像關(guān)鍵端口職責(zé)dbpostgres:165432每租戶(hù)一個(gè)獨(dú)立databaseodooodoo:208069處理HTTP請(qǐng)求與業(yè)務(wù)邏輯redisredis:7-alpine6379session存儲(chǔ)、緩存nginxnginx:1.27-alpine80/443域名路由、TLS終止、WebSocket轉(zhuǎn)發(fā)Odoo容器里有幾個(gè)參數(shù)直接影響多租戶(hù)行為必須在compose里顯式聲明。db_filter告訴Odoo哪些數(shù)據(jù)庫(kù)屬于租戶(hù)常見(jiàn)的做法是設(shè)為^odoo_只匹配以odoo_開(kāi)頭的庫(kù)避免把PostgreSQL里其他管理庫(kù)暴露到前端。list_dbfalse關(guān)閉數(shù)據(jù)庫(kù)列表展示防止用戶(hù)在登錄頁(yè)看到全部租戶(hù)庫(kù)名。proxy_modetrue讓Odoo信任Nginx轉(zhuǎn)發(fā)過(guò)來(lái)的HTTP頭否則生成的回鏈URL會(huì)帶上內(nèi)網(wǎng)端口。workers數(shù)量一般按CPU核數(shù)*21估算max_cron_threads保留1個(gè)線(xiàn)程跑定時(shí)任務(wù)多租戶(hù)場(chǎng)景下cron線(xiàn)程太多會(huì)互相搶數(shù)據(jù)庫(kù)連接。2.3 版本鎖定為什么從Odoo 20和PostgreSQL 16起步鏡像tag選擇上我的建議是直接鎖定Odoo 20和PostgreSQL 16不要用latest。latest在Docker里是個(gè)黑匣子今天拉下來(lái)能用三個(gè)月后再拉可能就是新版本升級(jí)引發(fā)的兼容問(wèn)題排查起來(lái)非常被動(dòng)。Odoo 20是目前社區(qū)活躍度最高的版本線(xiàn)Docker鏡像、第三方模塊適配都齊全Python版本和依賴(lài)在鏡像里已經(jīng)固定省去不少手工編譯的麻煩。PostgreSQL 16對(duì)Odoo 20的支持成熟還有一個(gè)實(shí)際原因備份恢復(fù)工具pg_dump/pg_restore在大版本之間不能保證向下兼容。如果線(xiàn)上是PostgreSQL 16恢復(fù)演練和災(zāi)備環(huán)境也必須是16鎖死版本能避免“生產(chǎn)好好的備份恢復(fù)不回去”的血淚事故。Redis用7-alpine即可Odoo對(duì)Redis版本不敏感但alpine鏡像體積小、內(nèi)存占用低適合容器密集部署。最后一個(gè)建議統(tǒng)一從私有鏡像倉(cāng)庫(kù)拉取這三個(gè)鏡像把版本號(hào)寫(xiě)進(jìn)compose文件不要在日常操作里手動(dòng)docker pull覆蓋tag。3. 部署落地用docker compose跑起第一套多租戶(hù)Odoo3.1 第一版docker-compose.yml先接受“一容器一庫(kù)”的簡(jiǎn)單拓?fù)湎葘?xiě)第一版compose文件不追求完美目標(biāo)是讓db、odoo、redis、nginx四個(gè)容器一次起來(lái)并且能通過(guò)db_filter識(shí)別租戶(hù)庫(kù)。后續(xù)要拆獨(dú)立租戶(hù)容器組時(shí)再擴(kuò)展但架構(gòu)骨架不變。version: 3.8 services: db: image: postgres:16 container_name: saas_db environment: POSTGRES_USER: odoo POSTGRES_PASSWORD: odoo_password POSTGRES_DB: postgres volumes: - db_data:/var/lib/postgresql/data healthcheck: test: [CMD-SHELL, pg_isready -U odoo] interval: 10s timeout: 5s retries: 5 networks: - saas_net odoo: image: odoo:20 container_name: saas_odoo depends_on: db: condition: service_healthy environment: HOST: db USER: odoo PASSWORD: odoo_password DB_FILTER: ^odoo_ LIST_DB: false PROXY_MODE: true WORKERS: 5 MAX_CRON_THREADS: 1 volumes: - odoo_data:/var/lib/odoo - ./addons:/mnt/extra-addons networks: - saas_net redis: image: redis:7-alpine container_name: saas_redis command: [redis-server, --appendonly, yes] networks: - saas_net nginx: image: nginx:1.27-alpine container_name: saas_nginx depends_on: - odoo ports: - 80:80 - 443:443 volumes: - ./nginx/conf.d:/etc/nginx/conf.d:ro - ./certs:/etc/nginx/certs:ro networks: - saas_net volumes: db_data: odoo_data: networks: saas_net: driver: bridge這段compose的邏輯是db容器先啟動(dòng)healthcheck通過(guò)后odoo容器才會(huì)創(chuàng)建這套依賴(lài)機(jī)制在compose里用condition: service_healthy實(shí)現(xiàn)。DB_FILTER: ^odoo_是關(guān)鍵的正則Odoo啟動(dòng)時(shí)會(huì)掃描PostgreSQL里所有數(shù)據(jù)庫(kù)只把以odoo_開(kāi)頭的庫(kù)當(dāng)作租戶(hù)實(shí)例。LIST_DB: false對(duì)應(yīng)Odoo配置里的list_db False登錄頁(yè)不再展示數(shù)據(jù)庫(kù)下拉框。PROXY_MODE: true對(duì)應(yīng)proxy_mode True后面Nginx轉(zhuǎn)發(fā)時(shí)才不會(huì)出URL端口錯(cuò)誤。workers數(shù)量這里寫(xiě)了5適合2核4G的初始機(jī)器。workers不是越大越好每個(gè)worker都持有數(shù)據(jù)庫(kù)連接池PostgreSQL默認(rèn)max_connections只有100workers太多反而拖垮數(shù)據(jù)庫(kù)這是第一次部署時(shí)最容易忽略的容量關(guān)系。3.2 初始化租戶(hù)數(shù)據(jù)庫(kù)并讓Odoo識(shí)別多庫(kù)compose文件寫(xiě)好后先啟動(dòng)數(shù)據(jù)庫(kù)容器確認(rèn)健康狀態(tài)再啟動(dòng)Odoo然后手動(dòng)創(chuàng)建第一個(gè)租戶(hù)庫(kù)。不要用docker compose up -d一把梭第一次跑先拆開(kāi)做方便定位是數(shù)據(jù)庫(kù)沒(méi)起來(lái)還是Odoo連接失敗。docker compose up -d db docker compose exec db pg_isready -U odoo docker compose exec db createdb -U odoo -O odoo odoo_tenant_001 docker compose up -d第一行只啟動(dòng)db容器第二行用pg_isready探測(cè)PostgreSQL是否接受連接。返回accepting connections說(shuō)明就緒再執(zhí)行第三行創(chuàng)建租戶(hù)庫(kù)。-U odoo指定用戶(hù)-O odoo把新庫(kù)的屬主設(shè)為odoo用戶(hù)這一步不能漏否則Odoo用odoo用戶(hù)登錄后對(duì)這個(gè)庫(kù)沒(méi)有完整權(quán)限運(yùn)行時(shí)會(huì)報(bào)permission denied。第四行把odoo、redis、nginx一起拉起來(lái)Odoo啟動(dòng)時(shí)讀到DB_FILTER自動(dòng)把odoo_tenant_001識(shí)別為可訪(fǎng)問(wèn)的租戶(hù)庫(kù)。打開(kāi)瀏覽器訪(fǎng)問(wèn)http://服務(wù)器IP/web/database/selector如果配置生效頁(yè)面不會(huì)列出數(shù)據(jù)庫(kù)列表需要手動(dòng)輸入租戶(hù)庫(kù)名odoo_tenant_001才能進(jìn)入初始化安裝界面?？吹竭@個(gè)行為說(shuō)明多租戶(hù)入口已經(jīng)通了。首次進(jìn)入會(huì)在租戶(hù)庫(kù)里初始化Odoo基礎(chǔ)模塊耗時(shí)一兩分鐘耐心等頁(yè)面跳轉(zhuǎn)。3.3 Nginx反向代理與租戶(hù)域名路由Odoo本身不處理域名路由它只按數(shù)據(jù)庫(kù)名分發(fā)請(qǐng)求域名到租戶(hù)庫(kù)的映射要Nginx來(lái)做。最常見(jiàn)的方案是通配符解析每個(gè)租戶(hù)一個(gè)二級(jí)域名結(jié)構(gòu)是tenant001.yourdomain.comDNS里加一條*.yourdomain.com到服務(wù)器IP的A記錄Nginx用一個(gè)server塊接住所有租戶(hù)請(qǐng)求轉(zhuǎn)發(fā)給Odoo容器。upstream odoo_backend { server saas_odoo:8069; keepalive 64; } server { listen 80; server_name *.yourdomain.com; proxy_read_timeout 720s; proxy_connect_timeout 10s; proxy_send_timeout 720s; proxy_set_header Host $host; proxy_set_header X-Forwarded-Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; location / { proxy_pass http://odoo_backend; } }關(guān)鍵在兩處server_name *.yourdomain.com匹配所有租戶(hù)子域proxy_pass http://odoo_backend把請(qǐng)求轉(zhuǎn)給compose網(wǎng)絡(luò)里的odoo容器。Odoo拿到請(qǐng)求后根據(jù)Host頭里的子域前綴結(jié)合dbfilter正則匹配對(duì)應(yīng)租戶(hù)庫(kù)這就是為什么dbfilter必須用^odoo_開(kāi)頭來(lái)匹配數(shù)據(jù)庫(kù)名的原因——tenant001.yourdomain.com需要和庫(kù)名odoo_tenant_001在命名上強(qiáng)對(duì)應(yīng)。WebSocket要單獨(dú)處理Odoo的實(shí)時(shí)通信比如消息通知走WebSocket協(xié)議Nginx默認(rèn)轉(zhuǎn)發(fā)不了。需要先定義map $http_upgrade $connection_upgrade { default upgrade; close; }這段映射放到http塊里再在server塊里帶上Upgrade和Connection頭。不帶這段Odoo后臺(tái)的在線(xiàn)用戶(hù)列表和聊天功能會(huì)偶發(fā)斷連報(bào)錯(cuò)日志里能看到websocket connection failed。4. 實(shí)例管理打通租戶(hù)生命周期、備份恢復(fù)與資源配額4.1 租戶(hù)生命周期管理的常規(guī)操作序列SaaS Kit的管理對(duì)象是租戶(hù)實(shí)例實(shí)例管理的第一步是把生命周期標(biāo)準(zhǔn)化創(chuàng)建、暫停、遷移、歸檔、銷(xiāo)毀每個(gè)動(dòng)作對(duì)應(yīng)一組確定的命令。不要手動(dòng)去容器里亂改要把命令沉淀成腳本否則租戶(hù)一多必然出錯(cuò)。# 創(chuàng)建租戶(hù) docker compose exec db createdb -U odoo -O odoo odoo_tenant_002 # 暫停租戶(hù)停止Odoo側(cè)服務(wù)保留數(shù)據(jù) docker compose stop odoo # 恢復(fù)服務(wù) docker compose start odoo # 歸檔租戶(hù)導(dǎo)出數(shù)據(jù)并下線(xiàn) docker compose exec db pg_dump -U odoo -Fc odoo_tenant_002 backups/odoo_tenant_002.dump docker compose exec db dropdb -U odoo odoo_tenant_002創(chuàng)建租戶(hù)其實(shí)只做一件事建一個(gè)空數(shù)據(jù)庫(kù)。Odoo會(huì)在首次訪(fǎng)問(wèn)時(shí)自動(dòng)完成模塊初始化不需要事先安裝任何東西。暫停和恢復(fù)針對(duì)整個(gè)Odoo容器操作這在一容器多庫(kù)的架構(gòu)下是硬傷——停一個(gè)租戶(hù)所有人都訪(fǎng)問(wèn)不了。所以暫停操作更適合用在“整體維護(hù)窗口”場(chǎng)景單獨(dú)的租戶(hù)停用要通過(guò)nginx層做路由攔截或者用數(shù)據(jù)庫(kù)級(jí)權(quán)限控制不能簡(jiǎn)單stop Odoo容器。歸檔操作要特別注意順序先pg_dump導(dǎo)出確認(rèn)dump文件大小合理再dropdb刪除庫(kù)。順序反了就得從備份恢復(fù)多租戶(hù)系統(tǒng)里沒(méi)有后悔藥吃。dropdb之后dbfilter正則自動(dòng)不再匹配這個(gè)庫(kù)租戶(hù)的域名訪(fǎng)問(wèn)會(huì)直接404屬于安全的離線(xiàn)狀態(tài)。4.2 備份與恢復(fù)多租戶(hù)下恢復(fù)比備份難十倍單機(jī)單庫(kù)的備份很簡(jiǎn)單多租戶(hù)場(chǎng)景下難點(diǎn)在恢復(fù)不能把整個(gè)PostgreSQL目錄拷貝覆蓋那會(huì)把所有租戶(hù)一起回滾也不能在恢復(fù)時(shí)讓dbfilter誤匹配到半初始化狀態(tài)的庫(kù)。我的建議是采用租戶(hù)級(jí)備份策略每個(gè)租戶(hù)庫(kù)獨(dú)立導(dǎo)出獨(dú)立恢復(fù)互不影響。# 備份單個(gè)租戶(hù)壓縮格式支持選擇性恢復(fù) docker compose exec db pg_dump -U odoo -Fc odoo_tenant_001 backups/odoo_tenant_001_$(date %F).dump # 恢復(fù)單個(gè)租戶(hù)到新庫(kù) docker compose exec db createdb -U odoo -O odoo odoo_tenant_001_restored docker compose exec db pg_restore -U odoo -d odoo_tenant_001_restored --no-owner --no-privileges backups/odoo_tenant_001_20250601.dump恢復(fù)時(shí)務(wù)必用--no-owner --no-privileges否則dump里的屬主信息會(huì)和當(dāng)前容器里的odoo用戶(hù)不一致Odoo連上去后經(jīng)常報(bào)權(quán)限錯(cuò)誤?；謴?fù)完成后新庫(kù)名如果不符合dbfilter正則Odoo不會(huì)識(shí)別它這時(shí)把容器里的DB_FILTER臨時(shí)改成正則匹配新庫(kù)名或者直接在Nginx層加一條測(cè)試域名指過(guò)去驗(yàn)證數(shù)據(jù)完整后再把舊庫(kù)切換走。cron定時(shí)備份的腳本建議分成兩層每晚全量備份所有租戶(hù)庫(kù)每小時(shí)只對(duì)變更最頻繁的兩三個(gè)租戶(hù)做增量。PostgreSQL沒(méi)有內(nèi)置增量常見(jiàn)的做法是結(jié)合WAL歸檔但對(duì)SaaS Kit這種規(guī)模來(lái)說(shuō)太重。實(shí)際夠用的方案是夜間cron跑全套pg_dump白天每?jī)尚r(shí)對(duì)活躍租戶(hù)單獨(dú)跑一次輕量dump保留最近7天備份?；謴?fù)演練每月至少做一次不要等真出事了才試。4.3 容器資源配額與SaaS套餐定價(jià)的映射多租戶(hù)系統(tǒng)管理到后期最大的問(wèn)題不是功能是資源分配。一個(gè)租戶(hù)寫(xiě)死一個(gè)Odoo容器不現(xiàn)實(shí)資源浪費(fèi)嚴(yán)重但共用容器又沒(méi)法控制單個(gè)租戶(hù)的CPU和內(nèi)存占用。SaaS Kit的常見(jiàn)做法是在容器編排層給租戶(hù)定義配額模板用compose里的mem_limit和cpus字段控制。# 示例獨(dú)立租戶(hù)容器組的資源配額 services: odoo_tenant_001: image: odoo:20 mem_limit: 2g cpus: 1.0 environment: WORKERS: 3先把配額模板和服務(wù)套餐綁定基礎(chǔ)版1G內(nèi)存1核專(zhuān)業(yè)版2G內(nèi)存2核旗艦版4G內(nèi)存4核。Odoo的workers數(shù)量跟隨內(nèi)存配額走1G內(nèi)存最多配3個(gè)workers再高數(shù)據(jù)庫(kù)連接池會(huì)先撐不住。這個(gè)映射關(guān)系要在交付文檔里寫(xiě)明否則銷(xiāo)售簽了高并發(fā)客戶(hù)部署時(shí)內(nèi)存配額給不夠后續(xù)全是性能投訴。docker update可以在容器運(yùn)行中動(dòng)態(tài)調(diào)整配額比如某個(gè)租戶(hù)月底結(jié)賬時(shí)CPU飆高臨時(shí)docker update --cpus 2 --mem_limit 4g saas_odoo_tenant_001結(jié)完賬再調(diào)回來(lái)。調(diào)整后觀察容器重啟情況內(nèi)存配額調(diào)低到當(dāng)前占用以下容器會(huì)被內(nèi)核直接殺掉這個(gè)操作必須謹(jǐn)慎。quota和計(jì)費(fèi)系統(tǒng)聯(lián)動(dòng)時(shí)建議按“配額階梯計(jì)費(fèi)”而不是“實(shí)際消耗計(jì)費(fèi)”否則AWS賬單波動(dòng)會(huì)讓用戶(hù)投訴到懷疑人生SaaS套餐的費(fèi)用策略里這是最穩(wěn)的一種設(shè)計(jì)。5. 避坑清單Docker部署Odoo SaaS Kit的常見(jiàn)問(wèn)題與排查路徑5.1 現(xiàn)象Docker Desktop啟動(dòng)失敗提示virtualization support not detectedWindows環(huán)境跑Docker Desktop最常撞上的錯(cuò)誤就是啟動(dòng)時(shí)彈出virtualization support not detected。原因是BIOS里的虛擬化技術(shù)沒(méi)開(kāi)或者Windows的虛擬機(jī)平臺(tái)功能沒(méi)啟用。解決路徑重啟進(jìn)BIOS/UEFI找到Intel VT-x或AMD-V選項(xiàng)并開(kāi)啟然后在Windows功能里勾選“適用于Linux的Windows子系統(tǒng)”和“虛擬機(jī)平臺(tái)”執(zhí)行bcdedit /set hypervisorlaunchtype auto后重啟。啟動(dòng)不了Docker Desktop后面所有compose操作都無(wú)法進(jìn)行。Linux服務(wù)器上如果遇到docker: failed to start daemon先查內(nèi)核模塊lsmod | grep overlay和cgroup掛載大多數(shù)是內(nèi)核太舊或系統(tǒng)盤(pán)空間不足導(dǎo)致dockerd啟動(dòng)失敗。5.2 現(xiàn)象連接不上Docker引擎報(bào)failed to connect to the docker apifailed to connect to the docker api at npipe:////./pipe/dockerDesktopLinuxEngine這個(gè)錯(cuò)誤在Windows和Mac上都很常見(jiàn)。表面意思是Docker客戶(hù)端連不上引擎實(shí)際是Docker Desktop啟動(dòng)到一半卡住了或者引擎在后臺(tái)崩潰。解決路徑先打開(kāi)Docker Desktop界面看引擎狀態(tài)圖標(biāo)是紅色說(shuō)明引擎沒(méi)起來(lái)點(diǎn)Restart如果Restart無(wú)效執(zhí)行wsl --shutdown關(guān)掉WSL虛擬機(jī)再重開(kāi)Docker Desktop。Windows服務(wù)里重啟com.docker.service也行。最直接的辦法是查Docker Desktop日志路徑在%LOCALAPPDATA%\Docker\log\看到EOF或connection reset基本是WSL2內(nèi)核問(wèn)題執(zhí)行wsl --update更新內(nèi)核后解決。5.3 現(xiàn)象容器間網(wǎng)絡(luò)不通Odoo連接PostgreSQL失敗compose文件部署時(shí)一切正常一旦有人手動(dòng)docker run補(bǔ)充容器就會(huì)出現(xiàn)Odoo容器連不上db容器的情況。原因很簡(jiǎn)單docker run默認(rèn)加入的是bridge網(wǎng)絡(luò)而compose創(chuàng)建的是自定義網(wǎng)絡(luò)saas_net兩個(gè)網(wǎng)絡(luò)的容器無(wú)法通過(guò)容器名互相解析。解決路徑所有補(bǔ)充容器都加--network saas_net參數(shù)或者把已有容器連進(jìn)去docker network connect saas_net container_name。排查時(shí)用docker network inspect saas_net查看節(jié)點(diǎn)列表確認(rèn)目標(biāo)容器在不在網(wǎng)絡(luò)里。另一個(gè)常見(jiàn)故障是容器網(wǎng)絡(luò)模式設(shè)置了network_mode: host這會(huì)導(dǎo)致compose網(wǎng)絡(luò)無(wú)法管理和隔離流量SaaS Kit多租戶(hù)場(chǎng)景下不建議使用host網(wǎng)絡(luò)。5.4 現(xiàn)象docker pull odoo鏡像下載慢卡在等待層數(shù)據(jù)多租戶(hù)系統(tǒng)一旦跑起來(lái)擴(kuò)容時(shí)最不想遇到的就是拉鏡像卡死。odoo官方鏡像體積不小層數(shù)多國(guó)內(nèi)網(wǎng)絡(luò)環(huán)境下直接拉官方倉(cāng)庫(kù)經(jīng)常幾KB每秒。解決路徑配置registry mirror是第一步。在/etc/docker/daemon.json里加registry-mirrors: [https://docker.mirrors.ustc.edu.cn]重啟docker daemon生效。如果公司網(wǎng)絡(luò)有緩存代理用registry-cache做內(nèi)網(wǎng)鏡像倉(cāng)庫(kù)20個(gè)租戶(hù)的服務(wù)器都從內(nèi)網(wǎng)倉(cāng)庫(kù)拉取速度質(zhì)變。切記不要在業(yè)務(wù)高峰期docker pull大鏡像這會(huì)擠占容器網(wǎng)絡(luò)帶寬出現(xiàn)整組服務(wù)響應(yīng)變慢的情況。實(shí)在拉不下來(lái)的鏡像換一臺(tái)網(wǎng)絡(luò)通暢的機(jī)器拉好再docker save成tar包scp過(guò)去docker load這是最土但最有效的后悔藥。5.5 現(xiàn)象所有租戶(hù)域名都進(jìn)入了同一個(gè)Odoo實(shí)例多個(gè)租戶(hù)域名配好后發(fā)現(xiàn)訪(fǎng)問(wèn)tenant002.yourdomain.com卻打開(kāi)了tenant001的登錄頁(yè)或者干脆提示數(shù)據(jù)庫(kù)不存在。這個(gè)坑十有八九是db_filter和域名路由失配。Odoo的多租戶(hù)識(shí)別鏈路是Nginx按Host轉(zhuǎn)發(fā)到OdooOdoo再用Host子域前綴去匹配數(shù)據(jù)庫(kù)名。任何一個(gè)環(huán)節(jié)的名字不對(duì)都會(huì)指向錯(cuò)誤的實(shí)例。解決路徑確認(rèn)數(shù)據(jù)庫(kù)名和子域名的映射關(guān)系。tenant002.yourdomain.com對(duì)應(yīng)的庫(kù)名必須是odoo_tenant_002dbfilter正則寫(xiě)成^odoo_才能匹配上。再看Nginx配置里有沒(méi)有多個(gè)server塊互相搶流量server_name *.yourdomain.com和server_name tenant002.yourdomain.com同時(shí)存在時(shí)Nginx按精確優(yōu)先規(guī)則匹配但很多人把精確域名寫(xiě)在通配前面導(dǎo)致所有請(qǐng)求都走精確匹配。最后檢查Odoo容器環(huán)境變量DB_FILTER有沒(méi)有被后面加載的配置文件覆蓋docker compose exec odoo env | grep DB_FILTER直接看運(yùn)行環(huán)境結(jié)果最可信。6. 進(jìn)階驗(yàn)證把SaaS Kit從“能跑”推到“敢上線(xiàn)”6.1 上線(xiàn)前要過(guò)的三關(guān)恢復(fù)演練、并發(fā)壓測(cè)、版本升級(jí)第一關(guān)是備份恢復(fù)演練選一個(gè)非生產(chǎn)租戶(hù)庫(kù)導(dǎo)出dump再恢復(fù)到全新庫(kù)全程記錄耗時(shí)。多租戶(hù)系統(tǒng)最容易翻車(chē)的就是災(zāi)備環(huán)節(jié)——備份天天跑恢復(fù)沒(méi)人試過(guò)。第二關(guān)是并發(fā)壓測(cè)用ab -n 1000 -c 20 http://localhost/觀察Odoo在20并發(fā)下的響應(yīng)時(shí)間和錯(cuò)誤率如果p95超過(guò)2秒先調(diào)workers數(shù)量再檢查PostgreSQL的shared_buffers。第三關(guān)是版本升級(jí)演練把odoo鏡像tag從20升到下一個(gè)版本前先在測(cè)試環(huán)境完整跑一遍odoo-bin -u all -d odoo_tenant_001確認(rèn)模塊遷移沒(méi)有破壞性變更。6.2 用兩條命令把多租戶(hù)狀態(tài)納入日常巡檢日常巡檢不一定要上監(jiān)控系統(tǒng)兩條命令足夠發(fā)現(xiàn)90%的問(wèn)題。docker stats --no-stream看所有容器的CPU和內(nèi)存占用哪個(gè)租戶(hù)容器內(nèi)存持續(xù)飆到配額上限就該考慮拆分或升級(jí)套餐了。docker logs --since 30m saas_odoo | grep -E CRITICAL|ERROR看近半小時(shí)的應(yīng)用錯(cuò)誤日志Odoo的ERROR日志通常會(huì)帶租戶(hù)庫(kù)名能直接定位是哪個(gè)實(shí)例出了問(wèn)題。我第一次上線(xiàn)SaaS Kit時(shí)最怕的不是某個(gè)容器掛了而是備份恢復(fù)沒(méi)人演練過(guò)結(jié)果第一個(gè)月就有一個(gè)租戶(hù)誤刪數(shù)據(jù)靠pg_dump恢復(fù)到十分鐘前才意識(shí)到這套方案的設(shè)計(jì)核心從來(lái)不是容器編排多花哨而是數(shù)據(jù)兜底夠不夠穩(wěn)。后來(lái)我把備份恢復(fù)腳本掛進(jìn)cron每月自動(dòng)郵件通知演練結(jié)果再也沒(méi)有因?yàn)槿藶檎`操作失眠過(guò)。做多租戶(hù)Odoo先敬畏數(shù)據(jù)再追求效率希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取