-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Christoph,

On 10/7/15 4:36 AM, Christoph Nenning wrote:
>> Hi list,
>> 
>> I just signed up to the list - please forgive any newb mistakes
>> but hopefully I'm following the right format, style and content.
>> 
>> I currently work in a production environment with eight app
>> servers, all running the same version of Tomcat (currently
>> 7.0.62).  Four servers support version 1 of our app, the other
>> four servers support version 2.  Within each group of four, two
>> serve completely open content via 80, the other two support
>> queries of sensitive data via 443.  Servers are named with a
>> number system where all odd-named servers are for the secure
>> content, all evens are open.
>> 
>> So here's the setup in a hopefully clearer portrayal:
>> 
>> App Version 1: Server 01: secure queries via 443 Server 02: open
>> content via 80 Server 03: secure queries via 443 Server 04: open
>> content via 80
>> 
>> App Version 2: Server 05: secure queries via 443 Server 06: open
>> content via 80 Server 07: secure queries via 443 Server 08: open
>> content via 80
>> 
>> Each pair of even and odd named servers are *conceptually*
>> linked, but physically stand on their own.  All http traffic and
>> https traffic for each version is directed to a particular server
>> by a load balancer.  No Apache Web Server is in the mix and we
>> would like to keep it that way for simplicity.  Load-wise, our
>> eight Tomcats are not taxed.
>> 
>> I'm responsible for upkeep of these servers, which requires
>> regular version upgrades and configuration changes when any
>> vulnerability is found by regular, periodic Nessus scans
>> (http://www.tenable.com/ products/nessus-vulnerability-scanner).
>> Sometimes the changes are related to ciphers, sometimes other
>> things, but I'd say 90% of the time, I just need to upgrade to a
>> newer version.
>> 
>> So no big deal conceptually, I fully admit, but doing this across
>>  eight servers is TEDIOUS.  And more importantly, it's a ripe 
>> opportunity for introducing user error.  On three occasions I
>> have brought our production systems by stupid mistakes in
>> server.xml or other config files, or most recently, accidentally
>> copying the wrong ROOT from a version 2 (05) box into the version
>> one boxes (01 and 03). I got things up and running fine with no
>> serious consequences but this being the third time, I thought
>> "there has to be a better way" right after I talked myself off
>> the "you're a complete idiot"
> ledge.
>> 
>> I'm starting to research Tomcat clustering but everything I see
>> just talks about load balancing and failover.  **What about ease
>> of configuration??** I'd like to be able to set up Tomcat
>> <something> (clusters?) to help automate what I've described
>> above to make it less tedious and reduce the chances of making
>> stupid mistakes when I'm on the 6th, 7th, 8th server.  I'm not
>> sure if Tomcat clustering is what I need, or if I should look at
>> something else.
>> 
>> Can you nice folks help direct me to where I should look for 
>> starters?  Will Tomcat clustering get me what I want?  or
>> something else, like Zookeeper?
>> 
>> Thanks, Mark Bramer
>> 
> 
> 
> We do somthing similar by utilizing docker containers.
> 
> At first we create a base-image consisting of: - minified linux
> distro - jvm - tomcat
> 
> Then we have application images based on that which add: - app
> specific tomcat config - the app itself
> 
> These images can be run as multiple instances and thus becoming 
> containers.
> 
> When we update tomcat it is done in the base-image and all
> app-images are rebuilt and containers restarted. So it is just one
> place where the change has to be done.
> 
> On config updates the according app-image is changed, rebuilt and 
> restarted.

I would love to invite you to ApacheCon and have you give a
presentation on how you do this because it's something I've been
wanting to do for a while, now.

Would your employer send you to ApacheCon?

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJWFUEwAAoJEBzwKT+lPKRYw34P/1QAyLAWOioogv2pJPQ09Ppx
kFVvgw1XJPhaI2ZdFgadPXkrvm9wNJIU/cR+/I+97Ehpmk/DFM0ZutYjunzB0IeI
Cr883Y/PtPvJvhurkggM4P147F68d/4DpdSDCNrdmHteQ3k3lB6pY57PCCr/45zX
81s553Nn/Y/l3m4HEUjWbIYZI2BiL1Fp8aJ//hgB8t/GWAPRoeTh6PMstQqD9EhA
xE7dkdlH4vYVMUtV8krPUGGgIbfJ1Q3UOyk36SdDBx5kNacFPM1BrwW/HSwj9ou1
GYeAlb+uAYIaKglADhKkjVwTxeYnJWscA5yoaTzSUNyQE08yVTD/ekhlR9b5EVMi
XUa1G9lGLgpJjMhCVK6yqSn+fHbZvxDPaYzpFHG3UQmxVBI+kl8GKhckSQRtG64k
PTJrQsC1xcjwh0i4Fi/FrOaveHndNCHv2eQ7KbarKWivE886gLMBtINuHNWoGHuP
dcQUK2wiTWCQR141Oiqd17p18/gYxUqtOhyzNW3SxkfwyTvEfE8BT8ioOH0350Li
l53bTEAiqhnF2clzQcWLDjsuSWnMfjGLVT/KD2WFDUe0awjOy/kc16OqWndKdpB0
iWVM2Ds6ddf63h4bdBvLI2+INugu+PkQIXoN9/J7OYaNB+oo4GCUidPfk9kGRQl2
YaRATse6j0NsPjgipVju
=aprI
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to