What's new?

In App Connect Operator 12.11.0 and IntegrationRuntime 13.0.3.0, we’re introducing a new way to expose TCPIP Server ports externally when deploying ACE flows in a containerized environment. This enhancement simplifies the process of managing external access to TCPIP Server nodes while keeping your configuration clean and centralized.

Previously, exposing TCPIP Server ports required either modifying the default service (which also exposed internal ports like the Admin API) or manually creating and managing a separate Kubernetes service. With this new feature, you can now define the specific TCPIP ports you want to expose directly in the IntegrationRuntime custom resource (CR), and the operator will handle the rest.

Why is this useful?

When deploying ACE flows that use TCPIP Server nodes, it’s common to need external access to those ports. Until now, the options were:

• Option A: Add the TCPIP port to the existing service in the CR and set the service type to NodePort to expose it via a node port. This exposes all default ports externally—including sensitive ones like the Admin API.
• Option B: Manually create a separate NodePort service for the TCPIP ports, which requires manual lifecycle management and adds operational overhead.

This new feature eliminates the need for workarounds by allowing you to define a dedicated NodePort service directly in the CR, scoped only to the ports you want to expose.

How does it work?

If you’re using a TCPIP Server node in your flow with settings like the following in the Toolkit:

You’ll want to define a nodePortService in your IntegrationRuntime CR like this:

spec:
  nodePortService:
    ports:
      - protocol: TCP
        name: tcpip-server
        nodePort: 32000
        port: 9910
        targetPort: 9910

When this field is specified, the operator automatically creates a new Kubernetes service with the ports you define. The service is named using the IntegrationRuntime name followed by -np-ir. For example, if your IntegrationRuntime is named my-runtime, the service will be called my-runtime-np-ir.

This way ensures that only the specified TCPIP ports are exposed externally, without affecting internal ports or requiring manual service management.

Things to keep in mind

There are a few important limitations and considerations:

• NodePort range: Most Kubernetes platforms restrict NodePort values to a specific range, typically 30000–32767. If you specify a nodePort, make sure it’s within this range and not already in use. Alternatively, you can omit the nodePort field and let Kubernetes assign an available port automatically. If you do this, you can find the automatically assigned nodePort by finding the Service in the same namespace as the IntegrationRuntime CR with the name of the CR and the -np-ir postfix.

• Service deletion: In the current release, if you remove the nodePortService section from the CR, the associated service is not automatically deleted. This is a known issue and will be resolved in Operator version 12.12.0 0 and IntegrationRuntime 13.0.3.1.

• Network policies: In this release, the operator does not automatically update network policies to allow traffic to the newly exposed ports. If your cluster uses restrictive network policies, you’ll need to manually update them to permit access to the NodePort service. Automatic handling of network policies is planned for a future release.

Try it now

If you're using version 12.11.0 or later of the App Connect Operator, you can try out this new feature by upgrading your integration runtimes to version 13.0.3.0 or later. Simply add the nodePortService section to your IntegrationRuntime CR and deploy your flow with TCPIP Server nodes.