Chris, On 5/20/2017 4:37 PM, Christopher Schultz wrote: > Mark, > > On 5/19/17 3:26 PM, Mark Eggers wrote: >> GB, > >> On 5/19/2017 8:28 AM, gkk gb wrote: >>> If my current Tomcat is installed in >>> >>> >>> /home/tomcat/dir1/apache-tomcat-8.5.9 >>> >>> >>> and then I install the latest Tomcat in >>> >>> >>> /home/tomcat/dir1/apache-tomcat-8.5.15 >>> >>> >>> how does Apache web server know to connect to the newer version >>> of Tomcat? Is this established by the definition of CATALINA_HOME >>> in .bash_profile? Or, some other way? >>> > >> The connection is done (normally) via a port. It's either AJP and >> the AJP port configured in server.xml, or HTTP (could be HTTPS) and >> the HTTP (or HTTPS) port configured in server.xml > >> This depends on how your Apache HTTPD server is configured. > >> If you use the same ports, then only one Apache Tomcat can be >> running at a time (can't have two processes listen on the same port >> - technically address / port combination). > >>> >>> Can I install both Tomcat versions side by side and switch >>> between them to verify everything works fine with the newer >>> Tomcat before deleting the older Tomcat? >>> >>> > >> Yep. > >> 1. Install newer Tomcat 2. Make sure server.xml is set the way you >> need it to be 3. Copy web applications over to new Tomcat > > I would always recommend using separate CATALINA_HOME and > CATALINA_BASE directories. You mention this below, but it's worth > reinforcing the fact that upgrades become even easier once this split > has been done. > >> 4. Shut down old Tomcat 5. Start up new Tomcat 6. Test > >> Then make a decision. If the your applications have difficulties >> with the new Tomcat, shut down the new Tomcat, start the old >> Tomcat, and debug the issues on a development / test environment. > >> I do something similar to upgrade Tomcats, albeit with an Ant >> script, separate CATALINA_HOME / CATALINA_BASE, and an appBase >> outside of CATALINA_BASE. > >> This allows me to install new Tomcat versions without taking down >> the old Tomcat. When it comes time to upgrade, I do the following: > >> 1. Shut down the Tomcat service 2. Move two links to the new Tomcat >> version (CATALINA_HOME / CATALINA_BASE) 3. Start up the Tomcat >> service > >> If there are issues, I can easily fall back to the old Tomcat >> with: > >> 1. Shut down the Tomcat service 2. Move two links to the old Tomcat >> version 3. Start up the Tomcat service > >> All of the server.xml modification information is kept in a set of >> property files which are versioned. The Ant scripts use the >> property files to configure Tomcat instances. > > This is roughly what we do as well: our ant-based build scripts build > server.xml (and context.xml for that matter) from a set of properties > that are specific to the application (and environment). > > And of course Tomcat is started/stopped with those same scripts :) > > Come to think of it... did I give you my Ant scripts ages ago? Or did > you develop your own? I think I may have promised to publish them, but > maybe never did. > > -chris
I developed my own. I use the Ant scripts just for customizing Tomcat installations. I do have one slight issue with my current Ant scripts. The link task isn't supposed to create a link if it already exists, but it does, and actually creates a link inside of the existing link. This means that I have a manual cleanup step to do, which is annoying. Also, the Ant xml task doesn't handle namespaces well. I'll have to figure out how to mangle tomcat-users.xml in a better fashion for the 8.x series. I use a custom-built init script for starting, stopping, querying, and getting the version of a Tomcat services. I'll have to build something soon to handle systemd. I use Maven, the Tomcat Maven plugin, and Jenkins to customize a WAR file for a particular environment. Coupled with parallel deployments, this basically allows us to update with no downtime. Mark /mde/
signature.asc
Description: OpenPGP digital signature
