When talking about Configuration Management it is important to acknowledge that writing Configuration Management code, or implementing “IaC” is virtually the same kind of work the software developers are performing. You use a professional code editor, abide to a strict set of syntax rules, track changes in Git or another VCS.
As an admin going the Configuration Management way, you effectively become a Developer of Operations for your infrastructure.
To emphasize the significance of the shift in work nature, the authors of the “UNIX and Linux System Administration Handbook” say that approaching CM activities in a different manner, without coordination and software developer attitude will surely result in “a muddle of conflicting or parallel code” and ultimately “the abyss”.
Other notable quotes from the chapter are these:
- changes should be structured, automated, and applied consistently among machines.
- People sometimes conflate DevOps and configuration management
- snowflake model of system administration – when no two systems are ever alike.
- security implications of this approach, however: the client controls the facts that it reports, so make sure that a compromised client can’t exploit the configuration management system to gain additional privileges.
- Nothing that runs out of cron, for example, can depend on the presence of an administrator to enter passwords. Working around that constraint inevitably ends up lowering security to the level of the root account.
- all major CM systems use similar conceptual models,
- they describe these models with different lexicons.
- Unfortunately, the terminology used by a particular CM system often has more to do with conforming to a marketing theme than with maximizing clarity.
- “environments,” both inside and outside the configuration management context.
- This seems to be the single term on which all configuration management systems agree.
- They’re an additional axis of variation that can affect multiple aspects of the configuration.
- A number of projects focus on specific subdomains of configuration management,
- notably new-system provisioning (e.g., Cobbler) and
- software deployment (e.g., Fabric and Capistrano)