Part 7b: Setting up a flexible Lenya environment
22 May 05
With a little more complex setup under our belts, let's take a look at a more flexible example. But before we do, let's recap what we've learned so far.
The Big Split
The image above is a diagram of what we set up in part 7a of this tutorial. You have two physical servers, connected through a network in some way (either through a crossover cable between the servers or through your network), one serving the Authoring area and the other serving the Live area. The Authoring server has a pubs directory (our repository) where all our files are stored. Using replication with rsync (again, you can use any other method, but this is the one I'm showcasing), the pubs directory on the Live server mirrors the one on the Authoring server. Each run an instance of Lenya/Tomcat (or Lenya/Jetty if you prefer) running at the usual port 8080. You can go nuts with mod_proxy if you so choose.
The downer to this setup is that if you are actively making changes to Lenya's source or to the publications themselves, you would have to take down the Authoring and/or Live instances, add in all your changes, then bring the instances back up. This is unwanted downtime on your site. What if your changes aren't perfect and something goes wrong? Then you'll have to bring the site down again, revert back to the old site (you did make a backup, didn't you?) and then bring the instances back up again. Again, more downtime. Well, let's expand our above setup so that this can be accounted for with as little downtime as possible.
Let's get stupid with Tomcat
Yeah, you heard me. We're gonna go crazy with Tomcat and add a couple of more instances to our setup. One more for the Authoring server, and another for the Live server. This means we need to be a little more vigilant with how our data is replicated so that we aren't overwriting production data with pre-production data. See the updated diagram below.
So, we still have the same two servers, but now each instance on the server serves a different purpose. One instance will be labeled as "pre-production" and the other will be labeled as "production". The pubs directory for the pre-production instance on the Authoring server will be replicated to the pubs directory for the pre-production instance on the Live server. The same holds true for the production instances as we did in our example in part 7a of this tutorial.
What's great about this is that while the production site is being served, you can put all your changes in place on the pre-production instances and test there. Once everything is perfect, then just change your mod_proxy settings so that it reverse proxies to the pre-production instances. Now, your pre-production instances become production and the previous production instances now become pre-production and the development cycle begins again. Your downtime is drastically reduced because all that needs to be restarted is Apache after you have changed the mod_proxy settings. That's all but a second or two. Nice, eh?
I won't go into any installation instructions, because they are exactly the same as our first example, only your installing tomcat twice on the same server. To change the port that Tomcat runs on, open up the file conf/server.xml under your Tomcat installation folder and search for the entry: <Service name="Catalina">. The port attribute should read 8080. Change that to whatever port you like (as long as it is above 1024 and is not used by any other service on your server). I just chose 7080 because it was closer to the default 8080 port.
Sharing data between Pre-Production and Production instances
It's quite possible (and highly likely) that you'll want to share the pubs between the pre-production and production instances. After all, if you're just making some changes to the publication or Lenya source code and then turn pre-production into production, don't you want to be using the same publications from your previous production instance? Sure you do. But this is quite simple. You can setup another rsync job that syncs the pubs directories between the pre-production and production instances on a regular, but in-frequent, basis, or you can just copy it manually when needed. No fuss, no muss. It would seem a bit wasteful, however, to rsync every 5 minutes between pre-production and production when you won't be making as many changes in the pre-production environment as production. Once a day might be nice, or force an rsync right before you start conducting tests in pre-production to cut down on load. Then rsync again before you turn it into production.
Adding in a Development server
So we've got quite the flexible setup going. One last thing - you really should have a setup just for developing to your heart's content. Wouldn't it suck if you were doing some development on the pre-production instance that (heaven forbid) took down the server? Oops. To avoid that, setup another server that has one instance of Tomcat/Lenya running so that you can mess around all you want and it won't affect anything in production.
Again, if you need copies of the pubs you have in pre-production or production, you can set that up manually, but my guess is that in a development environment, you'll be messing around more with functionality than with the publication's documents themselves.
How sweet it is
And there you have it, a very flexible setup for you to use in your Lenya installation. As always, feel free to post questions or comments on this and any other article I've posted here. Happy coding!