On 3/10/2014 2:42 PM, Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Leo,
On 3/10/14, 5:10 PM, Leo Donahue wrote:
I have to change the following in server.xml when I add more
Tomcat instances or upgrade:
server shutdown port connector port for HTTP connector port for
AJP realm org.apache.catalina.realm.UserDatabaseRealm if digesting
passwords in tomcat-users.xml host appbase (optional depending on
config) valve org.apache.catalina.valves.AccessLogValve (optional
depending where you like the root log to go) cleaning up all the
comments...
I script all of this with ant. Since I segment all of my web
applications into separate JVM/Tomcat instances, I just need:
1. An appBase
2. A shutdown port
3. A "normal" port (usually AJP)
4. (optional) a loopback-only port for privileged applications that
want to access my instance locally without HTTPS, load-balancing, etc.
We have multiple devs using the same shared development environment,
so everyone has an "app a" and "app b", and so on.
We create a parameterized server.xml file that basically says <Server
shutdown=${tomcat-shutdown-port}">, etc. and then ant takes a
user-specific configuration file and builds the configuration on the fly.
To deploy a new Tomcat instance, we just clone a started-project, give
it a name (in Ant's <project name="..."> attribute) and it picks-up
the configuration from this user-config file.
$ ant install tomcat-start
That's all it takes us to build a properly-configured CATALINA_BASE,
install the web application under development and launch Tomcat. I've
been using this setup for over 10 years at this point, and it's been
fantastic.
- -chris
Yep,
I've done something similar with ant and property files. We version
control the property files so if values need changing, we have a record.
The way we do upgrades is pretty handy.
1. create a new service with a new CATALINA_BASE and CATALINA_HOME
2. shut down the old service
3. move two links (to the new CATALINA_BASE and CATALINA_HOME)
4. start the new service
Step 1 has no impact on production, so we can do this well in advance.
Rollback is just as easy - repeat steps 2-4. It takes longer to do the
bookkeeping than it does to do the actual upgrade (or downgrade).
The script also has the capability of adding (or deleting) Host nodes.
Each Host node gets its own properties file.
This is done on Linux, so links work as expected.
In short, there are lots of ways to manage a bunch of Tomcat instances
with little effort.
. . . . just my two cents.
/mde/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
