Announcement: You can find the guides for Commerce 7.5 and later on the new Elastic Path Documentation site. This Developer Center contains the guides for Commerce 6.13.0 through 7.4.1.Visit new site

This version of Elastic Path Commerce is no longer supported or maintained. To upgrade to the latest version, contact your Elastic Path representative.

The Pusher - Architecture

The Pusher - Architecture

System requirements

The Pusher is single threaded and uses minimal memory (256 MB is is lots). However, the Pusher will use a lot of bandwidth to copy assets and artifacts, so the closer the deployer is to the target environment, the better.

Tip:

The recommended practice is to run the Pusher on a server that is on the same subnet as the target servers. This is especially important when deploying to a large server farm or applying a large volume of database updates.

Deployment scenarios

The Pusher can deploy Elastic Path applications according to the following common configurations:

  • Deploy locally (to the same machine where the deployment scripts reside)
  • Deploy to a single remote server. This includes all the EP applications as well as the database and JMS servers on the same remote server.
  • Deploy to multiple remote servers. This could be a single server with all the applications and a separate server for the database or a separate server for each application.
  • Deploy each application in a separate container (it's own Tomcat instance for example) on a single server.
  • Deploy each application in a separate container on multiple remote servers (a typical Production deployment.
  • Deploy a single application to a single server.
  • Update or deploy the database only.
  • Any combination of the above scenarios.

It can also deploy and install EP Commerce API and Geometrixx Demo store to AEM author or publish instance(s) with the configurations as described above.

Deployment process

The Pusher executes in 3 main phases:

  1. Setup: Read configuration files and unzip the deployment package into a workspace directory.
  2. Data population: Run data population using data from the workspace directory and configuration from the configuration directory.
  3. Server deployment: Deployment artifacts (webapps, assets, files, etc.) to each configured target server. Each type of artifact is associated with a separate deployment script in the the-pusher/extensions directory, allowing the deployment actions to be customized for each type of artifact. If the AEM deployment flag is set to true, it will also deploy EP artifacts to the target AEM author & publish instances.

the-pusher-deployment-process-Fall-2014-SP2

Target server layout

The exact way that the applications are deployed to the target servers will depend on your configuration file but some things will always be the same:

  • All EP artifacts are deployed to the $HOME/ep directory that you configured (e.g. /home/ep-user/ep)
  • The deployment script creates symlinks to the most recent appserver and asset versions, so you can easily roll back to the previous version if necessary. The number of versions to retain is configurable.
  • The contents of the configuration files directory are copied to $HOME/ep/.
  • Most application logs are located in the $HOME/ep/log directory.
  • Search indexes data are located in $HOME/ep/solrHome. The indexes will be rebuilt after every deployment.

Pusher configuration file

The Pusher configuration file controls Pusher behavior. You can execute the Pusher with multiple configuration files so you can group settings which are common across multiple environments into a single file.

Tip:

Use the sample configuration files in the the-pusher/configuration-examples directory as a starting point for defining your configuration.

There are examples for deploying all of the applications and the database, assets, etc. to a single server, a Production deployment example for deploying each application to a separate Tomcat container, and a clustered Search deployment using a master / slave Solr setup.

The deployment configuration examples are part of the documentation. Read the comments.

Configuration directory structure

The configuration directory contains the following Pusher and Data Population configuration objects.

Object Used by Description
files directory The Pusher Directory containing files to be copied to $HOME/ep/
database.properties

The Pusher & Data Population

 Database connection properties
data-population.properties Data Population Data Population configuration
filtering.properties Data Population Environment specific values used to filter placeholders in catalog data.

Deployment package structure

The deployment package is built by the extensions/packager project and contains the EP applications, tools, database schema and catalog data to be deployed as well as Tomcat and ActiveMQ installation packages. The same package can be deployed to multiple-environments without requiring any changes.

The structure of the current deployment package is below:

ext-deployment-package-<version>.zip
?? aemcomponents
?   ?? ep-commerce-api-<version>.zip
?   ?? ep-geometrixx-content-<version>.zip
?? database
?   ?? jdbc
?   ?   ?? [JDBC database drivers]
?   ?? core-schema-<version>.jar
?   ?? ext-data-<version>.jar
?? tools
?   ?? activemq
?   ?   ?? lib
?   ?       ?? apache-activemq-<version>.zip
?   ?       ?? [ActiveMQ Tomcat libraries]
?   ?? ep-data-population-cli-<version>-package.zip
?   ?? ep-importexport-cli-<version>-bin.zip
?? webapps
    ?? apache-tomcat-<version>.zip
    ?? commercemanager-<version>-macosx.cocoa.x86_64.zip
    ?? commercemanager-<version>-win32.win32.x86_64.zip
    ?? ep-rest-studio-<version>.war
    ?? ext-assets-<version>-assets.war
    ?? ext-cmserver-webapp-<version>.war
    ?? ext-cortex-webapp-<version>.war
    ?? ext-integration-webapp-<version>.war 
    ?? ext-search-webapp-<version>.war
    ?? ext-storefront-webapp-<version>.war