Improving Kubernetes Playbooks with Ansible-lint: Setting Up a Comfortable Development Environment 🚀

Hello everyone! Today, I’d like to talk about effectively dealing with the numerous lint errors you encounter when developing Ansible playbooks. This technique is particularly useful when creating complex playbooks, such as those for configuring Kubernetes environments! ✨

Why Take the Hard Road When There’s an Easy One? 🤔

Have you ever experienced this while writing Ansible playbooks?

❌ Use FQCN for builtin module actions (file). ansible-lint(fqcn[action-core])
❌ Trailing spaces ansible-lint(yaml[trailing-spaces])
❌ Use shell only when shell functionality is required. ansible-lint(command-instead-of-shell)

When these red error messages fill your screen, it’s really stressful and breaks your concentration. While it’s possible to fix each error one by one, you can also adjust your lint settings to create a more comfortable development environment!

What is Ansible-lint? 🧐

Ansible-lint is a tool that checks Ansible playbooks and verifies they’re written according to best practices. This tool:

• Checks YAML syntax
• Verifies Ansible module usage
• Detects potential security issues
• Ensures style guide compliance
• Recommends best practices

Installation Methods 📦

You can install it in various ways depending on your operating system:

macOS (using Homebrew):

brew install ansible-lint

Using pip (all operating systems):

pip install ansible-lint

Setting Up Ansible-lint in VSCode 💻

1. Install Required Extensions

• “Ansible” extension by Red Hat
• “YAML” extension by Red Hat

2. VSCode Settings

Add these items to your VSCode settings.json (open with Cmd+, or Ctrl+,):

{
  "editor.formatOnSave": true,
  "[yaml]": {
    "editor.defaultFormatter": "redhat.vscode-yaml",
    "editor.formatOnSave": true,
    "editor.tabSize": 2,
    "editor.insertSpaces": true
  },
  "yaml.format.enable": true,
  "yaml.validate": true,
  "ansible.validation.enabled": true,
  "ansible.ansible.path": "ansible"
}

Customizing Rules with a .ansible-lint File ⚙️

By creating a .ansible-lint file in your project’s root directory, you can customize lint rules. This file allows you to disable specific rules or exclude certain files from inspection.

Here’s an example .ansible-lint file used in the MoolMeow project:

# .ansible-lint file

# Disable specific rules
skip_list:
  # Module related rules
  - command-instead-of-module  # Warnings about using get_url instead of curl, etc.
  - command-instead-of-shell   # Warnings about using shell module instead of command
  - fqcn[action-core]          # Warnings about using fully qualified collection names
  
  # Shell script related rules
  - risky-shell-pipe           # Warnings about pipefail option when using shell pipes
  
  # General best practice rules
  - no-handler                 # Warnings recommending handlers
  - no-changed-when            # Warnings recommending changed_when
  
  # YAML format related rules
  - yaml[truthy]               # Warnings about True/False expression methods
  - yaml[trailing-spaces]      # Warnings about trailing spaces
  - yaml[line-length]          # Warnings about line length limits

# Files/directories to ignore during syntax parsing
exclude_paths:
  - .git/
  - .vscode/
  - .ansible-lint
  
# Rules to only show warnings for
warn_list:
  - experimental               # Only display warnings for experimental features

Common Lint Errors and Solutions 🛠️

1. FQCN Related Errors

Error message:

Use FQCN for builtin module actions (file). ansible-lint(fqcn[action-core])

Solution: Use Fully Qualified Collection Names (FQCN) or disable the rule.

# Non-FQCN method (generates warnings)
- file:
    path: /path/to/file
    state: touch

# FQCN method (recommended)
- ansible.builtin.file:
    path: /path/to/file
    state: touch

# Or disable the rule in .ansible-lint:
# skip_list:
#   - fqcn[action-core]

2. Recommendation to Use Command Module Instead of Shell

Error message:

Use shell only when shell functionality is required. ansible-lint(command-instead-of-shell)

Solution: Use the command module if shell features (pipes, redirections, etc.) aren’t needed, or disable the rule.

# Disable rule (.ansible-lint)
skip_list:
  - command-instead-of-shell

3. Recommendation for Pipefail Option When Using Pipelines

Error message:

Shells that use pipes should set the pipefail option. ansible-lint(risky-shell-pipe)

Solution: Set the pipefail option or disable the rule.

- name: Command with pipe
  shell: command1 | command2
  args:
    executable: /bin/bash
    pipefail: true

# Or disable the rule (.ansible-lint)
skip_list:
  - risky-shell-pipe

4. Recommendation to Separate Service Restart Actions as Handlers

Error message:

Tasks that run when changed should likely be handlers. ansible-lint(no-handler)

Solution: Use handlers or disable the rule.

# Disable rule (.ansible-lint)
skip_list:
  - no-handler

.ansible-lint Examples for Various Project Situations 📋

1. Strict Rule Application (Beginners/Official Projects)

skip_list: []  # Apply all rules
warn_list:
  - experimental  # Only warn for experimental features

2. Medium Level (Ongoing Development)

skip_list:
  - fqcn[action-core]
  - yaml[trailing-spaces]
  - yaml[line-length]

3. Flexible Settings (Quick Prototyping)

skip_list:
  - command-instead-of-module
  - command-instead-of-shell
  - fqcn[action-core]
  - risky-shell-pipe
  - no-handler
  - no-changed-when
  - yaml[truthy]
  - yaml[trailing-spaces]
  - yaml[line-length]

Conclusion: Choose the Comfortable Path 🌈

When writing complex Ansible playbooks, a gradual improvement approach can be more efficient than perfectly following all best practices from the start. Using a .ansible-lint file lets you ignore lint warnings that aren’t immediately important, allowing you to focus on developing core functionality.

After development has progressed to a certain point, you can gradually make your .ansible-lint file stricter to improve code quality. The key is a balanced approach! Don’t slow down development speed with overly strict rules, but also don’t foster bad habits with rules that are too relaxed. 😊

Discuss which rules are appropriate for your project with your team, and create an environment where everyone can work comfortably. Enjoy productive Ansible development without unnecessary stress! 🚀

#Ansible #Kubernetes #DevOps #AnsibleLint #MoolMeow