Docker Bridge Network: Varsayılan Bridge ile Kullanıcı Tanımlı Bridge

Bridge ağı varsayılan olarak ne yapar?

Bir Docker bridge ağının bir IPv4 alt ağı ve isteğe bağlı bir IPv6 alt ağı vardır. Ağa bağlanan her container'ın bu alt ağlardan adres alan bir ağ arayüzü olur. Belgelere göre bir bridge ağı varsayılan olarak şunları yapar:

• Ağdaki container'lara sunucudan ve aynı ağdaki diğer container'lardan sınırsız erişime izin verir.
• Başka ağlardaki container'lardan ve sunucunun dışından gelen erişimi engeller.
• Container'lara masquerading ile dış ağ erişimi verir; sunucunun dış ağlarındaki cihazlar yalnızca sunucunun IP adresini görür.
• Port yayınlamayı destekler; container portları ile sunucu IP adreslerindeki portlar arasında trafik yönlendirilir ve yayınlanan portlara sunucunun dışından erişilebilir.

Docker bridge sürücüsü, farklı bridge ağlarındaki container'ların birbirine yalnızca yayınlanmış portlar üzerinden ulaşabilmesi için sunucuya otomatik olarak kurallar ekler. Bridge ağları tek bir Docker daemon sunucusuyla sınırlıdır. Farklı sunuculardaki container'ların haberleşmesi için ya işletim sistemi düzeyinde yönlendirme kurarsınız ya da Swarm ile bir overlay ağı kullanırsınız.

Aynı kullanıcı tanımlı bridge ağındaki container'lar birbirlerine bütün portlarını fiilen açık tutar. Bir portun başka ağlardaki container'lardan ya da Docker dışındaki makinelerden erişilebilir olması için -p veya --publish ile yayınlanması gerekir. Yani veritabanınızın portunu aynı ağdaki uygulama container'ı için yayınlamanız gerekmez; yayınlamak onu sunucunun dışına da açar.

Varsayılan bridge ile kullanıcı tanımlı bridge farkları

Belgeler farkları beş başlıkta toplar. Bunları sunucu kullanımı açısından tek tek ele alalım.

1. Otomatik DNS çözümlemesi

Varsayılan bridge ağındaki container'lar birbirine yalnızca IP adresiyle erişebilir; eskimiş (legacy) sayılan --link seçeneği bunun tek istisnasıdır. Kullanıcı tanımlı bir bridge ağında ise container'lar birbirini adıyla ya da takma adıyla (alias) çözer. Belgelerdeki örnekte web ve db adlı iki container varsa web, veritabanına db adıyla bağlanır; uygulama hangi sunucuda çalışırsa çalışsın bu ad değişmez. Varsayılan ağda aynı şeyi yapmak için iki yönde link kurmak ya da container'ların /etc/hosts dosyalarını elle düzenlemek gerekir; belgeler bu ikincisinin hata ayıklaması zor sorunlar çıkardığını belirtir.

2. Daha iyi yalıtım

--network belirtilmeyen bütün container'lar varsayılan bridge ağına bağlanır. Bu, birbiriyle ilgisi olmayan uygulamaların aynı ağda durup birbirine erişebilmesi demektir ve belgeler bunu bir risk olarak tanımlar. Kullanıcı tanımlı bir ağ, yalnızca o ağa bağlanan container'ların konuşabildiği kapsamlı bir alan oluşturur. Aynı VPS üzerinde birden fazla müşteri sitesi ya da birbirinden bağımsız projeler çalıştırıyorsanız her projeye ayrı bir ağ vermek, bir projedeki açığın diğerine sıçrama yolunu daraltır.

3. Çalışırken bağlama ve ayırma

Bir container'ı kullanıcı tanımlı ağlara çalışırken bağlayıp ayırabilirsiniz. Varsayılan bridge ağından çıkarmak içinse container'ı durdurup farklı ağ seçenekleriyle yeniden oluşturmanız gerekir.

