简介面向具备服务器管理与Odoo使用经验的技术人员本资源系统讲解如何通过Odoo SaaS Kit搭建基于Docker的多租户Odoo实例。内容覆盖工具箱的安装配置、必要文件夹与Nginx虚拟主机设置、Odoo基础镜像构建、SaaS订阅方案创建以及模块上传、备份恢复、日志查看、域名管理等日常运维要点便于企业快速部署多客户独立Odoo环境并实现自动化计费与资源分配。资源为1个PDF文档共3.99MB页面结构清晰、步骤明确适合需要结合Docker与PostgreSQL进行云化部署和运维排障的技术团队参考。目前已有140人学习下载对于正在规划SaaS化Odoo服务或需要降低多租户维护成本的企业IT人员是一份具备实操指导价值的中文参考资料。1. Odoo SaaS Kit用 Docker 把一套 Odoo 拆成几十个独立租户实例手头同时管十几个客户的 Odoo 是什么体验以前我每次接新项目都要手动建库、手写 Nginx 虚拟主机、逐个装模块客户一过十个就开始乱。Odoo SaaS Kit 就是专门处理这种多租户部署场景的工具——它基于 Docker 为每个客户创建独立的 Odoo 实例容器数据库、配置、文件存储、域名全部隔离再从 Odoo 后台统一创建、启停、计费。你可以把所有客户放在同一台服务器也可以把部分客户放到远程服务器实例和数据库模板之间通过订阅计划自动关联。这套东西适合具备 Docker、Nginx、PostgreSQL 基础的技术人员部署前需要先理解它的目录与权限设计而不是装完模块就点按钮。下面按我的拆解顺序把镜像构建、权限配置和实例生命周期一次讲透。2. 先立住基础镜像Docker 环境、Python 依赖与 uid/gid 对齐2.1 为什么多租户要走 Docker文件在宿主、进程在容器先理解这套工具的设计逻辑。odoo_saas_kit 的每个客户对应一个 Docker 容器容器里跑一份 Odoo数据隔离靠两层容器层隔离文件与进程PostgreSQL 层隔离数据库。真正灵活的是「宿主共享」——odoo.conf、odoo-server.conf、vhost 配置、通用模块、Filestore 文件都在宿主机上创建客户端时由模块动态挂载进容器。这样做的好处是目录和文件都在宿主机备份、替换模块、改配置都不需要进入容器完成。但这套设计带来一个致命约束共享文件夹的所有权必须一致。odoo 服务进程在容器内以某个 uid 运行宿主上的目录是宿主 odoo 用户假设 uid 是 1001所有只要容器内 uid 和宿主 uid 不一致容器进程读宿主文件时就会报 Permission denied客户端实例直接起不来。这就是后面所有权限操作的根因。先记住这句话主机与容器内的 Odoo 用户 uid 和 gid 必须一致不一致时所有客户端容器都会在你眼前翻车。2.2 三步构建基础镜像依赖、Dockerfile 与 id 对齐先在宿主机安装 Python 依赖。三个库各管一件事docker 让 Odoo 通过 Python API 控制 Docker 创建容器erppeek 是 Odoo 的 XML-RPC 管理客户端负责建库、建模板这类管理任务paramiko 用于连接远程服务器执行 SSH 操作。如果只在本机部署、暂不打算用远程容器paramiko 可以缓一步但后面要加远程服务器就必须补上。Docker 本身的安装不多说Ubuntu 上装 docker-ce 直接走官方文档装完确认docker run hello-world能跑通再做下面的事。pip3 install docker erppeek paramiko # 远程部署场景还需要 psycopg2装之前先装系统依赖 sudo apt install libpq-dev pip3 install psycopg2第一个命令是核心三件套第二个命令块是远程场景的配套。psycopg2 用于 Python 直连 PostgreSQL远程服务器那一侧也需要装上libpq-dev 是编译 psycopg2 时的依赖apt 源里都有直接装即可。装完依赖后进入包含 Dockerfile 的目录构建镜像。压缩包里已经带了 Dockerfile、entrypoint.sh、run_odoo.sh 这些文件你需要做的是检查和改参数不是从零写 Dockerfilecd {your_docker_file_path} # 镜像名建议带上 Odoo 版本号便于多个版本并存 docker build -t odoobywebkul:12.0 .命令末尾的点号不能丢它表示构建上下文是当前目录。镜像名按「名称:标签」格式来标签用 Odoo 大版本号例如 12.0、13.0这样后面 saas.conf 里 odoo_image 字段能一眼看出对应关系。构建前必须检查三件事。第一用grep odoo /etc/passwd确认宿主 Odoo 用户的 uid 和 gid然后在 Dockerfile 里把 USER 指令对应的 uid/gid 改成一致。第二Dockerfile 和它旁边的可执行文件entrypoint.sh、run_odoo.sh要 chown 给 Odoo 用户否则运行容器时权限链断开。第三进容器验证docker run --rm -it odoobywebkul:12.0 id输出里的 uid/gid 必须和宿主一致。这一步验证花两分钟能省掉后面整整一周的排障时间。2.3 远程服务器准备镜像迁移与 2375 端口的安全边界如果你打算把部分客户放在另一台服务器主服务器和远程服务器之间走的是 SSH Docker API 两条通道。先创建远程的 Odoo 系统用户核心约束是 uid/gid 必须和主服务器一致否则镜像打过去也会重演权限问题adduser --system --home /opt/{your_odoo_user} --shell /bin/bash \ --uid {odoo_user_uid} --gid {odoo_user_gid} {your_odoo_user} passwd {odoo_app_user}--system创建系统用户--uid和--gid要填主服务器上 Odoo 用户对应的 idpasswd是启用密码认证因为 paramiko 后面要拿这套账号做 SSH 登录。镜像迁移到远程有三种方式。小局域网直接用docker save导出 tar 包再到远程docker load导入有私有仓库或 Docker Hub 账号就 push/pull最次是用同一套 Dockerfile 在远程重新构建。注意重新构建同样要检查 uid/gid 是否和远程用户匹配。docker save命令如下docker save odoobywebkul:12.0 odoobywebkul_12.0.tar # 传到远程服务器后执行 docker load odoobywebkul_12.0.tar远程服务器真正敏感的是 Docker 守护进程。默认 dockerd 只监听本地 socket跨服务器控制需要让它监听 2375# 修改 /lib/systemd/system/docker.service 的 ExecStart 行 ExecStart/usr/bin/dockerd -H fd:// -H tcp://0.0.0.0:2375 systemctl daemon-reload service docker restart提示Docker 的 2375 端口没有内置认证暴露公网等于把服务器控制权交出去。生产环境务必用防火墙把来源限制到主服务器的内网 IP云服务器再配一层安全组两头都要挡住。2375 是整套部署里风险最高的端口我见过不止一个人裸奔上线。改完配置后在主服务器上先用docker -H tcp://{remote_ip}:2375 ps手动测连通性通了再继续配其他地方。docker 网络不通的排查顺序也固定先看远程ss -lntp | grep 2375确认监听再看防火墙规则最后看安全组别一上来就怀疑镜像有问题。3. 权限、路径与连接排查多租户部署最容易翻车的四个坑3.1 给 Odoo 用户开权限Docker 组、Nginx sudo、PostgreSQL 三件事模块安装好只是开始。要让它能「用 Docker 建容器、动态改 Nginx 虚拟主机、连 PostgreSQL 建库」必须给 Odoo 运行用户补齐三样权限。第一件是加入 docker 组usermod -a -G docker {your_odoo_user} grep docker /etc/group # 确认用户已出现在 docker 组里加入 docker 组后如果 Odoo 是以旧会话常驻运行的组权限不会自动生效必须重启 Odoo 服务或让用户重新登录。这是最常见的「明明加了组还是 permission denied」的原因别在这个坑里反复打转。第二件是允许 Odoo 用户免密控制 Nginx。odoo_saas_kit 在创建客户端时实时写入虚拟主机配置并 reload Nginx所以需要放开 sudoers 权限echo {your_odoo_user} ALL(ALL) NOPASSWD:/usr/sbin/nginx /etc/sudoers visudo -c # 校验语法避免把 sudoers 改坏NOPASSWD必须写否则 sudo 会卡在密码输入上脚本执行直接挂掉。只放开 nginx 这一个命令不要给ALL ALL权限收得越紧越好。第三件是让 Nginx 主配置读取动态生成的虚拟主机目录。模块把每个客户端的 vhost 文件放在 docker_vhosts 目录主配置里必须 include 它否则写再多配置文件 Nginx 也看不到# 在 nginx.conf 的 http 块里加一行 include /opt/odoo/Odoo-SAAS-Data/docker_vhosts/*.conf; nginx -t service nginx reloadnginx -t永远放在 reload 之前虚拟主机模板里有语法错误时 reload 会直接失败客户端域名全部挂掉。docker_vhosts 目录的属主也要是 Odoo 用户否则模块没有写权限。PostgreSQL 的放开是第四件事也是最容易被忽略的。容器内访问宿主 PostgreSQL 时来源 IP 是 Docker 网段 172.17.0.0/16默认 pg_hba.conf 只允许 local 连接容器连接必然被拒。需要在 pg_hba.conf 里加一行host all all 172.17.0.0/16 md5改完 reload PostgreSQL再从容器里测一次连接。注意 172.17.0.1 是 docker0 网桥地址不是 localhost很多人卡在这里是因为概念没转过来。3.2 saas.conf 五项路径一行不对客户端就建不起来所有目录与镜像配置最终落在odoo_saas_kit/models/lib/saas.conf一共五条每条都直接决定客户端创建能否成功配置项作用示例值nginx_vhosts动态生成的 Nginx 虚拟主机存放路径/opt/odoo/Odoo-SAAS-Data/docker_vhosts/odoo_saas_data所有客户端配置与数据目录的根路径/opt/odoo/Odoo-SAAS-Data/common_addons所有客户端与模板共享的插件目录/opt/odoo/common_addonsodoo_image创建容器时使用的镜像名与标签odoobywebkul:12.0template_odoo_port模板容器占用的端口8888common_addons 这条值得多说一句它会在每个客户端容器创建时作为插件路径挂载进去放在这里的模块对所有客户端和模板都可见适合放基础模块和公共依赖。某个客户专属的模块不要放这里应该放到该客户容器自己的>docker ps -a --format table {{.Names}}\t{{.Status}} | grep saas docker restart {client_container_name} docker stop {client_container_name}容器名一般就是客户端域名去掉 http/https 后的字符串。建议用命令行管理容器启停界面按钮留给非技术同事操作。停止实例不会删数据容器停了数据库和文件都还在。要彻底下线需要删掉客户端记录并手动docker rm容器——模块不会自动帮你删容器这条必须写进运维清单否则创建又删除的客户端多了宿主机磁盘会被残留容器和悬空数据占满。5. 固化运维动作日志、主密码、备份与验收5.1 四条高频命令日志几乎每天都在查。客户端实例的日志在容器内部一条命令就能跟进去看docker exec -it {client_container_name} bash -c tail -f /var/log/odoo/odoo-server.log主密码不是统一的。每个客户端有自己的 odoo-server.conf里面的 admin_passwd 才是该实例的管理员主密码位置在Odoo-SAAS-Data/{client_container_name}/odoo-server.conf。新实例默认继承 saas.conf 里的缺省主密码但运营中通常会给不同客户改不同密码所以别记「一套密码通杀」直接去对应文件里查最稳。5.2 备份恢复与上线前验收备份分三块数据库用 pg_dump 导出目标库文件存储Filestore在客户端数据目录下直接打包镜像里的源代码不用备份Dockerfile 随时能重建。最省事的做法是写一个脚本每天执行 pg_dump rsync 数据目录到另一台机器恢复时先建库、再覆盖 Filestore、最后重启容器。正式卖客户之前我强烈建议按最小链路完整走一遍建一个测试计划创建数据库模板创建一个测试客户端走完激活、登录、模块安装验证然后停止并删除客户端再手动docker rm容器。这个流程全部跑通再上线能避开大部分线上事故。从那以后我每次接新环境都强制按这套顺序过一遍验证 uid/gid、测试 2375 连通性、确认 pg_hba.conf 的 CIDR一步不跳。这套东西表面上是模块部署实际上是在验证整个宿主机的权限链路权限链路没问题剩下的都是点按钮的事。希望帮到你。本文还有配套的精品资源点击获取