Overview #

Docker tidak hanya soal image dan container. Di balik kemampuan container untuk saling berbicara, diakses dari host, atau terhubung ke internet, ada satu lapisan yang sering dianggap “ajaib” padahal sebenarnya bisa dijelaskan secara struktural: Docker networking. Lapisan ini menentukan apakah container bisa saling menemukan satu sama lain, apakah service di dalam container bisa dijangkau dari luar, dan apakah aplikasi multi-container yang kamu bangun benar-benar aman.

Masalah klasik yang muncul pada pemula Docker adalah docker run jalan, tapi container tidak bisa saling komunikasi. Atau sebaliknya: container bisa bicara, tapi database-nya terekspos ke publik tanpa sengaja. Semua masalah itu berakar pada pemahaman network yang setengah-setengah. Begitu kamu memahami fondasi networking Docker, semua konfigurasi — docker network create, docker run --network, EXPOSE, -p, depends_on — terasa masuk akal.

Artikel ini adalah pondasi untuk seluruh section Network. Setelah membaca artikel ini, kamu akan memahami apa itu Docker networking, komponen internalnya (namespace, veth, bridge, iptables), perbedaan tiap network driver, kapan harus memilih yang mana, dan alur kerja yang akan kita bahas secara mendalam di artikel-artikel berikutnya. Artikel ini bersifat konseptual — contoh kode dan detail teknis akan muncul di artikel bridge, NAT, host, none, port mapping, dan seterusnya.

Kapan Harus Paham Docker Networking? #

Docker networking bukan topik yang berdiri sendiri. Ia muncul di hampir semua skenario: dari docker run nginx di laptop, sampai kluster Kubernetes dengan ratusan service. Tanda bahwa kamu perlu memahami topik ini dengan serius:

HARUS pahami Docker networking jika:
  ✓ Kamu menjalankan lebih dari satu container
  ✓ Aplikasi kamu butuh database atau message broker terpisah
  ✓ Kamu deploy ke production (cloud atau on-premise)
  ✓ Kamu menggunakan Docker Compose
  ✓ Kamu ingin secure service database dari internet
  ✓ Kamu debugging masalah "container tidak bisa connect"
  ✓ Kamu menyiapkan CI/CD dengan container

BELUM wajib jika:
  ✗ Kamu baru menjalankan satu container untuk eksperimen
  ✗ Kamu pakai layanan managed (RDS, Cloud SQL) di luar Docker
  ✗ Kamu hanya menjalankan container batch sekali jadi

Jika tiga atau lebih tanda di checklist “HARUS” berlaku untukmu, networking adalah keterampilan wajib, bukan opsional.

Konsep Dasar: Apa yang Terjadi Saat Container Berjalan? #

Setiap container Docker, sejak detik pertama dijalankan, sudah berinteraksi dengan lapisan jaringan di dalam host. Docker tidak melakukan sulap — ia menggunakan fitur Linux yang sudah matang: network namespace, virtual ethernet pair, bridge, dan iptables. Empat hal ini adalah fondasi yang perlu kamu pahami sebelum menyentuh network driver apapun.

flowchart LR
    A[docker run nginx] --> B[Docker Daemon]
    B --> C[Buat network namespace]
    B --> D[Buat veth pair]
    C --> E[Container: namespace baru]
    D --> F[Host: veth terhubung ke bridge]
    E <-->|veth| F
    F --> G[bridge: docker0 atau custom]
    G --> H[Host network fisik]
    H --> I[Internet]

Saat kamu menjalankan docker run nginx, Docker Engine melakukan hal berikut secara berurutan:

1. Membuat network namespace baru khusus untuk container itu. Namespace ini punya interface, routing table, dan iptables rule sendiri.
2. Membuat virtual ethernet (veth) pair — sepasang interface virtual yang saling terhubung. Satu ujung masuk ke namespace container (muncul sebagai eth0), ujung lain tetap di namespace host.
3. Menghubungkan ujung veth yang di host ke sebuah bridge (default docker0, atau user-defined bridge yang kamu buat).
4. Menambahkan aturan iptables untuk NAT, port forwarding, dan isolasi antar network.

Hasilnya: container punya IP address sendiri, bisa bicara ke container lain di bridge yang sama, dan bisa keluar ke internet lewat NAT — semuanya tanpa kamu harus konfigurasi Linux secara manual.

