, это как вообще?
Я еще хотел спросить, как реализовать планирование, например, сервис А запускается после сервиса B, до запуска сервиса C, но только если стартанул сервис Z, но пожалуй пусть это будет риторический вопрос.
В свое время только один инит скрипт, например для zookeeper, был строк под 200. Писало его человек 10 в общей сложности. Сколько времени убили, уйму просто. А могли бы зоокипер пилить вместо этого. Сейчас файл занимает пять строк и понятен любому человеку, а не только аутисту.
Так у вас там в первых двух строках прекрасное и можно дальше уже не читать.
Всё в одном файле — при обновлении приложений практически невозможно автоматически обновить код инициализации этого приложения. Например, когда обновляется ALSA, то пакет может просто заменить файлы /etc/init.d/alsasound, /etc/conf.d/alsasound, /etc/modules.d/alsa. А в моём случае админу нужно будет ручками править /etc/runit/1.
Нет поддержки всего на свете
Ну и сколько вы эти шашечки рисовали? А если надо будет поставить вдруг pulseaudio? Шашечки хорошо, но когда ехать-то?
Если я захочу заняться разработкой под андроид, например?
Что мне работодателю сказать, извини, дружок, через три месяца начнем, мне тут надо все запустить сначала?
Вы сейчас спрашиваете, какое количество разработчиков занимается профилированием и насколько часто они это делают. Я правильно понял? Этим занимаются все нормальные разработчики и всегда. По полгода пилят софт, чтобы полсекунды выйграть.
Для embedded, иногда даже для серверов еще можно оправдать легковесные разного рода супервизоры и иниты.
А как десктоп системы запускать в данной парадигме?
Писать простыни шелл скриптов — так уже проходили это, отказались. Эволюционировали дальше, опять отказались, родили системд.
Вы предлагаете вернуться к простыням обратно? А зачем? Чтобы безопаснее было?
Fedora, десктоп, 30% запущенных сервисов задетачены, мне для них что надо, баш скриптами врапперы писать? А зачем?
Проще. Но есть нюансы.
Как предлагаете делать systemd-analyze critical-chain, например?
Если я, например в userspace что-то разрабатываю, как мне сделать такое? Startup finished in 1.297s (kernel) + 2.825s (initrd) + 8.695s (userspace) = 12.818s
Скорость чего? Файловой системы эфемерного докера или файловой системы персистентного хранилища? Вы вообще понимаете, как устроен и как работает докер?
Все зависит от настроек. Может вы там лупбек тестили на лвм. Тогда будет медленнее. Overlay2 будет даже быстрее.
А зачем файловую систему вообще тестить в докере? Для этого есть персистентные хранилища, контейнер сам по себе эфемерная сущность.
Да с чего не про скорость, я выше приводил цитату, где уже все померяли и замерили еще в 2012 году.
«An Updated Performance Comparison of Virtual Machines and Linux Containers» by Felter et al. that provides a comparison between bare metal, KVM, and Docker containers. The general result is that Docker is nearly identical to Native performance and faster than KVM in every category."
Ну, вы уверены, что вы там все правильно настроили и понимаете, что вы там тестили?
Я вот не уверен. В этих тестах, например, помешаны в кучу кони и люди. Вот Оpenvz, например, на каком ядре работает сейчас? 2.6.32? Даже со всеми патчами — это по-прежнему 2.6.32, с того времени сколько сотен тысяч строк в ядро накоммитили? Докер и lxc — это тоже немного разные вещи. Гипервизоры сюда еще как-то попали.
Да, выразился неверно. Это виртуализация, на уровне операционной системы, в рамках одной ОС. Лишние проверки на пути — проверки чего? Вместо одного экземпляра пространства пользователя, работает несколько, акей. Как это влияет на количество каких-то проверок?
Да, только докер — это не виртуализация. Диски тут вообще никак не аффектятся.
Медленнее в докере только сеть.
«An Updated Performance Comparison of Virtual Machines and Linux Containers» by Felter et al. that provides a comparison between bare metal, KVM, and Docker containers. The general result is that Docker is nearly identical to Native performance and faster than KVM in every category.
Докер — это система изоляции, никакого оверхеда там почти нет. Тем более не может быть никаких 20%, 57 тысяч человек в слак чате кубернетеса подтвердят.
То есть при запихивании абстрактного астериска в докер контейнер, количество обслуженных клиентов падает на 20 процентов? Это очень большая величина, почему так? Откуда 20% появилось? Как считали? Там просто неоткуда взяться такой цифре.
Ничего с базой неясно. Ютуб гоняет и ничо, жужжит вроде.
Ничего особого докер никуда не вносит, использует cgroups и немного сетевой магии. Кубернетес уже везде. Оверхед 5%, плюсов больше. Никакой еще один слой абстракции никуда не вносится, все механизмы давно в ядре. Слой промежуточных сервисов может влиять на всю систему, согласен. А может и не влиять, тут уж как настроишь.
Как вы меряете производительность телефонии? Каждый пятый звонок обрабатывается неправильно и виноват прям докер? Да ладно.
С базой тоже непонятно, а без докера таких паттернов нет?
Есть же разные atomic OS, есть modular Fedora. Есть snap, flatpack, appimage.
Есть докер и k8s, наконец, где вообще не так важно, какая там у тебя операционная система под капотом и где пакеты вообще не особо нужны.
Ниша у «полностью программируемой OS» наверняка есть, но тратить месяц на настройку, чтобы потом держать 100 человек на поддержке — очень специфичный use case.
Ехать же надо, а не шашечки. Если для каждой поездки надо месяц готовить машину, в большинстве случаев такое не взлетит.
With Intra-Kernel Isolation, the namespace would still be the security boundary. However, instead of all sharing the main Kubernetes system services, each namespace would have it’s own “nested” Kubernetes system services. Meaning the api-server, kube-proxy, etc would all be running individually in a pod in that namespace.
Их не устраивает, что неймспейсы в кластере шарят один контролплейн. При компрометации контролплейна весь кластер будет скомпрометирован. Чтобы не перепиливать cgroups и namespaces предлагается добавить еще один уровень изоляции — собственно вмку с katacontainers и подложить туда каждому по своему куску контролплейна.
Также есть момент, что из-за нерешенной проблемы «hard-tenancy», все предпочитают делать не один большой кластер, а кучу мелких, генерируя кучу контролплейнов, которые полезной нагрузки не несут и жрут зря ресурсы.
Поэтому (неожиданно) надо всем выдать по своему маленькому кубернетесу в вмке и не париться про «hard-tenancy», что они смело называют «будущее».
Я в итоге ничего не понял сам и пойду уже праздновать.
Я еще хотел спросить, как реализовать планирование, например, сервис А запускается после сервиса B, до запуска сервиса C, но только если стартанул сервис Z, но пожалуй пусть это будет риторический вопрос.
В свое время только один инит скрипт, например для zookeeper, был строк под 200. Писало его человек 10 в общей сложности. Сколько времени убили, уйму просто. А могли бы зоокипер пилить вместо этого. Сейчас файл занимает пять строк и понятен любому человеку, а не только аутисту.
Ну и сколько вы эти шашечки рисовали? А если надо будет поставить вдруг pulseaudio? Шашечки хорошо, но когда ехать-то?
Если я захочу заняться разработкой под андроид, например?
Что мне работодателю сказать, извини, дружок, через три месяца начнем, мне тут надо все запустить сначала?
Вы сейчас спрашиваете, какое количество разработчиков занимается профилированием и насколько часто они это делают. Я правильно понял? Этим занимаются все нормальные разработчики и всегда. По полгода пилят софт, чтобы полсекунды выйграть.
А как десктоп системы запускать в данной парадигме?
Писать простыни шелл скриптов — так уже проходили это, отказались. Эволюционировали дальше, опять отказались, родили системд.
Вы предлагаете вернуться к простыням обратно? А зачем? Чтобы безопаснее было?
Fedora, десктоп, 30% запущенных сервисов задетачены, мне для них что надо, баш скриптами врапперы писать? А зачем?
Как предлагаете делать systemd-analyze critical-chain, например?
Если я, например в userspace что-то разрабатываю, как мне сделать такое? Startup finished in 1.297s (kernel) + 2.825s (initrd) + 8.695s (userspace) = 12.818s
А зачем файловую систему вообще тестить в докере? Для этого есть персистентные хранилища, контейнер сам по себе эфемерная сущность.
«An Updated Performance Comparison of Virtual Machines and Linux Containers» by Felter et al. that provides a comparison between bare metal, KVM, and Docker containers. The general result is that Docker is nearly identical to Native performance and faster than KVM in every category."
Я вот не уверен. В этих тестах, например, помешаны в кучу кони и люди. Вот Оpenvz, например, на каком ядре работает сейчас? 2.6.32? Даже со всеми патчами — это по-прежнему 2.6.32, с того времени сколько сотен тысяч строк в ядро накоммитили? Докер и lxc — это тоже немного разные вещи. Гипервизоры сюда еще как-то попали.
Медленнее в докере только сеть.
«An Updated Performance Comparison of Virtual Machines and Linux Containers» by Felter et al. that provides a comparison between bare metal, KVM, and Docker containers. The general result is that Docker is nearly identical to Native performance and faster than KVM in every category.
Докер — это система изоляции, никакого оверхеда там почти нет. Тем более не может быть никаких 20%, 57 тысяч человек в слак чате кубернетеса подтвердят.
Ничего с базой неясно. Ютуб гоняет и ничо, жужжит вроде.
Ничего особого докер никуда не вносит, использует cgroups и немного сетевой магии. Кубернетес уже везде. Оверхед 5%, плюсов больше. Никакой еще один слой абстракции никуда не вносится, все механизмы давно в ядре. Слой промежуточных сервисов может влиять на всю систему, согласен. А может и не влиять, тут уж как настроишь.
С базой тоже непонятно, а без докера таких паттернов нет?
Есть докер и k8s, наконец, где вообще не так важно, какая там у тебя операционная система под капотом и где пакеты вообще не особо нужны.
Ниша у «полностью программируемой OS» наверняка есть, но тратить месяц на настройку, чтобы потом держать 100 человек на поддержке — очень специфичный use case.
Ехать же надо, а не шашечки. Если для каждой поездки надо месяц готовить машину, в большинстве случаев такое не взлетит.
Их не устраивает, что неймспейсы в кластере шарят один контролплейн. При компрометации контролплейна весь кластер будет скомпрометирован. Чтобы не перепиливать cgroups и namespaces предлагается добавить еще один уровень изоляции — собственно вмку с katacontainers и подложить туда каждому по своему куску контролплейна.
Также есть момент, что из-за нерешенной проблемы «hard-tenancy», все предпочитают делать не один большой кластер, а кучу мелких, генерируя кучу контролплейнов, которые полезной нагрузки не несут и жрут зря ресурсы.
Поэтому (неожиданно) надо всем выдать по своему маленькому кубернетесу в вмке и не париться про «hard-tenancy», что они смело называют «будущее».
Я в итоге ничего не понял сам и пойду уже праздновать.