I added 2 hostname in groupname of inventory file.
For example
[db]
10.0.1.1
10.0.1.2
and I run playbook file already into these two hosts.
Now I want to add more host (10.0.1.3) into db group and run playbook file for this new host.
Are there any ways that I can run playbook file for only 10.0.1.3 without comment out 10.0.1.1 and 10.0.1.2 because they are installed already.
The beauty of Ansible is that it’s idempotent - meaning if you run the playbooks more than once, it will see that that changes are already there, and not repeat the work. You just have to be sure that your playbooks are designed correctly.
Thank for your explanation so much. So in my case, after add more host (10.0.1.3) it only install packages that designed in playbook on 10.0.1.3 only, right?
Hi,
To target specific hosts, you could either adjust hosts
key on your play block (from your playbook), or use —limit
(-l
for short) flag on ansible-playbook
command line.
Depends on the modules you used and / or how you wrote your playbooks / roles; most modules are idempotent, as suggested above, but it’s not always the case. Sometimes you have to add your own logic on top to prevent tasks to trigger a change.
Hi,
In normal playbooks you can just use ‘–limit’ option like @ptn said.
In AWX you have to go to: Templates>Launch> Other prompts and fill ‘Limit’ section.
Could you tell me which case?
Could you tell me more detail and example what we add?
This is entirely dependent on what you are doing in the playbook or individual tasks. The best to do is to test - run your playbook against a test server multiple times, and if it changes things multiple times, then add tasks/code that run checks first, and use conditionals on when to run tasks.
As hinted by @jrglynn2 , it depends. I wont give you a full list, but here is an example; amazon.aws.ec2_instance module’s count
parameter makes it that your task will always spawn more instances, thus making it not idempotent. Using exact_count instead will.
As for your second inquiry, again, not a complete list, but you can use mechanisms like when:
keyword, some specific jinja filters, or even run a task undoing what you did with changed_when: false
to that end. If that doesn’t click, ping me and I’ll write an example playbook to show you.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.