Manually creating ingress definitions for IBM App Connect instances at version 13.0.2.0-r1 or earlier in an IBM Cloud Kubernetes Service cluster

Kubernetes-only contentUse these instructions to expose your deployed App Connect Dashboard, App Connect Designer, integration runtime, and switch server instances in an IBM Cloud Kubernetes Service environment to external traffic. If you have enabled the API for IBM App Connect in containers to administer resources in the App Connect Dashboard, you also need to expose the API to external traffic.

Note:

If you are running IBM App Connect Operator 12.8.0 or later on IBM Cloud Kubernetes Service, you no longer need to manually create ingress definitions for your IBM App Connect instances. IBM App Connect Operator 12.8.0 introduces the facility to automatically create and manage ingress resources. When you create or update your IBM App Connect instances, you can enable ingress in the custom resource settings, which results in the requisite ingress resources being created. For more information, see Automatically creating ingress definitions for IBM App Connect instances in an IBM Cloud Kubernetes Service cluster.

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 (and API if enabled), App Connect Designer, 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. Run this ibmcloud command to list the IDs of all ALBs in the cluster, 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 IDs that start with public.

    The following example shows output for a Classic cluster.
    ALB ID                                            Enabled   Status     Type      ALB IP          Zone    Build                    ALB VLAN ID   NLB Version
private-crdf253b6025d64944ab99ed63bb4567b6-alb1   false     disabled   private   -               dal12   ingress:1.1.2_2507_iks   2294021       -
private-crdf253b6025d64944ab99ed63bb4567b6-alb2   false     disabled   private   -               dal10   ingress:1.1.2_2507_iks   2234947       -
public-crdf253b6025d64944ab99ed63bb4567b6-alb1    true      enabled    public    169.48.228.78   dal12   ingress:1.1.2_2507_iks   2294019       -
public-crdf253b6025d64944ab99ed63bb4567b6-alb2    true      enabled    public    169.46.17.6     dal10   ingress:1.1.2_2507_iks   2234945       -
    The following example shows output for a VPC cluster. 
    ALB ID                                            Enabled   Status     Type      Load Balancer Hostname                 Zone         Build
private-crdf253b6025d64944ab99ed63bb4567b6-alb1   false     disabled   private   -                                      us-south-2   ingress:1.1.2_2507_iks
private-crdf253b6025d64944ab99ed63bb4567b6-alb2   false     disabled   private   -                                      us-south-1   ingress:1.1.2_2507_iks
public-crdf253b6025d64944ab99ed63bb4567b6-alb1    true      enabled    public    23f2dfb1-us-south.lb.appdomain.cloud   us-south-2   ingress:1.1.2_2507_iks
public-crdf253b6025d64944ab99ed63bb4567b6-alb2    true      enabled    public    23f2dfb1-us-south.lb.appdomain.cloud   us-south-1   ingress:1.1.2_2507_iks

  2. From your local computer, create a YAML file (for example, appconn-ingress-configmap.yaml) for a ConfigMap object named ibm-ingress-deploy-config. In the YAML sample, replace <alb1_id> to <albN_id> with the individual public ALB IDs from the previous step. The enableSslPassthrough setting enables SSL passthrough for the ALBs, and ensures that the TLS connection is not terminated and passes through untouched.
    apiVersion: v1
kind: ConfigMap
metadata:
  name: ibm-ingress-deploy-config
  namespace: kube-system
data:
  <alb1_id>: '{"enableSslPassthrough":"true"}'
  <alb2_id>: '{"enableSslPassthrough":"true"}'
...
  <albN_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>

    Wait while the changes are applied to your ALBs.

  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. 
      kubectl get pods -n kube-system | grep alb

      These ingress pods are named in the format public-<cluster_id>-albN-*, where N represents an integer; for example: public-crdf253b6025d64944ab99ed63bb4567b6-alb1-5d6d86fbbc-kxj6z.

    2. Get the logs for the ALB pods.
      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 (and API if enabled), App Connect Designer, 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 resource 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 resource 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.
    • If the Dashboard was deployed with multiple replica pods, you must add an nginx.ingress.kubernetes.io/affinity annotation with an affinity type of cookie to metadata.annotations, as shown in the following example:
      kind: Ingress
apiVersion: networking.k8s.io/v1
metadata:
  name: <dashboardIngressName>
  namespace: <namespaceName>
  annotations:
    nginx.ingress.kubernetes.io/backend-protocol: HTTPS
    nginx.ingress.kubernetes.io/affinity: cookie
...
    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 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 resource for an API that is enabled for the App Connect Dashboard

Create an ingress resource that will be used to route external traffic to an API for IBM App Connect in containers, which 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 resource for an API that is enabled for the Dashboard, 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's API; for example, ace-dash-api.mycluster-a1b2cdef345678g9hi012j3kl4567890-0000.us-south.containers.appdomain.cloud. Only one host name can be specified for an 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 make API calls to administer resources in the App Connect Dashboard instance by providing the following URL as the base URL (and appending an operation path):

    https://<dashboardHostPrefix>.<ingress_subdomain>

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

Creating an ingress resource for a switch server

To expose a switch server to external traffic, you must create an ingress resource 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 resource 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: "false"
    nginx.ingress.kubernetes.io/ssl-passthrough: "true"
spec:
  ingressClassName: public-iks-k8s-nginx

  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 resource 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 runtime is automatically deployed to provide support for the built-in test facility for flows. After you create an ingress resource for a Designer instance, you will also be required to create an ingress resource for this integration runtime as described in Creating an ingress resource for the internal integration runtime that is deployed for App Connect Designer.

Procedure

To create an ingress resource 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 resource 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 resource for the internal integration runtime that is deployed for App Connect Designer.

Creating an ingress resource for the internal integration runtime that is deployed for App Connect Designer

When you create an App Connect Designer instance, the IBM App Connect Operator automatically deploys an internal integration runtime for that Designer instance. This integration runtime supports your Designer flows and enables you to verify the behavior of a running API flow by using the built-in test facility to call the endpoints for the implemented API operations. The internal integration runtime is named <designerAuthoringCRName>-designer by default.


You must create an ingress resource that will be used to route external traffic to this integration runtime 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 resource for the internal integration runtime that is deployed for a Designer instance, complete the following steps:

  1. From your local computer, create a YAML file (for example, appconn-ingress-desauthruntime.yaml) with the following content, where:
    • <designerAuthoringIRIngressName> is a unique short name by which the ingress can be identified.
    • <namespaceName> is the namespace where the Designer instance is deployed.
    • <designerAuthoringIRHostPrefix> 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 runtime'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: <designerAuthoringIRIngressName>
  namespace: <namespaceName>
  annotations:
    nginx.ingress.kubernetes.io/backend-protocol: HTTPS
spec:
  ingressClassName: public-iks-k8s-nginx
  tls:
    - hosts:
      - <designerAuthoringIRHostPrefix>.<ingress_subdomain>
  rules:
    - host: <designerAuthoringIRHostPrefix>.<ingress_subdomain>
      http:
        paths:
        - path: /
          pathType: Prefix
          backend:
            service:
              name: <designerAuthoringCRName>-designer-ir
              port:
                number: 7843
  2. Run the following command to create the ingress: 
    kubectl apply -f appconn-ingress-desauthruntime.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://<designerAuthoringIRHostPrefix>.<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 runtime in the App Connect Designer

Creating an ingress resource 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 resource 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>-ir
              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>-ir 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>-ir 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.