Ansible has changed significantly over the years.

In the early days, most users installed a single Ansible package, wrote a playbook, and executed it using:

ansible-playbook site.yml

The automation engine, modules, plugins, and command-line tools were installed directly on the control node. This was simple, but it eventually created dependency-management and reproducibility problems.

Modern Ansible environments may include:

• ansible-core
• The Ansible community package
• Ansible Collections
• ansible-navigator
• Automation Execution Environments
• ansible-builder
• Ansible development tools
• The Red Hat Ansible extension for VS Code
• VS Code Dev Containers
• Red Hat Ansible Automation Platform

These are sometimes described as different “versions” or “variants” of Ansible. Technically, they are different packages, tools, runtimes, and development workflows within the broader Ansible ecosystem.

This article explains what each component does, how they relate to one another, and which approach you should use in different situations.

1. Traditional Ansible Installation

The traditional Ansible workflow installs Ansible directly on a Linux control node.

For example:

sudo dnf install ansible

Or:

python3 -m pip install ansible

You then create an inventory:

[webservers]
192.168.1.10
192.168.1.11

Create a playbook:

---
- name: Configure web servers
  hosts: webservers
  become: true

  tasks:
    - name: Install Nginx
      ansible.builtin.package:
        name: nginx
        state: present

    - name: Start Nginx
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: true

And run it:

ansible-playbook -i inventory.ini webserver.yml

Features

• Simple installation
• Native ansible, ansible-playbook, and ansible-galaxy commands
• Direct access to local files and SSH keys
• Easy to understand
• Suitable for learning and small automation projects
• No container engine required

Limitations

The main problem is that the execution environment depends on the control node.

A playbook may depend on:

• A specific Python version
• Python libraries such as boto3, jmespath, or netaddr
• Particular Ansible Collections
• System packages
• SSH clients
• Cloud command-line tools
• Vendor-specific SDKs
• A specific version of ansible-core

This creates the classic problem:

The playbook works on one administrator’s laptop but fails on another system.

It can also cause conflicts when multiple projects require different versions of Ansible or Python libraries.

2. Ansible Core

ansible-core is the minimal automation engine at the center of the Ansible ecosystem.

It contains:

• The Ansible language and runtime
• The playbook execution engine
• Inventory processing
• Variables and facts
• Connection plugins
• Core command-line tools
• Modules and plugins from the ansible.builtin collection

The Ansible Core documentation explicitly separates ansible-core from the larger Ansible community package. ansible-core contains the runtime and built-in plugins, while the community package adds a curated set of Collections.

Installation

python3 -m pip install ansible-core

Verify the installation:

ansible --version

Commands Provided by Ansible Core

Important commands include:

ansible
ansible-playbook
ansible-config
ansible-doc
ansible-galaxy
ansible-inventory
ansible-vault
ansible-pull
ansible-console

What Is Included?

ansible-core includes the ansible.builtin collection.

Examples include:

ansible.builtin.copy
ansible.builtin.file
ansible.builtin.command
ansible.builtin.shell
ansible.builtin.package
ansible.builtin.service
ansible.builtin.user
ansible.builtin.template

The modules and plugins inside ansible.builtin are shipped as part of ansible-core.

However, many cloud, network, storage, database, and vendor-specific modules are not included.

For example, a minimal ansible-core installation may not automatically include Collections such as:

amazon.aws
community.aws
community.general
kubernetes.core
cisco.ios
ansible.posix
community.postgresql

You install the required Collections separately:

ansible-galaxy collection install amazon.aws
ansible-galaxy collection install kubernetes.core

A better approach is to define them in requirements.yml:

---
collections:
  - name: ansible.posix
    version: ">=2.0.0"

  - name: community.general
    version: ">=10.0.0"

  - name: kubernetes.core
    version: ">=5.0.0"

Then install them using:

ansible-galaxy collection install -r requirements.yml

Advantages of Ansible Core

• Small installation footprint
• Greater control over dependencies
• Suitable for custom automation runtimes
• Good for CI/CD pipelines
• Useful when only a few Collections are required
• Makes dependency declarations more explicit
• Appropriate as a base for execution environment images

Limitations

• Many useful Collections must be installed separately
• Python and system dependencies still exist on the control node
• Different developers may install different Collection versions
• It does not solve environment reproducibility by itself

Best Use Cases

Use ansible-core when:

