Comparison
Declarative configurationvsImperative configuration
Declarative configuration
you write down what should exist, submit it, and something else works out the steps — including that most of them are already done.
Describing the end state you want rather than the actions to reach it, and letting a controller compute the difference. Its defining property is that applying the same description twice is a no-op, which is what makes automation safe to re-run and re-run by default. The cost is a loss of directness: you cannot straightforwardly express 'do this once', and you have to learn to debug a system that is arguing with you rather than one that failed a step.
Full entry →Imperative configuration
you ran the commands in order, and doing it again would create a second copy of everything.
Specifying the steps rather than the outcome — create this, scale that, delete the other. It is direct, obvious and perfect for a one-off; it becomes a liability the moment the same script needs to run against a system that is already partly in the target state. The practical middle ground most teams land on is imperative commands for investigation and declarative files for anything that must survive a person leaving.
Full entry →