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
cd
rsync -e ‘ssh -i private_key_full_path/id_rsa_application2’ –exclude=.svn -nzvrpoglHDIt –delete root@
….
….
cd
rsync -e ‘ssh -i private_key_full_path/id_rsa_application2’ –exclude=.svn -nzvrpoglHDIt –delete root@
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.]]>
