Чем Ansible отличается от простого запуска оболочки Bash в Vagrant?


39

Команда ИТ-системных администраторов, которые имеют опыт использования сценариев оболочки для решения своих проблем, обдумывают возможность начать использовать вместо них Ansible.

Существуют ли существенные различия и веские причины, чтобы начать использовать Ansible и продолжать писать сценарии оболочки?

Ответы:


29

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

Теперь давайте посмотрим вводное видео и, как потенциальный новый пользователь, в случайном порядке ознакомимся с вводным материалом для Ansible, и давайте сравним его с тем, что опытный программист оболочки может создать сразу с полки.

Мой вывод заключается в том, что, помимо сценариев оболочки, Ansible предлагает: 1. Возможность проверки соответствия системы желаемому состоянию, 2. Возможность интеграции с Ansible Tower, которая является платной системой, которая, кажется, включает в себя возможности мониторинга. В некоторых важных случаях, например при реализации шаблона неизменяемого сервера, точка 1, вероятно, не очень полезна, поэтому список довольно узок.

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

Но это, возможно, только доказывает, насколько плохой вводный материал!

Быстрый старт видео:

Есть быстрый старт видео . Она начинается со страницы, в которой утверждается, что… ну, на самом деле это не претензии, это списки маркеров, артефакт, обычно используемый для приостановки критического суждения в презентациях (поскольку логика не показана, ее нельзя критиковать!)

1. Ansible прост:

1.1 Человекочитаемая автоматизация. Спецификации - это технические документы, как

  name: upgrade all packages
  yum:
    name: '*'
    state: latest

легче читать, чем соответствующий вызов yum, найденный в shell-скрипте? Кроме того, любой, кто имел контакт с AppleScript, умирает от смеха, когда читает «автоматизируемость, читаемую человеком».

1.2 Никаких специальных навыков кодирования не требуется. Что такое кодирование, если не писать формальные спецификации? У них есть условные, переменные, так как это не кодирование? И зачем мне что-то, что я не могу запрограммировать, что отныне будет негибким? Утверждение счастливо неточно!

1.3 Задачи, выполняемые по порядку. Возможно, некоторые поклонники Codegolf знают о языках, которые выполняют задачи в беспорядке, но выполнение задач по порядку вряд ли выглядит исключительным.

1.4 Быстро производите продуктивную работу - опытные программисты оболочки теперь работают продуктивно. Этот контраргумент столь же серьезен, как и начальный аргумент.

2. Ansible - это мощно

Популярная уловка продавца продавать артефакты состоит в том, чтобы заставить людей поверить, что они приобретут «силу» этих артефактов. История рекламы автомобилей или изотонических напитков должна содержать убедительный список примеров.

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

3. Ansible без агента

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

Остальная часть видео

В остальной части видео представлены инвентарные списки ресурсов, которые представляют собой статические списки ресурсов (например, серверов), и показано, как развернуть Apache на трех серверах одновременно. Это действительно не соответствует тому, как я работаю, когда ресурсы очень динамичны и могут перечисляться инструментами командной строки, предоставляемыми моим облачным провайдером, и потребляться моими функциями оболочки с помощью |оператора pipe . Кроме того, я не развертываю Apache на трех серверах одновременно, скорее, я создаю образ основного экземпляра, который затем использую для запуска 3 экземпляров, которые являются точными копиями одного из другого. Таким образом, «оркестрирующая» часть аргументации выглядит не очень уместно.

Случайная документация шаг 1: интеграция с EC2

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.

Случайное документирование, шаг 2. Непрерывная доставка и обновление

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

Случайная документация шаг 3: Тестирование стратегий

Наконец, мы встречаем то, что оказывается первой действительно интересной особенностью Ansible: «Ресурсы Ansible - это модели желаемого состояния. Таким образом, нет необходимости проверять, запущены ли службы, установлены ли пакеты или другие подобные вещи. Ansible - это система, которая гарантирует, что эти вещи декларативно верны. Вместо этого, отразите эти вещи в своих сборниках пьес ». Теперь это становится немного интересным, но:

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

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

