The configuration for Ansible can exist in a few different locations, where the first file found will be used. The search involves the following:
ANSIBLE_CFG: This environment variable is used, provided that it is set.
ansible.cfg: This is located in the current working directory.
~/.ansible.cfg: This is located in the user's home directory.
/etc/ansible/ansible.cfg: The default central Ansible configuration file for the system.
Here is a list of behavior inventory variables and the behaviors they intend to modify:
ansible_host: This is the DNS name or the Docker container name that Ansible will initiate a connection to.
ansible_port: This specifies the port number that Ansible will use to connect to the inventory host if it is not the default value of 22.
ansible_user: This specifies the username that Ansible will use to connect with the inventory host, regardless of the connection type.
ansible_password: This is used to provide Ansible with the password for authentication to the inventory host in conjunction with ansible_user. Use this for testing purposes only – you should always use a vault to store sensitive data such as passwords (please refer to Chapter 3, Protecting Your Secrets with Ansible).
ansible_ssh_private_key_file: This is used to specify which SSH private key file will be used to connect to the inventory host if you are not using the default one or ssh-agent.
ansible_ssh_common_args: This defines SSH arguments to append to the default arguments for ssh, sftp, and scp.
ansible_sftp_extra_args: This is used to specify additional arguments that will be passed to the sftp binary when called by Ansible.
ansible_scp_extra_args: This is used to specify additional arguments that will be passed to the scp binary when called by Ansible.
ansible_ssh_extra_args: This is used to specify additional arguments that will be passed to the ssh binary when called by Ansible.
ansible_ssh_pipelining: This setting uses a Boolean to define whether SSH pipelining should be used for this host.
ansible_ssh_executable: This setting overrides the path to the SSH executable for this host.
ansible_become: This defines whether privilege escalation (sudo or something else) should be used with this host.
ansible_become_method: This is the method to use for privilege escalation and can be one of sudo, su, pbrun, pfexec, doas, dzdo, or ksu.
ansible_become_user: This is the user to switch to through privilege escalation, typically root on Linux and Unix systems.
ansible_become_password: This is the password to use for privilege escalation. Only use this for testing purposes; you should always use a vault to store sensitive data such as passwords, Protecting Your Secrets with Ansible).
ansible_become_exe: This is used to set the executable that was used for the chosen escalation method if you are not using the default one defined by the system.
ansible_become_flags: This is used to set the flags passed to the chosen escalation executable if required.
ansible_connection: This is the connection type of the host. Candidates are local, smart, ssh, paramiko, docker, or winrm (we will look at this in more detail later in the book). The default setting is smart in any modern Ansible distribution (this detects whether the ControlPersist SSH feature is supported and, if so, uses ssh as the connection type; otherwise, it falls back to paramiko).
ansible_docker_extra_args: This is used to specify the extra argument that will be passed to a remote Docker daemon on a given inventory host.
ansible_shell_type: This is used to determine the shell type on the inventory host(s) in question. It defaults to the sh-style syntax but can be set to csh or fish to work with systems that use these shells.
ansible_shell_executable: This is used to determine the shell type on the inventory host(s) in question. It defaults to the sh-style syntax but can be set to csh or fish to work with systems that use these shells.
ansible_python_interpreter: This is used to manually set the path to Python on a given host in the inventory. For example, some distributions of Linux have more than one Python version installed, and it is important to ensure that the correct one is set. For example, a host might have both /usr/bin/python27 and /usr/bin/python3, and this is used to define which one will be used.
ansible_*_interpreter: This is used for any other interpreted language that Ansible might depend upon (for example, Perl or Ruby). This replaces the interpreter binary with the one that is specified.
Ansible works in following orders:-
- Variable loading
- Fact gathering
- The pre_tasks execution
- Handlers notified from the pre_tasks execution
- The roles execution
- The tasks execution
- Handlers notified from the roles or tasks execution
- The post_tasks execution
- Handlers notified from the post_tasks execution
#Generating SSH Key
$ ssh-keygen
#Copy the SSH Key on the Hosts
$ ssh-copy-id -i ~/.ssh/my_custom_key user@host
#Check the SSH Connection
$ ssh -i ~/.ssh/my_custom_key user@host
#Check Ansible version
Ansible --version
#Testing connectivity with all managed nodes
$ ansible all -m ping -i inventory_file --private-key=~/.ssh/my_custom_key
#Testing connectivity with all managed nodes using password
$ ansible all -m ping -i inventory_file --ask-pass
#Creating Ansible role
$ ansible-galaxy init role_name
#display list of installed roles
$ ansible-galaxy list
#Search for any roles in ansible-galaxy
#ansible-galaxy search role_name
0 Comments