iT邦幫忙

2024 iThome 鐵人賽

DAY 2
0
Odoo

Odoo 部署策略系列 第 2

模組、整合與部署:三層 Git Repo 結構的設計思考

  • 分享至 

  • xImage
  •  

三層結構的思考

在啟動專案時,我的第一個步驟是設計適當的 Git repository 及文件結構,為文件結構和命名方式找到最佳方案,蠻愉悅的XXD。以下是我逐步形成三層結構的思考過程。

模組的獨立 Repository

首先,我決定每個模組都應該擁有自己的 repository。這個決定基於以下幾個原因:

  • 方便分叉(fork)與管理:獨立的 repo 讓我們可以更靈活地管理每個模組的版本控制和更新。
  • 降低耦合性:將模組分離,減少了彼此之間的依賴,提升了維護和擴充的便利性。
  • 清晰的文件結構:獨立的模組使文件結構更直觀,有助於新加入的開發者快速理解專案。

透過這種方式,每個模組都能被單獨開發、測試和部署,提升了專案的靈活性。

整合層 Repository:odooBundle-Codebase

在確立了模組的獨立性之後,我自然地想到需要一個整合的 repository,來統籌管理所有模組,這就是 odooBundle-Codebase。在這個 repo 中,我們將各種模組作為 submodule 引入,odoo 社群版本身也被視為一個 submodule。

這樣的設計帶來了以下優點:

  • 固定元件版本:我們可以明確地指定每個元件(包括各模組和 odoo 本身)的版本,確保系統的一致性。
  • 分支策略:透過建立 devprod 分支,我們可以在開發分支進行測試,確認無誤後再合併到生產分支,確保生產環境的穩定。
  • 整合管理:集中管理所有模組,使得部署和維護過程更為簡單。

這個整合的 repo 成為系統的核心代碼庫,連結了各個獨立的模組。

部署層 Repository:WebApp-Deployment

最後一定要有的是用於部署的 repository,我命名為 WebApp-Deployment。這個 repo 的主要功能是管理實際環境的部署設定,並且統籌多個 web 應用的運行。

這層的設計考量包括:

  • 引入 odooBundle-Codebase:我們將 odooBundle-Codebase 作為 submodule 引入,並分別初始化 dev 和 prod 分支,以對應開發和生產環境。
  • 主控的反向代理:由於管理多個 web 應用,我們需要一個主控的 Nginx reverse proxy 來處理多個域名的訪問。
  • 資料庫與管理工具:包括各自的資料庫(開發與生產環境)和可選的 pgAdmin,用於管理 PostgreSQL 資料庫。
  • 敏感資訊的管理:由於涉及實際部署,我們需要妥善管理各種憑證和密碼,例如 pgAdmin 的密碼、odoo 資料庫的密碼、反向代理的憑證等。我們會提供範例檔案幫助其他開發者,但確保真實的敏感資訊不會被提交到 Git 版本控制中。

透過這個部署層的 repo,我們可以:

  • 統一管理部署配置:集中處理所有部署相關的設定,提升管理效率。
  • 隔離敏感資訊:設計合適的文件結構,妥善保護敏感資料。
  • 多應用支援:除了 odoo,還可以管理其他 web 應用的部署。

經過上述的思考過程,最終形成了這個三層的 Git repository 結構


思考點:odoo 的 Dockerfile 該放在哪裡呢?

在設計 Git repository 結構時,最初我打算將 Dockerfile 放在 WebApp-Deployment 這個 repository 裡,因為它負責實際的環境部署,管理各個應用和容器。這樣做的好處是將部署相關的設定集中在一處,便於管理。而且雖然 odooBundle-Codebase 需要管理整合各種模組,但當時希望更精確地鎖定各個 Python 依賴套件的版本。為了達成這個目標,我考慮使用 Poetry 來管理。當時的想法是,如果使用 Poetry 來處理依賴關係,那麼 Dockerfile 就可以相對簡化,並與 odooBundle-Codebase 解耦。

但是,由於某些原因(之後的文章會詳細討論),我在前幾天決定暫時停用 Poetry,並且將依賴套件的控制移動回 Dockerfile。這讓我重新思考 Dockerfile 的放置位置。因為依賴關係是與原始碼密切相關的,將 Dockerfile 放在 odooBundle-Codebase 層級會更為合理。這樣,我們可以在同一個 repository 中管理代碼和依賴,確保整體的一致性。

最終,我決定將 Dockerfile 放在 odooBundle-Codebase 中,並透過 entrypoint.sh 等方式,將開發(dev)和生產(prod)環境所需的資訊以 Docker 參數的形式傳遞進去。這樣一來,我們既能夠保持代碼與依賴的緊密關聯,又能在部署時靈活地調整環境設定。


檔案結構參考

最後,我想分享一下目前的檔案結構,供大家參考。

odooBundle-codebase

odooBundle-codebase/
├── addons                  # 預計拿來放 submodule
├── check-db-status.py
├── docker-compose.yml      # 只是測試用
├── Dockerfile
├── entrypoint.sh
├── odoo                    # Odoo 社群版的 submodule
│   ├── ...
│   └── odoo-bin
└── tutorials               # 教學練習用,也類似 addons 資料夾,被加入 .gitignore
    ├── awesome_clicker
    ├── awesome_dashboard
    ├── awesome_gallery
    ├── awesome_kanban
    ├── awesome_owl
    ├── estate
    └── README.md

WebApp-Deployment

WebApp-Deployment/
├── config
│   ├── certs
│   ├── dev.env
│   ├── pgadmin.env
│   └── prod.env
├── config.example          # 範例配置檔,避免將真實憑證提交到 Git
│   ├── certs
│   ├── dev.env
│   ├── pgadmin.env
│   └── prod.env
├── docker-compose.yml
├── odoo-dev
│   ├── logs
│   ├── odoo.conf
│   └── source              # submodule: odooBundle-Codebase 的 dev 分支
├── odoo-prod
│   ├── logs
│   ├── odoo.conf
│   └── source              # submodule: odooBundle-Codebase 的 prod 分支
├── postgresql-admin
│   └── servers.json
└── reverse-proxy
    ├── conf.d
    ├── html
    └── nginx.conf

上一篇
odoo 部署前的策略思考:從環境設置到協作方式
下一篇
分析 odoo 官方安裝方法:從原始碼、套件管理或 Docker 安裝
系列文
Odoo 部署策略13
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言