Fundamental Docker Swarm - Mengapa Ia Ada, Sejarah, dan Konsep Inti

#Pengenalan

Docker Swarm ada karena mengorkestra container dalam skala besar itu sulit. Ketika Anda melampaui menjalankan satu daemon Docker di satu mesin, Anda menghadapi masalah nyata: bagaimana cara mendistribusikan container di beberapa host? Bagaimana menangani kegagalan? Bagaimana mengelola jaringan dan penyimpanan? Bagaimana cara menskalakan layanan naik dan turun?

Docker Swarm menjawab pertanyaan-pertanyaan ini dengan solusi orkestrasi bawaan yang ringan. Tidak seperti Kubernetes, yang kuat tetapi kompleks, Swarm memprioritaskan kesederhanaan dan kemudahan penggunaan. Dirancang untuk tim yang membutuhkan orkestrasi container tanpa beban operasional yang berat.

Dalam artikel ini, kami akan mengeksplorasi mengapa Swarm ada, sejarahnya, masalah yang dipecahkannya, dan cara menggunakannya secara efektif dalam skenario dunia nyata.

#Daftar Isi

#Mengapa Docker Swarm Ada

#Masalah Orkestrasi Container

Sebelum Docker Swarm, menjalankan container dalam produksi berarti menyelesaikan beberapa masalah sulit secara manual:

1. Penjadwalan multi-host - Di mana setiap container harus berjalan?
2. Penemuan layanan - Bagaimana container menemukan satu sama lain?
3. Penyeimbangan beban - Bagaimana cara mendistribusikan lalu lintas?
4. Pemulihan kegagalan - Apa yang terjadi ketika container mogok?
5. Pembaruan bergulir - Bagaimana cara menerapkan versi baru tanpa downtime?
6. Manajemen sumber daya - Bagaimana cara mengalokasikan CPU dan memori?

Tim baik membangun solusi khusus atau menggunakan alat eksternal. Ini rapuh dan memakan waktu.

#Jawaban Docker

Docker Swarm dibuat untuk menyediakan orkestrasi yang:

• Bawaan - Tidak ada instalasi terpisah atau setup kompleks
• Sederhana - Menggunakan perintah Docker CLI yang familiar
• Ringan - Overhead sumber daya minimal
• Deklaratif - Tentukan keadaan yang diinginkan, Swarm menangani sisanya

Filosofinya: orkestrasi harus dapat diakses oleh tim dari ukuran apa pun, bukan hanya mereka yang memiliki keahlian Kubernetes khusus.

#Sejarah dan Evolusi

#Docker Swarm v1 (2015-2016)

Docker Swarm dimulai sebagai proyek terpisah pada tahun 2015. Ini adalah alat orkestrasi mandiri yang mengelola container Docker di seluruh cluster. Anda akan menjalankan Swarm sebagai layanan terpisah bersama Docker.

Karakteristik utama:

• Binary dan layanan terpisah
• Menggunakan perintah khusus Swarm
• Memerlukan penemuan layanan eksternal (Consul, etcd)
• Integrasi terbatas dengan Docker

#Docker Swarm Mode (2016-Sekarang)

Pada Juni 2016, Docker 1.12 memperkenalkan Swarm Mode - perubahan fundamental. Swarm menjadi asli untuk Docker itu sendiri, bukan alat terpisah.

Apa yang berubah:

• Fungsionalitas Swarm dibangun langsung ke dalam daemon Docker
• Clustering asli dengan docker swarm init
• Penemuan layanan dan penyeimbangan beban terintegrasi
• Konsensus Raft untuk manajemen status
• Tidak ada dependensi eksternal yang diperlukan

Ini adalah titik balik. Swarm Mode membuat orkestrasi dapat diakses oleh setiap pengguna Docker.

#Mengapa Swarm Penting Hari Ini

Meskipun dominasi Kubernetes, Swarm tetap relevan karena:

1. Kesederhanaan - Tim yang lebih kecil tidak memerlukan kompleksitas Kubernetes
2. Beban operasional lebih rendah - Lebih sedikit untuk dipelajari, lebih sedikit komponen untuk dikelola
3. Bawaan - Tidak ada instalasi atau konfigurasi tambahan
4. Hemat biaya - Berjalan di hardware sederhana
5. Familiar - Menggunakan CLI Docker dan konsep yang sudah Anda kenal

#Konsep Inti

