Creating ingress definitions for IBM App Connect instances in an IBM Cloud Kubernetes Service cluster

Kubernetes-only contentUse these instructions to expose your deployed App Connect Dashboard, App Connect Designer, integration server, integration runtime, and switch server instances in an IBM Cloud Kubernetes Service environment to external traffic.

Before you begin

When you create an IBM Cloud Kubernetes Service cluster, IBM provides the following components that are required to use ingress: ingress domain, ingress class, Application Load Balancers (ALBs), and TLS certificate. You reference these components when you create ingress resources for your App Connect Dashboard, App Connect Designer, integration server, integration runtime, and switch server instances. For more information, see IBM-provided Ingress components in the IBM Cloud Kubernetes Service documentation.

If you deploy a switch server, some prerequisite configuration is required before you create its ingress resource. You use a switch server to configure connectivity for hybrid integrations in IBM App Connect, which interact with callable flows in IBM App Connect Enterprise or IBM Integration Bus. You also use a switch server to configure connectivity for flows or integrations that interact with applications in a private network. As a prerequisite for ingress, you therefore need to modify the default settings for ALBs that run the Kubernetes ingress image, and which listen for and forward incoming requests to the appropriate pod. To modify the default settings, customize the ALB deployment to enable SSL pass-through by creating a ConfigMap object:

  1. Get the ID of the ALB, where <cluster_name_or_ID> is the name or identifier of your cluster. 
    ibmcloud ks ingress alb ls --cluster <cluster_name_or_ID>
    Tip: You can copy the cluster ID from the Overview page in your cluster.
    Cluster Overview page with the cluster ID

    In the output of the ibmcloud command, make a note of the ID that starts with public.

  2. From your local computer, create a YAML file (for example, appconn-ingress-configmap.yaml) for a ConfigMap object named ibm-ingress-deploy-config, where <alb_id> is the ALB ID from the previous step. 
    apiVersion: v1
kind: ConfigMap
metadata:
  name: ibm-ingress-deploy-config
  namespace: kube-system
data:
  <alb_id>: '{"enableSslPassthrough":"true"}'
  3. Create the ConfigMap object.
    kubectl apply -f appconn-ingress-configmap.yaml
  4. Update your ALBs to pick up the changes.
    ibmcloud ks ingress alb update -c <cluster_name_or_ID>
  5. To confirm the update, inspect the ALB (ingress) pod logs in the kube-system namespace.
    1. Run the following command to get the IDs of the ALB pods that are running in your cluster. (These ingress pods are named in the format public-<cluster_id>-alb1-*.)
      kubectl get pods -n kube-system | grep alb

    2. Get the logs for the ALB pod.
      kubectl logs <alb_pod_ID> -n kube-system

      In the pod logs, look for this message: "Starting TLS proxy for SSL Passthrough".

For more information about ALBs and ingress, see Application Load Balancers (ALBs) and Customizing the ALB deployment in the IBM Cloud Kubernetes Service documentation. For more information about switch servers, see App Connect Switch Server reference.

About this task

For each App Connect Dashboard, App Connect Designer, integration server, integration runtime, or switch server instance, you must create an ingress resource with rules that define an externally-reachable URL for accessing the running service in the cluster.

IBM provides ingress classes that implement the NGINX ingress controller, so you do not need to manually install an ingress controller in your IBM Cloud Kubernetes Service cluster. When you define an ingress resource for an instance, you simply need to specify the ingress class that determines which type of ingress controller is used.

For these instructions, an IBM Cloud Kubernetes Service cluster was provisioned on a Classic infrastructure, and the IBM-provided ingress subdomain, public-iks-k8s-nginx ingress class, and default TLS certificate are used. For more information, see Supported infrastructure providers, Ingress domain, Ingress class, and Setting up Ingress in the IBM Cloud Kubernetes Service documentation.

Work with a cluster administrator if necessary to create and apply the ingress resources.

