How to do configuration management right?

[kjkoster]

Dear All,

I have a question for you today. How do you keep the configuration of your application servers in sync across your environments (development, test, production, multiple machines in a cluster).

In many shops I see the sysadmins use see-point-click configuration interfaces to configure their application servers. That's all fine and nice, until you have to debug some really nasty class loader issues and change the container settings into 'the only combination that works'. I always ask how they will ensure that all the machines in the production cluster get these settings. Much to my astonishment they answer: "by manually comparing the screens".

How do you guys make sure that all servers in a cluster have the correct settings? When configuring development, test and production environments, how do you deal with the combination of settings that need to be identical and settings that need to be different?

Kees Jan

[Kees de Kooter]

As mentioned in a different thread I always try to keep the configuration that needs to be done to a bare minimum, preferable only a datasource and a mail session.

I use maven profiles to build packages for different target environments.

So the sysadmin only has to set one or two items in his app server (using his method of choice ;-)) and my environment-targeted app takes care of the rest.

[Barry]

Some things I keep in mind for clusters/JEE applications:
-Minimize configuration
-Store shared settings in a database
-Use JNDI for resources as much as possible

The database is part of your code management (You do check in your schema's and do change management on data in the database right?)
The other settings should not be more than some xml/properties, most of which can be filled with data from Maven profiles or ANT builds

[Barry]

Btw Kees Jan.

Do you still check in your configuration files into SCM (Subversion)?
If so, how is it working out for you?

I'm thinking of doing the same myself actually.

Regards,

Barry

[kjkoster]

Dear Barry,

Yes, I still do that. A complete Tomcat is just over 10MB and SVN handles that with no problems.

The only nit is that Tomcat rewrites tomcat-users.xml when it shuts down, so you always have a 'change' to commit after running.

I have a deployment script that does things like copy machine-specific configuration files into the tomcat folders after checkout. It also removes the .svn dirs on production machines.

Kees Jan

[Barry]

Well...

I wasn't planning on going as far as plunking a whole Tomcat into subversion (I still have scars from that experience, thanks Kees Jan.. people still pick on me for following your orders ;) )
I was more thinking along the lines of dumping the configuration folder into SVN and possibly rolling a script that will check the last edited date on the config files and auto commit them, but my SHELL-fu is not strong enough.

[kjkoster]

Dear Barry,

Well, forgive me. If the strongest counter argument that your valued collegues can come up with is: "noone else does this" there is nothing I can do put press on and (make you) do it.

Kees Jan