Трагедия systemd

Автор оригинала: Jonathan Corbet
  • Перевод
Согласно Википедии, трагедия — это «форма драмы, основанная на человеческих страданиях, которая вызывает в аудитории сопутствующий катарсис или удовольствие». Из этого определения почерпнул вдохновение Бенно Райс в своём выступлении на конференции 2019 linux.conf.au. Его доклад посвящён истории systemd, в которой немало страданий. А аудитория точно получила удовольствие, так что всё сходится. В целом, это сочувственный и тонкий взгляд на одну бурную главу в истории системы Linux.

Райса также вдохновила статья Ауринна Шоу о так называемой «культуре презрения». По словам Шоу, люди проявляют презрение (например, к разработчикам, которые используют другой язык программирования) в качестве социального знака, способа показать, что они принадлежат к правильной группе.

Безусловно, в этой истории есть такая культура: большие группы сообща проявляют общее презрения к systemd и к тем, кто использует эту систему. Отсюда вытекает концепция изменения или сопротивления. Да, знакомые вещи удобны. Но они не обязательно хороши, особенно если ничего не меняется уже много лет.

Истоки трагедии


По словам Райса, происхождение systemd связано с корнями самой системы Unix, которая была «счастливой случайностью» — реакцией на внешнюю сложность прежних систем. Unix был кардинально упрощён во всех отношениях, включая загрузку пользовательского пространства. Подсистема init заведовала всем «хозяйством», включая монтирование файловых систем и запуск демонов. Хотя это совершенно разные задачи, но их объединили в один процесс.

В те дни важных демонов было мало: cron, update (чья работа заключалась в том, чтобы иногда выписывать суперблоки файловой системы), и сам процесс init. К моменту выхода 4BSD у Unix и появился правильный демон getty, сетевые демоны вроде routed и telnetd, а также «супердемон» inetd. Именно здесь ситуация начала становиться интересной, но некоторое время всё это работало достаточно хорошо.

А потом случился Интернет. Хотя inetd нормально справлялся с небольшими объёмами трафика, но не мог создавать новый процесс на каждое входящее соединение. Тем временем веб-сайты обзавелись базами данных и другими системами с сохранением состояния между соединениями. Представление о демоне сместилось в сторону «сервиса», а это совсем другой зверь. Старый init мог только запустить сервис, но после этого становился практически бесполезен.

Частично проблема заключалась в объединении сервисов и конфигурации. Такие задачи, как монтирование файловых систем, относятся к последней разновидности; они обычно выполняются один раз во время загрузки, после чего забываются. Но такого подхода недостаточно для автоматизированного управления сервисами, которое требует постоянного внимания. Вот так на свет появились сервис-ориентированные системы, такие как Upstart и systemd. Здесь Unix пошла по пути, проторенному другими ОС. По словам Райса, у Windows NT с самого начала была сильная сервисная модель, а у Mac OS она до сих пор работает в виде launchd. Другим системам приходилось догонять.

Apple выпустила launchd в версии Tiger, где он заменил целую серию демонов обработки событий, включая init, cron и inetd. Таким образом, systemd стал попыткой позаимствовать хорошие идеи, реализованные в launchd. Когда Леннарт Пёттеринг начал решать эту проблему, он сначала посмотрел в сторону Upstart — системы, основанной на событиях. Она ещё работала на скриптах, но Пёттеринг пришёл к выводу, что сможет сделать лучше. В своей статье Rethinking PID 1 он называет launchd одним из образцов для работы. Он думал о повышении скорости загрузки и необходимости настройки системы инициализации на аппаратные и программные изменения в работающей системе. Во время создания init системы были статичными, но современная среда гораздо динамичнее, чем тогда.

Сервисный уровень


Классические Unix-подобные системы делятся на два основных компонента: ядро и пользовательское пространство. Но ядра со временем стали более динамичными и изменчивыми, подстраиваясь под оборудование, на котором они работают. Это привело к необходимости создания нового «сервисного слоя» (service layer) между ядром и пользовательским пространством. Этот слой включает в себя компоненты вроде udev и Network Manager, но systemd стремится обеспечить комплексный сервисный уровень; именно поэтому со временем он вбирал в себя функциональность таких компонентов как udev. Процесс шёл довольно успешно и был принят большинством (но не всеми) дистрибутивами Linux, хотя часто сопровождался язвительностью со стороны сообщества.

Против демона systemd часто звучат одни и те же аргументы: например, что он нарушает философию Unix. Райс предполагает, что этот аргумент основан на понятии, что systemd представляет собой единый монолитный двоичный файл. На самом деле systemd структурирован иначе: это много отдельных двоичных файлов, поддерживаемых в рамках одного проекта. Как «человек BSD» (он входил в число основных разработчиков FreeBSD), Райс находит смысл в таком объединении смежных концепций. Systemd — вовсе не раздутая и монолитная система, как считают некоторые критики.

Говорят, что в systemd много багов. «Это же софт», конечно, в нём будут баги, сказал Райс. Представление о том, что в отличие от любой другой системы systemd должен быть совершенным, поднимает планку слишком высоко. По крайней мере, у systemd практически всегда разумный режим работы при отказе, сказал он.

В той или иной форме часто повторяется одна жалоба, которую можно сформулировать так: «Не выношу Леннарта Пёттеринга». Райс отказался защищать стиль общения Пёттеринга, но сказал, что нельзя не восхититься силой воли и решимостью Пёттеринга. Не каждый сможет пройти через всё это.

Systemd не стремится к портируемости на системы, отличные от Linux, что приводит к отдельному классу жалоб. Если systemd станет стандартом, существует риск того, что операционные системы за пределами Linux станут ещё более изолированными. Многие хотят, чтобы systemd придерживался стандартных для Unix интерфейсов, но у Райса для них простой ответ: «Unix мёртв». Когда-то Unix был упражнением в предельной переносимости и имел реальный успех. Но теперь мы живём «в мире Linux с небольшими ошибками округления» (что человеку от FreeBSD больно говорить), и нет смысла придерживаться классических интерфейсов Unix. Нынешняя ситуация является «патологической монокультурой», где Linux может диктовать условия.

Systemd много выиграл в такой ситуации. Например, контрольные группы — высокоэффективный и интересный механизм управления процессами, без них было бы гораздо труднее решать эти задачи. Они гораздо более мощные и детальные, чем джейлы FreeBSD. Разработчики систем типа FreeBSD могут видеть угрозу в непереносимости systemd. Но эта ситуация также даёт им возможность свободно работать и искать собственные решения этих проблем.

Перемены и трагедия


Райс говорит, что миссия systemd сводится к большим разрушительным изменениям — вот где начинается трагедия. У нас нердов сложное отношение к изменениям. Да, это потрясающе, когда мы сами их создаём, но изменениям нельзя доверять, если они приходят извне. Systemd представляет тот вид внешне навязанных изменений, который люди находят угрожающим. Люди противятся таким изменениям даже от приятных разработчиков, не говоря уже о Пёттеринге, который не особо сочувствует окружающим. Это приводит к рефлекторным реакциям. Но людям нужно отступить и подумать, что они делают. «Никто не должен угрожать Леннарту смертью из-за какого-то программного обеспечения», — говорит Райс. Презрение — это не круто.

Вместо этого стоит подумать: почему вообще появился systemd и почему это важно? Какую проблему он решает? Для критиков одним из решением может быть попытка создать собственную альтернативу: они поймут, насколько весёлая эта задача. Кроме всего прочего, эта история показывает разницу в мышлении у нового поколения, которое рассуждает о системах больше с точки зрения API и контейнеров, например.

Итак, какие выводы можно сделать из истории systemd? Один из выводов: нельзя недооценивать транспорт сообщений. Systemd интенсивно использует шину D-Bus, которая во многом обеспечивает его гибкость. Райс не сторонник D-Bus, но большой сторонник шин для обмена сообщениями между процессами. В своё время он лоббировал создание такой нативной шины в BSD-системах, желательно встроенной в ядро и с лучшей безопасностью, чем у D-Bus. Поверх неё можно сделать надлежащую систему удалённого вызова процедур, где компоненты ядра и пользовательское пространство будут работать на одном уровне. В правильно спроектированной системе процесс просто отправит запрос API, не беспокоясь о том, где и как этот запрос будет обработан.

Среди прочих уроков — важность поддержки надлежащего жизненного цикла службы без необходимости установки дополнительных систем управления службами. Важно наладить автоматизацию обслуживания через API; и systemd обеспечивает многое из этого. Поддержка контейнеров также важна: это полезный способ инкапсуляции приложений.

Итак, в современных Linux-системах systemd выполняет роль сервисного слоя. Это хорошая платформа для управления службами, но она не должна быть единственной альтернативой. В systemd есть ряд полезных функций, включая удобные пользовательские юниты, последовательное именование устройств и даже хорошую модель журналирования, сказал Райс. Двоичные журналы — неплохая вещь, пока у вас есть инструменты, чтобы вытащить оттуда информацию. И systemd предоставляет новую модель приложения. Вместо одного двоичного файла приложение становится кучей модулей в одном контейнере.

Мир вокруг нас меняется, сказал Райс. Мы можем либо отдаться течению, либо сопротивляться ему. В первом случае, вероятно, плыть будет проще, чем во втором. Райс предложил всем, кто критикует systemd, более пристально изучить эту систему и попытался найти в ней хорошие вещи. Возможно, тогда завершится фаза катарсиса нашей трагедии — и мы сможем двигаться дальше.

Видеозапись выступления опубликована на YouTube.

Поддержать автора
Поделиться публикацией

