Kembali ke Blog Back to Blog
odoodockerpersonal

Setup Odoo 17/18/19 Barengan di Satu Mesin, dan Kenapa Akhirnya Nggak Pakai Docker

· 3 min read ID

Butuh tiga versi Odoo jalan barengan di satu mesin, buat testing dan bikin custom addon. 17, 18, 19. Community dan Enterprise.

Rencana awal Docker. Berakhirnya native install. Ini catatan kenapa, plus beberapa hal teknis lain yang nyangkut di jalan.


Postgres-nya satu, sharing.

Tiap versi Odoo butuh Postgres minimum yang beda-beda, 17 dan 18 minimal 12, 19 minimal 13. Daripada tiga instance Postgres terpisah, saya pakai satu instance Postgres 16 buat semuanya. Cukup buat kebutuhan dev.

Tiap versi bikin database sendiri di server yang sama. Nggak perlu container terpisah per versi.

Semua ini akhirnya dibungkus jadi satu workspace VSCode. Tiap versi udah ada venv-nya, config-nya, addons-nya, tinggal buka folder dan jalanin, nggak perlu setup ulang dari nol tiap kali butuh versi tertentu buat testing atau bikin addon.


Docker awalnya masuk akal. Ternyata nggak.

Alasan pilih Docker awalnya jelas, isolasi bersih antar versi tanpa bentrok dependency Python, setup cepat, tinggal mount folder addons ke /mnt/extra-addons plus flag --dev=reload biar kode Python auto-reload.

Tapi docker compose pull mogok. Bukan lambat, bener-bener nggak jalan, 20 menit 0% image tersimpan. Koneksi ke registry Docker Hub hidup, tapi pola aneh, bytes terkirim jauh lebih besar dari bytes diterima. Bukan packet loss biasa, kemungkinan ada yang motong response di tengah jalan.

Sempat coba matiin IPv6 (sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1), karena awalnya curiga IPv6 blackhole ke Docker Hub. Itu benerin masalah lain, tapi pull tetap macet.

Akhirnya pivot ke native install. Alasannya dua. Satu, network di mesin ini emang flaky ke banyak layanan, git HTTP/2 disconnect, DNS timeout, tapi tarball via python3 -m urllib.request jalan. Dua, alasan awal pilih Docker, isolasi dependency, ternyata sudah didapat cukup dari venv per versi. Docker jadi lapisan ekstra yang nggak nambah nilai kalau tiga versi ini jarang jalan bersamaan penuh.


Naming convention yang nyelametin dari database campur aduk.

Enam instance target, CE dan EE untuk tiap versi, semua nyambung ke Postgres yang sama. Tanpa filter, semua instance bakal lihat semua database di server.

Skema port, angka versi di puluhan-satuan, edisi di ratusan. CE di 80xx, EE di 81xx.

VersiCEEE
1780178117
1880188118
1980198119

Nama database dikasih prefix versi+edisi, 17ce-projectA, 18ee-clientX. Tiap conf punya filter yang cuma nunjukin database dengan prefix-nya sendiri.


Satu huruf underscore bikin filter itu nggak jalan sama sekali.

Saya tulis db_filter di semua file conf. Salah. Key yang bener dbfilter, tanpa underscore.

Odoo nggak nolak key yang salah. Dia cuma nyimpen apa adanya tanpa diparse, lempar warning di log yang gampang kelewat, unknown option 'db_filter' ... option stored as-is, without parsing. Efeknya, halaman pilih database nunjukin semua database di server, bukan cuma yang versi itu. Isolasi yang saya kira sudah jalan, ternyata dari awal nggak pernah aktif.

Sejak itu, tiap kali ada opsi conf yang kelihatannya nggak ngefek, cek dulu log startup buat baris unknown option. Itu tandanya.


Tiga versi CE sekarang jalan verified, database test di masing-masing, login sukses. EE baru satu yang beres, 19, pakai source legit yang sudah ada. 17 dan 18 EE nunggu source yang sama.

Pelajaran paling nempel, bukan soal Docker vs native yang menang. Soal jangan percaya konfigurasi cuma karena nggak ada error keras. Kadang yang paling bahaya itu yang diem-diem gagal.