Cubis Engineers

Ansible for Cloud Infrastructure

Automate repeatable Linux server tasks from one control machine without installing an agent on every server.

Cloud & infrastructureFoundationUpdated Aug 13, 2026ansibleautomationlinuxcloudconfiguration-management

Ansible runs on a control node—usually your workstation or a CI runner—and connects to managed Linux servers over SSH. Managed servers do not run an Ansible agent, but they normally need Python and an account that can use sudo for privileged tasks.

Use Ansible after you have completed a task manually and understand how to verify it. Automation makes a good procedure repeatable; it also repeats mistakes quickly.

What you will build

Terminal
control node
├── inventory/production.yml     servers and groups
├── group_vars/all.yml           shared settings
├── templates/                   managed configuration files
└── playbooks/server-baseline.yml

          └── SSH → managed Linux servers

Install Ansible on the control node

The Ansible project documents pipx as a supported way to install the full package without mixing it into the system Python environment.

Terminal
brew install pipx
pipx ensurepath
pipx install --include-deps ansible
ansible --version

Open a new shell after pipx ensurepath if ansible is not found. Pin the Ansible version in team and CI environments so a new release does not change behavior unexpectedly.

Project layout

Start with files in version control rather than /etc/ansible:

Terminal
mkdir -p infrastructure/ansible/{inventory,group_vars,playbooks,templates}
cd infrastructure/ansible
touch ansible.cfg inventory/production.yml group_vars/all.yml
ansible.cfg
[defaults]
inventory = inventory/production.yml
interpreter_python = auto_silent
retry_files_enabled = False

[ssh_connection]
pipelining = True

Do not disable SSH host-key checking to make setup easier. Add server host keys to known_hosts through a reviewed process so Ansible can detect an unexpected host.

Use Ansible for the right work

Good first tasks are package installation, users and SSH keys, configuration files, systemd services, directories, firewall rules, and scheduled jobs. Keep cloud resource provisioning separate unless the team has chosen and tested the relevant cloud collection and inventory plugin.

Prefer modules over shell commands

Modules such as ansible.builtin.package, user, template, and service understand the desired state and can avoid unnecessary changes. Use command or shell only when no suitable module exists, and define exactly when the command should run.

Official references

On this page