Migrating system configurations

Question

Are there any tools like the Django South database migration app, but for migrating entire server configurations?

I manage several server configurations entirely from source control. Django app code, Apache configuration, load balancer configuration, Ubuntu package lists, everything is listed in a configuration file and deployable via Fabric commands. However, I still need to manually determine what's changed, and decide which deployment commands to run in sequence to make the server match my configuration files.

Ideally, I'd like to manage my servers that way South manages my database schema. After I've changed my code, I'd want to generate a "schema migration", which would determine if the Apache.conf needs to be rewritten, static media needs to be uploaded, a new system package needs to be installed, etc.

I've looked at some traditional configuration management tools, but even the biggest ones, like Chef and Puppet, don't seem to have any feature like this and usually aren't idempotent. My own personal experience with Chef showed that this is somewhat it's aim, but that it generally failed to accomplish this, and was notoriously difficult to customize and debug.

Does anyone know of a tool with this functionality?

Answer 1

We use EntryPoints.

We have a simple tool which calls all entrypoints it can find.

The most often used entry point for us is "restart".

On "restart" the docs get updated, the wsgi-file gets touched to restart the worker processes. And if there is a need for a change in the file system (stupid example: rename directory "temp" to "tmp") do it.

This tool does not track the history of what had already been done. This means every restart checks if there is still the directory "temp". That's Idempotence.

Up to now the restart is still fast enough. Every EntryPoint implementation could use some sort of shortcut to check if it has already been done (example "touch" a file "var/entrypoints/do-foo.done").

We don't use the manage-command of django for this, because we use this to set up the systems. If a system gets set up, django is not yet available.

But keep in mind: configuration is better then programming: If several apps needs symlinks, it is better to implement one entrypoint which asks (per entrypoint again) the other apps: What symlinks to you need?