Comments 22
И в чём вывод? Используйте Docker и будет счастье?
По наблюдениям довольно мало людей знают, что такое докер. Я недавно был на собеседовании и они там чуть ли не кипятком… когда узнали, что знаю, что такое докер и даже могу создавать образы. Да и знакомые администраторы тоже не очень в теме, может из-за того, что они больше с виндой работают.
Мне вот интересно, это только я так докер воспринимаю, что это революция (или очень близко) в виртуализации (я понимаю, что это не виртуализация) или я это как-то не так воспринимаю? Скоро сюда ещё и Microsoft подключится со своим нано сервером.
Мне вот интересно, это только я так докер воспринимаю, что это революция (или очень близко) в виртуализации (я понимаю, что это не виртуализация) или я это как-то не так воспринимаю? Скоро сюда ещё и Microsoft подключится со своим нано сервером.
Я склонен считать, что таки эволюция
Простите моё невежество, но в чем именно революция?
Контейнерами уже лет 10 пользуются через OpenVZ и любой админ из хостинга умеет с ним работать.
Контейнерами уже лет 10 пользуются через OpenVZ и любой админ из хостинга умеет с ним работать.
LXC как технология существует с 2008 года.
Имхо такие вещи как Docker, Vagrant, CoreOS — однозначно революция.
Просто потому что они сделали уже существующие сложные вещи очень простыми для использования и автоматизации.
Просто потому что они сделали уже существующие сложные вещи очень простыми для использования и автоматизации.
Скорее уж docker registry. Именно благодаря репозиторию мы обязаны всей этой шумихи вокруг контейнеров. Примерно такое же произошло с появлением github.
На момент появления публичного Docker Hub все уже неплохо вертелось: blog.docker.com/2014/06/announcing-docker-hub-and-official-repositories В любом случае, Hub/Registry это важная часть Docker платформы и экосистемы.
Сыграло все:
Особенно важно выделить огромную работу на публику: Конференции, DockerCon, доклады. Отсюда и куча людей, которые начали его пробовать и нести свой вклад в проект через GitHub (1К contributors!)
Для большинства из нас Docker появился внезапно, многие узнали о нем уже будучи популярным. Но вся эта популярность благодаря OpenSource экосистеме и работе с коммьюнити (ну и $150M инвестиций :)
Сыграло все:
- OpenSource!
- простота
- низкий порог вхождения
- хороший API
- быстрый движок
- очень много интеграций
- четкие и понятные преимущества
- работает для enterprise/маленьких систем
Особенно важно выделить огромную работу на публику: Конференции, DockerCon, доклады. Отсюда и куча людей, которые начали его пробовать и нести свой вклад в проект через GitHub (1К contributors!)
Коммьюнити
Для большинства из нас Docker появился внезапно, многие узнали о нем уже будучи популярным. Но вся эта популярность благодаря OpenSource экосистеме и работе с коммьюнити (ну и $150M инвестиций :)
Это ли не революция? Новый подход при создании приложений
Панацеи, все-таки, нет и нужно под каждую конкретную задачу искать оптимальное решение.
К тому же, многие из проблем, поднимаемых автором, уже решены. Не покидает ощущение, что писалось лет 5-7 назад.
К тому же, многие из проблем, поднимаемых автором, уже решены. Не покидает ощущение, что писалось лет 5-7 назад.
Как раз насчет кластера на контейнерах и пишу статьи. На этих выходных, если успею, вторую из цикла допишу. Ссылка, если интересно.
Автор статьи использует hadoop yarn (ПО, требовательное к I/O) на виртуалках?
Может просто не использовать виртуалки?
Если выделять под hadoop отдельный железный сервер, отпадет необходимость «быстро развернуть кучу виртуалок под hadoop».
Такое ощущение, что у автора на работе много серверов виртуализации общего назначения.
И он осознал, что разворачивать в них кучу виртуалок для hadoop — неоптимально.
Ему бы прийти к CIO и сказать «нам нужно выделить часть серверов только под hadoop».
Или может я чего-то непонимаю?
Может просто не использовать виртуалки?
Если выделять под hadoop отдельный железный сервер, отпадет необходимость «быстро развернуть кучу виртуалок под hadoop».
Такое ощущение, что у автора на работе много серверов виртуализации общего назначения.
И он осознал, что разворачивать в них кучу виртуалок для hadoop — неоптимально.
Ему бы прийти к CIO и сказать «нам нужно выделить часть серверов только под hadoop».
Или может я чего-то непонимаю?
да даже не знаю как описать, то что автор набросал:
1) hadoop (главная идея) — если данным долго идти к processing unit, то давайте вычислительные юниты придут к данным — объединяем data & compute nodes на одних машинках
2) YARN — изоляция ВЫЧИСЛИТЕЛЬНЫХ ресурсов (память/cpu/io), но в любом случае доступ к hdfs проходит зачастую по direct без использования сетевых сокетов. пытаться разворачивать свои приложения в ярне просто потому, что это модно или он якобы даёт хорошую изоляцию ресурсов глупо, уж лучше mesos смотреть в этом случае. Ярн использует cgroups, но namespaces не использует и не собирается, так как у него совсем другие задачи.
3) KSM — не, я конечно понимаю что openvz её не поддерживает (могу ошибаться, давно пинал), но lxc её умеет. её разрабатывали как раз для повышения плотности приложений и не только виртуалок.
4) www.projectserengeti.org — гипервизор предоставляет планировщику хадупа структуру кластера с учетом физической топологии (виртмашина-физмашина-стойка). неужели вы думаете, что vmware так просто отдаст этот рынок?
5) «Так, в случае Hadoop виртуализованный стек ввода/вывода состоит из HDFS, гостевой файловой системы, гостевого драйвера, виртуального устройства, интерпретатора формата образов, файловой системы хоста, драйвера хоста и, наконец, физического устройства» — raw девайсы отдавать уже не модно в виртуалки?
мне интересно другое:
для некоторых задач в которых применяются виртуалки приходится тюнить параметры ядра (зачастую сеть), есть задачи где требуются свои кастомные модули загружать в ядро, КАК в таких случаях себя поведут контейнеры?
в итоге статья сводится к КО: пихать везде виртуализацию глупо
но продолжается неправильно: давайте пихать везде контейнеры
а уж каким боком рассматривается yarn в качестве горизонтального масштабирования, учитывая до конца нерешенные проблемы с long running приложениями, я не понимаю, я бы еще понял если бы он в пример приводил mesos и mesosphere.com
1) hadoop (главная идея) — если данным долго идти к processing unit, то давайте вычислительные юниты придут к данным — объединяем data & compute nodes на одних машинках
2) YARN — изоляция ВЫЧИСЛИТЕЛЬНЫХ ресурсов (память/cpu/io), но в любом случае доступ к hdfs проходит зачастую по direct без использования сетевых сокетов. пытаться разворачивать свои приложения в ярне просто потому, что это модно или он якобы даёт хорошую изоляцию ресурсов глупо, уж лучше mesos смотреть в этом случае. Ярн использует cgroups, но namespaces не использует и не собирается, так как у него совсем другие задачи.
3) KSM — не, я конечно понимаю что openvz её не поддерживает (могу ошибаться, давно пинал), но lxc её умеет. её разрабатывали как раз для повышения плотности приложений и не только виртуалок.
4) www.projectserengeti.org — гипервизор предоставляет планировщику хадупа структуру кластера с учетом физической топологии (виртмашина-физмашина-стойка). неужели вы думаете, что vmware так просто отдаст этот рынок?
5) «Так, в случае Hadoop виртуализованный стек ввода/вывода состоит из HDFS, гостевой файловой системы, гостевого драйвера, виртуального устройства, интерпретатора формата образов, файловой системы хоста, драйвера хоста и, наконец, физического устройства» — raw девайсы отдавать уже не модно в виртуалки?
мне интересно другое:
для некоторых задач в которых применяются виртуалки приходится тюнить параметры ядра (зачастую сеть), есть задачи где требуются свои кастомные модули загружать в ядро, КАК в таких случаях себя поведут контейнеры?
в итоге статья сводится к КО: пихать везде виртуализацию глупо
но продолжается неправильно: давайте пихать везде контейнеры
а уж каким боком рассматривается yarn в качестве горизонтального масштабирования, учитывая до конца нерешенные проблемы с long running приложениями, я не понимаю, я бы еще понял если бы он в пример приводил mesos и mesosphere.com
Вроде в любой книге по Hadoop Operations написано, что запускать его на виртуалках — нефига не хорошая идея дл прода.
docker — го-гавно. все просто на нем зависли.
контейнеров — дохера.
виртуализация в продакшн… кто так делает -то?
контейнеров — дохера.
виртуализация в продакшн… кто так делает -то?
и я не думаю, что надо хвалиться тем, что ТП может развернуть контейнер (это как верстать в дримвивере и программировать в пазл-игре),
если нихера не понимаешь это не поможет.
например: мне, как человеку плохо врубающемуся в dns устраивает, что какой нить DO перет эти проблемы на себя давая мне простую формочку…
но это не проканает если надо настроить кластер машин… для боя…
но мыж тут не про сайт-васи-пупкина.рф говорим?
если нихера не понимаешь это не поможет.
например: мне, как человеку плохо врубающемуся в dns устраивает, что какой нить DO перет эти проблемы на себя давая мне простую формочку…
но это не проканает если надо настроить кластер машин… для боя…
но мыж тут не про сайт-васи-пупкина.рф говорим?
Docker бомба! К сожалению еще не все осознали, но все двигается в сторону замены бесполезных громоздких виртуальных машин на контейнеры. У нас в компании успешно развернут кластер на Kubernetes, в котором ежедневно деплоится/ранятся/удаляется пару сотен контейнеров и сервисами и апликухами, для автоматизированного и ручного тестирования. Огромный плюс в том, что среда разработки идентична среде тестирования и продакшн. Просто скачивается готовый образ и за пару десятков секунд стартует необходимая среда с всеми компонентами. Как-нибудь напишу про это подробнее.
Sign up to leave a comment.
Незваный гость. Почему виртуальные машины — не лучшее решение для приложений завтрашнего дня?