Чим Ansible відрізняється від просто запуску резервної оболонки bash у Vagrant?


39

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

Чи є істотні відмінності та вагомі причини почати використовувати Ansible vs. продовжувати писати сценарії оболонки?

Відповіді:


29

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

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

Мій висновок полягає в тому, що для сценаріїв оболонки Ansible по суті пропонує 1. Можливість перевірити, чи відповідає система бажаному стану, 2. можливість інтегруватися з Ansible Tower, яка є платіжною системою, яка, схоже, включає можливості моніторингу. У деяких важливих випадках, наприклад, при реалізації незмінного шаблону сервера, точка 1, ймовірно, не дуже корисна, тому список досить тонкий.

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

Але це, можливо, лише доводить, наскільки поганий вступний матеріал!

Відео для швидкого запуску:

Існує відео швидкого запуску . Починається зі сторінки, що стверджує, що… ну це насправді не заявки, це списки куль, артефакт, який зазвичай використовується для призупинення критичного судження у презентаціях (оскільки логіка не показана, її не можна критикувати!)

1. Відповідь проста:

1.1 Автоматизація, зрозуміла для людини - Технічні характеристики - це технічні документи

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

бути простішим для читання, ніж відповідне виклик yum, знайдене в оболонці-скрипті? Крім того, кожен, хто мав контакт з AppleScript, вмирає, сміючись, читаючи "автоматизацію, зрозумілу людині".

1.2 Не потрібно спеціальних навичок кодування - Що таке кодування, якщо не писати формальних специфікацій? У них є умовні умови, змінні, так, як це не кодування? І навіщо мені потрібно щось, чого я не можу запрограмувати, що відтепер було б негнучким? Заява щасливо неточна!

1.3 Завдання, що виконуються в порядку - ну, можливо, деякі прихильники кодогольфа знають про мови, які виконують завдання безладно, але виконання завдань навряд чи виглядає винятково.

1.4 Швидко отримуйте продуктивність - кваліфіковані програмісти оболонок зараз продуктивні. Цей контр-аргумент настільки ж серйозний, як і початковий аргумент.

2. Відповідальний є потужним

Популярний фокус продавця, щоб продати артефакти, - це обдурити людей у ​​вірі, що вони набудуть "сили" цих артефактів. Історія реклами автомобілів чи ізотонічних напоїв повинна наводити переконливий перелік прикладів.

Тут Ansible може зробити "розгортання додатків" - але сценарій оболонки, безумовно, "управління конфігурацією", але це лише твердження про ціль інструменту, а не функцію та "оркестрацію робочого процесу", яка виглядає трохи претензійно, але жодного прикладу не йдеться понад те, що може зробити GNU Parallel .

3. Відповідь - не агент

Щоб заповнити стовпчик, вони написали за трьома різними способами, що для цього потрібен лише ssh, який, як всі знають, є демоном і не має нічого спільного з цими агентами, що пронизують управління конфігурацією світу!

Решта відео

В іншому відео представлені описи, які є статичними списками ресурсів (наприклад, сервери) і демонструє, як розгортати Apache на трьох серверах одночасно. Це дійсно не відповідає тому, як я працюю, де ресурси дуже динамічні і можуть бути перераховані інструментами командного рядка, наданими моїм хмарним провайдером, і спожиті моїми функціями оболонки за допомогою |оператора труби . Крім того, я не розгортаю 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

Відповідний скрипт оболонки був би по суті ідентичним 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: «Відповідальні ресурси - це моделі бажаного стану. Таким чином, не слід перевіряти, чи запускаються послуги, встановлюються пакети чи інші подібні речі. Відповідною є система, яка забезпечить, щоб ці речі були декларативно правдивими. Натомість зафіксуйте це у своїх ігрових книгах. "Тепер це стає трохи цікаво, але:

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

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

Нерозгадане занепокоєння: ремонтопридатність

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

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

Ідентифікація кроків налаштування

Документація Ansible звертає увагу на необхідність написання невмілих кроків конфігурації. Точніше, кроки конфігурації повинні бути записані так, щоб послідовність кроків aba можна було спростити до ab , тобто нам не потрібно повторювати етап налаштування. Це сильніший стан, ніж ідемпотенція. Оскільки Ansible дозволяє програвачам використовувати довільні команди оболонки, сам Ansible не може гарантувати, що ця суворіша умова буде дотримана. Це покладається лише на дисципліну програміста.


Це здається посібником ... вражаюче!
Pierre.Vriens

4
Я не міг більше погодитися. Ми використовували Ansible вже більше 1 року і зараз використовуємо Docker-контейнери, побудовані з хорошими, простими старими скриптами bash. Визначення стану - це, на мій погляд, і найцікавіша особливість, але, як ви вже згадували про це, - так багато служб, які не мають відповідного модуля Ansible, так що вам завжди доведеться відмовлятися від команд bash. І так, ми також розгортаємо на серверах лише незмінні контейнери, тому визначення стану насправді не є корисною у цьому випадку.
Андреас

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

1
@Andreas Я погоджуюся, що у вас все ще є багато випадків, коли вам потрібно повернутися до оболонки або командних модулів, що не означає, що ваша відповідальна гра не може бути ідентичною. Самі основні модулі підтримують ідентифікацію, просто перевіряючи, чи слід діяти. Ви можете зробити те ж саме, що ви працюєте з оболонкою або командним модулем, спершу запустивши завдання, яке перевіряє, чи слід щось робити, і зареєструвавши його вихід, потім виконавши умовне виконання другого завдання, виходячи з результатів першого завдання.
Леві

