You are currently viewing Zend Server 5.x documentation. Click here to view the latest Zend Server online documentation.

You are here: Zend Server User Guide > Concepts > Applications Tab > Understanding the Package Structure

Understanding the Package Structure

Your .zpk package contains the data, scripts, and an XML descriptor file for your application.

Data - Your application (all the source code files of your application).
Descriptor File - This XML file, which is defined by an XSD file, describes all necessary information in order to deploy your application using Zend Server’s deployment feature. For an example of the descriptor template see The XML Descriptor File.
It contains three parts:

name - (Required) The application's name.
summary - The application's short description.
description - The application's long description.
version - (Required) The application's version number.
eula - The EULA file.
appdir - (Required) The applications directory. By default, this is the data folder of your package.
docroot - The alias will point to the directory you specify.
scriptsdir - The directory in which your scripts are located. By default, this is the scripts folder of your package.
healthcheck - Add the relative URL you would like Zend Server to check against for Application Health Check. This checks if the URL returns a 200 (OK) response or an error response.
variables - Define environment variables for the deployment scripts.

Dependencies which need to be satisfied in order for the application to function correctly. For example, PHP version and PHP directive values.
User parameters that are required for the application’s deployment. For example, database name. These, along with the values you define, will appear in the User Parameters dialog during deployment. For more information see Deploying an Application.

Scripts (PHP hook scripts) - Zend Server deployment consists of six actions: two for deployment, and two for removal. Two hook scripts are provided for each action (pre and post), allowing you to customize the actions according to your needs. You can select from a list of available hook script constants to insert in the scripts.

Stage - Place the contents of the .zpk application package on the server or on the cluster nodes.

Pre-stage - All customized actions that must be executed before the staging process begins.
Post-stage - All customized actions that must be executed after the staging process ends.

Activate - Perform the final steps necessary to make a staged application public.

Pre-deactivate - All customized actions that must be executed before deactivation.
Post-deactivate - All customized actions that must be executed after deactivation.

Un-stage - Cleans up your server and deletes any files that were relevant only to the now deactivated application.

Pre-unstage - All customized actions that must be executed before the un-staging process begins.
Post-unstage - All customized actions that must be executed after the un-staging process is completed.

See Preparing the Package Using the Deployment Tool to learn how to build your application package.

Hook Script Examples

The following is a list of examples of operations that may be defined in each hook script:

Pre-stage - Validate and applying user customized parameter values, verify the existence of generic prerequisites, etc.
Post-stage - Create a new database schema, modify a file or directory permissions on staged source files, etc.
Pre-activate - Upgrade an existing database schema, etc.
Post-activate - Remove a temporary banner ("Down for Maintenance"), reset a cache, etc.
Pre-rollback - Return configuration files or the database to their previous verstion, etc.
Post-rollback - Take the site out of maintenance mode, return the load balancer settings, etc.
Pre-deactivate - Put up a banner ("Down for Maintenance") for the previous version, etc.
Post-deactivate - Modify external configuration files, etc.
Pre-unstage - Back up specific applications files such as audit logs and other data files, etc.
Post-unstage - Clean up external files referencing the application (which are no longer needed), etc.

The following is a list of the available dynamic values that can be used by the deployment hook scripts:

ZS_APPLICATION_BASE_DIR - Contains the directory to which the application is deployed
ZS_CURRENT_APP_VERSION - In case an upgrade was performed, contains the version number of the current application
ZS_PHP_VERSION - Contains the PHP version that Zend Server uses
ZS_PREVIOUS_APP_VERSION - In case a rollback was performed, contains the previous version of the application
ZS_PREVIOUS_APPLICATION_BASE_DIR = In case a rollback was performed, contains the directory to which the application was deployed
ZS_RUN_ONCE_NODE - When deploying in Zend Server Cluster Manager, a single node ID is chosen to perform actions that only need to be done once. If the value of this constant is set to ‘1’ during deployment, the node is defined as the ‘run once node’
ZS_WEBSERVER_GID - Contains the web server user group ID (UNIX only)
ZS_WEBSERVER_TYPE - Contains a code representing the web server type (APACHE)
ZS_WEBSERVER_UID - Contains the web server user ID (UNIX only)
ZS_WEBSERVER_VERSION - Contains the web server version (2.2)
ZS_BASE_URL = Contains the base URL set for deployment