#Node

Node adalah daemon Docker yang berpartisipasi dalam Swarm. Ada dua jenis:

Node Manager - Mengontrol cluster

• Mempertahankan status cluster
• Menjadwalkan layanan
• Melayani API
• Memilih pemimpin melalui konsensus Raft
• Dapat juga menjalankan container (secara default)

Node Worker - Menjalankan tugas

• Menjalankan container
• Melaporkan status ke manager
• Tidak dapat membuat keputusan penjadwalan

Swarm yang sehat membutuhkan setidaknya satu manager. Untuk produksi, gunakan 3, 5, atau 7 manager (angka ganjil untuk konsensus Raft).

#Layanan

Layanan adalah abstraksi utama dalam Swarm. Ini mendefinisikan:

• Image mana yang akan dijalankan
• Berapa banyak replika (salinan) yang harus dipertahankan
• Pemetaan port
• Variabel lingkungan
• Batas sumber daya
• Kebijakan pembaruan

Layanan bersifat deklaratif - Anda menentukan keadaan yang diinginkan, dan Swarm mempertahankannya.

#Tugas

Tugas adalah instance yang berjalan dari layanan. Jika Anda membuat layanan dengan 3 replika, Swarm membuat 3 tugas. Setiap tugas menjalankan container.

Ketika tugas gagal, Swarm secara otomatis membuat pengganti.

#Stack

Stack adalah kumpulan layanan yang didefinisikan dalam file Compose. Ini adalah setara Swarm dari namespace Kubernetes atau unit deployment.

Stack memungkinkan Anda menerapkan seluruh aplikasi (beberapa layanan) dengan satu perintah.

#Jaringan Overlay

Jaringan overlay memungkinkan komunikasi antara container di berbagai host. Mereka dienkripsi secara default dan menangani penemuan layanan secara otomatis.

Ketika Anda membuat layanan, Swarm secara otomatis mendaftarkannya di DNS. Container dapat menjangkau layanan berdasarkan nama.

#Penyeimbangan Beban

Swarm mencakup penyeimbangan beban bawaan:

• Penyeimbangan beban ingress - Lalu lintas eksternal ke port yang dipublikasikan
• Penemuan layanan - Penyeimbangan beban berbasis DNS internal
• VIP (Virtual IP) - Setiap layanan mendapat alamat IP yang stabil

#Cara Kerja Swarm di Balik Layar

#Konsensus Raft

Node manager menggunakan konsensus Raft untuk mempertahankan status cluster. Ini memastikan:

• Semua manager memiliki pandangan cluster yang sama
• Keputusan dibuat dengan aman bahkan jika beberapa manager gagal
• Status persisten dan dapat dipulihkan

Raft memerlukan quorum (mayoritas) manager untuk membuat keputusan. Dengan 3 manager, Anda dapat kehilangan 1. Dengan 5, Anda dapat kehilangan 2.

#Penjadwalan Layanan

Ketika Anda membuat layanan, manager:

1. Menerima definisi layanan
2. Menentukan berapa banyak tugas yang akan dibuat
3. Memilih node untuk setiap tugas berdasarkan:
   • Ketersediaan sumber daya
   • Batasan penempatan
   • Aturan afinitas
4. Menginstruksikan worker untuk memulai container
5. Memantau kesehatan tugas

#Manajemen Status

Swarm menyimpan status cluster dalam database terdistribusi yang direplikasi di semua manager. Ini mencakup:

• Definisi layanan
• Penugasan tugas
• Informasi node
• Konfigurasi jaringan

Jika manager mogok, yang lain terus beroperasi. Ketika itu pulih, itu menyinkronkan status dari cluster.

#Implementasi Praktis

#Menyiapkan Cluster Swarm

Mari buat cluster Swarm 3-node sederhana. Untuk contoh ini, kami akan menggunakan Docker di satu mesin dengan beberapa container yang mensimulasikan node.

docker swarm init --advertise-addr 127.0.0.1

Output ini menunjukkan perintah untuk bergabung dengan node worker:

Swarm initialized: current node (abc123...) is now a manager.
 
To add a worker to this swarm, run the following command:
 
    docker swarm join --token SWMTKN-1-xxx 127.0.0.1:2377
 
To add a manager to this swarm, run the following command:
 
    docker swarm join-token manager

Dalam produksi, Anda akan menjalankan ini di mesin terpisah. Untuk sekarang, mari verifikasi cluster:

docker node ls

#Membuat Layanan

Mari deploy layanan web sederhana:

docker service create \
  --name web \
  --replicas 3 \
  --publish 8080:80 \
  nginx:latest

Periksa status layanan:

docker service ls

Lihat tugas (container yang berjalan):

docker service ps web

#Penskalaan Layanan

Tingkatkan replika:

docker service scale web=5

Kurangi replika:

docker service scale web=2

#Memperbarui Layanan

Perbarui image:

docker service update \
  --image nginx:1.25 \
  web

Swarm melakukan pembaruan bergulir secara default - mengganti tugas satu per satu, memastikan ketersediaan.

#Menggunakan Docker Compose dengan Swarm

Tentukan stack dalam file Compose:

version: '3.9'
 
services:
  web:
    image: nginx:latest
    ports:
      - "8080:80"
    deploy:
      replicas: 3
      update_config:
        parallelism: 1
        delay: 10s
      restart_policy:
        condition: on-failure
        max_attempts: 3
    networks:
      - app-network
 
  db:
    image: postgres:15
    environment:
      POSTGRES_PASSWORD: secret
    volumes:
      - db-data:/var/lib/postgresql/data
    deploy:
      replicas: 1
      placement:
        constraints: [node.role == manager]
    networks:
      - app-network
 
volumes:
  db-data:
 
networks:
  app-network:
    driver: overlay

Deploy stack:

docker stack deploy -c docker-compose.yml myapp

Daftar stack:

docker stack ls

Lihat layanan dalam stack:

docker stack services myapp

Hapus stack:

docker stack rm myapp

#Kesalahan Umum dan Jebakan

#Kesalahan 1: Menjalankan Hanya Satu Manager

Masalah: Satu manager adalah titik kegagalan tunggal. Jika mogok, cluster berhenti menerima perintah.

Mengapa terjadi: Tim mulai kecil dan tidak merencanakan pertumbuhan.

Solusi: Selalu jalankan setidaknya 3 manager dalam produksi. Gunakan angka ganjil (3, 5, 7) untuk konsensus Raft.

#Kesalahan 2: Mengabaikan Batas Sumber Daya

Masalah: Layanan mengonsumsi semua sumber daya yang tersedia, membuat layanan lain kelaparan.

Mengapa terjadi: Mudah lupa batasan sumber daya saat mendefinisikan layanan.

Solusi: Selalu tetapkan permintaan dan batas sumber daya:

services:
  web:
    image: nginx:latest
    deploy:
      resources:
        limits:
          cpus: '0.5'
          memory: 512M
        reservations:
          cpus: '0.25'
          memory: 256M

#Kesalahan 3: Tidak Memantau Kesehatan Cluster

Masalah: Anda tidak menyadari ketika node gagal atau layanan menjadi tidak sehat.

Mengapa terjadi: Swarm tidak menyediakan dashboard monitoring bawaan.

Solusi: Gunakan alat monitoring eksternal (Prometheus, Grafana) atau alat khusus Swarm (Orbiter, Portainer).

#Kesalahan 4: Menyimpan Status dalam Container

Masalah: Ketika container diganti, data hilang.

Mengapa terjadi: Nyaman menyimpan data secara lokal selama pengembangan.

Solusi: Gunakan volume untuk data persisten:

services:
  db:
    image: postgres:15
    volumes:
      - db-data:/var/lib/postgresql/data
    deploy:
      replicas: 1
 
volumes:
  db-data:
    driver: local

#Kesalahan 5: Menerapkan Tanpa Pemeriksaan Kesehatan

Masalah: Swarm tidak tahu apakah layanan benar-benar sehat, hanya jika container berjalan.

Mengapa terjadi: Pemeriksaan kesehatan memerlukan konfigurasi tambahan.

Solusi: Tentukan pemeriksaan kesehatan dalam Dockerfile atau file Compose:

services:
  web:
    image: nginx:latest
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 40s

#Praktik Terbaik

#1. Rencanakan Topologi Manager Anda

• Pengembangan: 1 manager (dapat diterima untuk non-kritis)
• Produksi kecil: 3 manager
• Produksi besar: 5-7 manager

Distribusikan manager di berbagai zona ketersediaan atau pusat data.

#2. Gunakan Batasan Penempatan

Kontrol di mana layanan berjalan:

services:
  db:
    image: postgres:15
    deploy:
      placement:
        constraints:
          - node.role == manager
          - node.labels.disk == ssd

#3. Implementasikan Shutdown Graceful

Pastikan container menangani SIGTERM dengan benar:

FROM node:18
 
WORKDIR /app
COPY . .
 
# Gunakan bentuk exec untuk memastikan sinyal diterima
EXEC ["node", "server.js"]

#4. Gunakan Secrets untuk Data Sensitif

Simpan password dan kunci API dengan aman:

echo "my-secret-password" | docker secret create db_password -

Gunakan dalam layanan:

services:
  db:
    image: postgres:15
    environment:
      POSTGRES_PASSWORD_FILE: /run/secrets/db_password
    secrets:
      - db_password
    deploy:
      replicas: 1
 
secrets:
  db_password:
    external: true

#5. Pantau dan Catat Semuanya

Gunakan logging terpusat:

services:
  web:
    image: nginx:latest
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

#6. Rencanakan Pembaruan

Gunakan pembaruan bergulir untuk mempertahankan ketersediaan:

services:
  web:
    image: nginx:latest
    deploy:
      replicas: 3
      update_config:
        parallelism: 1
        delay: 10s
        failure_action: rollback
      restart_policy:
        condition: on-failure
        max_attempts: 3

#Kapan TIDAK Menggunakan Docker Swarm

#Swarm tidak ideal untuk:

1. Deployment multi-cloud kompleks - Kubernetes menangani ini lebih baik
2. Aplikasi stateful yang memerlukan penyimpanan canggih - Gunakan Kubernetes dengan persistent volume
3. Tim yang sudah berinvestasi dalam Kubernetes - Biaya switching melebihi manfaat
4. Aplikasi yang memerlukan kebijakan jaringan lanjutan - Kebijakan jaringan Kubernetes lebih kuat
5. Deployment skala besar (100+ node) - Kubernetes skalanya lebih baik
6. Organisasi yang memerlukan alat ekosistem ekstensif - Kubernetes memiliki ekosistem yang matang

#Kapan Swarm bersinar:

• Deployment skala kecil hingga menengah (5-50 node)
• Tim yang memprioritaskan kesederhanaan daripada fitur
• Alur kerja yang sudah berpusat pada Docker
• Lingkungan yang sensitif terhadap biaya
• Pembelajaran orkestrasi container

#Kasus Penggunaan Dunia Nyata: Platform E-Commerce

Mari kita bangun contoh praktis - platform e-commerce kecil dengan 3 layanan: frontend web, backend API, dan database.

#Gambaran Arsitektur

┌─────────────────────────────────────────┐
│         Docker Swarm Cluster            │
├─────────────────────────────────────────┤
│  Manager Node 1    Manager Node 2       │
│  (web-1, api-1)    (web-2, api-2)       │
│                                         │
│  Worker Node 1     Worker Node 2        │
│  (web-3, api-3)    (db-1)               │
└─────────────────────────────────────────┘

#File Compose

version: '3.9'
 
services:
  web:
    image: myregistry/ecommerce-web:1.0
    ports:
      - "80:3000"
    environment:
      API_URL: http://api:8000
      NODE_ENV: production
    deploy:
      replicas: 3
      update_config:
        parallelism: 1
        delay: 10s
        failure_action: rollback
      restart_policy:
        condition: on-failure
        max_attempts: 3
      resources:
        limits:
          cpus: '0.5'
          memory: 512M
        reservations:
          cpus: '0.25'
          memory: 256M
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 40s
    networks:
      - ecommerce-net
    secrets:
      - api_key
 
  api:
    image: myregistry/ecommerce-api:1.0
    ports:
      - "8000:8000"
    environment:
      DATABASE_URL: postgresql://postgres:${DB_PASSWORD}@db:5432/ecommerce
      NODE_ENV: production
    deploy:
      replicas: 2
      update_config:
        parallelism: 1
        delay: 10s
      restart_policy:
        condition: on-failure
        max_attempts: 3
      resources:
        limits:
          cpus: '1'
          memory: 1G
        reservations:
          cpus: '0.5'
          memory: 512M
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8000/health"]
      interval: 30s
      timeout: 10s
      retries: 3
    networks:
      - ecommerce-net
    secrets:
      - db_password
      - api_key
    depends_on:
      - db
 
  db:
    image: postgres:15-alpine
    environment:
      POSTGRES_DB: ecommerce
      POSTGRES_PASSWORD_FILE: /run/secrets/db_password
    volumes:
      - db-data:/var/lib/postgresql/data
    deploy:
      replicas: 1
      placement:
        constraints:
          - node.role == manager
      resources:
        limits:
          cpus: '2'
          memory: 2G
        reservations:
          cpus: '1'
          memory: 1G
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 10s
      timeout: 5s
      retries: 5
    networks:
      - ecommerce-net
    secrets:
      - db_password
 
