Configuration as Code: The Next Chapter After Your Infrastructure is Born
So you've deployed your shiny new infrastructure with Terraform and you're sitting there wondering what comes next? Well, congratulations, you've just given birth to a bunch of empty servers that are about as useful as a chocolate teapot until you actually configure them to do something.
This is where Configuration as Code enters the picture, and more specifically, where Ansible becomes your new best friend. If Terraform is the architect that builds your digital house, then Ansible is the interior designer who makes it actually livable.
The Great Divide: Infrastructure vs Configuration
Let's get something straight from the beginning. Terraform and Ansible aren't competitors, they're more like Batman and Robin, each with their own superpowers. Terraform excels at creating infrastructure – spinning up virtual machines, setting up networks, provisioning databases. But once those resources exist, they're basically digital paperweights until someone configures them.
That's where Ansible swoops in with its configuration management magic. While Terraform manages the lifecycle of infrastructure resources, Ansible focuses on what happens inside those resources. Think of it this way: Terraform builds the stage, Ansible directs the performance.
What Even Is Configuration as Code?
Configuration as Code is basically treating your server configurations the same way you treat your application code. Instead of logging into servers and manually installing packages, editing config files, and crossing your fingers that you remember all the steps next time, you write playbooks that describe exactly how your servers should be configured.
The beauty is in the repeatability. You can take a freshly provisioned server from Terraform and transform it into a fully configured web server, database server, or whatever you need, with a single command. No more "it works on my machine" because every machine gets configured exactly the same way.
Ansible: The Swiss Army Knife of Configuration Management
Ansible is what happens when someone decides that SSH should be a lot more powerful. It's agentless, which means you don't need to install anything on your target servers – Ansible just connects via SSH and does its thing. This is different from other configuration management tools that require you to install agents everywhere like some kind of digital surveillance network.
The tool uses a simple philosophy: you write playbooks in YAML that describe the desired state of your systems, and Ansible figures out how to make that happen. It's declarative, which means you tell it what you want, not how to do it. Want Apache installed and running? Just say so. Ansible will check if it's already installed, install it if needed, and make sure it's running.
The Post-Terraform Workflow
Here's how the beautiful dance between Terraform and Ansible typically works. First, Terraform provisions your infrastructure and spits out useful information like IP addresses, instance IDs, and other details. Then, either automatically or manually, you feed this information to Ansible, which takes over and configures everything.
The workflow looks something like this: Terraform creates the servers, Ansible configures them, and you sit back and watch the magic happen while sipping your coffee. Some teams even automate the handoff so that as soon as Terraform finishes provisioning, it triggers Ansible to start configuring.
Ansible Architecture: Control Nodes and Managed Nodes
Ansible operates on a simple client-server model, except there's no server. You have a control node (your laptop, a CI/CD server, or a dedicated management box) that runs Ansible commands, and managed nodes (your servers) that receive and execute those commands.
The control node needs Python and Ansible installed, while the managed nodes just need SSH access and Python. That's it. No databases to maintain, no agents to update, no additional infrastructure to manage. It's like having a remote control for your entire server fleet.
Inventory: Your Digital Phone Book
Before Ansible can manage your servers, it needs to know where they are. This is where inventory comes in – it's basically a list of all the servers you want to manage, organized into groups. After Terraform creates your infrastructure, you'll typically either create a static inventory file or use dynamic inventory to automatically discover your servers.
[webservers]
web1 ansible_host=10.0.1.10
web2 ansible_host=10.0.1.11
web3 ansible_host=10.0.1.12
[databases]
db1 ansible_host=10.0.10.10
db2 ansible_host=10.0.10.11
[webservers:vars]
http_port=80
max_clients=200
This inventory file defines two groups of servers: webservers and databases. You can also set variables at the group level, so all webservers get the same configuration values. It's like having a contact list that also stores notes about each person.
Playbooks: The Scripts That Make Magic Happen
Playbooks are where the real action happens. They're YAML files that contain one or more "plays," and each play targets a group of hosts and defines tasks to run on them. Think of a playbook as a recipe, and each task as a step in that recipe.
Here's a simple playbook that configures a web server after Terraform has provisioned it:
---
- name: Configure web servers
hosts: webservers
become: yes
vars:
packages:
- nginx
- curl
- git
tasks:
- name: Install required packages
package:
name: "{{ packages }}"
state: present
notify: restart nginx
- name: Start and enable nginx
service:
name: nginx
state: started
enabled: yes
- name: Copy nginx config
template:
src: nginx.conf.j2
dest: /etc/nginx/nginx.conf
backup: yes
notify: restart nginx
handlers:
- name: restart nginx
service:
name: nginx
state: restarted
This playbook installs packages, starts services, and deploys configuration files. The become: yes directive tells Ansible to use sudo for privileged operations. The notify keyword connects tasks to handlers, so nginx only gets restarted when the configuration actually changes.
Modules: The Building Blocks of Automation
Ansible modules are like individual tools in a toolbox – each one performs a specific task. There are modules for managing packages, services, files, users, databases, cloud resources, and just about everything else you can think of. The beauty is that modules are idempotent, meaning you can run them multiple times without causing problems.
Some of the most commonly used modules include:
packageoryum/aptfor managing software packagesservicefor controlling system servicesfilefor managing files and directoriestemplatefor deploying configuration files with variable substitutionuserfor managing user accountscopyfor copying files to remote hosts
Each module takes parameters that define what it should do. The package module needs to know which package to install, the service module needs to know which service to manage, and so on.
Templates: Making Configuration Files Dynamic
One of Ansible's superpowers is its ability to create configuration files dynamically using Jinja2 templates. Instead of having static configuration files, you can create templates that get populated with variables at runtime.
Here's a simple nginx configuration template:
server {
listen {{ http_port }};
server_name {{ ansible_fqdn }};
location / {
root /var/www/html;
index index.html;
}
access_log /var/log/nginx/{{ ansible_hostname }}_access.log;
error_log /var/log/nginx/{{ ansible_hostname }}_error.log;
}
This template uses variables like http_port and facts like ansible_fqdn to create a customized configuration file for each server. The same template can generate different configurations for development, staging, and production environments just by changing the variables.
Variables: The Data That Drives Your Playbooks
Variables in Ansible are like the settings on your washing machine – they determine how everything behaves. You can define variables in multiple places: in inventory files, in playbooks, in separate variable files, or even pass them on the command line.
Here's how you might organize variables for different environments:
# group_vars/webservers.yml
http_port: 80
max_connections: 1000
app_version: "2.1.4"
# group_vars/databases.yml
db_port: 5432
max_connections: 200
backup_hour: 3
Variables can also be facts that Ansible gathers automatically about each host, like the operating system, IP addresses, memory, and disk space. These facts make your playbooks smart enough to adapt to different types of servers automatically.
Handlers: The Notification System
Handlers are special tasks that only run when they're notified by other tasks. They're perfect for things like restarting services when configuration files change, or reloading applications when new code is deployed.
The brilliant thing about handlers is that they only run once, even if multiple tasks notify them. So if you update three different configuration files that all require nginx to restart, the handler ensures nginx only gets restarted once at the end of the playbook run.
tasks:
- name: Update nginx config
template:
src: nginx.conf.j2
dest: /etc/nginx/nginx.conf
notify: restart nginx
- name: Update php config
template:
src: php.ini.j2
dest: /etc/php/php.ini
notify: restart nginx
handlers:
- name: restart nginx
service:
name: nginx
state: restarted
Roles: The Lego Blocks of Infrastructure
As your playbooks grow, you'll discover that you're repeating yourself a lot. That's where roles come in – they're a way to package related tasks, variables, files, and templates into reusable components.
A role has a specific directory structure:
roles/
└── webserver/
├── tasks/
│ └── main.yml
├── handlers/
│ └── main.yml
├── templates/
│ └── nginx.conf.j2
├── files/
├── vars/
│ └── main.yml
└── defaults/
└── main.yml
Once you've created a role, you can use it in any playbook with just a few lines:
---
- name: Setup web servers
hosts: webservers
roles:
- webserver
- monitoring
- security
Roles make your Ansible code modular and reusable. You can create a database role, a web server role, a monitoring role, and mix and match them as needed. It's like having a library of pre-built automation that you can apply to any server.
Secrets Management with Ansible Vault
Configuration management inevitably involves secrets – database passwords, API keys, SSL certificates, and other sensitive data that you don't want floating around in plain text. Ansible Vault solves this problem by encrypting sensitive files and variables using AES256 encryption.
You can encrypt entire files:
ansible-vault create secrets.yml
Or encrypt individual variables within a playbook:
database_password: !vault |
$ANSIBLE_VAULT;1.1;AES256
66386439653761336464306537336534393734...
When you run your playbooks, Ansible automatically decrypts vault-encrypted content using the password you provide. This means your secrets stay encrypted in version control but are available to your automation at runtime.
Real-World Example: Configuring the Terraform-Provisioned Infrastructure
Let's take the infrastructure we built with Terraform in the previous blog and configure it with Ansible. We have a VPC with web servers and a database, all freshly provisioned and waiting to be configured.
First, we need an inventory that reflects our Terraform outputs:
# inventory/aws_hosts.yml
all:
children:
webservers:
hosts:
web-server-1:
ansible_host: 54.123.45.67 # From Terraform output
ansible_user: ec2-user
ansible_ssh_private_key_file: ~/.ssh/main-key.pem
databases:
hosts:
postgres-db:
ansible_host: main-postgres-db.abc123.us-west-2.rds.amazonaws.com
ansible_user: dbadmin
Next, let's create a playbook that configures our web server:
---
- name: Configure web application stack
hosts: webservers
become: yes
vars:
app_port: 8080
db_host: "{{ hostvars['postgres-db']['ansible_host'] }}"
app_user: webapp
tasks:
- name: Update system packages
yum:
name: '*'
state: latest
update_cache: yes
- name: Install required packages
yum:
name:
- nginx
- python3
- python3-pip
- git
state: present
- name: Create application user
user:
name: "{{ app_user }}"
home: /opt/webapp
shell: /bin/bash
system: yes
- name: Install Python dependencies
pip:
name:
- flask
- psycopg2-binary
- gunicorn
executable: pip3
- name: Deploy application code
git:
repo: https://github.com/company/webapp.git
dest: /opt/webapp/app
version: main
become_user: "{{ app_user }}"
notify: restart webapp
- name: Create application config
template:
src: app_config.py.j2
dest: /opt/webapp/config.py
owner: "{{ app_user }}"
mode: '0600'
notify: restart webapp
- name: Create systemd service file
template:
src: webapp.service.j2
dest: /etc/systemd/system/webapp.service
notify:
- reload systemd
- restart webapp
- name: Configure nginx as reverse proxy
template:
src: nginx_webapp.conf.j2
dest: /etc/nginx/conf.d/webapp.conf
notify: restart nginx
- name: Start and enable services
service:
name: "{{ item }}"
state: started
enabled: yes
loop:
- nginx
- webapp
handlers:
- name: reload systemd
systemd:
daemon_reload: yes
- name: restart webapp
service:
name: webapp
state: restarted
- name: restart nginx
service:
name: nginx
state: restarted
This playbook transforms our bare EC2 instance into a fully configured web application server. It installs software, creates users, deploys code, configures services, and starts everything up.
Templates for Dynamic Configuration
The playbook references several templates. Here's what the nginx configuration template might look like:
# templates/nginx_webapp.conf.j2
upstream webapp {
server 127.0.0.1:{{ app_port }};
}
server {
listen 80;
server_name {{ ansible_default_ipv4.address }};
location / {
proxy_pass http://webapp;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
location /health {
access_log off;
return 200 "healthy\n";
add_header Content-Type text/plain;
}
}
And the application configuration template:
# templates/app_config.py.j2
import os
class Config:
SECRET_KEY = os.environ.get('SECRET_KEY') or '{{ app_secret_key }}'
DATABASE_URL = 'postgresql://{{ db_user }}:{{ db_password }}@{{ db_host }}:5432/{{ db_name }}'
DEBUG = {{ 'True' if environment == 'development' else 'False' }}
PORT = {{ app_port }}
These templates allow the same playbook to work across different environments by simply changing the variables.
Environment-Specific Variables
Different environments need different configurations. Here's how you might structure environment-specific variables:
# group_vars/all.yml
app_user: webapp
app_port: 8080
# inventory/production/group_vars/webservers.yml
environment: production
app_secret_key: !vault |
$ANSIBLE_VAULT;1.1;AES256
66386439653761336464306537336534393734...
db_password: !vault |
$ANSIBLE_VAULT;1.1;AES256
33643036353239643435386439653761336464...
# inventory/staging/group_vars/webservers.yml
environment: staging
app_secret_key: staging-secret-key
db_password: staging-password
This approach keeps sensitive production data encrypted while allowing staging environments to use simpler configurations.
The Integration Dance: Terraform to Ansible
The handoff from Terraform to Ansible can be automated in several ways. One approach is to use Terraform's local-exec provisioner to trigger Ansible after resources are created:
resource "aws_instance" "web" {
# ... instance configuration ...
provisioner "local-exec" {
command = "sleep 30 && ansible-playbook -i inventory/aws_hosts.yml site.yml"
environment = {
ANSIBLE_HOST_KEY_CHECKING = "False"
}
}
}
Another approach is to use Terraform outputs to generate Ansible inventory dynamically:
output "ansible_inventory" {
value = templatefile("inventory_template.yml", {
web_servers = aws_instance.web[*].public_ip
db_endpoint = aws_db_instance.postgres.endpoint
})
}
Some teams prefer to keep the tools separate and use CI/CD pipelines to orchestrate the workflow: run Terraform, extract outputs, generate inventory, run Ansible.
Advanced Patterns: Roles and Galaxy
As your Ansible usage matures, you'll want to leverage Ansible Galaxy, which is like GitHub for Ansible roles. Instead of writing everything from scratch, you can download community-maintained roles for common tasks.
# Install a role from Galaxy
ansible-galaxy install geerlingguy.nginx
# Use it in your playbook
---
- name: Setup web servers
hosts: webservers
roles:
- geerlingguy.nginx
- company.webapp
You can also create your own roles and share them within your organization or with the broader community. This promotes code reuse and helps establish standard practices across teams.
Error Handling and Debugging
Ansible provides several mechanisms for handling errors and debugging playbooks. You can use the failed_when and changed_when directives to customize when tasks are considered failed or changed:
- name: Check if application is responding
uri:
url: "http://{{ ansible_default_ipv4.address }}/health"
status_code: 200
register: health_check
failed_when: health_check.status != 200
retries: 5
delay: 10
For debugging, you can use the debug module to output variable values or add the -vvv flag when running playbooks to get verbose output.
Best Practices That Actually Matter
After working with Ansible in production environments, certain practices emerge as genuinely important:
Use meaningful names everywhere. Your future self (and your teammates) will thank you for descriptive task names, variable names, and role names.
Structure your projects consistently. Establish conventions for directory layouts, naming, and variable organization. Document these conventions and enforce them through code reviews.
Test your playbooks. Use tools like Molecule to test your roles, and always test changes in non-production environments first.
Use version control religiously. Your Ansible code is infrastructure code and should be treated with the same care as application code.
Keep secrets secret. Always use Ansible Vault for sensitive data, and never commit unencrypted secrets to version control.
When Things Go Sideways
Ansible isn't magic, and sometimes things don't work as expected. Common issues include SSH connectivity problems, permission errors, and module-specific failures. The key is to understand that Ansible is essentially running commands over SSH, so many debugging techniques from regular system administration apply.
The --check flag runs playbooks in dry-run mode, showing what would happen without actually making changes. The --diff flag shows the differences that would be made to files. Both are invaluable for understanding what your playbooks will do before they do it.
The Bigger Picture
Configuration as Code with Ansible transforms how you think about server management. Instead of servers being precious snowflakes that you carefully tend and maintain, they become cattle that can be easily replaced. This shift in mindset enables practices like immutable infrastructure, where you replace servers rather than modify them.
When combined with Terraform's infrastructure provisioning capabilities, Ansible completes the automation story. You can go from nothing to fully configured, production-ready infrastructure with a few commands. This level of automation isn't just convenient – it's essential for modern cloud-native applications that need to scale quickly and reliably.
The tools will continue to evolve, new approaches will emerge, and the ecosystem will keep growing. But the fundamental principle remains: treat your configurations like code, version control them, test them, and deploy them consistently. Your infrastructure will be more reliable, your deployments will be more predictable, and your on-call rotations will be much more pleasant.
Welcome to the world where your servers configure themselves exactly the way you want them, every single time.