В чем преимущество простого Ansible по сравнению с обычными сценариями оболочки, если не используются совместно поддерживаемые роли Ansible-Galaxy? [закрыто]
Вы также можете остановиться на своем решении:
cat temp.txt | grep ^$labelNum | awk '{print $2}'
Которое будет соответствовать началу строки или
awk '/^'$labelNum'/{print $2}' temp.txt
Будет работать одинаково, но внутри awk экранирование сложное.
Я не думаю, что есть большая проблема с 20 строками в качестве сценария оболочки для отдельной машины или двух. Это хорошо иметь.
Тем не менее, ваш сценарий не является идемпотентным. Например, он использует apt-get upgrade foo, который может выполнять изменения, даже если скрипт уже был запущен в этой системе. Я не думаю, что стоит использовать apt-get upgrade foo. Эта команда не гарантирует применение обновлений безопасности или исправлений к вашим зависимостям.
Тщательно написанный плейбук Ansible можно использовать как небольшую проверку системы. Это зависит от того, что playbook является идемпотентным (, а также от того, что он точно сообщает об «измененном» статусе ). Выполнение ansible-playbook --checkпокажет, соответствует ли система всем заданным задачам или она была изменена. Это может быть полезно позже, а также для поиска несоответствий сразу после запуска playbook.
И вы можете настроить Ansible, чтобы запускать его на нескольких машинах одновременно.
Инструменты настройки, такие как Ansible, полезны при масштабировании. Отчасти из-за таких особенностей. Отчасти из-за такого рода ограничений, которым он побуждает вас следовать.
Поощрение вас к написанию идемпотентных скриптов также может быть полезно для обслуживания. Рассмотрим искушение написать сценарий, который добавляет строки в существующий файл (или добавляет токены внутрь существующей строки :-(). Если вы обеспечиваете идемпотентность, то вы можете повторно -запустить измененный сценарий без добавления повторяющихся строк.
Еще одно ограничение — если вы когда-нибудь захотите удалить что-то из установленной системы.Во многих случаях это не проблема, и вы всегда можете написать сценарий удаления или сценарий удаления позже. Но в некоторых случаях с этим нужно быть осторожным. Например. вы можете убедиться, что не используете Ansible lineinfileдля замены отдельной строки, а вместо этого перезаписываете весь файл своей собственной версией. Это может быть полезно, если вы больше не хотите менять строку A по умолчанию, но все же хотите изменить строку B.
В моем случае я хотел бы решить проблему удаления при управлении брандмауэрами. Если вы перестанете разрешать порт в своем сценарии установки, вы можете забыть явно заблокировать порт везде. Модуль Ansible ufwздесь не поможет, потому что позволяет только добавлять или удалять отдельные правила. В настоящее время я думаю об использовании альтернативы брандмауэру ufw, который имеет надлежащую поддержку работы с файлами конфигурации. (. firewalld, shorewall, ferm... ).
Разница между Bash и Ansible заключается в том, что Ansible при правильном написании является идемпотентным. Нет никаких изменений, когда плейбук запускается повторно. В этом отношении скрипт Bash описывает процедуру, в то время как плейбук Ansible скорее описывает состояние системы.
Чтобы ответить на комментарий
"not sure I understand idempotent well enough to understand the answer".
Идемпотентность означает, что сценарий «может быть применен несколько раз без изменения результата после первоначального применения». Лучшей практикой является запуск playbook дважды. Во время первого запуска playbook выполняет все изменения. Во время второго запуска никаких изменений не должно быть сообщено.
Одно из основных преимуществ Ansible заключается в том, что плейбуки, как правило, легче читать, чем плотные однострочники BASH, благодаря использованию синтаксиса YAML. Вы также можете использовать линтеры и отладчики более многофункциональным способом, чем вы можете использовать скрипты BASH, а некоторые IDE даже имеют встроенные модули завершения текста Ansible для помощи в написании плейбуков.