Deployment refers to the process of installing a Web application into the tc Runtime instance. This section describes two ways to deploy Web applications to the tc Runtime instance.
Static deployment: To deploy
statically, you simply copy your Web application, either as a packaged
WAR file or as an uncompressed directory (also called
exploded), to the deployment directory of the tc
Runtime instance. This directory is specified by the
appBase property of your virtual host; the default value
is CATALINA_BASE/webapps. Assuming that the
autoDeploy property of your host is enabled (default
value), then as soon as you copy your Web application to the
deployment directory, the tc Runtime instance deploys and starts it,
and users can immediately start using the application. See the
procedure below for details.
Dynamic deployment using HQ: The HQ user interface is a sophisticated GUI console with which you can deploy Web applications located on local or remote computers. You can also create groups of tc Runtime instances and then deploy a WAR file to the group; the HQ user interface then takes care of deploying the WAR file to each individual member of the group. This feature helps you avoid having to deploy to each tc Runtime instance individually, saving you much time if you have many servers in your environment.
See Tutorial: Using HQ to Configure and Manage tc Runtime Instances for a tutorial that describes how to deploy applications to single tc Runtime instances, create tc Runtime groups, and deploy an application to the group.
It is assumed in this section that you have already created a Web
application and want to deploy it to a tc Runtime instance so you can
start using the application. If you do not have a Web application, see
Tutorial: Very Simple Web Application
Development for a tutorial that describes how to create a very
simple HelloWorld application.
To deploy a Web application
statically: Copy the WAR or exploded directory to the
deployment directory, which by default is
CATALINA_BASE/webapps. For example, if your
CATALINA_BASE variable is
/home/tcserver/vfabric-tc-server-standard/myserver, and your
Web application is the exploded directory /home/apps/myApp,
then you deploy it statically with the following command:
prompt$ cp /home/apps/myApp /home/tcserver/vfabric-tc-server-standard/myserver/webapps
If you want to use a different deployment directory than the default
CATALINA_BASE/webapps, set the appBase attribute
of the <Host> element that configures the virtual host
for your tc Runtime instance. For additional details about static
deployment, see Tomcat
Web Application Deployment.
The tc Server Developer Edition includes Tomcat Manager, an Apache Web application that you can use to deploy your own Web applications and manage their lifecyle, such as starting, stopping, and undeploying them.
The default tc Server Developer Edition configuration does not automatically authorize any user to access Tomcat Manager. The following procedure describes how to authorize a user to access the application, and then how to invoke the Web application in your browser.
Update the CATALINA_BASE/conf/tomcat-users.xml
file in the tc Runtime instance by adding a manager
role.
The default tomcat-users.xml file does not
include any roles or users, although examples are shown in
comments.
An entry for the manager role looks like this:
<tomcat-users> <role rolename="manager" /> ... </tomcat-users>
In the same file, add a user with role manager.
For example, to specify that the tomcat user (with
password tomcat) have the manager role,
add the <user> element to the
tomcat-users.xml file, as follows:
<tomcat-users> <role rolename="manager" /> <user username="tomcat" password="tomcat" roles="manager" /> </tomcat-users>
Restart the tc Runtime instance for the changes to take effect.
Invoke Tomcat Manager in your browser using the following URL:
http://host:8080/manager/htmlwhere host
Enter the user and password you configured in the
tomcat-users.xml file, in our example
tomcat/tomcat.
The Applications table lists the currently deployed applications. Click the links in the Path column to actually invoke each application. The Commands column includes buttons for starting, stopping, reloading, and undeploying the applications.
From the Deploy section, you can deploy Web applications (either exploded or in a WAR format) from either the host where running the tc Runtime instance or from the local computer running your browser. When deploying from the host, you must specify the context path that users use to invoke the application.
For detailed information about Tomcat Manager, see the Manager App How-To on the Apache Tomcat Web site.
When you create an instance using tc Runtime 7, you can deploy multiple versions of the same web application. This makes it possible to upgrade applications without interruption. Users who have a session in process continue to use the existing version of the application, but new sessions use the latest version of the application.
To deploy a new version of an existing application using static
deployment, append a version number to the context name, separated by
two hash signs:
contextName##versionmyapp.war and you want to upgrade to version 2.0, you can
deploy the new WAR file myapp##02.0.war.
If you use the Hyperic HQ user interface to deploy a new version, do not rename the WAR file. The tc Server HQ plug-in automatically appends the version number for you.
Users continue to use the same URL to access the application; they do not include the version number. New sessions use the highest version deployed. Existing sessions continue to use the version that is already managing their session. If tc Runtime cannot locate the session in the SessionManager of an earlier version, the newest version is used.
The version number is processed as a string, not as a number. This
means that you can use letters in the version number, for example
myapp##02b. It also means that you must be careful to
ensure that your version numbers compare correctly. If the current
version is myapp##9.0, deploying myapp##10.0
will not work as expected because the string "9.0" sorts higher than
"10.0".
When all sessions using an earlier version of an application have ended, the older version can be undeployed.