1

I'm a new Ansible user and enjoying it so far. I'm using Ansible to define and apply webserver configurations. I'm using playbooks. Say I have a role to install and configure Nginx, the tasks are defined at roles/nginx/tasks/main.yml and referenced from ./site.yml so they always runs when I provision new servers. Something like this example: https://github.com/ansible/ansible-examples/tree/master/wordpress-nginx/roles/nginx. That's working great but on occasion I want to explicitly stop, start or restart Nginx. I know how to achieve this using Ansible but my question is around conventions or common practices. Should I...

A. Create start, stop and restart tasks inside the Nginx role folder? And if so how should I declare and invoke them. Clearly I shouldn't just add them to main.yml or they'll be invoked whenever I provision a new server. Should I create roles/nginx/tasks/start.yml, roles/nginx/tasks/stop.yml etc and invoke them like ansible-playbook -i staging nginx/roles/stop.yml.

B. Or should I not declare these in a playbook but rather execute them using ansible, like ansible webservers -i staging -a "nginx stop" -s.

C. Any other suggestions on the best way to accomplish this.

Thanks so much ( :

Stefan Moch
  • 84
  • 7
Bruce
  • 135
  • 1
  • 6

2 Answers2

2

If it is an ad hoc action, your environment is small and not very complex, everyone involved is informed, you want to be back to normal in two minutes, and you do not mind if the next ansible run would change this (e.g. the stopped service is restarted, because the service state definition in your ansible playbook says so), then go ahead with B. Be aware that you change the system state diverging from what your description in ansible says …

If you want to make things more clear, solution A is a good starting point. You can create the appropriate definitions for nginx stopped, started, etc., but all in all it is like B, just that the tasks are defined in some files.

As for C, you can develop A a bit further: make the state dependent on a variable. This way you can make the desired state explicit in your ansible configuration. Why a variable and not changing the state in the service definition? In more complex scenarios (say starting/stopping multiple services together) it helps you keeping things clear and simple. If you have multiple environments (staging, production, …), this makes it easy to keep the definitions the same while changing the state in one environment only.

Making things explicit offers some advantages:

  • it is documented for others (and your future self) to see

  • running ansible independently of your task will not interfere (given everyone has the current state)

  • if you run ansible automatically – triggered from version control –, you can use this to make your state change and also the change back

Stefan Moch
  • 84
  • 7
0

Keeping every task about a thing in one role is not required. Also, if you reach inside a role for a subset of its tasks, it feels like an ugly breach of abstraction. I know, I have done it.

For example, a web update playbook could, with its own tasks, copy in the content to the web root, and restart nginx if required.

What gets particularly powerful is describing the entire state in one playbook. Call role nginx, and in post_tasks also copy in the content for this particular web site. Your web site will be there, installing nginx if necessary. That nginx was restarted was simply a side effect when the handler task was called.

John Mahowald
  • 32,050
  • 2
  • 19
  • 34