Mengapa kamu tidak perlu tahu detail Linux? Karena Docker menyembunyikan semua kompleksitas itu di balik CLI yang sederhana. Tapi untuk debugging, audit keamanan, dan desain arsitektur, memahami apa yang terjadi “di balik layar” sangat membantu. Artikel ini memberikan peta besarnya; artikel-artikel selanjutnya menggali lebih dalam.

Empat Pondasi Docker Networking #

Sebelum membahas driver, pahami dulu empat mekanisme Linux yang dipakai Docker. Keempatnya akan muncul berulang kali di artikel lain di section ini.

1. Network Namespace #

Network namespace adalah isolasi jaringan di level kernel Linux. Setiap namespace punya:

• Interface jaringan sendiri (eth0, lo, dll).
• Routing table sendiri.
• Aturan iptables sendiri.

Container berjalan di dalam namespace-nya sendiri. Akibatnya, container A tidak bisa “melihat” interface container B — keduanya terisolasi di level kernel.

Host Network Namespace
├── Container A Namespace (eth0: 172.17.0.2)
├── Container B Namespace (eth0: 172.17.0.3)
└── Container C Namespace (eth0: 172.17.0.4)

2. Virtual Ethernet (veth) #

veth adalah pasangan interface virtual yang selalu terhubung dua arah — apa yang masuk dari satu ujung keluar di ujung lain. Docker membuat veth pair untuk setiap container:

• Satu ujung (biasanya bernama eth0) masuk ke namespace container.
• Ujung lain tetap di namespace host, terhubung ke bridge.

Ini adalah “kabel virtual” antara container dan host. Tanpa veth, container benar-benar terisolasi.

3. Bridge #

Bridge adalah virtual switch layer-2 di Linux. Bridge menerima koneksi dari banyak veth (satu per container) dan meneruskan paket berdasarkan MAC address — persis seperti switch fisik.

Bridge default Docker bernama docker0. Setiap container yang dijalankan tanpa --network akan terhubung ke bridge ini. Kamu juga bisa membuat bridge custom dengan docker network create — ini yang disebut user-defined bridge dan akan jadi topik utama di beberapa artikel ke depan.

4. iptables / NAT #

iptables adalah firewall dan NAT engine di Linux. Docker menambah aturan iptables untuk:

• MASQUERADE (source NAT) — agar container bisa akses internet lewat IP host.
• DNAT (destination NAT) — untuk port mapping (-p 8080:80).
• FORWARD rules — untuk mengizinkan atau menolak traffic antar network.

Kamu tidak perlu menulis iptables manual — Docker mengelolanya. Tapi untuk debug, iptables -t nat -L -n adalah perintah pertama yang akan kamu pakai saat ada masalah network.

Jenis Network Driver: Peta Besar #

Docker punya lima network driver built-in. Masing-masing punya karakteristik dan use case yang berbeda. Memahami kapan harus memilih yang mana adalah keputusan arsitektur yang penting.

Penjelasan singkat tiap driver (akan dibahas mendalam di artikel masing-masing):

Bridge — driver paling umum. Container terhubung ke bridge virtual dan saling berkomunikasi lewat IP atau nama (jika user-defined). Cocok untuk hampir semua kasus local development dan single-host deployment.

Host — container menggunakan network stack host secara langsung. Tidak ada isolasi, tidak ada port mapping, tapi performa paling tinggi. Cocok untuk workload yang sensitif terhadap latency atau butuh throughput jaringan tinggi.

None — container tanpa network sama sekali. Hanya punya interface loopback. Cocok untuk batch job, sandbox, atau security hardening di mana container tidak boleh bicara ke luar.

Overlay — driver untuk multi-host. Container di host berbeda bisa saling berkomunikasi seolah-olah berada di network yang sama. Biasa dipakai di Docker Swarm dan Kubernetes.

Macvlan — container diberi IP address langsung dari network fisik host. Container terlihat seperti device tersendiri di LAN. Cocok untuk integrasi dengan sistem lama yang tidak bisa di-bridge.

Pilih driver dengan sengaja. Banyak developer meninggalkan container di default bridge tanpa berpikir panjang. Untuk development single-host, ini tidak masalah. Tapi untuk arsitektur multi-container yang butuh DNS, isolasi, dan scalability, user-defined bridge (artinya bridge yang kamu buat sendiri dengan docker network create) adalah pilihan yang jauh lebih aman dan fleksibel. Pembahasan detail di artikel Bridge dan User-defined Network.

Alur Kerja: Request dari Client Sampai ke Container #

