此内容没有您所选择的语言版本。

Chapter 4. Mapping API environments in 3scale

An API provider gives access to the APIs managed through the 3scale Admin Portal. You then deploy the API backends in many environments. API backend environments include the following:

Different environments used for development, quality assurance (QA), staging, and production.
Different environments used for teams or departments that manage their own set of API backends.

A Red Hat 3scale API Management product represents a single API or subset of an API, but it is also used to map and manage different API backend environments.

To find out about mapping API environments for your 3scale product, see the following sections:

4.1. Product per environment

This method uses a separate 3scale Product for each API backend environment. In each product, configure a production gateway and a staging gateway, so the changes to the gateway configuration can be tested safely and promoted to the production configuration as you would with your API backends.

Production Product => Production Product APIcast gateway => Production Product API upstream
Staging Product => Staging Product APIcast gateway => Staging Product API upstream

Configure the product for the API backend environment as follows:

Create a backend with a base URL for the API backend for the environment.
Add the backend to the product for the environment with a backend path /.

Development environment

Create development backend
- Name: Dev
- Private Base URL: URL of the API backend
Create Dev product
- Production Public Base URL: https://dev-api-backend.yourdomain.com
- Staging Public Base URL: https://dev-api-backend.yourdomain.com
- Add Dev Backend with a backend path /

QA environment

Create QA backend
- Name: QA
- Private Base URL: URL of the API backend
Create QA product
- Production Public Base URL: https://qa-api-backend.yourdomain.com
- Staging Public Base URL: https://qa-api-backend.yourdomain.com
- Add QA Backend with a backend path /

Production environment

Create production backend
- Name: Prod
- Private Base URL: URL of the API backend
Create Prod product
- Production Public Base URL: https://prod-api-backend.yourdomain.com
- Staging Public Base URL: https://prod-api-backend.yourdomain.com
- Add production Backend with a backend path /

Additional resources

For more information about the 3scale product, see First steps with 3scale.

4.2. 3scale On-premises instances

For 3scale On-premises instances, there are multiple ways to set up 3scale to manage API backend environments.

A separate 3scale instance for each API backend environment
A single 3scale instance that uses the multitenancy feature

4.2.1. Separating 3scale instances per environment

In this approach a separate 3scale instance is deployed for each API backend environment. The benefit of this architecture is that each environment will be isolated from one another, therefore there are no shared databases or other resources. For example, any load testing being done in one environment will not impact the resources in other environments.

Note

This separation of installations has benefits as described above, however, it would require more operational resources and maintenance. These additional resources would be required on the OpenShift administration layer and not necessarily on the 3scale layer.

4.2.2. Separating 3scale tenants per environment

This approach uses a single 3scale instance, but the multitenancy feature is utilized to support multiple API backends.

There are two options:

Create a 1-to-1 mapping between environments and 3scale products within a single tenant.
Create a 1-to-1 mapping between environments and tenants with one or more product per tenant as required.
- There would be three tenants corresponding to API backend environments - dev-tenant, qa-tenant, prod-tenant. The benefit of this approach is that it allows for a logical separation of environments but uses shared physical resources.

Note

Shared physical resources will ultimately need to be taken into consideration when analysing the best strategy for mapping API environments to a single installation with multiple tenants.

4.3. 3scale mixed approach

It is possible to combine approaches described in 3scale On-premises instances. For example:

A separate 3scale instance for production.
A separate 3scale instance with separate tenant for non-production environments in development and QA.

4.4. 3scale with APIcast gateways

For 3scale On-premises instances, there are two alternatives to set up 3scale to manage API backend environments:

Each 3scale installation comes with two embedded APIcast gateways, for staging and production.
Deploy additional APIcast gateways externally to the OpenShift cluster where 3scale is running.

4.4.1. Embedded APIcast default gateways

When embedded APIcast gateways are used, the API backend configured using the above approaches described in 3scale with APIcast gateways are handled automatically. When a 3scale Master Admin adds a tenant, a route is created for the tenant in production and staging embedded APIcast gateways. See Understanding multitenancy subdomains

<API_NAME>-<TENANT_NAME>-apicast.staging.<WILDCARD_DOMAIN>
<API_NAME>-<TENANT_NAME>-apicast.production.<WIDLCARD_DOMAIN>

Therefore, each API backend environment mapped to a different tenant would get its own route. For example:

Developer: <API_NAME>-dev-apicast.staging.<WILDCARD_DOMAIN>
QA: <API_NAME>-qa-apicast.staging.<WILDCARD_DOMAIN>
Production: <API_NAME>-prod-apicast.staging.<WILDCARD_DOMAIN>

4.4.2. Additional APIcast gateways

Additional APIcast gateways are those deployed on a different OpenShift cluster than the one on which 3scale instance is running. There is more than one way to set up and use additional APIcast gateways. The value of environment variable THREESCALE_PORTAL_ENDPOINT used when starting APIcast depends how the additional APIcast gateways are set up.

You can configure a separate APIcast gateway for each API backend environment. For example:

DEV_APICAST -> DEV_TENANT ; DEV_APICAST started with THREESCALE_PORTAL_ENDPOINT = admin portal for DEV_TENANT
QA_APICAST -> QA_TENANT ; QA_APICAST started with THREESCALE_PORTAL_ENDPOINT = admin portal for QA_APICAST
PROD_APICAST -> PROD_TENANT ; PROD_APICAST started with THREESCALE_PORTAL_ENDPOINT = admin portal for PROD_APICAST

The THREESCALE_PORTAL_ENDPOINT is used by APIcast to download the configuration. Each tenant that maps to an API backend environment uses a separate APIcast gateway. The THREESCALE_PORTAL_ENDPOINT is set to the Admin Portal for the tenant containing all the product configurations specific to that API backend environment.

It is possible to use a single APIcast gateway with multiple API backend environments. In this case THREESCALE_PORTAL_ENDPOINT is set to the Master Admin Portal.