Анонсирована (http://rancher.com/announcing-rancher-os/) новая операционная система RancherOS (http://rancher.com/rancher-os/), напоминающая по своей сути проекты Atomic (http://www.opennet.me/opennews/art.shtml?num=39583) и CoreOS (http://www.opennet.me/opennews/art.shtml?num=40275), и также предоставляющая минимальную обвязку для запуска изолированных контейнеров. Ключевым отличием RancherOS является отказ от использование системного менеджера systemd и использование собственной системы инициализации, построенной непосредственно на базе инструментария Docker. Код системы написан на языке Go и распространяется (https://github.com/rancherio/os) под лицензией Apache. Проект основан (http://rancher.com/about/) несколькими известными разработчиками из компании Citrix и бывшими руководителями Cloud.com.
Размер загрузочного образа (https://github.com/rancherio/os/releases/) RancherOS составляет всего 20 Мб. Системное окружение RancherOS скомпоновано в виде образа начальной загрузки (initrd) и содержит абсолютный минимум, необходимый для запуска контейнеров на базе системы Docker. Всё остальное, включая udev, dhcp, ntp, cloud-init и rsyslog, запускается внутри отдельных системных контейнеров. Всё в RancherOS является контейнером. Над контейнерами функционирует только процесс Docker, выполняемый с PID 1. Пользовательский инструментарий и демон dockerd для запуска пользовательских контейнеров также выполняется в отдельном контейнере User Docker.<center><a href="https://raw.githubusercontent.com/rancherio/os/master/docs/r... src="http://www.opennet.me/opennews/pics_base/0_1424856398.png" style="border-style: solid; border-color: #606060; border-width: 1px;max-width:100%;" title="" border=0></a></center>
Имеется также специальный системный контейнер Сonsole, предоставляющий пользовательское окружения для управления RancherOS в консольном режиме. По умолчанию консольное окружение доступно по ssh и сформировано с использованием инструментария Busybox, но при желании в качестве консоли можно подключить полноценные программные окружения на основе Ubuntu, CentOS или Fedora. Между перезапусками сохраняется только содержимое разделов /opt и /home, всё остальное возвращается в исходное состояние. Конфигурация окружения передаётся во время загрузки через механизм cloud-init или определяется командой "rancherctl config" и затем сохраняется в специальный файл конфигурации. Для настройки также можно использовать web-интерфейс Rancher.io (https://github.com/rancherio/rancher). Обновление производится атомарно на уровне обновления целых контейнеров, в форме пакетов docker также обновляются ядро и образ начальной загрузки (initrd).
<center><a href="https://raw.githubusercontent.com/rancherio/rancher/master/d... src="http://www.opennet.me/opennews/pics_base/0_1424857617.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center>
<center><iframe src="//player.vimeo.com/video/120530912" width="500" height="272" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen></iframe></center>
URL: http://rancher.com/announcing-rancher-os/
Новость: http://www.opennet.me/opennews/art.shtml?num=41728
Видел такое в Ведроиде. В общем - правильное направление. Давно пора.
Баян ваще-то, только раньше оно называлось адресное пространство процесса и рулил там менеджер памяти,
сейчас назвали контейнер и гипервизор. Но такая х..ня, что для контейнеров нужно в 50 раз более мощное железо.Думаете изолировав процесс вы избавитесь от багов? Хрен там! Вы их увеличите в N*log[2](N) раз.
А если врубить Kernel Same Page, дедупликацию, ZRAM/zmalloc... ваще шайтан ящик получится.
Только назвать это всё нужнo FatThreads.Отседа вывод: Маркетолуги доят.
>Только назвать это всё нужнo FatThreads.Что то в этом есть, да ....
> для контейнеров нужно в 50 раз более мощное железо.Памяти только, остальное железо зачем более мощное?
А памяти зачем? В докере же вроде с отказом от ауфс забороли ту шнягу, когда один и тот же файл оказывался в пейжкэше несколько раз. Или не забороли?
Ну как, это же мечта каждого программера параллельных вычислений - на каждый тред по процу.
Полностью поддерживаю pavlinux-а, контейнерами и изоляцией вообще начинают заниматься люди которые не изучили принципов работы ОС, всё остальное порождает тормоза и кучу багов.
> А если врубить Kernel Same Page, дедупликацию, ZRAM/zmalloc... ваще шайтан ящик получится.Это ведроид. ИСЧХ, работает.
Рассказ слегка не по теме. В наше время очень дофига недоверенных приложений от проприетарных вендоров и было бы здорово их разделить.
В 90% случаев от них прекрасно можно (и нужно) отказаться. Что за идиотизм - добровольно гонять у себя недоверенный код... Тут JS стараешься не включать лишний раз.
> В 90% случаев от них прекрасно можно (и нужно) отказаться. Что за
> идиотизм - добровольно гонять у себя недоверенный код...Точно. Пока не проверил каждую строчку сорцов, и каждый байт компилятора - не смей запускать компиляцию!
вообще‐то раньше надо начинать: с составления генной карты. вот твои родители пропустили этот этап — и на свет появился ты. и зря.
>> А если врубить Kernel Same Page, дедупликацию, ZRAM/zmalloc... ваще шайтан ящик получится.
> Это ведроид. ИСЧХ, работает.Оно-то работает, только КПД от него в андроиде как от паравоза.
KSM задумывалось для вируталок с одинаковым содержимым, в данном случае оно
будет работать, в андроеде ну реально, простой больше жрёт тактов и кучу.
как тут поднимет некоторым настроение отсутствие systemd :)
правда в консоле будет, если поставить CentOS :)))))зы «dockerd - наше всё!»
> зы «dockerd - наше всё!»Для слоупоков и маргиналов может быть.
Серьезные облачные проекты строятся на smartos/leofs
Скорее нет, чем да. А вы просто диванный аналитег.
> Серьезные облачные проекты строятся на ... leofsЭто редкое gовнище. Имею "удовольствие" работать с этой лавкой. Наши идиоты походу их наняли для Ъ ... и теперь у нас сэкс в гамаке каждый день :(
> Серьезные облачные проекты строятся на smartos/leofs"Просто пробежать стометровку может любой лох! Вот если намылить асфальт и надеть ласты и противогаз - тогда вы настоящий спортсмен!"
edited: Тогда ты - настоящий солдат! (срочник)
> Серьезные облачные проектыОксюморон.
> как тут поднимет некоторым настроение отсутствие systemd :)Ага. Давно назревал вопрос замутить еще более жирный и кривой комбайн, чем systemd, чтобы народ валил на него, "потому что не systemd" :)
Как говорится, да будет каждому наукой случившееся между жабой и гадюкой
Гораздо более показательно то, что нелюбители жабы стремятся выбрать гадюку себе в кумиры :)
Ага, довольно забавно
> Давно назревал вопрос замутить еще более жирный и кривой комбайн, чем systemdэто как?
>> Давно назревал вопрос замутить еще более жирный и кривой комбайн, чем systemd
> это как?Лехко. Берем несколько адептов юниксвея, даем им компы, в которых из ЯП только шелл, запираем в подвале на полгодика, и вуаля!
Можно подумать, что на шелле нельзя забутстрапить компилятор :-)
> Можно подумать, что на шелле нельзя забутстрапить компилятор :-)Вопрос не в том. Что они будут делать ещё три с половиной месяца после того, как за две недели звмутят lisp на шеле, потом напишут на нём компилёр?
Хм, да, может получиться emacs :-)
> Вопрос не в том. Что они будут делать ещё три с половиной месяца после того, как за две недели звмутят lisp на шеле, потом напишут на нём компилёр?Будут пытаться запустить то, что написали :)
> Будут пытаться запустить то, что написали :)НедЪ )) Окажется, что пол-года они смотрели сериалы с планшета, через хакнутый wi-fi, и написали "Hello world! Suck my socks!" в консоли, потому что давно познали Дзен и не хотят плодить лишние сущности ))
А теперь ставьте свои минусы, школота )
То есть для тебя "познавшие Дзен" - это придурки, которым только сериалы смотреть, а что-то создать just for fun - зло? Ок, понято
> что-то создать just for fun - зло?Наоборот, это для познавших адептов так. Написал кто-то что - сразу крики "блоб", "блоатварь", "вендорлок" и другие страшные и непонятные слова.
> познали Дзен и не хотят плодить лишние сущности ))Это Дзен, а юникс-вей :)
Писать код и плодить сущности - удел всяких поцтерингов. Познавшие юникс-вей понимают, что написано уже более чем достаточно, и поэтому единственное достойное дело - критиковать, уничтожать и запрещать то, что уже написано.
В systemd свои контейнеры есть
> В systemd свои контейнеры естьParallels и kernel.org вздрогнули!
экий занятный вариант на тему кубов и прочего гипервизорства. Пожелаю удачи проекту.
Каких ещё кубов?
qubes os
Практически ничего общего
> экий занятный вариант на тему кубов и прочего гипервизорства. Пожелаю удачи проекту.Контейнеры - это не гипервизор. Гипервизор может существенно повысить безопасность, контейнеры - вряд ли. Особенно с учетом глобальной недопиленности LXC.
Да и в самом Docker с безопасностью далеко не гладко всё.
> Да и в самом Docker с безопасностью далеко не гладко всё.Ну, в KVM и Xen тоже бывали досадные ляпы. Особенно в Xen.
Но insecure by design LXC настораживает гораздо больше. Попробуйте настроить в контейнерах SELinux или auditd (последнее худо-бедно начали решать путем его переноса в journald, но к сабжу по понятной причина это не относится).
> SELinux или auditd (последнее худо-бедно начали решать путем его переноса в
> journald, но к сабжу по понятной причина это не относится).Если долбит паранойя - запускаем KVM виртуалку, в ней вложенную виртуалку, а там уже создаем контейнер. В него вкладываем еще контейнер. И самое главное - никакой сети!
> Если долбит паранойя - запускаем KVM виртуалку, в ней вложенную виртуалку, а
> там уже создаем контейнер. В него вкладываем еще контейнер. И самое
> главное - никакой сети!И ни в коем случае не включать. Это если паранойя.
А мандатный контроль доступа и аудит событий безопасности - стандартные требования при сертификации системы на более-менее серьезный уровень безопасности.
> А мандатный контроль доступа и аудит событий безопасности - стандартные требования при
> сертификации системы на более-менее серьезный уровень безопасности.А я и без сертификации такое на серверах запиливаю.
Я уж подумал, что ядро, udev и т.д. на молодёжном Go написали, а они вон чё... читеры вообщем.
Неплохо, только это г-но на Go. Правильное решение должно быть на Си.
+100500
> +100500Леннарт, залогинься!
> Неплохо, только это г-но на Go.Скажите спасибо, что не на гвидобэйсике.
вон lxc частями на гводобейсике и нече
>и нечеЭто для тебя "нече" потому что ты неграмотен повсюду. Максимум что можно делать - это статически слинковать с libperl (а скрипты управления на perl). Смысл в том что perl очень легко позволяет создать проблемно-ориентированный язык. Тогда можно будет писать динамичные сценарии управления со строгой грамматикой под прикладную область. Но это все уже зубодробильно, т.к. большинство заскулит от одного вида libperl.
Правильное и "чистое" решение - сделать все на Си (в т.ч. и ПОЯ, есть же bison, в конце-концов).
А зачем что-то линковать? В нормальном UNIX, API не зависит от языка. fork+exec "lxc-blah --blah", и все делов.
>А зачем что-то линковать? В нормальном UNIX, API не зависит от языка. fork+exec "lxc-blah --blah", и все делов.Глянь на архитектуру этого поделия. Линковать чтобы выражения и лексемы ПОЯ не гонять через argv для вычисления, а решать это сразу в PID 1. И только на исполнение fork+exec отдавать задание.
> Глянь на архитектуру этого поделия. Линковать чтобы выражения и лексемы ПОЯ не
> гонять через argv для вычисления, а решать это сразу в PID 1.Но зачем? Это же сугубо вопрос удобства. Скорость будет чуть меньше, да, но это не критично.
>Но зачем? Это же сугубо вопрос удобства. Скорость будет чуть меньше, да, но это не критично.Что-то я не никак пойму зачем разбивать поиск решения задачи на множество независимых исполняемых модулей? Можно конечно сделать отдельные бинарники на любые операции (один бинарник складывает два числа, другой - умножает, третий - делит) и агрументы результаты передавать через argv, но как-то логичнее будет сделать это в рамках функции с передачей аргументов через стек и регистры. Объясните.
> Что-то я не никак пойму зачем разбивать поиск решения задачи на множество
> независимых исполняемых модулей? Можно конечно сделать отдельные бинарники на любые операции
> (один бинарник складывает два числа, другой - умножает, третий - делит)
> и агрументы результаты передавать через argv, но как-то логичнее будет сделать
> это в рамках функции с передачей аргументов через стек и регистры.
> Объясните.Это называется "философия UNIX". В противовес ей - "философия Windows", основанная на линковке бинарников с библиотеками.
>Это называется "философия UNIX". В противовес ей - "философия Windows", основанная на линковке бинарников с библиотеками.Не знаю как вы называете для себя расщепление функции, но это однозначно не "Unix-way". Ну а "Windows-way" вообще не сформулирован как концепция. Не нужно разводить фантазии, нужно пытаться вникать в обстоятельства глубже, либо вообще лучше молчать.
>>Это называется "философия UNIX". В противовес ей - "философия Windows", основанная на линковке бинарников с библиотеками.
> Не знаю как вы называете для себя расщепление функции, но это однозначно не "Unix-way".Почему? Каждая программа должна делать _одно_ дело, и делать его хорошо.
Пока существует возможность разделить функцию на несколько более простых - это необходимо делать.
>Почему? Каждая программа должна делать _одно_ дело, и делать его хорошо.
>Пока существует возможность разделить функцию на несколько более простых - это необходимо делать.Наверное вы не поняли философию unix-way, а лишь ограничились какой-то частью.
Так вот, в программах много функции. Следует ли из этого что каждую функцию нужно расщеплять до тех пора пока от функции не останутся одни операторы разнесенные по разным двоичным модулям? Вам не кажется что тут что-то "не так" ?
> Так вот, в программах много функции. Следует ли из этого что каждую
> функцию нужно расщеплять до тех пора пока от функции не останутся
> одни операторы разнесенные по разным двоичным модулям? Вам не кажется что
> тут что-то "не так" ?А никто и не утверждает, что философия unix идеальна (кроме совсем уж упертых адептов). Как и все крайности, она имеет свои плюсы и минусы. В частности, один из важнейших плюсов - возможность заменить реализацию практически каждой операции на альтернативную, без пересборки.
>А никто и не утверждает, что философия unix идеальна (кроме совсем уж упертых адептов). Как и все крайности, она имеет свои плюсы и минусы. В частности, один из важнейших плюсов - возможность заменить реализацию практически каждой операции на альтернативную, без пересборки.Вы начинаете себе противоречить или вы уклоняетесь от ответа? Перечитайте мое сообщение и ответьте на вопросы.
> Правильное и "чистое" решение - сделать все на Си (в т.ч. и
> ПОЯ, есть же bison, в конце-концов).Обоснуй!
>Обоснуй!Что именно? Не могу понять что тебе тут не ясно.
Еще раз: я попросил привести обоснование утверждению, которое процитировал. Что мне ясно, а что не ясно - к делу совсем не относится.
>Еще раз: я попросил привести обоснование утверждению, которое процитировал. Что мне ясно, а что не ясно - к делу совсем не относится.Извини, бесплатно не обучаю. Есть вопросы/претензии - задавай предметно.
Я так и думал.
>Я так и думал.И что это изменило? Какая разница как ты думал или не думал?
> Смысл в том что perl очень легко позволяет создать проблемно-ориентированный язык.вот это точно. если не хватает проблем — perl всегда готов помочь.
> вон lxc частями на гводобейсике и нечеПоэтому и вылетит в пользу systemd.
>> вон lxc частями на гводобейсике и нече
> Поэтому и вылетит в пользу systemd.Нет.
https://www.openhub.net/p/systemd/analyses/latest/languages_...
Python 800 758 48.7% 368 1,926 0.5%https://www.openhub.net/p/systemd/analyses/latest/languages_...
Python 1,208 414 25.5% 371 1,993 3.0%
> systemd
> Python
> 0.5%Ужас какой.
Правильно решение должно быть на Objective-C. Что мы все и видим. Точка.
Хм, судя по анонсу - это такой специализированный уродец, рассчитанный на использование в качестве элемента облака. Ну так оно хоть какой-то смысл имеет...
Отказ от хоста не даёт никакого профита ни в производительности ни в потреблении ресурсов ни в управлении контейнерами.Профит есть изза лифтинга всех сервисов до контейнера — у нас есть только контейнеры, соотвественно весь софт, который применяется к контейнерам можна использовать для 100% софта. Минус — завязка на docker. А ведь кроме докера есть и другие системы.
Но с другой стороны можна сделать лифтинг всего к хосту, и весь софт, который работает для обычного хоста будет работать для 100% сервисов. Минус — systemd(uselessd?) и sshd на каждом хосте, но это небольшая плата за не привязаность к конкретной реализации. Плюс — нам пофиг на реализацию. docker, lxc, qemu/kvm, VServer, Xen, ..., всё будет работать.
> Плюс — нам пофиг на реализацию. docker, lxc, qemu/kvm, VServer, Xen, ..., всё будет работать.Ну запустите мне udev в отдельной от основной системы kvm-виртуалке :)
Ты не вкурил суть. Rancher предлагает делать docker cat file | docker wc -l — каждый процес в отдельном контейнере и докер рулит всеми.Я говорю что профита в этом нет. Проще сделать docker "cat file | wc-l" или lxc "...", или qemu "...", или вообще без.
> Ну запустите мне udev в отдельной от основной системы kvm-виртуалке :)А если я запущу udev в отдельной от основной системы kvm-виртуалке, то ... что?
> А если я запущу udev в отдельной от основной системы kvm-виртуалке, то ... что?А ничего. Совсем ничего. С тем же успехам можно не запускать udev вообще.
смотрю я на все эти телодвижения последних лет и мне все сильнее хочется запилить zaebalid ..
Вот как-то да, всё это выглядит, как изготовление красивых обёрток для прикрытия вонючей субстанции вместо того, чтобы её расчищать.Я понимал, когда переходили на виртуализацию - простота менеджмента, экономия железных ресурсов, простота масштабирования. А вот что к этому добавляют контейнеры - не понимаю, хоть убей. Единственное, что видится - удобство запуска сторонних проприетарных черных ящиков или софта, который так криво написан, что нормальными системными средствами им управлять не получается. Оба случая совсем не радуют.
> А вот что к этому добавляют контейнеры - не понимаю, хоть убей.Попробуйте поработать админом на более-менее крупных проектах, поймете довольно быстро. Или вам это хуже смерти?
Лично мне - хуже смерти (админил маленько в своё время - программировать гораздо веселее). Но знаю область более-менее. И хоть убей - не вижу, где там контейнеры нужны. Виртуализация - да, даёт управляемость и масштабирование. А зачем растаскивать по клеткам все процессы - не понимаю. Всё равно нормальная виртуалка имеет только одну функцию, а всё остальное в ней - как раз те самые syslog и подобное.Всё, что видел - либо voip вроде Asterisk и подобного, либо веб-серверы и скрипты на пыхах/перлах/рубях/питонах, либо J2EE, либо постгре с мускулом - ни в каких контейнерах не нуждалось и при минимальной вменяемости авторов деплоилось стандартным RPM плюс генерация конфигов когда надо - ну и при нужде стандартные образы виртуалок создавались и использовались.
> А зачем растаскивать по клеткам все процессы - не понимаю.Ключевая ошибка в слове "все", это действительно глупое применение. Контейнеры можно использовать точно также как и виртуалки, только с более удобным управлением и гораздо меньшим оверхедом.
Ну, поинт автора (который в мире докера, я так понимаю - совсем не последний человек) в том, чтобы именно всё по контейнерам распихивать.А так - в виртуалке на моей памяти всегда крутился один "большой" процесс (ну, или несколько клонов, как в случае fastcgi), всё остальное - служебные штуковины вроде syslog и тому подобного. А основной процесс всё равно хочется изолировать основательно - со своим разделом или диском, с возможностью полноценной миграции на другое железо, часто - со своим ядром и т.п. - то есть полноценная виртуалка - то, что доктор прописал.
> то есть полноценная виртуалка - то, что
> доктор прописал.Подтверждаю. Просто есть такие люди - бдсм-щики. Они берут роутер за 1500р, прошивают туда дд-врт, втыкают usb-hdd и принтер через hub, делают шары с этого Hdd, а потом жалуются что интернет тормозит ))
Для меня даже виртуалки - зло, которое внедряется только там, где нужно либо малое время простоя "в случае чего", а нормальную репликацию не сделать. Либо для разделения ресурсов нескольких серверов между сервисами, и "перекидывании" на время обслуживания сервера, либо более оптимального использования ресурсов.Виртуализация ради безопасности - это как заниматься любовью с кем попало и надеяться на презерватив. Лучше партнеров тщательнее выбирать, и в опасные порты пускать только по ip.
Конечно "одминов Ынтырпрайза" которые тут собрались это не касается, у них миллионы клиентов и пальцы веером )))
> вижу, где там контейнеры нужны. Виртуализация - да, даёт управляемость и
> масштабирование. А зачем растаскивать по клеткам все процессы - не понимаю.Затем что меньше оверхеда чем виртуализация при зачастую приемлимом уровне изоляции. То что оно местами бывает недопилено - второй вопрос.
Да проще всё - теперь продавцы VDS смогут продать не десятки из с одного тухлого песюга, а тысЩЩи. И всё.
окстись, они сто лет как Virtuozzo для этого используют. Но когда стал широко распространён Xen сотоварищи - лохов, ведущихся на virtuozzo, как-то поубавилось.
> окстись, они сто лет как Virtuozzo для этого используют. Но когда стал
> широко распространён Xen сотоварищи - лохов, ведущихся на virtuozzo, как-то поубавилось.Кому-то действительно нужно запускать свое ядро, и они готовы за гораздо большие деньги получать меньше ресурсов.
А кому-то это не надо. И если бы они тоже брали себе xen/kvm/vmware, они бы и были лохами.
Всё глючит - это аксиома. То, что глючит, не должно мешать остальному - это требование. Программы собирают из всякого шлака, кишки и шлак одного могут мешать работать соседнему - это жизнь.Минималистичный гипервизор управляет контейнерами, в каждом из которых запущен отдельный процесс со всем своим шлаком. Если он глючит - мы его перезапускаем. Весь контейнер.
Это не лучшее решение, но самое дешёвое из приемлимых.
С другой стороны сидят программеры, (недешёвый) труд которых оплачивается по часам и лучше тот, кто сделал задачу быстрее соседа. Быстрее - значит набросать шлак, скомпоновать лишь бы запустилось, и отдать в продакшн. Работает - ОК, глюкануло - перезапустилось, упало - отжалось.
Не рассказывай мне прописные истины. Всё это сто лет как решено виртуалками.
Официально "контейнеры" называются "контейнерная виртуализация". Судя по всему, прописные истины до тебя не дошли.Поработаю поисковой машиной: http://habrahabr.ru/company/centosadmin/blog/212985/ Это лик.без. Для ламо с гуманитарным образованием.
Кхм, неудивительно, что ты эту хрень читаешь, клоун. Видишь ли, когда ты вырастешь за пределы рефератов ты поймёшь, что основной вопрос всегда - не "что бывает". а "какая есть проблема, как она решается и где это решение перестаёт работать". И плевать, как контейнеры можно красиво назвать или как их нызвают официально. Ежу понятно, что в контексте обсуждения я сравнивал полноценную хардверную виртуализацию с контейнерами, и твои придирки к словам на аргумент как-то не тянут. Что забавно - в предыдущем сообщении вроде ж осмысленную (хоть и не относящцюся к делу) идею высказал - и тут же начал хрень нести как обычно.
Если ложить болт на теорию, то появляются "а зачем", "а я не понял".Stop thinking! Just read it!
Аппаратная виртуализация, которую ты понимаешь, нужна чтобы запустить ПО не предназначенной для твоей ОС или для архитектуры твоего ПК.
Контейнерная виртуализация позволяет запускать виртуализировать нативные приложения без потери производительности.
Понял, бобик?
Это ты бы головой подумал вместо того, чтобы туда есть. Впрочем, что с виндоклоуна взять.Процессоры, не поддерживающие аппаратную выиртуализацию, вымерли лет пять назад как минимум. А с появлением IOMMU - потерь производительности (которых и так было довольно мало с virtio) практически нет. И, что характерно, всё зто сто лет как работвает в продакшне и даёт реальную изоляцию на том уровне, где она действительно имеет смысл.
Но что ты так рад контейнерам - меня не удивляет ни разу - это ж готовая инфрастукрура для запуска сраной проприетарщины. Что до меня - я полагаю, что сие действо должно быть настолько неудобным, насколько возможно.
изыни, но ты клинический ИДИОТ. оверхед полноценной виртуалке на ПОРЯДОК выше конйтенера.
Я, если что, его мерил когда-то. Процентов 20 выходило на Xen по сравнению с голым железом - и по диску, и по вычислениям - разумеется, с virtio и толком настроенными ядрами. То, что оверхед контейнера может быть на порядок меньше - то есть в пределах пары процентов - я не спорю, но и 20% - ни разу не катастрофа. Тем более, что было это лет пять назад, наверняка с тех пор что-то поправили. А за эти 20% имеем гарантированно хорошую и давно вылизанную изоляцию.
Не то меряли.Нужно было мерять сеть (10 гигабит, сравнить загрузку процессора в виртуалке и на голом железе при работе на полной скорости), оверхед на вызовы ядра (очень много мелких операций ввода вывода и прочих подобных) и латентность. С последней на виртуалках вообще все печально.
А в контейнерах это все выполняется как на голом железе.
Плюс возможность без напряга запустить десяток или два контейнеров под разные задачи, когда будет изоляция, но производительность не отличается от запуска на голом железе. Изоляция с практически нулевым оверхедом. Попробуйте на домашнем десктопе о 8 гигах запустить 10 виртуалок хоть с чем и оцените, как вам живется.
Плюс возможность легко на лету менять выделяемые ресурсы (процесоры, диск, память и тд), в виртуалках это требует значительно больших усилий и далеко не всегда получается сделать без перезапуска.
Ну, мерял то, что было интересно. Я, честно говоря, живого сервака с сетью 10 Gb и не видел и не особенно представляю, что оно должно делать, чтобы такой канал загрузить. Латентность в i/o - верю, но не помню, когда это играло роль. Большой i/o - это всегда БД, а она кучами мелких вызовов особо не страдает, собирает их в пакеты.На домашней машине десяток изолированных процессов? Тяжело, наверное, но зачем? То же самое - насчет легкости смены ресурсов у процесса - не бывает такого практически в продакшне. Я не спорю, всё это с контенерами проще, я просто применения всему этому не вижу.
Если что - я знаю, что почти для любой технологии найдётся контекст, в котором она будет уместна. Я просто хайп вокруг докера сотоварищи понять не могу - LXC сто лет как тут, OpenVZ/Virtuozzo - тем более, и за пределами пародий на VDS не особо применялись. Всё это для меня выглядит как очередная мода.
> Всё это для меня выглядит как очередная мода.Jail FreeBSD были модны, пока не появились системы виртуализации от VMware. Как только появились KVM, OpenVZ/Virtuozzo и LXC в Linux, сразу ринулись "осваивать новые предметные знания", забыв о ESXi. Ну, и вскорости Docker вылупился со своим пониманием контейнеров. На SystemD похожая ситуация. :))
О, вот и бедный обиженный забытый фришник подтянулся. Как же можно - Jail не упомянули! Чувак, речь о том, что массовые контейнеры - это мода. Неважно, в каком обличьи и где крутятся. К примеру, никто сейчас в здравом уме VDS под OpenVZ не берёт - нормальную виртуализацию подавай. И джайлы твои - из той же серии. Фича для редкого применения.Впрочем, как я всегда не устаю напоминать - BSD - это пятая колонна свободного софта, так что смерти ему скорейшей вне зависимости от наличия в нём каких-либо технологий. Нечего в тюрьме делать, даже если там вкусно кормят.
> К примеру, никто сейчас в здравом уме VDS под OpenVZ не берёт - нормальную виртуализацию подавай.Каков размер вышей выборки? Один человек? Или меньше?
Ты забыл еще про Solaris Zones упомянуть для комплекта.
Так ведь SmartOS же есть, нафига новая смартось на линухе? А BSD пускай живет, там игрушки теплее и ламповее.
> О, вот и бедный обиженный забытый фришник подтянулся. Как же можно -
> Jail не упомянули! Чувак, речь о том, что массовые контейнеры -
> это мода. Неважно, в каком обличьи и где крутятся. К примеру,
> никто сейчас в здравом уме VDS под OpenVZ не берёт -
> нормальную виртуализацию подавай. И джайлы твои - из той же серии.
> Фича для редкого применения.Когда-то на Jail'ах хостились тысячи сайтов. На заре пузыря доткомов. И вот, через десять лет опять надувают пузырь "контейнерной виртуализации" (как звучит, а?!). Только на Linux. ;)
Я вот смотрю на весь этот цирк с конями и контейнерами, и меня не покидает чувство дежавю. Когда-то я это уже видел, но не в такой массовой истерии, как сейчас.
А, я понял! За время моих наблюдений народилось и выросло новое поколение, которое этого ещё не видело. А значит из сарая достали "новые-старые" грабли, чтобы по ним ходить. Или лучше так: сын нашёл блестящий новенький молоток отца, завёрнутый в тряпочку, и теперь всё вокруг для отпрыска кажется гвоздями.
> изыни, но ты клинический ИДИОТ. оверхед полноценной виртуалке на ПОРЯДОК выше конйтенера.нет, идиот тут именно ты. собственно, ты это очень убедительно продемонстрировал непониманием значения словосочетания «на порядок».
не понятно только, зачем ты пытаешься лезь в технические дискуссии со своей пустой черепной коробкой.
Что происходит? Клоуна подменили? Он же должен глупости нести, а вместо этого говорит здраво и поправляет глупости других.Осталось добавить, что между контейнерами и полноценной виртуализацией существует еще паравиртуализация.
Ну, на практике железная и пара вперемешку идут - во всяком случае, так было в Xen, с которым я дело имел. То есть где может - оно железно обрабатывает, где не может - помогаем, подсовывая драйверы, а где остаётся - идёт старая мерзкая подмена кода и прочая тормозная чертовщина.
> Аппаратная виртуализация, которую ты понимаешь, нужна чтобы запустить ПО не предназначенной для твоей ОС или для архитектуры твоего ПК.Не совсем корректно.
Во-первых, есть ряд аспектов, по которым виртуалки уделывают контейнеры на их же поле. Заморозка (как там criu поживает?), горячая миграция, и т.д. Особенно стоит отметить работу с файловой системой - какое-то вшивое приложение из контейнера может полностью положить все соседние по хосту контейнеры, просто очень часто дергая журнал корневой ФС (которые обычно лежат у всех контейнеров на одном разделе хоста). Пока это решается только делением на уровне блочных устройств.
А что касается архитектуры - тут аппаратная виртуализация вряд ли поможет. Эмуляция нужна, однако.
Есть правило: не улучшать то, что не приносит денег. Если прога начнёт генерить бабло, её улучшат, ошибки исправят. А нет - и болт с ней.
Очередной форексный планктон к нам пожаловал.
Ну, в этом он прав - ресурсов всегда ограниченное количество, всё не улучшишь. Другое дело, что непонятно, к чему он привёл эту прописную истину. Если он имел в виду, что неуправляемый софт имеет право на жизнь - то он гонит, потому что такое обычно и функционировать толком не может, на поддержке разоришься.
Первую часть понял верно - г--внокод живее всех живых. Со второй налажал - его НЕ НУЖНО поддерживать, от неприбыльного бизнеса/сервисов/функционала/.. избавляются.Фишка тут в том, что пока не запустишь не узнаешь а нужно ли оно кому-то вообще. И если нужно, то сколько он готов за это потратить.
Нет смысла тратить время и деньги, если проект себя не окупает. Куда больший эффект принесёт вложение времени (= денег) и сил в новый проект.
А когда запустил и он работает (может со скрипом и вылетами каждые 10 минут) - пусть работает и лучше не трогать.
Компании нужен сервис для АААА - 35 минут и он уже работает. Через неделю оказалось что не так уж он был и нужен (судя по доходам от него), но один-два клоуна им пользуются - пусть пользуются, а их жалобы на качество сервиса мы будем использовать в качестве туалетной бумаги.
Это ты вторую часть не понял. Система развёртывания и менеджмента - она, в общем-то, тривиальна (особенно если это не коробки, а сервис - окружение можно задать довольно жестко), и если уж её сделали невменяемо - шансы, что остальное будет приемлемо работать - близки к нулю. Такие штуки быстро скатываются в состояние "не дуй на него, а то упадёт" - и потом таки падают в самый неподходящий момент.И, кстати, обычно оказывается средний случай - оно генерит бабло не то чтобы феноменально и приводить код в чувство никто не готов, но убирать - тоже. И сидим, ждём, когда оно как следует рванёт, а потом разбираемся с недовольными клиентами, извиняемся и убалтываем их подождать, пока девы с админами чинят очередную чертовщину. Или - ещё лучше - эта хрень тормозит внедрение новых фич. По которым, понятно, тоже никто прибыль не гарантировал, так что они - не аргумент, чтобы что-то менять.
Поэтому с моей точки зрения вменяемая (в том числе - автоматизируемая) система установки и настройки - это показатель нижней планки качества, с которой продукт достоин вообще существовать.
Тебя ждет много сюрпризов с таким мировоззрением.
Ну что ж, подождём лет пять и на горизонте появится новая тенденция и все будут стараться делать новые фреймворки, оси и языки в рамках той новой тенденции.Мода дело такое. Странно то, что ещё не все поняли что это лишь мода. Наверное потому, что сложно поверить в то, что технологии также как и внешний вид могут быть модными, а могут и не быть.
А потом как всегда, пара ботанов захардкодят какую-то фигню и она всё завоюет просто потому, что проста, понятна и эффективна. Бедные модники, им никогда так не смочь.
> А потом как всегда, пара ботанов захардкодят какую-то фигню и она всё
> завоюет просто потому, что проста, понятна и эффективна. Бедные модники, им
> никогда так не смочь.Какой толстый намек на Поттеринга и Сайверса :)
GTA 5 будет летать?
А вот кто мне объяснит, зачем оно? Если мне нужна баребонная виртуализация - я воткну полноценный гипервизор, если контейнеры - возьму LXC или OpenVZ, если изолировать приложение - запихну его в cgroup+chroot. А это зачем?
Я так понял, чтобы унифицированно управлять всем в облаке, но мне кажется, что автор таки загнался
> А вот кто мне объяснит, зачем оно?Чтобы уменьшить количество лишних сущностей, по сравнению с LXC поверх полноценного Linux.
>> А вот кто мне объяснит, зачем оно?
> Чтобы уменьшить количество лишних сущностей, по сравнению с LXC поверх полноценного Linux.А что там за сущности такие? Страшные?
К примеру, на FreeBSD, чтобы запустить jail, нужно всего три вещи:
1) Выделенный и заранее настроенный образ операционной системы (без ядра), один или несколько;
2) Отредактированный /etc/jail.conf на машине-хосте;
3) Две строчки на автозапуск клеток в /etc/rc.conf машины-хоста (jail_enable="YES" и jail_list="<список клеток>").
> А что там за сущности такие? Страшные?Практически полноценные системы и хостах, и у гостей. Что нафиг никому не упало.
Нужен только минимальный набор компонентов.
