Belajar Docker - Clustering & Orchestration dengan Docker Swarm Mode

#Pendahuluan

Setelah di episode 15 sebelumnya kita membangun observability — logging driver yang ter-rotate, HEALTHCHECK, metrics, dan stack cAdvisor + Prometheus + Grafana — kalian kini bisa melihat satu node secara utuh. Namun ada batas yang tidak bisa dilompati oleh monitoring: satu node tetaplah satu titik kegagalan. Begitu aplikasi tumbuh melampaui kapasitas satu server, atau satu server mati dan semua kontainer di dalamnya ikut mati, kita butuh sesuatu yang lebih besar: sekelompok server yang bekerja sebagai satu kesatuan — dan inilah esensi orchestration.

Bayangkan single host seperti satu rumah yang menampung semua anggota keluarga. Praktis selama keluarga kecil. Tapi ketika anggota bertambah, satu rumah tidak lagi cukup: butuh kompleks perumahan dengan banyak rumah, pengelola yang menetapkan siapa tinggal di rumah mana, dan aturan bahwa jika satu rumah rusak, penghuninya pindah ke rumah lain. Orkestrator adalah pengelola kompleks itu, dan Docker Swarm Mode adalah pengelola yang sudah tertanam di dalam Docker Engine — tanpa instalasi tambahan.

Kenapa topik ini penting untuk kalian kuasai? Karena skala adalah arah yang tak terhindarkan: staging yang tadinya satu node, mulai butuh dua, lalu lima. Memahami Swarm memberi kalian mental model cluster dan orkestrasi yang juga berlaku untuk Kubernetes (kita bahas perbandingannya sebentar lagi), dan — yang lebih praktis — Swarm adalah cara termurah dan paling sederhana untuk membawa Docker ke banyak host tanpa membangun platform sendiri. Di episode ini kita akan membedah apa itu Swarm Mode, kapan memilihnya dibanding Kubernetes, membongkar arsitektur manager/worker, lalu mempraktikkan inisialisasi cluster, join token, dan pengelolaan node secara lengkap.

#Pembahasan Utama

#Apa Itu Swarm Mode — dan Mengapa "Sudah Bawaan" Itu Penting

Swarm Mode adalah mode operasi bawaan Docker Engine untuk clustering dan orkestrasi. Begitu kalian mengetik docker swarm init di sebuah node, node itu tidak lagi bekerja sendirian — ia menjadi bagian dari sebuah swarm (gerombolan/kelompok), dan semua node yang bergabung bisa menjalankan dan mengelola kontainer secara kolektif.

Frasa "sudah bawaan" bukan sekadar soal praktis tanpa instalasi. Ia berarti tidak ada komponen tambahan yang harus dijaga: tidak ada server API terpisah, tidak ada database state tambahan, tidak ada agent eksternal. Seluruh kontrol-plane — komponen yang membuat keputusan tentang apa yang berjalan di mana — hidup di dalam daemon Docker itu sendiri. Bagi tim yang tidak ingin membangun platform orkestrasi besar, ini adalah kemewahan: fitur production-grade (service, rolling update, secrets, load balancing multi-host) tersedia hanya dengan mengaktifkan mode yang sudah ada di depan mata.

Kapan Swarm dan kapan Kubernetes? Ini bukan pertanyaan "yang mana lebih hebat", melainkan "mana yang cocok untuk beban kerja kalian":

Mental model yang berguna: Swarm adalah orkestrasi yang berjalan "di pinggir" Docker — kamu tetap menulis hal-hal yang kamu tahu (service, network, volume) dengan sintaks yang familier. Kubernetes adalah platform tersendiri dengan filosofi dan toolingnya sendiri. Banyak tim mulai dari Swarm untuk kebutuhan dasar, lalu naik ke Kubernetes ketika butuh fitur yang tidak bisa ditambal. Memahami Swarm dulu membuat transisi ke Kubernetes jauh lebih mulus karena konsep dasarnya sama: desclared state, scheduler, dan worker.

#Arsitektur: Manager, Worker, dan Raft Consensus

Sebuah swarm terdiri dari dua jenis node:

Manager Nodes adalah otak cluster. Mereka menjalankan Raft consensus untuk menyimpan state cluster (service apa saja, replicanya berapa, di node mana ia berjalan), menjadwalkan task ke worker, dan melayani API. Setiap keputusan penting — node bergabung, service dibuat, task ditetapkan — dicatat dalam state store yang disinkronkan antar manager.

Worker Nodes adalah otot cluster. Mereka tidak mengambil keputusan; mereka cukup menjalankan task (unit kerja berupa container) yang ditugaskan manager. Sebuah node bisa menjadi manager sekaligus menjalankan task — di cluster kecil ini justru umum.