volumes:
  db-data:
    driver: local
 
networks:
  ecommerce-net:
    driver: overlay
    driver_opts:
      com.docker.network.driver.overlay.vxlan_list: 4789
 
secrets:
  db_password:
    file: ./secrets/db_password.txt
  api_key:
    file: ./secrets/api_key.txt

#Langkah-Langkah Deployment

1. Siapkan secrets:

mkdir -p secrets
echo "your-secure-password" > secrets/db_password.txt
echo "your-api-key" > secrets/api_key.txt

2. Inisialisasi Swarm (di manager pertama):

docker swarm init --advertise-addr <manager-ip>

3. Bergabung dengan node tambahan:

docker swarm join --token <token> <manager-ip>:2377

4. Deploy stack:

docker stack deploy -c ecommerce-stack.yml ecommerce

5. Verifikasi deployment:

docker stack services ecommerce

Output:

ID             NAME              MODE        REPLICAS   IMAGE
abc123...      ecommerce_web     replicated  3/3        myregistry/ecommerce-web:1.0
def456...      ecommerce_api     replicated  2/2        myregistry/ecommerce-api:1.0
ghi789...      ecommerce_db      replicated  1/1        postgres:15-alpine

6. Periksa tugas individual:

docker service ps ecommerce_web

#Penskalaan Selama Jam Puncak

Ketika lalu lintas meningkat, skalakan layanan web dan API:

docker service scale ecommerce_web=5 ecommerce_api=4

Swarm secara otomatis mendistribusikan tugas baru di seluruh node yang tersedia.

#Pembaruan Bergulir

Deploy versi baru dari layanan web:

docker service update \
  --image myregistry/ecommerce-web:1.1 \
  ecommerce_web

Swarm memperbarui satu tugas pada satu waktu, memastikan layanan tetap tersedia.

#Monitoring

Periksa kesehatan layanan:

docker service ps ecommerce_web --no-trunc

Lihat log dari layanan:

docker service logs ecommerce_api

#Menangani Kegagalan Node

Jika node worker gagal:

1. Swarm mendeteksi kegagalan
2. Tugas di node itu ditandai sebagai gagal
3. Tugas baru dijadwalkan di node yang sehat
4. Layanan mempertahankan jumlah replika mereka

Tidak ada intervensi manual yang diperlukan.

#Kesimpulan

Docker Swarm ada karena orkestrasi harus dapat diakses. Ini muncul dari filosofi Docker: buat alat yang kuat cukup sederhana untuk semua orang gunakan.

Meskipun Kubernetes mendominasi ruang enterprise, Swarm tetap menjadi pilihan yang tepat untuk tim yang menghargai kesederhanaan, fungsionalitas bawaan, dan overhead operasional yang lebih rendah. Ini sempurna untuk deployment skala kecil hingga menengah di mana Anda membutuhkan orkestrasi tanpa kompleksitas.

Poin-poin kunci yang perlu diambil:

• Swarm adalah orkestrasi yang dibangun ke dalam Docker, bukan alat terpisah
• Ini menggunakan perintah Docker CLI dan file Compose yang familiar
• Layanan adalah abstraksi utama - tentukan keadaan yang diinginkan, Swarm mempertahankannya
• Jaringan overlay dan penemuan layanan bekerja di luar kotak
• Ini ideal untuk tim yang memprioritaskan kesederhanaan daripada fitur lanjutan

Mulai dengan cluster 3-node, gunakan file Compose untuk definisi stack, implementasikan pemeriksaan kesehatan, dan pantau layanan Anda. Anda akan memiliki platform orkestrasi container yang andal dan mudah dirawat yang berkembang sesuai kebutuhan Anda.

Untuk contoh e-commerce, Anda sekarang memiliki template siap produksi. Sesuaikan dengan persyaratan spesifik Anda, tambahkan monitoring dan logging, dan Anda siap untuk deploy.