Документ обсуждает различные подходы к управлению сетевыми настройками в Docker, включая использование маршрутизируемых IP и различные типы сетевых интерфейсов, таких как bridge, macvlan и overlay. Рассматриваются плюсы и минусы каждого решения, а также их влияние на производительность и управление контейнерами. В конце подводятся итоги о предпочтениях в использовании сетевых решений в зависимости от конкретных нужд.

1. Каждому контейнеру
- по IP
Konstantin Nazarov [@racktear]

2. Docker и сеть

3. Мой случай: Tarantool облако

4. Требование1:
Маршрутизируемый IP

5. Требование2:
Связь между контейнерами

6. Зачем нужен внешний IP
• Внешние системы без service discovery
• Маленький downtime при "переезде"
• Можно обойтись без оркестрации

7. Так в чем проблема?

8. Так в чем проблема?

9. Так в чем проблема?
Docker сам настраивает Bridge

10. Опция 1: port forwarding

11. Опция 2: load balancer

12. Все еще не то
• Балансировщик нужно настраивать
• Есть одна точка отказа
• Сложно управлять

13. Как это работает

14. Обычная конфигурация

15. veth
$ ip link add veth0 type veth peer name veth1

16. network namespace
$ ip link set veth1 netns ns1

17. И собственный TCP/IP стек

18. Port Forwarding

19. Решение 1: NAT

20. Добавим еще один IP на хост
$ ip addr add <IP2> dev eth0

21. Форвардим порты контейнера на IP2
$ docker run -p <IP2>:80:80

22. Опционально: SNAT

23. Pros
• Работает "из коробки"
• Просто в обслуживании

24. Cons
• Не работает через Docker API

25. Решение 2: pipework

26. Решение 2: bridges
Вручную или через pipework

27. Pipework
$ docker run -name web1 -d apache
$ pipework mybridge web1 <IP>

28. Pipework
$ docker run -name web1 -d apache
$ pipework mybridge web1 <IP>

29. Pros
• Гибко
• Просто
• Можно сделать еще много интересного

30. Cons
• Не делается через Docker API
• Сложно встраивать в init/systemd

31. Решение 3: macvlan

32. macvlan
виртуальный интерфейс без "пары"

33. macvlan
можно "отдать" в контейнер

34. Pros
• Работает очень быстро
• Поддерживается pipework
• Поддерживается в docker-experimental

35. Cons
• Контейнеры не видны с хоста (без хаков)
• Требует пересборки докера
• (Или недоступно через API)

36. Решение 4: overlay net
(или vxlan)

37. vxlan

38. vxlan в докере

39. + хостовый интерфейс

40. Pros
• Хорошая изоляция
• Работает из коробки
• Работает с Docker Swarm

41. Cons
• Требует внешнего KV хранилища
• Сложно "пустить" трафик снаружи
• Требует отдельного контейнера для роутинга

42. Решение 5: weave

43. weave
• Использует vxlan "под капотом"
• Может работать поверх "неудобных" топологий
• Имеет свой service discovery
• ... и load balancing

44. Pros
• Работает как плагин к libnetwork
• Можно использовать через Docker API
• Можно попасть в overlay с хоста (expose)

45. Cons
• Много компонентов
• Нужен Docker API Proxy
• Имеет свой собственный gossip/kv хранилище

46. Решение 6: bridge

47. libnetwork

48. Вопросы:
• Как докер создает бридж?
• Как он его конфигурирует?

49. bridgeAlreadyExists := bridgeIface.exists()
if !bridgeAlreadyExists {
bridgeSetup.queueStep(setupDevice)
}
// Even if a bridge exists try to setup IPv4.
bridgeSetup.queueStep(setupBridgeIPv4)

50. Выводы
• Можно модифицировать бридж "извне"
• Но не IPv4 настройки: их "заменит"

51. В заключение

52. • Стандартные бриджи медленнее openvswitch
• Если нужна скорость - macvlan
• В другом случае - лучше бриджи (это просто)
• Overlay - с осторожностью

53. Чего ждать?
• libnetwork + hashicorp memberlist
• openvswitch портируют на DPDK

54. Спасибо!
Konstantin Nazarov [@racktear]