> Systemd -- это именно что об изменении подхода к администрированию одного конкретно взятого хоста.Я полностью с этим согласен.
> Если бы мы говорили об администрировании машин пачками, мы бы говорили о
> Puppet/Chef/SaltStack/Ansible. Все эти инструменты не утратили своего значения
> с приходом systemd.
Они не утратили. Но:
1) Теперь и одна система в чистом виде достаточно внятно администряема. И не надо убивать 2 дня чтобы понять ее состояние и проблемы, хотя-бы в первом приближении. Так что какой-ниюудь road warrior окучивающий вдску мелкой конторы с сайтом-визиткой вздохнет капельку свободнее. А в твоем сценарии это вообще не должно было существовать, да?
2) По минимуму некая ремотная/групповая фичность просматривается даже у тулсов системды. Оно как бы всего лишь поверх ssh, а для автоматизации баш, но для небольших инсталляций выглядит логичным вариантом. И позволяет плавно перейти от управления 1 хостом к небольшой группе, при том на основе в общем то юниксвэйных тулсов, что самое смешное. И без убер-энтерпрайзятины, неподъемной в мелких инсталляциях.
3) Наличие апи у системы таким тулзам может как максимум упростить и облегчить жизнь, так что они постепенно вместо глюкокодинга своих костылей неизвестного качества и глючности научатся брать состояния и логи из системды. И один раз разобраться в закидонах одного management core еще реально. А 20 раз в 20 разных инструментах - фигвам, mission impossible, всгда будут дурные взбрыки.
4) У поцтера просматривается хоть какая-то попытка сделать подложку под групповой управлятор, но при том - чтобы оно неплохо менеджилось даже в виде 1 машины. И это весьма милая фича. Это проипали его конкуренты, а напрасно, как на мой вкус. Здорово придумано как по мне.
> Опсы и девопсы пользуются этими инструментами и по сей день.
> И нам абсолютно наплевать, что вы там за init в бэкенде поставили.
Зато разработчикам таких софтин в долговременном плане апи здорово удобнее будет, имхо, и избавит их от прорвы глюкокодинга. Тем кто систему компонует тоже лишний раз попроще будет, пожалуй.
> Поэтому ещё раз: как вся эта белиберда о скоростном развёртывании кластера относится к systemd?
Общая идея похожа: максимум результата при минимуме возни. Системдшный юнит по сравнению с инит скриптом - именно об этом. Вызов апи вместо выдиранию по крупицам состояния самому - именно об этом. Централизованный системный лог с апи - именно об этом.
> Конкретно для администрирования одного хоста -- systemd не решил ни одной проблемы,
Для меня - решил и довольно много, а именно проблем, именно с системд... ух, как максимум он помог поймать мне проблему с рандомом, но она была вообще в кернеле, а системд ее лишь запалил своими диагностическими тулзами, показавшими что юнит заглыхает на цать секунд без понятной на то причины. Ну вот тут к нему и пришел трассир. Так что неплохо бы уточнить что не решил - у тебя. А у меня - решил.
> но привнёс много новых, о чём мы и пишем в каждой новости, где речь заходит о systemd.
При том как-то старательно игноря обратные примеры и поливая всех кто их приводит. Очень объективно, чо :)
> Поэтому второй вопрос: каким боком оно "ориентировано на результат"? Хвостом, что ли?
Ну вот таким - лично мне стало гораздо проще и быстрее состояние системы оценивать, да и свои кастомные юниты я как-то сильно быстрее запиливаю. А если так сразу не запускается - я довольно быстро понимаю где накосячил. Без кодинга гадских костылей для логинга очевидных вещей и прочей левой мусорной активности по сути не относящейся к делу. Да, я ленивый и вмне впадлу дописывать всем логинг выхлопа программы в stdout, stderr и прочие коды возврата. А родные скрипты что-то такое удосуживаются делать спасибо если в 1 случае из 10.