4. Her ağ için ayrı yapılandırılabilen köprü

Varsayılan bridge ağını da yapılandırabilirsiniz, ancak bütün container'lar MTU ve iptables kuralları gibi aynı ayarları paylaşır. Üstelik bu yapılandırma Docker'ın dışında yapılır ve Docker'ın yeniden başlatılmasını gerektirir. Kullanıcı tanımlı ağlar ise docker network create ile oluşturulup o anda yapılandırılır; farklı uygulama gruplarının farklı ağ gereksinimleri varsa her ağı ayrı ayarlayabilirsiniz.

5. Ortam değişkeni paylaşımı

Eskiden iki container arasında ortam değişkeni paylaşmanın tek yolu onları --link ile bağlamaktı ve bu kullanıcı tanımlı ağlarda mümkün değildir. Belgeler daha iyi yollar önerir: ortak bilgiyi içeren bir dosya ya da dizini bir Docker volume ile birden fazla container'a bağlamak, container'ları Compose ile birlikte başlatıp değişkenleri Compose dosyasında tanımlamak ya da Swarm servislerinin secret ve config özelliklerini kullanmak. Docker Engine 29.0.0 sürüm notlarına göre eski linklerle container'a eklenen ortam değişkenleri kullanımdan kaldırılmıştır ve artık otomatik eklenmez; daemon DOCKER_KEEP_DEPRECATED_LEGACY_LINKS_ENV_VARS=1 ile başlatılarak geri getirilebilir, ama bu kaçış yolunun ileride kaldırılacağı belirtilir.

Kullanıcı tanımlı bridge ağını yönetmek

Ağ oluşturmak için sürücü belirtmeniz gerekmez; varsayılan sürücü zaten bridge'dir. Alt ağı, IP aralığını, ağ geçidini ve diğer seçenekleri oluştururken verebilirsiniz:

docker network create my-net

# Alt ağ, container adresleri için aralık ve ağ geçidiyle
docker network create \
  --subnet 172.28.0.0/16 \
  --ip-range 172.28.5.0/24 \
  --gateway 172.28.5.254 \
  my-net2

Yeni bir container oluştururken bir ya da birden fazla --network bayrağı verebilirsiniz. Belgelerdeki örnek bir Nginx container'ını my-net ağına bağlar ve container'ın 80 numaralı portunu sunucunun 8080 portuna yayınlar. my-net ağındaki diğer her container, my-nginx container'ının bütün portlarına erişebilir; tersi de geçerlidir:

docker create --name my-nginx \
  --network my-net \
  --publish 8080:80 \
  nginx:latest

Çalışan bir container'ı mevcut bir ağa bağlamak ve ondan ayırmak için şu komutlar kullanılır:

docker network connect my-net my-nginx
docker network disconnect my-net my-nginx

Ağı silmek için docker network rm kullanılır. Ağa bağlı container'lar varsa önce onları ayırmanız gerekir:

docker network rm my-net

Bridge sürücü seçenekleri (--opt)

Kullanıcı tanımlı bir bridge ağı oluştururken -o veya --opt ile sürücüye özel seçenekler verebilirsiniz. Belgelerdeki tablonun özeti şöyledir:

Bu seçeneklerden bazılarının dockerd komut satırında karşılığı vardır ve varsayılan docker0 köprüsünü daemon başlarken yapılandırmak için kullanılır: enable_ip_masquerade için --ip-masq, enable_icc için --icc, host_binding_ipv4 için --ip, mtu için --mtu. Bridge adı ve arayüz öneki için karşılık bulunmaz. Daemon ayrıca kendi docker0 köprünüzü tanımlamanıza yarayan bir --bridge bayrağını destekler; belgeler bunu aynı sunucuda birden fazla daemon çalıştırmak için önerir.

