Зачем использовать Chef / Puppet вместо сценариев оболочки?

81

Новое в инструментах Puppet и Chef. Похоже, что работа, которую они выполняют, может быть выполнена с помощью сценариев оболочки. Возможно, это было сделано в сценариях оболочки, пока они не появились.

Я бы согласился, что они более читабельны. Но есть ли другие преимущества по сравнению со сценариями оболочки, кроме того, что они читаются?

отдыха
источник

Ответы:

56

Специфичный для домена язык имеет большое значение в количестве кода, который вы пишете. Например, вы можете утверждать, что нет большой разницы между:

chmod 640 /my/file

а также

file { "/my/file":
    mode => 640,
}

но есть большая разница между ними:

FILE=/my/file
chmod 640 $FILE
chown foo $FILE
chgrp bar $FILE
wget -O $FILE "http://my.puppet.server/dist/$FILE"
     # where the URL contains "Hello world"

а также

file { "/my/file":
    mode => 640,
    owner => foo,
    group => bar,
    content => "Hello world",
}

Что произойдет, если wget потерпит неудачу? Как ваш сценарий справится с этим? И что произойдет, если после этого в вашем скрипте будет что-то, что требует наличия $ FILE с правильным содержимым?

Вы можете утверждать, что можно просто вставить echo "Hello world" > $FILEсценарий, за исключением того, что в первом примере сценарий должен выполняться на клиенте, тогда как puppet компилирует все это на сервере. Поэтому, если вы изменяете контент, вам нужно всего лишь изменить его на сервере, и он изменит его на столько систем, сколько вы захотите. И кукольный автоматически обрабатывает зависимости и проблемы для вас.

Сравнения просто нет - правильные инструменты управления конфигурацией экономят ваше время и сложность. Чем больше вы пытаетесь сделать, тем больше сценариев оболочки кажутся неадекватными, и тем больше усилий вы сэкономите, делая это с puppet.

Пол Гир
источник
9
@Paul Gear, слишком упрощенно говорить, что инструменты управления конфигурацией - это путь в долгосрочной перспективе. Например, используя AWS, сценарий оболочки может собрать сервер с нуля, выполнить несколько тестов и, как только вы убедитесь, что с установками AWS все в порядке, создайте образ. Затем вы можете развернуть это изображение в среде предварительного просмотра или промежуточной среде для дальнейших тестов. После того, как вы проверите, что изображение подходит для ваших целей, вы переходите к производству. Инструменты управления конфигурацией вообще не помогают в этом сценарии.
Дерек Лиц
Теперь, если вы хотите управлять сотнями выделенных серверов, которые люди используют ежедневно (и у вас мало контроля над тем, что они делают, по ошибке или нет), вот где следует использовать инструменты управления конфигурацией.
Дерек Лиц
6
Это не очень убедительный пример. Я мог бы начать с wget, и тогда я бы не оказался в странном состоянии. Является ли файл как транзакция, которая будет откатана, если какой-либо из шагов не будет выполнен?
PSkocik
33

Это будет непопулярное мнение, но системы управления конфигурацией не обязательно лучше. Иногда просто действительно лучше.

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

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

kenchilada
источник
10
Когда стоимость управления средой настолько велика, что управление автоматизацией действительно обходится дешевле. Если проще создавать сценарии изменений, управляемых в Git, или настраивать их в мультиплексоре ssh, мы делаем это. Для меня важнее всего то, что я слежу за системами и проверяю, все ли функционирует должным образом. Пока меня предупреждают, когда что-то неправильно настроено, не так важно, как это настроено.
Кенчилада
10
@ewwhite "когда вы решите автоматизировать, а не против" xkcd.com/1205
MikeyB
3
Более современные инструменты, такие как Ansible, имеют значительно меньше затрат на развертывание / управление, чем Chef или Puppet, практически не требуя зависимостей (в частности, Ansible не использует агентов). Это действительно снижает планку принятия.
GomoX
2
@ewwhite Вы автоматизируете, когда вы хотите для личной производительности. Вы учитесь, автоматизируя, вы не учитесь, выполняя мирские задачи. Обучение = повышение производительности и итеративное улучшение. Автоматизация сочетается с этим, чтобы произвести больше позитива. Это положительный снежный ком, а не отрицательный. Технический прогресс против технического долга.
Дерек Лиц
2
@ABB Нет, это не подразумевается. Я даже не упоминаю сценарии оболочки, я упоминаю автоматизацию как общую практику. Вы можете автоматизировать вещи с помощью сценариев оболочки и изучать абстракцию сценариев вместо того, чтобы делать вещи вручную, что не только сэкономит вам время на повторное выполнение этой задачи, но и предотвратит ошибки. Кроме того, вы должны быть в состоянии написать свой следующий скрипт немного лучше, чем последний. Позитивный снежный ком ... Однако, если вы являетесь экспертом в написании сценариев и не пишете сценариев для чего-то, что вы когда-нибудь снова запустите, это никак не поможет вам научиться или сэкономить время.
Дерек Лиц
23

