Data aplikasi kita kini berada di posisi yang nyaman: volume menyimpannya melewati kematian container, arsip backup bisa dipulihkan kapan pun, dan angka UID/GID tidak lagi mengejutkan siapa pun. Tetapi penutup Section Penyimpanan Data meninggalkan satu pengamatan yang mengganjal — container kita masih saling asing: aplikasi web belum bisa menyapa database tetangganya, dan dunia luar baru bisa menyentuh container lewat port yang diterbitkan satu per satu. Mengubah container yang bisu menjadi mampu berbicara adalah pekerjaan Section Jaringan Container, dan pekerjaan itu berdiri di atas satu ketegangan mendasar: isolasi yang kita bangun sejak awal course justru menjadi penghalang begitu aplikasi butuh bekerja sama. Chapter ini memetakan fondasinya — network namespace, veth pair, bridge docker0, dan NAT — supaya setiap perintah pada chapter berikutnya terbaca sebagai kendali atas mesin yang sudah kita pahami, bukan hafalan flag.

Dua Tuntutan yang Saling Tarik: Isolasi dan Konektivitas #

Isolasi jaringan bukan fitur tambahan di Docker — isolasi adalah kondisi bawaan. Setiap container dilahirkan bersama network namespace sendiri, tempat kernel Linux menyediakan salinan kartu jaringan, tabel routing, dan ruang port yang tidak terlihat oleh container lain. Dua container yang sama-sama menjalankan nginx boleh sama-sama mendengarkan port 80 tanpa saling menabrak, persis seperti dua rumah yang masing-masing punya pintu bernomor sama. Kita sudah pernah melihat baris net pada tabel namespace di Chapter Arsitektur Docker; sekarang baris itu menjadi panggung utama.

Di sisi lain, aplikasi nyata hampir tidak pernah hidup sendirian. Sebuah aplikasi web memanggil database, database ditanya oleh skrip migrasi, proxy meneruskan permintaan ke backend — semua itu menuntut konektivitas. Tuntutannya bukan sekadar “bisa terhubung”, melainkan terhubung dengan cara yang terkendali: aplikasi boleh bicara dengan database di jaringan yang sama, tetapi tidak boleh dengan bebas mengintip container lain, apalagi interface host. Docker menjawab kedua tuntutan sekaligus dengan satu benda yang akan kita temui berulang kali di section ini: bridge — semacam switch virtual di dalam host yang menghubungkan container-container pilihan, lengkap dengan gerbang keluar yang dijaga NAT.

Network Namespace: Rumah Jaringan Sendiri #

Mari kita telaah apa sebenarnya yang dimiliki sebuah container ketika kernel menciptakan network namespace untuknya. Namespace ini membungkus tiga hal sekaligus, dan ketiganya menjelaskan mengapa container terasa seperti mesin terpisah:

  1. Interface jaringan — container melihat daftar kartu jaringannya sendiri: lo untuk loopback dan satu eth0 sebagai pintu utama; kartu LAN fisik host tidak terlihat sama sekali dari dalam.
  2. Tabel routing — container membawa aturan keputusannya sendiri, misalnya “semua tujuan 172.17.0.0/16 dikirim lewat eth0, sisanya diserahkan ke gateway”; host punya tabel yang berbeda isinya.
  3. Ruang port — nomor port 80 milik container A dan nomor port 80 milik container B adalah dua sumber daya yang berbeda; tidak ada tabrakan karena keduanya hidup di namespace yang berbeda.

Rumah yang lengkap tapi tanpa kabel inilah titik awal setiap container. Kernel tidak menyediakan jalan keluar otomatis dari sebuah network namespace — konektivitas harus dipasang secara sengaja. Di sinilah Docker turun tangan dengan dua perkakas berikutnya.

veth Pair: Kabel Virtual Dua Ujung #

veth (virtual ethernet) pair adalah pasangan interface yang dilekatkan kernel seperti kabel: paket yang masuk ke satu ujung keluar di ujung lainnya, begitu pula sebaliknya. Docker memakai kabel virtual ini sebagai tali penghubung antara rumah container dan dunia luar:

  1. Docker menciptakan sepasang interface di namespace host.
  2. Salah satu ujung dipindahkan ke dalam namespace container, lalu diberi nama eth0 — inilah kartu jaringan utama yang dilihat aplikasi di dalam container.
  3. Ujung satunya tetap tinggal di namespace host dan dicolokkan ke sebuah bridge bersama ujung-ujung container lain.

Nama eth0@if15 yang akan muncul pada output chapter berikutnya adalah jejak kerja pasangan ini: bagian setelah tanda @ menunjuk nomor interface pasangannya di sisi host. Kedua interface memang saling mengetahui — mereka adalah dua wajah dari satu kabel yang sama.

docker0: Switch Virtual di Dalam Host #

Bridge Linux bernama docker0 adalah alat yang dijadwalkan daemon Docker sejak pertama kali menyala. Perannya persis seperti switch di ruang server: setiap ujung veth container dicolokkan ke bridge ini, sehingga container-container dapat saling mengirim paket tanpa perlu meninggalkan host. Bridge docker0 memiliki alamat IP sendiri, 172.17.0.1 pada jaringan 172.17.0.0/16, dan alamat itu sekaligus berperan sebagai gateway default bagi setiap container yang tercolok — semua paket yang ditujukan ke luar jaringan bridge diserahkan ke 172.17.0.1 ini.

