This post was originally published on the
XLAB Steampunk blog.
Ansible Lint is a tool that checks your Ansible Playbooks for errors and provides recommendations for improvements. Steampunk Spotter is a tool that checks your Ansible Playbooks for errors and provides recommendations for improvements. So, what’s the deal? Is Spotter just a fancy Ansible Lint? Do we really need two similar tools? Why should you use Spotter, if you already use Ansible Lint? What does Spotter have that Ansible Lint doesn’t already? Yeah, we’re used to these questions, and we understand. At first glance, both tools can look quite the same.
And they are, in a sense. It’s not about how they differ, but how they complement each other.
Spotter picks up where Ansible Lint leaves off. Think of Spotter as Lint on steroids and think of Lint and Spotter as your entourage on your path to spotless Ansible Playbooks.
Using both tools is a winning combination and guarantees you will achieve reliable automation you can trust.
Ansible Lint: Always start with linting
We all agree - Ansible Lint is awesome. It is without a doubt an essential tool for checking Ansible content. This command-line tool (CLI) helps you write and package higher quality Ansible content and helps you save time by eliminating the need to focus on formatting and style, making execution errors, and spending hours debugging.
Use Ansible Lint to:
- catch programming errors, bugs, stylistic errors, and suspicious constructs,
- validate Ansible syntax to catch misconfigurations,
- enforce best practices in Ansible content,
- write playbooks, roles, and task files that are easy to understand and produce consistent results.
But when it comes to errors, you can never be too sure, right? Even when you think you’ve caught them all, there’s always another hiding somewhere between the lines.
Let’s use this playbook as an example:
---
- name: Example playbook
hosts: localhost
collections:
- ansible.builtin
tasks:
- name: Create a new user
user:
username: joe
password: "{{ lookup('env', 'SENSU_USER_PASSWORD') }}"
- name: Run command
shell: touch /tmp/lock
- name: Read-only command
command: ls /tmp
changed_when: false
- name: Print a message
debug:
msg: Hello from Ansible
check_mode: true
These are issues that Ansible Lint finds:
Steampunk Spotter: Spot even the most elusive errors
Spotter doesn’t check for styling errors, we have Ansible Lint for that. Spotter goes beyond syntax checking. It forays into the Ansible content itself, i.e. modules, roles, collections, and is therefore able to surpass general rules by applying suggestions that are specific to a particular module, user environment setup, etc. It spots hard to catch issues, automatically fixes some of them and saves you time with convenience features such as generating a requirements.yml file or by pointing you to the module documentation of a specific version.
So, after you fixed all linter issues, run Spotter to identify all the remaining issues Ansible Lint didn’t check for.
Use Spotter to:
- structure your playbooks to be readable, enable collaboration and are easy to use,
- avoid common playbook anti-patterns,
- catch hidden obstacles causing hard-to-catch and time-consuming errors,
- identify module and collection name changes and redirects,
- identify missing collection requirements,
- identify deprecated modules and their parameters,
- check for fully qualified collection names,
- ensure you are using only certified and approved collections,
- make sure you are using correct module parameters, considering their relationships,
- quickly identify invalid configurations,
- upgrade your Ansible content to newer Ansible versions.
Also, Spotter isn’t just a CLI tool. Using Spotter app, you can scan public Git repositories, collaborate with your team, and keep up with your scan history, the frequency of failed playbook executions, most common mistakes and your progress over time.
These are the additional issues in our example playbook that Spotter finds:
Lint and Spotter in action
While Ansible Lint and Steampunk Spotter catch some of the same issues, they differ in what they do with them. For example, both tools report the same error: we need to use fully qualified collection names (FQCN). But while Ansible Lint only suggests which FQCN we should use, Spotter goes a step further and automatically fixes them for you. In addition, Spotter also catches all redirects and changed module names.
Power of unity: using Ansible Lint and Steampunk Spotter together
First, we always run ansible-lint to see what errors it finds before even running Ansible. Spotter will not check for things Ansible Lint already checks for, so linting is a must. Then use Spotter extensively to check for potential errors Ansible Lint didn’t check for and to take advantage of everything it has to offer in terms of fixing the issues it can for you automatically, generating a requirements file or by pointing you to the module documentation of a specific version.
Use Spotter to simplify and speed up Ansible upgrades
Ansible upgrades are where Spotter really shows all its power. Steampunk Spotter checks if your existing playbooks are compatible with a specific Ansible version and identifies all the issues you need to resolve when upgrading to a new Ansible version. While Ansible Lint can tell you that your playbook will fail when upgrading to newer Ansible version, Spotter lets you determine the target version of Ansible and retrieves the source version from your system, so you can always be sure which version you’re upgrading from and to, and adjust fixes accordingly.
Using Ansible Lint and Steampunk Spotter, the upgrade process can take minutes instead of hours. See how in this blog post or watch a detailed video walkthrough of an Ansible upgrade in this free webinar, in which we walk you through the entire process step by step.
