automate server setup with source builds

I have a centOS5.4 server set that I have a "build script" for. The server runs as a webserver that runs apache+PHP for our proprietary app.

The build script, basically does a kickstart installation of the base OS and libraries that I need. I then have to go in and copy over the custom apache and PHP binaries that are built for our environment. Finally, I copy over our source code repository.

I have a couple problems with this, and would like advice on improving it:

1) If I build a new server, I want everything to be the same as the other servers. But at the time of install on the other servers I did an immediate yum update. If I do that currently on the new server, all kinds of libraries will be different.

2) Manually copying everything sucks. I'm about to build a shell script that will rscync and scp all the appropriate source code and config files, but I want to see if there is a better way first.

3) It would be ideal to create a disk dump image of the hard drive, then just DD that right onto the new server. BUT, for several servers, I am using software raid in mirror mode. Also, the hardware is slightly different. Does this matter? Will the mirror mode raid config just get picked up and rebuild the raid config on the second disk after I come back from boot? Will the other server hardware conflict with my base install?

Hopefully, someone comes out of left field here and just says, "No idiot, just user server clone enterprise 2k ++ ;) ". I would love that product. Thanks for your answers in advance.

CentOS is an enterprise grade operating system. Package updates do not increment major version, often have fixes back ported, and are well-tested before release. The risk is minimal. To lower the risk, test the updates yourself, your application against them, and then schedule out regular updates across your infrastructure.

Put your application on a fileserver and write a build script to deploy the application. Some people like to use their preferred packaging tool for deploying internal custom applications but it could be as simple as a tarball or a recursive transfer.

Creating images is something that is becoming less common. When it is used, it is typically applied to workstations or to environments with more static build standards. Historically, it was used in large enterprises that built a lot of servers as it was quicker to build from an image. I typically avoid it with UNIX servers but if build times became unusually sensitive I would start with benchmarking it relative to other methods.

There are a ton of configuration management tools available that you can use to help maintain your standards as well. Spacewalk is the Open Source counterpart to RedHat's Satellite Server.

I have gone into more detail on establishing server builds and standards in the following posts:

Managing an application across multiple servers, or PXE vs cfEngine/Chef/Puppet

1) As long as you perform regular updates on all your machines this will not be an issue. I know you mentioned setting up "machines". Here we use virtualization - I have created a "base" container and keep it turned off - using the tools provided by Virtuozzo I'm able to "clone" that image over and over again. When I need to update that clone I start it, run updates, then turn it off. While that works great for all new containers I still need to perform updates on all other running containers (Though I could opt to just keep the same "stale" image and replicate) What I achieve is having the software configuration I need (all applications, code, binaries, etc deployed and configured) and spinning up "new servers" is a snap

2) Have you thought of maybe building an RPM from your source code? While writing the actual spec files has been panned out to be a nightmare if you're simply running PHP code there isn't actually anything to "compile" meaning it's just writing a spec file that takes the source files from the RPM and place them in the correct location in addition to possibly running several setup scripts for Apache/your app. This can help you keep track of which server is running what version of your code and offer a way to better maintain your infrastructure.

3) I really can't answer that portion of your question.