Docker: гибкая сеть без NAT на все случаи жизни24.08.2016 16:33

Время на месте не стоит, и у горячо любимого всеми Docker от версии к версии появляется новый функционал. Случается так, что когда читаешь Changelog для новой версии, видишь там то, что может пригодиться и сделать какие-то вещи лучше, чем есть на данный момент.

Так дело обстояло и в моем случае. Хочу заметить, что многие задачи, которые приходится делать, я делаю по принципу keep it simple. То есть почти всегда, если для решения задачи можно использовать простые инструменты и шаги, я выберу этот путь. Я понимаю, что простой или сложный шаг или инструмент — оценка субъективная, но т.к. работаем мы в команде, то вот такие критерии могут подходить при выборе инструментов:

• используется ли инструмент в инфраструктуре?
• если требуется что-то новое, то нельзя ли использовать то, что уже есть?
• насколько сильно обслуживание (обновление, перезапуск) сервиса будет отличаться от остальных сервисов?
• <...>

• default bridge network;
• host network;
• user defined network.

Долгое время (да чего уж скрывать — и по сей день) для запуска контейнеров мы используем параметр --net=host, получая тем самым «нативный» eth внутри контейнера. Да, в этом случае одного бенефита — изоляции — мы, конечно, лишаемся… Но посмотрев на плюсы и минусы в нашем конкретном случае, мы намеренно пришли к такому решению, т.к. задачи изолировать сеть между запущенными приложениями в рамках одного хоста не стояло. Хочу напомнить, что пишу я о конкретном месте применения Docker — в Badoo.

Что мы знаем про наши сервисы:

• у нас есть карта размещения сервисов на серверах;
• у нас есть карта портов для каждого сервиса и его типа (или типов, если их много);
• у нас есть договоренность о том, что порты должны быть уникальными.

• если мы запускаем несколько сервисов на одной машине с --net=host, то пересечения портов мы не получим: все запустится и будет работать;
• если нам станет мало одного eth-интерфейса, то мы физически подключим еще один и посредством, например, DNS, раскидаем нагрузку между ними.

Дело было вечером, делать было нечего… Ранее говорилось о том, что мы продолжаем переносить наши сервисы в контейнеры. При следовании такому сценарию, как это обычно бывает, самые сложные остаются на потом. Причин для этого может быть масса:

• сервис критичен;
• отсутствие достаточного опыта, чтобы предложить максимально прозрачный и быстрый переезд сервиса в контейнер;
• можно «добавить что-то еще по вкусу».

• работает он на одном ядре (да, такое бывает);
• восполняя первый пробел, стоит отметить, что можно запустить несколько инстансов сервиса и использовать taskset/--cpuset-cpus;
• сервис «сильно» использует сеть, а также ему требуется большое количество портов для исходящих соединений.

• на машине, где планировалось поднятие сервиса, нужно было добавить дополнительный IP-адрес (или даже несколько) — ip a add (тут можно сразу указать на много минусов данного подхода, о которых мы знаем);
• про вышесказанное стоит помнить, чтобы не получить, к примеру, 2 одинаковых адреса на разных машинах;
• в конфигурации демона стоило указать, на каком адресе он работает, как раз чтобы не «съесть» все порты соседа или хост-системы.

• оставить все как есть, но обернуть в контейнер;
• поднимать на dockerhost все те же дополнительные IP-адреса;
• «биндить» приложение на конкретный адрес.

MACVLAN — это, по сути, Linux switch, который основан на статичном соответствии MAC и VLAN. Здесь используется unicast-фильтрация, не promiscuous-режим. MACVLAN может работать в режиме private, VEPA, bridge, passthru. MACVLAN — это reverse VLAN в Linux. Данная технология позволяет взять один реальный интерфейс и сделать на его основе несколько виртуальных с разными MAC-адресами.