Creating an ingress route for an App Connect Dashboard UI

Create an ingress resource that will be used to route external traffic to an App Connect Dashboard UI in your cluster.

Procedure

To create an ingress route for a running Dashboard UI, complete the following steps:

  1. From your local computer, create a YAML file (for example, appconn-ingress-dashboard.yaml) with the following content, where:
    • <dashboardIngressName> is a unique short name by which the ingress can be identified.
    • <namespaceName> is the namespace where the Dashboard instance is deployed.
    • <dashboardHostPrefix> is a unique user-supplied name for the UI instance, and <ingress_subdomain> is the ingress subdomain that is typically in the format <cluster_name>-<globally_unique_account_HASH>-0000.<region>.containers.appdomain.cloud. The combined value is used to form a host name for the Dashboard UI; for example, ace-dash.mycluster-a1b2cdef345678g9hi012j3kl4567890-0000.us-south.containers.appdomain.cloud. Only one host name can be specified for a Dashboard UI.
      Tip: To check your cluster's default domain, run ibmcloud ks cluster get --cluster <cluster_name> and look for the Ingress Subdomain value in the output. For example:
      Ingress Subdomain:              acecc-mycluster-cf1234e1b87ad465f7b7cd114438a7e6-0000.us-south.containers.appdomain.cloud
Ingress Secret:                 acecc-mycluster-cf1234e1b87ad465f7b7cd114438a7e6-0000
    • <dashboardCRName> is the metadata.name value in the Dashboard instance custom resource.
    Note: The <dashboardIngressName> and <dashboardHostPrefix> values for the Dashboard UI must be different from the <dashboardIngressName> and <dashboardHostPrefix> values for the API.
    kind: Ingress
apiVersion: networking.k8s.io/v1
metadata:
  name: <dashboardIngressName>
  namespace: <namespaceName>
  annotations:
    nginx.ingress.kubernetes.io/backend-protocol: HTTPS
spec:
  ingressClassName: public-iks-k8s-nginx
  tls:
    - hosts:
      - <dashboardHostPrefix>.<ingress_subdomain>
  rules:
    - host: <dashboardHostPrefix>.<ingress_subdomain>
      http:
        paths:
        - path: /
          pathType: Prefix
          backend:
            service:
              name: <dashboardCRname>-dash
              port:
                number: 8300
  2. Run the following command to create the ingress: 
    kubectl apply -f appconn-ingress-dashboard.yaml

    You can now access the App Connect Dashboard UI instance to deploy and manage integration servers or integration runtimes by providing the following URL in a browser:

    https://<dashboardHostPrefix>.<ingress_subdomain>

    Traffic to this URL will be routed to the <dashboardCRName>-dash service.

Creating an ingress route for an App Connect Dashboard API

Create an ingress resource that will be used to route external traffic to an API that is enabled for an App Connect Dashboard instance in your cluster. This API provides REST API facilities for administering resources that the App Connect Dashboard manages.

For more information about the API, see API for IBM App Connect in containers.

Procedure

To create an ingress route for an enabled Dashboard API, complete the following steps:

  1. From your local computer, create a YAML file (for example, appconn-ingress-dashboardapi.yaml) with the following content, where:
    • <dashboardIngressName> is a unique short name by which the ingress can be identified.
    • <namespaceName> is the namespace where the Dashboard instance is deployed.
    • <dashboardHostPrefix> is a unique user-supplied name for the instance, and <ingress_subdomain> is the ingress subdomain that is typically in the format <cluster_name>-<globally_unique_account_HASH>-0000.<region>.containers.appdomain.cloud. The combined value is used to form a host name for the Dashboard API; for example, ace-dash-api.mycluster-a1b2cdef345678g9hi012j3kl4567890-0000.us-south.containers.appdomain.cloud. Only one host name can be specified for a Dashboard API.
      Tip: To check your cluster's default domain, run ibmcloud ks cluster get --cluster <cluster_name> and look for the Ingress Subdomain value in the output. For example:
      Ingress Subdomain:              acecc-mycluster-cf1234e1b87ad465f7b7cd114438a7e6-0000.us-south.containers.appdomain.cloud
