|
|
||||
During development of your application, you will need to deploy new versions 10's or 100's of times.
There are three ways to deploy a new application in Tomcat.
At Metawerx, all JVM's support Tomcat Manager and also AutoDeploy.
There is no reason to restart the JVM to restart your application.
Why don't other hosts provide Tomcat Manager, or only provide Private JVM's?
Other hosting companies who support Java often don't supply these tools as they require detailed configuration changes. This leaves their customers with the following options: An expensive "private JVM" with a suitable RAM allocation, a cheap "private JVM" with very limited RAM, or a periodic-restart of Tomcat. Some hosts do this daily, making you wait up to 24 hours to see your changes, others do it every 2 hours, taking your site offline every time they restart.
Tomcat Manager and AutoDeploy have been a part of Tomcat since Tomcat 4.0 and allow you to easily deploy, reload or undeploy your application(s).
Tomcat uses a separate ClassLoader per application, so it is quite a trivial task for Java or Tomcat to simply drop the current ClassLoader and instantiate a new one with your new application.
There are certain cases where this is not usable. Certain applications do not support reloading, such as early versions of Hibernate, and some of the larger applications released by the Open Source community which are expected to run in a JVM of their own due to their size. The problem with these applications is usually that they don't clean up threads that are started by the application, or leak memory each time they are reloaded. For these applications we recommend a Dedicated JVM with a suitable amount of RAM. However, most applications run perfectly on a shared VM.
How does Metawerx protect Tomcat Manager?
The standard Tomcat setup uses BASIC Authentication which sends your login and password over the network as base64-encoded plain text. This is trivial to sniff on any public or compromised network and gives an attacker or bot instant access to your login credentials.
We modify Tomcat locally to provide HTTP DIGEST Authentication, whether you are on a shared or dedicated/private JVM. On Tomcat 7 and above, and all Managed VMs (any version) we also implement an anti-brute-forcing mechanism. Tomcat is very mature these days and bots now regularly attack Tomcat Manager attempting to brute-force the password. As far as we know, we are the only Java Hosting provider that takes these extra steps.
We integrate the AutoShun and OpenBL public blacklists into our firewall settings every 4 hours
We have contributed to the OpenSource Tomcat project to enhance the features available in Tomcat's HTTP DIGEST Authentication code.
For even higher security, you can encrypt your entire Tomcat Manager session using SSL/TLS with our Enterprise-Level Crypto extensions.
How does Metawerx deploy their own software?
Metawerx is continually deploying new features and changes to the hosting tools you will use on your site, in exactly the same way as you are updating and deploying your own software.
As we have been doing this for years (since 1997), our own deployment process is quite mature.
We are often asked for advice on the best way to develop and deploy software to the servers. This is our current method:
* For all Metawerx internal applications, we use AutoDeploy
* First we modify the java source and project files, then compile locally to check for syntax errors. We use UltraEdit and ANT, or newer developers seem to prefer Eclipse.
* Next we check the changed java source into Subversion (supported at metawerx) for version control. This is as simple as a right-mouse button click, and typing a log message to record what was done and who did it.
* Our build server (CruiseControl) notices the change and runs an automated build on our build server. This is the integration-testing phase. Java source, JSP source, taglibs and JSP tags are compiled. Unit tests are run against the code. PMD and CheckStyle reports are generated to ensure that our coding standards are met. Developers are then mailed a list of errors, or a successful build notification.
* On a successful build, we then test the application locally on our test environment.
* Next we run a Windows batch file (two clicks on the Desktop), which uploads the changes to multiple servers using RSync (supported at metawerx). Only changed files are uploaded, so this takes around 3-5 seconds. We exclude the web.xml file from the upload here to avoid a premature redeploy.
* Next, the script "touches" the web.xml file to update it's timestamp. Then web.xml is RSync'd to the server as the final step. This triggers Tomcat's AutoDeploy method and within 20-30 seconds the application redeploys automatically (no need to restart the JVM). At this point, the changes are live for all clients.
* Finally we perform live testing and notify relevant customers of the change.
As you can see, we use exactly the same tools and services which are available to our customers. If we ever find a faster method, we will start to use it internally, and we will also make it available to our customers.
