Peta konsep pada Chapter Konsep Networking Docker memperkenalkan docker0, veth pair, dan NAT masquerade sebagai tiga tokoh di balik layar — sekarang saatnya ketiganya kita jumpai secara langsung. Jaringan yang akan kita bedah adalah jaringan yang dipakai setiap container sejak awal course tanpa kita minta: bridge default. Kita akan melihatnya dari tiga sudut sekaligus — dari luar lewat docker network inspect, dari dalam lewat ip addr milik container, dan dari jauh lewat ping ke 8.8.8.8 yang membuktikan masquerade bekerja. Chapter ini ditutup dengan satu kelemahan default bridge yang paling terkenal, kelemahan yang akan mengubah cara kita menjalankan container untuk sisa course ini.

Tiga Jaringan yang Selalu Ada #

Instalasi Docker yang bersih selalu membawa tiga jaringan bawaan. Perintah berikut mendaftarkannya:

bash 
$ docker network ls

Output yang Dihasilkan:

text 
NETWORK ID     NAME      DRIVER    SCOPE
9e7d2c4b1a8f   bridge    bridge    local
3f8a6d2c9e4b   host      host      local
7c1e9a3d5f2b   none      null      local

Mari kita telaah kolom-kolomnya satu per satu:

  1. NETWORK ID — pengenal 12 karakter heksadesimal, padanan CONTAINER ID pada docker ps; bentuk penuhnya 64 karakter dan akan tampil pada docker network inspect.
  2. NAME — nama jaringan; ketiga nama ini adalah nama tetap yang sama di semua instalasi Docker, sehingga cocok dipakai sebagai rujukan lintas mesin.
  3. DRIVER — driver yang membangun jaringan; perhatikan jaringan bernama none justru tercatat dengan driver null, bukan none — istilah “null” memang istilah teknis untuk driver yang tidak membangun konektivitas apa pun, dan bedah lengkapnya menunggu di Chapter None Network.
  4. SCOPE — cakupan jaringan; local berarti jaringan hanya hidup pada host ini, berbeda dengan cakupan swarm yang membentang lintas host.

Setiap docker run tanpa flag --network menempelkan container ke jaringan bridge yang pertama itu. Seluruh demo kita sejak Section Dasar Docker CLI — container web, db-katalog, hingga latihan volume — diam-diam berbagi satu switch virtual yang sama. Saatnya kita buka kubahnya.

Bedah docker network inspect bridge #

Metadata lengkap jaringan default tersimpan dan bisa dibaca dengan satu perintah:

bash 
$ docker network inspect bridge

Output yang Dihasilkan:

json 
[
    {
        "Name": "bridge",
        "Id": "9e7d2c4b1a8f4c6e8a0b2d4f6a8c0e2b4d6f8a0c2e4b6d8f0a2c4e6b8d0f2a4c",
        "Created": "2026-10-13T08:12:09.418273521Z",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "172.17.0.0/16",
                    "Gateway": "172.17.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {},
        "Options": {
            "com.docker.network.bridge.default_bridge": "true",
            "com.docker.network.bridge.enable_icc": "true",
            "com.docker.network.bridge.enable_ip_masquerade": "true",
            "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
            "com.docker.network.bridge.name": "docker0",
            "com.docker.network.driver.mtu": "1500"
        },
        "Labels": {}
    }
]

Waktu Created menunjukkan pukul 08:12 pagi — daemon Docker Budi menyala sejak itu, dan jaringan bridge lahir bersamanya. Mari kita telaah bagian-bagian terpentingnya:

  1. IPAM.Config — pengaturan alamat: subnet 172.17.0.0/16 dengan gateway 172.17.0.1. Inilah angka-angka yang selama ini hanya kita lihat dari sisi container; 172.17.0.1 adalah alamat docker0 sendiri, bendahara alamat bagi semua container yang tercolok.
  2. com.docker.network.bridge.name: docker0 — nama interface bridge di namespace host; opsi ini menghubungkan jaringan bernama bridge dengan interface docker0 yang kita kenal dari diagram topologi chapter sebelumnya.
  3. com.docker.network.bridge.enable_ip_masquerade: true — sakelar NAT yang kita bahas sebagai konsep kini terlihat sebagai baris konfigurasi nyata; nilainya true, dan itulah alasan container bisa menjangkau internet.
  4. Containers kosong — daftar penghuni jaringan saat ini; pukul ini tidak ada container yang hidup di mesin latihan kita, sehingga objeknya kosong — kita akan mengisinya lagi segera.

