если бы докер подстраивался под 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 недостаточно полный функционал

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

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

Да

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

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

короче этот ваш рокет это даунлоад менеджер. так получается ?

Ну и обёртка же

Я вот не знаю, как руками правильно запустить процесс так, чтобы он и в отдельной сети был, и изолирован, и что там ещё

А так -- rkt run и работает

Кстати, @lorddaedra, а как принято доставлять приложения в случае с rkt при использовании непрерывного развёртывания?

С докером я запускал команду "скачай из локального реестра со свежим тегом" и оно работало

Я вот не знаю, как руками правильно запустить процесс так, чтобы он и в отдельной сети был, и изолирован, и что там ещё

nsenter

Кстати, @lorddaedra, а как принято доставлять приложения в случае с rkt при использовании непрерывного развёртывания?

про аналог докерхаба спрашиваешь?

https://quay.io/

но в отличие от докерхаба тут нет приватных бесплатных репозиториев

поэтому можно и свою сделать с помощью того же nginx

нененен

у меня в качестве приватного реестра стоял gitlab, раз уж он всё равно был

Вопрос в том, как доставлять изменения с rkt

Насколько я понял, основной способ -- подписанные targz

То есть задача сводится либо к выкладке их на локальный сервер, либо к пропихиванию силами CI на сервера?

Криво написал: 1) положить на шару и сказать "тащите оттуда файлы" или 2) положить файлы напрямую на сервера приложений

короче этот ваш рокет это даунлоад менеджер. так получается ?

ну, под капотом для запуска контейнеров он делает так: host OS └─ rkt └─ systemd-nspawn └─ systemd └─ chroot └─ user-app1

В случае того же докера второй вариант с экспортом образа в файлик и пропихиванием его на сервера не слишком распространён

ну, под капотом для запуска контейнеров он делает так: host OS └─ rkt └─ systemd-nspawn └─ systemd └─ chroot └─ user-app1

А есть такая же визуализация, но с lkvm stage1?

nsenter

забавная штука этот nsenter

А есть такая же визуализация, но с lkvm stage1?

да host OS └─ rkt └─ lkvm └─ kernel └─ systemd └─ chroot └─ user-app1

А как делается такая обёртка для текста в телеграме?

` три раза до и после

Телеграм умеет markdown, или это отдельная функция?

думаю, что не умеет (но кастомизированные клиенты могут уметь, если процессят это на клиенте)

про процесс сборки и CI, тут всё по аналогии с докером

сначала мы билдим образ , потом отправляем его в хранилище, потом оно расползается оттуда на серверы

Надеялся, что есть какая-то особая магия специально для rkt

билдить не обязательно самим

Хотя штатная работа с URL вполне подходит под это определение, я думаю

quay умеет билдить если что-то нужно

то есть CI может отправлять запрос за билдинг в quay, а потом качать и тестировать оттуда

ну, конечно, можно и самим билдить

можно с нуля через https://github.com/appc/acbuild

можно конвертировать Docker-образы

к слову, я разобрался с перенаправления

вот так это делается —port=80-tcp:8888

разница с докером в том, что тут в первом случае указывается не порт, а название

при конвертации оно берёт тот порт, который указан там в докерфайле (в родительском, возможно) и для наименования добавляет к этому порту -tcp

можно попробовать запустить без этого всего, потом сделать rkt cat-manifest 3dea550e и там посмотреть, как называются порты

а вот если в манифесте их бы не было - пришлось бы патчить его

пилите шура пилите. гдавное не малый бизнес ито хорошо.

я это делаю ради фана, поэтому "считалку денег" сейчас выключил

но если прагматично на всё это смотреть - я верю в светлое будущее Rkt, но он ещё сыроват, чтобы рекомендовать его всем и каждому

кстати, в рассуждениях выше про файловую систему я немного ошибся

On modern Linux systems, rkt now uses overlayfs by default when running application containers. This provides immense benefits to performance and efficiency: start times for large containers will be much faster, and multiple pods using the same images will consume less disk space and can share page cache entries. If overlayfs is not supported on the host operating system, rkt gracefully degrades back to the previous behaviour of extracting each image at runtime - this behaviour can also be triggered with the new —no-overlay flag to rkt run.