Ingress Secret:                 acecc-mycluster-cf1234e1b87ad465f7b7cd114438a7e6-0000
    • <dashboardCRName> is the metadata.name value in the Dashboard instance custom resource.
    Note: The <dashboardIngressName> and <dashboardHostPrefix> values for the API must be different from the <dashboardIngressName> and <dashboardHostPrefix> values for the Dashboard UI.
    kind: Ingress
apiVersion: networking.k8s.io/v1
metadata:
  name: <dashboardIngressName>
  namespace: <namespaceName>
  annotations:
    nginx.ingress.kubernetes.io/backend-protocol: HTTPS
spec:
  ingressClassName: public-iks-k8s-nginx
  tls:
    - hosts:
      - <dashboardHostPrefix>.<ingress_subdomain>
  rules:
    - host: <dashboardHostPrefix>.<ingress_subdomain>
      http:
        paths:
        - path: /
          pathType: Prefix
          backend:
            service:
              name: <dashboardCRname>-dash
              port:
                number: 8400
  2. Run the following command to create the ingress: 
    kubectl apply -f appconn-ingress-dashboardapi.yaml

    If you have the correct permission, you can now access the enabled API for the App Connect Dashboard instance to administer resources by providing the following URL in a browser:

    https://<dashboardHostPrefix>.<ingress_subdomain>

    Traffic to this URL will be routed to the <dashboardCRName>-dash service.

Creating an ingress route for a switch server

To expose a switch server to external traffic, you must create an ingress route immediately after you create the switch server because during its initialization, the switch server will need to provide a TLS host name (defined in an ingress resource) in order to request a certificate for this host. To prevent certificate-related errors from the ingress controller, the host name in the generated certificate and the TLS host name that is defined in your ingress resource must match.

Procedure

To create an ingress route for a newly deployed switch server, complete the following steps:

  1. From your local computer, create a YAML file (for example, appconn-ingress-switch.yaml) with the following content, where:
    • <switchServerIngressName> is a unique short name by which the ingress can be identified.
    • <namespaceName> is the namespace where the switch server is deployed.
    • <switchServerCRName> is the metadata.name value in the switch server custom resource.
      Note: In the YAML definition, the supplied label appconnect.ibm.com/switch: <switchServerCRName> denotes which switch server this ingress applies to. The IBM App Connect Operator will try to find this ingress definition for 10 minutes from when it started trying to create the switch server. If the Operator cannot find the ingress definition after this time, the switch server deployment moves to a FAILED state.
    • <switchServerHostPrefix> is a unique user-supplied name for the instance, and <ingress_subdomain> is the ingress subdomain that is typically in the format <cluster_name>-<globally_unique_account_HASH>-0000.<region>.containers.appdomain.cloud. The combined value is used to form a host name for the switch server; for example, ace-switch.mycluster-a1b2cdef345678g9hi012j3kl4567890-0000.us-south.containers.appdomain.cloud. Only one host name can be specified for a switch server.
      Tip: To check your cluster's default domain, run ibmcloud ks cluster get --cluster <cluster_name> and look for the Ingress Subdomain value in the output.

    kind: Ingress
apiVersion: networking.k8s.io/v1
metadata:
  name: <switchServerIngressName>
  namespace: <namespaceName>
  labels:
    appconnect.ibm.com/switch: <switchServerCRName>
  annotations:
    nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/ssl-passthrough: "true"
