Есть понимание того, что это 2 разных продукта, однако выполняют примерно одни и те же задачи.
Положим, есть серверная инфраструктура, состоящая из N хостов , где N >> 50. OS в основном Debian.
В связи с тем, что хочется привести эту самую инфраструктуру к общему знаменателю и получить возможность легко управлять ею, нужно внедрить chef или puppet.
Вопрос комплексный:
1. В каком продукте из этих двух можно разобраться с нуля быстрее?
2. С помощью какого решения из этих двух можно сделать вышеуказанную задачу быстрее и легче?
3. Какой продукт в последствии легче поддерживается?
4. По какому из этих решений больше мануалов и статей, что даёт некую лёгкость процесса гугления и достижения результата?
1. Ansible
2. Того, которое лучше знаете.
3. Тот, к которому привыкли.
4. Да по всем манулов просто немерено, как и готовых рецептов, шаблонов, наработок.
Я бы советовал присмотреться к ansible, но это лично на мой вкус.
Добрый день!
Лично я остановился на salt. docs.saltstack.com
Удобство питона сыграло мне на руку. Серверами я управляю с одно сервера, выполняю настройку конфигов и поддержание их актуальности
Есть куда более простой способ управлять инфраструктурой - собирать пакеты для всего и ставить их. Конфиги, мониторинг - всё упаковывать.
А ставить пакеты легко через любую cms.
Это называется простой способ? Вы так делаете? Сколько времени занимает: собрать пакет - накатить на хосты - найти ошибку в конфиге - пересобрать пакет - накатить на хосты?
Алексей Ямщиков: "хуяк хуяк и в продакшн". Примерно для этого.
Более или менее понятна история возникновения CFEngine (он действительно умеет все ОС и при помощи него можно настраивать гетерогенный кластер из веб-серверов на windows+solaris+linux+шпукс с одинаковой конфигурацией).
Остальные - только ради хуяк-хуяк.
Чтобы собирать пакеты - надо думать. Зато они императивны. А вот все cms - декларативны и думать там в целом не нужно. Зато частенько нужно лезть руками и исправлять то, что ты там этим хераком натворил.
Впрочем, ansible/puppet/chef дико удобны для того, чтобы ставить пакеты и контроллировать их версии, да =)
Влад Животнев: Кто то из нас запутался? "удобство в декларативности." - это же паппет (и присные) декларативен. А пакеты "Чтобы собирать пакеты - надо думать. Зато они императивны."
Значит пакеты императивны.
Как по мне так вы пакеты используете для какого то очень узкоспецифичного направления. Если бы всё было так радужно как вы расписали, то вероятно не появились бы никакие паппеты, чифы и т.д.
Пакет это набор файлов с инструкцией как их поставить и что сделать до и после (если я верно понимаю).
Если у вас гетерогенная среда, то у вас могут возникнуть проблеммы - где то пакет не поставился, где то какая то ошибка ещё вылезла. Думаю именно поэтому и были созданы "паппеты". Если я ошибаюсь - прошу просветить, глядишь экспириенса поднаберу. ))
Алексей Ямщиков: ну да, перепутал. Пакеты - императивны. Поэтому, если пакет ты сделал правильно и он поставился - то ты можешь быть уверен, что оно работает. Если ты его удалишь - то больше оно работать не будет.
А чтобы из паппета сделать императивный инструмент - нужно дохрена раз написать "file is absent".
Алексей Ямщиков: мне ваша боль, в общем-то, знакома. Пакеты вы собирать не умеете.
Именно для таких людей чифы с паппетом и прочим и появились. Чтобы не мыслить пакетными категориями, чтобы "всё из коробки в один клик", а мыслить категориями "если я поменяю конфиг Х, то произойдет У".
Алексей Ямщиков: а нормальных гетерогенных инф-р не бывает. Не нужно пытаться запустить половину балансеров на центосе, а вторую на убунтах.
Я видел, во что превращаются сервера после аутсореров, которые паппетом пытаются привести все свои сотни обслуживаемых серверов с дебианом/центосом/бсдой и прочим к похожему состоянию. Ничего хорошего из этого не выходит.
Влад Животнев: у меня всё на центосе, но роли у серверов разные. Где то одно нужно где то другое. Мне под каждый чих генерить пакет - слишком большой оверхед получается по времени?
Вот вы мне сейчас много раз указали что "для таких как я", но толком ничего не объяснили. Я понимаю, что вы работаете в Яндексе, но зачем из-за этого нос задирать?
Да, пакеты я собирать не умею, имею поверхностное представление об этом, и пока не вижу необходимости углублять свои знания в этом направлении. В общем то я и прошу прояснить мне что в этом способе такого уникально удобного (исходим из начального ответа и последующих реплик), что мне действительно нужно ознакомиться с тем как собирать пакеты и использовать это в продакшене.
Несколько RPM пакетов собирал, когда нужно было - из-за отсутствия нужных версий в репах. Но восторга от этой процедуры не получил.
Вот может вы мне всё таки объясните в чём профит?
Алексей Ямщиков: я же сказал - профит в том, что пакеты императивны.
Наличие пакета приводит систему в ожидаемое состояние, удаление пакета выводит систему из данного состояния.
Все cms - императивны. Они что-то делают и смотрят за тем, что за ними ничего не поломали. Если использовать cms на полную силу (с конфликтами, зависимостями и прочим) - то проще собирать пакеты. Если использовать не в полную силу - то система будет находиться в неизвестном состоянии в произвольно взятый момент времени.
> слишком большой оверхед получается по времени?
Вот тут ваша самая большая ошибка. Пакеты с конфигурацией как раз собирать очень легко.
Влад Животнев: Спасибо за объяснение. Мне всё таки кажется, что пакеты возможно использовать когда ты точно знаешь в какое состояние у тебя должна прийти система. В общем для каждой задачи свой инструмент. Согласен, что удаление пакета приведёт к откату системы на какую то позицию до установки, но насколько это нужно? Да, пакеты собирать легко. Но зачем? Вообще системы пакетов и puppet преследуют немного разные цели. Пакет - распространить ПО, "паппет" - с помощью нужных пакетов поставить ПО и произвести окончательную конфигурацию.
Давай попробуем на практическом примере, я всё равно не догоняю в чём профит императивного перед декларативным.
Задача 1. Давай возьмём конфиг зоны DNS. Мне нужно добавить в зону хост. Хост уже получил первоначальные настройки через паппет и скинул ему свои факты. Зона наполняется из фактов. В очередной раз как на DNS сервере отработает puppet agent данные о новом хосте подтянуться через факты, добавятся в зону, перезапустится DNS сервер. Я для этого ничего не делал (кроме начальной конфигурации) - оно в автомате всё собралось, прописалось, перезапустилось - в DNS появилась новая запись. Тут использование пакетов не прокатит (имхо). Откуда брать параметры других хостов, как наполнять зону - писать свои скрипты, которые будут решать конкретные задачи.
Задача 2. Есть демон VPN tinc. Для создания меш сети есть модуль l2mesh, который настраивает нужные хосты по заданным параметрам и при добавлении новых хостов он конфиги меняет, при удалении хостов из каталога конфиги старые удаляются. Опять же пакеты не подходят (имхо). Ведь для такой задачи придётся городить собственные скрипт-велосипеды в пакете.
Я соглашусь с тем, что настраивать через пакеты может быть круто, но только если не нужно конфигурировать много. В остальном это будет просто боль (имхо).
Алексей Ямщиков: ваши случаи (по крайней мере, первый) я и называю "херак-херак и в продакшн".
В ынтерпрайзе это иногда приводит к печальным последствиям. Например, новый хост по каким-либо причинам назовет себя market.yandex.ru. И добавит себя в RR.
Но вообще конкретно эта задаче решается посредством dyndns. Не нужно там ничего перезапускать.
Влад Животнев: "Например, новый хост по каким-либо причинам назовет себя market.yandex.ru." причин может быть множество и настройка через пакеты вам так же ничего не гарантирует. Можно ошибиться и запихнуть в пакет неверный конфиг.
Думаю можно закончить наш диалог. Использование пакетов для начальной настройки и провижионинга - возможно, для постоянной настройки/перенастройки - извращение.
Почитал на вашем сайте статью про сборку пакета - если бы я так пакеты собирал, то давно бы уже забыл что где и откуда конфигурится.
Средний
