Ansible-Lint Rule Analysis and Best Practices

A Comprehensive Guide to Navigate Ansible-Lint Rule Categories and Best Practices

October 31, 2023

Access the Complete Video Course and Learn Quick Ansible by 200+ Practical Lessons

#ansible-lint #automation #ansible-playbooks #devops #best-practices #rule-categories #security #code-quality

Introduction

Ansible-Lint is a powerful tool that helps Ansible users identify and correct issues in their playbooks and roles. It not only improves code quality but also ensures best practices are followed, making your automation processes more reliable and predictable.

In this article, we will explore various Ansible-Lint rules and provide insights into best practices to address the common issues flagged by these rules. We’ll cover rules related to module arguments, playbook structure, variable naming, and much more. We can list all the rules in Ansible Linter using the command ansible-lint -L.

Rule Categories

Ansible-Lint rules are organized into various categories, each addressing different aspects of the Ansible playbook and role development. Let’s dive into some of the most commonly encountered rule categories and explore them in detail.

Args

Rule Name: args
Purpose: Validating module arguments. (syntax, experimental) The “args” category focuses on validating the arguments provided to Ansible modules. It checks for correct syntax and identifies experimental features. It’s essential to use the right arguments for each module to ensure your tasks perform as intended.

Idioms

Rule Name: avoid-implicit
Purpose: Avoid implicit behaviors (unpredictability) The “idioms” category helps you avoid implicit or unpredictable behaviors in your playbooks. Implicit actions can lead to unexpected results, making your automation less reliable.
Rule Name: command-instead-of-module
Purpose: Using command rather than module. (command-shell, idiom) This rule encourages using modules over direct shell commands, as modules provide better control, error handling, and idempotence.
Rule Name: command-instead-of-shell
Purpose: Use shell only when shell functionality is required. (autofix, command-shell, idiom) Use the “command” module when shell functionality is necessary. This ensures better compatibility and maintainability.
Rule Name: partial-become
Purpose: become_user should have a corresponding become at the play or task level. (autofix, unpredictability) Ensure that when you specify “become_user,” there should also be a corresponding “become” at the play or task level for predictability and consistency.

Deprecated

Rule Name: deprecated-bare-vars
Purpose: Using bare variables is deprecated. (deprecations) The “deprecated” category focuses on identifying and discouraging the use of deprecated features and syntax. It’s essential to stay up to date with Ansible’s best practices.
Rule Name: deprecated-local-action
Purpose: Do not use ‘local_action,’ use ‘delegate_to: localhost’ (autofix, deprecations) Avoid using “local_action” and use “delegate_to: localhost” for better clarity and consistency in your playbooks.
Rule Name: deprecated-module
Purpose: Deprecated module. (deprecations) Identifies the use of deprecated modules in your playbooks. Deprecated modules can pose security risks, so it’s crucial to replace them with supported alternatives.

Syntax and Formatting

Rule Name: no-tabs
Purpose: Most files should not contain tabs. (formatting) Ensure that your Ansible playbooks and roles adhere to a consistent formatting style by avoiding the use of tabs.

-Rule Name: playbook-extension

Purpose: Use “.yml” or “.yaml” playbook extension. (formatting) Use a standard “.yml” or “.yaml” extension for your playbook files to maintain consistency and readability.

Security

Rule Name: no-log-password
Purpose: Password should not be logged. (autofix, opt-in, security, experimental) This rule highlights potential security risks when logging passwords in your playbooks. It’s essential to handle sensitive data securely.
Rule Name: no-prompting
Purpose: Disallow prompting. (opt-in) Discourages the use of prompting in playbooks. Prompting can disrupt automation processes, so it’s best to avoid it in your scripts.

Best Practices

Rule Name: no-changed-when
Purpose: Commands should not change things if nothing needs doing. (command-shell, idempotency) Ensures that tasks only make changes when necessary, improving idempotence and predictability.
Rule Name: no-free-form
Purpose: Rule for detecting discouraged free-form syntax for action modules. (autofix, syntax, risk) Discourages the use of free-form syntax within action modules in favor of structured, predictable syntax.
Rule Name: no-handler
Purpose: Tasks that run when changed should likely be handlers. (idiom) Promotes the use of handlers for tasks that run only when changes occur, improving playbook organization.

The Best Resources For Ansible

Certifications

The Linux Foundation Linux Performance Tuning - Build a broad toolkit to optimize Linux performance from the kernel up

Coursera Pro - Unlimited access to 7,000+ world-class courses, hands-on projects, and job-ready certificate programs—all included in your subscription

Video Course

Udemy: Learn Ansible Automation in 250+examples & practical lessons: Learn Ansible with some real-life examples of how to use the most common modules and Ansible Playbook

Printed Book

eBooks

Metadata

Rule Name: role-name
Purpose: Role name {0} does not match ^*$ pattern. (deprecations, metadata) Enforces naming conventions for roles, ensuring role names adhere to the required pattern.

Unpredictability

Rule Name: ignore-errors
Purpose: Use failed_when and specify error conditions instead of using ignore_errors. (unpredictability) Suggests using “failed_when” to specify error conditions rather than using “ignore_errors” for better predictability in your playbooks.
Rule Name: no-same-owner
Purpose: Do not preserve the owner and group when transferring files across hosts. (opt-in) Advises against preserving the owner and group when transferring files between hosts, reducing unpredictability.

Internal

Rule Name: internal-error
Purpose: Unexpected internal error (core) This category deals with unexpected internal errors in Ansible-Lint, which are generally core-related and not something you can fix directly.

Experimental

Rule Name: syntax-check
Purpose: Ansible syntax check failed. (core, unskippable) Identifies issues related to Ansible syntax checks and is generally considered experimental.
Rule Name: warning
Purpose: Other warnings detected during run. (core, experimental) This rule covers various other warnings detected during Ansible-Lint runs and is considered experimental.

Best Practices for Ansible-Lint Rules

Stay Updated: Regularly update Ansible-Lint to benefit from the latest rule improvements and bug fixes.
Integrate into CI/CD: Incorporate Ansible-Lint into your CI/CD pipelines to catch issues early in the development process.
Use Autofix: Take advantage of autofixable rules to automatically correct issues in your playbooks.
Check for Deprecated Features: Regularly check for deprecated features and modules in your playbooks and update them to use supported alternatives.
Follow Naming Conventions: Adhere to role naming conventions and playbook file extensions to ensure consistency and readability.
Prioritize Security: Pay close attention to security-related rules, such as “no-log-password,” to safeguard sensitive data.
Adopt Best Practices: Embrace best practices for playbook structure and module

Conclusion

Ansible-Lint, a powerful tool for Ansible users, enforces best practices and identifies potential issues in playbooks and roles. It covers a wide array of rule categories, from syntax and formatting to security, predictability, and deprecated features. Following its recommendations, such as avoiding deprecated modules, adhering to role naming conventions, and prioritizing security rules, ensures cleaner, more reliable automation code. By integrating Ansible-Lint into your CI/CD pipeline and staying updated with the latest rule improvements, you can maintain a high quality, consistency, and security standard in your Ansible automation, ultimately leading to more efficient and dependable processes.

Subscribe to the YouTube channel, Medium, and Website, X (formerly Twitter) to not miss the next episode of the Ansible Pilot.