Untuk memahami peran networking secara utuh, lihat alur tipikal request dari client (browser) ke aplikasi di dalam container, dan sebaliknya.

sequenceDiagram
    participant C as Client
    participant H as Docker Host
    participant I as iptables
    participant B as Bridge (docker0)
    participant V as veth
    participant CT as Container

    C->>H: GET http://host:8080
    H->>I: Terima paket di port 8080
    I->>I: DNAT: 8080 -> 172.17.0.2:80
    I->>B: Forward ke bridge
    B->>V: Lookup MAC, kirim ke veth
    V->>CT: Paket sampai di eth0 container
    CT-->>V: Response
    V-->>B: Kembali lewat bridge
    B-->>I: Source NAT (IP host)
    I-->>H: Paket keluar
    H-->>C: HTTP response sampai di client

Alur ini terjadi pada setiap request yang masuk lewat port mapping. Tanpa pemahaman alur ini, debugging masalah “request timeout” atau “connection refused” akan terasa seperti menebak-nebak.

Kalau baru mulai debugging masalah network Docker, urutan cek yang efektif:

1. docker ps — pastikan container jalan dan port mapping terlihat.
2. docker logs <container> — lihat apakah aplikasi di dalam container error atau tidak.
3. docker exec <container> sh -c "wget -qO- http://target:port" — test konektivitas dari dalam container.
4. iptables -t nat -L -n | grep <port> — pastikan rule NAT ada.
5. ip link show di host — pastikan bridge dan veth aktif.

Konsep Lanjutan yang Perlu Kamu Kenali #

Sebelum masuk ke artikel-artikel spesifik, ada tiga konsep yang akan sering kamu temui. Pahami dulu definisinya di sini, penjelasan detail menyusul di artikel masing-masing.

Port Mapping vs Port Exposure #

Ini dua hal yang sering tertukar:

# EXPOSE di Dockerfile — hanya metadata
EXPOSE 80

# Port mapping saat run — benar-benar membuka akses
docker run -p 8080:80 nginx

EXPOSE tidak membuka port ke host. Ia hanya informasi untuk dokumentasi dan tooling. Yang benar-benar membuka akses ke host adalah -p / --publish. Detail lengkap di artikel Port Mapping & Exposure.

NAT: Akses Keluar dan Masuk #

