Вы не понимаете…
Дело не в том что их нет.
А втом
Вам сравнительно пофиг на потенциальные nashvurnerabilities если ваш контейнер к примеру запускает маленький сервисе на яве.
Docker с Microsoft во всю что-то мутят. Рапортуют об успехах даже. Только если я правильно понимаю это все еще поверх Boot2Docker
Тоесть не «тру стори»
Если перфекционист то, да начинайте оптимировать базовые имиджы ;)
Я стараюсь прибывать в балансе между перфекционизмом и прагматизмом…
Дырка в баше меня не интересует в контейнере в котором бежит какой-нибудь микросервис ничего не делающис с башем (у меня к примеру все такие ;))
Но да если обновлять от разных базовых имиджей (и если вы подошли к вопросю серьезно то базовые имиджи ваши) вы имеете возможность ссылаться на конкретные весрии (это рекомендую)
но даже если у вас будет на хосте рознящиеся aufs layers. Вы действительно беспокоитесь? Ну ок как перфекционист видимо да…
Хорошо но это задача релизмэнедежмента а именно:
1) с головой переезжать на новые версии
2) чисть неиспользуемые имиджы на хостах… и что-бы ни гига лишнего не валялось ;)
Вроде решаемо если так приспичило…
Мне 1) важнее независимо от места на диске.
Именно из-за этой фичи я хочу его в скором времени опробовать!
Вроде маленькая вещь, но kubernetes на её основе (не только конечно) превращает Iaas кластер в Paas по управлению контенерами…
Как ответил frol смысл есть…
Да конечно яву можно запокавать в джарчик и потом? Копировать руками везде? Можете rpm строить и деплоить… уже неплохо…
Но саму яву с версиями тоже надо провизионировать… все это начинает разростатся…
Вопрос не в яве… А скорее хотите вы связывайтся с контейнерами или нет…
Помотрите немного вперед. Сегодня у вас ява а завтра nginx на fronend, послезавтра redis, потом
экспериментальный сервис на Go и вообще вы решили предоставлять кластеру мэнеджмент контейнеров — где чему бежать и хотите чтоб все это работало в продакшн так-же как на вашем лэптопе…
Вот в этом Докер вам поможет.
Чем больше образ => тем больше в нём файлов/пакетов => тем чаще они требуют обновлений => тем чаще вам нужно пересобирать свои образы.
Ну хорошо, в этом есть логика…
Но только не совсем та что вы описываете…
Нет Docker это не puppet — не нужно ему никаких обновлений часто… Вы любите докер за то что он позволяет вам выстроить ваш релизпайплан на базе Immutable images.
Конечно у вас есть какая-то инфраструктура на которй бегут контейнеры, например кластер виртуальных машин. Вот там вы и беспокойтесь об очередном ssl heartbleed.
А в контейнере вас совершенно не интересует, вышла ли новая версия vi или нет…
Конечно и уровень приложений в контеэнре иноигда надфо обоновить иза внешних факторов… Но это как-бы не проблема размера имиджа…
Если вы начинаете оптимировать размер базового имиджа, то значит можно позавидовать вашей прочей инфраструктуре ;)))
Ну что бы навести в этом порядок надо наверное определить задачи:
Вот есть контейнер и самое важно в контейнере это то что он стандартизирован… Снаружи он выглядит одинакого независимо что внутри… конечно он кушает разные проперти и вест поразному но это не важно…
Так вот если остаться в парадиогме архитектуры микросервисов (докер именно её упрощает прежде всего) то докер или Рокет в приницепе не вазно, свою задачу по запуску и мэнедзменту контейнеров они выполнят…
Другое дело если мы рассматриваем аппликацию состоящую из контейнеров и тут уже какраз вся сложность распределенных приложений… И хорошо что там есть конкуренция…
И что выбрать вопсро не легкий…
У само-го руки не доходят…
я в продукции пока польжусь ручными скриптами… но кошусь в сторону CoreOS и потом Kubernetes
Почему разошлись во мнениях CoreOs/Docker команды?
по моей ссылке сверху описано почему…
видит семя на уровне оркестрации контейнерво и их устроил бы докер проект который занимается только контейнерами а экосистемой…
Поэтому они видят опасность что Докер разрастется слишком. В принципе я сними даже согласен… Хорошо что есть конкуренция.
DockerUI
не нужно… Я один раз поставил и понял что я в консоли быстре… Она ничего не предвносит нового по функционалу
the PID 1 problem
Помоему докер со врменем сильно повлияет на архитектуру приложений… И в этой архитектуре совершенно не больно перестартануть контейнер.
А как можно написать о минусах не зная о контексте применения?
Ведь докер это тут сам посебе и может быть применен для решения многих задач…
Так что если вы опишите зачем он вам может вы сами и напишите что вам мешает в докере.
Вот например ребята из CoreOS считают что докер и так уже слишком много задач начинает решать и предлагают сконцентрироваться на контейнерах предлагая свой вариант
Ну и что? это лишь место на диске…
Выберете своим контейнерам базовый имидж и наследуйте от него и будут у вас эти 120 мб один раз на все контейнеры хоста на диске…
Меняет погоду?
Кто и что является клиентами этой базы данных?
Какие запросы типичны?
Если вам кроме широковещательных запросов пригодятся к примеру API только по моделям, только по предприятиям или только по запчастям, то почему бы не разделить на 3 сервиса…
А по широковещатесльным дергать все 3?
Но это только попытка понять задачу…
Может вам всегда надо список деталий, с моделями и предприятими и быстро… а по отдельности никогда не интересно впринципе… тогда и делить может не надо.
Дело ИМХО в том что нет четкого определения что такое микро (несмотря на то что его дают многие ).
В одном контексте микросервисы будут умещатся в 100 строк кода…
В другом это может быть большая штука мэнеджирующая какие-то бизнесс обьекты, которые нет смысла делить.
Дело не в том что их нет.
А втом
Вам сравнительно пофиг на потенциальные nashvurnerabilities если ваш контейнер к примеру запускает маленький сервисе на яве.
www.energy.siemens.com/br/en/renewable-energy/wind-power/platforms/g2-platform/wind-turbine-swt-2-3-108.htm#content=Technical%20specification
Тоесть не «тру стори»
Я стараюсь прибывать в балансе между перфекционизмом и прагматизмом…
Дырка в баше меня не интересует в контейнере в котором бежит какой-нибудь микросервис ничего не делающис с башем (у меня к примеру все такие ;))
Но да если обновлять от разных базовых имиджей (и если вы подошли к вопросю серьезно то базовые имиджи ваши) вы имеете возможность ссылаться на конкретные весрии (это рекомендую)
но даже если у вас будет на хосте рознящиеся aufs layers. Вы действительно беспокоитесь? Ну ок как перфекционист видимо да…
Хорошо но это задача релизмэнедежмента а именно:
1) с головой переезжать на новые версии
2) чисть неиспользуемые имиджы на хостах… и что-бы ни гига лишнего не валялось ;)
Вроде решаемо если так приспичило…
Мне 1) важнее независимо от места на диске.
Вроде маленькая вещь, но kubernetes на её основе (не только конечно) превращает Iaas кластер в Paas по управлению контенерами…
Да конечно яву можно запокавать в джарчик и потом? Копировать руками везде? Можете rpm строить и деплоить… уже неплохо…
Но саму яву с версиями тоже надо провизионировать… все это начинает разростатся…
Вопрос не в яве… А скорее хотите вы связывайтся с контейнерами или нет…
Помотрите немного вперед. Сегодня у вас ява а завтра nginx на fronend, послезавтра redis, потом
экспериментальный сервис на Go и вообще вы решили предоставлять кластеру мэнеджмент контейнеров — где чему бежать и хотите чтоб все это работало в продакшн так-же как на вашем лэптопе…
Вот в этом Докер вам поможет.
Ну хорошо, в этом есть логика…
Но только не совсем та что вы описываете…
Нет Docker это не puppet — не нужно ему никаких обновлений часто… Вы любите докер за то что он позволяет вам выстроить ваш релизпайплан на базе Immutable images.
Конечно у вас есть какая-то инфраструктура на которй бегут контейнеры, например кластер виртуальных машин. Вот там вы и беспокойтесь об очередном ssl heartbleed.
А в контейнере вас совершенно не интересует, вышла ли новая версия vi или нет…
Конечно и уровень приложений в контеэнре иноигда надфо обоновить иза внешних факторов… Но это как-бы не проблема размера имиджа…
Если вы начинаете оптимировать размер базового имиджа, то значит можно позавидовать вашей прочей инфраструктуре ;)))
Наследуйте ваш докерфайл от одного из базового (например мои: registry.hub.docker.com/u/shuron/java_8/ registry.hub.docker.com/u/shuron/debian-openjdk-7/ )
и вперед…
Вот есть контейнер и самое важно в контейнере это то что он стандартизирован… Снаружи он выглядит одинакого независимо что внутри… конечно он кушает разные проперти и вест поразному но это не важно…
Так вот если остаться в парадиогме архитектуры микросервисов (докер именно её упрощает прежде всего) то докер или Рокет в приницепе не вазно, свою задачу по запуску и мэнедзменту контейнеров они выполнят…
Другое дело если мы рассматриваем аппликацию состоящую из контейнеров и тут уже какраз вся сложность распределенных приложений… И хорошо что там есть конкуренция…
И что выбрать вопсро не легкий…
У само-го руки не доходят…
я в продукции пока польжусь ручными скриптами… но кошусь в сторону CoreOS и потом Kubernetes
по моей ссылке сверху описано почему…
видит семя на уровне оркестрации контейнерво и их устроил бы докер проект который занимается только контейнерами а экосистемой…
Поэтому они видят опасность что Докер разрастется слишком. В принципе я сними даже согласен… Хорошо что есть конкуренция.
не нужно… Я один раз поставил и понял что я в консоли быстре… Она ничего не предвносит нового по функционалу
Помоему докер со врменем сильно повлияет на архитектуру приложений… И в этой архитектуре совершенно не больно перестартануть контейнер.
Ведь докер это тут сам посебе и может быть применен для решения многих задач…
Так что если вы опишите зачем он вам может вы сами и напишите что вам мешает в докере.
Вот например ребята из CoreOS считают что докер и так уже слишком много задач начинает решать и предлагают сконцентрироваться на контейнерах предлагая свой вариант
начиная вот с это-го ответа:
stackoverflow.com/questions/16047306/how-is-docker-io-different-from-a-normal-virtual-machine/25938347#25938347
Это именно заче он нужен девелоперам.
А выше про техническии отличия от виртуалок.
Выберете своим контейнерам базовый имидж и наследуйте от него и будут у вас эти 120 мб один раз на все контейнеры хоста на диске…
Меняет погоду?
Вернее даже заюзать готовые из репы… А sshd вам не нужен в контехнерах.
Все остальное блекнет, включае комерческое…
Имею опыт внедрения на серьезные немецкие предприятия.
И как обычно в архитектурах куча Trade-offs :)
Какие запросы типичны?
Если вам кроме широковещательных запросов пригодятся к примеру API только по моделям, только по предприятиям или только по запчастям, то почему бы не разделить на 3 сервиса…
А по широковещатесльным дергать все 3?
Но это только попытка понять задачу…
Может вам всегда надо список деталий, с моделями и предприятими и быстро… а по отдельности никогда не интересно впринципе… тогда и делить может не надо.
Дело ИМХО в том что нет четкого определения что такое микро (несмотря на то что его дают многие ).
В одном контексте микросервисы будут умещатся в 100 строк кода…
В другом это может быть большая штука мэнеджирующая какие-то бизнесс обьекты, которые нет смысла делить.