spec:
  ingressClassName: public-iks-k8s-nginx
  tls:
    - hosts:
      - <switchServerHostPrefix>.<ingress_subdomain>
  rules:
    - host: <switchServerHostPrefix>.<ingress_subdomain>
      http:
        paths:
        - path: /
          pathType: Prefix
          backend:
            service:
              name: <switchServerCRName>-switch
              port:
                number: 4443
  2. Run the following command to create the ingress: 
    kubectl apply -f appconn-ingress-switch.yaml

    To help you resolve any network connectivity or certificate errors when using a switch server, see Troubleshooting ingress issues on Kubernetes.

Creating an ingress route for an App Connect Designer instance

Create an ingress resource that will be used to route external traffic to an App Connect Designer instance in your cluster.

About this task

When a Designer instance is deployed, an integration server is automatically deployed to provide support for the built-in test facility for flows. After you create an ingress route for a Designer instance, you will also be required to create an ingress route for this integration server, as described in Creating an ingress route for the internal integration server that is deployed for App Connect Designer.

Procedure

To create an ingress route for a running Designer instance, complete the following steps:

  1. From your local computer, create a YAML file (for example, appconn-ingress-desauth.yaml) with the following content, where:
    • <designerAuthoringUIIngressName> is a unique short name by which the ingress can be identified.
    • <namespaceName> is the namespace where the Designer instance is deployed.
    • <designerAuthoringUIHostPrefix> is a unique user-supplied name for the instance, and <ingress_subdomain> is the ingress subdomain that is typically in the format <cluster_name>-<globally_unique_account_HASH>-0000.<region>.containers.appdomain.cloud. The combined value is used to form a host name for the Designer instance; for example, ace-des.mycluster-a1b2cdef345678g9hi012j3kl4567890-0000.us-south.containers.appdomain.cloud. Only one host name can be specified for a Designer instance.
      Tip: To check your cluster's default domain, run ibmcloud ks cluster get --cluster <cluster_name> and look for the Ingress Subdomain value in the output.
    • <designerAuthoringCRName> is the metadata.name value in the Designer instance custom resource.
    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: <designerAuthoringUIIngressName>
  namespace: <namespaceName>
  annotations:
    nginx.ingress.kubernetes.io/backend-protocol: HTTPS
spec:
  ingressClassName: public-iks-k8s-nginx
  tls:
    - hosts:
      - <designerAuthoringUIHostPrefix>.<ingress_subdomain>
  rules:
    - host: <designerAuthoringUIHostPrefix>.<ingress_subdomain>
      http:
        paths:
        - path: /
          pathType: Prefix
          backend:
            service:
              name: <designerAuthoringCRName>-ui
              port:
                number: 443
  2. Run the following command to create the ingress: 
    kubectl apply -f appconn-ingress-desauth.yaml

    You can now access the App Connect Designer instance to create and manage flows by providing the following URL in a browser:

    https://<designerAuthoringUIHostPrefix>.<ingress_subdomain>

    Traffic to this URL will be routed to the <designerAuthoringCRName>-ui service.

    If you encounter Found. Redirecting to /auth/icp and 502 bad gateway errors while trying to access the App Connect Designer instance, see Troubleshooting ingress issues on Kubernetes.

What to do next

Create an ingress route that will be used by the built-in test facility for API flows in your App Connect Designer instance. For more information, see Creating an ingress route for the internal integration server that is deployed for App Connect Designer.

Creating an ingress route for the internal integration server that is deployed for App Connect Designer

You can verify the behavior of any running API flow in your App Connect Designer instance by using the built-in test facility to call the endpoints for each of the implemented API operations. An internal integration server (named <designerAuthoringCRName>-designer) is deployed by default with the App Connect Designer instance to facilitate this testing.


You must create an ingress resource that will be used to route external traffic to this integration server in the cluster, and then configure the correct endpoints for calling the API operations. (For information about creating API flows, see Creating and managing flows in App Connect Designer.)

Procedure