Container pertama yang tercolok mendapat alamat 172.17.0.2, container berikutnya 172.17.0.3, dan seterusnya dari kumpulan alamat 172.17.0.0/16. Komunikasi antar container pada bridge yang sama mengalir langsung lewat docker0: paket dari 172.17.0.2 menuju 172.17.0.3 tidak pernah meninggalkan host, tidak melewati NAT, dan tidak menyentuh kartu jaringan fisik — perjalanan selesai di dalam switch virtual.

NAT Masquerade: Pintu Keluar ke Internet #

Alamat 172.17.x.x adalah alamat privat — router-router di internet tidak bersedia meneruskan paket dengan alamat sumber semacam itu. Ketika sebuah container menjangkau 8.8.8.8, host Linux melakukan penerjemahan alamat bernama masquerade: kernel mengganti alamat sumber paket dari 172.17.0.2 menjadi alamat host itu sendiri, meneruskan paket ke internet seolah berasal dari host, lalu menerjemahkan balasan yang kembali ke alamat container aslinya. Container seolah-olah meminjam identitas host-nya setiap kali keluar rumah. Topologi lengkap perjalanan paket dari container sampai internet tampak seperti ini:

Diagram di atas memadatkan seluruh konsep chapter ini ke satu gambar. Mari kita telaah peran setiap elemennya:

  1. Container A dan Container B — dua rumah jaringan terpisah; masing-masing hanya melihat lo dan eth0 miliknya sendiri, dengan alamat privat dari kumpulan 172.17.0.0/16.
  2. veth pair — kabel virtual dua ujung yang menjadi satu-satunya pintu keluar rumah container; satu ujung menjadi eth0 di dalam namespace, ujung satunya tercolok di docker0.
  3. docker0 — switch virtual milik host dengan alamat 172.17.0.1; lalu lintas antar container selesai di sini, sementara lalu lintas ke luar diteruskan naik ke lapisan berikutnya.
  4. NAT masquerade — pos penerjemahan alamat di kernel host; paket keluar dari container diganti alamat sumbernya menjadi alamat host, dan balasannya diterjemahkan kembali.
  5. eth0 host — kartu jaringan fisik Budi beralamat 192.168.1.15; kartu inilah identitas yang dipakai container ketika bicara dengan dunia luar.
  6. Internet — tujuan akhir; dari sisi internet, seluruh container di host Budi tampak sebagai satu mesin dengan alamat 192.168.1.15.

Peta Enam Driver Jaringan #

Bridge dengan docker0 adalah pilihan bawaan Docker, tetapi bukan satu-satunya. Driver jaringan menentukan bagaimana sebuah network dibangun di balik layar, dan Docker menyediakan enam driver resmi dengan wilayah kerja masing-masing:

DriverCara kerja singkatKapan dipakai
bridgeSwitch virtual dalam satu host; container terhubung lewat veth pairDefault — komunikasi antar container pada satu host
hostContainer memakai stack jaringan host langsung, tanpa namespace terpisahButuh akses penuh ke interface host atau kinerja jaringan maksimal
noneNamespace tetap dibuat, tetapi tanpa interface selain loopbackIsolasi total — batch job dan komputasi tanpa akses jaringan
overlayJaringan virtual lintas host lewat enkapsulasi paketContainer di beberapa host fisik saling terhubung sebagai satu network
macvlanContainer mendapat MAC address sendiri di jaringan fisikContainer harus tampil sebagai perangkat nyata di LAN, misalnya bagi sistem DHCP lama
ipvlanContainer berbagi MAC address induk dengan alamat IP unikLingkungan yang membatasi mode NIC atau membatasi jumlah MAC per port

Port Publishing versus Komunikasi Antar Container #

Dua arah lalu lintas yang berbeda sering tertukar di mata pemula, padahal keduanya memakai mekanisme yang sama sekali berbeda. Tabel berikut memisahkannya:

Arah lalu lintasMekanisme yang bekerjaKapan dipakai
Luar host → container (port publishing)Flag -p 8080:80 membuat aturan DNAT: paket yang datang ke port host ditulis ulang tujuannya ke alamat containerBrowser, proses host, atau mesin lain menjangkau container
Container → container dalam satu bridgeLangsung lewat docker0 dengan alamat IP privat — tanpa flag apa pun, tanpa NATAplikasi memanggil database atau service tetangga di jaringan yang sama

Port publishing adalah pintu dari luar ke dalam; komunikasi antar container adalah lorong internal yang tidak membutuhkan pintu itu sama sekali. Perhatikan konsekuensinya: sebuah aplikasi web dan database-nya cukup berada di bridge yang sama untuk saling menjangkau, sementara browser di laptop Budi tetap membutuhkan -p karena berasal dari luar bridge.

Ada satu kepingan terakhir yang membuat gambar ini lengkap. Komunikasi antar container lewat alamat IP itu bisa, tetapi rapuh — alamat IP container berubah setiap kali container diciptakan ulang. Docker menyediakan DNS internal pada alamat 127.0.0.11 supaya container bisa memanggil tetangganya dengan nama, bukan angka; syaratnya, container harus berada pada network buatan sendiri, bukan bridge default. Kita akan membedah DNS ini tuntas pada Chapter Container DNS, setelah tangan kita berkotor dengan perintah-perintah jaringan yang sebenarnya.

Kita mulai dari jaringan yang dipakai setiap container tanpa kita minta: bridge default dengan docker0 sebagai bendaharanya. Chapter Bridge Network mengambil alih — membedah jaringan bawaan itu dari docker network ls sampai kelemahannya yang paling terkenal.

Referensi #