• You want a minimal Ansible installation
• You carefully manage Collections through requirements.yml
• You are building a CI pipeline
• You are building a custom execution environment
• Your automation mostly uses ansible.builtin
• You do not need the larger batteries-included Ansible package

3. The Ansible Community Package

The package installed using the following command is different from ansible-core:

python3 -m pip install ansible

This installs the Ansible community package.

The community package includes:

1. ansible-core
2. A curated set of community-maintained Ansible Collections

The official Ansible documentation describes it as a larger package containing ansible-core and selected Collections, providing an experience similar to the batteries-included Ansible releases that existed before the ecosystem was reorganized around Collections.

Why Was This Split Introduced?

Historically, thousands of modules were maintained inside the main Ansible repository.

As the project grew, this became difficult to maintain. Modules and plugins were therefore reorganized into independently maintained Collections.

For example:

ansible.builtin
ansible.posix
community.general
amazon.aws
azure.azcollection
google.cloud
kubernetes.core
cisco.ios
junipernetworks.junos

This allows cloud providers, networking vendors, platform teams, and community maintainers to release content independently from the core Ansible engine.

Features

• Includes ansible-core
• Includes many commonly used Collections
• Provides thousands of modules and plugins
• Easier for beginners
• Requires less initial dependency planning
• Supports general Linux, cloud, networking, storage, and application automation

For example, community.general contains many modules and plugins that are part of the broader Ansible package but not included in ansible-core.

Advantages

• Convenient installation
• Large module ecosystem available immediately
• Good for training and experimentation
• Easier for general-purpose automation
• Less time spent installing individual Collections

Limitations

• Larger installation
• Includes Collections you may not use
• Dependency versions still depend on the local Python environment
• Different machines can still have different package versions
• Not as reproducible as container-based execution environments

Best Use Cases

Use the Ansible community package when:

• You are learning Ansible
• You are conducting classroom training
• You want a broad module selection
• You manage multiple technologies
• You want to start quickly
• Strict runtime reproducibility is not yet a requirement

4. Python Virtual Environments with Ansible

Before execution environments became common, Python virtual environments were widely used to isolate Ansible projects.

Create a virtual environment:

python3 -m venv .venv

Activate it:

source .venv/bin/activate

Install Ansible:

pip install ansible-core

Install Python dependencies:

pip install boto3 botocore kubernetes

Install Collections:

ansible-galaxy collection install -r requirements.yml

Features

• Isolates Python packages
• Supports different Ansible versions per project
• Lightweight compared with containers
• Works without Docker or Podman
• Easy to integrate with local development

Limitations

A Python virtual environment isolates Python packages, but it does not completely isolate:

• Operating-system libraries
• SSH clients
• Kerberos libraries
• Git versions
• System utilities
• Compiler dependencies
• Container tools
• Cloud CLIs
• Network utilities

It also remains dependent on the host operating system.

For example, the same virtual environment may behave differently on:

• Ubuntu
• RHEL
• Fedora
• macOS
• WSL

Best Use Cases

Use a Python virtual environment when:

• You need lightweight dependency isolation
• Containers are unavailable
• You are working on a personal project
• The project has simple Python dependencies
• The host operating systems are standardized

Virtual environments are still useful, but they do not provide the same level of reproducibility as containerized execution environments.

5. Ansible Collections

Collections are the modern distribution format for Ansible automation content.

A Collection can include:

• Modules
• Roles
• Plugins
• Playbooks
• Documentation
• Tests

A Collection uses a namespace and collection name:

namespace.collection

Examples:

ansible.builtin
community.general
amazon.aws
kubernetes.core
cisco.ios
redhat.rhel_system_roles

Modules should normally be referenced using their Fully Qualified Collection Name, or FQCN:

- name: Create Kubernetes namespace
  kubernetes.core.k8s:
    state: present
    definition:
      apiVersion: v1
      kind: Namespace
      metadata:
        name: production

Instead of relying on a short module name:

- name: Create Kubernetes namespace
  k8s:
    state: present

Advantages

• Independent release cycles
• Clear content ownership
• Better dependency management
• Easier vendor integration
• Reduced naming conflicts
• Explicit module references
• Reusable roles and plugins

Important Point

Collections are not an alternative execution engine.

They are content packages used by ansible-core, the Ansible community package, ansible-navigator, and automation execution environments.

6. Ansible Navigator

ansible-navigator is a command-line tool and text-based user interface for developing, running, inspecting, and troubleshooting Ansible automation.

