Custom bridge network sudah cukup untuk kebanyakan skenario container yang berjalan di satu host tunggal, tapi topologi production tidak selalu sesederhana itu. Sysadmin/DevOps Engineer yang mengelola aplikasi dengan traffic tinggi sering perlu menyebar container ke lebih dari satu server fisik sekaligus, sementara kebutuhan keamanan menuntut isolasi jaringan yang lebih ketat daripada sekadar memisahkan container ke network yang berbeda. Bab ini membahas overlay network yang menghubungkan container lintas host, cara kerja multi-host networking lewat Docker Swarm, opsi konfigurasi lanjutan saat membuat user-defined network, sampai teknik network isolation yang lebih ketat untuk mengamankan topologi multi-tier di production.
15.1 Overlay Network dan Docker Swarm
Overlay network adalah driver jaringan yang menghubungkan container di lebih dari satu Docker host, membuat container-container tersebut bisa saling berkomunikasi seolah-olah berada di satu jaringan yang sama meski secara fisik tersebar di server yang berbeda. Berbeda dari bridge network yang cuma berlaku dalam satu host, overlay network butuh swarm mode aktif sebagai prasyarat, bahkan untuk menghubungkan container standalone sekalipun.
15.1.1 Cara Kerja Overlay Network
Overlay network membentuk jaringan terdistribusi di antara beberapa Docker daemon host dengan cara mengenkapsulasi paket jaringan lewat protokol VXLAN, lalu meneruskannya lewat jaringan fisik yang menghubungkan host-host tersebut. Docker Engine yang mengurus seluruh proses routing paket ke daemon dan container tujuan yang benar, sehingga container di host manapun bisa saling menjangkau lewat nama seperti pada custom bridge network biasa.
Beberapa port jaringan wajib terbuka antar host supaya overlay network berfungsi: port 2377/tcp untuk komunikasi control plane Swarm, port 7946/tcp dan 7946/udp untuk komunikasi antar node (node-to-node discovery), serta port 4789/udp untuk trafik data overlay itu sendiri. Sysadmin/DevOps Engineer yang mengatur firewall di lapangan sering lupa membuka ketiga port ini, sehingga node yang seharusnya bergabung ke swarm gagal saling menjangkau meski koneksi jaringan dasarnya sendiri normal.
15.1.2 Inisialisasi Swarm Mode
Overlay network cuma bisa dibuat setelah swarm mode aktif. Inisialisasi swarm mode di satu node yang berperan sebagai manager lewat docker swarm init.
docker swarm init --advertise-addr 192.168.1.10Swarm initialized: current node (abc123xyz) is now a manager.
To add a worker to this swarm, run the following command:
docker swarm join --token SWMTKN-1-xxxxx 192.168.1.10:2377Opsi --advertise-addr menentukan alamat IP yang dipakai node manager untuk berkomunikasi dengan node lain, penting disertakan secara eksplisit kalau host punya lebih dari satu network interface. Output docker swarm join di atas berisi token yang dipakai node lain untuk bergabung sebagai worker; jalankan perintah tersebut di setiap node worker yang ingin ditambahkan ke cluster.
15.1.3 Membuat Overlay Network dan Deploy Service
Setelah swarm mode aktif, buat overlay network lewat docker network create dengan driver overlay.
docker network create -d overlay app-overlay
docker service create --name web --network app-overlay --replicas 3 -p 8080:80 nginx:alpinePerintah docker service create di atas menjalankan tiga replika container nginx yang tersebar otomatis di seluruh node swarm, semuanya terhubung ke app-overlay. Cek distribusi task lewat docker service ps.
docker service ps webSetiap task yang muncul di output menunjukkan node tempat replika tersebut sebenarnya berjalan. Meski tersebar di node yang berbeda-beda, seluruh replika tetap bisa saling menjangkau lewat nama service web karena berada di overlay network yang sama, persis seperti mekanisme service discovery pada custom bridge network di satu host.
15.2 Multi-Host Networking dalam Praktik
Menjalankan service lintas node saja belum menyelesaikan seluruh gambaran multi-host networking. Ada beberapa mekanisme tambahan yang perlu dipahami: bagaimana port yang dipublish tetap bisa diakses dari node manapun, bagaimana container standalone (bukan Swarm service) bisa ikut bergabung ke overlay network, dan bagaimana mengamankan trafik overlay yang melintasi jaringan fisik antar host.
15.2.1 Routing Mesh dan Network Ingress
Saat sebuah service di-publish lewat -p seperti pada contoh web sebelumnya, Docker Swarm otomatis memanfaatkan overlay network khusus bernama ingress untuk mengimplementasikan routing mesh, mekanisme yang membuat port tersebut bisa diakses dari node manapun di swarm, bahkan dari node yang secara fisik tidak menjalankan replika service tersebut.
docker network lsNETWORK ID NAME DRIVER SCOPE
f1a2b3c4d5e6 ingress overlay swarm
a2b3c4d5e6f7 docker_gwbridge bridge localNetwork ingress dan docker_gwbridge di atas otomatis dibuat begitu swarm mode diaktifkan. docker_gwbridge berperan sebagai jembatan yang menghubungkan overlay network ke interface fisik host, sehingga trafik dari luar yang menuju port yang dipublish bisa diteruskan ke replika service yang tepat, di node manapun replika itu berjalan. Di lapangan, ini berarti request yang masuk ke node A bisa saja diteruskan ke replika yang sebenarnya berjalan di node B tanpa perlu load balancer eksternal tambahan untuk kasus sederhana.
15.2.2 Overlay Attachable untuk Container Standalone
Secara default, overlay network cuma bisa diakses oleh Swarm service, bukan container standalone yang dijalankan lewat docker run biasa. Opsi --attachable saat membuat overlay network menghilangkan batasan ini, mengizinkan container standalone maupun Swarm service untuk terhubung ke network yang sama.
docker network create -d overlay --attachable shared-overlay
docker run -d --name debug-tool --network shared-overlay alpine sleep 3600
docker exec debug-tool ping -c 2 webContainer debug-tool di atas berhasil dijalankan sebagai container standalone (bukan service), tapi tetap bisa menjangkau service web selama keduanya terhubung ke overlay network yang sama dan network tersebut dibuat dengan --attachable. Pola ini sering dipakai Sysadmin/DevOps Engineer untuk keperluan debugging atau menjalankan tool sekali pakai yang perlu mengakses service di dalam swarm tanpa harus dideploy sebagai service permanen.
15.2.3 Enkripsi Trafik Overlay
Trafik overlay network yang melintasi jaringan fisik antar host secara default tidak terenkripsi, sebuah risiko kalau jaringan fisik yang menghubungkan node-node swarm tidak sepenuhnya tepercaya, misalnya saat node tersebar di data center yang berbeda. Opsi --opt encrypted saat membuat overlay network mengaktifkan enkripsi IPsec di level VXLAN untuk seluruh trafik yang melintas di network tersebut.
docker network create -d overlay --opt encrypted secure-overlayEnkripsi ini membawa overhead performa yang tidak bisa diabaikan karena setiap paket harus dienkripsi dan didekripsi di level kernel, sehingga sebaiknya cuma diaktifkan untuk network yang memang menyimpan data sensitif melintasi jaringan fisik yang tidak sepenuhnya terpercaya. Perlu dicatat juga bahwa opsi ini tidak didukung untuk Windows container. Attacker yang berhasil menyadap trafik jaringan fisik antar node tanpa enkripsi overlay bisa membaca isi paket yang lewat, sementara dengan --opt encrypted aktif, paket yang tersadap tetap tidak bisa dibaca tanpa kunci enkripsi yang dikelola otomatis oleh Swarm.
docker service rm web
docker rm -f debug-tool
docker network rm app-overlay shared-overlay secure-overlay15.3 Konfigurasi Lanjutan User-Defined Network
Membuat custom network tanpa opsi tambahan sudah cukup untuk kebanyakan kasus, tapi docker network create menyediakan sejumlah opsi lanjutan yang berguna saat topologi jaringan container perlu menyesuaikan skema alamat IP yang sudah ada di infrastruktur, atau saat sebuah network memang harus benar-benar tertutup dari akses keluar.
15.3.1 Custom IPAM: Subnet, Gateway, dan IP Range
Secara default, Docker otomatis memilih subnet dan gateway untuk network baru dari pool alamat internal miliknya. Opsi --subnet, --gateway, dan --ip-range memungkinkan menentukan skema pengalamatan IP secara eksplisit, berguna terutama saat subnet default Docker bertabrakan dengan subnet yang sudah dipakai di jaringan perusahaan.
docker network create \
--subnet=10.20.0.0/24 \
--gateway=10.20.0.1 \
--ip-range=10.20.0.128/25 \
custom-ipam-netOpsi --subnet di atas menentukan rentang alamat keseluruhan untuk network tersebut, --gateway menentukan alamat gateway di dalam subnet itu, sementara --ip-range mempersempit rentang alamat yang benar-benar dialokasikan Docker ke container baru menjadi separuh bagian akhir dari subnet. Container yang dijalankan di network ini otomatis mendapat IP dari dalam rentang 10.20.0.128/25 tersebut, bukan dari keseluruhan subnet /24.
docker run -d --name ipam-test --network custom-ipam-net alpine sleep 3600
docker inspect --format '{{.NetworkSettings.Networks.custom-ipam-net.IPAddress}}' ipam-testSysadmin/DevOps Engineer yang mengelola banyak network sekaligus di infrastruktur besar biasanya menetapkan skema subnet seperti ini secara konsisten dari awal, supaya rentang alamat antar network tidak pernah tumpang tindih dan lebih mudah dipetakan saat troubleshooting.
15.3.2 Internal Network untuk Isolasi dari Luar
Opsi --internal membuat sebuah network sama sekali tidak punya jalur keluar ke jaringan di luar dirinya sendiri. Container yang terhubung ke internal network tetap bisa saling berkomunikasi satu sama lain, tapi tidak bisa menjangkau network lain atau internet sama sekali, karena Docker memang tidak mengonfigurasi default route keluar untuk network jenis ini.
docker network create --internal db-internal
docker run -d --name db --network db-internal postgres:16-alpine
docker exec db ping -c 2 8.8.8.8Perintah ping ke alamat internet publik di atas akan gagal timeout, membuktikan container db memang terisolasi total dari akses keluar. Pola ini cocok dipakai untuk tier database atau service internal lain yang secara desain tidak pernah butuh mengakses internet, sehingga kalaupun container tersebut kena eksploitasi lewat vulnerability tertentu, Attacker yang berhasil masuk tetap tidak bisa memakainya sebagai jalur keluar (exfiltration) ke internet.
docker rm -f ipam-test db
docker network rm custom-ipam-net db-internal15.4 Network Isolation dan Segmentasi Lanjutan
Memisahkan container ke network yang berbeda seperti pada pola frontend-backend sudah membangun isolasi dasar, tapi topologi production yang lebih kompleks kadang butuh kontrol lebih granular lagi, termasuk mengatur segmentasi multi-tier yang konsisten dan menonaktifkan komunikasi antar container secara default.
15.4.1 Multi-Tier Architecture dengan Internal Network
Kombinasi custom bridge network biasa dan internal network bisa membentuk arsitektur tiga tingkat yang lazim dipakai di production: tier publik yang boleh diakses dari luar, tier aplikasi yang cuma bisa dijangkau lewat tier publik, dan tier database yang benar-benar terisolasi dari internet.
docker network create public-net
docker network create --internal app-net
docker network create --internal db-net
docker run -d --name db --network db-net postgres:16-alpine
docker run -d --name api --network app-net node-app:latest
docker network connect db-net api
docker run -d --name proxy --network public-net -p 443:443 nginx:alpine
docker network connect app-net proxyContainer db cuma jadi anggota db-net yang bersifat internal, sehingga sama sekali tidak terjangkau dari luar maupun dari internet. Container api jadi anggota app-net (juga internal) sekaligus db-net lewat docker network connect, sehingga bisa menjangkau db tapi tetap tidak punya akses keluar ke internet. Container proxy jadi satu-satunya yang terhubung ke public-net yang tidak internal, sekaligus jadi anggota app-net supaya bisa meneruskan request ke api. Susunan berlapis seperti ini memastikan Attacker yang berhasil mengeksploitasi proxy dari luar masih harus menembus lapisan isolasi app-net dan db-net sebelum benar-benar menyentuh data di db, alih-alih langsung punya jalur terbuka dari internet ke database.
15.4.2 Menonaktifkan Inter-Container Communication (ICC)
Secara default, seluruh container yang terhubung ke bridge network yang sama (baik default bridge maupun custom bridge) bisa saling berkomunikasi bebas lewat opsi driver com.docker.network.bridge.enable_icc yang bernilai true. Menonaktifkan opsi ini lewat -o com.docker.network.bridge.enable_icc=false saat membuat network mencegah container yang terhubung padanya saling berkomunikasi satu sama lain secara default, meski masih berada di network yang sama.
docker network create -o com.docker.network.bridge.enable_icc=false isolated-net
docker run -d --name svc1 --network isolated-net alpine sleep 3600
docker run -d --name svc2 --network isolated-net alpine sleep 3600
docker exec svc1 ping -c 2 svc2Perintah ping di atas akan gagal meski svc1 dan svc2 sama-sama anggota isolated-net, karena opsi ICC yang dinonaktifkan membuat Docker menambahkan aturan iptables yang secara default menolak trafik antar container di network tersebut. Pola ini berguna untuk skenario yang memang butuh publish port dari beberapa container ke host tanpa mengizinkan container-container itu saling menjangkau langsung satu sama lain, misalnya beberapa service independen milik tenant berbeda yang kebetulan ditempatkan di network yang sama demi kemudahan manajemen, tapi memang harus saling terisolasi demi alasan keamanan.
docker rm -f db api proxy svc1 svc2
docker network rm public-net app-net db-net isolated-net