Idempotency means repeatedly running infrastructure automation produces the same end state as running it once, without side effects unless configuration changes or drift occurs. It keeps repeated operations from unnecessarily rebooting, recreating, or damaging resources. section 1.3.2
Avoiding an unnecessary switch reboot
A first network script reboots a switch every time it runs, disconnecting critical applications. An idempotent revision checks whether the interface is already configured and reboots only when the required configuration is absent or changed. section 1.3.2
Build idempotency into infrastructure automation by:
- Checking whether the current configuration matches the expected state before changing a resource. section 1.3.2
- Testing create, read, update, and delete functions so repeated execution produces the same configuration. section 3.6
- Using dependency-aware automation that can repeatedly converge networks, servers, and firewalls to the same state. section 4.5
- Testing imperative steps with varied prerequisites and mocking infrastructure API responses where necessary. section 6.2.3
- Preserving the existing state during migrations and refactoring by checking dry runs and correcting drift before applying changes. section 9.3.2 section 10.2.2
Figure 1.8 In version 1 of the script, you reboot the switch each time you run the script. In version 2, you check whether the network interface is configured before rebooting the switch. This preserves the working state of the network.
Compare the non-idempotent script that reboots on every run with the conditional version that preserves the working network state. section 1.3.2
Without idempotency, rerunning automation can double the number of servers, remove critical database data, duplicate migration data, or introduce unexpected changes during refactoring. Treat it as one of the core infrastructure-as-code principles alongside reproducibility, composability, and evolvability. section 1.3.2 section 1.3.5