It can execute playbooks:

• Directly on the local machine
• Inside an Automation Execution Environment

The Ansible documentation describes Navigator as a CLI and text-based interface that provides access to native Ansible utilities and can run automation content inside execution environment containers.

Traditional Command

ansible-playbook site.yml

Navigator Equivalent

ansible-navigator run site.yml

To display familiar console output:

ansible-navigator run site.yml --mode stdout

Or:

ansible-navigator run site.yml -m stdout

Red Hat documentation specifically identifies stdout mode as the way to obtain output similar to traditional ansible-playbook commands.

Major Features

1. Run Playbooks

ansible-navigator run playbook.yml

2. Inspect Inventory

ansible-navigator inventory -i inventory.ini

3. Browse Module Documentation

ansible-navigator doc ansible.builtin.copy

4. Inspect Execution Environment Images

ansible-navigator images

5. View Collections and Python Packages

Navigator can inspect an execution environment and show:

• Installed Collections
• Collection versions
• Python packages
• Python package versions
• Ansible version
• Operating-system details

Red Hat documents this inspection capability as a way to review the packages and Collections inside execution environments.

6. Generate Execution Artifacts

Navigator can produce artifact files containing information about an automation run.

These artifacts can help with:

• Troubleshooting
• Reviewing failed tasks
• Inspecting event data
• Comparing executions
• Auditing playbook runs

7. Run Inside Containers

The most important feature of Navigator is its integration with execution environments.

ansible-navigator run site.yml \
  --execution-environment true \
  --execution-environment-image my-ansible-ee:1.0

Configuration File

Navigator can be configured using ansible-navigator.yml:

---
ansible-navigator:
  execution-environment:
    enabled: true
    image: localhost/custom-ansible-ee:1.0
    pull:
      policy: missing

  mode: stdout

  playbook-artifact:
    enable: true

Advantages

• Consistent interface for running automation
• Supports local and containerized execution
• Better inspection and troubleshooting
• Interactive TUI
• Execution artifacts
• Closer alignment with Ansible Automation Platform
• Easier validation against production execution environments

Limitations

• More complex than ansible-playbook
• Requires users to understand container mounts
• SSH keys and local configuration may need explicit mounting
• Container networking can introduce additional troubleshooting
• Interactive mode may feel unfamiliar to beginners

Best Use Cases

Use ansible-navigator when:

• You use execution environments
• You develop content for Ansible Automation Platform
• Your team needs reproducible execution
• You want improved inspection and troubleshooting
• You want local execution to resemble production execution

7. Automation Execution Environments

An Automation Execution Environment is a container image used as an Ansible control node.

It contains everything required to run automation, including:

• ansible-core
• Ansible Runner
• Ansible Collections
• Python libraries
• System packages
• Supporting command-line utilities
• Configuration required by the automation

Red Hat describes execution environments as container images on which Ansible Automation Platform automation runs. They provide a standard way to build, distribute, and communicate automation dependencies.

Why Execution Environments Were Introduced

Consider an AWS automation project that requires:

ansible-core 2.x
amazon.aws
community.aws
boto3
botocore
AWS CLI
jq
openssh-clients

Another Kubernetes project may require:

ansible-core 2.x
kubernetes.core
kubernetes Python library
Helm
kubectl
OpenShift CLI

Installing everything directly on one control node can lead to conflicts.

Execution environments allow each project to have its own container image:

aws-automation-ee:1.0
kubernetes-automation-ee:1.0
network-automation-ee:1.0
database-automation-ee:1.0

Each image contains the exact dependencies needed by that automation project.

Example Execution

ansible-navigator run site.yml \
  --execution-environment-image quay.io/example/ansible-ee:1.0

Benefits

Reproducibility

The same image can run:

• On a developer laptop
• In a CI/CD pipeline
• On an automation execution node
• In Ansible Automation Platform

Dependency Isolation

Different projects can use different:

• Ansible versions
• Collection versions
• Python packages
• System libraries
• Command-line utilities

Portability

The environment is distributed through a container registry.

Better Production Consistency

The development runtime can closely match the production runtime.

Red Hat states that ansible-navigator runs playbooks inside an execution environment in the same manner that Ansible Automation Platform runs automation jobs.

Security and Governance

Organizations can:

• Approve specific base images
• Scan images for vulnerabilities
• Sign images
• Control Collection versions
• Rebuild images regularly
• Restrict images used in production

