Ansible Overview

Instructions are written to automate an IT admin's work.

Consistency of all systems in the infrastructure is maintained.

Applications are deployed automatically on a variety of environments.

• Push configuration: server pushes configuration to the nodes
• The server forces (pushes) the config onto the node. (ignores what is already there. So there is no need for the node to communicate back)
• Unlike Chef and Puppet,
• No agent is needed on the node. Contrast that to Puppet Chef that as a slave client on every node, and a puppet master.

Ansible works by connecting to your nodes and pushing out small programs, called "Ansible modules" to them. These programs are written to be resource models of the desired state of the system. Ansible then executes these modules (over SSH by default), and removes them when finished.

It is the actual module that is sent to the node, but then executed locally on the node, therefore the node must have a python interpreter to use to execute these modules. (remember modules are written in python). All true except in networking. See Network Modules vs System Modules section below.

Your library of modules can reside on any machine, and there are no servers, daemons, or databases required. Typically you'll work with your favorite terminal program, a text editor, and probably a version control system to keep track of changes to your content.

Ansible uses a concept of playbooks which are simply scripts that run against devices in your environment. Playbooks are extensible, because they use modules written in Python, so basic Python skills lets you write your own module for a device, or tweak an existing module to enhance that module's functionality.

Each play is a list of tasks mapped to a set of hosts which run on those hosts to define the role that those systems will perform.

Actually a play is a list of tasks and roles that should be run. But that is NOT the definition used by Cisco.

File is "dnf.yml". This is an "all-in-1" playbook, meaning, the tasks are included in the playbook itself. See "roles" for a more scalable approach.

---
   - name: add figlet to all hosts
     hosts: *
     tasks:
       # install epel respository first
       name: epel-release
       state: latest
     tasks:
       # install figlet
       name: figlet
       state: installed   # don't really care about the latest figlet

Another example:

---
- hosts: all
  become: true

- name: Install apache httpd
  apt:
   name: apache2
   state: present
- name: Copy in new index file
  copy:
   src: index.html
   dest: /var/www/html/index.html
   mode: '0755'

You could also use roles. Here is an example of installing apache2 using roles:

---
- hosts: all
  become: true
  roles:
  - install_apache2

For the above example, there needs to be a file called "install_apache2" ???

From: Ansible.com

"Ansible is a radically simple IT automation engine that automates cloud provisioning, configuration management, application deployment, intra-service orchestration, and many other IT needs.

Designed for multi-tier deployments since day one, Ansible models your IT infrastructure by describing how all of your systems inter-relate, rather than just managing one system at a time.

It uses no agents and no additional custom security infrastructure, so it's easy to deploy - and most importantly, it uses a very simple language (YAML, in the form of Ansible Playbooks) that allow you to describe your automation jobs in a way that approaches plain English."

The roles are the collections of commands that can be run on hosts. Roles are NOT defined within a playbook, but are a set of playbooks. Roles are stored in specific subdirectories, each of which have specific subdirectories.

The goal of roles is to organize playbooks and increase the flexibility and reusablility of ansible playbooks.

Ansible will execute the commands stored in specific directories on a target machine. The direcotries are all stored on the controller / local machine.

Within a given role subdirectory you can define variables, templates, files, and handlers that are specific to that role. When a playbook then calls a role, all those customizations are then applied. Makes for great flexibility.

Like a play, the role defines tasks and handlers. However, roles do not define on which hosts the role will be run. Therefore you must reference roles from within a playbook

The top level directory is the roles directory. Each role is stored in a subdirectory of the roles directory. Each role directory must at least contain a folder called tasks which contains a file called main.yml

---
- name: play1
  hosts: all
  become: true
  pre_tasks:
  - name: do something before roles
    debug: msg="this is run before a role"
  roles: 
  - install_role

- name: play 2
  hosts: group2
  roles:
  - config_role

Notice that it is the play that has the list of tasks and roles that should be run.