Нерешенная проблема: ремонтопригодность

Вводный материал от Ansible игнорирует вопрос ремонтопригодности. В сущности, без системы типов, сценарии оболочки имеют простоту сопровождения JavaScript, Lisp или Python: обширные рефакторинги могут быть успешно достигнуты только с помощью обширного автоматизированного набора тестов или, по крайней мере, проектов, которые позволяют легко проводить интерактивное тестирование. Тем не менее, в то время как сценарии оболочки являются основным языком в конфигурации и обслуживании системы, почти каждый язык программирования имеет интерфейс с оболочкой. Поэтому вполне возможно использовать преимущество удобства сопровождения продвинутых языков, используя их для склеивания различных битов конфигурации оболочки. Для OCaml я написал Rashell это, по сути, обеспечивает набор общих шаблонов взаимодействия для подпроцессов, что делает перевод сценариев конфигурации в OCaml по существу тривиальным.

Помимо Ansible, очень слабая структура playbooks и наличие функции метапрограммирования делают ситуацию по существу такой же плохой, как и для сценариев оболочки, с минусами, что не очевидно, как писать модульные тесты для Ansible и аргумент о введении ad-hoc языка более высокого уровня нельзя имитировать.

Идемпотентность шагов конфигурации

Документация Ansible обращает внимание на необходимость написания идемпотентных шагов конфигурации. Точнее, этапы конфигурации должны быть записаны так, чтобы последовательность шагов aba можно было упростить до ab , то есть нам не нужно повторять шаг конфигурации. Это более сильное состояние, чем идемпотентность. Поскольку Ansible позволяет Playbooks использовать произвольные команды оболочки, сам Ansible не в состоянии гарантировать соблюдение этого более строгого условия. Это зависит только от дисциплины программиста.


Это похоже на руководство ... впечатляет!
Pierre.Vriens

4
Я не мог согласиться больше. Мы использовали Ansible более 1 года и сейчас используем контейнеры Docker, созданные с использованием хороших, простых старых сценариев bash. Определение состояния также, на мой взгляд, является самой интересной функцией, но, как вы уже упомянули, существует очень много служб, у которых нет соответствующего модуля Ansible, поэтому вам все равно придется в любом случае отступать к командам bash. И да, мы также разворачиваем только неизменяемые контейнеры на серверах, поэтому определение состояния на самом деле не дает никаких преимуществ в этом случае.
Андреас

1
После тщательного использования ansible я могу подтвердить все замечания, которые я сделал априори. Идемпотентность возможна, но не навязывается ansible (см. Модуль vmware_guest для плохого гражданина), работа с их макросистемой - это настоящая боль, и все сложнее выполнять даже самые базовые обработки структурированных данных, некоторые основные вещи делают просто неправильно (формат playbook не может использовать режим файлов Unix без терапии), и единственное, что действительно полезно, - это загрузка полезных функций, написанных для ansible. Так что если бы Red Hat не продвигал этот продукт, я бы не смог понять широкое распространение.
Михаэль Ле Барбье Грюневальд

1
@ Андреас Я согласен, что у вас все еще есть много случаев, когда вам нужно вернуться к оболочке или к командным модулям, что не означает, что ваша игра не может быть идемпотентной. Сами основные модули поддерживают идемпотентность, просто проверяя, следует ли выполнить действие. Вы можете сделать то же самое самостоятельно с оболочкой или командным модулем, сначала запустив задачу, которая проверяет, нужно ли что-то сделать, и зарегистрировав ее вывод, затем выполнив условие для второй задачи на основе вывода из первой задачи.
Леви