Limitations

• Requires Docker or Podman
• Container registry access may be required
• Volume mounting must be understood
• Image maintenance becomes necessary
• Large images can consume storage
• Network and credential access must be configured carefully

Best Use Cases

Use execution environments when:

• Ansible runs in production
• Multiple teams share automation
• You use Ansible Automation Platform
• CI/CD must use the same runtime as developers
• Automation has complex dependencies
• Dependency conflicts are common
• Runtime governance and security are important

8. Ansible Builder

ansible-builder creates custom Automation Execution Environment images.

It reads dependency definition files and generates the container build context.

Example Project Structure

ansible-project/
├── execution-environment.yml
├── requirements.yml
├── requirements.txt
└── bindep.txt

execution-environment.yml

---
version: 3

images:
  base_image:
    name: quay.io/ansible/ansible-runner:latest

dependencies:
  galaxy: requirements.yml
  python: requirements.txt
  system: bindep.txt

additional_build_steps:
  append_final:
    - RUN ansible --version

requirements.yml

---
collections:
  - name: ansible.posix

  - name: community.general

  - name: kubernetes.core

requirements.txt

kubernetes
jmespath
netaddr

bindep.txt

openssh-clients [platform:rpm]
sshpass [platform:rpm]
git [platform:rpm]

Build the Image

ansible-builder build \
  --tag custom-ansible-ee:1.0

You can then run it using Navigator:

ansible-navigator run site.yml \
  --execution-environment-image custom-ansible-ee:1.0

Features

• Declarative dependency definition
• Collection dependency installation
• Python package installation
• Operating-system package installation
• Repeatable container builds
• Integration with Docker and Podman
• Suitable for CI pipelines
• Creates execution environments compatible with Navigator and Ansible Automation Platform

Best Use Cases

Use Ansible Builder when:

• The default execution environment lacks required dependencies
• Your playbooks require custom Python libraries
• You need cloud or vendor SDKs
• Your automation calls tools such as kubectl, helm, or cloud CLIs
• You need a controlled and versioned automation runtime

9. Ansible Development Tools

Modern Ansible development involves more than running playbooks.

Common development tools include:

ansible-core
ansible-navigator
ansible-builder
ansible-lint
ansible-creator
molecule
pytest
yamllint

Ansible Lint

ansible-lint checks playbooks and roles for:

• Syntax problems
• Deprecated practices
• Naming issues
• Risky shell commands
• Non-idempotent patterns
• Missing FQCNs
• Style and maintainability problems

Example:

ansible-lint playbook.yml

Molecule

Molecule helps test Ansible roles by:

1. Creating a test instance
2. Applying the role
3. Running verification
4. Testing idempotence
5. Destroying the test environment

Ansible Creator

Ansible Creator helps scaffold:

• Collections
• Roles
• Plugins
• Ansible projects

These tools support a software-development approach to automation, including linting, testing, code review, and CI validation.

10. The Red Hat Ansible Extension for VS Code

The Red Hat Ansible extension turns Visual Studio Code into an Ansible-aware development environment.

It provides features such as:

• YAML syntax awareness
• Autocompletion
• Module suggestions
• Hover documentation
• Diagnostics
• Go-to-definition support
• Integration with ansible-lint
• Playbook execution
• Integration with ansible-playbook
• Integration with ansible-navigator
• Support for local and execution-environment-based development

The Ansible documentation lists capabilities such as autocompletion, syntax highlighting, hover information, diagnostics, navigation, and commands for running ansible-playbook or ansible-navigator.

Important Distinction

The VS Code extension does not replace:

• ansible-core
• ansible-navigator
• Execution environments

It provides an editor interface around these tools.

The actual Ansible binaries must still exist either:

• On the local machine
• Inside a Python virtual environment
• Inside a VS Code Dev Container
• Inside an execution environment

11. VS Code Dev Containers for Ansible

A VS Code Dev Container is a containerized development workstation.

The VS Code interface runs on your desktop, while the project’s tools, extensions, shells, and language services run inside a container.

A .devcontainer/devcontainer.json file defines the environment.

Microsoft describes Dev Containers as full-featured development environments in which a project folder is opened inside or mounted into a container with a defined tool and runtime stack. VS Code extensions can also execute inside the container and access its tools and filesystem.

Example Project Structure

