Home / server / Questions / 40441
Accepted
joeforker
Asked: 2009-07-15 05:10:45 +0800 CST

How do you manage multiple similar Apache configurations?

  • 772

Right now I'm using Mercurial to synchronize similar Apache configurations between the production and development servers. A patch queue on top of that adds in the changes and extra stuff required for the development server.

The scheme works but it could be better. I always get merge conflicts when I reapply the patch queue after pulling changes from the deployment configs. I feel like I am always making identical changes to the separate http:// and https:// config files.

How should I factor out the identical bits between my :80 and :443 Apache configs and more cleanly add in the "extra bits" to the development config?

apache-2.2 configuration

3 Answers

  1. Best Answer

    You might want to consider using the Include feature of Apache's config system. Then separate out the elements of your config that are specific to an individual machine into a _local.conf that should make the merging simpler

    • 5

  2. Apache has an option to selectively enable certain configurations. This lets you use the same config file for development and production. Start apache with -DDEVELOPMENT or -DPROD, and you can use tags for configuration that is specific to the dev server. This way you won't get any merge conflicts (unless you change both dev/prod config files before merging of course)

    • 3

  3. This may be old school, but my stage and production apache configs were identical, except that some of the parameters within each were different (ie: IP address). I used a perl wrapper around a start script to 'fill in the blanks' in a methodical way. The actual base config 'templates' were indeed identical.

    This insured that the stage apache was functionally identical to the production apache.

    Sharing this production config with development enabled them to test as close to production as they wanted (and they wanted to, because they would not get into production unless their stuff 'worked' in stage. We supplied help occasionally (for mod_rewrite rules for example) and left the rest up to the developer.

    Difference between this particular setup and other places I've worked are:

    developement staff were encouraged to dabble in areas not directly related to the programs they worked on... ie: they may work on back-end applications (thus wouldn't need to know much about apache) yet they configured their own apache servers (in fact built their own desktops, but that's a line crossed IMnsHO).

    operations actually drove a lot of the infrastructure, rather than just running it.

    • 2