Комментарии 16
Запустили, к примеру, elasticsearch как -p 9200:9200 — получили дыру в безопасности размером с техас.
Согласен. Его просто надо правильно приготовить. Я писал про это на github.
https://github.com/il-da-r/dockerufw
К сожалению, данный подход не позволяет блокировать сам процесс docker-proxy, который и открывает данный порт на всех интерфейсах. Этот процесс, как и сам docker, имеет привелегию CAP_NET_ADMIN, что позволяет открывать порт в обход файрвола. Если потенциально в нем есть какая-то проблема, то будет небольшая дырка с рут-привелегиями и всеми капами. Лучше всего указать докеру дефолтный адрес для проброса порта как 127.0.0.1, указав параметр "ip": "127.0.0.1" в конфиге докера. Конечно, это не запрещает явно указать -p 0.0.0.0:8080:8080, но это уже буратинство :)
Детали сейчас не вспомню, но что-то прекращало работать.
Единственное, нужно ещё добавить в правила форвардинга трафик контейнеров, и маскарадинг. Без этого действительно сеть в контейнерах сломается
Что-то типа такого:
DOCKER_NET=«172.0.0.0/8»
iptables -t nat -A POSTROUTING! -o docker0 -s ${DOCKER_NET} -j MASQUERADE
iptables -A FORWARD -s ${DOCKER_NET} -j ACCEPT
iptables -A FORWARD -d ${DOCKER_NET} -j ACCEPT
iptables -A INPUT -s ${DOCKER_NET} -j ACCEPT
В этой статье я сосредоточусь на сценариях использования, связанных с интеграционным тестированием и использованием docker-compose в качестве среды разработки. Я думаю, что для производственного использования docker-compose обычно не подходит.
Очень важное замечание. Потому что дальше идёт описание сценария именно в дев среде. Для прода эти «грехи» неприменимы
. Его просто надо правильно приготовить
К сожалению, не помогает. Даже ввели DOCKER-USER цепочку — лучше не стало.
Поэтому совет публикации на 127.0.0.1:xxxx:yyyy — достаточно мудрый и я его поддерживаю.
С «грехом 1» даже интереснее — потому что если мы используем сеть хоста и публикуем внутри контейнера приложение на 0.0.0.0, то у нас файрволл как раз нормально работает. И в этом случае «нормально закрытый» файрволл отсекает все обращения не с локальной машины (что можно использовать как раз для прода — т.к. изоляция докер подсетей на самом деле достаточно эфемерна)
Грех №3: Вы используете helthy для координации запуска служб
Опечатка — конечно, же healthy. Спорный вопрос, на самом деле. Действительно порядок запуска очень важен бывает. И тогда есть два варианта — либо писать его в каком-то внешнем скрипте (баш? Мейкфайл?), либо выносить логику в отдельный контейнер. Но все же хочется, чтобы все запускалось одной командой. Тогда цепочка взаимодействия через хелсчеки и порядок вызовов выглядит не самой дурацкой. Но в каждом конкретном случае надо принимать решение самостоятельно — идеального, хорошего и универсального солюшена нет.
Что ж этого больше нет в версии 3.0 и никакой замены для него не предлагается.
«Отлично». Т.е. проблема в версии 3? Ну, так не пользуйтесь ею. 3.х придуман для сворм, это параллельная версия формата компоуз, которая не замещает 2.х По функционалу же они примерно идентичны.
В качестве простого примера, многие языки имеют глубокую интеграцию IDE, что делает вставку контейнера между языком и IDE практически невозможным. Есть много веских причин не делать этого.
Это тоже не так. Во-первых, приложение не существует в вакууме и можно объединить разработку на локалхосте, а зависимости — крутить в контейнерах. Чтобы основную машину не пачкать.
Вторая история — многие IDE уже поддерживают разработку в контейнерах. Бывают нюансы — да. Но в целом, понятно, что делать и как бороться с проблемами.
Я думаю, что для производственного использования docker-compose обычно не подходит
А я использую. До определенного уровня сложности имхо удобнее и проще, чем громоздить кубернетис или ещё какую конструкцию.
Кстати насчёт вывешивания портов наружу (привязка к 0.0.0.0). Если исправить "грех номер 1" то ведь автоматически исправляется и "грех номер 2"? Какой потом смысл в expose для отдельных контейнеров если все и так видят друг друга в docker Network? Ведь в таком случае точка входа (к примеру http сервер) как раз и должна привязываться к 0.0.0.0 интерфейсу.
Поток догм, которые полезны некоторым, но которые пытаются выдать за истину всем.
--net=host — это единственный адектватный метод получить хорошо работающую сеть в докере. (10к соединений в секунду, 10Гбит/с флуда на инспекцию, you name it).
Да, в некоторых случаях это излишне. Но заявления "вы используете неправильно", мягко говоря, преувеличены.
найс фичу затащили — так что порядку запуска быть!
Да уж. обмельчали DevOps, аж так, что пишут на хабр исключительно на опыте dev.
Если бы ТС действительно работал с докером, он бы не опустился до той чуши, которую мы здесь прочли.
Вы неправильно используете docker-compose