Ansible: repeatable configuration

1. Start without a cloud bill

No cloud account, SSH key or administrator password is needed for this lab. It writes one learning file inside your home directory. Windows users use Ubuntu in WSL; Linux users use an Ubuntu terminal. Follow Microsoft’s WSL setup first if needed. These are not PowerShell commands.

sudo apt update
sudo apt install -y python3-venv
mkdir -p ~/contoso-automation
cd ~/contoso-automation
python3 -m venv .venv
source .venv/bin/activate
python -m pip install ansible-core
ansible --version

This installs community ansible-core in an isolated environment, not a Red Hat-supported AAP runtime. Record the version that passes your tests; do not assume every future release behaves identically.

2. Give Ansible a checklist

Save these three files together in your project. Inventory says which computer; the playbook says what should be true; the template turns a variable into a file. localhost uses a local connection, not SSH.

The output goes to ~/contoso-automation-output/message.txt under the executing user’s home. Facts discover that path instead of hard-coding a username. No system service or cloud object is changed.

3. Run, verify and repeat

ansible-inventory -i inventory.ini --graph
ansible-playbook -i inventory.ini site.yml --syntax-check
ansible-playbook -i inventory.ini site.yml
cat ~/contoso-automation-output/message.txt
ansible-playbook -i inventory.ini site.yml

Expect the message and passing assertions. On the second run, the directory and template should report no changes. That is idempotence: repeating the checklist should not keep rearranging the room. Syntax checking does not prove permissions or business logic; assertions inspect the actual outcome.

4. Preview one small change

ansible-playbook -i inventory.ini site.yml --check --diff -e '{"lab_message":"My second Contoso message"}'
ansible-playbook -i inventory.ini site.yml -e '{"lab_message":"My second Contoso message"}'
cat ~/contoso-automation-output/message.txt

Use check mode after the first real run. It predicts supported changes; it cannot prove a deployment succeeded or read a file that does not yet exist. Our verification tasks skip check mode. Diff exposes contents, so do not use this exercise with secrets.

Extra variables override defaults. Pass the same message for another repeat run; without the override the original default returns. Limit launch-time variables to trusted inputs. As shared logic grows, organize it into roles and pin tested collection versions.

Reference: check and diff modes and variables.

5. Graduate to remote configuration

Use our AWS, Azure or Google Cloud server guide for a real SSH target. Set its actual address, login user and private-key path. Verify the server fingerprint independently first; do not disable host-key checking.

become: true means privilege escalation, not “make the error disappear.” Use it only for authorized tasks that require it. This lab deliberately uses become: false. Troubleshoot inventory → connection → Python → path → permissions → expected content. Do not hide failures with ignore_errors.

6. Clean up only the practice file

ls -la ~/contoso-automation-output
rm -i ~/contoso-automation-output/message.txt
rmdir ~/contoso-automation-output
deactivate

The removal is limited to this generated file; inspect it first and retain anything you want. Keep source files for the AAP exercise. Do not commit credentials, .venv or private inventories. No cloud resources were created.