Skip to main content
In this lesson we’ll cover how to use Ansible conditionals to:
  • detect target operating systems and versions using facts,
  • apply environment-specific configuration using variables,
  • reuse common tasks while running environment-specific steps only where appropriate.
Imagine a mixed infrastructure of Ubuntu 18.04, CentOS 7, and Windows Server 2019 hosts. Your goal is to deploy a web application across all these hosts but run different actions per OS and per environment (development, staging, production).
A dark presentation slide titled "Introduction" showing three outlined panels, each containing a stack of server icons. Each panel is topped with an operating-system logo (Ubuntu, CentOS, Windows) and a gear icon at the bottom.

Facts: What they are and how to use them

Ansible facts are automatically gathered system variables (unless you disable gathering). Facts provide details like distribution, distribution version, os_family, architecture, and more — and are commonly used inside when conditionals to drive OS-specific behaviour. Helpful links:
By default Ansible gathers facts at the start of a play using the setup module. If you set gather_facts: false, you must call the setup module explicitly (or enable gathering) before relying on ansible_facts.
Quick reference table: common facts and their uses You can inspect facts for a host with an ad-hoc command:
  • ansible <host-pattern> -m setup Or by adding a debug task to a play:

Scenario 1 — Install Nginx only on Ubuntu 18.04

Use facts in a when conditional to target a specific distribution and major version. Example task (apt-based install only for Ubuntu 18.04):
Notes:
  • For targeting all Debian-family distributions you could use ansible_facts['os_family'] == 'Debian'.
  • Always validate the exact fact keys by inspecting gathered facts on your hosts.
Relevant docs:

Scenario 2 — Use a variable to apply environment-specific configuration

Define an environment variable (for example app_env) to drive templating so each environment receives its specific configuration. Example templating task that chooses the source template based on app_env:
Where to define app_env:
  • inventory (host_vars or group_vars)
  • dedicated variable files
  • at the play level:
Relevant docs:

Scenario 3 — Reuse common tasks, but start services only in production

Many tasks are common across all hosts (package installation, directories, permissions). Use a when conditional to run environment-only actions (for example starting services) on production hosts. A compact example play that brings the scenarios together:
Notes:
  • Replace the apt task with yum or win_chocolatey on non-Debian systems when needed.
  • Use notify + handlers to centralize service restarts after configuration changes.
Service module docs:

Best practices and tips

  • Keep environment and role variables out of inline tasks. Prefer inventory (host_vars / group_vars) or dedicated variable files to make playbooks reusable and easy to manage.
  • Use consistent variable names across repositories (e.g., app_env or environment) to avoid confusion.
  • Inspect facts frequently with the setup module or debug to determine which fact names and values are available on your target hosts.
  • Use multiple when conditions as lists for readability: when:
    • condition1
    • condition2
  • Prefer checking os_family for portability across similar distributions, and use distribution + distribution_major_version for precise control.

Summary

Ansible conditionals — combining gathered facts and variables — let you write readable, maintainable automation for mixed OS environments. Use facts to detect OS and versions, variables to parameterize environment-specific behavior, and when conditionals to reuse common tasks while restricting environment-specific changes to the appropriate hosts. Further reading:

Watch Video

Practice Lab