Я новый пользователь Ansible и до сих пор наслаждаюсь им. Я использую Ansible для определения и применения конфигураций веб-сервера. Я использую плейбуки. Скажем, у меня есть роль для установки и настройки Nginx, задачи определены в roles/nginx/tasks/main.yml и ссылается на ./site.yml поэтому они всегда работают, когда я предоставляю новые серверы. Примерно так: https://github.com/ansible/ansible-examples/tree/master/wordpress-nginx/roles/nginx. Это отлично работает, но иногда я хочу явно остановить, запустить или перезапустить Nginx. Я знаю, как добиться этого с помощью Ansible, но мой вопрос касается условностей или общепринятых практик. Нужно ли мне...
A. Создавать задачи запуска, остановки и перезапуска внутри папки роли Nginx? И если да, то как мне их объявлять и вызывать. Ясно, что мне не следует просто добавлять их в main.yml, иначе они будут вызываться всякий раз, когда я инициализирую новый сервер. Должен ли я создать roles/nginx/tasks/start.yml, roles/nginx/tasks/stop.yml и т.д. и вызывать их как ansible-playbook -i staging nginx/roles/stop.yml.
Б. Или мне следует не объявлять их в playbook, а выполнять их с помощью ansible, лайк ansible webservers -i staging -a "nginx stop" -s.
C. Любые другие предложения по наилучшему способу достижения этой цели.
Спасибо ( :
Если это специальное действие, ваша среда небольшая и не очень сложная, все участники проинформированы, вы хотите вернуться в нормальное состояние через две минуты, и вы не возражаете, если следующий доступный запуск изменит это (например, остановленный service перезапускается, потому что об этом говорится в определении состояния службы в вашем анзибле), затем переходите к Б. Имейте в виду, что вы меняете состояние системы, отличное от того, что говорится в вашем описании в анзибле
Если вы хотите прояснить ситуацию, решение А - хорошая отправная точка. Вы можете создать соответствующие определения для nginx, который остановлен, запущен и т. Д., Но в целом это похоже на B, только задачи определены в некоторых файлах.
Что касается C, вы можете развить A немного дальше: сделать состояние зависимым от переменной. Таким образом, вы можете сделать желаемое состояние явным в своей доступной конфигурации. Почему переменная, а не изменение состояния в определении службы? В более сложных сценариях (например, запуск / остановка нескольких служб вместе) это помогает упростить и упростить задачу. Если у вас несколько сред (промежуточная, производственная,…), это упрощает сохранение определений одинаковыми при изменении состояния только в одной среде.
Явность вещей дает некоторые преимущества:
это задокументировано, чтобы другие (и вы в будущем) могли видеть
запуск ansible независимо от вашей задачи не будет мешать (если у всех есть текущее состояние)
если вы запускаете ansible автоматически - запускается из контроля версий - вы можете использовать это, чтобы изменить свое состояние, а также вернуть изменение
Необязательно держать каждую задачу в одной роли. Кроме того, если вы обращаетесь к роли для подмножества ее задач, это кажется уродливым нарушением абстракции. Я знаю, я это сделал.
Например, плейбук веб-обновлений может со своими собственными задачами копировать содержимое в корневой каталог и при необходимости перезапускать nginx.
Что особенно важно, так это описание всего состояния в одной книге. Вызовите роль nginx и скопируйте в post_tasks контент для этого конкретного веб-сайта. Ваш веб-сайт будет там, при необходимости установив nginx. Этот перезапуск nginx был просто побочным эффектом при вызове задачи-обработчика.