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:

Deploying API Gateway involves three main tasks:

  1. Installing the certificate manager in the subsystem namespace

  2. Setting up the certificates

  3. Deploying API Gateway

Installing the certificate manager in the subsystem namespace

  1. Log in to your cluster with your OpenShift user credentials:

    oc login
  2. 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
  3. 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
  4. Create the resource:

    oc apply -f operand-request.yaml

Setting up the certificates

  1. Change to the namespace where you want to install the subsystem:

    oc project <namespace>
  2. 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
  3. 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.

  4. Apply the file to the API Gateway namespace:

    oc apply -f ingress-ca.yaml
  5. 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
  6. Apply the file to your namespace:

    oc apply -f api-gateway-certs.yaml
  7. Verify that the command installation succeeded:

    oc get issuers

    All issuers created successfully:

    NAME                 READY
    ingress-issuer       True
    selfsigning-issuer   True
  8. 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
    ...
  9. 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.

    1. Get the secret:

      oc -n <api manager namespace> get secret api-manager-ca -o yaml > api-manager-ca.yaml
    2. Edit the api-manager-ca.yaml file and remove the following properties:

      • metadata.creationTimestamp

      • metadata.namespace

      • metadata.resourceVersion

      • metadata.uid

      • metadata.selfLink

    3. 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 under gateway.client.secretName.

    To disable mutual TLS between the API Manager and the API Gateway, set mtlsValidateClient to false in the spec section of the API Gateway CR.

Deploying API Gateway

  1. Create the API Gateway administrator secret:

    oc create secret generic admin-secret --from-literal=password=admin
  2. Create a GatewayCluster YAML file. For example, you can create a file that is called api-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 to true if you accept the license agreement. For more information, see Licensing.

    • In metadata.annotations, do not remove apiconnect-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 enter production or nonproduction 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 by apps. Such as apps.subnet.example.com.

  3. Apply the YAML file to the cluster:

    oc apply -f api-gateway.yaml
  4. 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.