Infrastructure as Code with Terraform and Ansible

Infrastructure as Code: a practical guide

Where should Terraform state live?

Terraform records what it has built in terraform.tfstate, and that file holds passwords and other sensitive values in plain text. Committing it to Git is one of the most common mistakes. If two people run terraform apply at once without state locking, the file can be corrupted and Terraform loses track of what it manages.

For small teams, GitLab's managed Terraform state backend is the simplest choice, with locking and versioning built in. Otherwise we set up an S3 backend on an internal MinIO with locking enabled. Resources created by hand earlier are brought under management with terraform import or an import block, so nothing needs rebuilding.

Ansible AWX or playbooks from the pipeline?

AWX is the open source project behind Ansible Automation Platform. It adds a web UI, per-team access control, scheduled runs, a credential store and a history of every job. The trade-off is that AWX is itself a service, installed on Kubernetes with the AWX Operator, and it needs upgrades and care.

If your team is small and every change goes through a merge request, running ansible-playbook from GitLab CI is enough and adds nothing new to maintain. AWX earns its place when people outside engineering, such as a support desk, need to run specific playbooks without direct server access.

Common server configuration automation mistakes

Leaning on the shell and command modules instead of purpose-built Ansible modules makes playbooks non-idempotent, so a second run repeats changes or fails. Passwords typed straight into group_vars should be encrypted with ansible-vault or kept in Vault.

Pin your versions too: collections in requirements.yml and providers in .terraform.lock.hcl, which belongs in Git. The biggest problem is human, though. If people keep making changes over SSH after the code exists, servers and code drift apart again. A scheduled playbook run in check mode surfaces that drift early.

What determines the size of an IaC project?

The number of distinct server roles matters more than the number of servers. Twenty identical web servers need one role; five servers that each do something different need five. Operating system variety adds work as well, since supporting Ubuntu, AlmaLinux and Windows together takes longer than a single distribution.

Other factors: whether your hypervisor or cloud provider has a usable API, whether CI and Git are already in place, how much documentation exists, and whether secrets management has an answer yet. We agree the scope once servers and resources are listed.