Pratikte en sık ihtiyaç duyulan iki seçenek şunlardır. host_binding_ipv4 değerini 127.0.0.1 yaparsanız o ağda sunucu adresi belirtilmeden yayınlanan portlar yalnızca sunucunun loopback adresinde açılır; bu, yanlışlıkla internete port açmayı önlemenin bir yoludur ve port yayınlama yazısında ayrıntılı anlatılıyor. enable_icc değerini false yaparsanız aynı ağdaki container'lar arasındaki doğrudan bağlantıyı kapatırsınız. Engine 29.9.0 sürüm notları, ICC kapalıyken aynı ağdaki başka bir container'dan yayınlanmış bir porta erişilememesi sorununun düzeltildiğini ve bu durumda IPv6 komşu keşfine (Neighbour Discovery) IPv4'teki gibi izin verildiğini kaydeder.

Bridge IP adresi yapılandırmasını atlamak

Bridge'e normalde ağın --gateway adresi atanır ve bu adres ağdan diğer ağlara giden varsayılan yol olarak kullanılır. com.docker.network.bridge.inhibit_ipv4 seçeneği ağ geçidi adresinin bridge'e atanmadan ağ oluşturulmasını sağlar. Belgelere göre bu, bridge'e fiziksel bir arayüz ekleyip ağ geçidi adresini ona vermek gibi elle yapılandırma senaryoları için kullanışlıdır. Bu durumda ağ geçidi adresini bridge'e ya da ona bağlı bir aygıta siz atamadıkça ağa giren ve ağdan çıkan trafik çalışmaz. Seçenek yalnızca kullanıcı tanımlı bridge ağlarında kullanılabilir.

Uygulamalı örnek: ad çözümleme ve yalıtım

Belgelerdeki uygulamalı örnek iki bridge türü arasındaki farkı somut olarak gösterir. Önce alpine-net adlı bir ağ oluşturulur, üç container bu ağa, bir container varsayılan bridge'e bağlanır, dördüncü container ise iki ağa birden bağlanır:

docker network create --driver bridge alpine-net
docker run -dit --name alpine1 --network alpine-net alpine ash
docker run -dit --name alpine2 --network alpine-net alpine ash
docker run -dit --name alpine3 alpine ash
docker run -dit --name alpine4 --network alpine-net alpine ash
docker network connect bridge alpine4

alpine1 içinden alpine2 adıyla ping atıldığında ad çözülür. Belgelerdeki çıktı şöyledir:

docker container attach alpine1

# ping -c 2 alpine2

PING alpine2 (172.18.0.3): 56 data bytes
64 bytes from 172.18.0.3: seq=0 ttl=64 time=0.085 ms
64 bytes from 172.18.0.3: seq=1 ttl=64 time=0.090 ms

--- alpine2 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.085/0.087/0.090 ms

Aynı container'dan varsayılan bridge'deki alpine3'e ne adıyla ne IP adresiyle ulaşılabilir; ad için ping: bad address 'alpine3' hatası alınır, IP adresine atılan ping ise yüzde 100 paket kaybıyla sonuçlanır. İki ağa birden bağlı olan alpine4 ise herkese ulaşır, ama alpine3'e yine yalnızca IP adresiyle: çünkü alpine3 ad çözümlemesi olmayan varsayılan ağdadır. Belgeler bir ayrıntıyı daha not eder: otomatik servis keşfi yalnızca sizin verdiğiniz container adlarını çözer, Docker'ın otomatik ürettiği adları çözmez. Durdurulan container'lar da IP adreslerini kaybeder.

docker container stop alpine1 alpine2 alpine3 alpine4
docker container rm alpine1 alpine2 alpine3 alpine4
docker network rm alpine-net

Varsayılan bridge ağını yapılandırmak

