Linux: December 2006 Archives
I maintain two websites for my company. By "maintain", I mean "run the server, and let someone else update them." I wrote the code for one of them, and the other is a static webpage which hasn't changed in years. Those are just the public ones, and I have plans to add several more internal websites as we expand.
Oh, "as we expand." Seeing as every site will have it's own T1 line, point to point T1 line, and linux/windows server combo, this means that I could host the public (and private) websites on a lot of IPs, and a lot of servers. However, I really really didn't want to have to maintain and update website code on multiple servers. The solution? Subversion.
As it stands now, we have company sites A, B, and C. C is merely a remote location without any servers, linked into it all with a point to point T1. Likewise, we're going to ignore that site completly. A is considered the "home" building, and I work in the B building. The B building actually has space for IT equiptment, and likewise that's where the large majority of it resides. Sites A and B each have a linux/windows server combo, but site B also has a decent sized RAID array. So, I picked the 1.2TB RAID array to house the actual subversion repositories.
I setup the repo server to be served over apache. I didn't bother with SSL because 1) the point to point T1 lines run IPSEC and 2) apache is configured to allow the login "server/server" from a hard-coded list of IPs (which would be the servers). The server login is not allowed write priviliges either. If you were to try to access the SVN repo from anywhere else, the server login would not work, and further I'm the only other one with a login. Seeing as I'm sitting about four feet away from the SVN server, I'm not worried about plaintext transmission (but I'll fix that when I get around to it).
The repo itself contains 1) all of the needed apache vhost config files, 2) htaccess files and 3) all of the actual website data. Due to items one and two, in httpd.conf I can throw in the line "Include /srv/conf/vhosts/*" and never worry about having to configure apache ever again. Likewise, if I really screw something up, it's easy to revert all of the servers at once to a working configuration.
Logging is still one thing I need to figure out. Currently, the vhosts are just set not to log anything at all. I need to think up a way to store the logs locally on each server, yet still manage to generate statistics for all of the servers combine. The best I can come up with so far is a daily rotation of the logs, only at the end the previous logs are shipped off to be stored somewhere (and likewise merged together, and then analyzed). Unless anyone else has any better ideas, I'll probably wind up doing that in the near future.
The servers have a cron job that runs nightly, which will execute `svn up` in /srv, and then /etc/init.d/apache2 reload. That's it. That's really all that there is to it.
Now I have a versioned setup for multiple servers. Further, it's rather easy to add additional servers: USE="mysql apache2" emerge apache php; cd /; svn co http://svn/srv. Tada. All done, just like that.
I would like to point out, however, that there is a reason I did not use NFS for this. Firstly, that's a single point of failure over an already incredibly loaded point to point T1 line. That's also the second reason: less traffic going over the links that would be better used to serve people files as they work through the day. Lastly, I just don't like NFS much.
Plus, it allows me to update any aspect of the websites from any computer. Never mind the local copy I can keep on my laptop and desktop at work.
As a direct result of installing subversion to maintain a few websites, I've simplified the management that I have to do, increased my ability to effectively admin multiple servers at once, and cut back on bandwidth running inbetween the two sites.
Subversion: what do you want to do today?