Также сравнительно недавно появилась технология IPVLAN (https://www.kernel.org/doc/Documentation/networking/ipvlan.txt). Основное отличие от MACVLAN заключается в том, что IPVLAN может работать в L3 mode. В данной статье я буду рассматривать вариант использования MACVLAN (в режиме bridge), потому что:

• не стоит ограничение в 1 MAC-адрес с одного линка на активном сетевом оборудовании;
• количество контейнеров на хосте не будет таким большим, что может привести к превышению mac capacity. С течением времени этот момент у нас может, конечно, измениться;
• на данном этапе L3 не нужен.

Теория — это отлично, но даже там мы видим, что overhead имеет место быть. Можно и нужно посмотреть на сравнительные тесты пропускной способности MACVLAN в интернете (например, http://comp.photo777.org/docker-network-performance/ и http://delaat.net/rp/2014–2015/p92/report.pdf), но также неотъемлемой частью эксперимента является проведение теста в своих лабораторных условиях. Поверить на слово — хорошо, но «потрогать руками» и сделать выводы самому — интересно и необходимо.

# docker network create -d macvlan --subnet=1.1.1.0/24 --gateway=1.1.1.1 -o parent=eth0 cppbig_vlan
Error response from daemon: plugin not found

docker[2012]: time="2016-08-04T11:44:44.095241242Z" level=warning msg="Unable to locate plugin: macvlan, retrying in 1s"
docker[2012]: time="2016-08-04T11:44:45.095489283Z" level=warning msg="Unable to locate plugin: macvlan, retrying in 2s"
docker[2012]: time="2016-08-04T11:44:47.095750785Z" level=warning msg="Unable to locate plugin: macvlan, retrying in 4s"
docker[2012]: time="2016-08-04T11:44:51.095970433Z" level=warning msg="Unable to locate plugin: macvlan, retrying in 8s"
docker[2012]: time="2016-08-04T11:44:59.096197565Z" level=error msg="Handler for POST /v1.23/networks/create returned error: plugin not found"

Тест был символическим, с использованием iperf. Для каждого варианта я запускал сначала 1 клиента, потом 8 в параллель. Вариантов было 2:

• --net=host;
• --net=macvlan.

# docker run -it --net=host --name=iperf_w_host_net --entrypoint=/bin/bash dockerio.badoo.com/itops/sle_12_base:latest
# iperf3 -s -p 12345
-----------------------------------------------------------
Server listening on 12345
-----------------------------------------------------------

# iperf3 -c 1.1.1.2 -p 12345 -t 30

# iperf3 -c 1.1.1.2 -p 12345 -t 30 -P 8

# docker run -it --net=cppbig_vlan --name=iperf_w_macvlan_net --ip=1.1.1.202 --entrypoint=/bin/bash dockerio.badoo.com/itops/sle_12_base:latest
# iperf3 -s -p 12345
-----------------------------------------------------------
Server listening on 12345
-----------------------------------------------------------

# iperf3 -c 1.1.1.202 -p 12345 -t 30

# iperf3 -c 1.1.1.202 -p 12345 -t 30 -P 8

Ограничения технологии by design: доступность контейнера с хоста и доступность хоста из контейнера отсутствует. Нам такой функционал необходим, потому что:

• часть проверок доступности сервиса проверяется «хелперами» Zabbix, которые выполняются на том хосте, где работает сервис;
• есть необходимость использовать кеширующий DNS, который расположен на хост-системе. В нашем случае это Unbound;
• бывает необходимость использовать доступ к еще каким-то сервисам, запущенным на хост-системе.
• Это лишь часть причин, по которым доступ «хост <==> контейнер» нам необходим. Взять и переделать архитектуру подобных узлов в одночасье невозможно.

1. Использовать два и более физических линка на машине. Это дает возможность взаимодействия через соседний интерфейс. Например, взять eth1 и отдать его специально для MACVLAN, а на хост-системе продолжать использовать eth0. Вариант, безусловно, неплохой, но это влечет за собой необходимость держать одинаковое количество линков на всех машинах, где мы планируем запускать подобные сервисы. Реализовать это дорого, не быстро и не всегда возможно.
2. Использовать еще один дополнительный IP-адрес на хост-системе, повесить его на виртуальный MACVLAN-интерфейс, который нужно поднять на хост-системе. Это приблизительно так же сложно с точки зрения поддержки («не забыть/не забывать»), как предыдущее предложение — это раз. А, так как ранее я говорил о том, что наш сервис сам по себе требует дополнительного адреса, то в итоге для запуска такого сервиса нам потребуется:
   • адрес для основного интерфейса хост-системы (1);
   • адрес для сервиса (2);
   • адрес для виртуального интерфейса, через который мы будем взаимодействовать с сервисом (3).
   
   В данном случае получается, что нам нужно слишком много IP-адресов, которые, по большому счету, использоваться будут мало. Помимо излишнего расходования IP-адресов стоит также помнить, что нам нужно будет поддерживать статичные маршруты через этот самый виртуальный интерфейс до контейнера. Это не непреодолимая сложность, но усложнение системы в целом — факт.

   Внимательный читатель задаст вопрос: «А зачем адрес на основной интерфейс и на MACVLAN-интерфейс, если можно адрес основного интерфейса отдать виртуальному?» В таком случае мы оставим нашу систему без адресов на реальных интерфейсах, а на такой шаг я пойти пока не готов.

   В предыдущих двух вариантах предполагалось, что адреса всех интерфейсов принадлежат одной сети. Как несложно представить, даже при 100 серверах в такой подсети, если завести по три адреса, то в /24 мы уже не попадаем.

3. Сервисный IP. Суть идеи заключается в том, что мы делаем отдельную подсеть для сервисов. Как это выглядит:
   • на сервер начинаем подавать «тегированный» траффик;
   • native VLAN оставляем в виде основной сети для dockerhost (eth0);
   • поднимаем виртуальный интерфейс с 802q, без IP-адреса на хост системе;
   • используем для сервиса IP-адрес из сервисной сети.

• для того чтобы подать «тегированный» трафик на интерфейс, кто нам нужен? Правильно, сетевики! Просим их выполнить переключение access-порта в порт, на который подаем 2 VLAN;
• поднять дополнительный интерфейс на хосте:

  # cat /etc/sysconfig/network/ifcfg-vlan8
  BOOTPROTO='static'
  STARTMODE='auto'
  VLAN='yes'
  ETHERDEVICE='eth0'
  
  # ip -d link show vlan8
  31: vlan8@eth0:  mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
  link/ether e4:11:5b:ea:b6:30 brd ff:ff:ff:ff:ff:ff promiscuity 1
  vlan protocol 802.1Q id 8 
  

  
  
• завести MACVLAN-сеть в Docker

  
  # docker network create -d macvlan --subnet=1.1.2.0/24 --gateway=1.1.2.1 -o parent=vlan8 c_services
  

  
  
• убедиться, что сеть в Docker появилась:

  
  # docker network ls | grep c_services
  a791089219e0        c_services          macvlan

Да, здесь видно использование conntrack на хосте.

Как так? Ну не нужен же conntrack для МACVLAN?! Так как дело было уже вечером, я решил проверить даже самые невероятные теории. В подтверждение моих теоретических знаний, connection tracking был на самом деле не нужен. Без него все продолжало работать. Выгрузка модулей, так или иначе завязанных на conntrack, была невозможной только в момент запуска моего контейнера. Идеи меня покинули, и пошел я домой, решив, что утро вечера мудренее.

На следующий день я в очередной раз убедился в точности данного высказывания. Итак, я решил «топорным» методом сделать так, чтобы Docker не мог подгружать nf_conntrack. Сначала я его просто переименовал (т.к. blacklist игнорируется при загрузке модуля через modprobe), после чего запустил свой контейнер снова. Контейнер, как и ожидалось, поднимался и отлично себя чувствовал, но в логе я увидел сообщения о том, что четыре правила не могут быть добавлены в iptables. Получается, что conntrack нужен? Вот правила, которые не хотели добавляться:

-t nat -A OUTPUT -d 127.0.0.11 -p udp --dport 53 -j DNAT --to-destination 127.0.0.11:35373
-t nat -A POSTROUTING -s 127.0.0.11 -p udp --sport 35373 -j SNAT --to-source :53
-t nat -A OUTPUT -d 127.0.0.11 -p tcp --dport 53 -j DNAT --to-destination 127.0.0.11:41214
-t nat -A POSTROUTING -s 127.0.0.11 -p tcp --sport 41214 -j SNAT --to-source :53

Далее я попробовал вернуть модуль, запустить сервис, поправить правила из iptables и выгрузить модули… Но не тут то было. Путем ковыряния modinfo я выяснил, какой там модуль от какого зависит, и какой из них кого тянет за собой. При создании сети Docker принудительно делает modprobe xt_nat, который, в свою очередь, зависит от nf_conntrack, вот тому подтверждение:

# modinfo xt_nat
filename:       /lib/modules/4.4.0-3.1-default/kernel/net/netfilter/xt_nat.ko
alias:          ip6t_DNAT
alias:          ip6t_SNAT
alias:          ipt_DNAT
alias:          ipt_SNAT
author:         Patrick McHardy 
license:        GPL
srcversion:     9982FF46CE7467C8F2361B5
depends:        x_tables,nf_nat
intree:         Y
vermagic:       4.4.0-3.1-default SMP preempt mod_unload modversions

• на Docker issues;
• в исходный код.

       if out, err := exec.Command("modprobe", "-va", "nf_nat").CombinedOutput(); err != nil {
               logrus.Warnf("Running modprobe nf_nat failed with message: `%s`, error: %v", strings.TrimSpace(string(out)), err)
       }
       if out, err := exec.Command("modprobe", "-va", "xt_conntrack").CombinedOutput(); err != nil {
               logrus.Warnf("Running modprobe xt_conntrack failed with message: `%s`, error: %v", strings.TrimSpace(string(out)), err)
       }

       if err := r.setupIPTable(); err != nil {
               return fmt.Errorf("setting up IP table rules failed: %v", err)
       }

Смотрим. Все ок, все работает.

На этом этапе можно считать, что вся наша схема в лабораторных условиях работает, осталось сделать самую малость — прицепить ее к нашему сервису. Хорошо, возвращаемся к сервису и смотрим на его общую архитектуру:

Пояснения о том, как оно работает:

• (1 и 6) мобильный клиент устанавливает соединение с неким урлом, за которым стоит балансировщик;
• (2) балансировщик выбирает нужный инстанс нашего сервиса и позволяет установить соединение клиент-сервис;
• (3 и 4) далее наш сервис проксирует запросы от клиента на кластер с кодом, но тоже через балансировщик в виде nginx. Вот тут мы и вернулись к нашему требованию о том, что nginx должен быть на той же машине, что и сервис. На данный момент также есть ограничение в том, что он должен быть именно на хосте, а не в контейнере (это, кстати, решило бы проблему сразу). Мы не будем в данной статье рассуждать о причинах этого требования, а примем это как условие.
• (5) у каждого инстанса нашего сервиса есть определенный id, который нужен коду, чтобы понимать, через какой именно инстанс отвечать клиенту.

# ip r
default via 1.1.2.254 dev eth0
10.0.0.0/8 via 1.1.2.1 dev eth0
1.1.2.0/24 dev eth0  proto kernel  scope link  src 1.1.2.14
192.168.0.0/16 via 1.1.2.1 dev eth0

# ip r
default via 1.1.2.1 dev eth0
1.1.2.0/24 dev eth0  proto kernel  scope link  src 1.1.2.14

• делать это руками, используя namespace контейнера;
• взять pipework https://github.com/jpetazzo/pipework и сделать все то же самое, но с его помощью.

Стремясь к идеалу, мы сделали для этой сервисной сети все маршруты через default gw, а всю сложность маршрутизации переложили на сетевой отдел. Всё. Точнее, я думал, что всё…

Как мне показалось на тот момент — решение отличное. Если бы все работало именно так, как я рассчитывал, так бы оно и было, но на этом ничего не закончилось. Чуть позже стало понятно, что при такой схеме мы получаем асимметричный роутинг для тех сетей, в которых есть маршрут через наш LTM. Чтобы стало чуть более понятно, я попробую показать, какие подсети у нас могут быть.

1. Сеть, у которой есть только 1 default gw и нет внешнего балансировщика.
   
   
   
2. Сеть, у которой более одного GW: например, балансировщик внешних запросов. Сложность в том, что внутренний трафик мы через него не гоняем.
   
   

• они не готовы брать на себя ответственность и следить за всеми сетями, в которых роутинг будет именно таким;
• мы, со своей стороны, не готовы поддерживать статичные маршруты для всех таких сетей на серверах

Я всегда говорю, что не стоит забывать про идеи, которые приходили в голову раньше, но были отвергнуты. Мы вернулись к мысли использовать статические маршруты внутри контейнера.

Итак, вот те условия, которые гарантируют нам работу нашего сервиса в контейнере:

• сам сервис;
• выделенный IP для сервиса;
• доступность сервиса и адреса со всех наших подсетей;
• возможность использовать и менять маршруты при запуске контейнера (самое важное, потому что именно это можно забыть).

Вот теперь картинка сложилась, и мы можем добавить все нужные нам штуки, связанные с маршрутизацией, в автозапуск.
Давайте посмотрим, как выглядит наш Dockerfile в близком к финальному результату.

Dockerfile:

FROM dockerio.badoo.com/itops/sle_12_base:latest
MAINTAINER #MAINTEINER#

RUN /usr/bin/zypper -q -n in iproute2
RUN groupadd -g 1001 wwwaccess

RUN mkdir -p /local/SERVICE/{var,conf} 
COPY get_configs.sh /local/SERVICE/
COPY config.cfg /local/SERVICE/
ADD SERVICE-CERTS/ /local/SERVICE-CERTS/

ADD SERVICE/bin/SERVICE-BINARY-${DVERSION} /local/SERVICE/bin/
ADD SERVICE/conf/ /local/SERVICE/conf/

COPY routes.sh  /etc/cont-init.d/00-routes.sh
COPY env.sh  /etc/cont-init.d/01-env.sh
COPY finish.sh  /etc/cont-finish.d/00-finish.sh
COPY run /etc/services.d/SERVICE/
COPY finish /etc/services.d/SERVICE/
RUN touch /tmp/fresh_container
ENTRYPOINT ["/init"]

• мы используем s6 overlay как supervisor внутри контейнера;
• мы добавляем пакет iproute, чтобы можно было править маршруты;
• мы добавляем запуск нескольких скриптов, которые выполняются ДО старта нашего сервиса (директория /etc/cont-init.d/), а также добавляем скрипты, которые будут выполнены ПОСЛЕ завершения работы сервиса, но ДО того, как опустится контейнер (/etc/cont-finish.d/);
• мы добавляем файл /tmp/fresh_container для того, чтобы понимать, первый ли раз стартует наш контейнер или нет. Чуть яснее про это будет, когда я покажу содержимое остальных скриптов;

1. get_configs.sh — это скрипт, который смотрит, есть ли конфиг для сервиса в нашей системе хранения и генерации конфигов, доставляет их в контейнер, проверяет на валидность, и если все в порядке, то с ним и запускает. Подробнее про это мы рассказывали на Docker Meetup;
2. routes.sh — скрипт, который подготавливает маршруты внутри контейнера:

   
   #!/usr/bin/with-contenv sh
   if [ ! -x /usr/sbin/ip ];then
           echo -e "\e[31mCan't execute /usr/sbin/ip\e[0m";
           [ $(pgrep s6-svscan) ] && s6-svscanctl -t /var/run/s6/services
           exit 1;
   else
           LTMGW=$(/usr/sbin/ip r show | /usr/bin/grep default | /usr/bin/awk {'print $3'} | /usr/bin/awk -F \. {'print $1"."$2"."$3".254"'})
           DEFGW=$(/usr/sbin/ip r show | /usr/bin/grep default | /usr/bin/awk {'print $3'} | /usr/bin/awk -F \. {'print $1"."$2"."$3".1"'})
           /usr/sbin/ip r replace default via ${LTMGW}
           /usr/sbin/ip r add 192.168.0.0/16 via 10.10.8.1 dev eth0
           /usr/sbin/ip r add 10.0.0.0/8 via 10.10.8.1 dev eth0
           echo -e "\e[32mAll job with routes done:\e[0m\n$(/usr/sbin/ip r show)"
   fi
   

   
   
3. env.sh — скрипт, который готовит окружение для нашего сервиса; зачастую именно он выполняется только 1 раз при первом старте контейнера:

   
   #!/usr/bin/with-contenv sh
   if [ ! -z  "${ISTEST}" ];then exit 0;fi
   if [ ! -n "${SERVICETYPE}" ];then
           echo -e "\e[31mPlease set SERVICE type\e[0m";
           [ $(pgrep s6-svscan) ] && s6-svscanctl -t /var/run/s6/services
           exit 1;
   fi
   bash /local/SERVICE/get_configs.sh || exit 1
   echo -e "\e[32mSERVICE ${SERVICETYPE} is running\e[0m"
   

   
   
4. finish.sh — скрипт, который просто чистит pid-файлы от нашего сервиса. Конкретный сервис настолько крут (как Чак Норрис), что сам этого не делает, но он не запустится, если обнаружит старые pid-файлы :)
5. run — это скрипт, который запускает наше приложение:

   
   #!/usr/bin/with-contenv bash
   exec /local/SERVICE/bin/SERVICE-${DVERSION} -l /local/SERVICE/var/mobile-${SERVICETYPE}.log -P /local/SERVICE/var/mobile-${SERVICETYPE}.pid -c /local/SERVICE/conf/SERVICE.conf -v ${VERBOSITY}
   

   
   
6. finish — скрипт, который тушит контейнер в случае, если сервис завершил свою работу:

   
   #!/bin/sh
   [ $(pgrep s6-svscan) ] && s6-svscanctl -t /var/run/s6/services

   
   

docker run -d --net=c_services --ip=1.1.2.17 --name=SERVICE-INSTANCE16 -h SERVICE-INSTANCE16.local --cap-add=NET_ADMIN --add-host='nginx.localhost:1.1.1.17' -e SERVICETYPE=INSTANCE16_eu1 -e HOST_IP=1.1.1.17 --volumes-from=badoo_loop dockerio.badoo.com/cteam/SERVICE:2.30.0_994

Антон banuchka Турецкий
Site Reliability Engineer, Badoo

Комментарии (2)

• ToSHiC

  24 августа 2016 в 16:21

  0

  ↑

  ↓

  А почему вы не рассматривали вариант с macvlan интерфейсом в качестве основного на хост-системе? А на eth0 даже адрес не навешивать. Заодно и пакеты перестанут ходить через свитч.

  • banuchka

    24 августа 2016 в 16:27

    0

    ↑

    ↓

    В статье я сделал оговорку по этому поводу, также в ней содержится и ответ:
    

    Внимательный читатель задаст вопрос: «А зачем адрес на основной интерфейс и на MACVLAN-интерфейс, если можно адрес основного интерфейса отдать виртуальному?» В таком случае мы оставим нашу систему без адресов на реальных интерфейсах, а на такой шаг я пойти пока не готов.

    
    Для того, чтобы пакеты перестали ходить через свитч мы также высадили nginx в контейнер, который использует нужную нам сеть.