Dasar-dasar Jaringan Docker

Aplikasi yang berjalan di dalam container jarang berdiri sendiri. Sebuah aplikasi web biasanya butuh terhubung ke database, cache, atau service lain, dan semuanya bisa saja berjalan sebagai container terpisah di host yang sama. Di sinilah jaringan Docker berperan: mengatur bagaimana container saling terhubung satu sama lain, sekaligus bagaimana container terhubung keluar ke jaringan host atau internet. Developer yang membangun aplikasi multi-service butuh paham konsep ini supaya container-container tersebut bisa saling bicara, sementara Sysadmin/DevOps Engineer perlu memahaminya untuk mengatur isolasi, keamanan, dan troubleshooting koneksi di production. Bab ini membahas berbagai network driver yang disediakan Docker, karakteristik default bridge network, cara membuat dan memakai custom bridge network, sampai teknik inspeksi jaringan untuk memastikan konfigurasi sudah benar.

13.1 Network Drivers

Docker Engine mendukung sistem jaringan yang bersifat pluggable lewat konsep network driver, yaitu komponen yang menentukan bagaimana sebuah network bekerja: apakah container saling terisolasi, terhubung lewat bridge virtual, memakai jaringan host langsung, atau tersambung lintas host lewat jaringan overlay. Setiap network yang dibuat di Docker selalu memakai salah satu driver ini.

13.1.1 Bridge

Bridge adalah network driver default di Docker. Kalau sebuah network dibuat tanpa menentukan driver secara eksplisit, Docker otomatis memakai driver bridge. Driver ini cocok dipakai saat container yang berjalan di satu host yang sama perlu saling berkomunikasi, misalnya container aplikasi web yang perlu menyambung ke container database di host yang sama.

Secara teknis, bridge network memakai perangkat jaringan virtual di level kernel Linux yang berfungsi seperti switch, menghubungkan seluruh container yang terpasang padanya dalam satu segmen jaringan privat. Setiap container yang terhubung ke bridge network yang sama mendapat alamat IP privat masing-masing dan bisa saling berkomunikasi lewat alamat tersebut.

13.1.2 Host

Network driver host menghapus isolasi jaringan antara container dan host, membuat container langsung memakai stack jaringan milik host tanpa NAT atau bridge virtual di antaranya. Kalau sebuah container yang memakai driver host membuka port 8080, port tersebut otomatis terbuka di host tanpa perlu opsi -p untuk publish port.

Driver ini cocok untuk kasus yang butuh performa jaringan maksimal atau perlu mengakses banyak range port dinamis, tapi konsekuensinya container kehilangan isolasi jaringan sama sekali dari host. Attacker yang berhasil mengeksploitasi container yang memakai network host punya akses jaringan yang jauh lebih luas dibanding container yang terisolasi lewat bridge, sehingga driver ini sebaiknya dipakai secara selektif dan disertai pertimbangan keamanan yang matang, terutama di production.

Dukungan driver host berbeda antar platform. Di Docker Engine Linux, driver ini didukung penuh dan sudah tersedia secara native. Di Docker Desktop untuk macOS dan Windows, dukungan host networking baru tersedia mulai versi 4.34 dan sifatnya opt-in lewat menu Settings > Resources > Network > Enable host networking, dengan keterbatasan: proses di dalam container tidak bisa langsung bind ke alamat IP host, cuma bekerja di layer 4 (TCP/UDP), dan tidak berlaku untuk Windows container.

13.1.3 Overlay

Overlay adalah driver yang menghubungkan beberapa Docker daemon di host berbeda, memungkinkan container atau service Swarm yang tersebar di banyak node untuk saling berkomunikasi seolah-olah berada di satu jaringan yang sama. Driver ini menghilangkan kebutuhan melakukan routing manual di level OS antar host, karena Docker yang mengurus enkapsulasi paket jaringan di baliknya.

