Choosing hosts in Ascender and Ansible
Which machines does a playbook actually touch? This lesson lays out the layers in Ansible and Ascender. An inventory is the big list of every host that could be operated against, file-based in INI or YAML on the command line and stored in the database in Ascender. The hosts section at the top of a playbook narrows that to a subset, and it can name individual hosts, groups, or a comma-separated mix. Groups keep playbooks generic and carry group-level variables, such as connection details for Cisco IOS devices or everything behind a web application. Limit, available on the CLI and in Ascender job templates, narrows the result further.
Greg Sowell's preferred pattern is hosts: all with the limit field doing the targeting, so the playbook never needs editing. The danger is obvious: forget the limit and an access-list change could hit firewalls and backbone routers. His safeguard is an assert task that compares the length of ansible_play_hosts_all to the all group and fails if they match.
The demo runs a job template three ways: with no limit it fails on the assertion, with a single host in the limit it passes, and with prompt on launch enabled the limit becomes a pre-filled, editable popup that still fails safely when blanked out. Anyone writing reusable playbooks gets a simple guard against accidental fleet-wide runs.
Key takeaways
- An inventory lists every host that could be targeted; the playbook hosts section selects a subset; limit narrows it further.
- Groups let a playbook reference one name instead of a hundred hosts and can hold variables like connection settings.
- The all group exists implicitly in every inventory, so hosts: all with a limit keeps playbooks generic but is risky.
- An assert on the length of ansible_play_hosts_all versus the all group fails the job when no limit was applied.
- Enabling prompt on launch for limit shows a pre-filled popup at launch, and the assert still catches an empty value.
Questions this video answers
What is the difference between an inventory, the hosts section and limit in Ansible?
The inventory is the full list of hosts a job could operate against. The hosts section at the top of a playbook picks a subset, using host names, group names or both. Limit, available on the CLI and in an Ascender job template, restricts the matched hosts even further without editing the playbook.
How can you prevent a playbook from accidentally running against all hosts?
Add an assert task at the start that checks the length of ansible_play_hosts_all is less than the size of the all group. If the job launches without a limit, the assertion fails and the run stops before any changes are made. The demo shows exactly this failing and then passing once a limit is set.
What does prompt on launch do for the limit field in Ascender?
It pops up a box when the job template is launched so the limit can be filled in or changed at run time. Any value already in the field appears as the default, and it can be overridden or blanked, in which case the assert guard in the playbook still stops the run.
This video is part of the Ascender Pro playlist. Browse every CIQ video by product and topic.
Transcript
foreign I'm Greg Sowell and I'm here with another ciq demo today I'm going to be talking about choosing hosts in Ascender or ansible it actually kind of works the same in both of them and they actually kind of work in tandem so I'm going to show you a little bit of that but first i'm going to slide deck queue so let's start by talking about the difference between inventories and hosts right so inventories if you're doing on the CLI it's going to be kind of a file base that can either be an ini format or in yaml right and so it's really just an
inventory is a big list of all the hosts that could potentially operate against now you can have multiple inventories right it doesn't mean you have to have one giganto inventory you can actually maintain multiple and I think most people probably do in their environments I know what I do so if it is CLI ansible you're going to be doing it file based if you're using Ascender it's actually stored in the database and to be perfectly honest it's easier in Ascender the way it breaks everything out and we'll take a look at that here in a little bit but again all of the hosts I could
potentially operate in this job right in this automation so there also is a host section inside of your playbook right it's at the very top and really what you're doing is you're designating a subset of hosts you're going to operate against inside that inventory right so inventory big Master list host section in a Playbook I'm narrowing down which individual hosts I'm actually going to operate against let's talk a little bit more about that host section itself so it can be a comma separated list of hosts right you can put all of them in there but imagine you have a hundred hosts do you actually want
to put all 100 of them in the list you probably don't and so inventories in ansible have this concept called groups so it makes it easier to group things together for multiple reasons and one of those specific reasons is in that host section I can actually just put a group name instead of all 100 of those hosts I can put one group name that also means if I add a host to that group where I remove one if I rerun the automation it's still going to run against that group right I don't have to actually go in and and edit my playbook host section right
View full transcriptHide full transcript
so it makes it very easy there as well as the group section can actually maintain variables specific for that group right so you could think of it as all of my Cisco iOS devices I put in there and I put the variable information in that group for connection information or it could be I have a web application and I want to group all the servers associated with that web allocation together right you kind of get the idea now the host action again I said you could put commless separated list of hosts or groups because June actually mix and match so you can have groups and
hosts kind of comma separated in there so it gives you a little bit of flexibility so groups again can represent one host or a thousand or ten thousand it kind of makes things a little bit simpler in that respect also it makes your playbook more generic right if I have just a group name in there I'm not having to go and edit that Playbook over and over so really good feature there limiting so limiting is something that is available on CLI and Ascender as well and what it really lets you do is further restrict down the host you're going to operate against right so inventory
big list of all my hosts host section it's going to narrow that down so say I did it on the web group right the whole section just says web and it's a group well on the CLI or in Ascender there's an extra option called limit and so if I fill something in the limit field it will further narrow down the results from the host section right now this can offer us a lot of efficiencies it's actually really cool how you can kind of pull these together because in my playbook if I want to I can just have the host section set to all and all
is an implicit group that exists for every inventory in every host that's in that inventory automatically exists in the alt right so I could just set the host section in my playbook to be all which means it could theoretically run against everything right but I will use the limit section to be more specific that way I truly never have to touch my playbook to adjust that host portion right because I'm using the limit option but this could be dangerous and I'm sure you can imagine why so I almost never won an automation to run against everything inside of my uh inside of my inventory because
it could break tons of stuff right so to me that's always been a little bit scary well there are some ways around it now let me show you a Playbook example of that so here is kind of a little generic test run Playbook again all this stuff is always in my publicit repository so you can come in here and play with this as you like but this Playbook has an initial task that guards against that exact problem right so if you take a look right here in the host section I have it set to all so theoretically if I just ran it just like it
is it's going to operate against everything in there so say for example I have this running and it's going to be removing an access list that protects connectivity to a switch right if I run it against all in my inventory it could theoretically pull this off of my firewalls or my backbone routers or really important infrastructure and it could break everything now I've put in this Playbook a safeguard against running all without using limits so right here I'm using an assert and that is a module that basically says hey I assume this is true if it's not error out so here I'm just saying I
assume that in here's some magic variables in here ansible play hosts all so it's going to find all of the hosts that have been matched right by the host section and it's going to find the length of that object and it's making sure that it's less than the group all so really it's saying hey if the number of hosts you have in here is not less than what you have here go ahead and fail out if it is less than go ahead and complete right in here I'm just doing a debug where I'm spitting out the inventory name so let's actually see that in action
and how we kind of use that with limits so I've got a little job template here I just named a test and this one is plane right so it doesn't have anything in there I'm looking at the limit option there's nothing specified in there so I'm going to go ahead and launch it now this should run and then fail let's see all right exactly as expected right it failed out our job and it right it can't complete and so this would protect us in the event that somebody tried to run this and forgot to use the limit option right so we're protected it's not going
to run against all so how do we kind of work around this I can go to details of this job right because it whenever I run a piece of automation it automatically pops me into the job section if I click on details there's the job template name right just kind of uh a little quick instead of having to go into templates and everywhere else I can click edit there so now I have this is the uh the inventory I'm actually running against I've only got two hosts in there I'm going to copy the name of one of them really quick so I could in theory
I could paste this right here and I can click save and then launch and so now I'm running it against a single host and it should successfully complete let's see excellent as expected all assertions passed and then it moves right on through but that's a little bit more rigid what if I want to make this slightly more flexible I can do that so I'm going to go back to details click on A8 test I'm going to edit this job template we have the option to prompt on launch and you have this on many things right if you kind of look around you'll see prompt on
launch in a lot of different areas and really what that means is if I launch this piece of automation it's going to have a pop-up box that says hey fill in the blank here and so I've got this entry I'm going to go ahead and leave that in there right so theoretically I could have um a group name in here or a couple of hosts in there and now those are going to become my default options though I can override them so I'm going to go ahead and click save I'm going to click launch again you can see it pops up and it's asking me
for a limit option here so since I already had something in there that becomes the default so if there's a default group that I want it to be in there it will always pop up in there and ready to go but I can augment if I want to now for example I've got the limit option in here and I can still blank it out and I can run it with nothing in there what's going to happen if I launch it with limit even on prompt on launch set to blank exactly as expected as you see here right there was nothing in the limit so our
first assertion task caught it and failed it so this actually can protect you so great efficiencies I never had to touch my playbook because I've got the group ball I'm only having to modify my job template here if I'm doing prompt on launch I don't even have to modify it I just prompted on launch I see the pop-up box I fill it in Bob's your uncle we're done so I think this is kind of a nice way to augment your playbooks make things a little bit more efficient if you have any questions or comments or you would tweet or tune this to your specific environments
please feel free to reach out to us love to hear from you if nothing else happy ascending happy automating happy hosting happy limiting and we'll see you next time bye
Built for scale. Chosen by the world’s best.
2.75M+
Rocky Linux instances
Being used world wide
90%
Of fortune 100 companies
Use CIQ supported technologies
250k
Avg. monthly downloads
Rocky Linux
9
Enterprise products
Spanning the kernel to the orchestrator
Have questions about your infrastructure?
Talk to a CIQ engineer about Rocky Linux, HPC, and AI infrastructure.