1. ANSIBLE_CFG: environment variable
2. ./ansible.cfg (i.e. in the current directory)
3. ~/.ansible.cfg (i.e. in the user's home directory)
4. /etc/ansible/ansible.cfg (i.e. system wide in /etc directory)

Run ansible-config --version

ansible-config --version
ansible-config 2.9.13
  config file = /etc/ansible/ansible.cfg
  configured module search path = ['/home/ansible/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /home/ansible/.venv-ansible/lib/python3.8/site-packages/ansible
  executable location = /home/ansible/.venv-ansible/bin/ansible-config
  python version = 3.8.5 (default, Sep  7 2020, 12:02:06) [GCC 8.3.1 20191121 (Red Hat 8.3.1-5)]
(.venv-ansible) ansible@c8host /etc/ansible[1034] $

Placed in the top level directory of the project:

[defaults] inventory = ./inventory retry_filesenabled = False

[ssh_connection] pipelining = True

Ansible takes the first string on a line in the hosts file as inventory_hostname You can override that using ansible_host on each line in your inventory, or in the [vars] section like follows:

• If you have very long domain names, and want to shorten the typing of these

in your inventory file, you can optionally use ansible_host

So rather than have:

[lab]
vm[1:5].zintis.ops

[webservers]
web1.zintis.ops
web2.zintis.ops
web3.zintis.ops

[webservers:vars]
apache_http_port=80
apache_https_port=443

You could have:

[all:vars]
host_domain=zintis.ops
ansible_host="{{inventory_hostname}}.{{host_domain}}"

[lab]
vm[1:5]

[webservers]
web1
web2
web3

[webservers:vars]
apache_http_port=80
apache_https_port=443

See intro to ansible inventory link in docs.ansible.com for more details.

Run ansible all --list hosts and that should show you all your inventory

Placed in ./inventory/hosts. See section Inventory file below for details.

localhost  ansible_connection=local

[labservers]
vm1 ansible_host=192.168.111.11
vm2 ansible_host=192.168.111.12
vm3 ansible_host=192.168.111.13
vm4 ansible_host=192.168.111.14 ansible_python_interpreter: /usr/bin/python
vm5 ansible_host=192.168.111.15

[continents]
aus ansible_host=172.28.105.2
ant ansible_host=172.28.105.3
asia ansible_host=172.28.105.5
eu  ansible_host=172.28.105.6
sa  ansible_host=172.28.105.8

The .ini file format for hosts is more common. Howerver, you can also use YAML format for the hosts(inventory) file. The same file is shown in YAML:

all:
  hosts:
    localhost:
      ansible_connection=local
  children:
    labservers:
      hosts:
        vm1:
          ansible_host: 192.168.111.11
        vm2:
          ansible_host: 192.168.111.12
        vm3:
          ansible_host: 192.168.111.13
        vm4:
          ansible_host: 192.168.111.14 
          ansible_python_interpreter: /usr/bin/python
        vm5:
          ansible_host: 192.168.111.15

    lab:
      hosts:
        vm[1:5].zintis.ops
      vars:
        variable1:  value1

    continents:
      hosts:
        aus:
          ansible_host: 172.28.105.2
        ant:
          ansible_host: 172.28.105.3
        asia:
          ansible_host:172.28.105.5
        eu:
          ansible_host: 172.28.105.6
        sa:
          ansible_host: 172.28.105.8

For the above .yml file, everything defined after a host: is considered a host variable.

Two more examples, proved to work with sandbox. They are the same hosts, but one is in [ini] format, the other in .yml format:

# minimal hosts version (ini) confirmed to work Feb 16, 2021
# for both of these sandbox routers.
[routers]
ios-xe-mgmt-latest.cisco.com
ios-xe-mgmt.cisco.com

[routers:vars]
ansible_user=developer
ansible_password=C1sco12345
ansible_connection=network_cli
ansible_network_os=ios
ansible_port=8181
netconf_port=10000
http_port=80
https_port=443

---
routers:
  hosts:
    ios-xe1:
      ansible_host: ios-xe-mgmt-latest.cisco.com
    ios-xe2:
      ansible_host: ios-xe-mgmt.cisco.com
  vars:
    ansible_user: developer
    ansible_password: C1sco12345
    ansible_connection: network_cli
    ansible_network_os: ios
    ansible_port: 8181
    netconf_port: 10000
    http_port: 80
    https_port: 443

If you start a value with {{ foo }}, you must quote the whole expression to create valid YAML syntax, so "{{ foo }}"

Wrong:

• app_path: {{ base_path }}/22

Correct:

• app_path: "{{ base_path }}/22"

Automation of multiple systems, each with slight variations, would be very difficult if not for ansible supporting variables. These variables include lists and dictionaries, so that all these slight variations can be supported and automated often within a single ansible command or playbook.

In a playbook you can use these variables (and lists) in the following:

• as module arguments
• in conditional "when" statements
• in templates
• in loops
• in hosts file (deprecated, but still supported) eg: 192.168.11.15 OS=LINUX

As the docs.ansible.com site directs, you can see many examples of variable use in the ansible-examples section.

As already seen in multiple places in this org file, ansible variables can be set in numerous places, and then used by playbooks and in playbook loops.

Since ansible uses ssh, the ssh environment is available and active to any ansible task (session). These would typically be environement variables set in .bash_profile or .bashrc, or other shell specific environment tweaks.

We can use ansible to set and retrieve environment variables too. Typically these are temporarily set, and NOT permanently saved to the ssh user on the remote host. After the playbook closes, those environment variables are gone.

Only alphanumeric characters and underscores can be used in a variable name. Variables cannot begin with a number. No python word or command can be used as a variable name.

Many registered variables (and facts) are nested YAML or JSON data structures. You cannot access values from these nested data structures with the simple {{ foo }} syntax. You must use either bracket notation or dot notation. For example, to reference an IP address from your facts using the bracket notation:

For example:

• {{ ansible_facts["eth0"]["ipv4"]["address"] }}

To reference an IP address from your facts using the dot notation:

• {{ ansible_facts.eth0.ipv4.address }}

From the docs.ansible.com variables docs: "You can define these variables in your playbooks, in your inventory, in re-usable files or roles, or at the command line. You can also create variables during a playbook run by registering the return value or values of a task as a new variable."

Once defined, you can use them

• as module arguments
• in conditional "when" statements
• in templates
• in loops

Any task that you have, you can register it to a variable. Then using debug you can display the variable, and so find out everything about the task.

In a task include the line: register: kasmanseitir

Then create another task, and call up debug: module debug: var=kasmanseitir

Once you see all the info on the task, you can run it again, and recall a specific field from that task, for instance debug: var=kasmanseitir.rc But a more robust approach (that ends up doing the same thing, just safer) debug: var=kasmanseitir['rc']

The reason is that some returned fields might have a dash, like rc-status If so, then your playbook will fail as "dash" "-" is not a valid syntax in ansible. So, be safe and use ['field'] and not .field notation.

You can turn off gathering facts, by telling ansible gather_facts: no You may want to turn off facts gathering on a docker container… But if you turn off facts, then none of the facts (variables) from any remote node will be unavailable to you.

• 1 Tasks in each role will see their own role’s defaults. Tasks defined outside of a role will see the last role’s defaults.
• 2(1,2) Variables defined in inventory file or provided by dynamic inventory.
• 3(1,2,3,4,5,6) Includes vars added by ‘vars plugins’ as well as host_vars and group_vars which are added by the default vars plugin shipped with Ansible.
• 4 When created with set_facts’s cacheable option, variables will have the high precedence in the play, but will be the same as a host facts precedence when they come from the cache.

In order:

1. Global: set by config, env variables and command line
2. Play: each play and contained structures, vars entries (vars; vars_fiels: vars_prompt), role defaults, and vars
3. Host: variables direclty associated to a host, like inventory, include_vars, facts, registered task outputs.

Best practice: Choose to define a variable based on the kind of control you need over the values, but here are tips:

1. inventory variables when dealing with geography or behaviour
2. groups often map roles to hosts, so you can set variables on the groups instead of defining them on a role
3. child groups override parent groups and host vars override group vars
4. set common defaults in group_vars/all, generally alongside your inventory file.

   # file: /etc/ansible/group_vars/toronto
   ntp_server: toronto-time.acme.org
   
   # file /etc/ansible/host_vars/west-coast-test
   ntp_server: override-west-ntp.acme.org
   

5. set defaults in roles to avoid undefined-variable errors. Often reasonable defaults should be set in roles/x/defaults/main.yml file. (or override that using the inventory, or at the command line.)

   # file ./roles/x/defaults/main.yml
   # if no other value is supplied in inventory or as  a parameter, pick
   # this value
   http_port: 80
   

6. set vars in roles ensure it is not overridden by inventory variables. Often reasonable defaults should be set in roles/x/defaults/main.yml file. (or override that using the inventory, or at the command line.)

   # file ./roles/x/vars/main.yml
   # this, 100% will be used in this role
   http_port: 80
   

7. Pass variables as parameters when you call roles (again best practice) It improves readability, clarity, and flexibility, adn overrides any defaults that exist for a role

   roles:
     - role: apache
       vars:
         http_port: 8080
   

   Or same role multiple times for example:

   roles:
   - role: app_user
     vars:
       myname: Ian
   - role: app_user
     vars:
       myname: Terry
   - role: app_user
    vars:
      myname: Graham
   - role: app_user
    vars:
      myname: John
   
   

Once our YAML playbook is finished and saved as a .yml file, you run it using the command:

• ansible-playbook <filename>.yml
• ansible-playbook -u root <filename>.yml if you are overriding the user id.

  Cisco claims that "ansible uses the root username by default" so -u can be omitted. THIS IS INCORRECT. The default username is to use yourself. So cisco is correct only if you are logged in as root which of course is NOT recommended. For example, I use a username of ansible and all my ansible playbooks run as the user ansible.

Often you will see -K as an option when you need to be prompted for a passwd. So, ansible-playbook -K <filename>.yml

If my is this playbook file called basics-playbook.yml:

---
- hosts: opsvms
  become: true
  roles:
  - basic-utils

If I was to run ansible-playbook basics-playbook.yml Ansible will look in the following directories for the basic-utils role: (notice: it was NOT looking for basics-playbook.yml file, but basic-utils which means it found the basics-playbook.yml file but was unable to find the role file, called 'basic)

1. /home/ansible/Ansible-CentOS/playbooks/roles:
2. home/ansible.ansible/roles
3. /usr/share/ansible/roles
4. /etc/ansible/roles
5. /home/ansible/Ansible-CentOS/playbooks

That failed for me with ERROR! the role 'basic-utils' was not found in : According to my tree, I put it in

Handlers are just tasks. But the handler name allows it to be "called" based on the condition of some other tasks, or at the very end of the playbook. So they are tasks that ONLY run when notified to run by another task.

Handlers will not be called if there was NO change in the system based on the playbook being executed. That way, if the config you want is already on the node in question, you don't have to restart apache (for example).

Other tasks tell a handler to run, using the notify: mytaskname function.

-tasks:
  - name: Write the apache config file
    ansible.builtin.template:
      src: /srv/httpd.j2
      dest: /etc/httpd.conf
    notify:
    - Restart apache
-handlers:
  - name: Restart apache
    systemctl: restart ?????/   this is wrong, find whzt is correct...

Handlers are very nice for preventing repeated restarts of a given service. Highly recommend. They can be used for other things that only need to be run once as well. This is accomplished by task running, and if successful use notify command that then is collected by the end of the playbook and only THEN run once.

Start with a simple playbook that installs Apache:

---
# run with "ansible-playbook -i inventory ansible-zp1.yml"
- name: Install Apache.
  hosts: centos
  become: true

  tasks:
    - name: Ensure Apache is installed.
      yum:
        name: httpd
        state: present

    - name: Ensure Apache is running and starts at boot.
      service:
        name: httpd
        state: started
        enabled: true

Then add a handler, (task), that only runs at the end of this playbook, and only if all the other tasks completed. Notice that we have not explicitly called the handler yet. We do that in the next example.

---
# run with "ansible-playbook -i inventory ansible-zp1.yml"
# adding a handler, named "restart apache"

- name: Install Apache.
  hosts: centos
  become: true

  handlers:
    - name: restart apache
      service:
        name: httpd
        state: restarted

  tasks:
    - name: Ensure Apache is installed.
      yum:
        name: httpd
        state: present

    - name: Ensure Apache is running and starts at boot.
      service:
        name: httpd
        state: started
        enabled: true

Adding a copy config task, that will then call the restart apache handler

---
# run with "ansible-playbook -i inventory ansible-zp1.yml"

- name: Install Apache.
  hosts: centos
  become: true

  handlers:
    - name: restart apache
      service:
        name: httpd
        state: restarted

  tasks:
    - name: Ensure Apache is installed.
      yum:
        name: httpd
        state: present

    - name: Copy test config file.
      copy:
        src: files/test.conf
        dest: /etc/httpd/config.d/test.conf
      notify: restart apache
      # the notify will "call" the handler "restart apache" iff a copy occurred

    - name: Ensure Apache is running and starts at boot.
      service:
        name: httpd
        state: started
        enabled: true


# this notify line will add the restart apache task to the end of the stack of
# handlers at the end of the playbook.  This stack will grow as needed for each
# run, then execute at the end of the playbook.
# 

  ---
# changing handler to run immediately after copy, and not wait to the end
# of the playbook to run, using ansible flush handlers.

- name: Install Apache.
  hosts: centos
  become: true

  handlers:
    - name: restart apache
      service:
        name: httpd
        state: restarted

  tasks:
    - name: Ensure Apache is installed.
      yum:
        name: httpd
        state: present

    - name: Copy test config file.
      copy:
        src: files/test.conf
        dest: /etc/httpd/config.d/test.conf
      notify: restart apache
      # the notify will "call" the handler "restart apache" iff a copy occurred

    - name: Make sure handlers are flushed immediately.
      meta: flush_handlers

    - name: Ensure Apache is running and starts at boot.
      service:
        name: httpd
        state: started
        enabled: true


# run with "ansible-playbook -i inventory ansible-zp1.yml"

  ---
# by default ansible will only run handlers if the playbook did not run into
# errors.  But if you want to restart apache, even if other ansible tasks
# failed with errors, then add the option "--force_handlers" This will make all
# handlers at the end of the playbook run, even if other tasks had errors.
#

- name: Install Apache.
  hosts: centos
  become: true

  handlers:
    - name: restart apache
      service:
        name: httpd
        state: restarted

  tasks:
    - name: Ensure Apache is installed.
      yum:
        name: httpd
        state: present

    - name: Copy test config file.
      copy:
        src: files/test.conf
        dest: /etc/httpd/config.d/test.conf
      notify: restart apache
      # the notify will "call" the handler "restart apache" iff a copy occurred

    - name: Make sure handlers are flushed immediately.
      meta: flush_handlers

    - name: Ensure Apache is running and starts at boot.
      service:
        name: httpd
        state: started
        enabled: true

    - fail:
    # this convenient ansible module simply fails for you.  Used to test handlers

# run with "ansible-playbook -i inventory ansible-zp1.yml --force_handlers"

  ---
# I can add a second handler, that will restart memcached (flush cached
# memory on the apache server).   Now that I have two handlers, I can
# set my notify: to be a list of handlers, not just a single handler

- name: Install Apache.
  hosts: centos
  become: true

  handlers:
    - name: restart apache
      service:
        name: httpd
        state: restarted

    - name: restart memcached
      service:
        name: memcached
        state: restarted

  tasks:
    - name: Ensure Apache is installed.
      yum:
        name: httpd
        state: present

    - name: Copy test config file.
      copy:
        src: files/test.conf
        dest: /etc/httpd/config.d/test.conf
      notify:
        - restart apache
        - restart memcached
      # the notify will "call" all the handlers in the list given:


    - name: Make sure handlers are flushed immediately.
      meta: flush_handlers

    - name: Ensure Apache is running and starts at boot.
      service:
        name: httpd
        state: started
        enabled: true

# run with "ansible-playbook -i inventory ansible-zp1.yml

And more:

  ---
# Since a handler is just a task, I can have that handler itself notify another
# handler, and so daisy-chain handlers that I need in the order I need them.
#
# Summarizing: a handler is just an ansible task, and you use the "notify"
# key to "call" that handler, by default at the end, but optionally with
# "force_handlers" immediately.


- name: Install Apache.
  hosts: centos
  become: true

  handlers:
    - name: restart apache
      service:
        name: httpd
        state: restarted
      notify: restart memcached 

    - name: restart memcached
      service:
        name: memcached
        state: restarted

  tasks:
    - name: Ensure Apache is installed.
      yum:
        name: httpd
        state: present

    - name: Copy test config file.
      copy:
        src: files/test.conf
        dest: /etc/httpd/config.d/test.conf
        notify: restart apache

    - name: Make sure handlers are flushed immediately.
      meta: flush_handlers

    - name: Ensure Apache is running and starts at boot.
      service:
        name: httpd
        state: started
        enabled: true

# run with "ansible-playbook -i inventory ansible-zp1.yml

For example:

• ansible all -m ping
• ansible all -m ping -u zintis
• ansible all -m ping -u zintis –ask-pass
• ansible -m ping all

Here is how to use the dnf module as a ad-hoc call:

• ansible foo.example.com -m dnf -a "name=httpd state=installed"
• ansible foo.example.com -m dnf -a "pkg=httpd state=installed"

Note: 'pkg' is an alias for 'name' so use them interchangeably

Look up details of the dnf module in docs.ansible.com

First as an ad-hoc command:

• ansible -m command -a "hostname" mailservers
• ansible -m command -a "uptime" opsvms
• ansible -m command -a "cat /etc/resolv.conf" opsvms

Then as a playbook: -name: Run a command to show ip routes fill this in…

• ansible -m shell -a 'hostname' all
• ansible -m shell -a 'df -h' all
• ansible -m shell -a 'whoami' all
• ansible -m shell -b -a "iptables -S" all

  you had to have run a sudo command within the sudo timeout I think.

• ansible -m shell -b -K -a 'whoami' allzp

  (venv-ansible) ansible@c8host ~/Ansible-CentOS[1050] $
  ansible  -b -K -m shell -a 'whoami'  allzp
  BECOME password: 
  vm1 | CHANGED | rc=0 >>
  root
  vm2 | CHANGED | rc=0 >>
  root
  vm4 | CHANGED | rc=0 >>
  root
  vm3 | CHANGED | rc=0 >>
  root
  (venv-ansible) ansible@c8host ~/Ansible-CentOS[1051] $
  

• ansible -m shell -a 'whoami' allzp Compare the following output to the previous output.

  (venv-ansible) ansible@c8host ~/Ansible-CentOS[1051] $
  ansible -m shell -a 'whoami'  allzp
  vm1 | CHANGED | rc=0 >>
  ansible
  vm4 | CHANGED | rc=0 >>
  ansible
  vm2 | CHANGED | rc=0 >>
  ansible
  vm3 | CHANGED | rc=0 >>
  ansible
  (venv-ansible) ansible@c8host ~/Ansible-CentOS[1052] $
  

  -b is to "become" the root user, i.e. sudo. -K is the prompt for password to get to sudo, (if the node does not permit visudo with NOPASSWD option.

  I set up my vms to have visudo with NOPASSWD option. The details of how I did that are as follows:

Taken from docs.ansible.com

• name: Execute the command in remote shell; stdout goes to the specified file on the remote. shell: somescript.sh >> somelog.txt
• name: Change the working directory to somedir/ before executing the command. shell: somescript.sh >> somelog.txt args: chdir: somedir/

- name: This command will change the working directory to somedir/ and will only run when somedir/somelog.txt doesn't exist.
  shell: somescript.sh >> somelog.txt
  args:
    chdir: somedir/
    creates: somelog.txt

• name: This command will change the working directory to somedir/. shell: cmd: ls -l | grep log chdir: somedir/
• name: Run a command that uses non-posix shell-isms (in this example /bin/sh doesn't handle redirection and wildcards together but bash does) shell: cat < /tmp/*txt args: executable: /bin/bash
• name: Run a command using a templated variable (always use quote filter to avoid injection) shell: cat {{ myfile|quote }}

• name: Run expect to wait for a successful PXE boot via out-of-band CIMC shell: set timeout 300 spawn ssh admin@{{ cimc_host }}

  expect "password:" send "{{ cimc_password }}\n"

  expect "\n{{ cimc_name }}" send "connect host\n"

  expect "pxeboot.n12" send "\n"

  exit 0 args: executable: /usr/bin/expect delegate_to: localhost

• name: Using curl to connect to a host via SOCKS proxy (unsupported in uri). Ordinarily this would throw a warning. shell: curl –socks5 localhost:9000 http://www.ansible.com args: warn: no

Runs a local script on a remote node, after transfering it

First, you can use this as an ad-hoc ansible command:

• ansible -m user -b -K -a 'name=bob' all # -K will prompt sudo password

You should then follow up with shell module to check if user has been added like so:

• ansible -m shell -a 'getent passwd | grep bob' all

Finally, if you were just testing, or need to remove a user you can:

• ansible -m user -b -a 'name=bob state=absent' all

If you have more users to maintain, you can use a playbook as follows:

- name: update password for a given user3
  hosts: labservers

  tasks:    
   - name: run user module to update password
     become: True
     ansible.builtin.user:
       name: zintis
       state: present
       password: $6$DUbU9uH3k3MUBSbL$MNxEvOqwc6CGZwRtrmBTb32Tjtw2gdlYsHJtHMjXpy70vY6ptP3aCZcW2MfyDtJR3DyilkOFm.MAyKdngBiHF.


# the password is a sha256 hash of the actual password.  I got that using python
# as recommended by docs.ansible.com user module documentation.
# $ python3.8 -c "from passlib.hash import sha512_crypt; import getpass; print(sha512_crypt.using(rounds=5000).hash(getpass.getpass()))"

More examples are available from docs.ansible.com

- name: Add the user 'johnd' with a specific uid and a primary group of 'admin'
  user:
    name: johnd
    comment: John Doe
    uid: 1040
    group: admin

- name: Add the user 'james' with a bash shell, appending the group 'admins' and 'developers' to the user's groups
  user:
    name: james
    shell: /bin/bash
    groups: admins,developers
    append: yes

- name: Remove the user 'johnd'
  user:
    name: johnd
    state: absent
    remove: yes

- name: Create a 2048-bit SSH key for user jsmith in ~jsmith/.ssh/id_rsa
  user:
    name: jsmith
    generate_ssh_key: yes
    ssh_key_bits: 2048
    ssh_key_file: .ssh/id_rsa

- name: Added a consultant whose account you want to expire
  user:
    name: james18
    shell: /bin/zsh
    groups: developers
    expires: 1422403387

- name: Starting at Ansible 2.6, modify user, remove expiry time
  user:
    name: james18
    expires: -1

If using the password option in the user module, it is a bad idea to leave the passwords unencrypted. So, see how I generate encrypted passwords link to 1st generate an encrypted password, then copy that into the user task as needed.

I use the easiest option, and that is to use ansible itself with this ad-hoc command: ansible all -i localhost, -m debug -a "msg={{ 'mypassword' | password_hash('sha512', 'mysecretsalt') }}" ansible all -i localhost, -m debug -a "msg={{ 'mypassword' | password_hash('sha512', 'mysecretsalt') }}"

The mkpasswd utility that is available on most Linux systems is also a great option:

mkpasswd --method=sha-512

Yet a 3rd option is to use Python. First, ensure that the Passlib password hashing library is installed:

pip install passlib

Then, generate the SHA512 password value with:

python -c "from passlib.hash import sha512_crypt; import getpass; print(sha512_crypt.using(rounds=5000).hash(getpass.getpass()))"

• ansible -m copy you will need a source and desintation as a minimum. src and dest
• src is the location of the copy source relative to the main.yml file
• dest is where to put the file on the target node
• permissions is the permissions on the target node

  Example of a copy module "task"

  - name: "adding standardized .bashrc"
    copy: src=../files/bash.bashrc dest=/etc/bash.bashrc owner=root, group=root, mode=0640
  

  Notice that the src is a relative reference ../files/vash.bashrc That implies that the "current" directory of this script is the 'roles' directory

  Example of a copy module "full playbook"

  - name: "Adding bashrc to /etc/"
    copy:
      src: bash.bashrc
      dest: $HOME/dot.bashrc
  
  

Note: this command can run for the user specified in the actual playbook. So, if the playbook has become: true (as in the example here, then the file copied will be in root's home directory, with root permissions.

---
- hosts: mailservers
  become: true
  roles:
  - basic-utils

If however the playbook omits become: true then the file will be in $HOME of the user running this playbook. (in my case user is ansible)

When copying directores using the ansible copy module there is a small quirk that can trip you up. That is the destination should be a directory IN WHICH the source directory will be placed.

So this:

Not this:

Another quirk: If you but the trailing / on the source directory, ONLY the contents of the directory will be copied, not the directory itself.

- name: "Copy four files to remote host"
  copy:
    src: "{{ item }}"
    dest: $HOME/{{ item }}
    owner: root
    group: root
    mode: 0600
  # source files should reside in ../files directory
  loop:
    - init.el
    - requirements.txt
    - readme.newuser
    - readme
  become: true   # needed because owner is to be root.

- name: "copy files within remote host"
  copy:
    src: $HOME/.bashrc
    dest: $HOME/.bashrc-backup
    remote_src: true

- name: write content to a remote file
  copy:
    dest: $HOME/.basrhc
    content: "alias lst='ls -lart --color=auto'"

But this replaces the entire contents of the file with the one line. So you may need to look at another module, or use the command module:

-name: Check for line in /etc/fstab
 command: grep /dev/sdb1
 changed_when: False
 register: shell_out

-name: Append to /etc/fstab
 command: cat /home/ansible/files/fstabdata >> /etc/fstab
 when: shell_out.std_out != ''

The ansible setup module is a good way to see what variables ansible has made available to you for the nodes you are asking for. These are called ansible "facts".

ansible -i inventory vm1 -m setup if inventory is giving errors run this: ansible ops -m setup # where ops is a section in the ansible hosts file. And you will see all the variables at your disposal for the vm1 host. Or can say all, if you like.

Now, any variable that comes back from setup, can be used in your playbooks. almost everything… ansible_dns, ansible_ipv4, etc.

IF your playbook has gather_facts: false Then a playbook that ask for stuff like ansible_osfamily or any other of these many facts, the playbook will fail. So set gather_facts: true if you want to use the ansible facts

Can be run this in any playbook to see all available facts. the ansible setup module gives you the "raw" information.

You can reference the ansible facts in a template or playbook as:

• {{ ansible_facts['devices']['xvda']['model'] }}

To reference the node name us:

• {{ ansible_facts['nodename'] }}

fetch files from remote nodes

manage files and file properties

handlers:
  - name: remove_bashrc file
    file:
      path: "$HOME/.bashrc"
      state: absent 

return a list of files based on specific properties

manages lines in text files, works well when you only are adding/removing a single line.

Parameters I use:

• backup Creates a backup of the file before adding the line.
• create If file not present, create the file. (used with state=present)
• insertafter Default is EOF, otherwise specify a regex.
• line This is the line to add/replace/remove. It is a string. read docs.ansible.com for details on double quoted control characters
• newline unix *this is key, as the default is windows, i.e. \r\n not \n
• path is required.
• regex Is a string to look for in every line of the file
• state present (whether the line should be there or not)

Example:

- name: add groups to sudoers
  lineinfile: dest=/etc/sudoers regexp="^root(\s+)ALL=(ALL)(\s+)ALL" insertafter="^root" line='{{ item }}' state=present backup=yes backrefs=yes
  with_items:
    - '%admin\tALL=(ALL:ALL)\tALL'
    - '%users\tALL=(ALL:ALL)\tALL'
  tags: sudoers

---
- hosts: all
  become: yes

  tasks:
   - name: Check the uptime
     shell: uptime
     register: UPTIME_PRE_REBOOT

   - debug: msg={{UPTIME_PRE_REBOOT.stdout}}

   - name: Unconditionally reboot the machine with all defaults
     reboot:

   - name: Check the uptime after reboot
     shell: uptime
     register: UPTIME_POST_REBOOT

   - debug: msg={{UPTIME_POST_REBOOT.stdout}}

A better option is to use the shell module, and sleep for 5 before shutting down. That gives ansible's ssh session time to cleanly terminate.

---
- hosts: all
  become: yes

  tasks:
   - name: Check the uptime
     shell: uptime
     register: UPTIME_PRE_REBOOT

   - debug: msg={{UPTIME_PRE_REBOOT.stdout}}

   - name: sleep 5 then shutdown
     shell: "sleep 5 && shutdown -h now"

—

• hosts: all become: yes

  tasks:

  • name: Check the uptime shell: uptime register: UPTIME_PREREBOOT
  • debug: msg={{UPTIME_{PREREBOOT.stdout}}}
  • name: sleep 5 then shutdown shell: "sleep 5 && shutdown -h now"

Yet another reboot example…. to be edited later (and pared down):

---
- name: Do something that requires a reboot when it results in a change.
  ...
  register: task_result

- name: Reboot immediately if there was a change.
  shell: "sleep 5 && reboot"
  async: 1
  poll: 0
  when: task_result is changed

- name: Wait for the reboot to complete if there was a change.
  wait_for_connection:
    connect_timeout: 20
    sleep: 5
    delay: 5
    timeout: 300
  when: task_result is changed

Finally, a good link to review reboot module is on docs.ansible.com

replace all instances of a string in a file using a back-referenced regex.

wrapper around rsync. Makes common tasks in playbooks quick and easy

This then is a problem if ansible will be running python commands on the network switch or router. That is why Netork Modules use a different approach.

So, ansible ad-hoc and ansible playbooks that call network modules, such as the ios_interface module, ( see Ansible Modules provided by Cisco: for complete list) actually run python on the local host (controller) and use a connection to the remote nodes according to the implementation specifics of the module used. For instance, the ansible module xxx actually uses Netconf to configure cisco router settings. But that is hidden in internal details in the cisco provided module.

Ansible Docs on Networks

From the docs.ansible.com website re Cisco collections: So, as you can see, if you install the cisco.ios collection, you will get a whole slew of modules to use with ansible and cisco ios devices. The whole list is documented in the collections index on docs.ansible.com

I did this successfully on my Alpine Linux:

= ansible-galaxy collection install cisco.ios

As described on docs.ansible.com, there are multiple communication protocols available to manage network node, because network modules execute on the control node instead of on the managed nodes.

Options are:

• XML over SSH
• CLI over SSH
• API over HTTPS

Depending on the vendor and model, you may forced to use one protocol, or have a choice of protocols. The most common protocol is CLI over SSH. You set the communication protocol with the ansible_connection variable:

• ansible.netcommon.network_cli
• ansible.netcommon.netconf
• ansible.netcommon.httpapi
• local

The ansible_connecion is mandatory for network modules

• note: ansible.netcommon.httpapi deprecates eos_eapi and nxos_nxapi

For ansible network modules, you MUST also have the network_os set to the correct vendor.

CLI over SSH

network_os setting

yes

ansible.netcommon.netconf

XML over SSH

network_os setting

yes

ansible.netcommon.httpapi

API over HTTP/HTTPS

network_os setting

yes

local

depends on provider

provider setting

no

- name: Add a banner
  ios_banner: 
    banner: login   # as opposed to other banners available on cisco routers
    text: 
      This router is part of DevNet.  Please play nice
    state: present

Straight out of docs.ansible.com:

- name: configure the login banner
  cisco.ios.ios_banner:
    banner: login
    text: |
      this is my login banner
      that contains a multiline
      string
    state: present

- name: remove the motd banner
  cisco.ios.ios_banner:
    banner: motd
    state: absent

- name: Configure banner from file
  cisco.ios.ios_banner:
    banner: motd
    text: "{{ lookup('file', './config_partial/raw_banner.cfg') }}"
    state: present

- name: Merge provided configuration with device configuration
  cisco.ios.ios_interfaces:
    config:
      - name: GigabitEthernet0/2
	description: 'Configured and Merged by Ansible Network'
	enabled: True
      - name: GigabitEthernet0/3
	description: 'Configured and Merged by Ansible Network'
	mtu: 2800
	enabled: False
	speed: 100
	duplex: full
    state: merged

---
- name: Add loopbacks on all my nxos switches
  hosts: nxosswitches
  connection: local
  gather_facts: no
  tasks:
    - name: Create loopback
      with_items: "{{local_loopback}}"
      nxos_interfaces:
	interface: "{{item.name}}"
	mode: layer3
	description: "{{item.desc}}"
	admin_state: down

    - name: Configure new loopback interfaces
      with_items: "{{local_loopback}}"
      nxos_l3_interfaces:
	config:
	  - name: "{{item.name}}"
	    ipv4:
	      - address: "{{item.ip_address}}"
	state: merged

With this example, we must also have the variables to pass into items So, the vars directory has this somehow?? If I were to guess I would say the local_loopback is a variable somewhere that is acually a list of items. Maybe:

local_loopback:
- name: loopback 1
- name: loopback 2
- name:
loopback 3

But that is just my guess!!! What is the actual method???

nxos_switch1.yml
---
local_loopback:
  - name: Loopback1
    desc: Ansible created loopback 1 interface
    ip_address: 192.168.1.1/24
  - name: Loopback2
    desc: Ansible created loopback 2 interface
    ip_address: 192.168.2.1/24


nxos_swtich2.yml
---
  - name: Loopback3
    desc: Ansible created loopback 3 interface
    ip_address: 192.168.3.1/24
  - name: Loopback4
    desc: Ansible created loopback 4 interface
    ip_address: 192.168.4.1/24

From a config in the traditional sense:

ip routing
router ospf 6401
network 172.16.0.0 0.15.255.255 area 0
router-id 172.17.17.100

• Arista: arista.eos
• Cisco: cisco.ios, cisco.iosxr, cisco.nxos,… see: Ansible Modules provided by Cisco:
• Juniper: junipernetworks.junos
• VyOS: vyos.vyos

Add this somewhere ansible iosv -m ios_command -a "commands='show ip int brief'"

(venv-ansible) ansible@c8host ~/Ansible-CentOS[653] $
tree .
.
├── ansible.cfg
├── base-utils.yml
├── hosts
├── playbooks
│   ├── dnf-delete.yml
│   ├── dnf-install-list.yml
│   ├── dnf-install-list.yml~
│   ├── dnf-list.yml
│   ├── dnf-updateall.yml
│   ├── dnf-update-specifics.yml
│   └── dnf-update.yml
└── roles
    ├── apache-LAMP
    │   ├── defaults
    │   ├── files
    │   ├── tasks
    │   │   └── main.yml
    │   ├── tests
    │   └── vars
    ├── basic-utils
    │   ├── defaults
    │   ├── files
    │   │   └── bash.bashrc
    │   ├── tasks
    │   │   ├── install-utils.yml
    │   │   ├── main.yml
    │   │   └── zintis-note.txt
    │   ├── tests
    │   └── vars
    ├── each-dir-is-a-role.txt
    ├── install-pb.yml
    └── mailservers
	├── defaults
	├── files
	├── tasks
	│   └── main.yml
	├── tests
	└── vars

20 directories, 22 files

If I want to run a basics-playbook.yml you must be at the level above the roles directory. Even if the basics-playbook.yml file is in playbooks sub-directory. Best to run it as: ansible-playbooks playbooks/basic-playbook.yml

In stead of having /etc/ansible.cfg as the only file, create a new directory structure for each project, and put the ansible.cfg file in the top level of that new directory. Following that, instead of using the default /etc/ansible/hosts file, you can create a hosts file in the ./inventory subdirectory as well.

Summarizing:

1. a new folder per project
2. ansible.cfg in the top directory
3. ./inventory/hosts as hosts file
4. ./group_vars

ansible@c8host ~/Centos-ansible[717] $
tree
.
├── all-in-1-playbooks
│   ├── all-in-one-playbooks-are-listed-here
│   ├── ansible.cheat
│   ├── dnf-update.yml
│   ├── shutdown-all.yml
│   └── shutdown-ops.yml
├── basics-playbook.yml
├── filter_plugins
├── group_vars
├── hosts
├── host_vars
├── library
├── module_utils
├── playbooks-using-roles
│   └── labservers.yml
├── production
├── roles
│   ├── each-dir-is-a-role.txt
│   ├── apache-LAMP
│   │   ├── defaults
.
.
.

│   ├── lab-tier
│   │   ├── defaults
│   │   │   └── main.yml
│   │   ├── files
│   │   │   ├── bar.txt
│   │   │   └── fu.txt
│   │   ├── handlers
│   │   │   ├── main.yml
│   │   │   └── main.yml~
│   │   ├── library
│   │   ├── meta
│   │   │   └── main.yml
│   │   ├── tasks
│   │   │   └── main.yml
│   │   ├── templates
│   │   │   └── ntp.conf.j2
│   │   ├── tests
│   │   └── vars
│   │       └── main.yml
│   └── whats-my-status
│       ├── defaults
│       │   └── main.yml
│       ├── files
│       │   ├── bar.txt
│       │   └── fu.txt
│       ├── handlers
│       │   ├── main.yml
│       │   └── main.yml~
│       ├── library
│       ├── meta
│       │   └── main.yml
│       ├── tasks
│       │   ├── debug-directly.yml
│       │   ├── debug-with-msg.yml
│       │   ├── debug-with-multiline-msg.yml
│       │   └── main.yml
│       ├── templates
│       │   └── ntp.conf.j2
│       ├── tests
│       └── vars
│           └── main.yml
├── samba-playbook.yml
├── site.yml
├── staging
├── status-playbook.yml
└── web-playbook.yml

64 directories, 68 files
ansible@c8host ~/Centos-ansible[718] $

The ansible-vault command is a command line tool to create and view encrypted variables. You can then place encrypted content in source code management (SCM) aka VCS, such as git.

Remember that ansible vault only protects data at rest.

You can use encrypted variables in ad-hoc commands and playbooks by supplying the passwords. You can modify ansible.cfg to specify the location of a password file, or to always prompt for a password.

I will encrypt all my variables with a single password, but you could decide to use different passwords for different needs. For example you could run a playbook that includes two vars files, one for production, one for dev. and encrypt with different passwords for the two.

ansible-playbook -i hosts --ask-vault-pass --extra-vars '@cluster.data.yml' reboot.yml

See docs.ansible.com for more info on vault.

When you run a task or playbook that uses encrypted variables or files, you must provide the passwords to decrypt the variables or files. You can do this at the command line or in the playbook itself.

Passing a single password

If all the encrypted variables and files your task or playbook needs use a single password, you can use the --ask-vault-pass or --vault-password-file cli options.

This command will encrypt single values inside a YAML file, thatn can be then included in a playbook, role, or variables file. You will need to pass three items:

1. a source for the vault password (prompt, file, or script, with or without a vault ID)
2. the strting to encrypt
3. the string name (name of the variable)

For example:

• ansible-vault encrypt_string <password_source> '<string_to_encrypt>' --name '<string_name_of_variable>'

Or a more concrete example to encrypt the string 'Cisco123!' using the only password stored in a "a_password_file" and name the variable 'IOSv-passwd':

• ansible-vault encrypt_string --vault-password-file a_password_file 'Cisco123!' --name 'IOSv-passwd'

To be prompted for a string to encrypt, encrypt it with the ‘dev’ vault password from ‘a_password_file’ name the variable ‘new_user_password’ and give it the vault ID label ‘dev’:

• ansible-vault encrypt_string --vault-id dev@a_password_file --stdin-name 'new_user_password'

You will be prompted: "Reading plaintext input from stdin. (ctrl-d to end input)" Warning, do NOT press ENTER after supplying the string to encrypt, or \n will be added to the end of the string to encrypt.

Use the debug module. You will need to pass the passwd. For example, if the above was stored in a file vars.yml, you could do:

-ansible localhost -m ansible.builtin.debug -a var=new_user_password" -e "@vars.yml" --vault-id dev@a_password_file

With a single password, you can --ask-vault-pass while in a playbook to then get prompted for one. or

With a singel password, you can retrieve the password from the file /path/to/my/vault-password-*

file Ad Hoc Commands ( and parallel task execution ) Once you have an ansible instance available, and the nodes have python and ssh setup, you can talk to it right away, without any additional setup.

ansible lab -m ping

Remember to run this from your ansible root directory or it won't work.

Running ansible all -m setup > my-ansible-host-ansible-extracted-facts is particularly useful to see what your are dealing with. The plethora of facts returned can help you refine your future ansible calls. For example, you could have a task that only applies to hosts from a specific ansible os family by adding when: ansible_os_family = 'RedHat'= to a task such as:

cat dnf-update.yml 
---
  - name: update figlet, vim, iftop on all hosts
    hosts: opsvms
    tasks:
      - name: install epel repo first
	dnf:
	  name: epel-release
	  state: present
	become: true
	when: ansible_os_family == 'RedHat'

      - name: dnf update figlet vim and iftop
	dnf:
	  name:
	    - figlet
	    - vim
	    - iftop
	  state: latest
	become: true

But you would not have known that was an option had you not run the setup module

ansible all -m shell -a 'getent passwd | grep ansi'
vm3 | CHANGED | rc=0 >>
ansible:x:1003:1003::/home/ansible:/bin/bash
vm1 | CHANGED | rc=0 >>
ansible:x:1002:1002::/home/ansible:/bin/bash
vm4 | CHANGED | rc=0 >>
ansible:x:10003:10003::/home/ansible:/bin/bash
vm5 | CHANGED | rc=0 >>
ansible:x:1002:1002::/home/ansible:/bin/bash
vm2 | CHANGED | rc=0 >>
ansible:x:1002:1002::/home/ansible:/bin/bash


ansible -m command -a "uname -a" opsvms
vm3 | CHANGED | rc=0 >>
Linux vm3 4.18.0-147.5.1.el8_1.x86_64 #1 SMP Wed Feb 5 02:00:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
vm2 | CHANGED | rc=0 >>
Linux vm2 4.18.0-147.5.1.el8_1.x86_64 #1 SMP Wed Feb 5 02:00:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
vm4 | CHANGED | rc=0 >>
Linux vm4 3.10.0-1062.18.1.el7.x86_64 #1 SMP Tue Mar 17 23:49:17 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
vm1 | CHANGED | rc=0 >>
Linux vm1 4.18.0-147.5.1.el8_1.x86_64 #1 SMP Wed Feb 5 02:00:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
vm5 | CHANGED | rc=0 >>
Linux vm5 4.18.0-147.8.1.el8_1.x86_64 #1 SMP Thu Apr 9 13:49:54 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
(venv-ansible) ansible@c8host ~[89] $

ansible -m command -a "host cbc.ca" opsvms
vm3 | CHANGED | rc=0 >>
cbc.ca has address 104.126.76.230
cbc.ca mail is handled by 10 alt4.aspmx.l.google.com.
cbc.ca mail is handled by 5 alt1.aspmx.l.google.com.
cbc.ca mail is handled by 10 alt3.aspmx.l.google.com.
cbc.ca mail is handled by 1 aspmx.l.google.com.
cbc.ca mail is handled by 5 alt2.aspmx.l.google.com.
vm1 | CHANGED | rc=0 >>
cbc.ca has address 104.126.76.230
cbc.ca mail is handled by 10 alt3.aspmx.l.google.com.
cbc.ca mail is handled by 5 alt2.aspmx.l.google.com.
cbc.ca mail is handled by 10 alt4.aspmx.l.google.com.
cbc.ca mail is handled by 1 aspmx.l.google.com.
cbc.ca mail is handled by 5 alt1.aspmx.l.google.com.
vm4 | CHANGED | rc=0 >>
cbc.ca has address 104.126.76.230
cbc.ca mail is handled by 5 alt1.aspmx.l.google.com.
cbc.ca mail is handled by 5 alt2.aspmx.l.google.com.
cbc.ca mail is handled by 10 alt4.aspmx.l.google.com.
cbc.ca mail is handled by 10 alt3.aspmx.l.google.com.
cbc.ca mail is handled by 1 aspmx.l.google.com.
vm5 | CHANGED | rc=0 >>
cbc.ca has address 104.126.76.230
cbc.ca mail is handled by 10 alt3.aspmx.l.google.com.
cbc.ca mail is handled by 10 alt4.aspmx.l.google.com.
cbc.ca mail is handled by 1 aspmx.l.google.com.
cbc.ca mail is handled by 5 alt1.aspmx.l.google.com.
cbc.ca mail is handled by 5 alt2.aspmx.l.google.com.
vm2 | CHANGED | rc=0 >>
cbc.ca has address 104.126.76.230
cbc.ca mail is handled by 10 alt4.aspmx.l.google.com.
cbc.ca mail is handled by 1 aspmx.l.google.com.
cbc.ca mail is handled by 5 alt1.aspmx.l.google.com.
cbc.ca mail is handled by 10 alt3.aspmx.l.google.com.
cbc.ca mail is handled by 5 alt2.aspmx.l.google.com.
(venv-ansible) ansible@c8host ~[91] $

Here is the output (with errors) of my first ansible ad-hoc command:

First attempt at an ansible hostname -m ping

(venv-pandas) zintis@c8host /etc/ansible[1025] $
ansible -i /etc/ansible/hosts mailservers -m ping
[Warning]: Unhandled error in Python interpreter discovery for host vm3: unexpected output from Python interpreter discovery
[WARNING]: sftp transfer mechanism failed on [vm3]. Use ANSIBLE_DEBUG=1 to see detailed information
[WARNING]: scp transfer mechanism failed on [vm3]. Use ANSIBLE_DEBUG=1 to see detailed information
[WARNING]: Platform unknown on host vm3 is using the discovered Python interpreter at /usr/bin/python, but future installation of another Python interpreter
could change this. See https://docs.ansible.com/ansible/2.9/reference_appendices/interpreter_discovery.html for more information.
vm3 | FAILED! => {
  "ansible_facts": {
      "discovered_interpreter_python": "/usr/bin/python"
  },
  "changed": false,
  "module_stderr": "Shared connection to vm3 closed.\r\n",
  "module_stdout": " \r\n                 _____ \r\n__   ___ __ ___ |___ / \r\n\\ \\ / /  _ ` _ \\  |_ \\\r\n \\ V /| | | | | |___) |\r\n  \\_/ |_| |_| |_|____/\r\n \r\n/bin/sh: /usr/bin/python: No such file or directory\r\n",
  "msg": "The module failed to execute correctly, you probably need to set the interpreter.\nSee stdout/stderr for the exact error",
  "rc": 127
}
vm2 | SUCCESS => {
  "ansible_facts": {
      "discovered_interpreter_python": "/usr/libexec/platform-python"
  },
  "changed": false,
  "ping": "pong"
}
vm4 | SUCCESS => {
  "ansible_facts": {
      "discovered_interpreter_python": "/usr/bin/python"
  },
  "changed": false,
  "ping": "pong"
}
(venv-pandas) zintis@c8host /etc/ansible[1025] $

The error were fixed by ensuring my ssh connection was corrected to vm3.

When you get warnings that a host is using a discovered interpreter, you can override the discovered interpreter by adding a line to the hosts file for that host, to specify exactly what the intpreter should be:

But that might not be the best long term solution. Need to investigate.

Ansible commands can be straight commands for the local ansible controller or modules that all you to execute ad-hoc commands on nodes, or groups of nodes.

(venv-ansible) ansible@c8host ~/CentOS-vms/roles[238] $
 tree ..
 ..
 ├── ansible.cfg
 ├── hosts
 ├── playbooks
 └── roles
     ├── apache-LAMP
     │   ├── defaults
     │   ├── files
     │   ├── tasks
     │   │   └── main.yml
     │   ├── tests
     │   └── vars
     ├── basic-utils
     │   ├── defaults
     │   ├── files
     │   ├── tasks
     │   │   └── main.yml
     │   ├── tests
     │   └── vars
     ├── each-dir-is-a-role.txt
     └── mailservers
	 ├── defaults
	 ├── files
	 ├── tasks
	 │   └── main.yml
	 ├── tests
	 └── vars

 20 directories, 6 files

Here is a more extensive example I got online:

.
├── ansible.cfg
├── dbservers.yaml
├── dev
├── dev_BAK
├── filter_plugins
├── group_vars
├── host_vars
├── library
├── module_utils
├── playbooks
│   └── fridayUpdates.yaml
├── prod
├── prod_BAK
├── roles
│   ├── apache
│   │   ├── defaults
│   │   │   └── main.yml
│   │   ├── files
│   │   │   ├── cci.conf
│   │   │   ├── wildcard-plus.cci.fsu.edu.key
│   │   │   └── wildcard-plus-intermediate.cci.fsu.edu.cer
│   │   ├── handlers
│   │   │   └── main.yml
│   │   ├── meta
│   │   │   └── main.yml
│   │   ├── README.md
│   │   ├── tasks
│   │   │   ├── apache.yaml
│   │   │   └── main.yml
│   │   ├── templates
│   │   ├── tests
│   │   │   ├── inventory
│   │   │   └── test.yml
│   │   └── vars
│   │       └── main.yml
│   ├── common
│   │   ├── defaults
│   │   │   └── main.yml
│   │   ├── files
│   │   │   ├── 00-graylog.conf
│   │   │   ├── 01-graylog_apache.conf
│   │   │   ├── 01-graylog.conf
│   │   │   ├── 02-graylog_fail2ban.conf
│   │   │   ├── 03-graylog_apt.conf
│   │   │   ├── 04-graylog_mysql.conf
│   │   │   ├── apache-404.conf
│   │   │   ├── apache_jail.local
│   │   │   ├── km12n_zpreztorc
│   │   │   ├── snmpd.conf
│   │   │   └── web15c_zpreztorc
│   │   ├── handlers
│   │   │   └── main.yml
│   │   ├── meta
│   │   │   └── main.yml
│   │   ├── README.md
│   │   ├── tasks
│   │   │   ├── fail2ban.yaml
│   │   │   ├── hosts.yaml
│   │   │   ├── hyperv.yaml
│   │   │   ├── libreagent.yaml
│   │   │   ├── main.yml
│   │   │   ├── rsyslog.yaml
│   │   │   ├── snmp.yaml
│   │   │   └── zsh.yaml
│   │   ├── templates
│   │   │   └── hosts.j2
│   │   ├── tests
│   │   │   ├── inventory
│   │   │   └── test.yml
│   │   └── vars
│   │       └── main.yml
│   └── mysql
│       ├── defaults
│       │   └── main.yml
│       ├── files
│       ├── handlers
│       │   └── main.yml
│       ├── meta
│       │   └── main.yml
│       ├── README.md
│       ├── tasks
│       │   ├── main.yml
│       │   └── mysql.yaml
│       ├── templates
│       ├── tests
│       │   ├── inventory
│       │   └── test.yml
│       └── vars
│           └── main.yml
├── site.yml
├── virtualmin.yaml

The local machine also has the ansible configuration file, and the inventory file, as explained below

Playbooks can finely orchestrate multiple slices of your infrastructure topology, with very detailed control over how many machines to tackle at a time. This is where Ansible starts to get most interesting.

Ansible's approach to orchestration is one of finely-tuned simplicity, as we believe your automation code should make perfect sense to you years down the road and there should be very little to remember about special syntax or features.

Here's what a playbook looks like. As a reminder, this is only here as a teaser - hop over to docs.ansible.com for the complete documentation and all that's possible.

---
- dnf: name={{contact.item}} state=installed
  with_items:
    - app_server
    - acme_software
 - service: name=app_server state=running enabled=yes
 - template:
   src=/opt/code/templates/foo.j2 
   dest=/etc/foo.conf
 notify: 
 - restart app server

Another example. How is this different? :

---
- hosts: all
  tasks:
    - name: ensure ntpd is at the latest version
      dnf: pkg=ntp state=latest
      notify:
      - restart ntpd
  handlers:
    - name: restart ntpd
      service: name=ntpd state=restarted

Here is a similar YAML file for a job

---
name: play1
hosts: webserver
tasks:
  -name: install apache
    dnf:
        name: apache
	state: present
  -name: start apache
    service:
        name: apache
	state: start
name: play2
hosts: databaseserver
tasks:
  -name: MySQL
  -state: present

See the "key-value-notation.org" file for more detail. I am including just an extract from that file here:

And of course, members of the list can also be maps:

---
apiVersion: v1
kind: Pod
metadata:
  name: rss-site
  labels:
  app: web
spec:
  containers:
  - name: front-end
    image: nginx
    ports:
      - containerPort: 80
      - sec_containerPort: 443
  - name: rss-reader
    image: nickchase/rss-php-nginx:v1
    ports:
      - containerPort: 88
      - sec_containerPort: 443

So as you can see here, we have a list of containers “objects”, each of
which consists of a name, an image, and a list of ports.  Each list item
under ports is itself a map that lists the containerPort and its value.

The Ansible documentation explores this in much greater depth. There’s a LOT more that you can do, including:

Take machines in and out of load balancers and monitoring windows Have one server know the IP address of all the others using facts gathered about those particular servers - and use those to dynamically build out configuration files some variables and prompt for others, and set defaults for when they are not set. Use the result of one command to decide whether to run another. There are lots of advanced possibilities but it's easy to get started.

Most importantly, the language remains readable and transparent, and you never have to do things like declare explicit ordering relationships or write code in a programming language.

extend ansible: modules, plugins and api Should you want to write your own, Ansible modules can be written in any language that can return JSON (Ruby, Python, bash, etc). Inventory can also plug in to any datasource by writing a program that speaks to that datasource and returns JSON. There's also various Python APIs for extending Ansible’s connection types (SSH is not the only transport possible), callbacks (how Ansible logs, etc), and even for adding new server side behaviors.

Passwords are supported, but SSH keys with ssh-agent are one of the best ways to use Ansible. Though if you want to use Kerberos, that's good too. Lots of options! Root logins are not required, you can login as any user, and then su or sudo to any user.

Ansible's "authorized_key" module is a great way to use ansible to control what machines can access what hosts. Other options, like kerberos or identity management systems, can also be used.

ssh-agent bash ssh-add ~/.ssh/id_rsa MANAGE YOUR INVENTORY IN SIMPLE TEXT FILES By default, Ansible represents what machines it manages using a very simple INI file that puts all of your managed machines in groups of your own choosing.

To add new machines, there is no additional SSL signing server involved, so there's never any hassle deciding why a particular machine didn’t get linked up due to obscure NTP or DNS issues.

If there's another source of truth in your infrastructure, Ansible can also plugin to that, such as drawing inventory, group, and variable information from sources like EC2, Rackspace, OpenStack, and more.

This is the learning-loops.yml playbook.

     ---
     - name: Looping over a single dictionary
       hosts: r1 r2
       gather_facts: no

       vars:
         runtask: true
         saygoodby: false
         a: 1
         b: [2, 3, 4]
         c:
           Title: "Brave New World"
           Author: "Aldous Huxley"
           Publication_date: 1932

       tasks:
       - debug:
         msg: "Looping where item is now {{ item }}"  # option 1 and option 2
         msg: "Looping where item is now {{ item.name }}" # option 3
         loop: "{{ c  }}"   # option 1 (see below)
         loop: "{{ c|dict2items  }}"   # option 2
         loop: "{{ c  }}"   # option 3
       # option 1  Gives an error:  looping over c, while c is a dictionary
       # fails because you can only loop over a list, and c is not a list
       # it is a dictionary.   To fix this see option #2

       # option 2 Works as "dict2items" converts a dictionary to a list.  
       # but it may not be what your were looking for.  You will get these
       # messages



ansible-playbook learning-loops.yml # with option 2. 

TASK [debug] *******************************************************************************************************************************
ok: [r1] => (item={'key': 'Title', 'value': 'Brave New World'}) => {
    "msg": "Looping where item is now {'key': 'Title', 'value': 'Brave New World'}"
}
ok: [r2] => (item={'key': 'Title', 'value': 'Brave New World'}) => {
    "msg": "Looping where item is now {'key': 'Title', 'value': 'Brave New World'}"
}
ok: [r1] => (item={'key': 'Author', 'value': 'Aldous Huxley'}) => {
    "msg": "Looping where item is now {'key': 'Author', 'value': 'Aldous Huxley'}"
}
ok: [r1] => (item={'key': 'Publication_date', 'value': 1932}) => {
    "msg": "Looping where item is now {'key': 'Publication_date', 'value': 1932}"
}
ok: [r2] => (item={'key': 'Author', 'value': 'Aldous Huxley'}) => {
    "msg": "Looping where item is now {'key': 'Author', 'value': 'Aldous Huxley'}"
}
ok: [r2] => (item={'key': 'Publication_date', 'value': 1932}) => {
    "msg": "Looping where item is now {'key': 'Publication_date', 'value': 1932}"
}

---
- name: Looping over a list of dictionaries
  hosts: ospfrouters
  gather_facts: no
  vars:
    runtask: true
    saygoodby: false
    a: 1
    b: [2, 3, 4]
     c:
     - hello: "Hello world."
       goodbye: "Goodbye dude."
     - e: 2.7182818 
       pi: 3.14159265

  tasks:
    - debug:
        msg: "Looping where item is now {{ item }}"  # option 1 (see below)
        msg: "Looping where item is now {{ item.key  }}" # option 2
        msg: "Looping where item is now {{ item['key']  }}" # option 3
      loop: "{{ c  }}" 

  # option 1  prints out the whole dictionary "c" twice
  # once for the two keys "hello" and "goodbye" and the 2nd time
  # for the kyes e and pi

  # option 2 prints out "hello Hello world." ok, but then fails
  # on the 2nd go around because "hello" is not a valid key in the
  # 2nd dictionary (only "e" and "pi" are defined keys now)

  # option 3 is exactly the same as option 2

Option 2 output, where the message is item.key I get this output

TASK [debug] *****************************************************************************************************************************
ok: [r1] => (item={'key': 'Title', 'value': 'Brave New World'}) => {
    "msg": "Looping where item is now Title"
}
ok: [r2] => (item={'key': 'Title', 'value': 'Brave New World'}) => {
    "msg": "Looping where item is now Title"
}
ok: [r1] => (item={'key': 'Author', 'value': 'Aldous Huxley'}) => {
    "msg": "Looping where item is now Author"
}
ok: [r1] => (item={'key': 'Publication_date', 'value': 1932}) => {
    "msg": "Looping where item is now Publication_date"
}
ok: [r2] => (item={'key': 'Author', 'value': 'Aldous Huxley'}) => {
    "msg": "Looping where item is now Author"
}
ok: [r2] => (item={'key': 'Publication_date', 'value': 1932}) => {
    "msg": "Looping where item is now Publication_date"
}

But if I change it item.value I will get this output

TASK [debug] *****************************************************************************************************************************
ok: [r1] => (item={'key': 'Title', 'value': 'Brave New World'}) => {
    "msg": "Looping where item is now Brave New World"
}
ok: [r2] => (item={'key': 'Title', 'value': 'Brave New World'}) => {
    "msg": "Looping where item is now Brave New World"
}
ok: [r1] => (item={'key': 'Author', 'value': 'Aldous Huxley'}) => {
    "msg": "Looping where item is now Aldous Huxley"
}
ok: [r1] => (item={'key': 'Publication_date', 'value': 1932}) => {
    "msg": "Looping where item is now 1932"
}
ok: [r2] => (item={'key': 'Author', 'value': 'Aldous Huxley'}) => {
    "msg": "Looping where item is now Aldous Huxley"
}
ok: [r2] => (item={'key': 'Publication_date', 'value': 1932}) => {
    "msg": "Looping where item is now 1932"
}

So, at this point my playbook is this:

---
- name: Looping over a single dictionary
  hosts: r1, r2
  gather_facts: no

  vars:
    runtask: true
    saygoodby: false
    a: 1
    b: [2, 3, 4]
    c:
      Title: "Brave New World"
      Author: "Aldous Huxley"
      Publication_date: 1932

  tasks:
    - debug:
        msg: "Looping where item is now {{ item.value }}" 
      loop: "{{ c|dict2items }}"  # option 0

Some modules are more efficient if they handle the looping. For example, right out of docs.ansible.com

- name: Optimal yum
  ansible.builtin.yum:
    name: "{{  list_of_packages  }}"
    state: present

is better than:

- name: Non-optimal yum, slower and may cause issues with interdependencies
  ansible.builtin.yum:
    name: "{{  item  }}"
    state: present
  loop: "{{  list_of_packages  }}"

1. setup an Ansible command station on VLAN 4094, with ip addr 192.168.0.0/24
2. create a credentials .yml file and store the username and password needed for the SSH connections

   file: creds.yml
   username: admin
   password: C1sco123!
   
   

3. create an inventory file that contains descriptions of your devices. This inventory file can also arbitrarily group items as you see fit. An example could be branch_routers, core_routers, access_switches etc…

   file: inventory
   [branch_routers]
   172.17.18.1
   172.17.20.1
   172.17.22.1
   
   [core_routers]
   10.0.5.1
   10.0.6.1
   10.0.10.1
   
   [access_switches}
   192.168.1.1
   192.168.21.1
   192.168.31.1
   192.168.41.1
   
   

4. create a playbook, writtin in YAML format.

   —

   • name:

tasks:
- name: Set ip addresses of all interfaces defined in host_vars
  cisco.ios.ios_l3_interfaces:
    config:
    - name: "{{ item.key }}"
      ipv4:
      - address: "{{ item.value }}"
    state: merged
    loop: "{{ interfacestochange|dict2items }}"



 - name: configure ip helpers on multiple interfaces
   cisco.ios.ios_config:
     lines:
     - ip helper-address 172.26.1.10
     - ip helper-address 172.26.3.8
     parents: '{{ item }}'
   with_items:
   - interface Ethernet1
   - interface Ethernet2
   - interface GigabitEthernet1

For the first task in the above example, this was r4.yml and r5.yml:

# r4   
interfacestochange:
  GigabitEthernet0/1: 10.0.0.17/28
  GigabitEthernet0/2: 10.0.0.2/28
  GigabitEthernet0/3: 172.31.30.4/24
  Loopback7: 172.17.17.4/32

# r5
interfacestochange:
  GigabitEthernet0/1: 172.16.16.34/28
  GigabitEthernet0/3: 172.16.16.49/28
  Loopback7: 172.17.17.5/32

Here is my r1 host_vars file:

interfacestochange:
  GigabitEthernet0/1: 172.16.16.33/28
  GigabitEthernet0/3: 172.16.16.17/28
  Loopback7: 172.17.17.1/32

describe_int:
  GigabitEthernet0/1: "Ethernet towards r5 and route to the Internet"
  GigabitEthernet0/3: "Ethernet towards r3 and border router"

With the following playbook, I can add descriptions to those two interfaces.

See ansible install on centos8 (linux) for installation on a Linux host.

if you have installed Ansible through Brew or pip, you have to create the ansible.cfg file (running ansible --version will show None as config file). You can set it on the /etc/ansible/ansible.cfg or even on your home folder as .ansible.cfg. After that, if you run ansible –version, you will see that it will recognize the ansible config file.

brew install ansible

i had to do this because my source venv-pandas/bin/activate was giving me errors:

bash: venv-ansible/bin/activate: line 35: syntax error near unexpected token `}'
bash: venv-ansible/bin/activate: line 35: `}'

(venv-pandas) zintis@c8host ~[1013] $ansible --version
ansible 2.9.7
config file = none
configured module search path = ['/home/zintis/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
ansible python module location = /home/zintis/venv-pandas/lib/python3.8/site-packages/ansible
executable location = /home/zintis/venv-pandas/bin/ansible
python version = 3.8.2 (default, apr 30 2020, 01:58:05) [gcc 8.3.1 20190507 (red hat 8.3.1-4)]
(venv-pandas) zintis@c8host ~[1014] $

see section on config file, but fixed