1
@ MichaelLeBarbierGrünewald, я должен в целом согласиться, что когда я работал с Ansible, было очень трудно начать работать, и его работа, которая занимает несколько недель, чтобы собрать сборник материалов для подключения к инфраструктуре в моей бывшей облачной компании, предоставив Linux дистрибутив, установите LAMP / LEMP или что-то еще. Как только это было завершено, это сэкономило нам время, но потребовалось целый месяц, чтобы все заработало. Никто из нас не был мастером сценариев bash, так что это не было альтернативой.
Даниил

22

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

Если команда может достичь того, что предлагает Ansible с помощью shell:

  1. Декларативное, идемпотентное управление конфигурацией
  2. Доступ к повторно используемым фрагментам (например, к книгам) для популярных в отрасли услуг.
  3. Надежное управление удаленным выполнением, с повторной попыткой, скользящей логикой и т. Д.

тогда они, вероятно, могли бы придерживаться того, что они знают.

В конце концов, вы можете реализовать «охранников» в BASH. Вы можете найти множество работ BASH для решения различных задач по настройке сервера (практически любой Dockerfile содержит 90% кода установки bash). Вы можете получить довольно близкое представление о том, что предлагает вам Ansible / Salt / Chef-Zero, без необходимости переносить все существующие решения на эти инструменты.

Это баланс между тенденциями NIH (не изобретенными здесь) и выбрасыванием хороших, устоявшихся сценариев в пользу более надежного решения.

И последнее, о чем следует помнить: как соотносится ваш технологический стек, когда вы пытаетесь привлечь в команду больше людей. Поиск людей, имеющих опыт работы с Ansible, намного проще, чем поиск людей, имеющих опыт работы с вашим конкретным инструментом CM для сценариев собственного производства. Это не чисто технический вопрос, а скорее культурный. Вы хотите быть странной организацией, которая изобретает свой собственный Ansible, или вы хотите быть разумной организацией, которая находит правильный инструмент для работы? Эти решения влияют на вашу способность привлекать таланты.


4
Понравился твой ответ; Я также хотел бы упомянуть, что, если команда bash стремится к идемпотентности, управлению выполнением и повторному использованию, в основном создавая собственную структуру управления конфигурациями, это сопряжено с затратами, и мы все знаем, что это может стать очень неприятным для собственных проектов ,
ᴳᵁᴵᴰᴼ

Я также подписываюсь на ваш ответ, особенно положив в баланс имеющийся опыт. У меня есть две маленькие критики: во-первых, это идемпотентность. Это, конечно, важный аспект систем конфигурации, но, поскольку можно использовать любые возможные команды оболочки в разных сборниках, система в лучшем случае может побуждать использовать идемпотентность. (На самом деле мы хотим что-то более мощное, чем idempotency aba = ab .) Во-вторых, надежное управление удаленным выполнением может быть совершенно неактуальным в некоторых важных случаях, например, при реализации шаблона неизменяемого сервера с использованием образов экземпляра.
Михаэль Ле Барбье Грюневальд,

13

Приведенный выше ответ покрывает часть этого, но пропускает один из важных элементов: конвергентный дизайн. Некоторое время назад я написал несколько слов об этом в контексте Chef по адресу https://coderanger.net/thinking/, но короткая версия заключается в том, что bash-скрипт - это набор инструкций, а Ansible playbook (или рецепт Chef, Salt). состояние и т. д.) - описание желаемого состояния. Документируя желаемое состояние, а не шаги, которые вы хотите предпринять, чтобы получить его, вы можете справиться с гораздо большим количеством начальных состояний. Это было сердцем Теории Promise, как обрисовано в CFEngine давно, и дизайн, который мы (инструменты управления конфигурацией) только что копировали с тех пор.

tl; dr Ansible-код говорит, что вы хотите, bash-код говорит, как что-то сделать.


2
Можете ли вы также добавить ссылку на «теорию обещаний», такую ​​как книги или статьи, и любой другой ценный материал, если кто-то хочет узнать об этом?
Евгений

