Section sebelumnya menutup dengan pipeline yang menyalakan toko secara otomatis: CI membangun image, menjalankan test, memindai kerentanan, mendorong registry.example.com/toko/backend:1.6.0 ke registry, lalu menyalurkannya ke server lewat SSH dan menutup setiap deploy dengan smoke test — persis ritual yang dirakit Chapter Deployment Automation. Otomatisasi itu membuat rilis terasa tenang, tetapi otomatisasi tidak mengubah bentuk jalannya: seluruh stack toko — proxy, frontend, backend, db, cache — tetap hidup di satu mesin bernama srv-toko. Pipeline hanya mempercepat satu-satunya jalan yang ada, dan jalan itu lebarnya tepat satu host. Chapter ini menghadapi pertanyaan yang selama ini kita tunda: apa saja yang tidak bisa dilakukan Compose, mengapa batas-batas itu bersifat desain dan bukan kekurangan yang menunggu rilis berikutnya, dan bagaimana kita mengenali waktunya pindah tanpa terburu-buru melompat jauh.
Compose Bicara ke Satu Daemon #
Untuk memahami batas Compose, kita harus kembali ke arsitektur yang dibedah Chapter Arsitektur Docker: perintah docker compose hanyalah klien yang berbicara ke REST API sebuah daemon melalui socket. Compose membaca compose.yaml, mengirim permintaan pembuatan network, container, dan volume ke daemon itu, lalu selesai. Tidak ada komponen di dalam Compose yang mengerti konsep “mesin kedua” — model datanya memang hanya mengenal satu daemon. Nama service seperti backend dipecahkan oleh embedded DNS daemon itu sendiri, network berada di dalam kernel mesin itu, dan volume menempel di disk mesin itu; semuanya kita buktikan sendiri sepanjang Section Docker Compose dan Multi-Container Application.
Batas ini bukan kekurangan yang lupa ditutupi, melainkan keputusan desain. Compose didefinisikan sebagai alat untuk mendeklarasikan dan menjalankan aplikasi multi-container pada satu host, dan pada pekerjaan itu Compose sungguh unggul: satu berkas, satu perintah, perilaku yang sama dari laptop sampai VPS. Bahkan docker context atau DOCKER_HOST yang kita bahas di Chapter Memahami Docker Context memungkinkan CLI mengarah ke daemon di mesin jauh — tetapi klien itu tetap bicara ke tepat satu daemon pada satu saat. Mengganti mesin tujuan berarti memindahkan masalah, bukan menyelesaikannya.
Konsekuensinya pada toko kita bisa dirangkum dalam lima batasan fundamental:
| # | Batasan fundamental | Wujud pada stack toko |
|---|---|---|
| 1 | Satu host adalah satu titik kegagalan | srv-toko padam — listrik, kernel panic, maintenance penyedia — dan seluruh toko ikut gelap: proxy, backend, db, cache sekaligus |
| 2 | Skala hanya vertikal | menambah kapasitas berarti upgrade paket VPS ke RAM/CPU lebih besar, yang menuntut restart mesin; tidak ada mekanisme menambahkan mesin kedua ke dalam model |
| 3 | Tanpa reschedule saat node mati | restart policy dari Chapter Restart Policy hanya menghidupkan ulang container di mesin yang sama; bila mesinnya sendiri yang mati, tidak ada pihak yang memindahkan beban ke mesin lain |
| 4 | Rolling update disusun tangan | pola blue-green pada Chapter Update dan Rollback kita rakit sendiri dari tiga project Compose, alias berwarna, dan nginx -s reload — orchestrator punya pola ini sebagai fitur bawaan |
| 5 | Tanpa service mesh dan autoscaling | jumlah replika tetap sepanjang hari; tidak ada mekanisme yang menambah replika saat promo memuncak atau membatasi trafik antar service |
Lima baris tabel itu tidak berarti Compose gagal — kelima pekerjaan memang bukan ranahnya. Yang berubah adalah pertanyaan kita: apakah toko sudah sampai pada titik di mana kelima pekerjaan itu menjadi kebutuhan nyata.
Nuansa –scale #
Satu perintah sering diajukan sebagai “bukti Compose bisa menskalakan”: docker compose up -d --scale backend=3. Perintah itu memang berfungsi, tetapi hanya untuk service tanpa pemetaan port host — pembatasan yang kita alami sendiri di Chapter Service ketika replika kedua katalog-web-2 gugur dengan galat Bind for 0.0.0.0:8080 failed: port is already allocated. Satu pemetaan "8080:80" menyediakan tepat satu pintu host, sehingga hanya service internal — seperti backend toko yang mendengarkan 3000 tanpa ports — yang boleh direplikasi begitu. Pada toko, kebijakan “hanya proxy yang menerbitkan port” kebetulan membuat --scale backend=3 berhasil.
Tetapi ada nuansa yang lebih dalam dari sekadar port. Tiga replika backend di satu mesin berbagi CPU, RAM, dan kernel yang sama: kita menambah proses, bukan menambah kapasitas. Ketika beban puncak benar-benar melampaui kapasitas mesin, --scale hanya mempercepat kehabisan memori — dan itulah saat skala vertikal menemui langit-langitnya. --scale menyelesaikan masalah ketersediaan proses, bukan masalah ketersediaan mesin.
Kapan Compose Masih Cukup #
Kabar yang jarang disuarakan dengan jujur: banyak aplikasi produksi menjalankan Compose di satu mesin selama bertahun-tahun dan hidup dengan bahagia. Syaratnya bukan keberanian, melainkan kesesuaian — dan tabel berikut memetakan kesesuaian itu dalam dua kolom yang kita baca baris per baris:
| Compose masih cukup ketika | Waktunya pindah ketika |
|---|---|
| satu mesin sungguhan cukup — beban puncak masih jauh di bawah kapasitas, dan pertumbuhan teramati lambat | ketersediaan tinggi menuntut lebih dari satu node — downtime satu mesin tidak lagi bisa diterima |
| tim kecil, satu sampai tiga orang, yang memahami seluruh tumpukan | trafik melonjak berulang — promo mingguan yang menuntut replika ditambah dan dikurangi secara dinamis |
| kebutuhan berupa latihan, prototipe, atau belajar — feedback loop cepat lebih berharga daripada HA | pager menyala jam 3 pagi karena satu-satunya mesin adalah satu-satunya titik kegagalan |
| staging yang harus menyerupai produksi tetapi boleh mati tanpa drama | organisasi atau klien menuntut fitur yang hanya dimiliki orchestrator — autoscaling, penjadwalan lintas zona, dan sejenisnya |
Perhatikan bahwa kolom kiri bukan daftar alasan untuk bermalas-malasan. Compose di satu VPS dengan disiplin backup dari Chapter Backup dan Recovery, healthcheck dari Chapter Healthcheck dan Restart Policy, dan update yang teruji adalah arsitektur yang sah dan murah. Batas yang kita hormati di chapter ini adalah batas kebutuhan, bukan batas harga diri.
Harga Sebuah Orchestrator #
Sebelum kita terburu-buru memandang orchestrator sebagai kotak ajaib yang menghapus kelima batasan di atas, kejujuran menuntut satu paragraf penghitungan harga. Orchestrator adalah sistem operasi kecil untuk cluster: ia punya versi yang harus di-upgrade sendiri — men-drain node, menaikkan versi Engine, lalu mengembalikannya satu per satu tanpa menjatuhkan layanan — dan peningkatan cluster yang gagal jauh lebih rumit daripada apt upgrade di satu VPS. Ia juga membawa mode kegagalan baru yang tidak ada di dunia satu mesin: kuorum manajer yang hilang, partisi jaringan yang membelah cluster, dan jam yang tidak sinkron. Terakhir, dan paling sering dilupakan: cluster membutuhkan manusia yang mengerti cara kerjanya pada jam 3 pagi. “Siapa yang memegang pager” adalah pertanyaan desain sistem, bukan pertanyaan administratif.
Orkestrasi memindahkan kerja manual ke dalam mesin, tetapi tidak menghapusnya — kerja itu berubah wujud menjadi pemeliharaan cluster itu sendiri. Pertukannya sering kali sepadan, dan pada skala tertentu menjadi keharusan; yang tidak sehat adalah membeli harga penuh untuk masalah yang belum dimiliki. Justru karena harganya nyata, kita perlu memahami dulu pekerjaan apa yang sebenarnya dikerjakan seorang orchestrator — desired state, reconciliation, penjadwalan — sebelum memilih alatnya. Chapter Pengantar Container Orchestration membuka kotak itu dengan tiga VPS yang baru disewa Budi.
Referensi #
- Docker Compose — definisi resmi cakupan Compose sebagai alat aplikasi multi-container satu host.
- Docker Swarm mode — mode orchestration bawaan Engine yang menjadi langkah pertama melewati satu mesin.
- Compose Specification
— model aplikasi yang dibaca Compose dan, sebagian, oleh
docker stack deploy.