Container Orchestration dengan Docker Swarm: Membangun Cluster dan Manajemen Service

Setelah aplikasi kita di-containerize dan bisa berjalan di satu mesin dengan Docker Compose, pertanyaan selanjutnya adalah: bagaimana menjalankannya di production dengan skala beberapa node? Container orchestration menjawab kebutuhan ini, dan Docker Swarm adalah solusi bawaan Docker yang paling mudah untuk memulai.

Kapan Container Orchestration Menjadi Kebutuhan Infrastruktur

Docker Compose bekerja sangat baik untuk development dan staging pada single host. Tapi Compose memiliki batasan fundamental: semua container berjalan di satu mesin. Jika mesin tersebut down, seluruh aplikasi berhenti. Tidak ada high availability, tidak ada distribusi beban antar node, dan tidak ada mekanisme scaling otomatis lintas server. Dalam skenario production, satu titik kegagalan seperti ini tidak dapat ditoleransi.

Di production, kita membutuhkan kemampuan untuk mendistribusikan container ke beberapa node, memastikan service tetap berjalan meskipun ada node yang gagal, dan melakukan update tanpa downtime. Container orchestration platform menyediakan semua itu dengan pendekatan declarative — kita cukup mendefinisikan konfigurasi yang diinginkan, dan platform akan mengeksekusinya secara otomatis.

Docker Swarm hadir sebagai solusi orchestration bawaan Docker yang tidak memerlukan instalasi tambahan. Berbeda dengan Kubernetes yang membutuhkan setup kompleks, Swarm menggunakan API Docker yang sudah kita kenal. Dengan satu perintah, kita bisa mengubah satu Docker host menjadi cluster manager. Ini membuat Swarm menjadi pilihan ideal untuk tim yang sudah familiar dengan Docker dan ingin mulai menerapkan orchestration tanpa kurva belajar yang curam.

Memahami Arsitektur Docker Swarm dan Peran Setiap Node

Sebuah Swarm cluster terdiri dari dua jenis node: manager node dan worker node. Manager node bertanggung jawab mengelola state cluster dan mengorkestrasi task. Worker node menjalankan container-task yang dikirim oleh manager dan melaporkan status secara periodik. Manager node juga bisa menjalankan task, tetapi worker node tidak bisa ikut serta dalam orchestration decision.

Proses pengelolaan ini sangat bergantung pada algoritma Raft consensus. Swarm menggunakan Raft untuk memastikan semua manager node memiliki state yang konsisten tentang cluster. Anggap saja Raft sebagai protokol voting — ketika manager leader mengambil keputusan, mayoritas manager lain harus menyetujuinya sebelum keputusan dijalankan. Mekanisme ini mencegah split-brain dan memastikan fault tolerance.

Abstraksi fundamental di Swarm adalah Service, bukan container individu. Kita mendefinisikan service dengan image, jumlah replika, port yang di-expose, dan konfigurasi lainnya. Swarm kemudian mengelola task (instance container) yang menjalankan service tersebut secara declarative. Artinya, kita hanya mendeklarasikan state akhir yang diinginkan — misalnya tiga replika Nginx berjalan di port 80 — dan Swarm akan memastikan state tersebut terpenuhi secara terus-menerus.