Stack Jaringan Sebuah Container di Bridge Default #

Sekarang kita masuk ke dalam rumah container itu sendiri. Satu container Alpine sekali jalan cukup untuk memotret seluruh isi network namespace-nya:

bash 
$ docker run --rm alpine:3.20 ip addr

Output yang Dihasilkan:

text 
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0@if15: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
    link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.2/16 scope global eth0
       valid_lft forever preferred_lft forever

Mari kita telaah baris demi baris:

  1. lo dengan 127.0.0.1/8 — loopback bawaan setiap network namespace; aplikasi di dalam container yang menyambung ke localhost mendarat di interface ini, bukan di loopback host.
  2. eth0@if15 — kartu jaringan utama container; akhiran @if15 adalah nomor interface pasangan di sisi host, jejak veth pair yang dijelaskan pada Chapter Konsep Networking Docker — kabel virtual dua ujung itu terbaca namanya di sini.
  3. inet 172.17.0.2/16 — alamat pertama yang dibagikan bendahara docker0 setelah alamat gateway 172.17.0.1 diambil sang bridge; container ini menjadi penghuni pertama, jadi kebagian nomor dua.
  4. MAC 02:42:ac:11:00:02 — alamat hardware kartu virtual ini menyimpan rahasia kecil yang menarik untuk dibedah, dan bedahnya ada di uraian berikutnya.

MAC address tersebut tidak dipilih secara acak. Docker menyusunnya dari dua bagian: prefiks 02:42 menandai alamat yang dikelola secara lokal (locally administered), lalu empat byte terakhir adalah alamat IP container ditulis dalam heksadesimal — ac adalah 172, 11 adalah 17, 00 adalah 0, dan 02 adalah 2, sehingga ac:11:00:02 terbaca sebagai 172.17.0.2. Dengan menyandikan alamat IP ke dalam MAC, Docker memastikan tidak ada dua container di bridge yang sama yang kebetulan memakai MAC identik.

Menembus ke Internet: Masquerade Bekerja #

Teori NAT masquerade sudah kita bangun di chapter sebelumnya; sekarang kita uji dengan target yang paling mudah dikenali:

bash 
$ docker run --rm alpine:3.20 ping -c 2 8.8.8.8

Output yang Dihasilkan:

text 
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=114 time=13.2 ms
64 bytes from 8.8.8.8: seq=1 ttl=113 time=12.8 ms

--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 12.8/13.0/13.2 ms

Mari kita telaah apa yang barusan terjadi di balik dua baris 64 bytes itu:

  1. Container tidak punya alamat publik — namespace container hanya memegang 172.17.0.2, alamat privat yang tidak dikenal router internet; paketnya sampai ke 8.8.8.8 karena kernel host menulis ulang alamat sumbernya menjadi 192.168.1.15 lewat aturan masquerade pada opsi enable_ip_masquerade yang barusan kita lihat di inspect.
  2. Balasan menemukan jalan pulang — 8.8.8.8 membalas ke 192.168.1.15, dan tabel terjemahan di kernel host mengarahkan balasan itu kembali ke 172.17.0.2 di dalam namespace container; proses ping sama sekali tidak menyadari adanya penerjemahan.
  3. ttl=114 — waktu hidup paket terhitung dari server Google ke host Budi; angka ini menunjukkan paket melintasi belasan hop router sebelum tiba, dan seluruh perjalanan pulangnya diterjemahkan dua kali oleh NAT tanpa satu paket pun tersesat.

Port Publishing di Balik Layar #

Jalur keluar ke internet kini terbukti; jalur masuk dari luar adalah cerita yang sudah pernah kita kerjakan. Flag -p 8080:80 pada Chapter Port Publishing bekerja dengan menulis aturan DNAT di kernel host: paket yang tiba di port 8080 milik host ditulis ulang tujuannya menjadi 172.17.0.2:80 sebelum diteruskan ke container. Kita replay mekanismenya secara singkat:

bash 
$ docker run -d --name web -p 8080:80 nginx

Output yang Dihasilkan:

text 
f7c2a91b3e55913c4a5f1c6c0a4d8e2b3f4a5b6c7d8e9f0a1b2c3d4e5f60718a
bash 
$ curl -sI localhost:8080

Output yang Dihasilkan:

