Layer7 API Developer Portal - 4.5

PDF
index saas 5.0 4.5 4.4 4.3.2 4.3.1 4.2 4.1 4.0
English

API Deployment Types

API deployment types allow administrators and API owners to control how APIs are deployed to a proxy. You select the API deployment type when adding proxies.
For more information about how to add a proxy, see Integrate On-Premise API Proxies.
You cannot edit the deployment type after the API is deployed to the proxy.
The API Details page displays the API deployment information on the
Deployments
 tab. The following graphic displays the Details page of API deployment information for different deployment types and proxies:
Proxies support the following deployment types:
  • Automatic
    For this deployment type, published APIs are immediately and automatically deployed to proxies.
  • On-demand
    For these event-driven deployments, the deployment is triggered when a user with deployment permissions makes calls to Apideployments resources in the Portal API. For example, this deployment type is useful when you want to stagger the deployment of an API across all or your geographic regions to avoid impacting production instances during peak hours.
    To use this deployment type, you must install and enable the Portal Deployer modular assertion on the proxy during the enrollment or upgrade process.
  • Scripted
    Custom scripts that you create trigger scripted deployments, which invokes the deployment APIs. Deployment APIs retrieve API deployment data and update the API deployment status for a proxy to keep the API Portal updated.
    To use this deployment type, you must install and enable the Portal Deployer modular assertion on the proxy during the enrollment or upgrade process.
On-demand and scripted deployments are available only for Portal-published APIs.
The following table displays more information about deployment types:
Deployment Type
Effect on API Deployments
Use Case
Execution Method Used
Note
Automatic
Changes to APIs are automatically deployed to the proxy. For example, whenever an API is created, edited, or deleted.
Backwards compatibility for retaining current deployment model and Gateway-published APIs.
This deployment type is recommended for the following use cases:
  • Rapid iteration of API development
  • Convenience and low maintenance
  • Development environments
UI and API call.
The API count displays for the Portal and the proxy on the API Proxy Details page because the APIs are automatically deployed to the proxy.
If you do not use the automatic deployment type for a proxy, the APIs are not synched to and from that proxy regardless of where they were created.
Gateway-published APIs
must
 use the automatic deployment type because they rely on the synchronized scheduled task to synchronize them from the proxy to the Portal.
To enable automatic deployment of Gateway-published APIs, you must enable migration between environments or clusters using Gateway Migration Utility (GMU). For more information, see the following links:
On-Demand
You can trigger API deployments on-demand by calling the Deployment API.
Deployments are triggered when a user with deployment permissions makes calls to the Apideployments resource in the Portal API.
On-demand deployments only apply to Portal-published APIs.
On-demand is recommended for the following use cases:
  • Deployments that are triggered as needed
  • Geographically distributed environments
  • UAT environments
For example, you want to stagger the deployment of an API across all or your geographic regions to avoid impacting production instances during peak hours.
UI and API call.
Deployment APIs to orchestrate and trigger the deployment process.
The API Proxy Details page displays only the APIs that have been created on the Portal and not the APIs that have been deployed to a proxy.
Scripted
You can integrate API deployments into your existing Continuous Integration/Continuous Deployment (CI/CD) process by using the deployment APIs and invoking them from your deployment script.
Deployments are triggered by the script in conjunction with the deployment APIs which are used to retrieve the API deployment data and update the API deployment status for a proxy.
Scripted deployments apply only to Portal-published APIs.
Scripted is recommended for the following use cases:
  • Integrations with existing CI/CD pipeline
  • Environments that are tightly controlled
  • Production environments
For example, you want control over when an API is deployed using a custom script in conjunction with the Deployment APIs.
UI and API call.
Restman used to deploy to proxy.
Deployment APIs and custom script to orchestrate and trigger the deployment process.
API Proxy Details page displays only the APIs that have been created on the Portal and not the APIs that have been deployed to a proxy.
More information:
Deployment Actions