Budi menyewa tiga VPS kecil dan menamainya manager-01 (192.168.1.10), worker-01 (192.168.1.11), dan worker-02 (192.168.1.12), semuanya menjalankan Docker Engine 29.9.0 yang segar dari repositori resmi. Motivasinya sederhana: insiden maintenance penyedia VPS yang memadamkan srv-toko selama empat puluh menit pada jam belanja ramai, ditambah tabel lima batasan di chapter sebelumnya. Rencananya pun terdengar sederhana — jalankan container di beberapa mesin sekaligus sehingga satu mesin mati tidak lagi memadamkan toko. Tetapi begitu Budi mencoba memindahkan sebagian stack dengan tangan, tiga tembok menyambutnya dalam satu sore. Chapter ini membedah tembok-tembok itu, lalu memperkenalkan pekerjaan yang lahir untuk meruntuhkannya: container orchestration.

Masalah Skala Banyak Node #

Tembok pertama adalah DNS. Nama backend dan db bekerja manis di srv-toko karena embedded DNS daemon — resolver 127.0.0.11 yang kita bedah di Chapter Container DNS — hanya hidup di dalam network yang diciptakan satu daemon pada satu mesin. Begitu Budi menjalankan backend di worker-01, container itu sama sekali tidak mengerti nama db yang hidup di mesin lain; resolusi lintas host tidak pernah menjadi bagian dari model network Docker satu daemon. Solusi tempelannya jujur dan buruk sekaligus: mengetik alamat IP mentah ke dalam environment variable.

Tembok kedua adalah pembukuan manual. Dengan IP yang tersebar di tiga mesin, “daftar server” berpindah ke catatan pribadi Budi — 192.168.1.10 untuk db, 192.168.1.11 dan 192.168.1.12 untuk backend, tulisannya yang harus dijinglok ke setiap konfigurasi. Tembok ketiga adalah kegagalan pada jam yang buruk. Ketika worker-01 tumbang pukul dua pagi, tidak ada satu pun komponen yang memindahkan container-nya ke mesin lain; yang tersisa adalah Budi, SSH, dan runbook yang ditulis dengan huruf miring harapan. Tiga tembok ini — penemuan, pembukuan, dan pemulihan — bukan masalah Docker yang cacat, melainkan pekerjaan baru yang muncul begitu aplikasi melampaui satu mesin.

Enam Pekerjaan Seorang Orchestrator #

Orchestrator adalah sistem yang mengambil alih enam pekerjaan yang selama ini kita kerjakan dengan tangan. Tabel berikut memetakan setiap pekerjaan ke wujud manualnya pada perjalanan kita sejauh ini:

Pekerjaan orchestratorWujud manual kita sejauh ini
Scheduling — memilih node untuk setiap containerkita memilih mesin, SSH ke sana, dan menjalankan docker run atau docker compose up sendiri
Scaling — menambah dan mengurangi replikadocker compose up -d --scale backend=3 dijalankan manusia saat ingat (dan hanya untuk service internal)
Self-healing — restart di mesin yang sama, atau menjadwalkan ulang di node lain bila node matirestart policy dari Chapter Restart Policy hanya menghidupkan ulang di mesin yang sama; node mati berarti runbook manual
Service discovery dan load balancing — satu nama untuk banyak replika di banyak nodeembedded DNS dan network alias dari Chapter Service Discovery, yang berhenti di batas satu daemon
Rolling update — mengganti versi selang-seling tanpa downtimepola blue-green tiga project yang kita rakit tangan di Chapter Update dan Rollback
Distribusi config dan secret — konfigurasi dan kredensial hadir di node yang tepat.env dan compose secrets disalin dan dijaga per mesin, dengan disiplin Chapter Secret Management

Enam baris itu bisa dirangkum dalam satu kalimat: orchestrator mengubah keputusan operasional dari kalimat perintah menjadi kalimat keadaan. Dan untuk menjalankan enam pekerjaan itu, cluster membutuhkan struktur kekuasaan.

