Налаштування ядра з привілейованим контейнером Docker


10

Я будую контейнер для налаштування параметрів ядра для балансира навантаження. Я вважаю за краще розгорнути ці зміни на хості у зображенні за допомогою одного привілейованого контейнера. Наприклад:

docker run --rm --privileged ubuntu:latest sysctl -w net.core.somaxconn=65535

При тестуванні зміни набувають чинності, але тільки для цього контейнера. У мене склалося враження, що з повністю привілейованими змінами контейнера в / proc фактично зміниться основна ОС.

$docker run --rm --privileged ubuntu:latest \
    sysctl -w net.core.somaxconn=65535
net.core.somaxconn = 65535

$ docker run --rm --privileged ubuntu:latest \
    /bin/bash -c "sysctl -a | grep somaxconn"
net.core.somaxconn = 128

Як це повинні працювати пільгові контейнери?

Я просто щось дурне роблю?

Який найкращий спосіб внести тривалі зміни?

Інформація про версію:

Client version: 1.4.1
Client API version: 1.16
Go version (client): go1.3.3
Git commit (client): 5bc2ff8
OS/Arch (client): linux/amd64
Server version: 1.4.1
Server API version: 1.16
Go version (server): go1.3.3
Git commit (server): 5bc2ff8

Приклад команди із змонтованим / proc:

$ docker run -v /proc:/proc ubuntu:latest \
    /bin/bash -c "sysctl -a | grep local_port"
net.ipv4.ip_local_port_range = 32768    61000

$ docker run -v /proc:/proc --privileged ubuntu:latest \
    /bin/bash -c "sysctl -p /updates/sysctl.conf"
net.ipv4.ip_local_port_range = 2000 65000

$ docker run -v /proc:/proc ubuntu:latest \
    /bin/bash -c "sysctl -a | grep local_port"
net.ipv4.ip_local_port_range = 32768    61000

$ docker run -v /proc:/proc --privileged ubuntu:latest \
    /bin/bash -c "sysctl -a | grep local_port"
net.ipv4.ip_local_port_range = 32768    61000

Чи потрібно робити щось нерозумно, як mount / proc як об'єм?
allingeek

Спробував монтаж / proc: / proc без удачі. Подальші дзвінки до sysctl-повернути початкові значення.
allingeek

Схоже, зараз це працює на Докер 18.09
Jairo Andres Velasco Romero

Відповіді:


8

Цей конкретний параметр підпадає під вплив мережевого простору імен, в якому працює докер.

Як правило /proc, змінюються налаштування, що відносяться до системи, але технічно кажучи, ви змінюєте налаштування, в /proc/netяких повертає результати на основі простору мереж імен.

Зверніть увагу, що /proc/netнасправді є символьним посиланням на те, /proc/self/netяк воно насправді відображає параметри простору імен, в яких ви виконуєте роботу.


Отже, якщо я вношу ці зміни в контейнер із встановленим / proc і хостом - .net, я можу внести зміни до хоста. Але якщо я зрозумію вашу відповідь, наступні контейнери підтримуватимуть старі значення (завантажені з постійних налаштувань хоста) у власному просторі імен. Мені потрібно запустити цей контейнер із чимось на зразок CAP_NET_ADMIN, щоб зробити ті самі зміни під час виконання в контейнері балансира навантаження. Звучить правильно?
allingeek

Так, запуск CAP_NET_ADMIN не повинен створювати проблеми, коли ви створили для нього простір імен.
Метью Іфе

Matthew_Ife У цьому випадку не проблема, що контейнер очікується привілейованим. Мені здається, що CAP_NET_ADMIN міг дозволити вийти з конфігурації докера (принаймні контейнер міг переналаштувати свій інтерфейс, щоб представити собі інший контейнер)
Ángel

@Angel Це залежало б від того, яка посилання виходить, встановлення всередині докера. Як правило, слід розміщувати примусове використання трафіку в батьківському просторі імен. Неможливо переключити простори імен кудись ще, оскільки для цього вам потрібен CAP_SYS_ADMIN.
Меттью Іфе

Так з використанням --net = хост буде працювати?
Хайро Андрес Веласко Ромеро

7

Docker 1.12+ має вбудовану підтримку налаштування значень sysctl всередині контейнерів. Ось уривок із документації :

Налаштування параметрів ядра (sysctls) з простором імен під час виконання

--Sysctl встановлює в контейнері параметри ядра (sysctls). Наприклад, щоб увімкнути переадресацію IP в просторі імен контейнерів, запустіть цю команду:

docker run --sysctl net.ipv4.ip_forward=1 someimage

Використовуючи ваш приклад, правильним способом підвищення net.core.somaxconnбуло б:

docker run ... --sysctl net.core.somaxconn=65535 ...

3

Привілейований контейнер все ще використовує власний простір імен для /proc. Що ви можете зробити, це змонтувати реальне /procвсередині контейнера:

docker run --rm --privileged -v /proc:/host-proc ubuntu:latest \
  'echo 65535 > /host-proc/sys/net/core/somaxconn'

Просто спробував це, і це не працює.
allingeek

З малого, що я знаю про докера; це повинен бути автономний екземпляр, як в'язниця на FreeBSD, тому його можна легко переміщати, перерозподіляти тощо ... Не слід змішувати доклет з хост-ОС.
голландський дядько

2
Існує кілька дійсних випадків використання - привілейованих контейнерів, і це здається ідеальним випадком. Усі контейнери використовують одне і те ж саме базове ядро. Стандартні контейнери монтують / додають лише для читання.
allingeek

@allingeek CAP_NET_ADMIN дійсно може бути відсутнім бітом.
Ángel

1
Пробував NET_ADMIN, і він все ще не працює - докер запустити --cap-додати NET_ADMIN --net = хост -v / proc: / proc_host ubuntu: 14.04 bash -c 'echo 1> / proc_host / sys / net / ipv4 / ip_forward '&& sysctl net.ipv4.ip_forward net.ipv4.ip_forward = 0
tomdee

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.