Overlay network relevan terutama saat container sudah berjalan dalam mode Swarm atau kebutuhan orkestrasi multi-host lain. Untuk deployment yang seluruh container-nya berjalan di satu host tunggal, bridge network sudah cukup dan lebih sederhana dikelola dibanding overlay.

13.1.4 Macvlan

Macvlan memberikan setiap container alamat MAC address unik, membuat container tersebut terlihat seperti perangkat fisik tersendiri di jaringan, bukan sekadar proses yang berjalan di balik NAT host. Docker daemon meneruskan trafik ke container berdasarkan MAC address tersebut, langsung terhubung ke jaringan fisik lewat interface parent yang ditentukan.

Driver ini berguna terutama untuk migrasi dari environment virtual machine ke container, terutama untuk aplikasi legacy yang memang mengharapkan koneksi langsung ke jaringan fisik, bukan lewat routing tambahan dari host Docker. Macvlan butuh interface jaringan fisik (misalnya eth0) sebagai parent, dan menurut dokumentasi resmi Docker driver ini hanya berjalan di Docker Engine Linux; Docker Desktop untuk macOS dan Windows maupun Docker Engine di Windows sama sekali tidak mendukungnya. Kebanyakan penyedia cloud juga memblokir trafik macvlan secara default, sehingga driver ini cuma praktis dipakai di infrastruktur dengan akses fisik langsung ke perangkat jaringan.

13.1.5 None

Driver none mengisolasi container sepenuhnya dari jaringan host maupun container lain. Container yang dijalankan dengan --network none cuma punya loopback interface, tanpa koneksi keluar sama sekali.

docker run --rm --network none alpine ip link show

Output perintah di atas cuma menampilkan satu interface, yaitu lo (loopback), membuktikan container ini benar-benar tidak punya akses jaringan eksternal. Driver ini cocok untuk container yang memang tidak butuh koneksi jaringan sama sekali, misalnya proses batch yang murni mengolah data lokal, atau untuk kebutuhan isolasi keamanan ekstra saat menjalankan proses yang tidak tepercaya.

13.2 Default Bridge Network

Setiap kali Docker Engine terpasang, sebuah bridge network bernama bridge otomatis tersedia dan menjadi network default untuk container yang dijalankan tanpa opsi --network. Memahami keterbatasan network ini penting supaya tidak salah asumsi soal cara container saling terhubung di dalamnya.

13.2.1 Cara Kerja Default Bridge

Cek keberadaan default bridge network lewat docker network ls.

docker network ls

NETWORK ID     NAME      DRIVER    SCOPE
c1a2b3d4e5f6   bridge    bridge    local
d2b3c4e5f6a7   host      host      local
e3c4d5f6a7b8   none      null      local

Ketiga network ini (bridge, host, none) selalu ada secara default di setiap instalasi Docker Engine, masing-masing mewakili driver bridge, host, dan none yang sudah dibahas sebelumnya. Container yang dijalankan tanpa opsi --network otomatis terhubung ke network bridge ini.

13.2.2 Keterbatasan Resolusi Nama di Default Bridge

Keterbatasan paling signifikan dari default bridge network adalah container yang terhubung padanya tidak mendapat resolusi DNS otomatis berdasarkan nama container. Buktikan langsung dengan menjalankan dua container di default bridge, lalu coba saling ping lewat nama container.

docker run -d --name web1 alpine sleep 3600
docker run -d --name web2 alpine sleep 3600
docker exec web1 ping -c 2 web2

Perintah ping di atas akan gagal dengan pesan semacam bad address 'web2', karena default bridge network memang tidak menyediakan DNS resolution otomatis antar container. Satu-satunya cara container saling terhubung di default bridge adalah lewat alamat IP masing-masing, yang bisa dicek lewat docker inspect.

docker inspect --format '{{.NetworkSettings.IPAddress}}' web2

docker exec web1 ping -c 2 172.17.0.3

