Automatic Package Deployment

Automatic package deployment allows Microservices Runtime to install or upgrade packages automatically. When automatic package deployment is enabled, packages can be installed or upgraded without using Deployer or an administrator tool such as, Microservices Runtime Administrator. Automatic deployment can be used with an on-premises Microservices Runtime and an Microservices Runtime that runs inside a Docker container.

Automatically deploying packages can be particularly useful for a Microservices Runtime that runs in a Docker container. Instead of creating the Docker image containing individual Packages, creating a base image containing Default package can be used to bring in custom packages. Packages to be installed or updated on the container can be placed in an autodeploy directory that Microservices Runtime periodically scans. Microservices Runtime will find and install the new or updated packages. If you do not use automatic deployment, you must rebuild the Docker image to use any new or updated packages with Microservices Runtime container.

Note: The automatic package deployment feature is available by default for a webMethods Microservices Runtime. To use the automatic package deployment feature with Integration Server, your Integration Server must have additional licensing.

How Automatic Package Deployment Works

In automatic package deployment, the packages that you want Microservices Runtime to deploy automatically are placed in a location that Microservices Runtime periodically scans for new or updated custom packages. Microservices Runtime executes a system task named “Auto Package Deployer” that scans the folder and checks for new or updated custom packages. When Microservices Runtime finds new or updated custom packages, Microservices Runtime does one of the following:

  • For a new package, Microservices Runtime installs, archives, and activates the package.

  • For an updated custom package, Microservices Runtime does one of the following:

    • If hot deployment is enabled for automatic package deployment, Microservices Runtime uses the block-and-wait approach employed by hot deployment to deploy the package. This ensures that Microservices Runtime assets are available for processing without any noticeable downtime. For more information about how hot deployment works, see webMethods Integration Server Administrator’s Guide

    • If hot deployment is not enabled, Microservices Runtime unloads the existing package information from memory and loads the new version of the package and its contents into memory. While the package is being upgraded, it is possible that some assets might be unavailable for some time. This could cause serious issues such as denial of service or disruption of the in-flight tasks.

Hot deployment is enabled for automatic package deployment if either of the following is true:

  • Hot deployment is enabled globally for the Microservices Runtime. Hot deployment is enabled globally when the Enabled field is set to Yes on the Settings > Hot Deployment page.
  • Hot deployment is enabled for automatic package deployment when the watt.server.autodeploy.alwaysUseHotDeployment server configuration parameter is set to true.

By default, the automatic package deployment feature is disabled in Microservices Runtime. To enable automatic package deployment or configure other aspects of hot deployment, such as the system task execution frequency, see the section Enabling and Configuring Automatic Package Deployment .

Determining Package Dependencies During Automatic Deployment

If you are deploying new package or updated custom packages and it has new dependent packages, you have to deploy the dependent packages too in the autodeploy folder. If you are deploying a new package or updated custom packages with existing dependent packages that are already deployed, then Microservices Runtime activates the new package. If you are deploying a new or updated custom packages with missing package dependencies the activation will fail. Also, if you are using hot deployment then you should identify package dependencies correctly. For more information see webMethods Integration Server Administrator’s Guide.

Considerations for Auto Deployment of Packages

Before you configure automatic package deployment in Microservices Runtime, keep the following behavior limitations and considerations in mind.

  • You cannot cancel an in-progress automatic package deployment operation.
  • If the watt.server.autodeploy.alwaysUseHotDeployment parameter is set to true. Microservices Runtime performs hot deployment for the installation of any custom package regardless of whether it is a new package or an upgraded package. For more information on hot deployment, see Enabling and Configuring Automatic Package Deployment.
  • If you are deploying new package and it has new dependent packages, you have to deploy all at once in the autodeploy folder.
  • If you use hot deployment for automatic package deployment, all of the hot deployment considerations apply to automatic package deployment as well. For more information about hot deployment considerations, see Enabling and Configuring Automatic Package Deployment.
  • When hot deployment is used for automatic package deployment, Microservices Runtime uses the configured hot deployment values. For more information about configuring hot deployment, see Enabling and Configuring Automatic Package Deployment.

Enabling and Configuring Automatic Package Deployment

About this task

Microservices Runtime uses various configuration settings for automatic package deployment of new and updated packages. Most of the settings have defaults. You can change these setting by using the Settings > Extended screen of the Integration Server Administrator as described below.

To configure automatic deployment for Microservices Runtime

Procedure

  1. In the Microservices Runtime Administrator, under Settings, click Extended.
  2. Click Edit Extended Settings.
  3. If the watt.server.autodeploy.alwaysUseHotDeployment, watt.server.autodeploy.enabled, and watt.server.autodeploy.interval parameters do not appear the Extended Settings list, do the following:
    1. Select Show and Hide Keys.
    2. Select the check boxes next to the watt.server.autodeploy.alwaysUseHotDeployment, watt.server.autodeploy.enabled, and watt.server.autodeploy.interval parameters.
    3. Click Save Changes.
  4. On the Settings > Extended page, click Edit Extended Settings.
  5. Set the following server configuration properties in Microservices Runtime.
    For this extended setting Description
    watt.server.autodeploy.
    enabled=true
    		 Enables automatic package deployment .
    watt.server.autodeploy.
    alwaysUseHotDeployment=true
    		 Use hot deployment for automatic deployment of packages.
    watt.server.autodeploy.interval=5
    		Specifies the interval, measured in minutes, at which Microservices Runtime executes the autodeploy system task.
  6. Click Save Changes.
  7. Restart the Microservices Runtime.

    The updated settings are now in effect.

Automatic Package Deployment Location

Where you place custom packages for automatic package deployment depends on whether you are using an on-premises Microservices Runtime or an Microservices Runtime running in a Docker container.

  • For an on-premises Microservices Runtime, place packages that you want automatically deployed in this location:

    Integration Server_directory \replicate\autodeploy folder.

    Note: For an on-premise Integration Server with a Microservices license, place packges that you want automaticaly deployed in this location: Integration Server_directory \instances\instance_name\replicate\autodeploy
  • For a Microservices Runtime or Integration Server running a Docker container, when you start the Docker container, you can map the above folder of a container to a volume which points to a folder on your HOST machine. You can then place packages that you want to the server to automatically deploy in the folder specified by the volume.