Deploy the Authoring and Delivery Web Applications Separately

Introduction

Goal

Deploy the authoring and delivery applications in separate containers.

Background

Typically Hippo's authoring (cms) and delivery (site) applications are deployed together on the same server. The delivery application has access to the repository which is hosted by the authoring application. However there are use cases where deploying the authoring and delivery applications separately on different application servers is preferable. For example you may want to deploy the delivery application on multiple servers to increase availability. In these cases the delivery application is deployed without the authoring application, therefore it cannot access the repository hosted by the latter.

The solution is to package the content repository as a separate web application and deploy it together with the delivery application. The repository webapp will provide for access from the delivery application to the underlying storage repository.

Requirements

• The content repository must be backed by a supported database and configured for clustering. See Configure Hippo for your Database Server for sample configurations for supported databases.
• The authoring cluster must be started before the delivery cluster.

Deployment

The project should be delivered as two separate distributions for the authoring and delivery applications. These two tar.gz files contain the web applications for each server. Deploy the cms and site WARs to the first server, and the site and repository WARs to the second.

Take special care to:

• Specify the location of your repository.xml on both servers. This is done with the system property repo.config as mentioned in Configure the Application Server (Apache Tomcat on Linux).

• Disable bootstrapping on the delivery server (-Drepo.bootstrap=false).

  Always start up the container hosting the delivery application (site.war) with bootstrapping disabled, i.e. with -Drepo.bootstrap=false.
  If you would enable bootstrapping for the delivery application, the following undesirable scenario would unfold:
  The bootstrap process removes all initialization items from the repository that it can't find on the classpath; because you have a limited set of artifacts on the repository classpath, a lot of initialize items will be removed; next time you start up the authoring node, where these initialization items are on the classpath, the bootstrap process will replay those initialize items because it can't find them in the repository anymore. The result is that you end up with duplicate content and configuration all over the place.

• Make sure the authoring clusters are started before starting the delivery clusters.

Disabling Scheduled Jobs on the Delivery Nodes

By default all repository instances perform scheduled tasks in a clustered repository setup. Scheduled tasks are amongst others: scheduled (de-)publications, repository maintenance jobs, checking for brokenlinks, etc. In case you want to be sure that these actions do not run on the delivery nodes, you can disable this behaviour by adding the following directive to the startup script of the application container.

-Dhippo.scheduler.disabled=true