В чем различие между сетевыми режимами NAT и Bridge?

А, слушай, вот эта тема с NAT и Bridge — это как сравнивать, блядь, жить в коммуналке с одним общим телефоном или снять отдельную хату с прямой линией. Ёпта, сейчас разжуем.

NAT (Этажерка с одним выходом на балкон)

Представь: у тебя в квартире (это хост) стоит, сука, этажерка с кучей полок (это твои виртуалки или контейнеры). На каждой полке живёт по пиплу. У каждого свой внутренний номер комнаты (приватный IP). Но почту получают все на один адрес дома. Хули происходит?

• Как работает: Пипл с полки хочет в интернет — кричит в трубку домофона: «Хозяин, закажи мне пиццу!». Хозяин (NAT на хосте) звонит, заказывает, но говорит свой адрес. Пиццу привозят ему. Он орет: «Эй, Вася с третьей полки, это твоя пицца, на, жри!». Исходящий трафик — пожалуйста. А вот чтобы тебе позвонили прямо на полку — нихуя. Нужно хозяину заранее сказать: «Слушай, если звонок про Васю — соединяй сразу на мою полку». Это и есть проброс портов (port forwarding). Без него твой контейнер — невидимка, блядь.

• Плюсы, ёбана:
  — Безопасность, как в танке. Снаружи нихуя не видно, кто и на какой полке орёт.
  — Проще пареной репы. Включил — и уже работает, не надо ковыряться в роутере.
  — IP-адресов не жрёт, как саранча. Всё стадо сидит за одним внешним IP хоста.

• Когда это надо:
  Контейнеру просто надо в интернет — скачать пакеты, отправить метрики. Ему похуй, что его снаружи не видно. Docker, кстати, по умолчанию так и делает — сажает всё в NAT, чтоб не выёбывались.

Bridge (Мост, или «Я тоже здесь живу!»)

А это уже, блядь, серьёзнее. Ты берёшь и строишь виртуальный мост от своей квартиры (хоста) прямо до подъездной двери. И каждая твоя виртуалка или контейнер получает, сука, собственную прописку в этом же доме (сети). Как будто у тебя в квартире живут отдельные люди с отдельными звонками в дверь.

• Как работает: Ты создаёшь на хосте виртуальный свитч (мост). К нему подключаешь сетевые карты своих виртуалок. Они получают IP-адреса из той же подсети, что и твой хост (или из соседней, но с проходным двором). И всё — они теперь полноценные соседи в локальной сети. К ним можно обращаться напрямую, без посредников. Хочешь зайти на веб-сервер в контейнере? Пиши его IP в браузере — и ты внутри, блядь.

• Плюсы, охуенные:
  — Прямой доступ, ёбта. Никаких тебе пробросов. Другие компы в сети видят твой контейнер как родного.
  — Прозрачность, как у голого стекла. Сеть ведёт себя почти как железная.
  — Гибкость. Можно контейнеры между собой в одну сеть сгруппировать, чтобы они общались без всякого NAT, быстро и без костылей.

• Когда это надо:
  Когда разворачиваешь сервис, который должен быть виден другим. Веб-сервер, база данных, файловое хранилище. Или когда контейнеров много и они должны друг с другом болтать в своей изолированной пати.

Примеры из жизни Docker'а, чтоб вообще пиздец всё стало ясно:

• NAT (Дефолтное поведение для одиночек):

  docker run my_image  # Сидит в дефолтном бридже, который работает через NAT. Наружу не торчит.

  Контейнеру дали внутренний IP, он может в интернет, но снаружи к нему не подойти. Типичная жизнь интроверта.

• Кастомный Bridge (Для своих тусовок):

  docker network create --driver bridge my_cool_network  # Создал свою сетку
  docker run --network=my_cool_network my_image_1  # Посадил туда первого
  docker run --network=my_cool_network my_image_2  # И второго

  Теперь image_1 и image_2 могут общаться между собой по именам контейнеров, напрямую, быстро. Это их личный чат. Но чтобы из внешнего мира (не из хоста) до них достучаться — всё равно часто нужны пляски с бубном (настройка сети хоста или режим host).

Итог, блядь:
NAT — для изоляции и экономии, когда главное — дать доступ наружу.
Bridge — для интеграции и прямого доступа, когда нужно, чтобы к тебе могли прийти.

Выбирай по задаче, а не потому что «в документации так написали». Всё, рот меня чих-пых, вроде объяснил.