docker это не про настройку инфраструктуры, это про "мы не осилили всё вместе, будем делать по отдельности" как правило. Ну, когда на вопрос "зачем тут докер?" поступают ответы в стиле "эээ... ммм...", "потому что умеем!", "почему нет?" — вот как раз оно.
...
А вот для продакшена.... Ну, такое вот. Докер в проде это минус в карму и косые взгляды. Ну, кроме, пожалуй, варианта когда проект гдетотам на сферическом амазоне крутитцца и нужно уметь быстро/автоматически масштабировать мощности в зависимости от нагрузки.
И правда ведь... Docker — он же не бесплатный по ресурсам, верно? Зачем он, если можно и без него?
Всё правильно. Докер — для масштабных "облачных" служб типа Амазона. Где куча софта разных версий, куча конфигураций, и всё это надо автоматически разворачивать на тысячах серверов.
Ну ещё иногда для разработки. Точнее, для автоматического тестирования разрабатываемого софта.
Здравствуйте, Shmj, Вы писали:
S> И правда ведь... Docker — он же не бесплатный по ресурсам, верно? Зачем он, если можно и без него?
Для разработки ресурсоемкость решения не особо принципиальна будь то docker, virtual box, kvm, chroot (и все остальное, что могут использовать для изоляции). Для прода, где нужна стабильность и прочие аттрибуты "зрелости" (а не хипстерское "упало, да и фиг с ним — облако новых нарожает") докер непригоден (но не из за оверхеда конечно же).
S>docker это не про настройку инфраструктуры, это про "мы не осилили всё вместе, будем делать по отдельности" как правило. Ну, когда на вопрос "зачем тут докер?" поступают ответы в стиле "эээ... ммм...", "потому что умеем!", "почему нет?" — вот как раз оно.
S>...
S>А вот для продакшена.... Ну, такое вот. Докер в проде это минус в карму и косые взгляды. Ну, кроме, пожалуй, варианта когда проект гдетотам на сферическом амазоне крутитцца и нужно уметь быстро/автоматически масштабировать мощности в зависимости от нагрузки.
S>И правда ведь... Docker — он же не бесплатный по ресурсам, верно? Зачем он, если можно и без него?
Докер это унифицированный деплой.
Установка сложного приложения без докера выглядит так:
1) Устновить nodejs\веб-сервер\еще какую-нибудь-фигню версии 15.43.442, именно такой, потому что на другом не тестировалось и корректность работы не гарантируется.
2) Поднять базу на mongodb 12.697 и кэш на редис на 3.974, именно на таких, потому что на других не тестировалось и работоспособность не гарантируется.
3) Открыть порты 1234 и 4321.
4) Прописать в переменных окружения нужные параметры, совпадающие с фазой менструального цикла лемура.
Естественно для каждого языка\платформы\базы этот набор магических пассов руками уникален.
Установка с докером — передать образ и запустить пару команд в командной строке. Всю работу по конфигурации берет на себя разработчик.
Конечно шеридану такая ситуация не нравилась, потому что лишает админа власти над этими выскочками-программистами. Программисты с докером могут поставить приложения у заказчика без усилий с снисхождения админа.
А вот в чем профит от "микросервисов" — я до сих пор не понял и даже внятных примеров нет.
S>docker это не про настройку инфраструктуры, это про "мы не осилили всё вместе, будем делать по отдельности" как правило. Ну, когда на вопрос "зачем тут докер?" поступают ответы в стиле "эээ... ммм...", "потому что умеем!", "почему нет?" — вот как раз оно.
S>...
S>А вот для продакшена.... Ну, такое вот. Докер в проде это минус в карму и косые взгляды. Ну, кроме, пожалуй, варианта когда проект гдетотам на сферическом амазоне крутитцца и нужно уметь быстро/автоматически масштабировать мощности в зависимости от нагрузки.
S>И правда ведь... Docker — он же не бесплатный по ресурсам, верно? Зачем он, если можно и без него?
Ну это вопрос по-моему аналогичен вопросу "зачем виртуализация"?
На мой взгляд для максимальной утилизации железа, и упрощения администрирования.
И если говорить о Linux, то cgroups практически бесплатен по сравнению
с настоящей виртуализацией. Там вроде 1-10 процентов деградации по сравнению
с запуском без cgroups. Это ведь по-сути "chroot" на супер стероидах.
Здравствуйте, Shmj, Вы писали:
S>И правда ведь... Docker — он же не бесплатный по ресурсам, верно? Зачем он, если можно и без него?
Docker — практически бесплатный по CPU/RAM. Это же не виртуализация, а контейнеры.
Основной overhead — это в дополнительных копиях системных библиотек в контейнере. Но для типичных условий это совершенно несущественно.
Вообще мне понравилась концепция докера. Но как-то у меня не срастается с практикой. Как ни поставлю, то зависает, то сервер зависает через какое-то время. В общем пока отложил. Но это было несколько лет назад, может уже отладили.
В целом для некоторых юз-кейсов при разработке считаю его просто божественным. Всё хочу внедрить в тестирование. Концепция такая. Есть чистая база, на неё накатываются миграции (SQL-файлы), после всех миграций база становится в чистом актуальном состоянии (без данных). После этого на этой чистой базе прогоняются тесты. При этом каждый тест рассчитывает на то, что база, собственно, чистая. Сейчас это всё делается в полу-ручном состоянии и тесты делают rollback после выполнения, но это не идеальный вариант. С докером я хочу сделать так: каждая миграция это отдельный слой. Т.е. если мы меняем последнюю миграцию (при разработке), то они все не прогоняются заново, а берётся предпоследнее состояние базы, это должно быть куда быстрей. Также для каждого теста берётся последнее состояние базы прям на диске, тест прогоняется, можно делать коммит, а состояние потом выбрасывается. Можно даже пускать несколько тестов параллельно.
Правда пока не осилил так сделать, как-то пытался, но слишком муторно это всё. Но концепция мне очень нравится и когда-нибудь осилю.
Оверхед у докера по идее совсем небольшой. Это же не виртуальная машина.
Здравствуйте, vsb, Вы писали:
vsb>Вообще мне понравилась концепция докера. Но как-то у меня не срастается с практикой. Как ни поставлю, то зависает, то сервер зависает через какое-то время. В общем пока отложил. Но это было несколько лет назад, может уже отладили.
На Винде он как гражданин второго класса, поддержка остаточная, то тут отвалится, то там. Но всё равно удобно. Одновременно иметь пару ораклов и постгрис и никто никуда не посрал, и удалить одной командой можно, как не было. Хочу один Zookeeper и Kafka, хочу — кластер из трёх, посмотреть как оно отказ узлов обрабатывает и как наше приложение реагирует. И опять нигде не насрано, удалил потом как не было.
vsb>Оверхед у докера по идее совсем небольшой. Это же не виртуальная машина.
На винде создаётся виртуальная машина Hyper-V и весь Докер и все контейнеры там крутятся. Но на каждый контейнер не создаётся, да. Но формально всё-таки виртуальная машина.
Здравствуйте, bzig, Вы писали:
vsb>>Вообще мне понравилась концепция докера. Но как-то у меня не срастается с практикой. Как ни поставлю, то зависает, то сервер зависает через какое-то время. В общем пока отложил. Но это было несколько лет назад, может уже отладили.
B>На Винде он как гражданин второго класса, поддержка остаточная, то тут отвалится, то там. Но всё равно удобно. Одновременно иметь пару ораклов и постгрис и никто никуда не посрал, и удалить одной командой можно, как не было. Хочу один Zookeeper и Kafka, хочу — кластер из трёх, посмотреть как оно отказ узлов обрабатывает и как наше приложение реагирует. И опять нигде не насрано, удалил потом как не было.
Зависало у меня как раз в линуксе. В венде, как ни странно, всё работало.
vsb>>Оверхед у докера по идее совсем небольшой. Это же не виртуальная машина.
B>На винде создаётся виртуальная машина Hyper-V и весь Докер и все контейнеры там крутятся. Но на каждый контейнер не создаётся, да. Но формально всё-таки виртуальная машина.
Ну речь о продакшне, думаю, никто в своём уме не будет продакшн в докере крутить на вендовом хосте.
Здравствуйте, gandjustas, Вы писали:
G>Докер это унифицированный деплой.
Унифицированный деплой это ansible.
G>Установка сложного приложения без докера выглядит так: ... G>Установка с докером — передать образ и запустить пару команд в командной строке. Всю работу по конфигурации берет на себя разработчик. ansible-playbook playbook-deploy.yaml и оно может даже само выкачать всё нужное.
G>Конечно шеридану такая ситуация не нравилась, потому что лишает админа власти над этими выскочками-программистами. Программисты с докером могут поставить приложения у заказчика без усилий с снисхождения админа.
У тебя админ что, жену увёл?
Какая нахрен власть? Админ работает параллельно с программистами. Чтобы те не отвлекались от кода и делали то, что они умеют делать с полной отдачей. Админ для программиста это этакий деплой с голосовым управлением. "Чувак, я тут дописал-оттестировал, но нужно чтобы в системе была либа А, пара реверспрокси на эти порты и блекджек вот тут". Нормальный админ уточнит детали, , прикинет возможные проблемы, обсудит с программистом если такие есть и оба два разойдутся пилить каждый свою работу.
Если у вас не такие админы, то я вам сочуствую. Увольняйте их нахрен и нанимайте нормальных.
Если у вас нет админов вообще, то вы — стартап, который еще не дорос до админов. Если конечно дорастёт вообще...
Здравствуйте, gandjustas, Вы писали:
G>А вот в чем профит от "микросервисов" — я до сих пор не понял и даже внятных примеров нет.
Профит микросервисов в их независимости друг от друга:
— можно создавать на разных языках/платформах, упрощается дизайн сервисов
— можно гибко масштабировать — увеличивать количество только нужных сервисов
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Докер это унифицированный деплой. S>Унифицированный деплой это ansible. S>ansible-playbook playbook-deploy.yaml и оно может даже само выкачать всё нужное.
Напоминает диалог и фильма Snatch
— Мне очень не нравится выезжать из своей страны, особенно выезжать не на теплый песчаный пляж, где все ходят в соломенных шляпах и тебе подтаскивают коктейли.
— У нас тут есть песчаные пляжи.
— Да кому они на х*** нужны, эти ваши пляжи?!
Здравствуйте, Буравчик, Вы писали:
Б>Здравствуйте, gandjustas, Вы писали:
G>>А вот в чем профит от "микросервисов" — я до сих пор не понял и даже внятных примеров нет.
Б>Профит микросервисов в их независимости друг от друга:
Я тоже слышал эти лозунги, но преимущества в чем?
Б>- можно создавать на разных языках/платформах, упрощается дизайн сервисов
То есть вместо одного программиста на одном языке для поддержки теперь требуется 10 программистов на 10 языках? Это реально кто-то считает преимуществом?
Б>- можно гибко масштабировать — увеличивать количество только нужных сервисов
Я примерно то же самое слышал про про CORBA 20 лет назал, про WS-* 15 лет назад и про REST — 10 лет назад.
Проблема только в том, что 99,9% проектов не доживают до состояния когда ВСЕ их компоненты не могут уместиться на одной машине.
разговоры про scale out были модными 10 лет назад, примерно когда и rest. Но, внезапно, мощности серверов растут, а scale-out так и не стал дешевле в пересчете не ядро или гигибайт памяти. А вот сетевые задержки не меняются и толщна каналов, даже внутри ДЦ не растет так сильно.
Здравствуйте, gandjustas, Вы писали:
G>Напоминает диалог и фильма Snatch G>
G>— Мне очень не нравится выезжать из своей страны, особенно выезжать не на теплый песчаный пляж, где все ходят в соломенных шляпах и тебе подтаскивают коктейли.
G>— У нас тут есть песчаные пляжи.
G>— Да кому они на х*** нужны, эти ваши пляжи?!
Ну всё верно. Он ж просил теплый песчаный пляж
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, gandjustas, Вы писали:
G>То есть вместо одного программиста на одном языке для поддержки теперь требуется 10 программистов на 10 языках? Это реально кто-то считает преимуществом?
Да, например AI может быть написан на python, сервисы на go, интеграция с enterprise на java.
Ну и упрощение сервисов — маленькую программу написать проще, также как и переписать с нуля при необходимости.
G>Проблема только в том, что 99,9% проектов не доживают до состояния когда ВСЕ их компоненты не могут уместиться на одной машине.
Есть и другие причины для использования нескольких машин. Например, отказоустойчивость.
G>Но, внезапно, мощности серверов растут, а scale-out так и не стал дешевле в пересчете не ядро или гигибайт памяти
Это пока у тебе запросы скромные — 128 Гб и 32 ядра. А если больше, то становится выгоднее взять несколько серверов вместо супермощного.
S>И правда ведь... Docker — он же не бесплатный по ресурсам, верно? Зачем он, если можно и без него?
Без него будет дольше и хуже, чем с ним. Даже несмотря на то, что докер — говно.
Ты получаешь одинаковый environment на всех стадиях: в разработке, при тестировании, на staging'е, в production'е. Безо всяких свистоплясток типа «а вот у девелопера будет докер, а вот на тесте развернем ansible'ом, а в проде тоже развернем ansible'ом, но надо еще извернуться, чтобы куда-то security-sensitive ключи засунуть» (хотя докер, естественно, не решает проблему ключей).
Получить на dev-машине такой же environment, как на prod'е — бесценно. Остальное — мелочи жизни.
Здравствуйте, Буравчик, Вы писали:
Б>Здравствуйте, gandjustas, Вы писали:
G>>То есть вместо одного программиста на одном языке для поддержки теперь требуется 10 программистов на 10 языках? Это реально кто-то считает преимуществом?
Б>Да, например AI может быть написан на python, сервисы на go, интеграция с enterprise на java.
Но дешевле все сделать на одном языке. На той же java.
Б>Ну и упрощение сервисов — маленькую программу написать проще, также как и переписать с нуля при необходимости.
Написать одну большую программу проще, чем кучу маленьких, в сумме дающих функциональность большой.
G>>Проблема только в том, что 99,9% проектов не доживают до состояния когда ВСЕ их компоненты не могут уместиться на одной машине. Б>Есть и другие причины для использования нескольких машин. Например, отказоустойчивость.
Только вот незадача. Если у тебя N сервисов, которые распределны на N*2 машин, то для ганартированного выхода из строя надо N+1 одновременных отказов. Но, внезапно, отказ может случиться при выходе из строя двух машин.
Тогда как у монолитного приложения, распределенного на 2*N узлов, отказ будет наступать при выходе из строя всех узлов кроме одного.
Чтобы победить эту проблему надо микросервсы размещать на всех узлах кластера, но тогда непонятно зачем микросервисы.
G>>Но, внезапно, мощности серверов растут, а scale-out так и не стал дешевле в пересчете не ядро или гигибайт памяти Б>Это пока у тебе запросы скромные — 128 Гб и 32 ядра. А если больше, то становится выгоднее взять несколько серверов вместо супермощного.
128г и 32 это в 100 раз больше, чем необходимо для среднего проекта. Хотя, возможно, при наличии микросервисов это даже мало.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Буравчик, Вы писали:
Б>>Здравствуйте, gandjustas, Вы писали:
G>>>То есть вместо одного программиста на одном языке для поддержки теперь требуется 10 программистов на 10 языках? Это реально кто-то считает преимуществом?
Б>>Да, например AI может быть написан на python, сервисы на go, интеграция с enterprise на java. G>Но дешевле все сделать на одном языке. На той же java.
так кроме программ там еще БД, прокси, message brokers и куча всего прочего, уже кем-то написанного. Они уже есть и написаны на разных языках
AB>. Для прода, где нужна стабильность и прочие аттрибуты "зрелости" (а не хипстерское "упало, да и фиг с ним — облако новых нарожает") докер непригоден (но не из за оверхеда конечно же).
Это прошлый век.
Тот прод, что нонеча, это как раз "constant partial failure", когда в любой момент времени где-то что-то не работает. Но только у части юзеров, и только часть функциональности. Скажем, не подгружается третья сверху строчка пикселей видеофайла, у жителей Новой Зеландии.
(почему новой зеландии? да потому что они (а) говорят по-английски (б) их не так много (в) они изолированы (г) они уже приучены в случае чего звонить в саппорт )
