Question

I'm scaling up a hosting environment to start using load balanced web servers running Apache. So far I've been managing VirtualHosts manually, but now I'm going to need a way to copy the VirtualHosts to the multiple other web servers. I have some ideas, and I'm wondering if people can comment on the pros/cons of each to help me decide.

  1. Create new VirtualHosts manually and create a script to rsync the conf files across servers.
  2. I'm considering using Puppet to manage packages across all servers. I could put the Puppet files in source control and use it to create VirtualHosts on each server.
  3. Create an NFS share and symlink the apache VirtualHost directory to there.

Opinions, past experiences, and light criticism is welcome.

Was it helpful?

Solution

Personally I would avoid NFS for something like this simply because it's another single point of failure (what if the NFS server goes down? You will not be able to start or probably do anything with your web servers).

Also, rsync seems an overkill, and Puppet is possibly also an overkill, depending on how many servers do you have.

If I were you, I'd simply put all the shared configuration files in a git or hg (Mercurial) repository and sync by simply pulling & updating the sources. If you need it to be more centralized than what git & hg do, use Subversion (note that if the Subversion repo server goes down, each of your web servers will have its own local copy of everything, from which you could reconstruct it).

OTHER TIPS

I have succesfully used NFS sharing to share apache configurations. This is used mostly in read mode, versy few writes. You will not have any performance problem. You my experience problems in services start order (ensure NFS is started before apache). NFS could also be used to share the SSL sessions data and maybe some application shared directories (temporary images uploads, maybe even the source code if the application maitain something like an opcode cache n php and is not doing dumb things).

Now using tools like puppet, salt-stack our chief is even better, as you could manage the service restart/reload after any configuration alteration.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top