1
Это на самом деле то, на что я ссылался, когда говорил, что вы можете написать идемпотентный код bash (то есть он может запускаться в любой точке, запускаться несколько раз и сходиться в нужное состояние). Но ваш ответ сделал это намного яснее.
Ассаф Лави

Да, идемпотентность является важным свойством конвергентных систем, но они не всегда напрямую связаны между собой :) что касается материалов по теории обещаний, у Марка Берджесса (создателя CFEngine) есть несколько книг, и я могу найти ссылки, когда вернусь к ноутбук.
Coderanger


3

Стоит отметить, что у вас будет меньше проблем с запуском ваших сборников игр на удаленных хостах. Как это главная причина для запуска ANSIBLE. Когда вы используете сценарии оболочки, вам все равно нужен способ сценария scp'ing на удаленном хосте.


Разве Ansible не является просто оберткой вокруг ssh в этом смысле?
Евгений

По сути, да. Он делает ssh, копирует скрипты Python удаленно и запускает их. Это означает, что, между прочим, если ваш ansible модуль зависит от некоторой библиотеки python, эта библиотека должна присутствовать на удаленной машине при некоторых обстоятельствах.
Ассаф Лави

1
И если вы испортили конфигурацию ssh, вы заблокированы на своем компьютере, обычный недостаток push vs pull.
Тенсибай

1

Это 2019 год, и я только что провел несколько дней на кривой обучения, и вот абсолютная правда: Ansible не стоит хлопот.

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

Если вам не требуются какие-либо из его функций, кроме предоставления, и вы когда-либо выполняете подготовку только на одной конкретной ОС. Ради бога напишите приличный shell.script.

На данный момент весь проект напоминает мне о ранних форумах по Linux, где новичкам сообщали RTFM и высмеивали вопрос, почему кто-то не может написать графический интерфейс для настройки параметров графики. Ты просто не понимаешь? Вы должны придерживаться окна ... возможно, я буду спариваться .. счастливого пути.

Используйте Docker. В предпочтении ко всему. Докер невероятно простой и мощный.

Но что, если вы абсолютно обязаны обеспечить на уже существующей олова? Каковы реальные альтернативы?

Ну ... пока их нет. Но я пообещаю вам это, если ANSIBLE не станет лучше, скоро будет. Потому что как бы фанаты ни давили на него и не прощали его неудачи ... это 5 из 10 усилий.

SCP до сценария bash и избавить себя от неприятностей.


Сначала он работает на Windows через Win_RM или SSH. Во-вторых, синтаксис yaml очень приятен и может быть сгенерирован программно, и хотя некоторые из ошибок могут вводить в заблуждение, они ничем не отличаются от Java или Python, пытающихся вывести себя из себя во время исключения. В-третьих, понятие просто SCPing сценария на сервере неприменимо в высокодинамичных облачных средах. Какой сервер? Серверы могут меняться каждый день. Ansible позволяет легко настраивать плагины инвентаризации с простыми способами группировать серверы и назначать им переменные. Я не думаю, что Ansible не стоит этого. Я думаю, это излишне для вашей среды.
Леви

@ Леви да. Я виноват в том, что ansible не работает в Windows, имеет конфигурацию, в которой нет схемы, и имеет более длительную кривую обучения и более высокие затраты на обслуживание, чем любой специальный метод для достижения той же задачи.
Ричард

Для облачных сред существуют другие подходы для типов крупных предприятий, которые могут оправдать кривую обучения. Я понимаю, что делает ANSIBLE. Я просто не вижу ниши.
Ричард

Ниша - это простая в использовании инфраструктура автоматизации для нескольких машин. Это не так хорошо для Windows, как для Linux. Также это не хорошо для MSDOS и Netware. Сейчас 2019 год, Windows-серверы - маленькая бесполезная ниша в наши дни.
Дясный
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.