После 11 месяцев разработки представлен (https://mirage.io/blog/announcing-mirage-25-release) релиз облачной операционной системы MirageOS 2.5 (http://mirage.io/), которая обеспечивает возможность запуска поверх гипервизора приложений, написанных на языке OCaml. MirageOS позволяет создавать операционные системы одного приложения, содержащие только компоненты, необходимые для запуска одной программы, без необходимости использования традиционных операционных систем с универсальным ядром, утилитами и набором библиотек. В разработке MirageOS принимают участие исследователи из Кембриджского университета, компании Citrix, проектов Xen, FreeBSD, Galois и OCamlPro.<center><img src="http://www.opennet.me/opennews/pics_base/0_1386599694.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;" title="" border="0"></center>
Разработка программ производится в традиционных ОС, после чего при помощи MirageOS программа компилируется в самодостаточное специализированное ядро (концепция unikernel (http://queue.acm.org/detail.cfm?id=2566628)), которое может запускаться непосредственно поверх гипервизора Xen или в форме процесса в POSIX-совместимом окружении. Сгенерированное окружение не содержит ничего лишнего и взаимодействует непосредственно с гипервизором без драйверов и системных прослоек, что позволяет добиться существенного снижения накладных расходов и повышения безопасности. Работа с MirageOS сводится к трём стадиям: подготовка конфигурации с определением используемых в окружении OPAM-пакетов (https://opam.ocaml.org/), сборка окружения и запуск и контроль за выполнением окружения (MirageOS сам создаст файлы конфигурации для Xen и запустит окружение).
Несмотря на то, что приложения и библиотеки формируются на высокоуровневом языке OCaml, итоговые окружения демонстрируют достаточно неплохую производительность и минимальный размер окружения (например, DNS-сервер занимает всего 200 Кб). Упрощается и сопровождение окружений, так как при необходимости обновления программы или изменения конфигурации, достаточно создать и запустить новое окружение. Поддерживается несколько десятков библиотек (https://github.com/mirage) на языке OCaml для выполнения сетевых операций (DNS, SSH, OpenFlow, HTTP, XMPP и т.п.), работы с хранилищами и обеспечения параллельной обработки данных.
Ключевым новшеством (https://mirage.io/releases) MirageOS 2.5 является полноценная реализация TLS-шифрования, интегрированная во все подсистемы MirageOS, в том числе в API для определения конфигурации, что позволяет разработчикам создавать и развёртывать безопасные unikernel. В качестве основы выступает проект OCaml-TLS (http://openmirage.org/blog/introducing-ocaml-tls), в рамках которого подготовлена высокопроизводительная и надёжная реализация протокола TLS, написанная на языке OCaml. В дополнение к OCaml-TLS подготовлена коллекция unix-утилит для работы с TLS, например, утилита tlstunnel позволяет быстро создавать рабочие конфигурации, используя tlstunnel как замену stunnel и stud.
URL: https://mirage.io/blog/announcing-mirage-25-release
Новость: http://www.opennet.me/opennews/art.shtml?num=42515
Некоторым чужие факапы видимо не в прок. Однажды фирма майкрософт уже пыталась сделать нечто наподобие - в azure изначально подразумевался только запуск приложений на дотнете поверх гипервизора.Реально идея оказалась полным отстoeм. Кастомерам часто надо было запускать "не только на дотнете" или какие-то кастомные настройки характерные для ОС. И вся эта сферическая буита "можно запускать только программы на 1 языке с его рантаймом" пошла лесом. Впрочем, гугл тоже этой хренью занимался уже много лет и как-то она и близко не стоит по популярности обычных хостингов и облаков позволяющих запускать "универсальные операционки".
Секрет в том что рулить гольным инстансом приложения без операционки - крайне неудобно. А как только надо что-то продвинутое - без general purpose операционки быстро наступает облом. В обычной ОС вы например периодику пропишете в systemd.timers или крон. Парой строк конфига. А при таком подходе - вы таки пойдете сами себе кодить аналог крона, о чем вы наверняка всю жизнь только и мечтали...
Смотрите на это не как на обычный сервер, а как на узкоспециализированное решение на очень мощном микроконтроллере. Естественно у такого подхода будут свои минусы, и на массовое решение это не годится. Но в определенных ситуациях может быть вполне востребовано.
> Смотрите на это не как на обычный сервер, а как на узкоспециализированное
> решение на очень мощном микроконтроллере....где еще надиктовали с ножом к горлу левый ЯП и довольно чреватые методы работы.
Итог? Шаг в сторону - и вместо штатных фич системы вы идете кодить все сами. Вместо того чтобы взять готовое решение, как белый человек. Вы жизнь мечтали накодить себе аналог крона и системного логгера на ocaml?! А может вы всю жизнь мечтали написать эрзац-трассир? Тогда это ваш выбор! Правда, потом оказывается что дебаггинг там - геморнее чем на микроконтроллерах. А ловить редкие баги - опупеешь. При том всякая вебня и прочее - БОЛЬШОЕ, в отличие от МК. Если для микроконтроллера с фирварью на пять кило - баг стреляющий раз в неделю таки редкость, то для облачной фигни с кодом на 8М - это совершенно обычное дело. А т.к. стандартных фич системы ТАМ НЕТ, нормального дебага тоже нет, логгинга нет, крона нет, вообще нифуя нет. И програмеры потом разрываются между терабайтом ультравербозных логов флудящих все вокруг и тормозящих продакшн ломом в вентилятор, чтобы понять что там вообще происходит и полным непониманием того что там творится, на выбор. О том что все это пришлось месяц ударно кодить я вообще молчу, ведь приходится их спичек и желудей экстренно делать ну хоть какое-то подобие недо-логгинга и недо-трассира, попутно сгородив эрзац-крон т.к. терабайты ультравербозных логов которые почти трэйсы - мигом сжирают все место. Про какое-нибудь подобие дебаггера (ну, стандартных то дебагеров в левой недосистеме нет) - речь не идет: обычно программеры таки сцут начинать такое махровое наполеонство. Поэтому они месяцами сношаются с поимкой неочевидных багов. Тем более что на рабочей машине такое если и можно развернуть то оно ортогонально обычным практикам и повседневным сценариям. И поэтому для програмера сие похоже на визит к инопланетянам. Где что ни нажмешь - результат поражает неожиданностью и полным отличием от того к чему програмер привык.
> Естественно у такого подхода будут свои минусы,
Главный из которых - то что много гемора совершенно на ровном месте. Если в такой фигне случается БАГ (а при сложности типичной для вебни, облаков, серверов XMPP, HTTP и прочее - баги гарантированы) - это все, пипец. Нормального тулинга для поимки багов нету. Сливай вода, туши фонарь. И закладывай пару месяцев на кодинг эрзац логгера, эрзац-трассира и прочей фигни, которая в нормальных системах готовая лежит.
> Но в определенных ситуациях может быть вполне востребовано.
Ну я просто видел как такое пытались использовать. Это был трэш, угар и содомия. Люди убивали по полгода на то что пыхапэшник средней руки сделает (и отладит на своем ноуте) за месяц. При том оно все-равно адово глюкало в продакшне а процесс борьбы с багами больше напоминал влезание в ластах и противогазе на намыленный фонарный столб. В таком окружении за каждый прибитый баг надо олимпийскую медаль давать.
Ну, технически отладка - это дело решаемое, тулзы с библиотеками (в том числе и отладка-логирование) один раз пишутся и отлаживаются, в конце концов. Но плюшек я в этом не вижу, хоть убей. Во-первых, таки да - экзотический язык с ограниченным набором библиотек. Во-вторых - плевать, сколько занимает код. Потому что данные, которые он будет лопатить, занимают в памяти минимум на пару порядков больше обычно. В-третьих - ну да, как только захочется странного - это странное обойдётся дорого. В-четвёртых - они там всерьёз, скажем, FS сами реализовывать будут? Что за чушь насчёт "отсутствия ядра и драйверов" - очевидно же, что функциональность с неба не свалится, и релизовывать её заново - это бред сивой кобылы
> Ну, технически отладка - это дело решаемое, тулзы с библиотекамиЗнаешь, теоретически - много чего решаемо. А практически - это кто-то должен сделать.
Можно написать отладчик? Да. Только посмотри сколько ресурсов на это в нормальном виде реально надо. Вон в LLVM народа поболее чем у некоторых, а нормальный отладчик за несколько лет так и не сделали. При том такая фигня при отсутствии нормальной оси - вообще с АБСОЛЮТНО ВСЕМ. Сферическое приложение в вакууме - это круто, концептуально и ... не от мира сего.
Так, очевидное: стоит сервачок. Он в основном HTTP, но еще он синкает файлы по rsync. Несколько гигов потенциально. И задержка не более 5 минут. Ну так надо. В этом конкретном случае. Любой человек в здравом уме в general purpose оси просто пропишет рсинк в крон. Дешево и сердито, занимает 5 минут времени. А потом просто работает. А на такой конструкции - ОПАНЬКИ!
> (в том числе и отладка-логирование) один раз пишутся и отлаживаются, в конце концов.
Вот только это кто-то должен сделать. А чтобы это было в нормальном виде, на это надо вбухать уйму ресурсов. В general purpose осях - все это делали исторически, за многие годы, между делом, под нужды разработчиков и юзерей. А сейчас мы можем прийти и за 5 минут опереться на плечи гигантов. Которые до нас написали cron, rsync и что там еще. И вместо борьбы с искусственными сложностями - заняться решением своей задачи. А не написанием себе логгера с замашкми трассира, подрыва писать свою реализацию протокола rsync на ocaml и что там еще.
Я уж не говорю о том что схватиться за единственный малопопулярный ЯП, принципиально обув себя на все остальные ЯП и наработки под них - это фееричный прострел пяток и залет на туеву хучу работы на ровном месте. Там где можно было бы сто раз взять готовые либы, программы и скрипты - придется пыхтеть самому.
> сколько занимает код. Потому что данные, которые он будет лопатить, занимают
> в памяти минимум на пару порядков больше обычно.Это конечно варьируется. Но в целом такие конструкции оказались совершенно не от мира сего.
> да, как только захочется странного - это странное обойдётся дорого.
Более того, в 95% случаев придется делать козью морду и с позором объявить что задача "не решается" [вами, за разумное время и деньги, с этой технологией]. Под гомерический гогот скриптокидозников, показывающих внезапно обломившемуся им клиенту как это сделать за 5 минут и даже без программирования.
> В-четвёртых - они там всерьёз, скажем, FS сами реализовывать будут?
В таких вещах ФС как таковой может и не быть. Будет какое-нить апи к базе, например. Мелкомякоть как-то так и хотели. Реально оказался адов гемор на ровном месте, разумеется, и все труба шатали такую мегаконцептуальщину.
> Что за чушь насчёт "отсутствия ядра и драйверов"
Имеется в виду что в контейнере с ОС-паразитом нет большинства драйверов и ядро может быть урезанное, т.е. чисто прослойка для работы с гипервизором.
Но реально кучу лишних дров можно оборвать и у general purpose, если это так принципиально. Это и под реальное железо то делают, там где место жмет. Ну вон опенвртшники в 4 мега упаковываются, при том половина из этого - как раз программы рисующие вебморду, ну и всякая логика вокруг типа фаера, роутинга и обвязки всего этого. Но реально плюс-минус пара мегабайтов на обычной VM в более-менее типовых условиях - никого не парит. И хардкорно плясать с бубном чтобы откусить от виртуалки несколько мегов - в целом довольно странное начинание. Ну то-есть пытаются делать поменьше и полегче, но лишь до тех пор пока это не начинает требовать много времени и факапить то для чего виртуалки поставили.
Как бы для микроконтроллеров используются чуток другие принципы разработки. А на arduino IDE никто софт для серверов не пишет.
Возможно, ребята просто хотят писать приложения для банкоматов на своём любимом языке, для чего и сделали инструмент. Так что никакого отношения к изначальной концепции Azure это не имеет. На взрывную популярность продукт не претендует, что ясно сразу: OCaml -- язык во многом довольно интересный (например, как попытка привить функциональному языку элементы императивности, изначально лишённая "пуризма" и позволяющая писать достаточно высокопроизводительный код), но всё-таки круг его любителей достаточно узок и всегда таким останется.
Я понимаю что хочется умолчать, но на картинке справа не видно где именно находится это монолитное ядро (unikernel). Правильно ли я понимаю что applcation на второй картинке - это прога которая статически слинкована с монолитным ядром? Если так, то это конечно здетц..
unikernel не является классическим ядром (с драйверами и процессами). Почитайте, например, http://queue.acm.org/detail.cfm?id=2566628
Среди этого множества букв не видно внятных ответов. Если подумать, то все равно оказывается что функционал ядра прилип либо как статика к приложению, либо он в рантайме приложения. Я понимаю что там сильно неполноценное ядро (там очень сильная урезка), но раз заявлено "POSIX-совместимое окружение", то там есть..fork, exec, waitpid и т.д. Если там есть все это, то..в application это что-то вроде init-процесса (который у нас с pid 0). А если этого нет..то это не POSIX-совместимое. Подскажете как все это работает и зачем такие проекты нужны (только не пилить бабло) ?
> Подскажете как все это работает и зачем такие проекты нужны (только не пилить бабло) ?"Сгенерированное окружение не содержит ничего лишнего и взаимодействует непосредственно с гипервизором без драйверов и системных прослоек, что позволяет добиться существенного снижения накладных расходов и повышения безопасности."
"например, DNS-сервер занимает всего 200 Кб"
Сколько DNS-сервер будет весить вмести с os? Сколько там будет багов/уязвимость? Сколько там будет бесполезных прослоек?
А как сочетается "POSIX-совместимое окружение" и "ничего лишнего"?
"программа компилируется в самодостаточное специализированное ядро (концепция unikernel ), которое может запускаться непосредственно поверх гипервизора Xen" - вот и будет - "ничего лишнего"."или в форме процесса в POSIX-совместимом окружении" - для тех случаев когда можно пожертвовать минимализмом для упрощения портирования.
Ну ты сам сравни эти 2 картинки "влоб". Я вот не пойму кто берет обработку "processes" и "threads", а вы? А если у меня приложение с POSIX-theads ? А если еще и preforked ?
На картинках не изображен unikernel, так как он фактически является частью приложения, а не самодостаточным ядром.
Ну и в чём преимущество тогда?
контейнерные апликухи двигают со своей средой.
представь, если бы 90% поставщиков софта - начали внезапно, поставлять его в виде vmdk-конейнеров для VMWare Player/Workstation(или VirtualBox/PC или QEMU, не суть).
чистая среда для софта, без оверхэдов, без "инсталляций", без факапов, с нормальным менеджментом ресурсов и бэкапами, файловером даже на недружественных к оному host os.то есть это не попытка скрестить qubes и микроядро как некоторые подумали, это просто вывод апликух(и серверных приложений тоже) на уровень контейнерной платформы.
до этого часть поставщиков и комьюити - релизили опционально контейнерами трех форматов ряд веще(в основном сетевую хрентоень), а они хотят это "стандартизировать и упростить", а скорее - подмять под себя.
Танунафиг, это означает, что такой софт тащит с собой статически линкованные бибилиотеки со всеми проблемами обновления на которые вендор, как обычно, забьёт. Без инсталляций - тоже не выйдет, там много чего нужного делается - от инициализации данных до миграции со старых версий. Нормальный менеджмент ресурсов? Чем он будет отличаться от обычного выделения ресурсов виртуалке? Не, если это сравнивать с колхозным подходом "в одной ос на сервере куча задач" - то да, но нормальные люди в продакшне держат под каждую задачу свою виртуалку. Контейнеры - сами по себе довольно сомнительная идея, когда можно иметь полноценные VM с достаточно небольшим оверхедом, но контейнер с отказом от существующих и распространённых средств менеджмента, на окамле - это бред.Ну а насчёт "подмять под себя" с требованием писать на окамле - забавно, да.
Если так - то еще хуже. Ведь тогда слой API реализующих POSIX-совместимость находятся в..приложении?? о_0 Может все-таки где-нибудь от Language Runtime и глубже ? Так как там дела обстоят с fork и pthreads? - Мне очень интересно.
Сходите к ним на сайт почитайте. Но предлагаемые приложения event-based без выделения потоков.
> Сколько DNS-сервер будет весить вмести с os? Сколько там будет багов/уязвимость? Сколько
> там будет бесполезных прослоек?Зато в коде на 200 кило почти наверняка есть баги. Потому что это достаточно много кода. И в совершенно лысой системе без какого либо тулинга - ну удачи вам понять где в вашем DNS сервере вообще порылся баг...
Вот она многозадачная DOS. Дождались!
Все идет к винде вот и snappy тоже...
Поддержка других гипервизоров сделала бы эту штуку интересней