To create an ingress route for the internal integration server that is deployed for a Designer instance, complete the following steps:

  1. From your local computer, create a YAML file (for example, appconn-ingress-desauthserver.yaml) with the following content, where:
    • <designerAuthoringISIngressName> is a unique short name by which the ingress can be identified.
    • <namespaceName> is the namespace where the Designer instance is deployed.
    • <designerAuthoringISHostPrefix> is a unique user-supplied name for the instance, and <ingress_subdomain> is the ingress subdomain that is typically in the format <cluster_name>-<globally_unique_account_HASH>-0000.<region>.containers.appdomain.cloud. The combined value is used to denote the internal integration server's endpoint (host name); for example, ace-des-is.mycluster-a1b2cdef345678g9hi012j3kl4567890-0000.us-south.containers.appdomain.cloud. Only one host name can be specified for this instance.
      Tip: To check your cluster's default domain, run ibmcloud ks cluster get --cluster <cluster_name> and look for the Ingress Subdomain value in the output.
    • <designerAuthoringCRName> is the metadata.name value in the Designer instance custom resource.
    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: <designerAuthoringISIngressName>
  namespace: <namespaceName>
  annotations:
    nginx.ingress.kubernetes.io/backend-protocol: HTTPS
spec:
  ingressClassName: public-iks-k8s-nginx
  tls:
    - hosts:
      - <designerAuthoringISHostPrefix>.<ingress_subdomain>
  rules:
    - host: <designerAuthoringISHostPrefix>.<ingress_subdomain>
      http:
        paths:
        - path: /
          pathType: Prefix
          backend:
            service:
              name: <designerAuthoringCRName>-designer-is
              port:
                number: 7843
  2. Run the following command to create the ingress: 
    kubectl apply -f appconn-ingress-desauthserver.yaml
  3. To ensure that the API flow displays the correct endpoints for the running API while within the Test tab for the flow, run the following command to set the ingress external address, which you created earlier, on the deployment. In this command, <namespaceName> is the namespace whether the Designer instance is deployed. 
    kubectl set env deployment/<designerAuthoringCRName>-ui SINGLE_TENANT_API_BASE_URL=https://<designerAuthoringISHostPrefix>.<ingress_subdomain> -n <namespaceName>

    For example:

    kubectl set env deployment/des-01-quickstart-ui SINGLE_TENANT_API_BASE_URL=https://ace-des.mycluster-a1b2cdef345678g9hi012j3kl4567890-0000.us-south.containers.appdomain.cloud -n ace-test

    The correct endpoints will be shown when you open the Test tab for the running API in App Connect Designer. For each operation, you can then use the Try it tab to test that calls can be successfully made to the external endpoint.

    Ingress endpoint for an integration server in the App Connect Designer

Creating an ingress route for an integration server in the App Connect Dashboard

When you deploy one or more BAR files to an integration server, you can indicate whether an HTTP or HTTPS route should be used to externally expose the service that identifies the set of pods where the integration runs. You must manually create this external route for the selected HTTP or HTTPS protocol. These instructions describe how to create an ingress resource for an integration server and configure the endpoints in your cluster.

Note: To use an HTTPS route, ensure that TLS is enabled for the integration server. Include the following custom resource (CR) settings in the integration server's CR before you deploy it or update the CR settings after deployment.
  • Set spec.forceFlowHTTPS.enabled to true to force all HTTP Input nodes and SOAP Input nodes in all deployed flows in the integration server to use TLS.
  • Set spec.forceFlowHTTPS.secretName to the name of a secret that stores a user-supplied public certificate/private key pair to use for enforcing TLS.
  • Set spec.service.endpointType to https.

Procedure

