Deploying the API Gateway subsystem on Linux® x86_64 (CLI)
Deploy the individual API Gateway subsystem. This procedure uses the CLI.
API Connect subsystems can be installed by creating individual subsystem custom resources (CRs), instead of using an API Connect cluster.
There are four subsystems that can be installed:
API Manager. For more information, see Deploying the API Manager subsystem on Linux x86_64 (CLI)
API Analytics. For more information, see Deploying the API Analytics subsystem on Linux x86_64 (CLI)
API Portal. For more information, see Deploying the API Portal subsystem on Linux x86_64 (CLI)
API Gateway (discussed in this procedure)
Deploying API Gateway involves three main tasks:
Installing the certificate manager in the subsystem namespace
Log in to your cluster with your OpenShift user credentials:
oc login
If you installed the operators in All namespaces on the cluster mode, you need to use a project other than
openshift-operators
in which to deploy the instances.If needed, create a new project in which to create the Operand Request object:
oc new-project <project_name>
For example:
oc new-project integration
Create a file called
operand-request.yaml
and add the following content:apiVersion: operator.ibm.com/v1alpha1 kind: OperandRequest metadata: name: ibm-apiconnect-cert-manager spec: requests: - operands: - name: ibm-cert-manager-operator registry: common-service registryNamespace: ibm-common-services
Create the resource:
oc apply -f operand-request.yaml
Setting up the certificates
Change to the namespace where you want to install the subsystem:
oc project <namespace>
If you have installed the API Manager subsystem in another namespace, extract the API Manager
ingress-ca
certificates.oc -n <api manager namespace> get secret ingress-ca -o yaml > ingress-ca.yaml
Edit the
ingress-ca.yaml
file and remove the following properties:metadata.creationTimestamp
metadata.namespace
metadata.resourceVersion
metadata.uid
metadata.selfLink
Keep this file. You will need to apply it in the namespaces of your other subsystems so that they can communicate with the API Manager subsystem.
Apply the file to the API Gateway namespace:
oc apply -f ingress-ca.yaml
Create a file that is called
api-gateway-certs.yaml
and paste in the following contents:apiVersion: cert-manager.io/v1 kind: Issuer metadata: name: selfsigning-issuer labels: { app.kubernetes.io/instance: "api-manager", app.kubernetes.io/managed-by: "ibm-apiconnect", app.kubernetes.io/name: "selfsigning-issuer" } spec: selfSigned: {} --- apiVersion: cert-manager.io/v1 kind: Issuer metadata: name: ingress-issuer labels: { app.kubernetes.io/instance: "api-manager", app.kubernetes.io/managed-by: "ibm-apiconnect", app.kubernetes.io/name: "ingress-issuer" } spec: ca: secretName: ingress-ca --- apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: gateway-service labels: { app.kubernetes.io/instance: "gatewaycluster", app.kubernetes.io/managed-by: "ibm-apiconnect", app.kubernetes.io/name: "gateway-service" } spec: commonName: gateway-service secretName: gateway-service issuerRef: name: ingress-issuer usages: - "client auth" - "signing" - "key encipherment" duration: 17520h # 2 years renewBefore: 48h --- apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: gateway-peering labels: { app.kubernetes.io/instance: "gatewaycluster", app.kubernetes.io/managed-by: "ibm-apiconnect", app.kubernetes.io/name: "gateway-peering" } spec: commonName: gateway-peering secretName: gateway-peering issuerRef: name: ingress-issuer usages: - "server auth" - "client auth" - "signing" - "key encipherment" duration: 17520h # 2 years renewBefore: 48h
Apply the file to your namespace:
oc apply -f api-gateway-certs.yaml
Verify that the command installation succeeded:
oc get issuers
All issuers created successfully:
NAME READY ingress-issuer True selfsigning-issuer True
Verify that the API Gateway secrets were created:
oc get secrets
All secrets created successfully:
NAME TYPE DATA AGE ... gateway-peering kubernetes.io/tls 3 2m gateway-service kubernetes.io/tls 3 2m3s ...
Copy the
api-manager-ca
secret from the namespace where the API Manager subsystem is installed into the namespace where the API Gateway will be installed.Get the secret:
oc -n <api manager namespace> get secret api-manager-ca -o yaml > api-manager-ca.yaml
Edit the
api-manager-ca.yaml
file and remove the following properties:metadata.creationTimestamp
metadata.namespace
metadata.resourceVersion
metadata.uid
metadata.selfLink
Apply the file to the API Gateway namespace:
oc apply -f api-manager-ca.yaml
This ensures that the gateway service authenticates incoming requests from the API Manager, such as gateway service registration, and publishing APIs to the gateway service. Specifically, the gateway service requires that incoming requests present a certificate that was signed by the same CA that was used to sign the gateway service management endpoint. The gateway service management endpoint secret is specified under
gatewayManagerEndpoint.hosts.secretName
. The API Manager’s gateway client’s TLS credentials are specified in the API Manager CR undergateway.client.secretName
.To disable mutual TLS between the API Manager and the API Gateway, set
mtlsValidateClient
tofalse
in thespec
section of the API Gateway CR.
Deploying API Gateway
Create the API Gateway administrator secret:
oc create secret generic admin-secret --from-literal=password=admin
Create a
GatewayCluster
YAML file. For example, you can create a file that is calledapi-gateway.yaml
with the following example configuration. All fields in the example are required. Update the values as applicable for your configuration:apiVersion: gateway.apiconnect.ibm.com/v1beta1 kind: GatewayCluster metadata: name: api-gateway labels: { app.kubernetes.io/instance: "api-gateway", app.kubernetes.io/managed-by: "ibm-apiconnect", app.kubernetes.io/name: "api-gateway" } spec: version: 10.0.6.0 profile: n1xc1.m8 mtlsValidateClient: true apicGatewayServiceV5CompatibilityMode: false mgmtPlatformEndpointCASecret: secretName: ingress-ca mgmtPlatformEndpointSvcCASecret: secretName: api-manager-ca gatewayEndpoint: annotations: cert-manager.io/issuer: ingress-issuer hosts: - name: rgw.$STACK_HOST secretName: gwv6-endpoint gatewayManagerEndpoint: annotations: cert-manager.io/issuer: ingress-issuer hosts: - name: rgwd.$STACK_HOST secretName: gwv6-manager-endpoint apicGatewayServiceTLS: secretName: gateway-service apicGatewayPeeringTLS: secretName: gateway-peering datapowerLogLevel: 3 license: accept: false use: production license: L-KZXM-S7SNCU tokenManagementService: enabled: true storage: storageClassName: <storage-class> volumeSize: 30Gi adminUser: secretName: admin-secret
Change the value of
spec.license.accept
totrue
if you accept the license agreement. For more information, see Licensing.In
metadata.annotations
, do not removeapiconnect-operator/cp4i: "false"
. This annotation guarantees that API Gateway does not attempt to integration with the Platform UI. This integration is not supported.For
spec.license.use
enterproduction
ornonproduction
to match the type of license that you purchased.For
spec.license.license
enter the license ID for the API Connect program that you purchased. To get the available license IDs, see API Connect licenses in the API Connect documentation.For
spec.profile
enter the type of installation profile that you want. For more information, see API Connect deployment profiles for OpenShift and Cloud Pak for Integration.For
spec.version
enter the API Connect product version or channel to be installed.For
<storage-class>
, specify the RWO block storage class to use for persistence storage. For more information about selecting storage classes for Cloud Pak for Integration, see Storage considerations. To review API Connect storage support, see the "Supported storage types" section in Deployment requirements, in the API Connect documentation.Replace
$STACK_HOST
with the desired ingress subdomain for the API Connect stack. This variable is used when specifying endpoints. Domain names that are used for endpoints cannot contain the underscore "_" character. The host on OpenShift is typically prefixed byapps
. Such asapps.subnet.example.com
.
Apply the YAML file to the cluster:
oc apply -f api-gateway.yaml
Check the status of API Gateway by running the following command in the project (namespace) where it was deployed:
oc get GatewayCluster
The installation is complete when the READY status changes to
True
, and the SUMMARY reports that all services are online:NAME READY SUMMARY VERSION RECONCILED VERSION AGE api-gateway True 2/2 <version> <version-build> 7m17s
What's next?
Install other subsystems as needed.
When you have completed the installation of all required API Connect subsystems, you can proceed to defining your API Connect configuration by using the API Connect Cloud Manager; refer to the Cloud Manager configuration checklist.