Cara lama untuk mengatasi keterbatasan ini adalah opsi --link, tapi opsi ini sudah berstatus deprecated menurut dokumentasi resmi Docker dan sebaiknya tidak dipakai lagi untuk kebutuhan baru. Di lapangan, keterbatasan inilah alasan utama kenapa default bridge network jarang dipakai langsung untuk deployment aplikasi multi-container yang perlu saling terhubung; solusi yang lebih tepat adalah membuat custom bridge network sendiri.

13.2.3 Membersihkan Container Percobaan

Setelah selesai bereksperimen, hentikan dan hapus kedua container percobaan supaya tidak menumpuk di host.

docker rm -f web1 web2

13.3 Custom Bridge Network

Solusi paling umum untuk menghubungkan beberapa container di satu host sekaligus mendapat resolusi nama otomatis adalah membuat custom bridge network (disebut juga user-defined bridge network), yaitu bridge network yang dibuat secara eksplisit oleh pengguna, bukan network bridge bawaan Docker.

13.3.1 Membuat Custom Bridge Network

Buat custom bridge network lewat docker network create.

docker network create app-net

Kalau opsi -d tidak disertakan, Docker otomatis memakai driver bridge karena memang menjadi default. Menyertakan -d bridge secara eksplisit juga valid dan lebih jelas maksudnya bagi orang lain yang membaca perintah tersebut.

docker network create -d bridge app-net

Jalankan dua container yang terhubung ke app-net, lalu ulangi percobaan resolusi nama seperti sebelumnya.

docker run -d --name web1 --network app-net alpine sleep 3600
docker run -d --name web2 --network app-net alpine sleep 3600
docker exec web1 ping -c 2 web2

Kali ini perintah ping berhasil, karena custom bridge network menyediakan DNS resolution otomatis antar container yang terhubung padanya. Container web1 bisa menjangkau web2 langsung lewat namanya, tanpa perlu tahu alamat IP-nya sama sekali. Perilaku ini konsisten dipakai dalam kombinasi container dan database (misalnya container aplikasi menyambung ke container database cukup lewat nama db), tidak peduli host mana pun yang menjalankannya.

13.3.2 Menghubungkan Container yang Sudah Berjalan

Container yang sudah telanjur berjalan tanpa opsi --network tetap bisa dihubungkan ke custom bridge network belakangan, tanpa perlu membuat ulang container tersebut.

docker run -d --name web3 alpine sleep 3600
docker network connect app-net web3
docker exec web1 ping -c 2 web3

Perintah docker network connect menambahkan sebuah container ke network tambahan, membuat container tersebut punya lebih dari satu network sekaligus (misalnya tetap di default bridge sekaligus terhubung ke app-net). Sebaliknya, docker network disconnect melepaskan container dari sebuah network tanpa perlu menghentikan container itu sendiri.

docker network disconnect app-net web3

13.3.3 Alias Jaringan

Selain nama container itu sendiri, custom bridge network juga mendukung network alias, yaitu nama tambahan yang bisa dipakai container lain untuk menjangkau sebuah container di network yang sama. Fitur ini berguna misalnya saat ingin memberi nama generik seperti db ke sebuah container database, terlepas dari nama container aslinya.

docker run -d --name postgres-primary --network app-net --network-alias db postgres:16-alpine

Container lain di app-net bisa menjangkau container postgres-primary di atas cukup lewat alias db, tanpa perlu tahu nama container aslinya. Praktik ini memudahkan pergantian container backend (misalnya saat migrasi versi database) tanpa perlu mengubah konfigurasi koneksi di sisi aplikasi, selama alias yang dipakai tetap konsisten.

13.3.4 Menghapus Custom Network

Custom network yang tidak lagi dipakai bisa dihapus lewat docker network rm. Docker menolak menghapus network yang masih dipakai oleh container yang berjalan, sehingga lepaskan atau hentikan dulu seluruh container yang terhubung sebelum menghapus network-nya.

docker rm -f web1 web2 web3 postgres-primary
docker network rm app-net