Gambar: Arsitektur Docker Swarm — Sumber: [Docker Docs](https://docs.docker.com/engine/swarm/how-swarm-mode-works/nodes/)

Mari kita inisialisasi cluster Swarm pertama:

# Inisialisasi Swarm pada node pertama sebagai manager
docker swarm init --advertise-addr 192.168.1.100

# Lihat status node dalam cluster
docker node ls

Output docker node ls akan menampilkan satu node dengan role Manager dan status Ready. Untuk menambahkan worker node, kita menggunakan token dari perintah docker swarm join-token worker.

Deployment Layanan ke dalam Swarm Cluster

Setelah cluster aktif, langkah selanjutnya adalah men-deploy service menggunakan docker service create. Perhatikan bahwa perintah ini mirip dengan docker run, tetapi beroperasi di level cluster.

Kita akan deploy sebuah service Nginx dengan tiga replika. Perintah berikut membuat service yang dapat diakses melalui port 80 dan akan didistribusikan ke seluruh node dalam cluster:

# Deploy service Nginx dengan 3 replika
docker service create --name web-service \
  --replicas 3 \
  -p 80:80 \
  nginx:alpine

# Verifikasi service dan task
docker service ls
docker service ps web-service

docker service ps web-service akan menampilkan tiga task yang didistribusikan ke node-node yang tersedia. Swarm secara otomatis menentukan penempatan task berdasarkan resource yang tersedia dan constraint yang didefinisikan.

Salah satu skenario yang paling menarik adalah ketika terjadi node failure. Jika salah satu node mati, Swarm secara otomatis akan memindahkan task dari node yang gagal ke node lain yang masih sehat. Proses ini terjadi tanpa intervensi manual. Kita bisa menguji ini dengan mematikan Docker daemon di salah satu worker node, lalu jalankan docker service ps web-service — kita akan melihat task yang sebelumnya berjalan di node yang mati berpindah ke node lain dengan status baru.

Perintah docker service create juga mendukung opsi seperti batasan memori dan CPU, environment variables, volume mount, dan network attachment — sama seperti docker run, hanya saja diterapkan di level cluster.

Service Discovery dan Ingress Load Balancing

Salah satu fitur powerful Swarm adalah internal DNS resolution. Setiap service dalam cluster mendapatkan nama DNS yang bisa di-resolve oleh container lain. Sebagai contoh, jika kita memiliki service bernama api-service, container lain cukup memanggil http://api-service tanpa perlu tahu IP address atau port mana yang digunakan.

Swarm juga menyediakan Routing Mesh untuk ingress traffic. Ketika kita mem-publish port dengan flag -p 80:80, setiap node dalam cluster akan mendengarkan port tersebut. Jika request masuk ke node yang tidak menjalankan task service tersebut, Swarm akan meneruskan request secara internal ke node yang tepat.

Mari kita uji dua mekanisme ini:

# Deploy layanan kedua untuk testing internal DNS
docker service create --name curl-test \
  --replicas 1 \
  alpine sleep 3600

# Cari container ID dari curl-test
CONTAINER_ID=$(docker ps --filter "name=curl-test" -q)

# Test internal DNS resolution
docker exec $CONTAINER_ID ping web-service

# Test ingress load balancing dari luar cluster
curl http://localhost:80

Internal load balancing terjadi di layer DNS Swarm — setiap request ke nama service akan di-resolve ke salah satu task yang sehat secara round-robin. Jika ada tiga replika web-service, DNS Swarm akan mendistribusikan request ke ketiganya secara bergantian tanpa perlu reverse proxy tambahan.

Ingress load balancing bekerja di layer network melalui Routing Mesh. Saat request masuk ke node mana pun pada port 80, Swarm akan memeriksa service mana yang memiliki port tersebut, lalu meneruskan request ke task yang sesuai. Proses ini transparan bagi klien — klien cukup memanggil IP address node mana pun dalam cluster.

Kombinasi internal DNS resolution dan ingress Routing Mesh memungkinkan arsitektur yang fleksibel. Service backend bisa terhubung secara internal melalui DNS, sementara service frontend mengekspos port ke publik melalui ingress. Swarm menangani kompleksitas routing tanpa konfigurasi tambahan.

Gambar: Routing Mesh pada Docker Swarm — Sumber: [Docker Docs](https://docs.docker.com/engine/swarm/ingress/)

Rolling Update dan Rollback Strategy

Memperbarui service di production tanpa downtime adalah persyaratan mutlak. Swarm menyediakan parameter rolling update yang memberi kita kendali penuh atas proses update.

Parameter utama yang perlu dipahami:

• --update-parallelism: jumlah task yang diperbarui dalam satu batch. Nilai 1 berarti memperbarui satu task setiap kali, paling aman untuk production.
• --update-delay: jeda waktu antar batch. Nilai 10s memberi waktu memantau kestabilan task baru.
• --update-order: urutan update. start-first memulai task baru sebelum menghentikan yang lama (zero-downtime), stop-first sebaliknya.

Kita akan melakukan rolling update image Nginx dengan konfigurasi yang aman:

# Rolling update dengan delay dan parallelism yang terkontrol
docker service update \
  --image nginx:1.25-alpine \
  --update-parallelism 1 \
  --update-delay 10s \
  --update-order start-first \
  web-service

# Monitor progress update
docker service ps web-service

# Rollback jika terjadi masalah
docker service rollback web-service

Dengan konfigurasi di atas, Swarm memperbarui satu task dalam satu waktu, menunggu 10 detik antar batch, dan memulai task baru sebelum menghentikan task lama (start-first). Jika task baru gagal — misalnya health check tidak lulus — Swarm akan menahan update dan, dengan opsi --rollback-monitor, dapat melakukan rollback secara otomatis ke konfigurasi sebelumnya.

Perintah docker service rollback melakukan rollback ke versi sebelumnya dengan parameter yang sama seperti update. Swarm menyimpan riwayat konfigurasi service, sehingga rollback dapat dilakukan kapan saja tanpa perlu mendefinisikan ulang service.

Best Practices Manajemen Cluster Swarm

Beberapa praktik penting untuk menjaga Swarm cluster tetap stabil di production:

Jumlah Manager Node: Production harus memiliki 3 atau 5 manager node. Dua manager tidak memberikan fault tolerance karena Raft membutuhkan mayoritas (51%). Tiga manager mentolerir satu kegagalan, lima manager mentolerir dua kegagalan. Jangan gunakan jumlah genap — Raft membutuhkan kuorum, dan jumlah genap tidak memberikan keunggulan toleransi.

Label dan Constraint: Gunakan docker node update --label-add untuk memberi label pada node (misalnya ssd=true atau region=us-east). Kemudian gunakan --constraint saat membuat service untuk mengontrol penempatan task. Ini penting untuk workload yang membutuhkan hardware spesifik.

Backup Cluster State: State cluster Swarm disimpan di manager node dalam direktori /var/lib/docker/swarm. Backup direktori ini secara berkala. Untuk restore, hentikan Docker, restore direktori dari backup, lalu restart Docker.

Monitoring Dasar: Manfaatkan docker service logs web-service untuk melihat log semua task, dan docker stats untuk monitor resource real-time. Untuk observability lebih dalam, integrasikan dengan Prometheus dan Grafana.

Security Considerations: Enkripsi komunikasi antar node dengan flag --autolock. Gunakan Docker Secrets untuk menyimpan data sensitif seperti password dan API keys.

Ingin menguasai container orchestration dan DevOps practices secara menyeluruh? Program DevOps Engineering Bootcamp di Rumah Coding mencakup Docker Swarm, Kubernetes, CI/CD pipelines, dan production deployment strategies dengan hands-on labs.