Manager, Worker, dan Control Plane #

Cluster orchestrator selalu berbentuk dua peran. Node manager membentuk control plane — otak yang menyimpan keadaan cluster, menerima deklarasi dari operator, dan memutuskan penempatan container. Node worker hanya menerima perintah dan menjalankan container; worker tidak tahu apa-apa tentang keputusan. Kita sudah mengintip pembagian ini pada Chapter Resource di Swarm: penjadwal yang menghitung sisa kapasitas tiap node hidup di sisi manager.

Kekuasaan manager dijaga oleh mekanisme quorum: keputusan cluster sah hanya bila mayoritas manager menyetujuinya, sehingga jumlah manager dianjurkan ganjil — tiga manager toleran satu kegagalan, lima toleran dua. Angka ganjil bukan takhayul: dua manager toleran nol kegagalan, karena satu manager mati meninggalkan satu berbanding satu dan mayoritas tidak tercapai; cluster dengan dua manager justru lebih rapuh daripada cluster satu manager yang paling tidak masih bisa mengambil keputusan sendirian. Cluster latihan kita hari ini hanya punya satu manager di manager-01 — cukup untuk belajar, dan kita akan jujur soal risikonya saat membangunnya.

Desired State dan Reconciliation Loop #

Inti seluruh orchestration adalah satu pola: desired state dan reconciliation loop. Alih-alih memerintah “jalankan container ini di mesin itu”, operator mendeklarasikan keadaan yang diinginkan — “service web berjumlah 3 replika” — dan sistem terus-menerus membandingkan keadaan aktual dengan keadaan yang diinginkan, lalu bertindak atas selisihnya. Loop perbandingan itu tidak pernah berhenti; keadaan baru dibaca setiap beberapa detik:

Mari kita telaah tiga cabang diagram tersebut:

  1. Cabang diam — aktual 3 dari 3: tidak ada tindakan; loop hanya memeriksa ulang. Kondisi inilah yang kita lihat sebagai status 3/3 pada keluaran service nanti.
  2. Cabang kurang — aktual 2 dari 3: loop mencari node yang muat, menjadwalkan replika pengganti, dan menunggunya hidup sebelum kembali memeriksa.
  3. Cabang lebih — aktual 5 dari 3: loop memilih replika yang dihentikan supaya keadaan kembali ke angka yang dideklarasikan.

Tiga skenario toko membuat pola ini terasa hidup. Saat worker-01 mati, replikanya hilang dari pembukuan aktual — loop melihat 2/3 dan menjadwalkan replika pengganti di node yang tersisa tanpa membangunkan siapa pun. Saat promo datang, Siti cukup mengubah deklarasi menjadi 6 replika — loop yang menyebar ke enam task. Saat maintenance, Budi menandai satu node agar dikosongkan — loop memindahkan task-tasknya ke node lain sebelum mesin dimatikan. Ketiganya adalah satu mekanisme yang sama, bukan tiga fitur berbeda.

Peta Ekosistem #

Sisa pertanyaannya tinggal memilih wujud. Tiga nama mengisi peta orchestrator yang relevan untuk kita:

PlatformPosisi di ekosistem
Docker Swarmmode cluster bawaan Docker Engine — tidak ada perangkat lunak baru yang dipasang, pas untuk cluster Docker kecil sampai menengah
Kubernetesstandar industri paling luas — lulusan CNCF dengan ekosistem add-on terbesar, menjadi bahasa bersama lintas perusahaan dan penyedia cloud
Nomadalternatif dari HashiCorp — satu biner yang ringan untuk dijalankan dan mampu mengorkestrasi beban di luar container juga

Untuk perjalanan kita, Swarm adalah pintu masuk yang paling murah: cluster bisa berdiri dalam dua perintah di atas Engine yang sudah terpasang di tiga VPS Budi. Chapter Docker Swarm membangun cluster itu sungguhan — token, node, service, dan stack toko di atasnya.

Referensi #