To create an ingress route for a running integration server, complete either of the following steps:

  • If you want to specify https as the type of transport to be used by the integration endpoint, complete the following steps:
    1. From your local computer, create a YAML file (for example, appconn-ingress-intserverhttps.yaml) with the following content.
      • Set <integrationServerIngressName> to a unique short name by which the ingress can be identified.
      • Set <namespaceName> to the namespace where the integration server is deployed.
      • For a secured HTTPS endpoint, set <integrationServerHostPrefix> to a unique user-supplied name for the instance, and set <ingress_subdomain> to the ingress subdomain that is typically in the format <cluster_name>-<globally_unique_account_HASH>-0000.<region>.containers.appdomain.cloud. The combined value is used to denote an external (TLS) endpoint; for example, ace-is.mycluster-a1b2cdef345678g9hi012j3kl4567890-0000.us-south.containers.appdomain.cloud.

        Also include the annotation nginx.ingress.kubernetes.io/backend-protocol: HTTPS, and use 7843 as the service port.

        Tip: To check your cluster's default domain, run ibmcloud ks cluster get --cluster <cluster_name> and look for the Ingress Subdomain value in the output.
      • Set <integrationServerCRName> to the metadata.name value in the integration server custom resource.
      apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: <integrationServerIngressName>
  namespace: <namespaceName>
  annotations:
    nginx.ingress.kubernetes.io/backend-protocol: HTTPS
spec:
  ingressClassName: public-iks-k8s-nginx
  tls:
    - hosts:
      - <integrationServerHostPrefix>.<ingress_subdomain>
  rules:
    - host: <integrationServerHostPrefix>.<ingress_subdomain>
        paths:
        - path: /
          pathType: Prefix
          backend:
            service:
              name: <integrationServerCRName>-is
              port:
                number: 7843
    2. Run the following command to create the ingress: 
      kubectl apply -f appconn-ingress-intserverhttps.yaml
    3. To ensure that the integration server displays the correct endpoints for the deployed integration within the App Connect Dashboard, run the following command to set the ingress external address on the deployment. In this command, <namespaceName> is the namespace whether the integration server is deployed: 
      kubectl set env deployment/<integrationServerCRName>-is MQSI_OVERRIDE_HOSTNAME=<integrationServerHostPrefix>.<ingress_subdomain> MQSI_OVERRIDE_HTTPS_PORT=443 -n <namespaceName>

      For example:

      kubectl set env deployment/myis-toolkit-is MQSI_OVERRIDE_HOSTNAME=ace-is.mycluster-a1b2cdef345678g9hi012j3kl4567890-0000.us-south.containers.appdomain.cloud MQSI_OVERRIDE_HTTPS_PORT=443 -n ace-test

      The correct endpoints will be shown when you click the tile for the relevant integration.

      Ingress endpoint for an integration server in the App Connect Dashboard
  • If you want to specify http as the type of transport to be used by the integration endpoint, complete the following steps:
    1. From your local computer, create a YAML file (for example, appconn-ingress-intserverhttp.yaml) with the following content.
      • Set <integrationServerIngressName> to a unique short name by which the ingress can be identified.
      • Set <namespaceName> to the namespace where the integration server is deployed.
      • For an unsecured HTTP endpoint, set <integrationServerHostPrefix> to a unique user-supplied name for the instance, and set <ingress_subdomain> to the ingress subdomain that is typically in the format <cluster_name>-<globally_unique_account_HASH>-0000.<region>.containers.appdomain.cloud. The combined value is used to denote an external endpoint; for example, ace-is.mycluster-a1b2cdef345678g9hi012j3kl4567890-0000.us-south.containers.appdomain.cloud.

        Also use 7800 as the service port. An nginx.ingress.kubernetes.io/backend-protocol annotation does not need to be included in this case because it defaults to HTTP.

        Tip: To check your cluster's default domain, run ibmcloud ks cluster get --cluster <cluster_name> and look for the Ingress Subdomain value in the output.
      • Set <integrationServerCRName> to the metadata.name value in the integration server custom resource.
      apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: <integrationServerIngressName>
  namespace: <namespaceName>
