Plays against different server groups in playbook

Dimitri Yioulos

unread,

Oct 1, 2015, 3:18:38 PM10/1/15

to Ansible Project

I'm creating a playbook to update, then reboot, a group of windows servers (serversA). Prior to reboot, however, I have to stop a couple of services on another group of windows servers (serversB). This is what I'd like to happen when I run "ansible-playbook -l serversA playbook.yml":

where playbook.yml:

- hosts: serversA

gather_facts: false

tasks:

- name: win update

win_updates:

category: ['SecurityUpdates','CriticalUpdates','Updates','Tools','DefinitionUpdates','UpdateRollups']

register: reboot_hint

- hosts: serversB

gather_facts: false

tasks:

- name: check for XYZ service

raw: sc query XYZ

register: xyz_hint

failed_when: xyz_hint.rc not in [0,1060]

- name: stop XYZ and ABC services <-- if XYZ service is installed, so is ABC

win_service: name={{ item }} state=stopped

with_items: ["XYZ", "ABC"]

when: xyz_hint.rc == 0

- hosts: serversA

gather_facts: false

tasks:

- name: reboot server

raw: 'cmd /c shutdown /r /t 0'

when: reboot_hint.reboot_required == true

Can I do this in a single playbook? If not (or if this is set up incorrectly, and I'm sure it is), then how?

Thanks!

Brian Coca

unread,

Oct 1, 2015, 4:16:20 PM10/1/15

to Ansible Project

you can have multiple plays per playbook, that is actually how it is
defined playbook = container for 1 or more plays.

--
Brian Coca

Josh Smift

unread,

Oct 1, 2015, 4:23:14 PM10/1/15

to ansible...@googlegroups.com

BC> you can have multiple plays per playbook, that is actually how it is
BC> defined playbook = container for 1 or more plays.

I was just thinking about something that this seems like an opportune time
to ask about:

It seems that if you have multiple plays, some of which target different
hosts, and if all of the hosts in *one play* fail, that fails the entire
playbook. Is that still true, and is there a way to overide that behavior?
(I did a bit of searching, and saw some questions in the archive from a
year or more ago which implied that there wasn't a way to override it.)

Our particular use case is that we have a playbook to check that our
systems are in synch with how we expect them to be, with a play for each
type of system, and sometimes one of those plays will fail for some minor
intermittent reason -- it only targets one host and that host is down,
etc. It'd be nice if the rest of the playbook could continue in that case.

-Josh (j...@care.com)

This email is intended for the person(s) to whom it is addressed and may contain information that is PRIVILEGED or CONFIDENTIAL. Any unauthorized use, distribution, copying, or disclosure by any person other than the addressee(s) is strictly prohibited. If you have received this email in error, please notify the sender immediately by return email and delete the message and any attachments from your system.

Dimitri Yioulos

unread,

Oct 2, 2015, 9:29:14 AM10/2/15

to Ansible Project

Hi, Brian.

Yes, I understand about the playbook running one or more plays. What I didn't understand (and this is another of my embarrassing mistakes) is that I shouldn't have identified any servers or groups when running the playbook, as in "ansible-playbook -l serversA playbook.yml" but, rather, run it thusly, "ansible-playbook playbook.yml". That, of course, let's Ansible apply the plays to the servers or groups that are specified in the plays. Arrgh. Hope I'm not using up all of my goodwill on the list.

Dimitri

Brian Coca

unread,

Oct 2, 2015, 10:08:06 AM10/2/15

to Ansible Project

Dimitri,

not sure what you mean by "ansible-playbook -l serversA playbook.yml"

don't worry about using up goodwill, i never had any to begin with ....
--
Brian Coca

Dimitri Yioulos

unread,

Oct 2, 2015, 10:58:49 AM10/2/15

to Ansible Project

Hey, Brian.

I was using the "l" switch, thereby limiting the playbook run to a subset of servers. In this case, there was no need for such limiting (and, in fact, it caused the playbook to work incorrectly). How stupid of me. So, allow me to post the entire playbook:

---

- hosts: admin2

gather_facts: false

sudo: yes

tasks:

- nagios: action=downtime minutes=20 author="Dimitri Yioulos" service=host host={{item}}

with_items: "{{ groups['sqlservers'] }}"

delegate_to: admin2

tags:

- nagios_downtime

- nagios: action=downtime minutes=20 author="Dimitri Yioulos" service=all host={{item}}

with_items: "{{ groups['sqlservers'] }}"

delegate_to: admin2

tags:

- nagios_downtime

- hosts: sqlservers

gather_facts: false

tasks:

- name: copy logoff script to servers

win_copy: src=/etc/ansible/files/Logoff-Users.ps1 dest='c:\temp\Logoff-Users.ps1'

tags:

- copy_script

- name: log off users

raw: '@powershell c:\temp\Logoff-Users.ps1'

tags:

- userlogoff

- name: win update

win_updates:

category: ['SecurityUpdates','CriticalUpdates','Updates','Tools','DefinitionUpdates','UpdateRollups']

register: reboot_hint

tags:

- update

- hosts: lyris

gather_facts: false

tasks:

- name: check for Lyris service

raw: sc query ListManager

register: lyris_hint

failed_when: lyris_hint.rc not in [0,1060] # 1060 == Service not installed

tags:

- lyris_stop

- name: stop Lyris services

win_service: name={{ item }} state=stopped start_mode=manual

with_items: ["ListManager", "LyrisAlert"]

when: lyris_hint.rc == 0 # ie, the ListManager service is installed

tags:

- lyris_stop

- name: kill LyrisConsole process

raw: taskill /f /im LyrisConsole.exe

tags:

- lyris_stop

- hosts: sqlservers

gather_facts: false

tasks:

- name: reboot server

raw: 'cmd /c shutdown /r /t 0'

when: reboot_hint.reboot_required == true

As you can see, there are several things going on here: put servers in downtime in Nagios; put a remote user logout script on the servers, run the script, then apply Windows updates; stop a particular service, and stop a small program, on another set of servers (must be done; I'll skip the explanation) and, finally; reboot the servers if the installed updates require same. Some of this is based on answers to previous questions I've posted (thanks, all, so much). I'm not sure if it's the cleanest, or most elegant, way to do all of that stuff, but the playbook does work. At the end of the day, that's what counts.