Contents
This topic introduces the concepts in the deployment and promotion of API Gateway configuration. A typical enterprise-level customer will have several environments through which an API Gateway configuration will move from development to production. For example, this typically includes completely separate development, testing, and production domains. Promotion refers to the act of moving API Gateway configuration from one environment to another, and configuring environment-specific values so that the configuration can be deployed in each environment. For details on general API Gateway concepts, see the API Gateway Concepts Guide.
API Gateway supports a range of different operating systems (for example, Windows, Linux, and Unix). This means that API Gateway configuration can be promoted and deployed across environments running on different operating systems. For details on supported platform versions, see the API Gateway Installation Guide.
In a typical environment topology, each environment is implemented as a completely separate API Gateway domain. The exact mapping of environments to domains is determined by how each environment is administered, and which users have access rights.
Environments are distinct administrative entities in which only certain users have the privileges to perform operations. For example, only Production Operations staff have access to the Production environment. In the API Gateway architecture, a domain is a distinct administrative entity for managing groups of API Gateways. For example, the Production environment is implemented as a distinct Production domain to which only Production Operations staff have access.
In the following diagram, each environment is implemented as a distinct API Gateway domain. Developers work in their own Development environments, and then promote their API Gateway configurations to a central Testing team that performs testing in a single Testing environment. When testing is complete, the Testing team promotes the API Gateway configurations to the Production Operations team for deployment in the Production environment. Development, Testing, and Production Operations teams have access to their respective environments only. Therefore, each environment should be implemented as a distinct domain.
The API Gateway configuration is deployed to a group of API Gateways. Therefore, each domain consists of the required API Gateway groups to run the configurations. In the following diagram, the Development and Testing teams work in the same environment with common access to all API Gateway configurations. Therefore, in this case, there is a single domain for all the Development and Testing API Gateway groups.
![[Note]](../common_oracle/images/admon/note.png) |
Note |
|---|---|
|
The API Gateway does not mandate a specific environment-to-domain configuration, and is flexible enough to work with any architecture. However, you should manage your environments in an environment and domain topology. Implementing each environment as a distinct API Gateway domain is a good starting point. |
In a multi-environment topology, promotion refers to physically moving an API Gateway configuration between environments. For example, this may involve using FTP to transfer a configuration file, or loading and retrieving the file in a Configuration Management (CM) repository. In addition, promotion involves configuring environment-specific settings for the target environment (for example, users, certificates, and external connections to third-party systems). This is known as environmentalization.
Promotion typically involves two distinct tasks performed by different user types:
-
In the downstream Development environment, the policy developer prepares the configuration for promotion to upstream environments (for example, Testing and Production). This involves deciding what settings are environment-specific, and assumes expertise in policy development and configuration tools such as Policy Studio.
-
The upstream user takes the configuration prepared by the policy developer, creates the environment-specific configuration, and deploys it. This is typically performed by an API Gateway administrator in upstream environments. The Configuration Studio tool used for this promotion step is designed for the skills of upstream administrators, and does not assume expertise in policy development and configuration.
Deployment refers to deploying configuration to an API Gateway group in a local domain. For example, you can deploy using the following tools:
-
Policy Studio in a Development environment
-
API Gateway Manager in a Testing environment
-
Scripts in a Production environment (for example,
managedomainor a custom script)
For more details, see API Gateway Deployment and Promotion Tasks.
API Gateway configuration consists of the following types of information:
These component configuration types are described as follows:
| Configuration Type | Description | Environment Specific |
|---|---|---|
| Policy | Policy rule definitions and configuration | Some may be environment specific |
| Listener | Configuration for listeners used by policies (for example, for HTTP, JMS, or TIBCO) | Some environment specific |
| External Connection | Settings for external configuration (for example, Database Connection or Authentication Repository) | Some environment specific |
| Certificate | Security certificates and keys used by policies | All environment specific |
| User | Local username/password store for API client authentication | All environment specific |
| Environment Setting | Environment-specific settings for environmentalized configuration in the policy, listener, and external connection configuration | All environment specific |
| Package Property |
Name-value pairs used to describe the contents of the configuration
package (for example, Version, ID, or
Timestamp).
|
Some environment specific |
The API Gateway deployment and promotion tools bundle the API Gateway configuration into the following configuration package files:
| Package | Description | Used When |
|---|---|---|
Deployment Package (.fed)
|
Contains all API Gateway component configuration (policy, listener, external
connection, user, certificate, and environment setting). Implemented as a
.fed file. This contains all the data that would be contained
in separate policy and environment packages combined.
|
Used by the policy developer in Policy Studio during the iterative development cycle to deploy all configuration. For more details, see the section called “Deploying in a Development Environment”. |
Policy Package (.pol)
|
Contains the policy, listener, external connection, and environment setting
configuration. Implemented as a .pol file. The environment settings
in the .pol file contain a list of what has been environmentalized
in the policy, listener, and external connection configuration. It does not
contain the environment-specific values.
|
Used when promoting APIs and policy configuration to upstream environment for example, testing or production). Its contents remain unchanged in the upstream environment. For more details, see the section called “Environmentalizing Configuration”. |
Environment Package (.env)
|
Contains the user, certificate, and environment setting configuration.
Implemented as an .env file. The environment settings in
the .env file contain a list of what has been environmentalized
in the policy, listener, and external connection configuration, along with the
environment-specific values.
|
Environment-specific settings used in upstream environments only (for example, testing or production). For more details, see the section called “Promoting Upstream (First Cycle)”. |
The combined contents of the policy package and environment package are equivalent to the contents of the deployment package, which contain all API Gateway configuration:
For more details on package properties, see Configuring Package Properties.
