Maintaining multiple Java application versions on an E2E CLOUD server

Customer requirements:-
————————-
1. Has a local SVN server running on an ubuntu machine at a local LAN in their office.
2. Wants to run a Java webserver on Ubuntu 12.04 LTS server on server.
3. Owns a domain name on which to run the web-application

Suggested Setup:-
Setup Application on various application contexts in a Java Webserver (e.g. Tomcat) on URLs like
http://localhost:8080/application-version1
http://localhost:8080/application-version2
….
….
http://localhost:8080/application-versionN
in folders
/usr/local/java-webserver/webapps/application1
/usr/local/java-webserver/webapps/application2
….
….
/usr/local/java-webserver/webapps/applicationN

The application codebases can be directly updated via rsync from the local machine’s SVN working copies on a machine on client’s LAN by using the rsync over ssh transport.

Run via cron or manually the following
cd
rsync -e ‘ssh -i /id_rsa_application1′ –exclude=.svn -nzvrpoglHDIt –delete root@:/usr/local/java-webserver/webapps/application1

cd
rsync -e ‘ssh -i private_key_full_path/id_rsa_application2’ –exclude=.svn -nzvrpoglHDIt –delete root@:/usr/local/java-webserver/webapps/application2

….
….

cd
rsync -e ‘ssh -i private_key_full_path/id_rsa_application2’ –exclude=.svn -nzvrpoglHDIt –delete root@:/usr/local/java-webserver/webapps/applicationN

On Apache2 use mod_proxy to reverse proxy multiple application contexts on to various fully qualified host names as below:-

Production Version at a VirtualHost on Apache2 with ServerName www.
proxying http://localhost:8080/PRODUCTION

Version 1 at a VirtualHost on Apache2 with ServerName www.
proxying http://localhost:8080/application1
….
….
And so on.

Notes:-

As you see only 1 routable IP address is required for such a setup and a single server. The SVN doesn’t need to setup on the remote server outside the office LAN.
Database configuration management is similarly easy where each application context can use its own DB in MySQL/PerconaDB/MariaDB/PostgreSQL
Use of a separate private key for each version is suggested as it seems that each working copy version on the branches for an application codebase is being worked by an individual developer.