ansible-project/
├── .devcontainer/
│   ├── devcontainer.json
│   └── Containerfile
├── inventory/
├── playbooks/
├── roles/
├── requirements.yml
├── ansible.cfg
└── ansible-navigator.yml

Example devcontainer.json

{
  "name": "Ansible Development Environment",
  "build": {
    "dockerfile": "Containerfile"
  },
  "workspaceFolder": "/workspace",
  "workspaceMount": "source=${localWorkspaceFolder},target=/workspace,type=bind",
  "runArgs": [
    "--network=host"
  ],
  "mounts": [
    "source=${localEnv:HOME}/.ssh,target=/home/vscode/.ssh,type=bind,readonly",
    "source=${localEnv:HOME}/.kube,target=/home/vscode/.kube,type=bind,readonly"
  ],
  "customizations": {
    "vscode": {
      "extensions": [
        "redhat.ansible",
        "redhat.vscode-yaml",
        "ms-azuretools.vscode-containers"
      ]
    }
  },
  "postCreateCommand": "ansible-galaxy collection install -r requirements.yml"
}

Example Containerfile

FROM registry.access.redhat.com/ubi9/python-311

USER root

RUN dnf install -y \
      git \
      openssh-clients \
      sshpass \
      podman \
      findutils \
    && dnf clean all

RUN pip install --no-cache-dir \
      ansible-core \
      ansible-navigator \
      ansible-builder \
      ansible-lint \
      molecule

RUN useradd -m -s /bin/bash vscode

USER vscode

WORKDIR /workspace

What the Dev Container Provides

The Dev Container acts as the developer’s workstation and may contain:

• Git
• Python
• ansible-core
• ansible-navigator
• ansible-builder
• ansible-lint
• Molecule
• Podman or Docker CLI
• kubectl
• Helm
• Cloud CLIs
• VS Code extensions
• YAML language services

Advantages

Standardized Developer Workstations

Every developer gets the same:

• Ansible version
• Python version
• Collection versions
• Linting tools
• Editor extensions
• Supporting CLIs

Faster Onboarding

A developer can clone the repository and select:

Dev Containers: Reopen in Container

The project environment is then created automatically.

Reduced Host Pollution

Developers do not need to install every automation tool directly on their laptops.

Version-Controlled Development Environment

The Dev Container configuration lives inside the Git repository.

Changes to development tooling can therefore be reviewed through pull requests.

Cross-Platform Development

A consistent Linux environment can be provided to users working from:

• Linux
• Windows
• macOS

Limitations

• Requires a container engine
• Mounting SSH keys and configuration must be handled securely
• File permissions can be complicated
• Host networking behaves differently across operating systems
• Nested container access may require additional configuration
• Dev Container image size can become large

12. Dev Container vs Execution Environment

A Dev Container and an Ansible Execution Environment are related, but they solve different problems.

Dev Container

A Dev Container is the complete development workstation.

It may contain:

• Git
• VS Code server
• Editor extensions
• Ansible development tools
• Linting tools
• Testing tools
• Container clients
• Shell customization
• Documentation utilities

Execution Environment

An Execution Environment is the runtime used to execute Ansible automation.

It should contain:

• ansible-core
• Ansible Runner
• Required Collections
• Python dependencies
• Required system packages

Recommended Architecture

Developer Laptop
       |
       v
VS Code
       |
       v
Dev Container
  - Git
  - ansible-lint
  - ansible-builder
  - ansible-navigator
  - Testing tools
       |
       v
Execution Environment Container
  - ansible-core
  - Collections
  - Python dependencies
  - Runtime system packages
       |
       v
Managed Nodes

In this architecture:

• The Dev Container standardizes development.
• Navigator launches the automation.
• The Execution Environment standardizes runtime execution.
• Ansible connects from the execution environment to managed systems.

Can the Dev Container Also Be the Execution Environment?

Technically, it is sometimes possible to execute playbooks directly from the Dev Container.

However, this is not always the best design.

A development container may include unnecessary tools such as:

• Git clients
• Debuggers
• Editors
• Test frameworks
• Build tools
• Shell customizations

A production execution environment should normally be smaller and contain only runtime dependencies.

For small teams, using the Dev Container directly may be acceptable. For larger or regulated environments, separate development and runtime images are preferable.

13. Ansible Navigator Inside a VS Code Dev Container

The most modern local development workflow combines:

1. VS Code
2. Dev Containers
3. The Red Hat Ansible extension
4. ansible-navigator
5. Automation Execution Environments

The workflow looks like this:

VS Code Desktop
      |
      v
Ansible Dev Container
      |
      | ansible-navigator run
      v
Automation Execution Environment
      |
      | SSH / API
      v
Managed Infrastructure

Red Hat documentation includes this type of workflow and notes that registry authentication may need to be performed from inside the Dev Container when development tools need to pull execution environment images.

Example Command

From the VS Code terminal inside the Dev Container:

ansible-navigator run playbooks/site.yml \
  -i inventory/hosts.yml \
  --execution-environment-image \
  registry.example.com/automation/linux-ee:1.0 \
  --mode stdout

Why This Workflow Is Powerful

The developer environment becomes reproducible:

.devcontainer/devcontainer.json

The automation runtime also becomes reproducible:

execution-environment.yml

The project dependencies become explicit:

requirements.yml
requirements.txt
bindep.txt

This provides multiple levels of consistency:

• Editor consistency
• Development-tool consistency
• Ansible runtime consistency
• Collection consistency
• Python dependency consistency
• CI/CD consistency
• Production consistency

14. Red Hat Ansible Automation Platform

Red Hat Ansible Automation Platform, commonly called AAP, is the enterprise automation platform built around Ansible.

It includes capabilities such as:

• Automation Controller
• Automation Execution
• Execution Environments
• Private Automation Hub
• Event-Driven Ansible
• Role-based access control
• Credentials management
• Scheduling
• Workflow automation
• Inventory management
• Logging and auditing
• Enterprise support
• High-availability options

AAP should not be viewed as another form of ansible-core.

Instead, it is a platform for centrally managing, securing, executing, and governing Ansible automation.

Typical Workflow

Developer
   |
   v
VS Code Dev Container
   |
   v
Git Repository
   |
   v
Automation Controller
   |
   v
Execution Environment
   |
   v
Managed Infrastructure

Best Use Cases

Use Ansible Automation Platform when:

• Multiple teams execute automation
• Centralized credentials are required
• Role-based access control is important
• Automation must be scheduled
• Approval workflows are needed
• Audit logs are required
• Enterprise support is required
• Automation must run across multiple execution nodes
• A private Collection and execution-environment registry is needed

15. Comparison of Ansible Variants and Components

16. Which Ansible Variant Should You Use?

17. Recommended Approach for Beginners

For someone learning Ansible for the first time, start with:

python3 -m pip install ansible

Use:

ansible
ansible-playbook
ansible-galaxy
ansible-vault

This teaches the core concepts without introducing container complexity.

Focus on:

• Inventory
• Ad hoc commands
• Playbooks
• Variables
• Facts
• Handlers
• Templates
• Roles
• Vault
• Collections

After understanding these concepts, move to:

ansible-core
requirements.yml
ansible-lint
ansible-navigator
execution environments
ansible-builder

Do not begin with all the modern tooling at once unless the training objective specifically covers Ansible Automation Platform.

18. Recommended Approach for Individual Developers

For an individual developer managing a small number of systems:

Python virtual environment
        +
ansible-core
        +
requirements.yml
        +
ansible-lint

Example:

python3 -m venv .venv
source .venv/bin/activate

pip install ansible-core ansible-lint

ansible-galaxy collection install -r requirements.yml

This is usually enough when:

• Only one person develops the automation
• The operating system is standardized
• Dependencies are not complicated
• CI/CD is limited
• Ansible Automation Platform is not used

19. Recommended Approach for Teams

For a team of automation developers:

VS Code
   +
Dev Container
   +
Ansible extension
   +
ansible-lint
   +
ansible-navigator
   +
custom execution environment

This solves two different consistency problems.

Development Consistency

The Dev Container standardizes:

• Editor extensions
• Git
• Python
• Navigator
• Builder
• Linting
• Testing tools

Runtime Consistency

The execution environment standardizes:

• ansible-core
• Collections
• Python libraries
• Runtime system packages

This is the most practical modern Ansible development model for a team.

20. Recommended Approach for Enterprise Automation

For enterprise production environments:

VS Code Dev Container
        |
        v
Git Repository
        |
        v
CI Validation
  - ansible-lint
  - syntax checks
  - Molecule tests
        |
        v
Approved Execution Environment
        |
        v
Ansible Automation Platform
        |
        v
Production Infrastructure

Recommended controls include:

