Sunday, January 16, 2022

Ansible Error Handling and Fail Handling

Hello everyone!! In this post I would like to experiment with the failure handling with block-rescue-always block in a Ansible tasks in playbook. 

Prerequisites

* Ansible installed and their must be Target nodes
* Basic understanding of any programming language that uses try- catch blocks

Ansible stops playbook execution on a task failure and we can choose to ignore that using 'ignore_errors' to continue with remaining tasks. (in Python we have 'pass' similar to that).

If you have couple of tasks in a playbook, when first task fails Ansible stops there. But if you want to execute the next tasks even though your first task failed.


---
# File name: ignore_err.yml
 - name: check ignore errors
   hosts: localhost
   gather_facts: false
   tasks:
    - block:
        - command: "ls ~/"
        - command: "ls ~/bin"
        - command: "ls /etc/hosts"
          become_user: root
          become: yes
      ignore_errors: yes

Now you can try to execute with 13 line and with out that line observe the output.
ansible-playbook ignore_err.yml
Execution of ignore_error play.

block concept

Common tasks 1. Install Apache httpd, memcached packages 2. We can use templates/src 3. We can start the services
tasks:
  - block:
    - yum: name={{ item }} state=installed
	  with_items:
	    - httpd
		- memcached
	- template: src=templates/src.j2 dest=/etc/mytest.conf
	
	- service: name=httpd state=started enabled=True 
  when: ansible_distribution == 'CentOS'
  become: true
  become_user: root

Nested blocks

Block of blocks
---
 - name: Block of blocks
	tasks:
	  - name: install web server
	  - block:
		  - block:
			  - name: Install apache2
				apt: name=apache2 state=present
			when: ansible_os_family == "Debian"
		  - block:
			  - name: Install HTTPd
				yum: name=httpd state=present
			when: ansible_os_family == "RedHat"
		tags: package

Block-level variable scope

We can have different scope for the variables defined at global playbook level and here we can also experiance the block level variables they can be only accessable with in the block, outside the block it will be 'UNDEFINED VARIABLE'.
 - hosts: localhost
   vars:
     mystate: Happy
   tasks:
     - block:
             - debug: var=mystate
             - debug: var=mynextstate
       vars:
         mynextstate: Learning
     - debug: var=mynextstate
Execution:
ansible-playbook block_vars.yml
Screenshot of execution:

block-rescue

Ansible allows us to define the scope for do the code has errors under the block directive. When fatal error encountered Ansible control will jump out to the rescue directive section. Where you can perform some tasks that can be like sending failure notifications to the team on slack or email or pager.
- name: Testing block-rescue directives
  hosts: localhost
  tasks:
    - name: Handling the error tasks status
      block:
          - debug:
                  msg: 'This task is successful'
          - name: This will force failure
            command: /bin/false
          - debug:
                  msg: 'This task will not be executed'
      rescue:
          - name: Sleep for 30 seconds and continue with play
            wait_for:
              timeout: 30
            delegate_to: localhost

          - debug:
                  msg: 'As there was a failure in block section, rescue section will run'
Execution
ansible-playbook block-rescue.yml
Screenshot:

block-rescue-always in Ansible

The error point can be by running /usr/bin/false command

Error handling with three blocks 
1. block which contains tasks there could be some possible errors 
2. rescue part will be executed when there is error occurred in the upper block
3. To ensure some task that should executed always even when you are using the block having errors or not. 



---
- name: save file as block-rescue-always.yml
  hosts: localhost
  connection: local

  tasks:
    - block:
            - debug:
                msg: "I execute here..."
            - command: /usr/bin/false
            - debug:
                msg: "I never touched :("
      rescue:
            - debug:
                msg: "I caught Error here..."

            - command: /usr/bin/false
            - debug:
                msg: "I also never touched..."
      always:
            - debug:
                msg: "I am always there like God!"

Execution output
ansible-playbook block_rescue_always.yml
screenshot:

Using fail module in Ansible play

In most of the automation projects, Focus on the failure with handling tasks is major requirement
---
 - name: testing fail
   gather_facts: no
   hosts: localhost
   tasks:
     - name: check home bin folder
       command: ls ~/bin
       register: error_msg
       ignore_errors: yes

     - name: debug bin
       debug:
         msg: "{{ error_msg }}"

     - name: failing blok
       fail:
         msg: "FAILED exiting now..."
       when: error_msg.rc != 0

     - name: check home bin folder
       command: ls ~/
       register: home_msg

     - name: debug home
       debug:
         msg: "{{ error_msg }}"
         
Execution of the fail module
ansible-playbook fail_test.yml
Screenshot:

Ansible fail module error handling ignore error

Hope you like this post write your experience with error handling in Ansible playbooks.

References:


No comments:

Categories

Kubernetes (24) Docker (20) git (13) Jenkins (12) AWS (7) Jenkins CI (5) Vagrant (5) K8s (4) VirtualBox (4) CentOS7 (3) docker registry (3) docker-ee (3) ucp (3) Jenkins Automation (2) Jenkins Master Slave (2) Jenkins Project (2) containers (2) create deployment (2) docker EE (2) docker private registry (2) dockers (2) dtr (2) kubeadm (2) kubectl (2) kubelet (2) openssl (2) Alert Manager CLI (1) AlertManager (1) Apache Maven (1) Best DevOps interview questions (1) CentOS (1) Container as a Service (1) DevOps Interview Questions (1) Docker 19 CE on Ubuntu 19.04 (1) Docker Tutorial (1) Docker UCP (1) Docker installation on Ubunutu (1) Docker interview questions (1) Docker on PowerShell (1) Docker on Windows (1) Docker version (1) Docker-ee installation on CentOS (1) DockerHub (1) Features of DTR (1) Fedora (1) Freestyle Project (1) Git Install on CentOS (1) Git Install on Oracle Linux (1) Git Install on RHEL (1) Git Source based installation (1) Git line ending setup (1) Git migration (1) Grafana on Windows (1) Install DTR (1) Install Docker on Windows Server (1) Install Maven on CentOS (1) Issues (1) Jenkins CI server on AWS instance (1) Jenkins First Job (1) Jenkins Installation on CentOS7 (1) Jenkins Master (1) Jenkins automatic build (1) Jenkins installation on Ubuntu 18.04 (1) Jenkins integration with GitHub server (1) Jenkins on AWS Ubuntu (1) Kubernetes Cluster provisioning (1) Kubernetes interview questions (1) Kuberntes Installation (1) Maven (1) Maven installation on Unix (1) Operations interview Questions (1) Oracle Linux (1) Personal access tokens on GitHub (1) Problem in Docker (1) Prometheus (1) Prometheus CLI (1) RHEL (1) SCM (1) SCM Poll (1) SRE interview questions (1) Troubleshooting (1) Uninstall Git (1) Uninstall Git on CentOS7 (1) Universal Control Plane (1) Vagrantfile (1) amtool (1) aws IAM Role (1) aws policy (1) caas (1) chef installation (1) create organization on UCP (1) create team on UCP (1) docker CE (1) docker UCP console (1) docker command line (1) docker commands (1) docker community edition (1) docker container (1) docker editions (1) docker enterprise edition (1) docker enterprise edition deep dive (1) docker for windows (1) docker hub (1) docker installation (1) docker node (1) docker releases (1) docker secure registry (1) docker service (1) docker swarm init (1) docker swarm join (1) docker trusted registry (1) elasticBeanStalk (1) global configurations (1) helm installation issue (1) mvn (1) namespaces (1) promtool (1) service creation (1) slack (1)