The Ansible Dry Run or Ansible Check mode feature is to validate your playbook before execution
With the Ansible Dry Run feature, you can run the playbook without having to make changes to the server. This allows us to see what changes are going to be made when the Playbook is running
.
Here is a playbook to install and start the Apache HTTP web server. But I want to run it dry.
– – name: Playbook hosts: web servers become: yes become_user: root tasks: – name: make sure Apache is on the latest version yum: name: httpd status: last – name: make sure Apache is running the service: name: httpd status: started
Our goal is to install the Apache web server, but I want to run it dry first and see what changes it makes to the remote host.
In a way, I can use this to see which machines already have httpd/apache installed.
We can dry run this playbook to validate.
Ansible Dry Run – How
to run the playbook in check mode To run the ansible playbook in verification mode (dry run) you must start the playbook with the -C or -check option of the ansible-playbook command
So here is the command to run ansible-playbook in check mode (dry run) $ ansible-playbook
<
> book name –
check
As mentioned above, we’re going to run the playbook against the list of hosts that Apache already has installed on them. So let’s check it by doing a DRY RUN
where Ansible
Dry run would fail/Can’t use Ansible dry run
is to validate and see what changes are being made before they are actually applied
.
But when you have a conditional or outcome-based task execution in the playbook. The dry race would fail.
For example, consider the following manual in which you try to install the Weblogic application server based on the installation and availability of the Java JDK.
If you are running the following playbook in check mode, also known as dry execution. It would fail in the middle because it cannot satisfy the requirement to install the weblogic task since Java is not yet installed. (since you couldn’t install anything on dry execution)
– name : Install java become: yes become_user: weblogic tags: installjava, app shell: “tar -xzf server-jre*.tar.gz” args: chdir: “{{ oracle_home }}” environment: JAVA_HOME: “/opt/oracle/jdk1.8.0_191” PATH: “{{JAVA_HOME}}/bin” – name: Crate a Soft link to java become: yes become_user: root tags: linkjava shell: “ln -s {{oracle_home}}/jdk1.8.0_191/bin/java /usr/bin/java” ignore_errors: true – name : Validate Java become: yes become_user: weblogic tags: app,vjava command: “java -version” register: javaver – debug: msg: ” Java Version Found {{ javaver.stderr }}” – name: Install Weblogic become: yes become_user: weblogic tags: installweblogic,app register: wlsinstall shell: “java -jar {{ oracle_home}}/fmw*.jar -silent -invPtrLoc {{oracle_home}}/oraInst.loc -responseFile {{oracle_home}}/install.file -ignoreSysPrereqs -force -novalidation ORACLE_HOME={{oracle_home}} INSTALL_TYPE=’WebLogic Server'” args: chdir: “{{ oracle_home }}” when: “‘java version \”1.8.0_191\”‘ in javaver.stderr” failed_when: “‘failed’ in wlsinstall.stderr” changed_when: “‘already installed’ not in wlsinstall.stdout”
I hope you can understand how Dry run works and where it can be used and where it can’t.
Best regards, Sarav AK
