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


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

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


76
2018-05-01 10:13


Источник




Ответы:


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

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 в сценарии, за исключением того, что в первом примере сценарий должен запускаться на клиенте, тогда как кукольный компилирует все это на сервере. Поэтому, если вы меняете контент, вам нужно только изменить его на сервере, и он меняет его на столько систем, сколько вы хотите его надеть. И марионетки автоматически обрабатывают зависимости и проблемы переноса.

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


55
2018-05-01 11:14



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


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

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

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


31
2018-05-01 14:58



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


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

Автоматизация становится более масштабируемой и формализованной, Кукла и шеф-повар считаются стандартами в эти дни (проверьте объявления о работе).

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


23
2018-05-01 10:40



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


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

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

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

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

  • идемпотентность
  • Простота управления зависимостями (управление версиями)
  • Стандартизованная организация (принята на отраслевом уровне)
  • Абстракция для разделения задач настройки сервера с подробностей на уровне системы
  • Возможность использовать знания сообщества (что гарантированно охватывает все вышеперечисленные принципы)

13
2018-05-03 19:11



Идемпотентность вряд ли невозможна с помощью ss. Зависимости управляются хорошо с помощью yum / apt и т. Д. Принятие не имеет значения. Знания сообщества существуют для ss. Однако я согласен с тем, что не нужно копировать кучу скриптов, а также централизованно настраивать системы. Я слышал, что марионетка требует агента на стороне клиента. - A-B-B


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

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

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


10
2018-05-20 02:19



На самом деле мой chmod не предполагает, что файл существует, потому что файл был создан или протестирован для существования скриптом. - A-B-B


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

Если ваши потребности в сборке являются скромными (или, как правило, ремесленными органическими свободными торговыми серверами свободной торговли, то сохраняйте их просто.

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

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

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


9
2018-05-01 22:32





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

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


1
2017-12-25 01:15