Overview

Basic Deployment Methods

Webapps Directory Deployment

For a simple deployment, you can copy a .war archive file containing your application to a webapps directory. Resin will detect the .war archive, expand it, and start serving requests.

The webapps directory is configured and enabled by the <web-app-deploy/> tag in the resin.xml.

<resin xmlns="http://caucho.com/ns/resin">

  <cluster id="">
    ...
    <host id="">
  
      <web-app-deploy path="webapps"
                      expand-preserve-fileset="WEB-INF/work/**"/>
    
    </host>
  </cluster>
</resin>

The expand-preserve-fileset attribute lets you keep files for a redeployment, which can improve restart times. Normally, Resin will delete all files for an update, including the compiled files for JSP, which forces Resin to recompile JSP files, even if they haven't changed in the update. If you add the expand-preserve-fileset, Resin will only recompile the JSP files that have changed.

Command-Line Deployment

Command-line deployment uses the same resin.xml <web-app-deploy> configuration as a webapps deployment and expands the archive to the same directory. Instead of looking for the .war file in a directory, Resin will look in an internal repository using the web-app's identifier.

unix> resinctl deploy test.war

The default deployment is to the default host with the war's name as a prefix. Both can be changed with deploy options.

Command-Line vs Directory Priority

The command-line deployment takes priority over the directory deployement, because a deployment to a cluster ensures that all servers have the same version of the application. This means you must undeploy a web-app from the command-line if you decide to switch from command-line deployment to directory deployment.

unix> resinctl undeploy test.war
unix> cp test.war webapps

Deployment Expansion

The <web-app-deploy> controls the expansion based on web-app ids like "production/webapps/default/test" which is the same as the web-app identifier. The deployment expansion process looks like the following:

1. Look in the internal repository for "production/webapps/default/test" (uploaded by command-line). If an archive exists in the internal repository, skip to step #4.
2. If that fails, look for a webapps/test.war
3. If the webapps/test.war exists, copy the test.war into the internal repository as "server/[server-id]/webapps/default/test"
4. Use the archive in "production/webapps/default/test" (or "server/[server-id]/webapps/default/test") as the repository source archive.
5. Delete the old webapps/test directory (saving some directories when expand-preserve-fileset is configured.)
6. Expand the repository source archive files into the webapps/test directory.
7. Restart the webapp

The deployment identifier matches the web-app id that Resin logs at startup time. The identifier a repository tag that lets Resin have a general cloud repository system and also handle web-app deployments, versioning, and staging.

For the example web-app tag "production/webapp/default/test", the "production" is the deployment stage, "webapp" is because it's a webapp deployment, "default" is the virtual-host name and "test" is the web-app name.

Cloud Deployment

Activating deployed applications

Startup and Redeploy Modes

The startup-mode is used in a number of places to determine the behaviour of a resource when the server starts.

The startup-mode has three values: "automatic", "lazy", and "manual".

• automatic - starts the resource on server start (default)
• lazy - starts the resource on the first use
• manual - waits for JMX to start the resource

The redeploy-mode is used in a number of places to determine the behaviour of a resource when it is replaced or modified while the server is running.

The redeploy-mode has two values: "automatic", and "manual".

• automatic - restarts the resource when it is modified (web.xml, *.class, *.war, etc).
• manual - waits for JMX to restart the resource when changes occur.

Deploying to a live server without interruption

It may be possible to deploy a web application to a live server without interruption to service if certain conditions are met.

1. The session objects for your users are being persisted.
2. The usage of session scoped objects between the old version and the new is compatible.
3. The usage of application scoped objects between the old version and the new is compatible.
4. Database schema changes are not required.

Resin allows you to have a backup instance running. The idea is that this backup instance of Resin takes over if your primary Resin instance goes down.

If you are using a load balancer to distribute your load to multiple primary servers, each primary server has a backup server.

You can use this feature to deploy to a live server without interruption of service.

1. shutdown primary server(s) (backup server(s) takes over)
2. deploy new war to primary server(s)
3. start primary server(s). As soon as the primary server starts, the user will be using the new version of the application.
4. deploy new war to backup server(s)

Versioning and Graceful Upgrades

Deployment Methods

Filesystem deployment: Custom web-app with .war file

In this scenario, you want to configure a web-app with a specific root-directory and specify the location of the .war file. As usual, when Resin sees any changes in the .war file, it will expand the new data into the root-directory and restart the web-app. This capability, gives sites more flexibility where their directories and archive files should be placed, beyond the standard webapps directory.

The optional archive-path argument of the <web-app> will point to the .war file to be expanded.

<resin xmlns="http://caucho.com/ns/resin">
  <cluster id="">
    <host id="">

      <web-app id="/foo" root-directory="/var/resin/foo"
               expand-preserve-fileset="WEB-INF/work/**"
               archive-path="/usr/local/stage/foo.war"/>

    </host>
  </cluster>
</resin>

Command-Line Remote Deployment

The "deploy" command deploys a .war file to the default virtual host. In a cloud environment, Resin will copy the deployed .war to all servers in the cluster. Since the com.caucho.security.AdminAuthenticator requires a user and password, you'll need to pass those arguments.

unix> resinctl deploy hello.war \
           -user foo -password test

Browser-based Remote Deployment

As of Resin 4.0.0, it is now possible to deploy web applications remotely to a shared repository that is distributed across the cluster. This feature allows you to deploy once to any triad server and have the application be updated automatically across the entire cluster. When a new dynamic server joins the cluster, the triad will populate it with these applications as well.

To deploy an application remotely:

1. log into the resin-admin console on any triad server. Make sure you are connecting over SSL, as this feature is not available over a non-encrypted channel.
2. Browse to the "webapp" tab of the resin-admin server and at the bottom of the page, enter the virtual host, URL, and local .war file specifying the web application, then press "Deploy".
3. The application should now be deployed on the server. In a few moments, all the servers in the cluster will have the webapp.