I have a very generic playbook with no hard coded info whatsoever. Everything in the playbook is a variable and filled out by supplying extra vars, even host names for connections. There are no inventory files in use since the host this is run against is random usually.
On a command line in linux, I can run my ansible playbook multiple times with different variables passed and they will all run at the same time.
ansible-playbook cluster_check_build.yml -e {"host": "host1"...}
ansible-playbook cluster_check_build.yml -e {"host": "host2"...}
In tower however, if I create a job template and use the same playbook then things run serially. I call that job template multiple times using the API and passing the data as JSON. Each time I called the API to launch the job task I am supplying new extra_vars so the job task is running against different hosts. I see the jobs run serially and not parallel like from the command line.
I have 400+ hosts that need to have the same playbook run against them at random times. This playbook can take an hour or so to complete. There can be times where the playbook needs to run against 20 or 30 random hosts. Time is crucial and serial Job processing is a non starter.
Is it possible to run the same job template against different hosts in parallel? IF the answer is no then what are my options? Hopefully not creating 400+ job templates. That seems like it defeats the purpose of a very generic playbook.
I feel like an absolute fool. In the bottom right of my job template is a tiny check box that says "ENABLE CONCURRENT JOBS" <---this was the fix.
Yes, you can run templates/playbooks against multiple hosts in parallel in Tower/AWX.
These are the situations where your template will run serially:
"forks" set to 1 in your template
SERIAL=1 within your playbook
Your Tower/AWX instance is setup with only 1 fork
Your Instance is set with >1 forks but other jobs are running at the same time.
Related
I need to run a playbook having a number of checks performed on hosts but needn’t run the same again if run successfully once. I would want Ansible to trigger a message saying that the checks(Ansible script) was already run successfully. How can I achieve that?
There is an option called: --start-at-task=START_AT
This will start your playbook at the task matching the given name.
example
ansible-playbook playbook_name --start-at-task=START_AT
change "START_AT" with the name of the task you will start at.
ansible-playbook —list-tasks —tag<tagname>
Lists the tasknames. Is there way to get more details of task other than name?
If you want to see the end result of each task without executing the tasks,
Ansible provides a check mode, also called dry run mode that predicts the changes that may occur in each task without actually executing it.
ansible-playbook --check your_playbook.yaml
I am running a bash script from the playbook. The bash script runs multiple scripts in parallel in-turn on a remote machine and it will give the output on console only when the entire playbook is executed. I want to print the output real-time. Is it possible?
Storing of result with 'register' provided by ansible to print output is not helping here. As I need real-time output.
It is not possible to take influence on a script "realtime" that is currently running.
U could use the failed_when to catch script errors:
https://docs.ansible.com/ansible/latest/user_guide/playbooks_error_handling.html#controlling-what-defines-failure
or u catch errors in the script self at runtime.
I am running a playbook for deployment of nodes.Suppose because of some issue like power failure or some other exception, the execution failed after executing some tasks.So, I am trying to resume the execution from same place where it failed, when I run the playbook next time.
It is time consuming to run the playbook for all the task from start.Is it possible to achieve the solution?
You can use function --start-at-task="task name" this will run the whole playbook from the specific task name and continue from there om. But be careful, if you have registered any variables in tasks before and use them afterwards, starting at that task will not register them and therefore the play will not use them. In that case you could give tag "always" to the tasks that register variables
The output of a failed ansible-playbook run actually tells you how to do this (assuming you have 'retry_files_enabled' set true in your config, which is the default):
to retry, use: --limit #/some/path/to/a/retry/file
In the case of a failure, Ansible will create a retry file, which is for the specific purpose of what you requested. Therefore, just append the '--limit' statement to the command you used to run the playbook and kick it off again.
Edit: To be fair, your specific case of a power failure on the control machine would not be covered by this, but any failure that Ansible handles (i.e. the majority), will work with this method.
execute like this:
ansible-playbook --forks=10 myscript.yml --start-at-task='install java'
with limit: ansible-playbook --forks=10 myscript.yml --limit limit1 --start-at-task='install java'
It is my understanding that running ansible with -B will put the process in the background and I will get the console back. I don't know if I am using it wrong, or it is not working as expected. What I expect is to have the sleep command initiate on all three computers and then the prompt will be available to me to run another command. What happens is that I do not get access to the console until the command completes (in this case 2 minutes).
Is something wrong, am I misunderstanding what the -B does or am I doing it wrong?
With polling:
Without polling:
There are two parameters to configure async tasks in Ansible: async and poll.
async in playbooks (-B in ad-hoc) – total number of seconds you allow the task to run.
poll in playbooks (-P in ad-hoc) – period in seconds how often you want check for result.
So if you just need fire and forget ad-hoc command, use -B 3600 -P 0: allow 1 min execution and don't care about result.
By default -P 15, so ansible doesn't exit but checks your job every 15 seconds.