spec:
  ingressClassName: public-iks-k8s-nginx
  tls:
    - hosts:
      - <integrationServerHostPrefix>.<ingress_subdomain>
  rules:
    - host: <integrationServerHostPrefix>.<ingress_subdomain>
      http:
        paths:
        - path: /
          pathType: Prefix
          backend:
            service:
              name: <integrationServerCRName>-is
              port:
                number: 7800
    2. Run the following command to create the ingress: 
      kubectl apply -f appconn-ingress-intserverhttp.yaml
    3. To ensure that the integration server displays the correct endpoints for the deployed integration within the App Connect Dashboard, run the following command to set the ingress external address on the deployment. In this command, <namespaceName> is the namespace whether the integration server is deployed: 
      kubectl set env deployment/<integrationServerCRName>-is MQSI_OVERRIDE_HOSTNAME=<integrationServerHostPrefix>.<ingress_subdomain> MQSI_OVERRIDE_HTTP_PORT=80 -n <namespaceName>

      For example:

      kubectl set env deployment/myis-toolkit-is MQSI_OVERRIDE_HOSTNAME=ace-is.mycluster-a1b2cdef345678g9hi012j3kl4567890-0000.us-south.containers.appdomain.cloud MQSI_OVERRIDE_HTTP_PORT=80 -n ace-test

      The correct endpoints will be shown when you click the tile for the relevant integration.

Creating an ingress route for an integration runtime in the App Connect Dashboard

When you deploy one or more BAR files to an integration runtime, you can indicate whether an HTTP or HTTPS route should be used to externally expose the service that identifies the set of pods where the integration runs. You must manually create this external route for the selected HTTP or HTTPS protocol. These instructions describe how to create an ingress resource for an integration runtime and configure the endpoints in your cluster.

Note: To use an HTTPS route, ensure that TLS is enabled for the integration runtime. Include the following custom resource (CR) settings in the integration runtime's CR before you deploy it or update the CR settings after deployment.
  • Set spec.forceFlowsHTTPS.enabled to true to force all HTTP Input nodes and SOAP Input nodes in all deployed flows in the integration runtime to use TLS.
  • Set spec.forceFlowsHTTPS.secretName to the name of a secret that stores a user-supplied public certificate/private key pair to use for enforcing TLS.
  • Set spec.restApiHTTPS.enabled to https.

Procedure

To create an ingress route for a running integration runtime, complete either of the following steps:

  • If you want to specify https as the type of transport to be used by the integration endpoint, complete the following steps:
    1. From your local computer, create a YAML file (for example, appconn-ingress-intruntimehttps.yaml) with the following content.
      • Set <integrationRuntimeIngressName> to a unique short name by which the ingress can be identified.
      • Set <namespaceName> to the namespace where the integration runtime is deployed.
      • For a secured HTTPS endpoint, set <integrationRuntimeHostPrefix> to a unique user-supplied name for the instance, and set <ingress_subdomain> to the ingress subdomain that is typically in the format <cluster_name>-<globally_unique_account_HASH>-0000.<region>.containers.appdomain.cloud. The combined value is used to denote an external (TLS) endpoint; for example, ace-is.mycluster-a1b2cdef345678g9hi012j3kl4567890-0000.us-south.containers.appdomain.cloud.

        Also include the annotation nginx.ingress.kubernetes.io/backend-protocol: HTTPS, and use 7843 as the service port.

        Tip: To check your cluster's default domain, run ibmcloud ks cluster get --cluster <cluster_name> and look for the Ingress Subdomain value in the output.
      • Set <integrationRuntimeCRName> to the metadata.name value in the integration runtime custom resource.
      apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: <integrationRuntimeIngressName>
  namespace: <namespaceName>
  annotations:
    nginx.ingress.kubernetes.io/backend-protocol: HTTPS