• Pin all Collection versions
• Pin Python package versions
• Version execution environment images
• Scan container images
• Avoid using latest tags
• Store images in an approved registry
• Test playbooks in CI
• Use FQCNs
• Use Ansible Vault or centralized credentials
• Separate development and production credentials
• Require code review
• Maintain audit logs

21. Example Modern Ansible Project

ansible-project/
├── .devcontainer/
│   ├── devcontainer.json
│   └── Containerfile
├── .github/
│   └── workflows/
│       └── ansible-ci.yml
├── inventory/
│   ├── development/
│   │   └── hosts.yml
│   └── production/
│       └── hosts.yml
├── playbooks/
│   └── site.yml
├── roles/
│   └── webserver/
├── group_vars/
├── host_vars/
├── tests/
├── ansible.cfg
├── ansible-navigator.yml
├── execution-environment.yml
├── requirements.yml
├── requirements.txt
├── bindep.txt
└── README.md

Purpose of Each File

22. Common Misunderstandings

“Ansible Navigator Replaced Ansible Core”

It did not.

Navigator uses the Ansible runtime and provides an alternative interface for executing and inspecting automation.

ansible-core remains the underlying automation engine.

“Execution Environments Replace Playbooks”

They do not.

An execution environment packages the runtime used to execute playbooks.

Your playbooks, roles, inventories, and variables still exist as normal project files.

“A Dev Container and Execution Environment Are the Same”

They are not necessarily the same.

A Dev Container is optimized for development.

An Execution Environment is optimized for running automation.

They may share a base image or some dependencies, but they serve different purposes.

“The VS Code Extension Includes Ansible”

The extension provides editor functionality. It still requires access to Ansible tools installed locally or inside a container.

“I Must Use Navigator for Every Ansible Project”

You do not.

For small scripts and basic learning, ansible-playbook remains perfectly valid.

Navigator becomes more valuable when execution environments, artifacts, or Ansible Automation Platform compatibility are required.

“Containers Remove Every External Dependency”

They remove many control-node dependencies, but not every external dependency.

Automation may still require:

• Network access
• SSH keys
• API tokens
• Vault passwords
• DNS resolution
• Proxy configuration
• Cloud credentials
• Access to private registries

These must be passed or mounted securely.

23. Practical Migration Path

Organizations do not need to adopt every modern component immediately.

A sensible migration path is:

Stage 1: Traditional Ansible

ansible-playbook
inventory
roles
variables

Stage 2: Explicit Dependencies

ansible-core
requirements.yml
requirements.txt

Stage 3: Quality Controls

ansible-lint
syntax checking
Git
code review
CI

Stage 4: Reproducible Runtime

ansible-builder
execution environments
ansible-navigator

Stage 5: Reproducible Development

VS Code
Dev Containers
Ansible extension
Molecule

Stage 6: Enterprise Governance

Ansible Automation Platform
RBAC
central credentials
workflows
approved execution environments
private automation hub

This gradual approach avoids overwhelming teams while steadily improving automation quality and reproducibility.

Conclusion

The modern Ansible ecosystem is easier to understand when its components are separated by responsibility.

• ansible-core is the automation engine.
• The Ansible community package combines the engine with a broad set of Collections.
• Collections distribute modules, roles, and plugins.
• Python virtual environments provide lightweight Python isolation.
• ansible-navigator runs and inspects automation, particularly inside execution environments.
• Execution environments provide reproducible Ansible runtimes.
• ansible-builder creates those execution environments.
• The VS Code Ansible extension improves the authoring experience.
• VS Code Dev Containers standardize the complete development workstation.
• Ansible Automation Platform provides centralized enterprise execution and governance.

For basic learning, a local Ansible installation remains sufficient.

For individual projects, ansible-core with a virtual environment and pinned dependencies is often enough.

For teams, the strongest modern workflow is:

VS Code Dev Container
        +
Ansible extension
        +
ansible-navigator
        +
custom execution environment

For enterprise production environments, add Ansible Automation Platform for centralized credentials, role-based access, scheduling, auditing, workflows, and controlled execution.

The goal of these newer tools is not to make Ansible unnecessarily complicated. Their purpose is to solve problems that appear as automation grows:

• Dependency conflicts
• Inconsistent developer workstations
• Different development and production runtimes
• Difficult onboarding
• Weak testing
• Limited governance
• Poor reproducibility

You should therefore choose the simplest Ansible workflow that meets your current requirements, while keeping a clear migration path toward execution environments and standardized development containers as your automation estate grows.