Вы ответили на свой вопрос ...

Автоматизация становится все более масштабируемой и формализованной . В наши дни Puppet и Chef считаются стандартами (см. Объявления о работе ).

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

ewwhite
источник
7
Являются ли сценарии оболочки менее формализованными? Делает ли цитирование объявлений о работе убедительным аргумент? И devops довольно позорно, потому что он / она недоиспользуется как разработчик. Ссылка ничего не говорит о масштабируемости. Является ли утверждение, что сценарии оболочки не масштабируемы? Я думаю, что Puppet интересен, но не обязательно по причинам в ответе.
Acumenus
Объявления о работе отражают реальный рынок для определенных навыков. Да, использование управления конфигурацией по прямому назначению является более масштабируемым, более надежным и более простым для документирования, чем сценарии оболочки. Я был во многих средах, и большинство сценариев, которые я вижу, не созданы таким образом, чтобы считаться «производственным качеством», и организованы для обработки исключений. Посмотрите принятый ответ, чтобы понять почему.
ewwhite
1
«И devops довольно позорно, потому что он / она недоиспользуется как разработчик». Это просто не правда. DevOps - это специализация разработки, как и веб-разработка. Модели и методы разработки программного обеспечения все еще применяются. Вы должны прочитать о DevOps.
Хаим Элия
13

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

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

Правильное решение CM помогает обеспечить успех в масштабе за счет упрощения межплатформенной автоматизации и совместной работы в команде. Хотя это можно сделать с помощью хорошо организованной, правильно поддерживаемой, версионной группы сценариев оболочки; Вы должны спросить себя «почему». Chef / Puppet и подобные технологии появились, потому что группа талантливых SysOps устала от необходимости снова и снова решать одни и те же проблемы и решила предложить нам лучший вариант.

Ключевые части:

  • идемпотентность
  • Простота управления зависимостями (управление версиями)
  • Стандартизированная организация (принята на отраслевом уровне)
  • Абстракция для отделения задач конфигурации сервера от деталей системного уровня
  • Способность использовать знания сообщества (это гарантированно охватывает все вышеупомянутые принципы)
Мэтт Сурабиан
источник
3
Идемпотентность вряд ли невозможна с сс. Зависимости хорошо управляются yum / apt и т. Д. Принятие не имеет значения. Знание сообщества существует для сс. Однако я согласен с тем, что не нужно копировать несколько сценариев, а также централизованно настраивать системы. Я слышал, марионетке нужен агент на стороне клиента.
Acumenus
10

Современные инструменты управления конфигурацией, такие как Puppet и Chef, позволяют вам определять состояние системы, не беспокоясь о действиях, необходимых для достижения настроенного сервера.

Например, ваша команда chmod предполагает, что файл существует, пользователь, владеющий файлом, существует, что каталоги созданы и т. Д. Поэтому ваш сценарий должен учитывать все эти предпосылки.

Инструменты управления конфигурацией на основе состояний проще: вам нужно только, чтобы у файла были правильные разрешения. Как это достигается - проблема инструмента.

Джон Джарокер
источник
1
На самом деле my chmodне предполагает, что файл существует, потому что файл был создан или проверен сценарием на наличие.
Acumenus
9

Если вам доступны одноразовые серверы, или у вас есть причина встать более чем на пару одновременно, полноценная система CM будет намного лучше отвечать вашим потребностям, чем серия сценариев оболочки.

Если ваши потребности в сборке скромны (или вы предпочитаете изготавливать вручную органические серверы справедливой торговли со свободным диапазоном), сделайте это просто.

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

С учетом вышесказанного вы можете запускать Chef без сервера (chef-solo), и я уверен, что у Puppet есть аналог, где вы все еще можете использовать чужие кулинарные книги и рецепты без запуска центрального сервера.

Еще одним преимуществом является сообщество: есть много людей (многие из которых будут умнее и / или опытнее вас). Лично мне нравится, когда кто-то другой выполняет мою работу за меня, часто более масштабно, чем я бы.

gWaldo
источник
1

Я создал оболочку автоматизации сервера на основе сценариев оболочки: https://github.com/myplaceonline/posixcube

Я уверен, что я не первый, кто делает такой проект, но я не мог найти что-то подобное, чтобы соответствовать моим потребностям, поэтому я подумал, что другие могут найти это полезным. У меня был только опыт работы с Chef, но когда я начал оглядываться на Ansible и других, я хотел попробовать сценарии оболочки, и мне пока нравится результат.

Kevin
источник