# Git Repo to mantain the app configurations in several servers

I need to versioning in a GIT repository, configurations of a particular platform, spread across multiple servers. Take into account that in each of these servers there are completely different configurations, while the application is the same. What is the best way to do this?

1. Create a branch for each server

• repository.git:conf --> [branch Server 1]
• repository.git:conf --> [branch Server 2]
• repository.git:conf --> [branch Server N]
• Note: This method seems to me, that is difficult to maintain because each change in the server configurations, I need to create subbranches which becomes confusing.
2. Create a single repo with a different directory for each server

• repository.git:conf/Server 1
• repository.git:conf/Server 2
• repository.git:conf/Server N
• Note: This is easy to mantain
3. Create a repo for each server

• repository_1.git:conf
• repository_2.git:conf
• repository_N.git:conf
• Note: This method requires me to create a branch for each new server.

There are other methods, what are the best practices in this case? Should I use the one that I feel most comfortable?

Tks,

Gulden PT

-
I say do whatever puppet does. –  Ignacio Vazquez-Abrams Jan 13 '11 at 12:40

Bcfg2 is a great configuration management system than can be used with any version control system.

I use one repository for all of the systems I manage. Bcfg2 handles differences in configuration files for different machine and groups by appending the hostname or group name with a priority to the file name. Bcfg2 gives your system the most specific file for each ConfigFile entry.

So, in your configuration decription you would have:

<ConfigFile name="/etc/network/interfaces" />


and your config files would be:

# ls Cfg/etc/network/interfaces
interfaces
interfaces.H_server1
interfaces.H_server2


The main benefit I see with Bcfg2 over Puppet and Cfengine is that instead of running scripts to configure your system to do things, Bcfg2 determines how your system does not fit your specification and makes what changes are necessary.

-

Actually, the easiest way is to run everything through a Config Management tool. I prefer Chef, but Puppet and cfengine also solve the same problem. Chef, at least was built with the intent or expectation that the configurations would be stored in version control.

However, Without redoing your infrastructure, you should probably script the copying of your individual config files to a common directory, ensure that if the files aren't named to be self-evident, wrap them in a sensically-named folder, and wrap that in the server name.

So:

--networkDrive
----ServerName1
------WebServerConfig
------AppServerConfig
----ServerName
------AnotherAppConfig
----ServerName


...and so on...

From there it's easy to git it up and commit (which is also easily scriptable.)

-
Does cfengine, Puppet and Chef requires to install software(agents,ruby,phyton,...) in the remote nodes, or the nodes are Configuration Managment System independent? –  gulden PT Jan 13 '11 at 16:55
Chef requires a client (I think it requires Ruby, but I'm not sure), however this can be easily scripted and built into your computer automated build process so that you never need to think about it again. –  gWaldo Jan 19 '11 at 13:55