Pull to refresh

Comments 14

Конкретно это решение — нет, не смотрел. Выглядит интерессно хотя бы наличием пакетов в том числе под упомянутый Debian. Cпасибо за ссылку, полез читать.
Если я правильно понял QuickStart Guide и User Manual, cobblerd заточен в первую очередь на redhat-based дистрибутивы. Плюс он рассчитан на более сложные задачи, чем просто сетевая установка, которые в том числе частично пересекаются с scm вроде puppet/chef. Для наших потребностей это будет — простите за английский термин — overcomplicating.
cobbler может ставить debian/ubuntu. Можно использовать kickstart, можно использовать preseed — выбор ваш. cobbler хорошо тем, что является работающей связкой всех необходимых сервисов, конфигурирование сводится к минимуму. Насчет сложности задач решать, конечно, вам.
Тоже хотел сказать за cobbler, но опередили. Плюс, для раскатки наверное лучше была бы какая-нибудь SCM (ansible/salt/chef/puppet/etc). Поможет в дальнейшем сопровождении.
Касательно cobbler ответил выше.

Puppet в дальнейшем сопровождении и используется. И сейчас рассматривается вариант перевода скрипта firstboot на манифесты puppet-a. Как всегда, правда, не хватает то времени то желания на переделку. Скрипт в реальности сложнее/объемнее, чем в статье; включающий в том числе запуск нескольких скриптов на внешних серверах для регистрации в nagios, генерации ключей openvpn и открытия «куда положено» доступов новоустановленному компьютеру.
А ещё есть CFEngine, который весь детский сад вроде puppet, ansible и прочей шелухи за пояс затыкает на раз-два.
Раньше были холивары emacs vs vim, теперь, видимо puppet vs chef vs ansible vs CFEngine vs etc :) Поделитесь опытом, какая у CFEngine киллер-фича, что он настолько лучше всего остального?
Тоже интересно. Давно не смотрел его, а тут вот довелось чуть пощупать CFEnginev3. Особо вроде ничего не поменялось со времён CFEnginev2 — у него как был так и остался негуманоидный синтаксис и сложность внедрения. Надеюсь, хоть регулярные сегфолты в трешке починили.

После эксплуатации CFv2, осмотра chef/puppet/salt/CFv3, понравился Ansible. Реально гораздо проще начинать и продолжать. Не без недостатков конечно, но апстрим довольно вменяемый и оперативный.
Ansible не так давно перестал быть порочен своей push-only архитектурой, но остался невообразимо ужасен в плане конфигурирования на yaml и Jina2 (хотя это вроде уже починили). Ну и шутку Майкла про «we're a real systems management app, not just a python library. We do not expect to be installed in virtualenv» я по достоинству оценил. Он же, если не ошибаюсь, ещё заявлял, мол, pull для таких вещей может захотеть только тупой и эта стратегия никогда не будет приоритетной в Ansible (точную цитату не могу найти, к сожалению). Коммьюнити вокруг Ansible сложилось с большего вменяемое, но вот рулевой у проекта — совсем нет. И я всё ещё настаиваю на том, что bash для сисадмина проще и понятнее, чем Питон или Руби.
Не получится холивара по причине очень разных весовых категорий. Во-первых, CFE в своё время инспирировал Puppet (который в свою очередь через три-четыре года инспирировал Chef). Во-вторых, под CFE есть серьёзная научная основа. В-третьих, CFE зависит только сам от себя и от рантайма (неожиданно, но это чертовски важно для области применения подобных инструментов). А из личного опыта могу заметить, что либо проблема (относительно) легко решается хоть скриптом на баше, либо (с трудом) решается с помощью CFE. Ну либо вообще не решается и только руками.

Я вообще понимаю, почему люди могут выбирать Puppet или Chef. С ними 99% типовых задач решается клонированием репозитория с рецептами с гитхаба, и для социальных облачных стартапов такое вполне приемлимо. Но в статье-то как раз-таки идёт речь не о клонировании виртуалок на Rackspace и AWS, а о реальной задаче с авторазворачиванием клиентских машин. Я бы не доверял такие интимные подробности жизни склонированному с гитхаба неизвестно чему.
Можно, я встряну?
На всякий случай напомню, что в статье ни слова не говорилось о puppet. Был описан только личный опыт применения стандартных средств и в конце — пара простеньких скриптов на баше.

И — да. Вам не кажется, что раз cfengine «инспирировал» (интерессный перевод слова «inspired», в жизни бы не выдумал) puppet, значет этому cfengine все же чего-то не хватало?

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

Чего не хватало (и всё ещё не хватает) CFE? Низкого порога вхождения. Внутренний язык и концепция не всегда очевидны и порой выносят мозг на ровном месте. Репозитория с готовыми решениями мало, приходится ещё своей головой думать. Но поняв хотя бы половину предложенных идей уже можно что-то начинать делать не только на локалхосте, доучивая по дороге.

А, да, «инспирировать» всё же от латинского «inspirare»: gramota.ru/slovari/dic/?word=%E8%ED%F1%EF%E8%F0%E8%F0%EE%E2%E0%F2%FC&all=x и существует в русском языке уже давно, ещё до этих наших интернетов.
Sign up to leave a comment.

Articles

Change theme settings