Comments 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 и для них будет нормальным решением, хотя бы на первое время.
UFO just landed and posted this here
Главная сложность балансировки нагрузки, что нельзя рвать сессии. Если например на веб ресурсе авторизация сохраняется в сессии, пользователь при обновлении страницы должен попасть на тот же вебсервер, где записана его сессия. Иначе он будет все время отваливаться… Подскажите, как у docker-а с этим?
Sign up to leave a comment.
Устранение беспорядка маршрутизации сервисов при помощи Docker