Ansible Scalability, Deploy Configuration Files to Multiple Servers at Scale

Configuration drift starts the moment you SSH into servers one at a time. This blueprint provisions multiple AWS EC2 instances, builds an Ansible inventory from the live infrastructure, and pushes the same configuration file to every host in one declarative Kestra flow. It pairs Infrastructure as Code provisioning with Ansible configuration management so DevOps and platform teams can stand up fleets and keep them consistent without hand-editing hosts. Keywords: Ansible automation, AWS EC2 provisioning, configuration management, Infrastructure as Code, dynamic inventory, server orchestration.

How it works

1. The aws_setup task (io.kestra.plugin.aws.cli.AwsCLI) runs the AWS CLI to create an SSH key pair, create a security group opening port 22, and launch two t2.micro EC2 instances. It exports ssh-key.pem via outputFiles and emits instance metadata as Kestra outputs.
2. The ansible task (io.kestra.plugin.ansible.cli.AnsibleCLI) receives the SSH key plus two generated inputFiles: an inventory.ini built dynamically from the provisioned instance IPs, and a playbook.yml that copies a .env configuration file to /home/app/.env with mode: '0600' on every host in the servers group.
3. The task runs ansible-playbook -i inventory.ini playbook.yml --key-file ssh-key.pem, applying identical configuration in parallel across all targets.

What you get

• Repeatable provisioning of multiple EC2 instances from a single flow.
• A dynamic Ansible inventory wired to the actual provisioned IPs.
• Consistent configuration files and file permissions on every server.
• Dynamically managed SSH credentials passed between tasks, no manual key handling.

Who it's for

• DevOps engineers automating fleet configuration.
• Platform teams enforcing consistency across environments.
• Infrastructure teams adopting Infrastructure as Code with Ansible.

Why orchestrate this with Kestra

Ansible runs playbooks but does not schedule, retry, or track lineage between a provisioning step and a configuration step. Kestra closes that gap: chain AwsCLI output (keys, IPs) directly into the Ansible task with templating, add event triggers (a new commit, a webhook, a schedule) to drive runs, attach retries and alerting, and keep everything as declarative, version-controlled YAML with full execution history. The whole provision-then-configure sequence becomes one auditable pipeline instead of two disconnected tools.

Prerequisites

• A Kestra instance with the AWS and Ansible plugins available.
• AWS credentials authorized to create key pairs, security groups, and EC2 instances.
• The ansible-playbook CLI available to the Ansible task runner (for example via a Docker task runner image that bundles Ansible).

Secrets

This flow as written embeds AWS CLI calls and SSH key handling inline and does not reference any {{ secret('NAME') }} values. Before running in production, move AWS credentials and any sensitive playbook values (such as the database password and API secret in the .env content) into Kestra secrets and reference them with {{ secret('AWS_ACCESS_KEY_ID') }}, {{ secret('AWS_SECRET_ACCESS_KEY') }}, and similar.

Quick start

1. Add the flow to a Kestra namespace.
2. Configure AWS credentials for the AwsCLI task (env vars or pluginDefaults).
3. Adjust the AMI, instance type, region, and subnet to match your account.
4. Execute the flow and watch EC2 instances launch and the playbook apply.

How to extend

• Replace the static .env copy with templated config rendered from inputs or secrets.
• Scale the instance --count and let the inventory grow automatically.
• Add roles, handlers, or package installs to the playbook for full server setup.
• Swap AWS for another cloud and reuse the same Ansible deployment pattern.

Links

• Ansible plugin documentation
• AWS plugin documentation
• Orchestrate Ansible with Kestra