Команда ИТ-системных администраторов, которые имеют опыт использования сценариев оболочки для решения своих проблем, обдумывают возможность начать использовать вместо них Ansible.
Существуют ли существенные различия и веские причины, чтобы начать использовать Ansible и продолжать писать сценарии оболочки?
Ответы:
Я никогда не использовал Ansible, но уже несколько недель я пытаюсь выяснить, насколько хорошим может быть Ansible по сравнению с надписями на скорлупе - что доказывает, по крайней мере, в моем случае, что преследующие их рекламные кампании эффективны! После многих неудачных попыток - что доказывает, что их документация не дает ответа на один из самых очевидных вопросов, - я думаю, что наконец-то понял:
Теперь давайте посмотрим вводное видео и, как потенциальный новый пользователь, в случайном порядке ознакомимся с вводным материалом для Ansible, и давайте сравним его с тем, что опытный программист оболочки может создать сразу с полки.
Мой вывод заключается в том, что, помимо сценариев оболочки, Ansible предлагает: 1. Возможность проверки соответствия системы желаемому состоянию, 2. Возможность интеграции с Ansible Tower, которая является платной системой, которая, кажется, включает в себя возможности мониторинга. В некоторых важных случаях, например при реализации шаблона неизменяемого сервера, точка 1, вероятно, не очень полезна, поэтому список довольно узок.
Мой вывод заключается в том, что преимущества, предлагаемые Ansible по сравнению с сценариями оболочки, в том виде, в котором они представлены в документации, могут быть ощутимыми в нескольких горстках оптимизма, хорошо охватываемых доступными модулями, но в общем случае малы или даже гипотетичны. Для опытного программиста оболочки, вероятно, эти преимущества, скорее всего, уравновешены другими аспектами компромисса.
Но это, возможно, только доказывает, насколько плохой вводный материал!
Есть быстрый старт видео . Она начинается со страницы, в которой утверждается, что… ну, на самом деле это не претензии, это списки маркеров, артефакт, обычно используемый для приостановки критического суждения в презентациях (поскольку логика не показана, ее нельзя критиковать!)
1.1 Человекочитаемая автоматизация. Спецификации - это технические документы, как
name: upgrade all packages
yum:
name: '*'
state: latest
легче читать, чем соответствующий вызов yum, найденный в shell-скрипте? Кроме того, любой, кто имел контакт с AppleScript, умирает от смеха, когда читает «автоматизируемость, читаемую человеком».
1.2 Никаких специальных навыков кодирования не требуется. Что такое кодирование, если не писать формальные спецификации? У них есть условные, переменные, так как это не кодирование? И зачем мне что-то, что я не могу запрограммировать, что отныне будет негибким? Утверждение счастливо неточно!
1.3 Задачи, выполняемые по порядку. Возможно, некоторые поклонники Codegolf знают о языках, которые выполняют задачи в беспорядке, но выполнение задач по порядку вряд ли выглядит исключительным.
1.4 Быстро производите продуктивную работу - опытные программисты оболочки теперь работают продуктивно. Этот контраргумент столь же серьезен, как и начальный аргумент.
Популярная уловка продавца продавать артефакты состоит в том, чтобы заставить людей поверить, что они приобретут «силу» этих артефактов. История рекламы автомобилей или изотонических напитков должна содержать убедительный список примеров.
Здесь Ansible может выполнить «развертывание приложения» - но скрипт сценария наверняка сделает «управление конфигурацией», но это всего лишь заявление о назначении инструмента, а не о функции и «согласовании рабочего процесса», которое выглядит немного претенциозно, но ни один пример не подходит сверх того, что может сделать GNU Parallel .
Чтобы заполнить колонку, они написали тремя различными способами, что для этого нужен только ssh, который, как все знают, является демоном и не имеет ничего общего с этими агентами, пронизывающими управление конфигурацией мира!
В остальной части видео представлены инвентарные списки ресурсов, которые представляют собой статические списки ресурсов (например, серверов), и показано, как развернуть Apache на трех серверах одновременно. Это действительно не соответствует тому, как я работаю, когда ресурсы очень динамичны и могут перечисляться инструментами командной строки, предоставляемыми моим облачным провайдером, и потребляться моими функциями оболочки с помощью |оператора pipe . Кроме того, я не развертываю Apache на трех серверах одновременно, скорее, я создаю образ основного экземпляра, который затем использую для запуска 3 экземпляров, которые являются точными копиями одного из другого. Таким образом, «оркестрирующая» часть аргументации выглядит не очень уместно.
EC2 - это вычислительный сервис от Amazon, взаимодействие с которым поддерживается некоторым модулем Ansible . (Другие популярные поставщики облачных вычислений также предоставляются):
# demo_setup.yml
- hosts: localhost
connection: local
gather_facts: False
tasks:
- name: Provision a set of instances
ec2:
key_name: my_key
group: test
instance_type: t2.micro
image: "{{ ami_id }}"
wait: true
exact_count: 5
count_tag:
Name: Demo
instance_tags:
Name: Demo
register: ec2
Соответствующий shell-скрипт будет практически идентичен YAML, замененному JSON:
provision_a_set_of_instances()
{
aws --output=text ec2 run-instances --image-id …
}
или версия JSON
provision_a_set_of_instances()
{
aws --output=text ec2 run-instances --cli-input-json "$(provision_a_set_of_instances__json)"
}
provision_a_set_of_instances__json()
{
cat <<EOF
{
"ImageId": …
}
EOF
}
Обе версии в основном идентичны, основная часть полезной нагрузки - это перечисление значений инициализации в структурах YAML или JSON.
Большая часть этого руководства не отображает каких-либо действительно интересных функций: в нем представлены переменные (IIRC, в сценариях оболочки также есть переменные) !, а модуль Ansible обрабатывает mysql, так что если вместо поиска «как мне создать пользователя mysql» с привилегиями на XY »и заканчивается чем-то вроде
# Create Application DB User
mysql --host "${mysql_host}" --user "${mysql_user}" --password "${mysql_password}" "${mysql_table}" <<EOF
GRANT ALL PRIVILEGES ON *.* TO 'root'@'%';
EOF
Вы ищете «как мне создать пользователя mysql с привилегиями на XY в ansible » и в итоге получаете
- name: Create Application DB User
mysql_user: name={{ dbuser }} password={{ upassword }}
priv=*.*:ALL host='%' state=present
Разница все еще, вероятно, не очень значимая. На этой странице мы также обнаруживаем, что в Ansible есть шаблон языка метапрограммирования.
{% for host in groups['monitoring'] %}
-A INPUT -p tcp -s {{ hostvars[host].ansible_default_ipv4.address }} --dport 5666 -j ACCEPT
{% endfor %}
Когда я вижу это, я оказываюсь в своей зоне комфорта. Этот вид простого метапрограммирования для декларативных языков является точно такой же теоретической парадигмой, что и BSD Makefiles! Как я часто программировал. Этот отрывок показывает нам, что обещание работать с файлом YAML нарушено (поэтому я не могу запустить свои книги воспроизведения, например, через анализатор YAML ). Это также показывает нам, что Ansible должен обсудить тонкое искусство порядка оценки: мы должны решить, будут ли переменные расширяться в «декларативной части» языка или в «императивной» мета-части языка. Здесь программирование оболочки проще, здесь нет метапрограммирования, кроме явного eval или внешнего поиска сценариев. Гипотетическая эквивалентная выдержка из оболочки будет
enumerate_group 'monitoring' | {
while read host; do
…
done
}
чья сложность по сравнению с вариантом Ansible, вероятно, терпима: он просто использует простые, правильные, скучные конструкции из языка.
Наконец, мы встречаем то, что оказывается первой действительно интересной особенностью Ansible: «Ресурсы Ansible - это модели желаемого состояния. Таким образом, нет необходимости проверять, запущены ли службы, установлены ли пакеты или другие подобные вещи. Ansible - это система, которая гарантирует, что эти вещи декларативно верны. Вместо этого, отразите эти вещи в своих сборниках пьес ». Теперь это становится немного интересным, но:
Помимо нескольких стандартных ситуаций, легко реализуемых доступными модулями, мне придется самому кормить битами, реализующими тест, что, вероятно, будет включать некоторые команды оболочки.
Проверка соответствия установок может быть не очень уместна в контексте, где реализован шаблон неизменяемого сервера: где все работающие системы обычно создаются из главного образа (например, образа экземпляра или образа докера) и никогда не обновляются - они заменяются на новый вместо
Вводный материал от Ansible игнорирует вопрос ремонтопригодности. В сущности, без системы типов, сценарии оболочки имеют простоту сопровождения JavaScript, Lisp или Python: обширные рефакторинги могут быть успешно достигнуты только с помощью обширного автоматизированного набора тестов или, по крайней мере, проектов, которые позволяют легко проводить интерактивное тестирование. Тем не менее, в то время как сценарии оболочки являются основным языком в конфигурации и обслуживании системы, почти каждый язык программирования имеет интерфейс с оболочкой. Поэтому вполне возможно использовать преимущество удобства сопровождения продвинутых языков, используя их для склеивания различных битов конфигурации оболочки. Для OCaml я написал Rashell это, по сути, обеспечивает набор общих шаблонов взаимодействия для подпроцессов, что делает перевод сценариев конфигурации в OCaml по существу тривиальным.
Помимо Ansible, очень слабая структура playbooks и наличие функции метапрограммирования делают ситуацию по существу такой же плохой, как и для сценариев оболочки, с минусами, что не очевидно, как писать модульные тесты для Ansible и аргумент о введении ad-hoc языка более высокого уровня нельзя имитировать.
Документация Ansible обращает внимание на необходимость написания идемпотентных шагов конфигурации. Точнее, этапы конфигурации должны быть записаны так, чтобы последовательность шагов aba можно было упростить до ab , то есть нам не нужно повторять шаг конфигурации. Это более сильное состояние, чем идемпотентность. Поскольку Ansible позволяет Playbooks использовать произвольные команды оболочки, сам Ansible не в состоянии гарантировать соблюдение этого более строгого условия. Это зависит только от дисциплины программиста.
Если говорить так, даже если Ansible имеет некоторые присущие преимущества, преимущества использования знакомых инструментов (в данном случае сценариев оболочки) должны быть перевешены. Я не думаю, что есть четкий ответ на это.
Если команда может достичь того, что предлагает Ansible с помощью shell:
тогда они, вероятно, могли бы придерживаться того, что они знают.
В конце концов, вы можете реализовать «охранников» в BASH. Вы можете найти множество работ BASH для решения различных задач по настройке сервера (практически любой Dockerfile содержит 90% кода установки bash). Вы можете получить довольно близкое представление о том, что предлагает вам Ansible / Salt / Chef-Zero, без необходимости переносить все существующие решения на эти инструменты.
Это баланс между тенденциями NIH (не изобретенными здесь) и выбрасыванием хороших, устоявшихся сценариев в пользу более надежного решения.
И последнее, о чем следует помнить: как соотносится ваш технологический стек, когда вы пытаетесь привлечь в команду больше людей. Поиск людей, имеющих опыт работы с Ansible, намного проще, чем поиск людей, имеющих опыт работы с вашим конкретным инструментом CM для сценариев собственного производства. Это не чисто технический вопрос, а скорее культурный. Вы хотите быть странной организацией, которая изобретает свой собственный Ansible, или вы хотите быть разумной организацией, которая находит правильный инструмент для работы? Эти решения влияют на вашу способность привлекать таланты.
Приведенный выше ответ покрывает часть этого, но пропускает один из важных элементов: конвергентный дизайн. Некоторое время назад я написал несколько слов об этом в контексте Chef по адресу https://coderanger.net/thinking/, но короткая версия заключается в том, что bash-скрипт - это набор инструкций, а Ansible playbook (или рецепт Chef, Salt). состояние и т. д.) - описание желаемого состояния. Документируя желаемое состояние, а не шаги, которые вы хотите предпринять, чтобы получить его, вы можете справиться с гораздо большим количеством начальных состояний. Это было сердцем Теории Promise, как обрисовано в CFEngine давно, и дизайн, который мы (инструменты управления конфигурацией) только что копировали с тех пор.
tl; dr Ansible-код говорит, что вы хотите, bash-код говорит, как что-то сделать.
Стоит отметить, что у вас будет меньше проблем с запуском ваших сборников игр на удаленных хостах. Как это главная причина для запуска ANSIBLE. Когда вы используете сценарии оболочки, вам все равно нужен способ сценария scp'ing на удаленном хосте.
Это 2019 год, и я только что провел несколько дней на кривой обучения, и вот абсолютная правда: Ansible не стоит хлопот.
он не закончен, он не запускается на окнах, а сочетание конфигурации YAML и вводящих в заблуждение сообщений об ошибках заставит вас кровоточить. Это кажется почти преднамеренно ужасным, и я имею в виду это серьезно. Это, очевидно, продукт разочарованного проекта на стороне разработчика redhat sysadmins. Вероятно, хипстер.
Если вам не требуются какие-либо из его функций, кроме предоставления, и вы когда-либо выполняете подготовку только на одной конкретной ОС. Ради бога напишите приличный shell.script.
На данный момент весь проект напоминает мне о ранних форумах по Linux, где новичкам сообщали RTFM и высмеивали вопрос, почему кто-то не может написать графический интерфейс для настройки параметров графики. Ты просто не понимаешь? Вы должны придерживаться окна ... возможно, я буду спариваться .. счастливого пути.
Используйте Docker. В предпочтении ко всему. Докер невероятно простой и мощный.
Но что, если вы абсолютно обязаны обеспечить на уже существующей олова? Каковы реальные альтернативы?
Ну ... пока их нет. Но я пообещаю вам это, если ANSIBLE не станет лучше, скоро будет. Потому что как бы фанаты ни давили на него и не прощали его неудачи ... это 5 из 10 усилий.
SCP до сценария bash и избавить себя от неприятностей.