Belgeler varsayılan bridge ağını Docker'ın eski bir ayrıntısı olarak tanımlar ve üretimde önermez. Yine de bazı ayarlarını değiştirmeniz gerekebilir; örneğin varsayılan 172.17.0.0/16 alt ağı sunucunun bağlı olduğu bir ağla çakışıyorsa. Bu ayarlar daemon.json dosyasında yapılır ve yalnızca ihtiyaç duyduğunuz anahtarları yazmanız önerilir:

{
  "bip": "192.168.1.1/24",
  "fixed-cidr": "192.168.1.0/25",
  "mtu": 1500,
  "default-gateway": "192.168.1.254",
  "dns": ["10.20.1.2", "10.20.1.3"]
}

Bu örnekte köprünün adresi bip değerinden gelen 192.168.1.1/24'tür ve ağın alt ağı da yine bip'ten çıkan 192.168.1.0/24'tür. Container adresleri ise fixed-cidr ile verilen 192.168.1.0/25 aralığından dağıtılır. Değişikliklerin etkili olması için Docker'ı yeniden başlatmanız gerekir. Varsayılan bridge için IPv6 seçenekleri (ipv6, bip6, fixed-cidr-v6, default-gateway-v6) Docker IPv6 yapılandırma yazısında anlatılıyor. Daemon dosyasının genel kuralları için daemon.json yapılandırma yazısına bakın.

Varsayılan bridge'e bağlanan container'lar birbirleriyle konuşabilir, ama yalnızca IP adresiyle. Yeni kurulmuş bir sunucuda docker run ile ağ belirtmeden başlattığınız her container buraya düşer. Belgelerdeki örnekte iki container 172.17.0.2 ve 172.17.0.3 adreslerini alır ve birbirine IP ile ping atabilir, ama ping -c 2 alpine2 komutu ping: bad address 'alpine2' hatası verir.

Compose ile bridge ağları

Compose, bir proje için varsayılan olarak bridge sürücüsünü kullanan tek bir ağ oluşturur. Uygulamanız myapp adlı bir dizindeyse ağın adı myapp_default olur. Her servis bu ağa servis adıyla katılır ve dahili DNS'e kaydolur; bu sayede web servisi veritabanına postgres://db:5432 ile bağlanabilir. Servisten servise iletişim container portunu kullanır; sunucu portu yalnızca ağın dışından erişim içindir. Proje adını --project-name ya da COMPOSE_PROJECT_NAME ile değiştirebilirsiniz.

Aşağıdaki dosya iki bridge ağı tanımlar. front ağına özel bir köprü adı verilir; back ağı ise sabit bir alt ağ, container adresleri için bir aralık ve bir ağ geçidiyle oluşturulur. app servisi back ağında ek olarak api, db servisi database takma adıyla görünür ve db sabit bir IPv4 adresi alır. Dosya Docker CLI 29.8.1, Docker Compose v5.5.1 ile docker compose config --quiet doğrulamasından geçmiştir:

services:
  web:
    image: nginx:latest
    networks:
      - front
  app:
    image: example/app:latest
    networks:
      front:
      back:
        aliases:
          - api
  db:
    image: postgres:18
    networks:
      back:
        aliases:
          - database
        ipv4_address: 172.28.5.10

networks:
  front:
    driver: bridge
    driver_opts:
      com.docker.network.bridge.name: br-front
  back:
    driver: bridge
    ipam:
      config:
        - subnet: 172.28.0.0/16
          ip_range: 172.28.5.0/24
          gateway: 172.28.5.254

Compose başvuru belgesine göre sabit adres vermek için (ipv4_address, ipv6_address) üst düzey ağ tanımında bu adresleri kapsayan bir ipam alt ağ yapılandırması bulunmalıdır. Takma adlar ağ kapsamlıdır: aynı servis farklı ağlarda farklı adlarla görünebilir. Bir takma adı birden fazla container ya da servis paylaşırsa adın hangi container'a çözüleceği garanti edilmez. Yine de Compose belgeleri, container IP adreslerinin her başlatmada dinamik verildiğini ve yeniden oluşturmada değiştiğini hatırlatarak servislere her zaman adıyla erişmenizi önerir; sabit IP yalnızca gerçekten gerektiğinde kullanılmalıdır.

