AVIO Consulting

A SOA Architectural Initiative Quick-Start Checklist

Apr 30, 2015 | SOA

Introduction

With the rollout of CloudHub 2.0 (CH2.0), an enhanced version of MuleSoft’s integration platform, enterprises are presented with many new features and functionalities designed to streamline their operations and boost efficiency. You can find an overview of those features in this blog post.

Central to this upgrade is the imperative task of API migration, a process that requires careful planning, execution, and adaptation. The objective of this blog is to assist technical individuals responsible for overseeing their organization’s MuleSoft platform in navigating the technical aspects of this transition. Here we describe the main steps of CH2.0 API migration, offering insights, best practices, and practical tips to facilitate a smooth transition for organizations.

We aim to provide clear guidance while instilling assurance that AVIO Consulting stands ready as the trusted partner to lead you through this process.

Migration

There is not a built-in feature to migrate your existing infrastructure (VPC/VPN/DLB) from CloudHub 1.0 (CH1.0) to CH2.0. If you’re using these specific infrastructure features, you will have to establish and customize a fresh private space, create a new VPN connection, and make necessary adjustments to your applications before launching them on the new runtime.

CH2.0 requires 4.3.0+ runtimes, so if your APIs run on lower runtime versions, this is the moment to upgrade them. If not, the APIs are good to go to CH2.0 with no runtime version changes.

Private Spaces

VPCs from CH1.0 are called Private Spaces in CH2.0. The first step in setting up a CH2.0 environment is to create and configure these private spaces.

You can deploy the APIs to a shared space with not much configuration, but a private space is needed if you want to take advantage of features like TLS context (vanity domains), firewall rules (ingress and egress rules), inbound and outbound static IPs, and VPNs. Best practices recommend that one private space is created for the non-prod environments and another one for a production environment.

Once you have created a private space, you have to provision the private network in it, defining a region where the APIs will run and a CIDR block for the private network. The IP range must be chosen and defined with the network team, taking care not to use a range that overlaps with another one in use by other Private Spaces, CH1.0 VPCs, or even by the local company network. This article defines what a CIDR block is and provides insight on how to best choose the appropriate range.

 

The Private Space configuration is a bit different from the VPCs. All configurations are in the Private Space area on Runtime Manager. There is no need to create Dedicated Load Balancers because CH2.0 has a built-in feature called Ingress Controller that acts as a dedicated load balancer (DLB) and is included with the Private Space. So, the private network, firewall rules, VPN, and advanced configurations are all together.

Reconfiguring network

If your APIs connect to on-prem services like databases or other systems, new VPN connections must be created. It’s not possible to reuse the VPN connections used by the VPCs or to create a VPN to connect VPCs to the new Private Spaces.

This task must be done along with the network team. Once you have defined the routing type and some other details about the VPN, you can create the connection and then Anypoint Platform generates a connection guide with all the information needed by the network team to set up the connection from the internal network.

In the Firewall rules tab, you can configure a Private Space level firewall. To secure your CH2.0 applications, you should configure the Private Space level firewall rules to allow traffic to and from specific IP addresses and ports. You can set the ingress and egress of your application traffic with the firewall rules. You can also control egress traffic at the application level in CH2.0, restricting the applications running in your Private Space to connect to specific destinations only.

CH2.0 also brings inbound and outbound static IPs at the Private Space level. Three addresses are provided for each group. That way you have static IPs to use for whitelisting purposes.

Adjustments to code / configurations

Property files

The CH2.0 default port is 8081 for HTTP or HTTPS. The main change you must make is to change the http.port property in the property files and set that property to the API Listener. The Ingress Controller only uses that port to reach APIs in the Private Space. If you need, for any reason, to have APIs listening on a different port, it’s possible, but those APIs must be reached by other APIs in the private space, not by external access through the Ingress Controller.

Another change must be made to the requester URLs. An API can hit another one in the same Private Space by using just the protocol, the API name, and the port, like this: http://application-name:8081/basepath

If you need to connect APIs deployed to CH2.0 to APIs deployed to CH1.0, the connectivity must be granted by the DLB, and this communication must be released by the firewall rules. Mapping rules must be created to allow external access to the API in CH1.0. This scenario is usual during the migration process when some APIs are migrated and others haven’t been yet. If you have that need, you also must update the requester URLs to make it hit the other API through the external address provided by the DLB. In such cases, the ports are the external ones: 80 (HTTP) or 443 (HTTPS).

Pipelines

The deployment process has now a new stage, which is the Exchange application deployment. This means that before deploying the application to the Private Space (Runtime Manager), you need to publish the application .jar file to Exchange. It acts as a maven repository for deployable project assets and this step is mandatory for the deployment process if you are using the mule maven plugin, and it also requires changes to the pom.xml file.

Before deploying, CH2.0 will look for the same asset in Exchange. If the asset is not present, the deployment will fail.

So, for sending the artifact to Exchange, the maven command is this:

mvn clean deploy

After that, you can run this command to finally deploy the API:

mvn clean deploy -DmuleDeploy

You have to update the pipelines whatever method you are using for deployments, and add that task before the API deployment main task.

Conclusion

The transition from CloudHub 1.0 to CloudHub 2.0 marks a considerable advancement, with advantages and improvements that make it worthwhile for businesses aiming to enhance efficiency and scalability in their integration procedures.

AVIO Consulting, recognized as a reliable MuleSoft collaborator, is fully prepared to assist you in navigating this progression, guaranteeing a seamless and assured shift. Reach out to our team today to gain insight into how this transition will impact your organization.