1
@ MichaelLeBarbierGrünewald, я повинен погодитись, коли я працював з Ansible, було справжнім болем працювати, і його робота потребує тижнів, щоб зібрати ігрову книжку разом, щоб підключитися до інфраструктури моєї колишньої хмарної компанії, надавши linux дистрибутиву, встановити LAMP / LEMP або інше. Після того, як він був завершений, це заощадило нам час, але потрібен був місяць як раз, щоб підняти його та запустити. Ніхто з нас не був майстрами баскетболів, щоб це не було альтернативою.
Даніель

22

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

Якщо команда може досягти речей, які пропонує Ansible з оболонкою:

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

тоді, можливо, вони могли б дотримуватися того, що знають.

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

Це врівноваження між тенденціями NIH (тут не винайдено) та викиданням добрих, встановлених сценаріїв на користь більш надійного рішення.

Останнє врахування, яке слід пам’ятати: як вимірюється стек технологій, коли ви намагаєтеся набрати більше людей до команди. Знайти людей, які мають досвід Ansible, набагато простіше, ніж знайти людей, які мають досвід у вашому конкретному домашньому інструменті сценаріїв CM. Це не суто технічний розгляд, скоріше культурний. Ви хочете бути дивним органом, який вигадує власну відповідь, чи ви хочете бути розумним органом, який знаходить правильний інструмент для роботи? Ці рішення впливають на вашу здатність малювати талант.


4
Сподобалась ваша відповідь; Я також зазначив, що якщо команда bash збирається на ідентифікацію, керування виконанням та повторне використання, в основному, написання власної системи управління конфігурацією, це пов'язано з витратами, і всі ми знаємо, що це може стати дуже неприємним для внутрішніх проектів. .
ᴳᵁᴵᴰᴼ

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

13

Вищенаведена відповідь охоплює її частину, але пропускає один із важливих елементів: збіжний дизайн. Я писав кілька слів про це в контексті шеф-кухаря на цьому веб- сайті https://coderanger.net/thinking/, але коротка версія полягає в тому, що сценарій bash - це набір інструкцій, в той час як ігрова книга Ansible (або рецепт шеф-кухаря, сіль стан тощо) - це опис потрібного стану. Задокументувавши стан, який ви хочете, а не кроки, які ви хочете зробити, щоб дістатися до нього, ви можете впоратися з набагато більшою кількістю стартових станів. Це було основою Теорії обіцянок, як це було давно викладено у CFEngine, і дизайну, який ми (інструменти управління конфігураціями) ми тільки що копіювали.

tl; dr Відповідний код говорить те, що ви хочете, bash code говорить, як зробити щось.


2
Чи можете ви також додати якісь посилання на "теорію обіцянок", наприклад, книги чи статті та будь-який інший цінний матеріал, якщо хтось хоче дізнатися про це?
Євгеній

1
Це власне те, на що я натякав, коли сказав, що ви можете написати idempotent bash-код (тобто, який можна починати в будь-якій точці, запускати кілька разів і конвертувати в потрібний стан). Але ваша відповідь зробила це набагато зрозуміліше.
Ассаф Лав'є

Так, idempotence є важливою властивістю конвергентних систем, але обидві не завжди безпосередньо пов'язані :) що стосується матеріалів про Теорію обіцянок, Марк Берджес (творець CFEngine) має кілька книг, я можу знайти посилання, коли я повернувся в ноутбук.
кодерангер


3

Варто зауважити, що у вас буде менше проблем із запусканням ваших чутливих ігор на віддалених хостах. Оскільки це головна причина запуску ансиле. Коли ви використовуєте сценарій оболонки, вам все одно потрібно мати спосіб скриптування scp'ing на віддалений хост.


Чи не відповідає в цьому сенсі лише обгорткою навколо ssh?
Євгеній

По суті, так. Він робить ssh, віддалено копіює сценарії python та запускає їх. Це означає, btw, що якщо ваш ansible модуль залежить від якоїсь бібліотеки python, ця бібліотека повинна бути присутня на віддаленій машині за певних обставин.
Ассаф Лав'є

1
І якщо ви зіпсуєте конфігурацію ssh, ви заблоковані з машини, звичайний недолік push vs pull.
Тенсібай

1

Настав 2019 рік, і я щойно провів кілька днів на кривій аннзивного навчання, і ось абсолютна істина: Ansible не вартує клопоту.

він не закінчений, він не працює на Windows, а поєднання конфігурації YAML та оманливих повідомлень про помилки зробить ваш погляд кровотоком. Це здається майже навмисно жахливим, і я маю на увазі це серйозно. Очевидно, це продукт проекту Redhat sysadmins, який розчарував розробник. Напевно, хіпстер.

Якщо вам не потрібні будь-які з її функцій, окрім резервування, і ви лише надаєте доступ до однієї конкретної ОС. На жаль, напишіть гідний shell.script.

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

Використовуйте Docker. У перевагу чому завгодно. Докер надзвичайно простий і потужний.

Але що робити, якщо ви обов'язково повинні забезпечити наявну олово? Які реальні альтернативи?

Ну ... ще немає. Але я пообіцяю вам це, якщо тільки не стане кращим, швидше буде. Тому що, як би сильно не натискали фанати, і пробачте, що це невдачі ... це 5 з 10 для зусиль.

SCP створити сценарій bash і врятувати себе від неприємностей.


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

@Levi так. Я все мою вину в тому, що ansible не працює на Windows, має конфігурацію, яка не має схеми, і, має більш довгу криву навчання та більш високі витрати на обслуговування, ніж будь-який замовлений спосіб досягнення тієї ж задачі.
Річард

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

Ніша - це проста у використанні система автоматизації для декількох машин. Це не так чудово для Windows, як для Linux. Також це не чудово підходить для msdos та мереж. Це 2019 рік, сервери Windows - це маленька марна ніша в наші дні.
діасний
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.