Servis yeniden oluşturulduğunda eski container kaldırılır ve yenisi aynı adla ama farklı bir IP adresiyle ağa katılır. Eski container'a açık bağlantılar kapanır; adı yeniden çözüp tekrar bağlanmak her container'ın kendi sorumluluğudur. Uygulamanızın veritabanı bağlantı havuzunun yeniden bağlanmayı desteklediğinden emin olun. Çok servisli Compose kullanımının temelleri Docker Compose rehberinde anlatılıyor.

Bağlantı sınırı ve diğer sınırlamalar

Belgelere göre Linux çekirdeğinin koyduğu sınırlar nedeniyle tek bir bridge ağına 1000 ya da daha fazla container bağlandığında ağ kararsızlaşır ve container'lar arası iletişim kopabilir. Bu kadar çok container'ı tek ağda toplamak yerine uygulamaları ayrı ağlara bölmek hem bu sınırdan kaçınmanızı hem de yalıtımı artırmanızı sağlar. IPv4 adres yapılandırması ayrıca varsayılan bridge ağında kapatılamaz; yalnızca IPv6 kullanan bir ağ istiyorsanız kullanıcı tanımlı bir ağı --ipv6 --ipv4=false ile oluşturmalısınız.

Sık yapılan hatalar

• Container adıyla bağlanmayı varsayılan ağda denemek: ad çözümleme yalnızca kullanıcı tanımlı ağlarda vardır.
• Veritabanı portunu "uygulama erişsin" diye yayınlamak: aynı ağdaki container'lar zaten bütün portlara erişir; yayınlamak portu sunucunun dışına açar.
• Otomatik üretilmiş container adıyla ad çözümlemeyi beklemek: servis keşfi yalnızca özel verilmiş adları çözer.
• Ağı silmeden önce container'ları ayırmamak: bağlı container varken docker network rm başarısız olur.
• Docker'ın oluşturduğu bridge aygıtlarını ve kuralları elle değiştirmek: belgeler bunları uygulama ayrıntısı sayar ve Docker'a bırakmanızı ister.

Sık Sorulan Sorular

docker0 nedir?

Varsayılan bridge ağının Linux üzerindeki köprü arayüzüdür. daemon.json içindeki bip, fixed-cidr, mtu gibi anahtarlarla yapılandırılır ve değişiklik için daemon yeniden başlatılır.

Kullanıcı tanımlı ağda container'lar neden birbirini adıyla buluyor?

Bu ağlardaki container'lar Docker'ın 127.0.0.11 adresindeki gömülü DNS sunucusunu kullanır; bu sunucu container adlarını ve takma adları çözer, dış adları sunucunun DNS sunucularına iletir.

İki farklı Compose projesini aynı ağda nasıl konuştururum?

Compose belgelerinin önerdiği yol, ağı bir kez docker network create ile oluşturup her iki projede external: true olarak tanımlamaktır. Ağ docker compose up öncesinde var olmalıdır, yoksa Compose Network not found hatası verir.

Bridge ağında MTU'yu nasıl değiştiririm?

Kullanıcı tanımlı ağ için -o com.docker.network.driver.mtu=... seçeneğini, varsayılan bridge için daemon.json içinde mtu anahtarını kullanırsınız.

Marka adları sahiplerine aittir. Bu yazı bağımsız bir teknik rehberdir; adı geçen kuruluşlarla bayilik veya ortaklık ilişkisi bulunduğu anlamına gelmez.

İlgili içerikler: Docker öğrenme rehberi · Docker network türleri · Docker port yayınlama · Docker iptables ve UFW · Docker IPv6 · Docker Compose rehberi