spec:
  ingressClassName: public-iks-k8s-nginx
  tls:
    - hosts:
      - <integrationRuntimeHostPrefix>.<ingress_subdomain>
  rules:
    - host: <integrationRuntimeHostPrefix>.<ingress_subdomain>
        paths:
        - path: /
          pathType: Prefix
          backend:
            service:
              name: <integrationRuntimeCRName>-is
              port:
                number: 7843
    2. Run the following command to create the ingress: 
      kubectl apply -f appconn-ingress-intruntimehttps.yaml
    3. To ensure that the integration runtime displays the correct endpoints for the deployed integration within the App Connect Dashboard, run the following command to set the ingress external address on the deployment. In this command, <namespaceName> is the namespace whether the integration runtime is deployed: 
      kubectl set env deployment/<integrationRuntimeCRName>-is MQSI_OVERRIDE_HOSTNAME=<integrationRuntimeHostPrefix>.<ingress_subdomain> MQSI_OVERRIDE_HTTPS_PORT=443 -n <namespaceName>

      For example:

      kubectl set env deployment/myir-toolkit-ir MQSI_OVERRIDE_HOSTNAME=ace-ir.mycluster-a1b2cdef345678g9hi012j3kl4567890-0000.us-south.containers.appdomain.cloud MQSI_OVERRIDE_HTTPS_PORT=443 -n ace-test

      The correct endpoints will be shown when you click the tile for the relevant integration.

      Ingress endpoint for an integration runtime in the App Connect Dashboard
  • If you want to specify http as the type of transport to be used by the integration endpoint, complete the following steps:
    1. From your local computer, create a YAML file (for example, appconn-ingress-intruntimehttp.yaml) with the following content.
      • Set <integrationRuntimeIngressName> to a unique short name by which the ingress can be identified.
      • Set <namespaceName> to the namespace where the integration runtime is deployed.
      • For an unsecured HTTP endpoint, set <integrationRuntimeHostPrefix> to a unique user-supplied name for the instance, and set <ingress_subdomain> to the ingress subdomain that is typically in the format <cluster_name>-<globally_unique_account_HASH>-0000.<region>.containers.appdomain.cloud. The combined value is used to denote an external endpoint; for example, ace-is.mycluster-a1b2cdef345678g9hi012j3kl4567890-0000.us-south.containers.appdomain.cloud.

        Also use 7800 as the service port. An nginx.ingress.kubernetes.io/backend-protocol annotation does not need to be included in this case because it defaults to HTTP.

        Tip: To check your cluster's default domain, run ibmcloud ks cluster get --cluster <cluster_name> and look for the Ingress Subdomain value in the output.
      • Set <integrationRuntimeCRName> to the metadata.name value in the integration runtime custom resource.
      apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: <integrationRuntimeIngressName>
  namespace: <namespaceName>
spec:
  ingressClassName: public-iks-k8s-nginx
  tls:
    - hosts:
      - <integrationRuntimeHostPrefix>.<ingress_subdomain>
  rules:
    - host: <integrationRuntimeHostPrefix>.<ingress_subdomain>
      http:
        paths:
        - path: /
          pathType: Prefix
          backend:
            service:
              name: <integrationRuntimeCRName>-is
              port:
                number: 7800
    2. Run the following command to create the ingress: 
      kubectl apply -f appconn-ingress-intruntimehttp.yaml
    3. To ensure that the integration runtime displays the correct endpoints for the deployed integration within the App Connect Dashboard, run the following command to set the ingress external address on the deployment. In this command, <namespaceName> is the namespace whether the integration runtime is deployed: 
      kubectl set env deployment/<integrationRuntimeCRName>-is MQSI_OVERRIDE_HOSTNAME=<integrationRuntimeHostPrefix>.<ingress_subdomain> MQSI_OVERRIDE_HTTP_PORT=80 -n <namespaceName>

      For example:

      kubectl set env deployment/myir-toolkit-ir MQSI_OVERRIDE_HOSTNAME=ace-ir.mycluster-a1b2cdef345678g9hi012j3kl4567890-0000.us-south.containers.appdomain.cloud MQSI_OVERRIDE_HTTP_PORT=80 -n ace-test

      The correct endpoints will be shown when you click the tile for the relevant integration.