Does Ansible Use Python 2 Or 3?

Ansible now requires Python 3 for its control node, with support for Python 2 officially removed in ansible-core version 2.17. For the systems it manages (managed nodes), it can use either Python 2 or Python 3, though Python 3 is strongly recommended and has become the standard.

The transition from Python 2 to 3 has been a long and complex journey for the Ansible community, driven by the end-of-life for Python 2 in 2020. This shift affects both how Ansible runs on the control node and how it executes modules on the managed nodes.

The evolving Python support for Ansible

The control node: From dual-support to Python 3 exclusivity

The "control node" is the machine where you run the ansible or ansible-playbook command.

• Dual-version support (pre-2.12): For many years, Ansible was engineered to run on both Python 2.7 and Python 3.5 or higher, allowing for maximum compatibility. This was a critical design choice, as it allowed Ansible to manage a wide variety of machines with different default Python versions.
• The shift to Python 3 (2.12–2.16): With the official end-of-life for Python 2.7 in 2020, the Ansible project began phasing out Python 2 support. Starting with ansible-core 2.12, Python 3.8 or newer became a requirement for the control node. Deprecation warnings were introduced to alert users.
• Python 3 exclusively (2.17+): In ansible-core version 2.17, all Python 2.7 support was completely removed from the controller. This aligns Ansible with modern Python development standards and allows the project to take advantage of newer language features.

Managed nodes: Flexibility and interpreter discovery

"Managed nodes" are the target systems—like servers or network devices—that Ansible automates. Ansible's modules are copied and executed on these nodes, so they also require a Python interpreter.

• Dynamic interpreter discovery: By default, Ansible automatically attempts to find a compatible Python interpreter on the managed node. This discovery process checks common paths (/usr/bin/python, /usr/bin/python3, etc.) to find a supported Python version.
• The role of ansible_python_interpreter: In scenarios where the interpreter is in a non-standard location or needs to be explicitly specified, users can set the ansible_python_interpreter variable. This variable can be configured at various levels:
  • Globally: In the ansible.cfg file.
  • For a group of hosts: In the inventory file.
  • For an individual host: In the inventory file.
• Python 2 vs. Python 3 on managed nodes: While older Linux distributions like RHEL 7 shipped with Python 2.7 by default, newer versions like RHEL 8 and 9 use Python 3. Ansible can continue to manage these older systems, but for new deployments, it is best practice to ensure Python 3 is installed. The ansible_python_interpreter variable can be used to explicitly target the desired version.

The practical impact of the transition

For the modern user (latest Ansible versions)

If you are running the latest versions of Ansible and managing up-to-date operating systems, the Python version is almost a non-issue.

• Control Node: You will be running a modern version of Python 3.x (e.g., 3.8+).
• Managed Nodes: Newer OS versions automatically provide a Python 3 interpreter, and Ansible will discover and use it without manual intervention.

For legacy systems (RHEL 7, CentOS 6, etc.)

Managing older operating systems introduces complexity that requires more configuration.

• RHEL 7 example: RHEL 7 ships with Python 2.7 as its system Python. While it can be managed by a modern Python 3-based Ansible control node, you might encounter issues with some modules that have Python 3-specific dependencies. You can solve this by explicitly setting the Python interpreter to /usr/bin/python for RHEL 7 hosts in your inventory file.
• Yum and legacy Python: A classic problem is that the yum package manager on older Red Hat systems relies on Python 2.7. The yum Ansible module would need to be executed by Python 2 to function correctly on these targets.

Key considerations and best practices

• Use Python 3 whenever possible: Python 3 is the future of the language. For all new projects and modern systems, aim to use Python 3 on both the control node and the managed nodes.
• Explicitly define the interpreter for legacy hosts: If you are managing a mixed environment of old and new operating systems, use the ansible_python_interpreter inventory variable. This prevents surprises and ensures you are using the correct interpreter for each host or group.
• Understand interpreter discovery: Be aware that Ansible automatically tries to find a suitable interpreter. If you see unexpected behavior, check the discovered interpreter by running a debug task or inspecting Ansible's verbose output.
• Use virtual environments: When installing Ansible with pip, always do so within a dedicated Python virtual environment. This isolates Ansible and its dependencies from your system's Python installation, preventing conflicts and allowing for easier management.

Summary: The final verdict

The question "Does Ansible use Python 2 or 3?" no longer has a dual-answer. The definitive answer is that Ansible requires Python 3 on the control node. While it retains the flexibility to manage systems running older versions of Python 2 on the managed nodes, this is a legacy feature, and Python 3 is the standard for both modern control and managed environments.