Infrastructure Automation and Configuration Management Services

Infrastructure Automation: Ansible, AWX, Rundeck, SaltStack

The task sounds simple: update the nginx configuration on 200 servers. Doing it manually takes two days and inevitably leads to several discrepancies between servers. Our team writes an Ansible playbook in 15 minutes, runs it, and gets an identical configuration on each server with changes committed to git. Automation not only speeds things up—it eliminates the class of problems arising from manual management.

We have been automating infrastructure since 2019—over 5 years, with more than 50 projects completed: from startups with 10 servers to enterprise clusters with 2000 machines. Our stack: Ansible, AWX, Rundeck, SaltStack. Our approach is always the same: idempotency, versioning, RBAC, documentation. The result: downtime reduced by 80%, and the number of incidents due to human error drops threefold.

Why is idempotency the main requirement for production?

Beginners write Ansible like bash scripts using command and shell everywhere. Production-grade Ansible uses idempotent tasks with proper modules, variable management, and role separation. Idempotency ensures that re-running a playbook does not introduce unnecessary changes. Without it, each execution risks breaking the configuration, and rollback becomes a lottery.

Role structure instead of flat playbook

roles/ nginx/ tasks/ main.yml install.yml configure.yml handlers/ main.yml templates/ nginx.conf.j2 vhost.conf.j2 defaults/ main.yml vars/ main.yml files/ ssl/ 

defaults/main.yml — low-priority variables that are easy to override. vars/main.yml — high-priority variables, rarely overridden. This is important: Ansible has 22 variable priority levels, and confusion between them is a source of hard-to-diagnose bugs.

Idempotency is the core requirement

The template module changes a file only if it has changed—this is correct. command: sed -i 's/old/new/' /etc/app.conf is not idempotent; it will run every time. The correct approach: use the lineinfile or replace module.

Handlers and notify

Nginx does not need to be restarted if the config hasn't changed:

# tasks/configure.yml - name: Deploy nginx config template: src: nginx.conf.j2 dest: /etc/nginx/nginx.conf owner: root mode: '0644' validate: 'nginx -t -c %s' notify: Reload nginx # handlers/main.yml - name: Reload nginx systemd: name: nginx state: reloaded 

validate with nginx -t checks the config before copying. If validation fails, the task is not executed, and the server does not get a broken config. The handler fires once at the end of the play, even if multiple tasks notified it.

Secrets via Ansible Vault

ansible-vault encrypt_string 'secret_password' --name db_password creates an encrypted string that can be stored directly in vars/main.yml. Vault password file via --vault-password-file or the environment variable ANSIBLE_VAULT_PASSWORD_FILE for CI/CD without interactive input.

Dynamic inventory

For AWS, use the aws_ec2 plugin:

# inventory/aws_ec2.yml plugin: amazon.aws.aws_ec2 regions: - eu-central-1 filters: tag:Environment: production instance-state-name: running keyed_groups: - key: tags.Role prefix: role - key: placement.availability_zone hostnames: - private-ip-address 

ansible-inventory -i inventory/aws_ec2.yml --graph will show the automatically generated group structure based on EC2 tags. No need to manually update the hosts file when infrastructure changes.

How does AWX scale Ansible for a team?

Running ansible-playbook from a laptop is fine for one engineer. When 10 people run playbooks, centralization is needed: who ran what, when, and with what result. AWX (the open‑source version of Ansible Tower) solves exactly this.

What does centralized Ansible via AWX provide?

Job Templates are playbook + inventory + credentials + extra vars. Created once, run any number of times with the same parameters or with overrides via Survey.

A Survey is a form with parameters that the operator fills in before execution. For example: environment choice (staging/production), application version for deployment, run_migrations flag. This allows the team to run playbooks without access to the code.

Credentials in AWX are stored encrypted and are never exposed to the user—they are only used during execution. SSH keys, AWS credentials, Vault password—all are stored in AWX and not copied to workstations.

- name: Create Job Template awx.awx.job_template: name: "Deploy Application" job_type: run inventory: "Production Inventory" project: "Infrastructure" playbook: deploy.yml credentials: - "SSH Production" - "Vault Password" survey_enabled: yes survey_spec: name: "Deploy Survey" description: "" spec: - question_name: "Application version" variable: app_version type: text required: yes - question_name: "Run database migrations" variable: run_migrations type: multiplechoice choices: "yes\nno" default: "no" state: present