I’ve been wondering whether automated CM tools like Ansible and Chef make system changes in the best way possible from a configuration management point of view. Right now they make changes by executing a series of script statements. This works and is a powerful approach, but I wonder if these tools couldn’t “compile” the changes into packages and install them instead. For example, could the configuration for BIND be assembled into a .rpm package (company_BIND_config_1.2.3.rpm), published to the company package repository, and then installed via yum update?
The benefits of creating an intermediate file are that it:
- uses the platform’s native package management system
- allows rollback
- provides automated dependency management (the config package depends on the application package)
- provides better configuration management
- simplify the deployment process from test to production
Ansible is already very lightweight and uses only an SSH connection to make changes. Using packages would require nothing beyond yum. If the configuration rpm caused problems on a production machine it could be rolled back using yum. The package files could be verified using the rpm verify function. A version numbered configuration package would make it a true configuration item (CI) and which could be tracked in a CM database; something which the current script based approach does not allow.
This idea is speculation on my part. There may be good reasons why this wouldn’t work. We don’t want to lose the power of the configuration tools. On the other hand, it would be useful if the tools supported actual configuration management (in the IEEE Std 828-2012 sense).