Container menggunakan IP private yang tidak bisa diakses dari internet. Untuk keluar (misal apt-get update) Docker pakai MASQUERADE (SNAT). Untuk masuk (misal curl http://localhost:8080) Docker pakai DNAT lewat port mapping. Detail lengkap di artikel NAT.

DNS Internal: Service Discovery Otomatis #

Pada user-defined network, container bisa saling memanggil hanya dengan nama container atau service name (di Compose). Tidak perlu hafal IP. Detail lengkap di artikel DNS Internal.

Decision Tree: Memilih Network Driver #

flowchart TD
    A{Multi-host?} -- Ya --> B{Pakai Swarm?}
    B -- Ya --> C[overlay]
    B -- Tidak --> D[bridge per host + service mesh]
    A -- Tidak --> E{Butuh performa tinggi?}
    E -- Ya --> F[host]
    E -- Tidak --> G{Butuh DNS antar container?}
    G -- Ya --> H[user-defined bridge]
    G -- Tidak --> I[default bridge / none]

Decision tree di atas bukan aturan kaku — hanya starting point. Untuk kebanyakan kasus, user-defined bridge adalah default yang aman dan fleksibel.

Anatomi File dan Perintah yang Akan Sering Kamu Pakai #

Berikut perintah-perintah Docker networking yang akan muncul berulang kali di artikel-artikel selanjutnya. Hafalkan dulu, nanti akan terasa natural.

# Lihat semua network di host
docker network ls

# Inspect detail satu network (subnet, gateway, container yang terhubung)
docker network inspect <nama-network>

# Buat user-defined network
docker network create my-network

# Jalankan container di network tertentu
docker run --network my-network --name app my-image

# Hubungkan container yang sudah jalan ke network lain
docker network connect my-network app

# Putuskan container dari network
docker network disconnect my-network app

# Hapus network (kalau tidak ada container yang terhubung)
docker network rm my-network

Kapan pakai docker network create? Setiap kali kamu butuh lebih dari satu container berkomunikasi dengan rapi. Untuk satu container random yang tidak butuh bicara ke container lain, default bridge cukup. Untuk aplikasi multi-container, selalu buat network.

Bagaimana Artikel-Artikel di Section Ini Saling Terhubung #

Section Network disusun berurutan. Tiap artikel membangun di atas artikel sebelumnya:

Kamu bisa membaca berurutan, atau loncat ke artikel yang sedang kamu butuhkan. Tapi untuk pemahaman utuh, urutan di atas adalah yang paling efektif.

Hubungan Docker Networking dengan Arsitektur Microservices #

Pada akhirnya, semua konsep di section ini bermuara ke satu hal: mendukung arsitektur microservices dengan baik. Microservices tanpa networking yang sehat akan rapuh. Mari kita lihat mengapa networking adalah pondasi yang tidak bisa ditawar.

flowchart TB
    subgraph Edge["Edge Layer"]
        LB[Load Balancer / Reverse Proxy]
    end

    subgraph App["Application Layer"]
        API1[API Service]
        API2[API Service]
    end

    subgraph Data["Data Layer"]
        DB[(Database)]
        Cache[(Cache)]
    end

    LB --> API1
    LB --> API2
    API1 <--> DB
    API2 <--> DB
    API1 <--> Cache

Pada arsitektur di atas:

• API Service berbicara dengan Database dan Cache lewat network internal.
• Load Balancer berbicara dengan API Service lewat port mapping.
• Setiap layer punya isolasi berbeda: edge terekspos ke internet, data layer benar-benar tersembunyi.

Inilah yang akan kamu rancang jika paham Docker networking. Tanpa pemahaman itu, biasanya semua container dijejer di satu bridge, database terekspos ke host, dan satu celah keamanan di service publik bisa dipakai untuk mengakses database internal.

Prinsip Dasar yang Patut Diingat #

Sebelum masuk ke artikel-artikel spesifik, catat tiga prinsip ini. Mereka akan menjadi kompas setiap kali kamu ragu mengambil keputusan networking.

1. Isolasi adalah default, bukan tambahan. Container secara default terisolasi dari satu sama lain. Kamu yang memutuskan untuk membuka isolasi itu — bukan sebaliknya. Kalau ragu, biarkan container terisolasi dan buka akses hanya yang benar-benar dibutuhkan.

2. Gunakan nama, bukan IP. IP container bisa berubah setiap restart. Nama container dan service name di Compose stabil. Biasakan menulis http://db:5432, bukan http://172.17.0.3:5432.

3. Network adalah bagian dari security perimeter. Memisahkan network frontend dan backend adalah salah satu bentuk defense in depth. Service yang tidak perlu bicara ke internet, jangan diberi akses. Service yang hanya untuk internal, jangan di-expose.

Kebanyakan masalah “container tidak bisa connect” berasal dari tiga hal: (1) container di network berbeda, (2) service di dalam container belum siap saat container lain coba konek, (3) port tidak di-expose atau di-publish. Ketiganya solvable kalau kamu paham konsep di section ini.

Ringkasan #

• Docker networking adalah lapisan yang memungkinkan container saling bicara, diakses dari host, dan terhubung ke internet. Ia dibangun di atas fitur Linux: namespace, veth, bridge, dan iptables.
• Network namespace mengisolasi interface, routing table, dan iptables tiap container — ini yang membuat container aman dari satu sama lain secara default.
• veth pair adalah “kabel virtual” antara container dan host. Bridge adalah switch virtual yang menghubungkan banyak container. iptables mengatur NAT dan firewall.
• Lima network driver punya kegunaan berbeda: bridge (umum), host (performa), none (sandbox), overlay (multi-host), macvlan (legacy LAN).
• Default bridge cocok untuk eksperimen, tapi user-defined bridge adalah pilihan serius untuk aplikasi multi-container — ada DNS internal, isolasi lebih baik, dan port mapping eksplisit.
• Port mapping (-p) berbeda dari port exposure (EXPOSE). Yang pertama benar-benar membuka akses; yang kedua hanya dokumentasi.
• NAT adalah mekanisme yang membuat container dengan IP private bisa akses internet (SNAT) dan bisa diakses dari host (DNAT).
• DNS internal di user-defined network memungkinkan container saling memanggil hanya dengan nama, bukan IP — fondasi untuk Docker Compose dan microservices.
• Untuk debugging, mulai dari docker ps → docker logs → docker exec test koneksi → iptables rule → ip link. Urutan ini menutup 90% masalah network.

← Sebelumnya: Sharing Data   Berikutnya: Bridge Network →