From configuration tool to automation platform
Ansible began as an agentless automation tool for server configuration: playbooks in YAML, connection via SSH, no agent to install on managed nodes. This simple model took Ansible from managing a handful of servers to becoming one of the most widely adopted IT automation platforms in the world. But the evolution of the infrastructure landscape — multi-cloud, containers, software-defined networking — has demanded an equally significant evolution in the project’s structure.
Restructuring around Collections
The most important architectural change in recent years is the restructuring around Collections. Previously, hundreds of modules — for AWS, Azure, Google Cloud, VMware, databases, network services — were distributed together with the main Ansible package. Each release required coordinating thousands of modules with different development cycles.
Collections separate modules and plugins from the core. Each Collection is an independent package with its own release cycle, documentation and maintainers. The amazon.aws Collection can release a new version without waiting for an Ansible release; the community.general Collection evolves at its own pace.
ansible-core and Galaxy
The result of the restructuring is a clear separation: ansible-core contains the execution engine, the playbook language, plugin APIs and a minimal set of builtin modules. Everything else — hundreds of modules for cloud platforms, databases, network services, containers — is installed as a Collection from Ansible Galaxy, the Collection marketplace.
Galaxy works as a centralised registry: teams can publish their own Collections, share roles and plugins with the community, and manage dependencies through a requirements.yml file analogous to those used by package managers.
Execution Environments
Execution Environments solve a practical problem: the Python dependencies needed to run different modules can conflict. An AWS module requires boto3, an Azure module requires the Azure SDK, a networking module requires netmiko — and the versions must be compatible with each other and with the system’s Python.
Execution Environments are container images that include ansible-core, the required Collections and all Python dependencies in an isolated and reproducible environment. The ansible-builder tool generates these images from a configuration file, and ansible-navigator uses them as the default execution environment. The result is automation that does not depend on the state of the control machine.
Automation beyond servers
In 2022 Ansible’s scope extends well beyond server configuration. Collections cover cloud provisioning — creating VPCs, load balancers, Kubernetes clusters — management of network appliances from Cisco, Juniper and Arista, automation of databases, containers and CI/CD pipelines. For organisations managing hybrid infrastructures, Ansible offers a single declarative language to orchestrate heterogeneous resources.
Link: ansible.com