Hands-on Lab·CompTIA Linux+
Infrastructure as code, idempotence and drift
Domain 4 asks for the vocabulary of infrastructure as code, and the words are easy to define and hard to recognise. This guide writes one short playbook describing a desired state, runs it twice to show what idempotence looks like in a recap line, breaks the machine behind its back, finds the drift with a dry run that changes nothing, and corrects it.
Automation and Scripting Guide 28 of 28 Intermediate
- OSAlmaLinux 10.2
- Kernel6.12.0-211.7.3.el10_2
- systemd257
- Mandatory access controlAppArmor on Ubuntu, SELinux enforcing on Alma
- TimeAbout 24 min
- Firewallufw / nftables 1.1.6 - firewalld / nftables 1.1.5
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| LPLUS-B01 | 192.168.0.74 | AlmaLinux 10.2 | RPM-family host - dnf, firewalld, NetworkManager, SELinux | 2 Core | 4 GB | 50 GB |
This guide includes
Use this when you need to know what these terms mean in practice rather than as definitions. This matters because a script and a playbook look similar and behave completely differently on the second run, and because the difference is the entire reason the tools exist.
- describing a desired state rather than the steps to reach it
- reading
changed=in a play recap as the answer to "did anything need doing" - recognising a task that is not idempotent, and why a shell command usually is not
- detecting drift with
--check --diffwithout altering the machine - correcting drift by re-running the same unchanged description
- placing Ansible, Terraform and a shell script relative to each other
Before you start
- a-script-a-repo-and-a-container
-
The tool, and what agentless means
-
A description of a desired state
-
Running it once, and running it again
-
Drift, and finding it without correcting it
-
Correcting it
-
Putting the machine back