Skip to main content

Managing the Applications Lifecycle

 

OutSystems

Deployment Zones Reference

Each deployment zone has the following parameters:

Name

The name that identifies the deployment zone. This name will appear in several places in the UI, so it should be meaningful of what it represents.

Examples: Business backend, Services, Core factory, Intranet

Description
The purpose of the deployment zone. You can use this field to store any relevant information to better understand how the zone is used and what kind of applications should be added to it.
Is Default for new eSpaces
Boolean parameter that, when active, states that the current deployment zone is the default deployment zone. You can set a deployment zone as the default one by clicking "Set as Default".
Internal Address

Internal address for all applications living in the deployment zone. When applications in other deployment zones need to refer applications living in this deployment zone (and don't want to use the environment URL), they will use this address. Learn how this address must fit in your network architecture in Recommended Network Architecture.

The platform installation must be able to access this address on ports 80 and 443. Anything living in this deployment zone must be able to reach the platform installation on the port defined for the Deployment Controller Service (by default, 12000).

This address must be a valid machine domain name or IP address, and it cannot have a port.

Valid examples: 192.168.42.23, intranet.mydomain.com, rincewind.lan

Invalid examples: 192.168.42.23/site, 192.168.42.23:8080/site, rincewind.lan/university

Use HTTPS for internal communications
Boolean parameter that, when active, will cause all internal environment communications to use the HTTPS protocol.
Hosting Technology

Refers to the type of technology on which all applications in this zone will run on. Available options are: Classic Virtual Machines, Docker Containers, Amazon ECS, Azure Container Service and Pivotal Cloud Foundry.

The following options are container-based hosting technologies: Docker Containers, Amazon ECS, Azure Container Service and Pivotal Cloud Foundry.

The following options are Docker-based container technologies: Docker Containers, Amazon ECS and Azure Container Service.

Includes all Servers
Boolean parameter that, when active, will make the platform automatically include all servers in the current deployment zone, including those added at a later date. When this parameter is active you will not be able to manually add or remove servers from the deployment zone.

The following fields are only applicable to some of the hosting technologies available:

Deployment Mode

Applies to: All container-based hosting technologies.

Refers to the type of deployment that will be performed in this deployment zone: Automatic or Manual.

In automatic deployments, in addition to all the required manual deployment parameters you must also define trigger URLs to connect the different OutSystems deployment steps with specific tasks on your automated deployment tool of choice.

Output Files To

Applies to: All container-based hosting technologies.

A file-system location where the platform will put all the artifacts (a set of files) required to create the application container.

The provided location can be a path on the same machine where the platform is installed or a network share.

The user account used by OutSystems services (usually Local Service) must have read/write permissions on this location.

Examples: C:\users\eskerina\container-bundles, \\twoflower\luggage

NOTE: A C:\ path (or similar) refers to a location in the same machine where the platform is installed. If the specified directory does not exist, it will be created when the application is published in this zone.

Result

Applies to: All container-based hosting technologies.

A file-system location where the platform expects you to put a result file with a well-known structure to signal that either the container with the application is running and can be accessed, or the deployment has failed.

The provided location can be a path on the same machine where the platform is installed or a network share. It can be the same folder that was configured in the previous parameter.

The user account used by the OutSystems services (usually Local Service) must have read permissions on this location.

Examples: C:\users\eskerina\container-results, \\twoflower\luggage

NOTE: Any C:\ path (or similar) refers to a location in the same machine where the platform is installed.

Output Config Files to

Applies to: All container-based hosting technologies.

A file-system location where the platform will place the unified configuration file required for both the application and the Application Scheduler Service living inside the container. Each application will have its own sub-folder inside the provided path.

The provided location can be a path on the same machine where the platform is installed or a network share. The user account used by the OutSystems services (usually Local Service), must have read/write permissions on this location.

Examples: C:\users\eskerina\container-configs, \\twoflower\luggage

Note: Any C:\ path (or similar) refers to a location in the same machine where the platform is installed. If the specified directory does not exist, it will be created when the application is published in this deployment zone.

From Image

Applies to: All Docker-based hosting technologies.

The base image on which the containers for this deployment zone will be built upon. This parameter provides an extensibility point to use your own base images instead of the default (and recommended) one. This parameter matches the FROM directive used in Dockerfiles.

The default (and recommended) image is microsoft/iis:latest.

If you want to use your own image, you can do so as long as it includes Windows Server Core and IIS.

Example: microsoft/iis:latest

Note: the word latest in the image name is just a convention with no special meaning. You may refer to any version of an image other than the latest one.

While having a central registry is not a requirement, it is highly recommended that you set up your infrastructure so that the base image specified for the containers of a deployment zone is available for use by the container runtime before you start a deployment. This will significantly decrease the amount of time required to build container images for OutSystems applications.

Check the Docker registry requirements.

Automatic Deployment Fields

The following fields are only applicable when using "Automatic" deployment mode with container-based hosting technologies:

Container Build Trigger URL

URL called during application deployment in the "Preparing Deploy" step. The platform will make an HTTP "GET" request to the configured URL expecting a 2xx OK response.

The trigger URL handler must be synchronous and should respond as soon as possible stating that the task has started. The deployment will not proceed until a .preparedone result file is created in the "Result" folder, stating that the "Preparing Deploy" step was completed.

During this stage you can automate operations like docker image build (for Docker-based hosting technologies) or cf push --nostart (for Pivotal Cloud Foundry) since all container artifacts will be available and ready for use.

The following parameters will be appended to the URL query string:

  • Address: Configured internal address for the deployment zone.
  • ApplicationName: Name of the application being deployed.
  • ApplicationKey: Application key identifier used to identify the generated ZIP bundle, along with OperationId.
  • OperationId: A GUID representing the publish operation. Different deployments will have different Ids.
  • TargetPath: Path where the bundle is available.
  • ResultPath: Path where the result files should be placed.
  • ConfigPath: Path where the application configurations file exists.

All the values of these query string parameters will be serialized in Base64 encoding.

The filename of the application bundle ZIP file created by the platform in "TargetPath" is defined in the following manner:

<ApplicationKey>_<OperationId>.zip

The filename of the result file for this stage, expected at "ResultPath", is the following:

<ApplicationKey>_<OperationId>.preparedone

Container Run Trigger URL

URL called during application deployment in the "Deploying" step. The platform will make an HTTP "GET" request to the configured URL expecting a 2xx OK response.

The trigger URL handler must be synchronous and should respond as soon as possible stating that the task has started. The deployment will not proceed until a .deploydone result file is created in the "Result" folder, stating that the "Deploying" step was completed.

During this stage you can automate operations like docker run (for Docker-based hosting technologies) or cf start (for Pivotal Cloud Foundry). The database metamodel will already be upgraded, so it’s the ideal stage to spin up the new version of the application, stop the old version and change any routing rules.

The same set of query string parameters presented in the previous field will be appended to this trigger URL.

The filename of the result file for this stage, expected at "ResultPath", is the following:

<ApplicationKey>_<OperationId>.deploydone

Update Configurations Trigger URL

URL called whenever the application configuration file changes. The platform will make a an HTTP "GET" request to the configured URL expecting a 2xx OK response.

The trigger URL handler must be synchronous and should respond as soon as possible stating that the task has started. The deployment will not proceed until a .configsdone result file is created in the "Result" folder stating that the "Update Configs" step was completed.

During this stage you can automate operations like:

  • For Docker-based hosting technologies: Copying the configuration file generated in the "Output Config Files to" folder to the folder that was mounted in the Docker container. If the mounted folder is the same and no copy is needed, the trigger URL handler can simply create the .configsdone file in the "Result" folder.

  • For PCF hosting technology: Copying the configuration file generated in the "Output Config Files to" to the bundle config folder and do a cf push to update the application with the new configurations.

The same set of query string parameters presented in the "Container Build Trigger URL" field will be appended to this trigger URL.

The filename of the result file for this stage, expected at "ResultPath", is the following:

<ApplicationKey>_<OperationId>.configsdone

Container Remove Trigger URL

URL called whenever a container-deployed application can be removed. This will happen in the following situations:

  • The original application name changed;
  • The application was removed;
  • The application changed to a different deployment zone.

The platform will make an HTTP "GET" request to the configured URL expecting a 2xx OK response. The trigger URL handler must be synchronous and should respond as soon as possible stating that the task has started. The removal process will not proceed until a .undeploydone result file is created in the "Result" folder stating that the "Undeploy" step was completed.

During this stage you can automate operations like docker rm (for Docker-based hosting technologies) or cf delete (for Pivotal Cloud Foundry).

The same set of query string parameters presented in the "Container Build Trigger URL" field will be appended to this trigger URL.

The filename of the result file for this stage, expected at “ResultPath”, is the following:

<ApplicationKey>_<OperationId>.undeploydone

You can change almost all parameters about a deployment zone, except for the "Hosting Technology" when the zone has modules/applications associated with it. Some changes to deployment zones settings will require you to republish your applications to be effective. You may also have to republish the consumers of your applications.

  • Was this article helpful?