Salah satu istilah yang langsung bikin saya berhenti pas pertama kali membaca saat training Carbonio adalah Carbonio Mesh. Awalnya saya pikir ini sekadar nama keren untuk salah satu service, tapi setelah saya pelajari lebih dalam, ternyata Mesh ini justru jadi salah satu komponen paling fundamental yang membedakan Carbonio dengan platform mail server lain yang biasa saya temui di artikel-artikel. Tulisan ini saya buat dari catatan saya sendiri selama mencerna materinya, semoga membantu teman-teman yang juga lagi belajar.

Pendahuluan

Sebelum membahas Mesh-nya, saya mau cerita dulu kenapa komponen ini ada. Carbonio itu sebenarnya bukan satu aplikasi raksasa, tapi kumpulan banyak komponen kecil yang saling ngobrol: ada Mailstore yang menyimpan email, ada MTA (Postfix) yang menerima dan mengirim email, ada Proxy (Nginx) yang jadi pintu depan, ada LDAP, ada PostgreSQL, dan masih banyak lagi. Pertanyaan sederhananya: bagaimana cara satu komponen tahu di mana komponen lain berada? Apalagi kalau instalasinya multi-server, di mana setiap komponen bisa duduk di mesin yang berbeda-beda.

Cara lama yang dipakai Zimbra dulu adalah dengan menyimpan informasi lokasi di LDAP secara statis. Cukup berfungsi, tapi kaku. Kalau ada komponen baru ditambahkan, kalau ada server yang pindah IP, atau kalau ada service yang tiba-tiba mati, sistem nggak punya cara dinamis untuk tahu. Di sinilah Carbonio Mesh masuk.

Apa Carbonio Services Mesh?

Di balik layar, Carbonio Mesh sebenarnya adalah HashiCorp Consul yang sudah di-bundle dan dikonfigurasi khusus oleh Zextras. Consul ini bukan teknologi baru, sudah dipakai di banyak perusahaan besar untuk arsitektur microservice. Yang Zextras lakukan adalah memanfaatkannya jadi “tulang punggung” komunikasi antar komponen Carbonio.

Fungsi Service Mesh

Setelah saya pelajari, ada tiga fungsi utama yang menurut saya paling penting untuk dipahami sebagai sysadmin:

1. Service discovery. Ini yang sudah saya ceritakan di atas — Mesh tahu di mana setiap service berada dan bisa ditanya kapan saja oleh komponen lain.
2. Health check. Mesh secara berkala mengecek apakah setiap service yang terdaftar masih hidup dan responsif. Kalau ada yang mati, Mesh akan menandainya sehingga komponen lain nggak akan kirim request ke service yang sudah tumbang.
3. Key-value store. Mesh juga berfungsi sebagai tempat menyimpan konfigurasi bersama yang bisa diakses semua komponen. Jadi semacam papan pengumuman terpusat.

Catatan

Ada satu detail yang ditekankan instruktur dan saya rasa worth diingat: kredensial Mesh disimpan terenkripsi di cluster-credentials.tar.gpg, dan password untuk mendekripsinya ada di /var/lib/service-discover/password, yang hanya bisa dibaca oleh user root. File ini krusial. Kalau file ini hilang atau rusak, banyak proses administrasi Carbonio (termasuk upgrade dan pending-setups) akan macet.

Satu insight lain: kalau suatu hari ada masalah aneh di Carbonio, misalnya MTA nggak bisa kirim email ke Mailstore padahal kedua service-nya jalan, selalu cek dulu apakah keduanya ter-register dengan benar di Mesh. Pelajaran ini sering disebut di training, dan saya kira ke depannya akan banyak terbukti sendiri waktu troubleshooting di lapangan.

Penutup

Buat saya yang sebelumnya cuma kenal Zimbra, Carbonio Mesh ini awalnya terasa seperti lapisan tambahan yang bikin sistem makin rumit. Tapi semakin saya pelajari, semakin saya sadar bahwa justru Mesh inilah yang bikin Carbonio jauh lebih siap untuk arsitektur modern. Seperti menjadi jembatan antar services.

Catatan ini masih akan terus saya update seiring saya menemukan hal baru di training. Kalau ada teman-teman yang punya pengalaman troubleshooting yang melibatkan Mesh, silahkan comment ya.