Комментарии 344

    +2

    Попахивает Стокгольмским синдромом. Адекватно и корректно про трагедию systemd написано здесь: https://www.skarnet.org/software/s6/systemd.html (англ.).

      +5
      Почему? Мне кажется, что по сути хоть нас и лишили выбора — systemd есть уже везде, но это не так уж и плохо. По крайней мере, стоимость поддержки зоопарка систем в виде centos/rhel/ubuntu/debian стала ниже. Юниты удобно и легко писать и отлаживать и можно забыть этот кошмар с init.d-скриптами в прошлом.
        –1

        Кошмар с init.d для меня ушёл в прошлое в 2001 году, когда я собрал свой дистрибутив на базе LFS с запуском сервисов через daemontools. Правда, появился кошмар поддержки своего дистрибутива, но это решилось переходом в 2004 на Gentoo с использованием runit и в качестве init и для управления сервисами. 15 лет такой вариант Gentoo используется и на рабочих станциях и на серверах — никаких проблем нет, всё работает крайне надёжно и требует минимальной поддержки раз в пару лет (я про конфиги runit для загрузки ОС и/или сервисов).


        Что касается запуска собственных проектов где-нить на AWS, то там запускается любой дистрибутив, под него ставится докер, и всё остальное происходит исключительно в докере — что там за дистрибутив на хосте и используется ли в нём systemd или что-то другое — уже без разницы, на хосте помимо установки докера разве что специфичным для дистрибутива способом запускаются обновления ОС.

          +3

          Предлагаете все тащить в докер? И БД (монга, постгрес и пр.) тоже?
          И если уж на то пошло:


          • тогда дистрибутивы типа Gentoo, Centos и пр. не нужны — лучше брать CoreOS Container Linux
          • compute instance вообще не нужны — нужна платформа типа кубернетеса.

          И, да, докер — это уже прошлый день. Теперь модно CRI-O/containerd.

            +1

            Да без разницы, какой дистрибутив, и без разницы, докер или что-то другое модное, суть в том, что то, что мы раньше ставили на сервера системными сервисами теперь ставится контейнерами. БД в докере работает ничуть не хуже, чем вне докера — volume с данными по сути подключается через bind mount каталога хоста, так что проседания производительности нет.

              +1
              Спасибо, я в курсе.
              Сам проводил измерения. Но есть нюансы ) дьявол в деталях.
              Та же сетевая латентность при работе через докер выше. Для какого-нибудь хостинга или простого сайта это некритично, но для серьезных применений — так себе и нужно это учитывать.
              С другой стороны — действительно, systemd позволяет все настроить так же. И даже зарезать сервисы по cpu/mem через те же cgroups. Нужно ли в этот зоопарк тащить ещё и докер, т.е. лишнюю сущность — ну, пускай решает сам )))

              P.s. я уж не говорю какой это ад настроить файрволл на машине с докер-демоном, под управлением scm, да ещё и в роли vpn пира )))
                +2

                Ну, я бы не сказал, что прямо ад. У меня на домашнем сервере 20 сетевых интерфейсов, часть разные локалки для изоляции, пара провайдеров, несколько клиентов openvpn, сервер openvpn, ну и докер (причём в нём несколько разных проектов, каждый в своей docker network) — настройки iptables у меня ручные, довольно сложные, но про докер там почти ничего — прописаны его подсети для антиспуфинга и немного фильтрации. Докер в iptables сам кучу своего добавляет, но этими правилами он рулит сам, и пока они ничего не ломали, хотя в моих условиях этого можно было ожидать.


                А на нормальных серверах я обычно все докеры помещаю в общую сеть площадки (staging, prod, etc.), не доступную напрямую из инета, и файрвол настраиваю на сервере-шлюзе между этой сетью и инетом (ну и плюс в роли а-ля файрвола по конкретным докер-сервисам выступает конфиг nginx куда приходят запросы юзеров, фактически этот конфиг определяет, какие докер-сервисы публичные, а какие нет).


                Что касается латентности — да, но это для абсолютного большинства проектов некритичный недостаток, зато бонусов от упаковки конкретных версий сервисов в образы докера и запуска их везде — от CI до машин разработчиков — намного больше.

                  0
                  Ваша точка зрения понятна. Спасибо. Я больше про кейсы, когда нужно перезагрузить правила netfilter и система управления файрволлом перезагружает все, после чего правила docker ломаются. Решение — перезапустить докер-демона, чтобы он все перестроил «как надо», но оно не всегда приемлемо (если нельзя делать даже минимальный простой). Либо управлять правилами файрволла полностью руками, а не пользоваться автоматикой, встроенной в докер.
                  В целом — преимущества от использования докера перевешивают недостатки и сложности, вносимые им. Но, к сожалению, мои разработчики вот эти вот граничные кейсы вряд ли осилят сами.
                    0
                    И ещё. Вопрос безопасности. Докер — это не про безопасность. Точнее — не про ту. Действительно, он реализует изоляцию контейнеров. Но она не железобетонная. Одна ошибка в ядре или демоне — и мы приплыли. Я больше про разделение прав пользователей. Гипотетический сценарий. Есть сервер. На нем докер. С ним работает 5 разработчиков. Хочется красиво распилить права. Но нет — для работы с докеросрачик нужен или рут-доступ, или добавление пользователя в группу docker. А последнее эффективно означает рутовые права на сервере (надеюсь, не надо пояснять почему?). В доверенной среде, когда все друг друга знают очень хорошо, это ещё куда ни шло. Но в прод такое тащить…
                    Есть несколько идей как такое победить. Например, можно определить структуру контейнеров изначально. Администратор ее формирует, а далее через sudoers даёт возможность выполнять команды docker пользователям только над своими контейнерами. Или, я тут позавчера случайно узнал, можно запустить два докер демона. Не изучал глубоко эту возможность, но для чего-то это может пригодиться.
                    Но лучше решение, конечно, — наверное, мигрировать в кубернетес или опеншифт. Он большой пласт этих вопросов закрывает
                      +3
                      Мы такую проблему решаем через деплой исключительно через настроенный CI/CD. И систему мерж реквестов, вероятность возможности навредить сильно снижается. В определенных случаях ещё и через Docker in Docker запускаем, ещё сильнее изолируя разработчиков.
                      Конечно, последним рубежом является выделение одного и более виртуального сервера на проект…
                        –1
                        Попробуйте повоевать с дата-сатанистами на этот счет )))
                        Понятно, что можно отрезать все ручки, чтобы все было только автоматизированно. А на сервере пускать только по служебкам… Но это такое себе…
                        Конечно, последним рубежом является выделение одного и более виртуального сервера на проект…

                        несомненно. Это еще и другие плюсы — например, удобнее считать косты, чем пытаться понять какая загрузка сервера в этом месяце была между проектами, если они его делят.
                          0
                          Попробуйте повоевать с дата-сатанистами на этот счет )))

                          Безопасность практически всегда вредит удобству использования, но я полностью согласен с alexkuzko — деплой на сервера необходимо автоматизировать через CI/CD, доступ на сервера должен быть только у devops, разработчики, даже если они дата-сатанисты, должны вносить все изменения в код только через репо (причём право мержа в ветку, которая автоматом выкатывается на сервер, должно быть только у тимлида) и непосредственного доступа к докеру не иметь.


                          Либо, если это не прод, то можно поднять им отдельный сервер и дать полный доступ к нему, главное чтобы была возможность быстро грохнуть его и пересоздать с нуля за несколько минут, на случай его они его сломают.

                            +1
                            Я, между прочим, Вам не перечу и поддерживаю точку зрения, что в идеальном мире нужно деплоить только через автоматизированный CI/CD. К сожалению, на этом пути много мин :-)
                            Либо, если это не прод, то можно поднять им отдельный сервер и дать полный доступ к нему, главное чтобы была возможность быстро грохнуть его и пересоздать с нуля за несколько минут, на случай его они его сломают.

                            ну, или откатить состояние, если уж на то пошло.
                      0
                      насчет файрволла. Вообще идеальный кейс, когда платформа (ну, там амазон, гугль, или openstack в on-premise инсталляции — не важно) предоставляет примитивы vpc или файрволла на уровне сети. Тогда можно настроить группы безопасности и они имеют приоритет перед файрволлом внутри ВМ. И можно спать спокойно. В противном случае, повторюсь, настройка файрволла на машине докера похожа на попытки «скрестить ежа с ужом».
                        0

                        Ну, дома я действительно вынужден либо перезапускать докер после перегрузки правил iptables, либо менять правила по одному и ручками, не забывая при этом продублировать их в системный конфиг чтобы они сохранились после перезагрузки. А на серверах, как я уже говорил, проблема решается отсутствием отдельных правил iptables на серверах с докером, они настраиваются на шлюзе и/или в AWS VPC.

                      –2
                      >я уж не говорю какой это ад настроить файрволл
                      >Ну, я бы не сказал, что прямо ад.

                      Для типичного девопуса добавить правило после докера — непосильная задача. И сам докер писали, похоже, такие же девопусы — например очень типичное правило в таблице nat делающее redirect с 8080 по 80 порт докер не видит и просто тупо не работает. А типичный девопус сидит целый день над этой страшной проблемой и чешет голову, Я и Ж.

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

                      Да, девопуса заставить обновлять что-либо невозможно. Даже если их сильно пинать за устаревший софт. Иначе бы пользовались yum-репозиториями вендора.

                      Мне вообще удивительно, как инструменты нищебродного хайлоада (т.е. когда нагрузок много, а денег мало) расползаются и в нормальное ИТ.
                      До докера уже много лет можно было делать live migration. С «могучим» докером это проблема. Софт писали так, чтобы он не падал раз в день, соответственно 100500 копий его запускать смысла не было. Вменяемое количество копий и деплой по группам можно делать средствами application server-а уже 15 лет. Журналы (логи) читали. А сейчас модно запустить 100500 копий, 30% из которых возможно как-то худо-бедно будут работать, потом терабайты логов грузить в специально развернутый очередной кластер и НЕ ЧИТАТЬ. И этот подход впаривают как передовой… (рукалицо)
                        –2
                        Для типичного девопуса добавить правило после докера — непосильная задача. И сам докер писали, похоже, такие же девопусы — например очень типичное правило в таблице nat делающее redirect с 8080 по 80 порт докер не видит и просто тупо не работает. А типичный девопус сидит целый день над этой страшной проблемой и чешет голову, Я и Ж.

                        Проблема не в том, что это непосильная задача, а проблема в том, что это сложности на ровном месте. Вы же понимаете, что правило из таблицы NAT имеет приоритет перед таблицей filter со всеми вытекающими. А еще отдельная история, когда правило в nat есть, в filter разрешающего нет и ты удивляешься почему контейнер одним способом доступен, а по прямому IP хоста — нет.
                        И только вот в каких-то последних версиях докера сделали наконец-то отдельные цепочки DOCKER-USER, хотя, честно говоря, не особо это и спасает.
                        Софт писали так, чтобы он не падал раз в день, соответственно 100500 копий его запускать смысла не было.

                        это последствия тренда на то, что мы все запускаем на дешевом голимом ненадежном железе, потому что массовый рынок, а реально надежные и хорошие железки выдавливаются в очень узкий сегмент. Но производитель же ведь тоже не дурак и хочет кушать ) и поэтому наценка на эти узкоспециализированные, но очень надежные железки взлетает в космос (это типичная экономическая история). Касательно надежности еще момент, что всегда что-то может отказать. Независимо от количества девяток. И нужно иметь план Б. Будь-то восстановление с простоем, или что проще — иметь реплику и переключать на нее трафик.
                          –1
                          >что мы все запускаем на дешевом голимом ненадежном железе

                          Мы это кто конкретно? :) Я в прошлом сообщении уже проехался по нищебродно-хайлоадному подходу. Гугл, вроде, на коньсюмерном мусоре раньше крутился. Зачем натягивать сову на глобус (инструменты для решения проблем масштабирования гугла втюхивать всем)?

                          В нормальных конторах, даже не особо богатых, в стойках стоят серверы, с надежностью оных ничего не случилось. Сейчас наоборот виртуализация используется в 90% случаев, которая умеет live migration. А докер?!

                          И касательно железа, я наоборот не устаю поражаться — даже в плохих условиях (регулярные сбои системы охлаждения, а серверы работают как часы. Даже после многократных самоотключений по достижении +42С ambient. ;) У дисков SMART смотришь — 55-57 градусов. И живут по 7 лет. И тд и тп.
                            0
                            И касательно железа, я наоборот не устаю поражаться — даже в плохих условиях (регулярные сбои системы охлаждения, а серверы работают как часы. Даже после многократных самоотключений по достижении +42С ambient. ;) У дисков SMART смотришь — 55-57 градусов. И живут по 7 лет. И тд и тп.

                            а) были исследования, которые показывают, что с ростом температуры количество отказов нарастает. Например, желтизна, но повод подумать.
                            б) есть куча историй про вылеты дисков. От перегрева тоже. И из «бракованных» (нет, мне не нравится, давайте назовем лучше — рискованных или ненадежных) серий и партий
                            в) у гугла были проблемы с отказами в ДЦ из-за перегрева. Из новостей нашел аналогичную историю про MS тыц.
                            г) по поводу железа — действительно нужно удивляться, что оно вообще работает. Это такая сложная инженерная материя ))) что прямо магия. И не нужно питать иллюзий по поводу надежности.
                            В нормальных конторах, даже не особо богатых, в стойках стоят серверы, с надежностью оных ничего не случилось. Сейчас наоборот виртуализация используется в 90% случаев, которая умеет live migration. А докер?!

                            так виртуализация за эти и нужна, чтобы тоже компенсировать недостаток надежности железа + более гибкое управление ресурсами.
                            Докер — лив-миграцию сам не умеет (она ему и не нужна), но со всякими обвязками отчасти решает проблему.
                            Я в прошлом сообщении уже проехался по нищебродно-хайлоадному подходу.

                            и что? Мы живем в рамках некой парадигмы. И если все делают каким-то образом, то и нам тоже придется делать так же. Экономика-с.
                            Мы это кто конкретно?

                            Мы — все. Ну, может кроме каких-то специфичных применений из mission critical, но там есть соответствующие бюджеты.
                              –2
                              >так виртуализация за эти и нужна, чтобы тоже компенсировать >недостаток надежности железа + более гибкое управление
                              >Докер — лив-миграцию сам не умеет

                              Итого, спрашивается, а зачем нужен докер (не гуглу!)? Виртуализация уже много лет как есть. И даже бесплатная умеет больше докера. Про VMWARE молчу.

                              >(она ему и не нужна)

                              Конечно, у девопусов же мантра «быстро поднятое упавшим не считается» :)))

                              И от собственного микросерия головного мозга они не страдают. Хотя микросервисы понятие из лохматых 90-х и никто не мешал их делать последние 50 лет на любой из технологий (которые заметно легче очередного хайпового REST).
                                0
                                Я предлагаю вам пойти еще дальше. Зачем нужна виртуализация, если все можно запускать в bare metal? Зачем вообще что-то нужно, если вы этого не понимаете?
                                Что плохого в том, что «быстро поднятое упавшим не считается»?
                                Вы читали вообще про 12-factor-app?
                                  –1
                                  >Вы читали вообще про 12-factor-app?

                                  Ой, ну всё, до 2011 года программирования не было. И надежных сервисов.

                                  С этим тоже смешно получается, есть такая очередная хайповая придумка маздайсофта — SDL. При этом, качество ХР и качество «дисяточки» почему-то не в пользу последней. А почему? Потому что «индусы заполонили» и «быстро поднятое упавшим не считается».
                                    0
                                    Да конечно были, только сейчас 2019 год, количество информации в единицу времени растет по экспоненте. Старые подходы и старые технологии уже не работают, придумывают новые. Нормальный процесс, разве нет? Как вы будете, например, 10 гигабит данных в секунду обрабатывать, скриптом на перле? 3 года писать надежный сервис для этого? Ну, успехов чо
                                      –3
                                      Ну запустишь перл-скритп в докере и что изменится?

                                      Cчитать, что без докера масштабируемость не делается — свою отсталость светить.

                                      >10 гигабит данных в секунду обрабатывать
                                      >3 года писать надежный сервис для этого

                                      У фанатиков докера уже сам докер данные обрабатывает? Хехе… Ну, взяли докер, потом что, надежный сервис сам напишется? :)))
                                        +3
                                        Нет, я запущу кубернетес кластер, например, и там буду делать map-reduce, например, с использованием по максимуму всех возможностей kubernetes, автоматическое скалирование, например.
                                        Что даст мне возможность сконцентрироваться на задаче обработки данных, за которую мне в итоге и платят. А задачи масштабирования, скалирования, HA и прочего с разработчиков будут сняты по максимуму. При этом разработчики будут коммитить по сто раз на день, а не раз в полгода. С моментальной выкладкой кода на прод, а не раз в полгода, на что будeт автоматически запускаться куча тестов, уменьшая в итоге количество ошибок и увеличивая качество продукта.
                                        Что увеличивает эффективность, уменьшает косты и позволяет в итоге зарабатывать больше, а тратить меньше.
                                          –3
                                          Ох уж эти влажные мечты ;)
                                            0
                                            Так вы попробуйте, может и у вас получится.
                                            Мы к марту доделаем четвертый проект уже за год по похожей схеме. Kubernetes+JenkinsX+Gitlab, Hadoop
                                            Приезжайте в мае на kubecon, я вам расскажу в деталях, без проблем.
                      +4

                      > Та же сетевая латентность при работе через докер выше.


                      Не выше, если использовать host network режим.

                        0
                        О, докеросрачик.
                        По host mode режиму — у меня строгое ощущение, что он создаёт больше проблем, чем решает. Ну, попробуйте в нем, например, запустить два postgres из одного образа. :) Понятно, что удариться в микроменеджмент и руками раскидывать все порты, но это убивает все преимущества docker.
                        Если у Вас другие ощущения — расскажите, прям даже интересно
                          0

                          Я считаю, что docker networking — зло. связывание локальных контейнеров в общую подсеть — фича сомнительной полезности, т.к. в реальной среде разные приложения обычно развернуты на разных хостах. Микроменеджмент портов это ни разу не отменяет, т.к. настраивать их или пробрасывать их — и там, и там нужна похожая конфигурация.


                          Мы строим работу с сетью примерно так:


                          • все наши образы позволяют настраивать номер порта и интерфейс для всех слушающих портов.
                          • если сервис нужен только локально, он биндится на локалхост
                          • имя сервиса-ip-порт сохраняются в service discovery

                          Таким образом, всё работает быстро, слушающие порты настраиваются в конфиге приложения (мы ведем табличку портов для приложений, чтобы не было конфликтов, но порты можно назначать и рандомно), клиенты получают номер порта из service discovery.

                            0

                            docker networking удобен в случае, например, фрилансера, держащего на своей рабочей станции несколько не связанных проектов, которые хочется как-то изолировать друг от друга.

                              0
                              может все-таки стоит использовать vagrant?
                              По крайней мере присмотреться к нему поплотнее?
                              Ну, и я не поверю, что все эти «несколько несвязанных проектов» нужно держать запущенными одновременно, а не последовательно (хотя, конечно, кейсы разные бывают...)
                                0

                                ну, это частный случай. и даже в такой ситуации я предпочитаю написать простые шелл скрипты, поднимающие и опускающие нужный набор контейнеров.

                        0
                        Ну а телефония в докере показывает иногда и 20%+ падение производительности и проблемы со звуком.
                        С базой тоже есть патерны, показывающие падения(например, большое количество записи или не помещающиеся в память сеты).
                          +1
                          Как вы меряете производительность телефонии? Каждый пятый звонок обрабатывается неправильно и виноват прям докер? Да ладно.
                          С базой тоже непонятно, а без докера таких паттернов нет?
                            0
                            Производительность просто — речь о количестве клиентов или одновременно идущих (с минимально определенным качеством) телефонных разговоров.
                            Касательно базы — все же ясно.
                            а без докера таких паттернов нет?

                            и да, и нет. Просто докер вносит еще один уровень абстракции, еще один слой промежуточных сервисов, которые могут влиять на всю систему.
                              –1
                              То есть при запихивании абстрактного астериска в докер контейнер, количество обслуженных клиентов падает на 20 процентов? Это очень большая величина, почему так? Откуда 20% появилось? Как считали? Там просто неоткуда взяться такой цифре.
                              Ничего с базой неясно. Ютуб гоняет и ничо, жужжит вроде.
                              Ничего особого докер никуда не вносит, использует cgroups и немного сетевой магии. Кубернетес уже везде. Оверхед 5%, плюсов больше. Никакой еще один слой абстракции никуда не вносится, все механизмы давно в ядре. Слой промежуточных сервисов может влиять на всю систему, согласен. А может и не влиять, тут уж как настроишь.
                                +1
                                Это число сказал я.
                                Зачем вы у него спрашиваете.
                                Считали так — запускаем нагрузочное тестирование и сложный диалплан с докером и без, увеличиваем нагрузку, пока не просядет качество.
                                У докера, lxc и openvz +- одинаковые показатели в данном тесте. У xen и qemu еще все хуже. Хуже всего дело обстоит у hyper-V.
                                  0
                                  Ну, вы уверены, что вы там все правильно настроили и понимаете, что вы там тестили?
                                  Я вот не уверен. В этих тестах, например, помешаны в кучу кони и люди. Вот Оpenvz, например, на каком ядре работает сейчас? 2.6.32? Даже со всеми патчами — это по-прежнему 2.6.32, с того времени сколько сотен тысяч строк в ядро накоммитили? Докер и lxc — это тоже немного разные вещи. Гипервизоры сюда еще как-то попали.
                                    0
                                    Я соглашусь, что измерение могло быть однобоким в том плане, что были выбраны неоптимальные и странные настройки докера. Другой вопрос, что почему эти странные и неоптимальные настройки были по дефолту. Например, мне руками приходилось драйвер менять на overlay2. Надеюсь, не будете отрицать, что aufs — сейчас это дно? Медленное.
                                      0
                                      Тому причин множество. Overlay, например, не Posix Compliant, что может повлечь некоторые проблемы в работе приложений.
                                      +2

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

                                        –2
                                        Я не пишу, но в контейнере может быть что угодно.
                                        Например, пишутся неотключаемые логи или временные файлы.
                                        Или мне безразлична судьба базы данных.
                                        Что тогда скажете?
                                        Понятно, что не все кейсы должны случаться
                                        Хотя бы из каких-то разумных соображений.
                                        Но чисто гипотетически в качестве образа Вам могут передать что угодно. И с неверной инструкцией.

                                        Для справедливости скажу, что, вот, например, постгресовский дефолтных образ базу ВСЕГДА пишет в вольюм. Независимо от Вашего желания. Потому что объявлен в Dockerfile. Т.е. если явно ничего не делать, то появляются безымянные вольюмы, но, в общем-то, это не особо страшно. И это даже хорошо
                                          +3
                                          Кто вам мешает пересобрать и сделать правильно?
                              0
                              Количество звонков, при котором вы гарантировнно получаете проблемы со звуком = производительность телефонии. Если ставил эксперт, то процентов на 20 разница. Там очень много мелких пакетов проходит(mpps). А вообще может и со старта быть проблемы со звуком.

                              Производительность базы похоже на падение как с недавним мелдаун патчем. Когда у вас быстрая ssd и много операций чтения — это заметно. Естественно вы это не заметите на супер-медленных hdd.

                              В общем не стоит виртуализацию сунуть там, где она не нужна.
                                0
                                Да, только докер — это не виртуализация. Диски тут вообще никак не аффектятся.
                                Медленнее в докере только сеть.
                                «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 тысяч человек в слак чате кубернетеса подтвердят.
                                  –2
                                  Да ладно. Даже LVM это виртуализация в том или ином виде. Докер контейнеры это лишние проверки на пути.
                                  Конечно, это виртулизация. Просто не PVM.
                                    0
                                    Да чего говорить с докер-зомби — только бисер метать…
                                    Вот что бывает при фанатичном использовании технологий… А мудрость… Ну, появится потом…
                                      0
                                      Так не надо метать бисер, приведите факты. Пока я вижу только некие «20%», некие «лишние проверки» и прочее. При этом ютуб-то работает?
                                        0
                                        Мне очень жаль, что Вы не понимаете разницы между latency & throughput/bandwidth. В орфографии мог немного ошибиться )
                                        Обслуживая массового клиента мы в первую очередь стараемся охватить бОльшее количество клиентов, чем сделать сервис отзывчивым для каждого из них. В общем-то это в струе docker'а. Он, к сожалению, не про скорость, а больше про скорость разработки, вывода в продакшн, про изоляцию и про унификацию среды.
                                          0
                                          Да с чего не про скорость, я выше приводил цитату, где уже все померяли и замерили еще в 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."
                                            0
                                            Да сравнение там некорректное. Не на всех типах нагрузки. К тому же много воды с тех пор утекло.
                                            Краткий вывод получается, что при сравнении производительности kvm vs docker — докер всегда рвет КВМ (ну, прям К.О.), т.к. он все-таки контейнеризация, а не виртуализация. Касательно docker vs bare-metal даже из того обзора видно, что сеть немного, но медленнее, да и диск гоняли только в одном из режимов. У меня цели жонглировать цифрами и фактами нет, но могу сказать, что в реальности картина немного другая. Да и учтите, что обычно докеры крутят на ВМках… А не поверх баре-метала. Что вносит еще больше неизвестных.
                                              0
                                              ага, при условии, что те же bind mount'ы выставлены так, что /var и /tmp контейнера смотрят на тот же диск, где data volume'ы/mount'ы.
                                              иначе получается, что какой-нибудь перегон пары гигабайт временных данных происходит не на уровне фс, а на уровне блочных устройств, «незаметно» для юзера отжирая время и ресурсы
                                                0
                                                если вы говорите, что mv между двумя байнд маунтами одного устройства будет простым переименованием, то нет. это будет копирование плюс удаление
                                        0
                                        Да, выразился неверно. Это виртуализация, на уровне операционной системы, в рамках одной ОС. Лишние проверки на пути — проверки чего? Вместо одного экземпляра пространства пользователя, работает несколько, акей. Как это влияет на количество каких-то проверок?
                                          0
                                          На пути системных вызовов. Например, очевидно, что доступ к файлу на слоеной файловой системе должен пройти через все слои в худшем случае. Действительно, скорость может не сильно пострадать. Да и задержка тоже. Но могут быть специфические кейсы, в которых просадка будет заметна.
                                          Или Вы утверждаете, что это будет быстрее, чем обратиться к файлу на настоящей ФС?
                                            0
                                            Все зависит от настроек. Может вы там лупбек тестили на лвм. Тогда будет медленнее. Overlay2 будет даже быстрее.
                                            А зачем файловую систему вообще тестить в докере? Для этого есть персистентные хранилища, контейнер сам по себе эфемерная сущность.
                                              –1
                                              А зачем файловую систему вообще тестить в докере?

                                              А Вы правда думаете, что ее скорость не играет роли от слова совсем?
                                                0
                                                Скорость чего? Файловой системы эфемерного докера или файловой системы персистентного хранилища? Вы вообще понимаете, как устроен и как работает докер?
                                                  0
                                                  Тяжелый случай…
                                                  +2

                                                  да, не влияет. ФС в докере нужна исключительно для чтения бинарников в память. всё серьезное IO должно быть смапплено на каталоги основной файловой системы.

                                            +1
                                            Это не виртуализация ни разу. Это банальное увеличение изоляции. Ядро остается одно на всех и виртуализации устройств не происходит.
                                  0
                                  Да без разницы, что модно. Главное — чтобы работало, а не было модным.

                                  Ну, если вам конечно не надо меряться понтами с другими айтишниками.
                                  +1
                                  Там все так же плохо. Для каждого сервиса пишется свой скрипт. У systemd из ключевых моментов про который редко кто говорит, это отсутствие привязки к какому-то sh в описании сервиса. Он там просто не требуется. В итоге в случае если у вас ПО запускается на разных дистрибутивах то можно использовать один и тот же unit файл. В итоге для linux к примеру разработчик может включать unit файл для своего ПО и будет уверен, что он работает. В отличии от пачки init скриптов которые обычно для ПО писались непосредственно мантейнерами дистрибутива.
                                    0

                                    Вот только документацию всем многим читать лень, и одни и те же (далеко не идеальные) копипастные шаблоны гуляют от сервиса к сервису.


                                    (Справедливо как для systemd unit'ов, так и для init-скриптов.)

                                      +1
                                      Для systemd это меньшая трагедия, практически все unit там малы и понятны :)
                                        0
                                        Это пока малы
                                          +1
                                          Они и не рассчитаны на то, чтобы быть монструозными. И сложность переходит на уровень взаимодействия юнитов друг с другом, а не нарастает ВНУТРИ юнитов.
                                            0
                                            Возможно вы не помните, но тоже говорили про init.d/rc.d
                                            Ничего не мешает индийским кодерам насунуть внутрь больше ctr-v
                                      +4
                                      Всё же описание сервиса — не скрипт, а скорее декларация. В любом случае, простой сервис определяется за пять минут, отладки практически не требует. После SysV init — глоток свежего воздуха, честное слово.
                                        0
                                        Именно так. Более того, в тех же redhat и debian в sysvinit это частично пытались втаскивать через конфигурации с стандартные скрипты. Но это все равно совсем не то.
                                    +3
                                    Я соглашусь с Вами в одном моменте, который, с точки зрения моей (не админа, а продвинутого юзера-разработчика, использующего линукс в своей деятельности)
                                    systemd есть уже везде

                                    Вот! Эта подсистема инициализации покрывает 90% популярных дистрибутивов, и, при всех недостатках (о которых я не берусь судить ни в коей мере!) стала стандартом дэ-факто. А значит разобраться в работе навскидку взятой системы, починить её и настроить стало проще, потому что нужно знать только одну подсистему инициализации.

                                    Другой вопрос, что при несовершенстве стандарта его нужно улучшать. Но я, как просто потребитель продукта GNU/Linux оцениваю шествие systemd по планете больше положительно, чем отрицательно.

                                    что по сути хоть нас и лишили выбора

                                    никто не лишал нас выбора — очень многие мои арчеколлеги юзают OpenRC и не жалуются. К счастью линук != отсутствие выбора, при должном уровне квалификации, разумеется
                                      –2

                                      Арч и прочие — это весьма маргинальные дистрибутивы, которыми пользуются, ну, наверное, процентов 10 максимум. Я говорю именно про сервера, а не персональные машинки. К сожалению, у меня на руках нет точных цифр, т.к. я не нашел правильных обзоров. Но, повторюсь, что по ощущениям топчик такой: ubuntu, centos/rhel, debian, потом уже все остальное.

                                        +5
                                        Арч и прочие — это весьма маргинальные дистрибутивы, которыми пользуются, ну, наверное, процентов 10 максимум

                                        Называть арчеводов маргиналами… ну, как-то грубовато, не находите? Тем не менее да, арчеводов довольно мало, но systemd не только на арче, а и на всём перечисленном Вами, и альтернативные подсистемы инициализации доступны и там.
                                          0
                                          Да, прошу прощения, я не про то, чтобы обидеть, а про то, что это меньшинства.
                                            0
                                            Я понял, ничего страшного)
                                    0
                                    На первый взгляд, по большей части там приводятся аргументы, опровергаемые Райсом.
                                      +2

                                      Это не совсем так, вчитайтесь чуть внимательнее. Там описана базовая проблема (с точки зрения автора) дизайна systemd:


                                      The single, overarching problem with systemd is that it attempts, in every possible way, to do more instead of less.

                                      Всё остальное — это просто логичные следствия этого подхода, среди которых действительно встречаются и упомянутые Райсом.

                                      +3
                                      автор этого опуса, мягко говоря, не в теме. sytemd это linux basesystem. т.е. вместо стенаний «BSD is not dead, Solaris is not dead, but systemd ignores Unix» можно пройти и посмотреть, из чего состоит и как разрабатывается freebsd base
                                        +1
                                        Ну и там вопросы, а почему кто-то должен поддерживать FreeBSD и прочее? Им надо пусть поддерживают. Никто не мешает патчи писать, если патчи не принимают форкнуть в конце концов. Или написать свой который реально лучше.
                                        0
                                        Например, контрольные группы — высокоэффективный и интересный механизм управления процессами, без них было бы гораздо труднее решать эти задачи. Они гораздо более мощные и детальные, чем джейлы FreeBSD.

                                        Странно разработчику FreeBSD сравнивать CGroups c jail. Насколько я знаю CGroups — это метод управления разделением ресурсов системы между группами процессов. С Jail скорее соотносятся пространства имён. Да и чрезмерная навороченность cgoups не позволяет ими пользоваться в отрыве от такого инструмента как systemd, поскольку управлять руками всеми этими параметрами нереально (а реально ли ими вообще управлять человеку? это всё помещается в одну голову?). В FreeBSD можно пользоваться учётом и ограничением ресурсов, причём вешать это ограничение именно на jail-ы объединяя группы процессов в контейнеры, что ИМХО намного прозрачнее управлением ресурсами по-сервисно.

                                        у Райса для них простой ответ: «Unix мёртв». Когда-то Unix был упражнением в предельной переносимости и имел реальный успех. Но теперь мы живём «в мире Linux с небольшими ошибками округления»

                                        Когда-то это мир принадлежал Microsoft Windows, и эти времена ещё не прошли до конца. Кроме того в самом Unix были лидеры отрасли, захватывающие поляну на время. ИМХО не стоит настолько ультимативно заявлять о безальтернативности Linux…
                                          +1
                                          ИМХО не стоит настолько ультимативно заявлять о безальтернативности Linux…

                                          мир очень изменяется. Раньше были и мейнфреймы, к которым одновременно подключались сотни пользователей. А завтра — все вычисления будут в облаке, поверх lambda / FaaS. И эти линуксы будут никому не нужны. Точнее не так — они будут обеспечивать работу всей этой махины, только знать их нужно будет именно тому персоналу, который обеспечивает этот промежуточный слой. А потребителю услуги (т.е. разработчику) будет предоставлена возможность писать код на более высоком уровне абстракции на его любимом языке.
                                            +3

                                            Чур вас с облаками.
                                            Они нужны для крайне малой категории задач и пускай там и остаются, в большинстве случаев они противопоказаны. Вычисления, если возможно, нужно производить ближе к пользователю.
                                            Мощностей пользовательского оборудования сейчас более чем достаточно, особенно если избавиться от ненужных абстракций "любимого" языка программирования. Если пропускную способность с горем попалам поднимают(и далеко не бесплатно), то задержки сети и доступность ещё никому победить не удалось, не говоря уже о потери контроля за данными.

                                              +1
                                              Есть идея о будущем буме «пограничных вычислений», но что-то я пока ни оборудования не вижу, ни технологий для этого. Может просто плохо смотрел, т.к. это пересекается с основной деятельностью чуть менее чем никак.

                                              Kubernetes поверх «малинок» уже возможен и на одном из митапы его продавали. Но этого недостаточно, чтобы эту область вытянуть.
                                                0
                                                Kubernetes поверх «малинок» уже возможен и на одном из митапы его продавали.

                                                А применение этому безобразию то какое? ну кроме отказоустойчивых микросервисов управления домом…
                                                  0
                                                  ну, типа надежные пограничные вычисления + уже известный фреймворк и методики управления (ну, там манифесты и пр.).
                                                  Что-то такого плана www.youtube.com/watch?v=1vTn9qs24Ug
                                              0
                                              Раньше были и мейнфреймы, к которым одновременно подключались сотни пользователей. А завтра — все вычисления будут в облаке, поверх lambda / FaaS

                                              Ну то есть ничего не поменялось, кроме интерфейса доступа к Mainframe. Ведь если вычесть из стоимости этой железки всё ЧСВ её создателей и продвигателей на выходе останется решение с достаточно оптимальным соотношением отказоустойчивости, управляемости, энергопотребления… Проблема то этих машин только в запретительной цене закупки и поддержки.
                                              0
                                              cgroups позволяет создавать контейнеры. Собственно doker поверх них и бежит.
                                                0
                                                Контейнеры в Linux — это пространства имён (namespaces) для изоляции и cgroups для разделения ресурсов, или я что-то путаю?
                                                  0
                                                  Мое ощущение, что да, что все верно понимаете.
                                                    +1
                                                    Там как бы namespaces выросли из cgroups. А потом уже выросли контейнеры как результат.
                                                +6

                                                Вот эта попытка менять весь мир под себя (есть мейнстримный Linux, а все остальные идут лесом) очень напоминает то, как себя вёл Microsoft cо своим Windows в своё время. В итоге игнорирование, или, в более мягкой формулировке — недостаточное внимание, ко мнению общественности пошло самому продукту во вред.
                                                Собственно тот же процесс начался и на Linux, когда вследствие такого рода эгоцентричности страдать начинают сами пользователи системы. К примеру, чего стоит недавнее заявление о том что ядро 5.0 скорее всего не будет поддерживать ZFS при том, что ничего enterprise ready в замен там в ближайшие годы не предвидится.

                                                  0
                                                  В смысле не включат или в смысле что даже dkms не соберешь?
                                                  UPD: Для ленивых — www.phoronix.com/scan.php?page=news_item&px=ZFS-On-Linux-5.0-Workaround
                                                    0

                                                    Не знаю, что там у вас не будет собираться, потому что у меня всё собирается много лет начиная с FreeBSD 8.0 прямо с ядром.
                                                    Насчёт перспектив в Linux лучше почитать предыдущий тред вместе с комментариями.
                                                    https://www.phoronix.com/scan.php?page=news_item&px=ZFS-On-Linux-5.0-Problem

                                                      +1
                                                      DKMS — Dynamic Kernel Module Support. Механизм для сборки и подключения модулей ядра не из основной ветки. И да, даже DKMS сломается, потому что из ядра выкинуть часть необходимых API(?).
                                                    –1
                                                    ZFS нет в ядре Linux в силу лицензии не совместимой с GPL.
                                                      +2
                                                      К примеру, чего стоит недавнее заявление о том что ядро 5.0 скорее всего не будет поддерживать ZFS при том, что ничего enterprise ready в замен там в ближайшие годы не предвидится.

                                                      Просто обратите внимание на общую [для всего мира] тенденцию — не нужно потребителю знать, что там под капотом: закройте глаза и пользуйте. Сломалось — несите в СЕРВИС. Вот и в ИТ Вам будут продавать сервис: *aaS


                                                      Смириться. Пока тенденцию не качнёт обратно :)


                                                      P.S. потому на *tree-fs и строят всякие "лисапеты", вместо того, чтобы просто сделать zfs diff :))

                                                        –1
                                                        Проблема в том, что zfs при поломках значительно сложней чинить… Под линуксом zfs всё ж менее надёжна, чем тупая и не самая быстрая ext4, но которая в 99% случаев даже не потребует fsck при ребуте кнопкой.
                                                        Под фрей поломать zfs мне не удавалось, а вот под линуксом на не слишком интенсивном i/o, но зато на требовательных по памяти задачах — получил oom с kernel panic и потерю данных в разделе с zfs. Ну и, к тому же, отдавать до четверти памяти под рабочие структуры фс — иногда перебор, тут всё ж не сервер-хранилище, а запускалка приложений в виртуалке с единственным /dev/vda.
                                                          –1
                                                          Сломалось — несите в СЕРВИС.

                                                          P.S. потому на *tree-fs и строят всякие «лисапеты», вместо того, чтобы просто сделать zfs diff

                                                          а какими глазами на вас посмотрит сервис, когда вы придете к нему со сломанным зфс диффом?
                                                          0
                                                          ядро 5.0 скорее всего не будет поддерживать ZFS при том, что ничего enterprise ready в замен там в ближайшие годы не предвидится
                                                          зол никогда не была и никогда не будет энтерпрайз реди. просто потому что энтерпрайз не совместим с неподдерживаемым tainted ядром. в то же время есть энтерпрайз дистры, в которых дефолтная файловая система бтрфс. которая ими поддерживается и у которой, в отличие от зфс(даже солярисовой, которая таки да энтерпрайз, а не неподдерживаемый костыль), не устаревший дизайн
                                                            0
                                                            зол никогда не была и никогда не будет энтерпрайз реди

                                                            Очень может быть что так. Однако, и альтернатив реальных пока нет.
                                                            BTRFS по многочисленным отзывам даже её поклонников, а также отказу от поддержки её развития со стороны "пингвинячьего всего" Redhat, находится на расстоянии лет (если не вечности) от стадии enterptise ready. Только на Oracle и надежда.
                                                            Несмотря на более современную архитектуру.

                                                              +1
                                                              из редхата просто все разработчики бтрфс поуходили в фейсбук, там ее некому поддерживать. т.е. это сложности редхата, а не бтрфс. в сусе разработчики есть, бтрфс поддерживается в слес, так что в полный рост энтерпрайз.
                                                                0

                                                                Трудно сказать что там творится под капотом, возможно у них там своя BTRFS с бэкджеком и шлюхами, но на средину прошлого года общедоступная BTRFS, по отзывам её поклонников, была глючным ломучим говном.
                                                                http://forum.ixbt.com/topic.cgi?id=109:309:9301#9301

                                                                  0
                                                                  у меня на опенсусе она никогда не подводила, НО я никогда не сидел на самых последних-распоследних ядрах… Последнее ядро у меня было что-то типа 4.4.116
                                                                    0
                                                                    У меня есть кластер из ~40 нод, там докер и atomic-fedora-29, проблем нет. Но там и записи почти нет, volumes все в цефе, свап не нужен. Ничего из функционала не используем. Пару блэкаутов было, пережили нормально. Подозреваю, сломается, если начать туда сильно писать.
                                                                    Как storage driver для докера, претензий нет.
                                                                      0
                                                                      у них исходники ядра в общем доступе. если у арчеводов что-то сломалось, то надо писать жалобы в свой дистр, а не на ихбт. ихбт за работу арча не отвечает. ну и середина прошлого года была давно. и ремарка про бекап забавная. бекап надо иметь независимо от файловой системы
                                                              +9

                                                              Как и ожидалось, в статье нет ни слова про daemontools, runit или Supervisor, но вместо этого — ложная дихотомия sysvinit vs systemd, и попытки преподнести любую критику как простое ретроградство.


                                                              Поклонники systemd, однако, такие поклонники.

                                                                +1
                                                                Ну, так сделайте нормальное сравнение. Докажите свою точку зрения. И возможно, что Вы убедите, например, меня, что OpenRC или runit — это правильно.
                                                                  +2
                                                                  У меня нет намерения что-то доказывать (сам использую систему с systemd и не страдаю). Просто было бы неплохо излагать историю объективно, а не как в политике.
                                                                    +1
                                                                    +1
                                                                    Как и ожидалось, в статье нет ни слова про daemontools, runit или Supervisor, но вместо этого — ложная дихотомия sysvinit vs systemd
                                                                    это легко объяснимо. раньше везде стоял сис5инит, теперь везде стоит системд, т.е. произошла массовая миграция с одного на другой. автор описывает этот процесс. с демонтулс на ранит никто не переходил и никакой трагедии не происходило, т.е. описывать нечего.
                                                                    Поклонники systemd, однако, такие поклонники.
                                                                    автор слегка разработчик фрибсд. видимо, его купили
                                                                    +2

                                                                    то, что systemd сложнее, чем init.d — это его недостаток, а не преимущество.

                                                                      +2
                                                                      Сложность в чем? Мы же прекрасно понимаем, что можно делать простые системы, которые потом обрастают дополнительными модулями и костылями, т.е. становятся сложными в эксплуатации, если юзкейсы выходят за рамки минимального функционала. Так и наоборот — существуют сложные системы, которые просты в эксплуатации. Это относится и к systemd, kubernetes и прочим новомодным штукам. Другой вопрос, что эти сложные системы иногда ломаются и тогда нужно уметь спускаться на нижние слои абстракции, чтобы уметь их чинить, но это нужно далеко не всегда )
                                                                        +7
                                                                        Он проще. Да сам по себе как софт systemd сложнее. Но вот с точки зрения всей инфраструктуры он проще. И проще он за счет большей сложности systemd. Достаточно хоть раз написать systemd unit и скрипт инициализации под один из дистрибутивов linux.
                                                                          –5

                                                                          run-скрипты daemontools/runit/s6 намного проще unit-файлов systemd.

                                                                            +1
                                                                            Скорее да, чем нет. Но можно ли в них удобно настраивать те же cgroups?
                                                                            Вопрос для личного образования, а не чтобы потроллить.
                                                                              –1

                                                                              Нельзя. По фичам daemontools и runit сильно отстают от systemd, в s6 фич намного больше и он старается внедрить многое из systemd но с правильной архитектурой, но поддержки cgroups нет и в s6, насколько я помню. Зато мы получаем cgroups из коробки в docker, и, как по мне, этого более чем достаточно — никогда не понимал зачем нужны cgroups для традиционных системных сервисов (ну т.е. приятно, когда они есть из коробки, спору нет, но вот реальной пользы я от них для системных сервисов ни разу не видел и не слышал о таком).

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

                                                                                я приводил кейс и могу повторить. Мы хотим распилить один большой мощный сервер на несколько задач, чтобы они не подрались за ОЗУ, за процессор, и при этом не хотим активировать своп (на сервере — mongodb, clickhouse, маленький postgres для метрик и куча http rest api).
                                                                                  –1

                                                                                  Я говорил про пользу для системных сервисов (syslog, ssh, vpn, dhcp, cron, dns, smtp, etc.). Всё остальное, нужное именно нашему проекту, запускается в докере, и там cgroups и лимиты есть.

                                                                                    +1
                                                                                    Я допускаю, что в этом случае достаточно CoreOS Container Linux в качестве хостовой системы. И не нужно никаких daemontools и runit…
                                                                                    0
                                                                                    Вообще в таком случае лучше пилить таки по контейнерам. Но лучше по нормальным, а не по docker. Банально проще администрировать.
                                                                                    +3
                                                                                    никогда не понимал зачем нужны cgroups для традиционных системных сервисов
                                                                                    это от нежелания ознакомиться с документацией по системд. они нужны например для того, чтобы можно было надежно остановить сервис, у которого форкаются процессы
                                                                                      –3

                                                                                      Можно узнать, какие из стандартных системных сервисов ведут себя таким образом? Не форкают вспомогательные процессы — таких хватает, а оставляют их после себя получив SIGTERM?


                                                                                      Кстати говоря, cgroups для решения этой проблемы обычно не требуется, если сервис работает под выделенным системным аккаунтом то можно убить все процессы этого юзера через pkill -u USER, но обычно достаточно убить группу процессов (все нормальные сервисы обычно вызывают setsid(2)) через kill -PID. Если же сервис запускается под root, не сделал setsid сам, наплодил процессы которые сделали собственный setsid, да ещё и не реализовал подчистку запущенных процессов при получении SIGTERM — может не надо таким системным сервисом вообще пользоваться?


                                                                                      Всё это и есть типичнейший пример подхода systemd "do more" вместо "do less", при котором дополнительным усложнением героически решается теоретическая проблема, которая на практике вообще не существует.

                                                                                        +4
                                                                                        можно убить все процессы этого юзера через pkill -u USER
                                                                                        нельзя, если они могут форкаться в это время, pkill не atomic
                                                                                        может не надо таким системным сервисом вообще пользоваться?
                                                                                        может не надо пользоваться супервизором процессов, который работает только если никто не делает резких движений?
                                                                                          +4
                                                                                          может не надо таким системным сервисом вообще пользоваться?
                                                                                          среди системных сервисов вы по собственной инициативе перечислили cron. а крон что делает? он форкает пользовательские задачи. любые. которые могут форкать все, что им взбредет в голову
                                                                                    0
                                                                                    Да ладно? Можно пример? Вот простейший пример для unit

                                                                                    [Unit]
                                                                                    Description=Test service

                                                                                    [Service]
                                                                                    Type=simple
                                                                                    ExecStart=/usr/bin/blalbla
                                                                                    ExecStop=/bin/kill -s SIGINT $MAINPID

                                                                                    [Install]
                                                                                    WantedBy=default.target


                                                                                    Это самый простой вариант.
                                                                                      –1

                                                                                      А вот практически то же самое для daemontools/runit/s6, файл ./run в каталоге сервиса:


                                                                                      #!/bin/sh
                                                                                      exec /usr/bin/blalbla 2>&1

                                                                                      Отличие в том, что при остановке сервиса убивать его будут через SIGTERM, а не SIGINT (вообще, SIGINT для сервисов, серьёзно???). В случае runit есть возможность изменить SIGTERM на SIGINT создав второй файл ./control/t:


                                                                                      #!/bin/sh
                                                                                      sv i .
                                                                                        +1
                                                                                        Ага только вот проблема. Что там у вас за sh? А от этого может сильно зависеть как будет отрабатывать ваш скрипт. Причем более того в дистрибутивах то они разные, что уж за другие юниксы говорить.
                                                                                        Выключать можно 100500 разными методами. Это пример из моего ближайшего шаблона, там надо такой посылать чтоб сервис убирал за собой сокет.
                                                                                          +1

                                                                                          У меня скрипты эти написаны на POSIX sh, отработает гарантированно на любой реализации /bin/sh любого дистрибутива. В ./run-файлах практически никогда не встречается сложной логики, а-ля скрипты init.d — там в 99% банально редиректы STDERR и exec в нужный сервис с нужными этому сервису аргументами командной строки. Иногда цепочка вспомогательных утилит делающих exec друг в друга для задания ограничений сервису, напр.:


                                                                                          #!/bin/sh
                                                                                          exec 2>&1
                                                                                          exec envuidgid tinydns envdir ./env softlimit -d400000 /usr/bin/tinydns

                                                                                          Это всё абсолютно портабельно, повода для паники нет.

                                                                                            –1
                                                                                            Даже в ubuntu? Даже в том случае если в место sh используется zsh? Проблема в том что там будет с /bin/sh заранее узнать нельзя да и вообще не должна такая утилита привязываться к shell хоть какому-то.
                                                                                              +1

                                                                                              Ещё раз. Медленно. Есть стандарт. POSIX-совместимые sh. Все используемые варианты шелла, которые можно обнаружить в качестве /bin/sh в любых дистрибутивах *NIX — являются POSIX-совместимыми. И этот стандарт поддерживает довольно много всего, так что вполне можно писать достаточно сложные sh-скрипты, которые будут работать везде (разве что кроме винды, да и то, сейчас и это уже не так очевидно).


                                                                                              Кстати, есть вспомогательные утилиты вроде checkbashisms, которые могут подсказать если случайно в скрипте использовали фичу не входящую в POSIX sh.

                                                                                                0
                                                                                                Все используемые варианты шелла, которые можно обнаружить в качестве /bin/sh в любых дистрибутивах *NIX — являются POSIX-совместимыми.

                                                                                                csh к примеру не является совместимым.

                                                                                                Дополнительно могут различаться пути расположение самих пакетов и т.п. Как итог сделать универсальный запускатель во всех возможных дистрибутивах может быть затруднительно, даже с systemd. Дополнительно напомню все дружно кладут на использование только POSIX-совместимых инструкций shell. Кучу раз эти грабли собирал уже.

                                                                                                Так что с портабельностью ровно те же проблемы что и sysvinit и многих других.

                                                                                                Я в свое время смотрел кучу разных init систем. Из нормальных которые реально удобно пользоваться и дают все необходимое ровно две это openrc и systemd. И да у openrc при этом свой отдельный обработчик сценариев как и systemd. Это позволяет не зависеть от того какой там shell стоит в конкретной системе и дополнительно ограничивает художества которые делают некоторые люди.
                                                                                                  –1

                                                                                                  Можете назвать хоть один дистрибутив, в котором csh/tcsh запускается как /bin/sh?


                                                                                                  Пути расположения действительно отличаются (потому что предложенный DJB /package так и не стал популярным), но какое это имеет отношение к данной дискуссии? Разве в unit-файле ExecStart работает как-то иначе?

                                                                                                    +1
                                                                                                    Можете назвать хоть один дистрибутив, в котором csh/tcsh запускается как /bin/sh?

                                                                                                    Админ может поменять. Внезапно ага.

                                                                                                    Разве в unit-файле ExecStart работает как-то иначе?

                                                                                                    В systemd можно прописать PATH и не указывать пути при запуске к примеру. Причем глобально это можно сделать.

                                                                                                    Насчет же дискуссии могу сказать, что в большинстве случаев администраторы банально не обладают должной квалификацией. По этой причине unit в systemd позволяет не отстрелить ногу с ходу вполне приличная штука.
                                                                                                      +1
                                                                                                      Админ может поменять. Внезапно ага.

                                                                                                      Не может — у него пол системы ляжет. А вообще он может сделать rm -rf /bin — и что, надо быть к этому готовым и иметь запасной набор бинарников в /var/tmp/резервный-bin/?


                                                                                                      В systemd можно прописать PATH и не указывать пути при запуске к примеру. Причем глобально это можно сделать.

                                                                                                      Не может быть! В обычных sh-скриптах тоже так можно! Ну надо же, как здорово, что в POSIX sh додумались включить такую продвинутую и уникальную фичу systemd.

                                                                                                        0
                                                                                                        В каждый скрипт прописывать будете?
                                                                                                          0

                                                                                                          Вы издеваетесь? Всегда есть место, куда можно прописать глобальное значение PATH по умолчанию. Например при использовании runit для запуска сервисов его обычно задают непосредственно перед запуском runsvdir — команды, которая запускает все сервисы, примерно так:


                                                                                                          #!/bin/sh
                                                                                                          PATH=/usr/local/bin:/usr/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin
                                                                                                          
                                                                                                          exec env - PATH=$PATH runsvdir -P /etc/service

                                                                                                          В этом случае все ./run-файлы будут видеть именно это значение PATH и никаких других переменных окружения по умолчанию у них не будет.

                                                                                                            +3
                                                                                                            И опять мы дружно делаем еще один sh скрипт. Да кстати еще один дополнительный момент, для настройки всего этого хозяйства требуется редактировать sh файл со всеми вытекающими. К примеру можно довольно легко сломать запуск. И это не шутка :)
                                                                                                      0
                                                                                                      Разве в unit-файле ExecStart работает как-то иначе?
                                                                                                      если «иначе» это «не зависит от /bin/sh», то да. чтобы запустить шелл из юнитфайла, надо запускать =/bin/sh ...., ну или =/bin/script.sh…
                                                                                                      я не думаю, что кто-то использует csh вместо шелла, но есть много других вариантов с разной степенью корявости. если вы протестировали свой скрипт в системе х, где /bin/sh это bash, он совсем необязательно будет работать в системе у, где это ash
                                                                                                        0

                                                                                                        "иначе" — это "не зависит от $PATH"


                                                                                                        Скрипт будет работать везде, если писать его без башизмов и контролировать это тулзой вроде checkbashisms.

                                                                                                          +2
                                                                                                          ExecStart= само по себе не использует $PATH, первое слово это полный путь к программе.
                                                                                                          вы регулярно приводите примеры скриптов, которые не будут работать на моей системе (т.к. запускают бинари, которых у меня нет), несмотря на отсутствие башизмов.
                                                                                                            –1

                                                                                                            Может это Вас шокирует, но Вы делаете ровно то же самое — приводите примеры unit-файлов, которые не будут работать на моей системе (т.к. для их выполнения нужен не установленный у меня systemd).


                                                                                                            И если Вы нажмёте на кнопочку "Показать ветку комментариев", то убедитесь, что я привожу эти примеры не потому, что утверждаю что они запустятся на Вашей системе, а в подтверждение моего утверждения в начале ветки:


                                                                                                            run-скрипты daemontools/runit/s6 намного проще unit-файлов systemd.
                                                                                                              +2
                                                                                                              системд идет в стандартной поставке мейнстрим дистров. если у вас лфс, то вы сами за себя и не ожидайте, что кто-то будет напрягаться

                                                                                                              И если Вы нажмёте на кнопочку «Показать ветку комментариев», то убедитесь, что я привожу эти примеры не потому, что утверждаю что они запустятся на Вашей системе, а в подтверждение моего утверждения в начале ветки:

                                                                                                              run-скрипты daemontools/runit/s6 намного проще unit-файлов systemd.

                                                                                                              у вас не выходит подтвердить это утверждение. получается только «нигде не работающие скрипты в простейшем случае ровно такой же сложности, как юнитфайл, но лишены всех его плюшек»
                                                                                                                0

                                                                                                                У меня Gentoo. Плюс из популярных без systemd есть ещё как минимум Devuan, Arch и Slackware. А вообще список достаточно большой: http://without-systemd.org/wiki/index.php/Linux_distributions_without_systemd

                                                                                                                  +1
                                                                                                                  Про Arch не надо. Это как минимум не соответствует действительно, иначе зачем арчеводы сделали страничку — wiki.archlinux.org/index.php/Systemd_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9)
                                                                                                                  По-вашему, это благотворительность? Т.е. они пишут статьи для пользователей других дистрибутивов?
                                                                                                                  Давайте сойдемся на том, что есть дефолтная конфигурация дистрибутива и кастомная.
                                                                                                                  Насчет Slackware вообще не в курсе — его еще не похоронили?
                                                                                                                  Т.е. реально из Вашего списка только Devuan строго не systemd-дистриб.
                                                                                                                +2
                                                                                                                Проще. Но есть нюансы.
                                                                                                                Как предлагаете делать systemd-analyze critical-chain, например?
                                                                                                                Если я, например в userspace что-то разрабатываю, как мне сделать такое? Startup finished in 1.297s (kernel) + 2.825s (initrd) + 8.695s (userspace) = 12.818s
                                                                                                                  –3

                                                                                                                  Вы не поверите, но у меня за всю загрузку системы отвечает ровно один sh-скрипт размером 200-300 строк. Пример этого скрипта Вы можете найти в статье Как загружается Linux в разделе "Startup: /etc/runit/1".


                                                                                                                  Так что при желании измерить этот "userspace" можно тупо вписать несколько строк date между любыми этапами загрузки (они все в виде вызовов функций перечислены в конце скрипта). И, будем откровенны, насколько часто и насколько большому количеству разработчиков нужно замерять это время — и стоит ли их удобство в эти моменты установки systemd, со всеми его уязвимостями и "особенностями", большинству обычных юзеров?

                                                                                                                    +1
                                                                                                                    Так у вас там в первых двух строках прекрасное и можно дальше уже не читать.
                                                                                                                    Всё в одном файле — при обновлении приложений практически невозможно автоматически обновить код инициализации этого приложения. Например, когда обновляется ALSA, то пакет может просто заменить файлы /etc/init.d/alsasound, /etc/conf.d/alsasound, /etc/modules.d/alsa. А в моём случае админу нужно будет ручками править /etc/runit/1.
                                                                                                                    Нет поддержки всего на свете

                                                                                                                    Ну и сколько вы эти шашечки рисовали? А если надо будет поставить вдруг pulseaudio? Шашечки хорошо, но когда ехать-то?
                                                                                                                    Если я захочу заняться разработкой под андроид, например?
                                                                                                                    Что мне работодателю сказать, извини, дружок, через три месяца начнем, мне тут надо все запустить сначала?
                                                                                                                    Вы сейчас спрашиваете, какое количество разработчиков занимается профилированием и насколько часто они это делают. Я правильно понял? Этим занимаются все нормальные разработчики и всегда. По полгода пилят софт, чтобы полсекунды выйграть.
                                                                                                                      –1

                                                                                                                      Шашечки рисовал некоторое время. Это был интересный проект для саморазвития и изучения процессов, которые происходят при загрузке системы. Так что время не жалко.


                                                                                                                      Но любопытный факт в том, что на поддержку этого у меня за 15 лет ушло до смешного мало времени, хотя за это время много чего изменилось. При этом эти скрипты за 15 лет использовались на некотором количестве десктопов и серверов, причём не только мной. В общем, это только выглядит страшно, а на практике работает весьма неплохо.


                                                                                                                      При этом надо отметить, что в случае каких-то проблем при загрузке этот подход позволяет найти и исправить проблему практически моментально, потому что весь выполняющийся при загрузке код максимально краткий, простой и очевидный — при этом отладка аналогичных проблем в sysvinit, OpenRC и systemd требует намного больше времени и усилий, потому что там задействовано намного больше кода, файлов, конфигов, а в случае systemd ещё и сложных и местами глючных (или скажем политкоректнее "с не всегда очевидным поведением") инструментов.


                                                                                                                      Вы сейчас спрашиваете, какое количество разработчиков занимается профилированием и насколько часто они это делают.

                                                                                                                      Нет, я спрашивал о профилировании кода, выполняющегося при загрузке системы. Что касается профилирования обычных прикладных приложений/сервисов — я не понимаю, какое вообще отношение к их профилированию может иметь systemd, для этого существуют намного более практичные штатные инструменты.

                                                                                                                        +3
                                                                                                                        Например, какие такие штатные инструменты позволяют оценить, сколько твоя программа отожрала при загрузке времени, в целом и в интеграции с другими сервисами?

                                                                                                                        300 строк — это максимально краткий, простой и очевидный код? А по пять строк юниты — это код сложный и запутанный, ну акей. Пока вы саморазвиваетесь в интересных проектах, люди деньги хотят зарабатывать. Если сравнить это с такси, никому ваше такси не будет интересно, если вы приедете через месяц после заказа, с криками, смотрите какие я тут шашечки нарисовал. Для себя ок, прикольно, не спорю, хотя есть и поприятнее занятия, как по мне. Но какой в этом business value?
                                                                                                                          –2
                                                                                                                          Например, какие такие штатные инструменты позволяют оценить, сколько твоя программа отожрала при загрузке времени, в целом и в интеграции с другими сервисами?

                                                                                                                          Для анализа работы сервисов специально придумали логи и метрики — моя программа обычно выводит такую информацию в них.


                                                                                                                          Сколько времени мой сервис запускается в условиях когда одновременно запускаются вообще все сервисы — мне обычно не интересно, частично потому что такое случается только при редких перезагрузках серверов (а сервисы обычно обновляются/перезапускаются по одному), и частично потому что этой информацией сложно воспользоваться для чего-то полезного (она не покажет какой сервис нуждается в оптимизации). Но если вдруг мне это станет интересно — время затраченное на полную перезагрузку сервера и запуск всех сервисов легко увидеть на тех же метриках.


                                                                                                                          К слову говоря все данные systemd относятся к текущему серверу, а современные сервисы гораздо чаще всё-равно разворачиваются на кластерах, и статистику хочется смотреть по всему кластеру, а не по отдельному серверу — и для этого метрики намного удобнее systemd.


                                                                                                                          300 строк — это максимально краткий, простой и очевидный код? А по пять строк юниты — это код сложный и запутанный, ну акей.

                                                                                                                          300 строк на sh у меня делают то, что делает значительная часть кода самого systemd плюс значительная часть unit-файлов, которые systemd выполняет при загрузке системы (исключая те unit-файлы, которые запускают обычные сервисы вроде ssh/vpn/etc. — аналог этих unit-файлов у меня в ./run-файлах, тоже которые занимают меньше строк).


                                                                                                                          В общем, Ваша цитата это очередная попытка сравнивать тёплое с мягким, довольно типичная для любителей systemd — хотя никак не могу понять, почему это настолько распространённая проблема…


                                                                                                                          Но какой в этом business value?

                                                                                                                          Я получил простую и очень надёжно работающую систему, требующую минимум времени на поддержку. С успехом использую её 15 лет, на своём десктопе и десктопах нескольких друзей, плюс на серверах кучи проектов в которых я участвовал до появление докера (с докером что стоит на хосте стало намного менее принципиально), и пока что не вижу причин от неё отказываться — все известные мне альтернативы работают менее надёжно и/или требуют больше усилий на поддержку, а их основные достоинства в том, что они более популярны и/или поддерживают не нужные лично мне фичи. Так что business value в том, что я за 15 лет сэкономил кучу времени и нервов.

                                                                                                                            +1
                                                                                                                            У вас в разных комментариях взаимоисключающие утверждения.
                                                                                                                            Я получил простую и очень надёжно работающую систему, требующую минимум времени на поддержку

                                                                                                                            Что может быть минимальнее, чем
                                                                                                                            dnf upgrade
                                                                                                                            , например.
                                                                                                                            А вот тут вообще песня.
                                                                                                                            Да, в списке процессов болтаются всякие самозапустившиеся «сервисы» вроде /usr/libexec/gvfs-udisks2-volume-monitor, /usr/libexec/udisks2/udisksd, gpg-agent, /usr/libexec/dconf-service etc. без нормального runit-супервизора. Это немного раздражает, но без веских причин, скорее просто по принципу «потому что тишина должна быть в библиотеке!». По факту у них просто собственный жизненный цикл, кто-то их автоматом запустил когда они понадобились, и если они крешнутся, то этот кто-то их и перезапустит когда они снова понадобятся.


                                                                                                                            Ну да ладно. Вас уже не в ту степь понесло.
                                                                                                                            Какие-то метрики уже появились. Причем тут метрики и
                                                                                                                            процесс загрузки системы?
                                                                                                                      +2
                                                                                                                      у меня за всю загрузку системы отвечает ровно один sh-скрипт
                                                                                                                      т.е. ваша система не живет в динамичном мире, в котором живут все остальные. в реальном мире набор запущенных сервисов не определяется жестко одним скриптом, а реагирует динамически на меняющиеся внешние условия
                                                                                                                        0

                                                                                                                        Этот скрипт не запускает никаких сервисов, он отвечает за необходимую инициализацию системы перед тем, как runit параллельно запустит все сервисы. Сами сервисы запускаются практически однострочными ./run-файлами, как Вы видели в примерах, и никакой проблемы в процессе работы запускать новые сервисы или останавливать/удалять/перезапускать/обновлять работающие нет.

                                                                                                                          +2
                                                                                                                          значит, этот скрипт не сможет вам сказать «Startup finished in 1.297s (kernel) + 2.825s (initrd) + 8.695s (userspace) = 12.818s», потому что в userspace входит запуск всех сервисов параллельно
                                                                                                                      +1

                                                                                                                      «это не нужно», конечно же

                                                                                                      +1
                                                                                                      Иногда цепочка вспомогательных утилит делающих exec друг в друга для задания ограничений сервису, напр.:

                                                                                                      #!/bin/sh
                                                                                                      exec 2>&1
                                                                                                      exec envuidgid tinydns envdir ./env softlimit -d400000 /usr/bin/tinydns

                                                                                                      а покажите цепочку, которая настраивает несколько приватных маунтов, мне такое часто надо
                                                                                                      ну и кстати, /bin/sh не делает ваш скрипт посикс совместимым, в моей посикс совместимой системе нет ни envuidgid, ни envdir. в этом и польза стандартизации системд
                                                                                                      Это всё абсолютно портабельно
                                                                                                      см выше. по сравнению с системд это все абсолютно непортабельно
                                                                                                        –1

                                                                                                        У меня этот run-файл не менялся с начала 2000-х, когда я ещё использовал daemontools. Сейчас использую runit, а с ним в комплекте идёт утилита chpst, которая умеет делать всё то же самое, что и этот конвейер. Иными словами, если пишется ./run-файл для runit, то в нём гарантированно можно использовать chpst для этих целей, а если он пишется для daemontools — то можно использовать вышеупомянутые утилиты.


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


                                                                                                        Приватные маунты это прекрасно, но речь идёт о системных сервисах — кому из них нужны приватные маунты? А не системные сервисы запускаются в докере, где приватные маунты доступны.

                                                                                                          +4
                                                                                                          Иными словами, если пишется ./run-файл для runit, то в нём гарантированно можно использовать chpst для этих целей, а если он пишется для daemontools — то можно использовать вышеупомянутые утилиты.
                                                                                                          а если пишется юнитфайл, то в нем гарантировано можно использовать синтаксис юнитфайлов. и это будет работать на любом мейнстрим дистре, в отличие от ранита и демонтулс
                                                                                                          Что касается совместимости с POSIX sh, то она не требует ограничиваться в sh-скрипте исключительно командами включёнными в POSIX, иначе вообще практически ни один скрипт не может считаться совместимым.
                                                                                                          почему? посикс описывает набор утилит. все остальное — это зависимость не на посикс, а на что-то другое.
                                                                                                          Приватные маунты это прекрасно, но речь идёт о системных сервисах — кому из них нужны приватные маунты?
                                                                                                          всем нужны, чтобы не видеть лишнего. но я строчку попросил не для системных сервисов(т.к. это умеет системд), мне и в простых скриптах надо
                                                                                                    0
                                                                                                    А вот практически то же самое для daemontools/runit/s6, файл ./run в каталоге сервиса:

                                                                                                    #!/bin/sh
                                                                                                    exec /usr/bin/blalbla 2>&1

                                                                                                    Отличие в том, что при остановке сервиса убивать его будут через SIGTERM, а не SIGINT
                                                                                                    ну т.е. совсем не то же самое. чтобы убивать через сигтерм, в оригинальном примере достаточно удалить строку, он по дефолту так убьет. а не по дефолту (как в примере) делается одной простой строкой. но это не все отличия. в примере юнитфайла есть описание, в вашем примере никакого описания нет(нет, строка комментария не подойдет, описание из юнитфайла доступно программно для запущенных сервисов). в примере юнитфайла указано, куда этот сервис встраивается в дерево зависимостей, в вашем примере этого нет. и сделать это одной строкой нельзя. в примере юнитфайла автоматически работает огромное количество дефолтных плюшек, которых в вашем примере нет, потому что вы не слышали о пользе cgroups и т.д.
                                                                                                      +2
                                                                                                      Основная фишка в том что это декларативный подход, а не императивный как в случае с использованием sh скриптов.
                                                                                                        +1
                                                                                                        да, но, что характерно, фанаты шелл скриптов могут все имеративно вставить в ExecStart=/bin/sh -c '...'. а наоборот — нет
                                                                                                          0
                                                                                                          Но зачем?
                                                                                                            0
                                                                                                            я не знаю, зачем люди настаивают на необходимости писать скрипты, я только заметил, что их такой возможности никто не лишал
                                                                                                        –1
                                                                                                        чтобы убивать через сигтерм, в оригинальном примере достаточно удалить строку, он по дефолту так убьет

                                                                                                        В моём примере достаточно удалить файл ./control/t и он тоже по дефолту убьёт через SIGTERM — и, честно скажу, файл всегда удалить проще, чем строку.


                                                                                                        а не по дефолту (как в примере) делается одной простой строкой.

                                                                                                        А не по дефолту делается одним простым файлом из, по сути одной строки (если не считать #!/bin/sh).


                                                                                                        в примере юнитфайла есть описание, в вашем примере никакого описания нет(нет, строка комментария не подойдет, описание из юнитфайла доступно програмно для запущенных сервисов)

                                                                                                        Это правда, но лично мне всегда хватало имени сервиса чтобы с ним работать, можно узнать почему Вам его недостаточно и как в этой ситуации помогает длинное описание?


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

                                                                                                        А это потому, что ни в daemontools ни в runit нет зависимостей. И, Вы не поверите, но они там нафиг не нужны — если какому-то сервису при старте не хватило какой-то зависимости (поскольку он случайно запустился раньше неё), то он тупо пишет в лог "ой", падает, и runit через секунду его перезапускает, что полностью решает проблему. В s6 зависимости есть, но на практике их отсутствие в runit никогда не создавало проблем, так что переходить ради зависимостей на s6 я пока не вижу смысла.


                                                                                                        и сделать это одной строкой нельзя.

                                                                                                        Вообще-то в s6 зависимость указывается именно одной строкой.


                                                                                                        в примере юнитфайла автоматически работает огромное количество дефолтных плюшек, которых в вашем примере нет, потому что вы не слышали о пользе cgroups и т.д.

                                                                                                        Я прекрасно знаю о пользе cgroups, просто я не вижу реальной пользы от cgroups на практике для системных сервисов — а все остальные, для которых польза безусловно есть, я запускаю в докере.

                                                                                                          +1
                                                                                                          честно скажу, файл всегда удалить проще, чем строку.
                                                                                                          вы не с той стороны заходите. я имел в виду, что по дефолту этой строки нет, а если хочется, то можно добавить строку. что проще, чем добавить файл(нет, это делает не админ в командной строке, а разработчик сервиса в редакторе)
                                                                                                          делается одним простым файлом из, по сути одной строки (если не считать #!/bin/sh).
                                                                                                          вам дали избыточный пример, который дает повод для критики непосвященным. в юнитфайле можно точно так же из одной строки(если не считать [Service]):
                                                                                                          [Service]
                                                                                                          ExecStart=/usr/bin/blalbla
                                                                                                          я посчитал, это одинаковое количество символов с вашим скриптом. только тут на самом деле огромное количество фич включено по дефолту
                                                                                                          как в этой ситуации помогает длинное описание?
                                                                                                          понятнее вывод systemctl list-units? но, как мы уже выяснили, если вам не надо описание, вы его можете не писать. а если надо, то вам поможет только юнитфайл
                                                                                                          И, Вы не поверите, но они там нафиг не нужны
                                                                                                          не поверю, потому что я знаю, зачем они нужны. если, к примеру, у вас есть сервис, которому нужна база данных, то в системд он явно указывает зависимость. если вы не будете запускать сервис(а с сокет активейшн это превращается в «не будете пытаться коннектиться клиентом), то и базу данных никто запускать не будет(в отсутствие других клиентов базы данных). а как только понадобится запустить сервис, он стартанет и базу данных. все устаревшие альтернативы(включая апстарт с ивентами) вынуждены в такой ситуации просто сходу стартовать все, что в принципе установлено в систему, даже если оно может понадобиться только в следующее полнолуние, а может и не понадобиться вовсе
                                                                                                          Вообще-то в s6 зависимость указывается именно одной строкой.
                                                                                                          как это помогает раниту и демонтулс?
                                                                                                          я не вижу реальной пользы от cgroups на практике для системных сервисов
                                                                                                          хттпд — системный сервис? полезно ли на практике точно прибить его вместе со всеми форкающимися цги? „я не вижу пользы“ не всегда свидетельствует об отсутствии пользы, иногда это отсутствие знаний и вообще это странный аргумент против чего-то, в чем все остальные пользу видят
                                                                                                            –1
                                                                                                            хттпд — системный сервис?

                                                                                                            Нет. Системные — те, которые нужны для обслуживания системы, а не прикладных задач юзера вроде веб-сайта компании: acpid, agetty, atd, cups, cron, dhcpd, dns, syslog, mcelog, vpn, smtp, ssh, ну и docker.


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

                                                                                                            Ну так расскажите, какие конкретно реальные проблемы с любыми из вышеупомянутых сервисов помогут решить cgroups?

                                                                                                              +1
                                                                                                              почему перечисленный список сервисов чем-то важнее других(особенно, в контексте убивания сервиса)? откуда уверенность, что никто из этого списка не использует форк?
                                                                                                              я уже несколько раз повторил: есть надежный способ убить все процесссы в сигруппе, нет надежного способа убить произвольное дерево процессов, которые в этот момент могут форкаться
                                                                                                                –1

                                                                                                                Окей, повторю основную мысль ещё раз: systemd делает много ненужного, решает не существующие на практике проблемы, и за всё это приходится платить очень высокую цену (включая уязвимости в настолько критичной части системы).


                                                                                                                Дальше идёт разбор конкретных фич, например cgroups, и мы пытаемся определить нужные они или нет. Вы утверждаете, что это крайне нужные и полезные фичи. Я утверждаю, что если использовать сервер определённым образом (запуская все наши прикладные сервисы вроде http и DB) в докере, то пользы от cgroups в systemd нет, поскольку под управлением systemd остаются только системные сервисы (вроде перечисленных мной выше), у которых тупо нет проблем, которые надо решать через cgroups. При этом я нисколько не спорю с полезностью cgroups, просто в моём случае я получаю управление cgroups через docker, а не systemd.

                                                                                                                  +2
                                                                                                                  основная мысль состоит в том, что системд делает много нужного и решает существующие на практике проблемы, именно поэтому специально обученные люди, занимающиеся сервисами в мейнстрим дистрибутивах, перешли на него.
                                                                                                                  громкая критика системд слышна только от дилетантов, которые плохо разбираются и в сервисах в целом и в системд в частности.
                                                                                                                  кстати, раз уж он не в первый раз всплывает, рокет — сила, докер — могила.
                                                                                                                  и это, давно докер стал портабельным за пределы линуха(основной аргумент против сигрупп)?
                                                                                                                  и про уязвимости
                                                                                                                    –1

                                                                                                                    Да, уязвимости докера меня лично сильно беспокоят. Но тут такое дело, по факту выбор ведь не между docker и systemd, а между systemd+docker или runit+docker — и второй вариант очевидно содержит намного меньше уязвимостей.


                                                                                                                    Что касается k8s и прочих альтернатив докеру — не имею ничего против, в контексте данной дискуссии абсолютно всё-равно какой инструмент используется для управления контейнерами и cgroups для контейнеров, вопрос в том есть ли какая-то реальная польза для cgroups для системных сервисов, или нет.

                                                                                                                      +2
                                                                                                                      в системд есть встроенная поддержка неймспейсов. плюс с ним идет systemd-nspawn, так что докер необязателен. и вопрос исключения сигрупп ради портабельности никак не обработан
                                                                                                                        +2
                                                                                                                        Для embedded, иногда даже для серверов еще можно оправдать легковесные разного рода супервизоры и иниты.
                                                                                                                        А как десктоп системы запускать в данной парадигме?
                                                                                                                        Писать простыни шелл скриптов — так уже проходили это, отказались. Эволюционировали дальше, опять отказались, родили системд.
                                                                                                                        Вы предлагаете вернуться к простыням обратно? А зачем? Чтобы безопаснее было?
                                                                                                                        Fedora, десктоп, 30% запущенных сервисов задетачены, мне для них что надо, баш скриптами врапперы писать? А зачем?
                                                                                                                          –3

                                                                                                                          Не совсем понял, о каких таких специфичных для десктора простынях скриптов речь.


                                                                                                                          У меня 15 лет дома на десктопе runit. Да, в списке процессов болтаются всякие самозапустившиеся "сервисы" вроде /usr/libexec/gvfs-udisks2-volume-monitor, /usr/libexec/udisks2/udisksd, gpg-agent, /usr/libexec/dconf-service etc. без нормального runit-супервизора. Это немного раздражает, но без веских причин, скорее просто по принципу "потому что тишина должна быть в библиотеке!". По факту у них просто собственный жизненный цикл, кто-то их автоматом запустил когда они понадобились, и если они крешнутся, то этот кто-то их и перезапустит когда они снова понадобятся. А если выключить Xorg, то они все будут убиты автоматом. В отличие от системных сервисов, которыми я нередко управляю вручную через runit, нужды вручную управлять этими "сервисами" у меня пока не возникало.

                                                                                                                            +1
                                                                                                                            Самозапустившиеся, кто-то их автоматом запустил
                                                                                                                            , это как вообще?
                                                                                                                            Я еще хотел спросить, как реализовать планирование, например, сервис А запускается после сервиса B, до запуска сервиса C, но только если стартанул сервис Z, но пожалуй пусть это будет риторический вопрос.
                                                                                                                            В свое время только один инит скрипт, например для zookeeper, был строк под 200. Писало его человек 10 в общей сложности. Сколько времени убили, уйму просто. А могли бы зоокипер пилить вместо этого. Сейчас файл занимает пять строк и понятен любому человеку, а не только аутисту.
                                                                                                                              –3

                                                                                                                              Сейчас чтобы запустить сервис типа zookeeper не нужен файл и на 5 строк, достаточно docker run --name some-zookeeper --restart always -d zookeeper.

                                                                                                                                +1
                                                                                                                                Да, вот только чтобы докер заработал, надо дофига всего при загрузке проинитить. Настроить сеть, настроить оверлей, выделить сторадж, прикрутить iptables, поднять d-bus, поднять логгирование, разобраться с race condition при всем этом.
                                                                                                                                А только потом запустить в докере zookeper, не забыв указать ему переменные окружения. А потом разработчик с соседнего отдела приходит и говорит, там это, баг у нас походу, давай попробуем сменить файлуху вот тут в сервисе на reiserfs, например. Только тут надо на 300 машинах, там половина центос 6,8, вот тут вообще опенвз стоит, тут вот центос обновили, но не до конца. А вот тут машина грузится долго, нам полсофта надо переписывать, че за хрень? А ты ему, щас погоди, чувак, давай через неделю другую приходи, следующие спринтов 10 твои, мне тут свой суперинит поправить надо.
                                                                                                                                Есть серверы, где докер, например, не заработает, тут как быть? Например, там убунта, в которой уже выпилили апстарт. И которую обновить нельзя, там кривой aufs с проблемами с dir permissions + отключен коннтрак.
                                                                                                                                Мир он такой, многогранный. Именно поэтому там существует и runit, и upstart, и по старинке, и systemd одновременно. Если вам чего-то тут не нравится или не надо, всегда найдется несколько сотен тысяч человек, которые думают по-другому.
                                                                                                                                  +3
                                                                                                                                  это подмена понятий. файл нужен, просто он уже в образе докера. точно так же, как и юнитфайлы уже есть в системе, достаточно systemctl start zookeper. что, кстати, короче заклинания для докера
                                                                                                                                  0
                                                                                                                                  Я еще хотел спросить, как реализовать планирование, например, сервис А запускается после сервиса B, до запуска сервиса C, но только если стартанул сервис Z, но пожалуй пусть это будет риторический вопрос.

                                                                                                                                  пардон, докер это вообще не про это. Даже если вы упакуете все сервисы в докер, то такую цепочку в нем не реализовать. Только если не привлекать сторонние утилиты. docker-compose? Увольте, он ничего сложного не умеет. Получается опять возвращаемся ЛИБО к оркестрации (кубики+ансиблы и прочее), ЛИБО к systemd, но тезис коллеги выше в том, что если есть systemd, то докер уже не нужен, т.к. первый все уже умеет (изоляция, разделение ресурсов и much more). Паковать docker-контейнеры в systemd юниты можно, но при этом теряется часть прелестей самого systemd + много бойлерплейта.
                                                                                                                                    0
                                                                                                                                    Так это и не про докер кейс. Это про инит в целом.
                                                                                                                                    что если есть systemd, то докер уже не нужен,

                                                                                                                                    Это вы откуда такое утверждение взяли? Было утверждение, что systemd использует cgroups и этому есть свои причины, которые вам и привели неоднократно. Из-за этого, в том числе, использование докера необязательно, если вам нужны только cgroups.
                                                                                                                                    Докер же — это не просто cgroups, это целый комбайн, там еще куча всего дополнительно намешано.
                                                                                                                                      0
                                                                                                                                      Было утверждение, что systemd использует cgroups и этому есть свои причины, которые вам и привели неоднократно

                                                                                                                                      И что? Пускай использует. Я не против.
                                                                                                                                      Из-за этого, в том числе, использование докера необязательно, если вам нужны только cgroups.

                                                                                                                                      Эм. По факту из всего вышеперечисленного докер решает только две задачи:
                                                                                                                                      1. пакетирование приложений и их доставка. systemd это не умеет. Но это умеют системы SCM + пакетные менеджеры (последние есть во всех современных дист-х)
                                                                                                                                      Ну, и все равно настраивать среду под докер и как-то инициировать стягивание новых версий образов нужно (scm?)
                                                                                                                                      2. изоляция окружений. Т.е. чтобы не было взаимовлияния. Потому что держать те же несколько версий php/python на одной машине — кошмар. И, да, докер с этим справляется хорошо. Другой вопрос — а нужно ли это всегда.
                                                                                                                                      Все остальное — автоперезапуск сервиса, зависимости между сервисами, ограничение по процу/памяти и пр. — systemd прекрасно отрабатывает.

                                                                                                                                      Лучше скажите — что Вы планируете делать для совмещения докера и systemd? Ну, предположим, что докер-контейнеру нужен маунт нфс, т.е. уже нужно зависимости между разными сущностями строить.
                                                                                                                                        +1
                                                                                                                                        Еще раз.
                                                                                                                                        Утверждения были такие.
                                                                                                                                        1. systemd умеет cgroups. Зачем это нужно, уже указали, не раз. В ответ на это наш коллега с «простой и понятной системой» с инит скриптом из 300 строк заявил, что ему это не надо, есть вот же докер, что еще надо.

                                                                                                                                        На вопрос, что делать, когда докер по разным причинам запустить вдруг нельзя, наш коллега тактично отвечать не стал.
                                                                                                                                        2. Докер не замена иниту и инит не замена докера.
                                                                                                                                        Хотя наш коллега с «простой и понятной системой» и думает иначе.
                                                                                                                                        Я знаю что такое докер, я ничего не планирую делать для совмещения systemd и докера. Зачем бы мне это надо было?
                                                                                                                                  +2
                                                                                                                                  У меня 15 лет дома на десктопе runit
                                                                                                                                  у меня в течение бОльшего времени дома на десктопе то, что идет с дистрибутивом. процесс написания скриптов/юнитфайлов аутсортится разработчикам дистрибутива. никакого беспокойства по поводу «скриптов обижают» не испытываю
                                                                                                                                    0
                                                                                                                                    процесс написания скриптов/юнитфайлов аутсортится разработчикам дистрибутива

                                                                                                                                    я честно скажу, что они это плохо делают, что для обычных инит-скриптов, что системд-юнитов. Возможно даже проблема не в разработчиках дистрибутивах как таковых (они попросту не могут знать специфику всего ПО), а в разработчиках конкретного приклада, который включается в дистрибутив. Но все равно от этого не легче.