Какие системы администрирования систем вы используете?
Уважаемые сисадмины! Я подрабатываю в институте, где собираются в ближайшее время сменить ZenWorks на что-то из этого списка. В связи с этим вопрос, скорее, статистического характера: кто чем пользуется для администрирования систем?
@kenny_opennix сложно дебажить (правда, cfe ещё сложнее, да), можно прострелить себе ногу.
Не императивен - откатиться на предыдущую конфигурацию с гарантией нельзя.
Ну и в целом медленный (сама серверная часть - не помогут и мануалы про "если у вас стало больше десяти хостов"). Возможно, на десятке машин всё будет и хорошо, но на сотне-двух там уже ад и содомия происходит. Кластеризуется тяжело.
не правы вы. прекрасно все дебажется, прекрасно отдается под контроль версий. Я проливаю ферму из несколько 10 серверов, может вы просто не пробовали делать инклуды и разносить все рецепты по классам? Вы приведите конректные примеры где он неудобен, и в чем затыки. Пока я вижу только слова.
@kenny_opennix VCS не помогут вам откатить конфигурацию, если в новой конфигурации был создан новый файл/новый пользователь.
Если у нас кто-то и использует паппет - то только в своём маленьком уголке из сотни хостов. На широкую ногу - никто.
опять же вы не правы, google использует. Вы как-то галословно говорите не приводя никаких доводов, Вы попробуйте к примеру сделать рецепты инстансов и после этого говорите или допустим управлять обширной фермой, у меня получается.
@kenny_opennix я вам выше пример привел. Откатитесь после того, как создали файл.
Ну и создайте кластерок на 100 машин, которые каждую минуту-две дергают puppet. И посмотрите, как быстро он будет работать. Само собой, с боевым набором рецептов.
легко ensure => absent, и filebucket
А потом сделайте анонс заново.
У меня под папетом более 100 машин уже несколько лет, переходил с шефа, а то что вы говорите это мягко говоря не правда.
@kenny_opennix то, что вы написали, называется не "откатить конфигурацию", а "переписать так, чтобы вернуло всё в зад".
Когда над кластером работает человек 5 или количество выкладок в день зашкаливает за 2 десятка - такой метод совершенно не применим. Если что-то сломается - слишком много времени уйдет на исправление. А если нужно будет откатиться на состояние "утром" после масштабных работ - то вы вообще с ума сойдете, проще переналить всё будет. Правильно собранные же пакеты (по debian policy, например) легко откатываются взад-вперед (и уже неважно чем - хоть тем же паппетом).
Ну и ваш метод работы с CMS сильно напоминает "мне лень писать sh-скрипты, я не хочу придумывать, как их деплоить". В принципе, здравая мысль (придумывать как их деплоить - та ещё работка), разве что менять повсеместный shell на ruby (да и ещё не сам ruby, а какой то мета-язык, основанный на ruby) для админов - не ахти какое полезное решение, если человек шелла не знает. Но стоит понимать, что вы не конфигурацию пишете, а именно что скрипты, которые что-то делают по очереди. А при втором запуске проверяют, что всё осталось в том же состоянии. Вот и всё.
В общем, спорить с вами бесполезно. Вас не переубедить (ну или мне лень), меня тоже - я на эти системы менеджмента конфигураций, которые конфигурации на самом деле не манагерят, уже насмотрелся.
Вы неадекватны. Я деплою вещательные сервера. Несете чушь и приписываете мне что я не говорил. Хватит ересь нести и не пудрите людям мозги. Причем по теме вы не предложили ничего просто сказали все гавно, а вы на белом коне и со шпагой,удчи в вашей нелегкой шизофрении, и матчасть подтените прежде чем говорить что-то гавно
@kenny_opennix зря вы гоните :) @inkvizitor68sl всё правильно сказал.
Puppet в силу своей "декларативности", описывает состояние тех элементов которые вы описали в конфигурации, если в вашей предыдущей конфигурации их не было, то puppet с ними ничего и не сделает, запущенные процессы продолжат работать, пакеты по прежнему будут установлены, репозитории и правила apt-pin по прежнему будут вносить смуту и содомию.
Для того чтобы обеспечить возможность быстрого отката, самому придется придумать версионность и реализовать её средствами DSL puppet'а, ну либо модулями(там можно пошире развернуться).
Тоже наелся этой хрени. Но по прежнему использую для раскатки "базовой конфигураци", поскольку держим инфраструктуру в разных "амазонах", и гораздо проще её накатить puppet'ом, чем мастерить образ для каждого облачного сервиса. Положительным побочным эффектом (лично для меня) является документирование "ролей" серверов и необходимой конфигурации.
Использовать можно, но для очень ограниченных задач.
А если сравнивать с тем что есть сейчас на рынке я бы смотрел на chef (можно многое сделать руками в отличие от паппета) и cf engine.
Забыл сказать.
Все вышеописанное проявляется более явно когда вы "сквозным" образом начинаете использовать puppet. Тоесть в динамике конфигурируете сервисы одной ноды, в зависимости от состояний переменных на других нодах (hiera и бла бла бла).
