Комментарии 10
Интересная статья! С большим удовольствием читаю статьи от вашей команды! Причем всегда очень радует, что темы довольно не тривиальные и основанные на личном опыте а не «гдетокогдатоктото». Хочется сказать спасибо, так держать!
Не подскажите, а как быть с оверхедом? Overlay-network, который дает docker-swarm режет канал сети больше, чем в двое. С сеткой маршрутизации таких проблем не будет?
Кто-нибудь вообще использует docker networking в продакшне? Я честно не вижу в нем никакого смысла — порты можно настроить в конфиге приложения, service discovery лучше использовать собственный, а не доверять докеру.
А почему вы думаете, что ваш service discovery будет работать лучше, чем Docker?
Вы забыли еще про балансировку запросов, автоматическое обновление и восстановление без простоев. И это не считая всех остальных удобств Docker. Да, сетевой оверхед присутствует. Но даже двойное снижение пропускной способности (из комментария от SirEdvin) и увеличенные сетевые задержки вполне допустимы для веб-сервисов — ведь именно для них в первую очередь будет использован Swarm. Разработчики таких сервисов будут очень охотно пользоваться Docker Swarm. Уверен в этом, потому что сам являюсь разработчиком веб-сервисов и уже более года использую Docker в production. А с переходом на версию 1.12 мои веб-приложения будут поддерживать масштабирование и отказоустойчивость можно сказать из коробки.
PS: Redis/PostgreSQL и прочим решениям со встроенным либо подключаемым масштабированием/отказоустойчивостью Docker действительно будет мало полезен, но будет лишь замедлять их работу. Но если это позволит упростить процедуру разворачивания (АКА деплоя), то Docker Swarm и для них будет нормальным решением, хотя бы на первое время.
порты можно настроить в конфиге приложения
Вы забыли еще про балансировку запросов, автоматическое обновление и восстановление без простоев. И это не считая всех остальных удобств Docker. Да, сетевой оверхед присутствует. Но даже двойное снижение пропускной способности (из комментария от SirEdvin) и увеличенные сетевые задержки вполне допустимы для веб-сервисов — ведь именно для них в первую очередь будет использован Swarm. Разработчики таких сервисов будут очень охотно пользоваться Docker Swarm. Уверен в этом, потому что сам являюсь разработчиком веб-сервисов и уже более года использую Docker в production. А с переходом на версию 1.12 мои веб-приложения будут поддерживать масштабирование и отказоустойчивость можно сказать из коробки.
PS: Redis/PostgreSQL и прочим решениям со встроенным либо подключаемым масштабированием/отказоустойчивостью Docker действительно будет мало полезен, но будет лишь замедлять их работу. Но если это позволит упростить процедуру разворачивания (АКА деплоя), то Docker Swarm и для них будет нормальным решением, хотя бы на первое время.
НЛО прилетело и опубликовало эту надпись здесь
Главная сложность балансировки нагрузки, что нельзя рвать сессии. Если например на веб ресурсе авторизация сохраняется в сессии, пользователь при обновлении страницы должен попасть на тот же вебсервер, где записана его сессия. Иначе он будет все время отваливаться… Подскажите, как у docker-а с этим?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Устранение беспорядка маршрутизации сервисов при помощи Docker