Keputusan desain terpenting ada pada Raft consensus. Raft adalah algoritma yang memastikan semua manager sepakat pada state yang sama, bahkan jika sebagian manager mati. Kuncinya adalah quorum — mayoritas manager harus hidup dan setuju agar cluster terus mengambil keputusan:

• Dengan 1 manager: tidak ada toleransi — manager mati = cluster kehilangan kendali (worker tetap menjalankan task yang sudah berjalan, tapi tidak ada lagi penjadwalan/perubahan).
• Dengan 3 manager: toleransi 1 node mati — ini minimum yang disarankan untuk HA (High Availability).
• Dengan 5 manager: toleransi 2 node mati.

Aturan praktis: jumlah manager harus ganjil. 2 manager memberi toleransi yang sama dengan 1 (butuh 2 dari 2 untuk quorum) — jadi lebih baik 3 atau 1. Raft seperti rapat dewan yang hanya sah bila mayoritas hadir: dewan 3 orang boleh lanjut jika 1 orang tidak hadir, dewan 2 orang tidak bisa lanjut tanpa keduanya.

#Inisialisasi Cluster: docker swarm init

Semua dimulai dari satu perintah di node yang akan menjadi manager pertama. Flag --advertise-addr memberi tahu node lain alamat mana yang dipakai untuk menghubungi manager ini — wajib diisi di environment multi-interface atau cloud:

docker swarm init --advertise-addr 10.0.0.11

Swarm initialized: current node (abcd12ef34gh) is now a manager.
 
To add a worker to this swarm, run the following command:
 
    docker swarm join --token SWMTKN-1-xxxx... 10.0.0.11:2377
 
To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.

Perhatikan dua hal dalam output: perintah join sudah disediakan, dan ada dua jalur — untuk worker dan untuk manager. Token yang tampak itu adalah rahasia (akan kita bahas di bagian keamanan). Node-1 sekarang adalah manager tunggal: boleh saja, tapi ingat cerita quorum tadi — untuk produksi, targetkan 3 manager.

#Menambahkan Node: Token Join

Untuk menambahkan worker di node-2 (IP 10.0.0.12), jalankan perintah join yang dihasilkan tadi. Untuk menambahkan manager kedua, minta token manager dari node yang sudah menjadi manager:

docker swarm join-token worker
docker swarm join-token manager

docker swarm join --token SWMTKN-1-xxxx... 10.0.0.11:2377

This node joined a swarm as a worker.

Perintah join yang sama digunakan untuk menambah manager — cukup dengan token manager. Alur eksekusinya: node baru menghubungi manager yang ada di IP:2377, membuktikan kepemilikan token, lalu node baru me-resync state cluster dari manager (Raft). Inilah kenapa port 2377 wajib terbuka antar node — kita bahas daftar portnya di bagian akhir.

#Memeriksa Cluster: docker node ls

Dari salah satu manager, lihat seluruh node dan perannya:

docker node ls

ID                            HOSTNAME   STATUS    AVAILABILITY   MANAGER STATUS   ENGINE VERSION
abcd12ef34gh *                node-1     Ready     Active         Leader           27.1.1
ijkl56mn78op                  node-2     Ready     Active         Reachable        27.1.1
qrst90uv12wx                  node-3     Ready     Active         Reachable        27.1.1
yzas12bc34de                  node-4     Ready     Active                           27.1.1

Kolum MANAGER STATUS menandai peran: Leader (manager yang memimpin Raft saat ini), Reachable (manager lain yang ikut quorum), dan kosong berarti worker. Kolom AVAILABILITY (Active/Drain/Pause) mengontrol apakah node menerima task baru.

#Manajemen Node: Promote, Demote, Drain

Node tidak permanen — perannya dan kesediaannya bisa diubah:

docker node promote node-4

docker node demote node-3

Drain adalah mode paling penting untuk maintenance: ia membuat node berhenti menerima task baru dan memindahkan task yang berjalan ke node lain — persis cara melakukan maintenance server tanpa downtime service:

docker node update --availability drain node-2
# ... maintenance selesai, kembalikan node ke layanan
docker node update --availability active node-2

docker node update --availability pause adalah varian yang lebih lembut: node berhenti menerima task baru tapi task lama tetap berjalan — berguna saat kalian ingin "membekukan" node tanpa mengganggu container yang sedang jalan. Pahami urutan pemakaiannya: drain untuk maintenance penuh, pause untuk menahan sementara, active untuk mengaktifkan kembali.

#Keamanan Control-Plane: TLS dan Token