text 
HTTP/1.1 200 OK
Server: nginx/1.29.4
Date: Tue, 13 Oct 2026 18:15:03 GMT
Content-Type: text/html
Content-Length: 615
Last-Modified: Mon, 12 Oct 2026 09:24:17 GMT
Connection: keep-alive
ETag: "6779f57d-267"
Accept-Ranges: bytes

Respons 200 OK itu menempuh dua lapis penerjemahan: dari port 8080 di host menuju port 80 di container lewat DNAT, lalu balasannya diterjemahkan balik. Perlu dicatat bahwa dari sudut pandang nginx, klien yang datang tampak berasal dari 172.17.0.1 — alamat docker0 — persis seperti yang kita saksikan pada baris-baris access log di Chapter Melihat Log Container. Port publishing dan NAT masquerade sesungguhnya adalah dua arah dari mesin penerjemahan alamat yang sama.

Kelemahan Default Bridge: Tanpa DNS #

Sampai di sini default bridge tampak sempurna — konektivitas antar container, jalan keluar ke internet, dan pintu masuk dari luar semuanya bekerja. Kelemahannya baru muncul ketika kita meminta hal yang paling wajar di dunia aplikasi: memanggil tetangga dengan nama. Kita siapkan dua container yang saling bekerja sama, keduanya di jaringan bawaan yang sama:

bash 
$ docker run -d --name web-a nginx

Output yang Dihasilkan:

text 
2d9f4c7b1a5e6b8d0f2a4c6e8a1c3e5b7d9f0a2c4e6b8d0f1a3c5e7b9d0f2a4c
bash 
$ docker run -d --name app alpine:3.20 sleep 1h

Output yang Dihasilkan:

text 
6c1e8a4b2f9d0b2d4f6a8c1e3b5d7f9a0c2e4b6d8f0a2c4e6b8d0f1a3c5e7b9d

Kedua container kini menjadi tetangga terdekat di bridge yang sama — web masih memegang 172.17.0.2 dari recap port publishing, web-a menempati 172.17.0.3, dan app menempati 172.17.0.4. Dari dalam app, kita coba menyapa web-a dengan namanya:

bash 
$ docker exec app ping -c 2 web-a

Output yang Dihasilkan:

text 
ping: bad address 'web-a'

Sapaan itu ditolak mentah-mentah. Namun konektivitasnya sendiri tidaklah rusak — buktinya, memanggil alamat IP milik web-a secara langsung tetap berhasil:

bash 
$ docker exec app ping -c 2 172.17.0.3

Output yang Dihasilkan:

text 
PING 172.17.0.3 (172.17.0.3): 56 data bytes
64 bytes from 172.17.0.3: seq=0 ttl=64 time=0.089 ms
64 bytes from 172.17.0.3: seq=1 ttl=64 time=0.117 ms

--- 172.17.0.3 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.089/0.103/0.117 ms

Mari kita telaah pasangan keberhasilan dan kegagalan di atas:

  1. bad address berarti nama tidak diterjemahkan — pesan galat ini keluar saat proses resolusi nama gagal, sebelum satu paket pun dikirim; default bridge tidak menyediakan server DNS untuk nama container, sehingga web-a tidak pernah berubah menjadi 172.17.0.3 di mata app.
  2. Ping lewat IP berhasil mulus — time di bawah 0.2 milidetik menandakan perjalanan lurus lewat docker0 tanpa keluar host; masalahnya murni soal nama, bukan soal jalur.
  3. Mekanisme --link adalah warisan lama — pada masa lalu, flag --link pada docker run bisa menyuntikkan entri nama antar container di default bridge; mekanisme itu telah ditinggalkan dan tidak boleh dipakai lagi pada instalasi Docker modern, sehingga default bridge benar-benar tanpa DNS.

Jalan keluarnya terlihat menggoda: catat saja alamat IP-nya. Jalan itu adalah jebakan.

Sebelum pindah, kita bersihkan meja latihan dari chapter ini:

bash 
$ docker rm -f web web-a app

Output yang Dihasilkan:

text 
web
web-a
app

Default bridge telah menunjukkan wibawa dan cacatnya sekaligus: konektivitas dan NAT bekerja tanpa komando, tetapi nama container tidak bisa dipanggil. Sebelum kita membangun jaringan sendiri yang memperbaiki cacat itu, ada satu mode jaringan yang bergerak ke arah sebaliknya — melepas isolasi sepenuhnya dan menumpang langsung pada stack jaringan host. Chapter Host Network membedah mode paling agresif ini, lengkap dengan konsekuensi yang wajib dipahami sebelum memakainya.

Referensi #