Untuk membersihkan seluruh custom network yang sudah tidak dipakai container mana pun sekaligus, pakai docker network prune. Perintah ini menghapus iptables rule, bridge device, dan routing table entry yang terkait dengan network yang dihapus, jadi pastikan memang tidak ada network yang masih dibutuhkan sebelum menjalankannya di production.

docker network prune

13.4 Network Inspection

Saat komunikasi antar container bermasalah, langkah pertama Sysadmin/DevOps Engineer biasanya memeriksa konfigurasi network yang sedang dipakai, bukan langsung menebak penyebabnya dari log aplikasi. Docker menyediakan beberapa perintah inspeksi untuk kebutuhan ini.

13.4.1 Melihat Daftar Network

docker network ls menampilkan seluruh network yang ada di host, termasuk driver dan scope masing-masing, seperti sudah dipakai pada bagian sebelumnya. Gunakan opsi --filter untuk mempersempit hasil, misalnya cuma menampilkan network dengan driver bridge.

docker network ls --filter driver=bridge

13.4.2 Inspeksi Detail Network

docker network inspect menampilkan detail lengkap sebuah network dalam format JSON, termasuk subnet, gateway, dan daftar container yang sedang terhubung padanya.

docker network create app-net
docker run -d --name web1 --network app-net alpine sleep 3600
docker network inspect app-net

[
    {
        "Name": "app-net",
        "Driver": "bridge",
        "IPAM": {
            "Config": [
                {
                    "Subnet": "172.20.0.0/16",
                    "Gateway": "172.20.0.1"
                }
            ]
        },
        "Containers": {
            "a1b2c3d4e5f6": {
                "Name": "web1",
                "IPv4Address": "172.20.0.2/16"
            }
        }
    }
]

Bagian Containers pada output di atas jadi cara paling cepat memastikan sebuah container benar-benar terhubung ke network yang dimaksud, sekaligus melihat alamat IP yang dipakainya di network tersebut. Kalau container yang seharusnya terhubung tidak muncul di daftar ini, kemungkinan besar container tersebut belum di-attach lewat --network saat dijalankan atau docker network connect belum dieksekusi.

13.4.3 Memeriksa Network dari Sisi Container

Selain inspeksi dari sisi Docker Engine, periksa juga konfigurasi jaringan dari dalam container itu sendiri untuk memastikan interface dan resolusi DNS bekerja seperti yang diharapkan.

docker exec web1 ip addr show
docker exec web1 cat /etc/resolv.conf

Perintah ip addr show menampilkan interface jaringan beserta alamat IP yang dipakai container, sementara isi /etc/resolv.conf menunjukkan DNS server yang dipakai container untuk resolusi nama. Pada custom bridge network, Docker otomatis mengarahkan resolusi nama container ke DNS server internal miliknya sendiri, berbeda dari default bridge yang tidak menyediakan mekanisme ini sama sekali.

13.4.4 Troubleshooting Umum

Beberapa masalah jaringan yang sering ditemui di lapangan dan cara memeriksanya:

• Container tidak bisa saling ping lewat nama: pastikan kedua container berada di custom bridge network yang sama, bukan default bridge. Cek lewat docker network inspect apakah keduanya memang terdaftar sebagai anggota network yang sama.
• Port yang sudah di-publish tetap tidak bisa diakses dari luar host: periksa apakah proses di dalam container benar-benar listen di alamat 0.0.0.0, bukan cuma 127.0.0.1, karena binding ke localhost saja membuat port tersebut tidak terjangkau dari luar container meski sudah di-publish.
• Dua network dengan subnet yang tumpang tindih (overlapping): kalau custom network gagal dibuat karena konflik alamat, tentukan subnet secara eksplisit lewat opsi --subnet saat membuat network supaya tidak bentrok dengan network lain yang sudah ada.

docker network create --subnet=172.28.0.0/16 custom-net

Menentukan subnet secara eksplisit seperti ini juga berguna untuk lingkungan production yang perlu memastikan rentang alamat IP antar network tidak saling tumpang tindih, terutama kalau host tersebut menjalankan banyak custom network sekaligus.