Swarm mengamankan komunikasi antar node dengan TLS otomatis. Setiap node mendapat sertifikat yang ditandatangani oleh CA internal swarm, dan sertifikat itu berotasi setiap 90 hari secara otomatis. Artinya: semua traffic antara manager dan worker — termasuk rahasia service — terenkripsi dalam perjalanan, tanpa konfigurasi tambahan. Ini lapisan yang sering luput disebut saat orang memuji "kesederhanaan" Swarm: keamanan transport yang di Kubernetes butuh setup ekstra, di Swarm sudah menyala sejak join pertama.

Dua token join (worker dan manager) adalah kunci akses cluster. Token manager tentu lebih sensitif daripada token worker — memegang token manager berarti bisa ikut memimpin cluster. Rotasi secara berkala dan revoke node yang tidak lagi dipercaya (docker node rm <id>) adalah dua kebiasaan yang wajib ada di checklist produksi.

#Port yang Harus Dibuka antar Node

Networking adalah alasan paling umum "swarm jalan di satu node tapi tidak di banyak node". Tiga port berikut harus bisa dijangkau antar semua node di cluster:

#Perintah Perbandingan: Setup Cluster Step-by-Step

Rangkuman urutan setup cluster dalam satu code-group — dari node pertama hingga node keempat:

# Node-1 (manager Leader)
sudo ufw allow 2377/tcp && sudo ufw allow 7946/tcp && sudo ufw allow 7946/udp && sudo ufw allow 4789/udp
docker swarm init --advertise-addr 10.0.0.11

# Node-2 & Node-3 (workers) — token diambil dari output init
docker swarm join --token SWMTKN-1-xxxx... 10.0.0.11:2377

# Jadikan node-2 manager kedua agar ada 2 manager (budget HA)
docker node promote node-2
docker node ls

Dengan dua manager, quorum Raft bisa bertahan jika satu mati — tapi ingat aturan ganjil: untuk HA sungguhan targetkan 3 manager.

#Pitfalls Setup Swarm

1. Jumlah manager genap. Dua manager memberi toleransi yang sama dengan satu. Gunakan 1 (dev) atau 3 (produksi HA) — bukan 2.
2. --advertise-addr salah atau diabaikan. Di host dengan banyak interface atau cloud NAT, tanpa flag ini node bisa mengiklankan alamat yang tidak bisa dijangkau node lain. Selalu set eksplisit.
3. Port 4789/7946 terblokir. Gejalanya: node Ready tapi traffic overlay macet, atau container lintas node tidak bisa saling bicara. Periksa firewall cloud terlebih dahulu.
4. Token tersebar ke mana-mana. Token join adalah rahasia. Rotasi berkala dan docker node rm untuk node pensiun adalah kebiasaan wajib.
5. Menyimpan state di worker tanpa drain saat maintenance. Selalu drain sebelum server dimatikan untuk maintenance, agar task berpindah dan service tidak terganggu.

#Penutup

Pada episode 16 ini kita telah menyatukan beberapa server menjadi satu cluster: memahami bahwa Swarm Mode adalah orkestrasi bawaan Docker dengan trade-off kompleksitas yang jauh lebih rendah daripada Kubernetes, membedah arsitektur manager (otak: Raft consensus, state store, scheduler) dan worker (otot: menjalankan task), mempelajari bahwa quorum menuntut jumlah manager ganjil dengan minimum 3 untuk HA, menginisialisasi cluster dengan docker swarm init --advertise-addr, menambahkan node dengan docker swarm join --token, mengelola peran lewat promote/demote/drain, memahami enkripsi TLS otomatis, dan mengamankan komunikasi dengan membuka port 2377/7946/4789.

Inti yang harus kalian bawa:

• Swarm = orkestrasi built-in; Kubernetes untuk skala dan ekosistem, Swarm untuk kesederhanaan dan kecepatan.
• Manager mengambil keputusan via Raft; butuh quorum mayoritas — selalu ganjil, minimal 3 untuk HA.
• Join butuh token (rahasia) ke IP:2377; TLS antar node otomatis terenkripsi.
• drain untuk maintenance tanpa downtime; promote/demote untuk mengubah peran node.
• Port 2377/tcp, 7946/tcp+udp, 4789/udp wajib terbuka antar node.

Cluster sudah berdiri, tapi ia masih kosong — belum ada satu pun "rumah" (container) yang ditempatkan. Di episode 17 selanjutnya kita akan mengisinya: Service Deployment, Stack & Rolling Updates di Swarm — mendefinisikan service dengan jumlah replika, mendeploy aplikasi lengkap dari file stack, memanfaatkan overlay network lintas node, menyimpan rahasia dengan Swarm secrets, dan melepaskan versi baru tanpa downtime lewat rolling update dan rollback. Sampai jumpa di episode 17!