This document describes how to install and configure Apigee from the
command line
with VPC peering. These steps apply to both Subscription and Pay-as-you-go
pricing models for paid organizations with or without
data residency enabled.
Summary of steps
The provisioning steps are as follows:
Step 1: Define environment variables:
Set up gcloud and define environment variables.
The Google Cloud CLI manages authentication, local configuration,
developer workflow,and interactions with the Google Cloud APIs.
Step 2: Enable APIs: Apigee requires you to enable several
Google Cloud APIs.
Step 4: Configure service networking: Service networking
automates the private connectivity set up (using VPC Network Peering) between your network
and Apigee.
Step 5: Create an organization: An Apigee organization
(sometimes referred to as an org) is the top-level container in Apigee. It includes all of
your environments and environment groups, users, API proxies, and related resources.
Step 6: Create a runtime instance: An instance, or runtime
is where your project and related services are stored; it provides the user-facing endpoint
for your services.
Step 7: Create an environment: An API proxy must be
deployed to an environment, and added to an environment group, before the APIs it exposes
are accessible over the network.
Set up gcloud and define environment variables for use in later steps:
Be sure you have completed the setup requirements listed in
Before you begin.
You must have the Cloud SDK installed. If you need to install it, see
Installing Cloud SDK.
Initialize the Cloud SDK, as described in Initializing the gcloud CLI, or otherwise ensure that
the Google Cloud project you created in Prerequisites is the default project for
gcloud.
Define the following environment variables in your command terminal.
Select the tab that corresponds to the type of organization you need:
No data residency or with
Data residency:
AUTH defines the Authentication header with a bearer token.
You will use this header when calling Apigee APIs. Note that the token expires
after a period of time and when it does, you can simply regenerate it using the
same command. For more information, see the reference page for the
print-access-token command.
PROJECT_ID is the Cloud project ID that you created as part of the
Prerequisites.
PROJECT_NUMBER is the Cloud project number that you created as part
of the Prerequisites.
RUNTIME_LOCATION is the physical location where the Apigee instance you
will create later is located. For a list of available runtime locations, see
Apigee locations.
ANALYTICS_REGION is the physical location at which Apigee
analytics data will be stored. For a list of available Apigee API Analytics
regions, see
Apigee locations.
Both RUNTIME_LOCATION and ANALYTICS_REGION
can be the same region, but they do not have to be the same.
BILLING_TYPE is the billing type for the organization you create. Valid values are:
AUTH defines the Authentication header with a bearer token.
You will use this header when calling Apigee APIs. Note that the token expires
after a period of time and when it does, you can simply regenerate it using the
same command. For more information, see the reference page for the
print-access-token command.
PROJECT_ID is the Cloud project ID that you created as part of the
Prerequisites.
PROJECT_NUMBER is the Cloud project number that you created as part
of the Prerequisites.
RUNTIME_LOCATION is the physical location where the Apigee instance you
will create later is located. For a list of available runtime locations, see
Apigee locations.
The runtime location must be within
the control plane location.
CONTROL_PLANE_LOCATION is the physical location at which Apigee control plane data will be stored.
For a list of available control plane locations, see
Apigee locations.
CONSUMER_DATA_REGION is a sub-region of the control plane region. You must specify both the CONTROL_PLANE_LOCATION and the CONSUMER_DATA_REGION.
For a list of available consumer data regions, see
Apigee locations.
BILLING_TYPE is the billing type for the organization you create. Valid values are:
(Optional) Check your work by echoing the values you just set. Note that when you want
to use a variable in your commands, precede the variable's name with a dollar sign
($).
The responses to your echo commands should look something like the following:
YOUR_TOKEN
my-cloud-project
1234567890
us-west1
us
us-west1
SUBSCRIPTION
Step 2: Enable APIs
Permissions required for this task
You can give the Apigee provisioner a predefined role that includes the
permissions needed to complete this task, or give more fine-grained
permissions to provide the least privilege necessary. See
Predefined roles and
API enablement permissions.
Apigee requires you to enable several Google Cloud APIs. Enable them by executing the following services enable
command:
Verify that the agent was successfully created. The response should show the name of
the agent in the following format:
service-PROJECT_NUMBER@gcp-sa-apigee.iam.gserviceaccount.com.
for example:
Service identity created: service-1234567890@gcp-sa-apigee.iam.gserviceaccount.com
Step 4: Configure service networking
In this step, you allocate a pair of IP Address Ranges (a /22 and /28 CIDR range) to Apigee and
perform the VPC peering between your network and Apigee's network. Each Apigee instance
requires a non-overlapping CIDR range of /22 and /28. The Apigee runtime plane
is assigned IP addresses from within this CIDR range. As a result, it's
important that the range is reserved for Apigee and not used by other applications in
your VPC network. For more information and important considerations,
see Understanding peering ranges.
Note that you are creating sufficient network IP range for one Apigee instance. If you plan
to create additional Apigee instances, you have to repeat this step for each one. The ranges
cannot be shared between instances. See also Expanding Apigee to multiple regions.
Permissions required for
this task
You can give the Apigee provisioner a predefined role that includes the
permissions needed to complete this task, or give more fine-grained
permissions to provide the least privilege necessary. See
Predefined roles and
Service networking permissions.
RANGE_NAME is the name of the IP address range you are creating.
You can name the range anything you want. For example: google-svcs
NETWORK_NAME is the name of the network resource in which the addresses
should be reserved.
Google creates a default network
(named default) for each new project, so you can use that. However,
Google does not recommend using the default network for anything other than testing.
Create a network IP range with a CIDR length of /22:
Where --addresses lets you optionally specify an
address range. For example, to allocate the CIDR block
192.168.0.0/22, specify 192.168.0.0 for
the address and 22 for the prefix length. See also
Creating an IP allocation.
If you do not provide the --addresses parameter, then
gcloud selects an available address range for you.
On success, gcloud responds with the following:
Created [https://www.googleapis.com/compute/v1/projects/PROJECT_NAME/global/addresses/google-svcs].
After you create a range of IP addresses, the addresses are associated with
the project until you release them.
Verify the network IP range was created with a CIDR length of /22:
Create a network IP range with a CIDR length of /28. This range is required and is
used by Apigee for troubleshooting purposes and cannot be customized or changed.
Where --addresses lets you optionally specify an
address range. For example, to allocate the CIDR block
192.168.0.0/28, specify 192.168.0.0 for
the address and 28 for the prefix length. See also
Creating an IP allocation.
If you do not provide the --addresses parameter, then
gcloud selects an available address range for you.
Verify the network IP range was created with a CIDR length of /28:
Apigee creates a connection between your network and Google's services; specifically,
Apigee connects your project to the Service Networking API through VPC peering. Apigee
also associates IP addresses with your project.
After few minutes, verify whether VPC peering succeeded:
gcloud services vpc-peerings list \
--network=$NETWORK_NAME \
--service=servicenetworking.googleapis.com \
--project=$PROJECT_ID
Step 5: Create an organization
Permissions required for this task
You can give the Apigee provisioner a predefined role that includes
the permissions needed to complete this task, or give more fine-grained
permissions to provide the least privilege necessary. See:
Before you can create an organization, you must create a runtime database
encryption key ring and key (see step 1) and, if you
are using
data residency, control plane encryption key rings and keys
(see step 2). These
Cloud KMS keys encrypt data that is stored and replicated across
runtime and control plane locations. Apigee uses these entities to
encrypt application data such as KVMs, cache, and client secrets, which is
then stored in the database. For more information, see
About the Apigee encryption keys.
Create a runtime database encryption key ring and key.
Define an environment variable for the location of your runtime database
encryption ring and key. This helps ensure consistency when you create them and
makes it easier for you to follow along in the documentation.
The value is the physical location where your runtime database encryption key ring
and key are stored.
Single region
Single region configurations (in which you have just one instance
in one region): Choose from the supported KMS
regional locations.
For example:
RUNTIMEDBKEY_LOCATION="us-west1"
The value can be the same as your $RUNTIME_LOCATION (also a region) but it
does not have to be. However, there may be a performance benefit if they are the
same.
We recommend that if you have a multi-region configuration in the US, use
us for your location if possible. Otherwise, use nam4.
Define environment variables for database key rings and key names.
The key ring's name must be unique to your organization. If you create a
second or subsequent region, the name cannot be the same as other key rings'
names.
(Optional) Check your work by echoing the values you just set. Remember that when you want
to use a variable in your commands, precede the variable's name with a dollar sign
($).
CONTROL_PLANE_LOCATION is the physical location at which Apigee control plane data will be stored.
For a list of available control plane locations, see
Apigee locations.
CONSUMER_DATA_REGION is a sub-region of the control plane region. You must specify both the CONTROL_PLANE_LOCATION and the CONSUMER_DATA_REGION.
For a list of available consumer data regions, see
Apigee locations.
Define environment variables for control plane database key rings and key names.
The key ring's name must be unique to your organization.
This command binds the key to the Apigee Service Agent. On successful completion
of this request, gcloud responds with something similar to the following:
runtimeDatabaseEncryptionKeyName: The ID of the application
encryption key that you created in the previous step. Recall that the ID is structured
like a file path. For example: projects/my-project/locations/us-west1/keyRings/my-key-ring/cryptoKeys/my-key
runtimeDatabaseEncryptionKeyName: The ID of the application
encryption key that you created in the previous step. Recall that the ID is
structured like a file path. For example: projects/my-project/locations/us-west1/keyRings/my-key-ring/cryptoKeys/my-key
After you execute this command, Apigee starts a long-running operation,
which can take a few minutes to complete.
If you get an error, check your use of quotation marks around
the variable values in the data payload. Be sure that you have double-single-double quotes
around the $PROJECT_ID variable, as the following example shows:
"'"$PROJECT_ID"'"
If you use plain strings (not environment variables) for request values, you can
wrap them in double quotes within the
single-quoted payload string, as the following example shows:
'{ "name":"my-gcp-project", ... }'
Wait a few minutes.
To check the status of your creation request, you can send a GET request to the Apigee
List organizations API, as the following example shows:
If you see this response, then the organization creation has not completed yet:
{
"error": {
"code": 403,
"message": "Permission denied on resource \"organizations/apigee-docs-m\" (or it may not exist)",
"status": "PERMISSION_DENIED"
}
}
If Apigee has successfully created a new organization, you will receive a response
that is similar to the following:
You can give the Apigee provisioner a predefined role that includes the
permissions needed to complete this task, or give more fine-grained
permissions to provide the least privilege necessary. See
Predefined roles and
Runtime instance permissions.
A runtime instance is where your Apigee project and related services are stored; it
provides the user-facing endpoint for your services. To create a new runtime instance:
Check that Apigee has finished creating your organization. You submitted a request to
create a new organization in Create an Apigee organization, but
you need to be sure it's done before you continue.
If the organization exists (and you have the proper permissions to view it), Apigee
responds with details about it. If Apigee responds with an error, wait a couple of
minutes and send the request again.
Similar to the preceding task where you created an encryption key for the database,
now you need to create a
Cloud KMS key used to encrypt data on the server side.
To get started, define the following environment variables:
INSTANCE_NAME: Your new instance's name. For example,
my-runtime-instance. The name must start with a lowercase letter, can
be up to 32 characters long, and can include only lowercase letters, numbers and
hyphens. It cannot start or end with a hyphen and must be at least two characters
long.
RUNTIME_LOCATION is the physical place in which your cluster is hosted.
Valid values are any location allowed by Compute Engine. (See
Available regions and zones.) This example uses
us-west1.
DISK_KEY_RING_NAME is the name of the disk encryption key ring.
DISK_KEY_NAME is the name of the disk encryption key.
consumerAcceptList (Optional) Specifies a list of
Google Cloud project IDs that can privately connect to the Apigee VPC's
service attachment. Service attachment is an entity used with Google Cloud
Private Service Connect to allow service producers (in this case, Apigee) to
expose services to consumers (in this case, one or more Cloud projects that you own).
By default, we use the Cloud project that is already associated with your Apigee
organization. For example:
"consumerAcceptList": ["project1", "project2", "project3"]
Note that you can also set and change the list of accepted
projects in the Instance UI. For details, see
Managing instances.
While the /22 IP range is used for running Apigee core workloads,
the /28 range is used by Apigee to access the instance for troubleshooting purposes.
See also
Creating instances.
This request can take up to 20 minutes to complete because Apigee must create and
launch a new Kubernetes cluster, install the Apigee resources on that cluster, and set up
load balancing.
To check the status of your runtime instance creation request, execute the following
command. When the state is ACTIVE, you can go on to the next step.
No data residency
curl -i -X GET -H "Authorization: Bearer $AUTH" \
"https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances/$INSTANCE_NAME"
Data residency
curl -i -X GET -H "Authorization: Bearer $AUTH" \
"https://$CONTROL_PLANE_LOCATION-apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances/$INSTANCE_NAME"
Step 7: Create an environment
Permissions required for this task
You can give the Apigee provisioner a predefined role that includes
the permissions needed to complete this task, or give more fine-grained
permissions to provide the least privilege necessary. See:
To create an environment and attach it to the runtime on the command
line:
Define environment variables to be used in this section. The specific environment variables you create
will depend upon whether you are creating an environment for a subscription or Pay-as-you-go
org.
Subscription
For a subscription environment, create these variables:
ENVIRONMENT_NAME is a string name. For example: test
ENVIRONMENT_TYPE is the
environment type
for this environment and is only applicable for Pay-as-you-go users, who must
specify one of these values: BASE, INTERMEDIATE, or
COMPREHENSIVE. Other users should omit the environment type.
ENV_GROUP_NAME is a string name. For example: test-group
ENV_GROUP_HOSTNAME is a valid domain host name. For example: foo.example.com
Create a new environment with the Environments API. The specific commands you use
will depend upon whether you are creating an environment for a subscription or Pay-as-you-go
org.
Subscription
For a new subscription environment, use the following command:
In this step, you configure how client applications communicate with Apigee. Client to Apigee
traffic is also called "northbound" traffic. Northbound configuration options include the following.
Go to the configuration option you wish to use and perform the steps for that option:
Access type
Description of the configuration and deployment process
Use a managed instance group (MIG) to send
API traffic from a global load balancer's backend service to Apigee. With this configuration, Apigee is only able
to connect to the peered VPC. This configuration lets you send Apigee API proxy requests from any
network-enabled machine.
Allow only internal access to your API proxies from any of your Google Cloud projects using
Private Service Connect (PSC).
PSC enables private connection between a
service producer (Apigee) and a service consumer (the peered VPC project and/or
one or more other Cloud projects that you control). With this method, requests
pass through either a service endpoint or a regional internal load balancer to a single point of attachment, called
a service attachment.
This configuration lets your internal clients send
Apigee API proxy requests from any network-enabled machine.
Use Private Service Connect (PSC) to enable private connection between
a service producer (Apigee) and a service consumer (the peered VPC project and/or
one or more other Cloud projects that you control). With this method, requests pass through
either a global external load balancer or a regional external load balancer to a single
point of attachment, called a service attachment.
This configuration lets you send
Apigee API proxy requests from any
network-enabled machine.
Each of these routing approaches is presented in the instructions below.
Internal routing (VPC)
For routing of traffic from internal clients to Apigee, you can choose to use TLS
termination or not:
TLS Options: You have two choices if you want to make API proxy
calls from internal clients with TLS enabled:
(Option 1) Configure an internal load balancer (ILB):
Create a managed instance group (MIG) in your project. To create the MIG, follow the steps 8a, 8b,
and 8c in the External routing (MIG)
tab.
Create and configure an internal HTTPS(S) load balancer (ILB), and
attach the MIG you created to the backend service of the ILB, as explained in
Set up Internal HTTP(S) Load Balancing with VM instance group backends. With the ILB configuration,
you have full control over the CA certificates used with the ILB.
(Option 2) Use the internal, default fully qualified domain name and the internal load balancer
IP of the Apigee instance. This case is recommended only for testing purposes, and not
for a production environment. In this case, Apigee-created self-signed certificates are used,
with Apigee's internal load balancer, and you cannot change them. See
Calling an API proxy with internal-only access.
Non-TLS option: If you don't need to enable TLS termination, you can call API proxies
where the client disables TLS. For example, by using the -k option with
cURL, you can disable TLS. See
Calling an API proxy with internal-only access.
External routing (MIG)
This section describes how to configure routing to allow external access
to API proxies using a managed instance group (MIG) to send API traffic from a global
load balancer's backend service to Apigee. You must do
this before you can send a request from an external client to your Apigee runtime
instance.
Permissions required for this task
You can give the Apigee provisioner a predefined role that includes the permissions needed to complete this task,
or give more fine-grained permissions to provide the least privilege necessary.
See Predefined roles
and Access routing permissions.
The instructions in this section use environment variables to refer to repeatedly used
strings. We recommend that you set these before continuing:
MIG_NAME=apigee-mig-MIG_NAME # You can choose a different name if you like
VPC_NAME=default # If you are using a shared VPC, use the shared VPC nameVPC_SUBNET=default # Private Google Access must be enabled for this subnetREGION=RUNTIME_REGION # The same region as your Apigee runtime instanceAPIGEE_ENDPOINT=APIGEE_INSTANCE_IP # See the tip below for details on getting this IP address value
You'll use these variables several times during the remaining processes. If you
wish to configure multiple regions, then create variables with values specific for
each region.
Step 8c: Create a managed instance group
In this step, you create and configure a managed instance group (MIG). In a later step,
you add the MIG to a backend service which is attached to a global load balancer. A MIG is
required to send API traffic from the global load balancer's backend service to Apigee.
As you can see from this command, machines are of type e2-medium. They run
Debian 12 and have 20GB of disk. The startup-script.sh script configures the MIG to route inbound traffic from the load
balancer to the Apigee instance.
Step 8d: Create an SSL certificate and key for the load balancer
You only need to create the credentials once, whether you are
installing in single or multi regions. In a later step, you will associate these credentials
with the load balancer's target HTTPS proxy.
Set DOMAIN_HOSTNAME to a valid domain hostname that you have registered. In a later step, you will obtain the load
balancer's IP address and update the domain A record to point to that address. For example, a domain hostname
might look like this: foo.example.com.
You'll use this health check to ensure that the backend service is running. For
configuring more advanced health checks against a specific proxy, see
Performing health checks.
Step 8f: Get a reserved IP address and create firewall rules
You must assign an IP address to the load balancer and then create rules that allow
the load balancer to access the MIG. You only need to do this step once, whether you are
installing in single or multi regions.
Important step: Go to the site, DNS host, or ISP where your DNS records are managed, and make sure
your domain's DNS record resolves to the IP address of the Google Cloud load
balancer. This address is the IP value returned in the last step. For more detail, see
Update the DNS A and AAAA records to point to the load balancer's IP address.
Create a firewall rule that lets the load balancer access the MIG by using the
following command:
gcloud compute firewall-rules create FIREWALL_RULE_NAME \
--description "Allow incoming from GLB on TCP port 443 to Apigee Proxy" \
--project $PROJECT_ID --network $VPC_NAME --allow=tcp:443 \
--source-ranges=130.211.0.0/22,35.191.0.0/16 --target-tags=gke-apigee-proxy
Note that the IP address ranges 130.211.0.0/22 and 35.191.0.0/16 are the source IP
address ranges for Google Load Balancing. This firewall rule allows Google Cloud Load Balancing to
make health check requests to the MIG.
This section explains how to allow only internal access to your API proxies from any of your
Google Cloud projects using Private Service Connect (PSC).
You have two options for configuring internal access with PSC:
Service endpoint: Requests pass through a service endpoint to a single point of
attachment, called a
service attachment.
Internal regional load balancer: Requests pass through a regional internal HTTP(S) load balancer. See also
Global vs regional load balancing.
Select the tab below for your configuration choice and follow the steps:
Service endpoint
Permissions required for this task
You can give the Apigee provisioner a predefined role that includes the permissions needed to complete this task,
or give more fine-grained permissions to provide the least privilege necessary.
See Predefined roles
and Access routing permissions.
Create a PSC service endpoint for the service attachment
Get the service attachment from the instance you created previously:
No data residency
curl -i -X GET -H "Authorization: Bearer $AUTH" \
"https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances"
Data residency
curl -i -X GET -H "Authorization: Bearer $AUTH" \
"https://$CONTROL_PLANE_LOCATION-apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances"
In the following sample output, the serviceAttachment
value is shown in bold type:
Create a PSC Service Endpoint that points to the service attachment that you obtained
from the instance response body in the previous step, as explained in
Create a Private Service Connect endpoint.
You can give the Apigee provisioner a predefined role that includes the permissions needed to complete this task,
or give more fine-grained permissions to provide the least privilege necessary.
See Predefined roles
and Access routing permissions.
Step 8a: Set up environment variables
The instructions in this section use environment variables to refer to repeatedly used
strings. Be sure you have set the variables in
Define environment variables.
In addition, set the following environment variables:
TARGET_SERVICE: the service attachment that you want to
connect to. For example: projects/bfac7497a40c32a12p-tp/regions/us-west1/serviceAttachments/apigee-us-west1-crw7
NETWORK_NAME: (Optional) Name of the network in which the NEG is created. If you omit
this parameter, the default project network is used.
SUBNET_NAME: Name of the subnet used for private connectivity to the producer.
The subnet size can be small: the PSC NEG only needs one IP from the subnet.
For Apigee, only one PSC NEG is needed per region. The subnet can be shared and used by VMs or
other entities.
If a subnet is not specified, network endpoints may belong to any subnetwork in the
region where the network endpoint group is created.
Where $PROJECT_ID can be the Cloud project that is already
associated with your Apigee organization, or a Cloud project included
in the consumerAcceptlist when the
Apigee runtime instance was created.
Step 8d: Configure the regional internal load balancer
Reserve an internal IPv4 address for the load balancer.
BACKEND_SERVICE_NAME with the name of the backend service.
To create an HTTPS load balancer, you must have an SSL certificate resource to use in the
HTTPS target proxy.
Use this command to create a self-managed SSL certificate resource. To create a
self-managed SSL certificate, you need a local private key file and a local certificate
file. If you need to create these files, see step 1 of using self-managed SSL certificates.
DEFAULT_BACKEND_SERVICE_NAME: the name of the load balancer's default backend service.
The default is used when no host rule matches the requested hostname.
Use the SSL certificate resource to create a target HTTPS proxy.
This section describes how to configure external routing using
Private Service Connect (PSC) to
allow communication between Apigee and VPCs that you control. You must do this before
you can send a request from an external client to your Apigee runtime instance.
Permissions required for this task
You can give the Apigee provisioner a predefined role that includes the permissions needed to complete this task,
or give more fine-grained permissions to provide the least privilege necessary.
See Predefined roles
and Access routing permissions.
Step 8b: Create a NEG and configure the load balancer
You can create a global or regional load balancer.
TARGET_SERVICE: the service attachment that you want to
connect to. Use the service attachment value returned by the previous
command. For example:
projects/bfac7497a40c32a12p-tp/regions/us-west1/serviceAttachments/apigee-us-west1-crw7
NETWORK_NAME: (Optional) Name of the network in which the NEG is created. If you omit
this parameter, the default project network is used.
SUBNET_NAME: Name of the subnet used for private connectivity to the producer.
The subnet size can be small: the PSC NEG only needs one IP from the subnet.
For Apigee, only one PSC NEG is needed per region. The subnet can be shared and used by VMs or
other entities.
If a subnet is not specified, network endpoints may belong to any subnetwork in the
region where the network endpoint group is created.
$PROJECT_ID The Cloud project that is already associated
with your Apigee organization, or a Cloud project included
in the consumerAcceptlist when the
Apigee runtime instance was created.
If you haven't already,
create an environment variable to hold the project ID, because it is
used in most of the following commands.
Reserve a global external IPv4 address for the load balancer.
DEFAULT_BACKEND_SERVICE_NAME: the name of the load balancer's default backend service.
The default is used when no host rule matches the requested hostname.
Create the target HTTPS proxy.
To create an HTTPS load balancer, you must have an SSL certificate resource to use in the
HTTPS target proxy. You can create an SSL certificate resource using either a Google-managed
SSL certificate or a self-managed SSL certificate. Using Google-managed certificates is
recommended because Google Cloud obtains, manages, and renews these certificates automatically.
Use this command to create a self-managed SSL certificate resource. To create a
self-managed SSL certificate, you need a local private key file and a local certificate
file. If you need to create these files, see step 1 of using self-managed SSL certificates.
TARGET_SERVICE: the name of the service attachment that you want to connect to.
For example: projects/bfac7497a40c32a12p-tp/regions/us-west1/serviceAttachments/apigee-us-west1-crw7
DEFAULT_BACKEND_SERVICE_NAME: the name of the load balancer's default backend service.
The default is used when no host rule matches the requested hostname.
Create the target HTTPS proxy.
To create an HTTPS load balancer, you must have an SSL certificate resource to use in the
HTTPS target proxy.
Use this command to create a self-managed SSL certificate resource. To create a
self-managed SSL certificate, you need a local private key file and a local certificate
file. If you need to create these files, see step 1 of using self-managed SSL certificates.
Creating and deploying proxies requires a minimum set of permissions. If you
have Apigee Org Admin role, you can complete this task. To learn about other
roles you can employ, see
Apigee roles.
Download the
sample proxy from GitHub. The target of the proxy is the
httpbin.org service, which is
a commonly used public request and response service.
Upload the API proxy bundle to the runtime using the Apigee
apis API:
If you get an error like this:
CONNECT_CR_SRVR_HELLO:sslv3 alert handshake failure, check to
be sure the SSL certificate you created previously has been provisioned.
Use this command to check the
provisioning status. When the cert is provisioned, its status is
ACTIVE.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-02-14 UTC."],[],[]]