Env Vars Masuk Container, Koneksi Belum Otomatis
Nambah env var di Compose itu baru setengah jalan; container tetap butuh jalur network yang sadar ke host sebelum fitur LLM search bisa jalan.
Commit-nya kecil banget. Satu file: docker-compose.yml. Isinya nambah tiga env var ke service api. Ada API_NINEROUTER_BASE_URL, API_NINEROUTER_API_KEY, dan API_SEARCH_LLM_MODEL. Semuanya pakai interpolasi Compose dengan default kosong, jadi kalo environment deployment nggak ngasih nilai, container tetap jalan tapi dapet string kosong.
Komentar di diff-nya jelas: kalo env kosong, fitur LLM smart search mati dan pencarian FULLTEXT murni tetap jalan. Angka emang nggak berubah, cuma wiring konfigurasi. Tapi justru commit sekecil ini yang bikin saya berhenti sebentar.
Pass env beda masalah dengan nyambung
Dugaan pertama saya salah. Di kepala saya: env udah diteruskan ke container, berarti begitu service api butuh router LLM yang jalan di host yang sama, ya tinggal pakai. Selesai.
Ternyata nggak. Meneruskan nilai dan punya jalur network itu dua hal yang beda total. Compose cuma tugasnya bikin variabel itu muncul di dalam container. Container sendiri punya network namespace terpisah, jadi yang disebut loopback di dalam sana nunjuk ke dirinya sendiri, bukan ke host. Request ke router LLM yang jalan di host bisa jadi nyangkut, bukan karena env-nya salah, tapi karena jalurnya nggak ada.
Sadar ini rasanya agak ngeselin. Commit-nya udah merge, env-nya udah masuk, tapi fitur tetap aja mati dengan cara yang sama kayak sebelum env ada. Dari luar nggak ada error yang nyuruh saya mikir soal network, jadi kesimpulan gampang salah: nilainya yang keliru, padahal jalurnya yang belum ada.
Jalur ke host harus dibikin sadar
Untung polanya standar. Docker punya nilai khusus host-gateway yang bisa dipasang lewat add-host untuk mengarah ke alamat internal host [1]. Di sisi Compose, extra_hosts nambahin mapping hostname itu ke konfigurasi network container, dan di Linux mapping-nya mendarat di file hosts milik container [2].
Tapi itu baru separuh cerita. Sisi host juga harus nurut. Uvicorn defaultnya bind ke alamat loopback, yang artinya service di host cuma denger koneksi dari dirinya sendiri [3]. Kalo router LLM jalan dengan default itu, container di bridge mana pun nggak bakal bisa nyampe, sebagus apapun mapping hostname-nya. Bind-nya harus disetel secara sadar ke interface yang bisa dijangkau dari network container.
Soal network-nya sendiri, container tanpa opsi network masuk ke default bridge [4]. Docker Desktop lebih ramah lagi: dia nyediain hostname siap pakai kayak host.docker.internal dan gateway.docker.internal untuk ngelabeli host dan gateway VM-nya [5].
Saya nggak nulis nomor alamat di sini sengaja. Gateway network bisa beda antar mesin, dan contoh publik juga pakai hostname dengan placeholder, bukan alamat nyata. Nge-hardcode alamat di compose artinya bikin config yang cuma bener di laptop saya.
Kenapa default kosong lebih jujur
Keputusan yang saya ambil: pola env default kosong itu tetap dipertahankan, dan menurut saya ini pola yang lebih jujur daripada ngisi env dengan nilai "asal ada".
Env kosong itu pernyataan yang gampang dibaca: fitur LLM smart search nggak dikonfigurasi, fallback fulltext pegang kendali, selesai. Nggak ada kemungkinan setengah jalan. Bandingkan dengan env bohong, misalnya base URL yang diisi tapi service-nya nggak dijangkau dari container. Fitur keliatan nyala, terus tiap request gagal dengan error yang bikin orang debugging ke arah yang salah. Arahnya ke network, padahal itu justru bagian yang emang harus diselesaikan terpisah.
Sisanya soal kebersihan. Nama env disebut di compose, tapi nilainya nggak. Nilai yang nyata cuma datang dari environment deployment, yang di VPS saya kelola lewat strategi branch main, staging, dan api. Itu berarti API key nggak pernah nongol di git history, dan laptop developer lain bisa clone repo tanpa bawa-bawa secret orang lain.
Yang saya sadari setelah commit kecil ini: config itu baru setengah jalan menuju fitur. Sisa jalannya soal network, dan dua-duanya harus dicek sendiri-sendiri. Commit berikutnya kalau ada yang bilang "env udah masuk kok", saya bakal tanya satu hal dulu: container-nya bisa nyampe nggak ke service-nya.