идеальный вариант - монолитное ядро, без возможности загрузить туда всякие стрёмные модули

и никаких AUFS и прочих таких штук

Unikernel?

Тоже часть докера

мне тут идеологически не нравится, что докер что-то там придумывает, стартапит, хотя он мне нужен лишь для запуска образов

есть стандартное решение - ext4

Это не докер придумал

почему я не могу просто ext4 использовать?

без всяких вот этих плагинов

Но ведь CoreOS тоже что-то придумали и настартапили

Нет ему не нравится именно докер

Не пугает Александра завязка на etcd

Он ее еще не нашёл

Rkt работает же без etcd?

Не пугает ркбут в любой момент

А щас тяжело найти что-то без etcd

Я вот kubernetes щупал

Rkt работает же без etcd?

Ага, только будет не удобнл

Как моноколесо.

А Fleet -- он же тоже etcdшный?

Да

Он поверх

если это облако - то etcd или аналоги нужны

а как иначе

и ребуты для обновлений - тоже нормально (ну, почему бы и нет?)

Там шина на нём. Коныигуратор на нем

ну да, там всё вокруг etcd

и ребуты для обновлений - тоже нормально (ну, почему бы и нет?)

Они сильнее вяжут

Чем докер

если бы докер подстраивался под systemd - особых претензий бы к нему не было)

А про файловый кнш Александр не думает

если бы докер подстраивался под systemd - особых претензий бы к нему не было)

Зачем тебе докер то?

мне нужны контейнеры, но так чтобы их было удобно билдить

nspawn же

И не рокет ни докер

И ext4

ещё мне нужны kvm

Если докер начнёт подстраиваться под systemd, то набигут те, кому не нравится, что он не подстраивается под s6 например

потому что не всему коду я доверяю

ну и вот Rkt я вижу как удобную систему чтобы примерно одинаково всем управлять

и виртуалками и контейнерами

к этому всё идёт

О, а эксплойтов на выход за пределы гипервизора не бывает?

а сам Rkt будет запускаться через systemd или fleet (который поверх systemd), если облако

а когда-нибудь я и до Kubernetes там возможно доберусь, но мне не сильно это нужно

О, а эксплойтов на выход за пределы гипервизора не бывает?

ну, у докера были эксплоиты, что ты просто делаешь docker pull из чужой репозитории, даже не запускаешь, а уже заразился

О чём и речь. Возможно, если есть недоверие к чужому коду, то изоляция программными средствами -- не слишком надёжный инструмент?

да, не самый надежный, но так дешевле, чем покупать отдельные серверы

просто соотносится стоимость проблем в случае взлома и стоимость серверов

в данном случае мне будет дешевле исправить проблему в случае взлома

Тогда как мириться с потерей производительности из-за kvm?

да там потеря не очень большая

но да, идельно всё не сделаешь

контейнеры, конечно, быстрее будут

но и kvm тоже не тормоз

там несколько процентов всего же

nspawn же

Кстати, у меня rkt требует пакет с nspawn для работы, так что фиг его знает

Rkt это как бы удобная обёртка для запуска контейнеров

вся эта виртуализация она давно уже изобретена и работает на другом уровне

Саша что не так с nspawn?

Чистый системд

И ядро

на этот вопрос я не знаю ответа, наверное, дело в том, что мало статей на эту тему

Так почитай же

Раз rkt использует nspawn, то с ним, видимо, всё ок

https://coreos.com/rkt/docs/latest/rkt-vs-other-projects.html#rkt-vs-systemd-nspawn

Nspawn это просто указание неймспейса

И всё

это всё крутится вокруг cgroups

я так понимаю

Ну то есть nspawn лучше даже

Они там ненастартапили

А сигруппы изолируют файлы?

By default rkt uses systemd-nspawn to configure the namespaces for an application container.

видимо, у systemd-nspawn недостаточно полный функционал

и поэтому потребовалось что-то большее, чтобы запускать сервисы

Качать он не умеет готовые контейнеры, вот что

Да

А так всё как ты любишь

Чрут + сгруппы + неймспейс