The Ansible orchestration engine interacts with a user who is writing the Ansible playbook to execute the Ansible orchestration and interact along with the services of private or public cloud and configuration management database. The below diagram explains it.
Playbooks here actually define your workflow because whatever tasks that you write in a playbook, it gets executed in the same order that you have written them. They are written in YAML format, which describes the tasks and executes through the Ansible. Also, you can launch the tasks synchronously and asynchronously with playbooks.
The above architecture has a bunch of Host machines to which ansible server connects and pushes the playbooks through SSH. It is not always needed to use an SSH for connecting with your host machines; you can also use a connection plug-in. For example, Ansible provides you with a docker container connection plugin and using that connection plug-in, you can easily connect to all your Docker containers and start configuring right away.
It has an Ansible automation engine using which users can directly run a playbook that gets deployed on the hosts. There are multiple components in the Ansible automation engine. The first is a host inventory. It’s a list of all the IP addresses of all the hosts. Let’s go one by one, in the Ansible automation engine.
Ansible works against multiple systems in your infrastructure at the same time. It does this by selecting portions of systems listed in Ansible’s inventory file, which defaults to being saved in the location /etc/ansible/hosts. You can specify a different inventory file using the -i <path> option on the command line.
