How to enable a microservice architecture Code Engine by deploying a Spring Cloud Eureka Registry Server, a Zuul API Gateway and your own microservices.

This blog post details the ease of deploying a Eureka Registry Server to enable Service Discovery and a Netflix Zuul API Gateway, which routes to any additional microservices you want to deploy. This allows the microservices to only accept traffic through the API gateway. An example of this architecture is displayed below:

Before you begin

Deploying the Registry Server

First, select your Code Engine project:

ibmcloud ce project select --name <Name>

Next, create your application. You will likely always want at least one instance of your registry to be available so your other services can register to it when needed. The port option should match the port specified in your Eureka application’s application.yml file. If the port is 8080, the flag is not needed because Code Engine’s default port is 8080:

ibmcloud ce application create --src . --min-scale 1 --port <port> --name <name> --visibility <visibility>

Note that the visibility is public by default, which means the project will be accessible via the internet. If you would like the application to only be accessible from other Code Engine applications or a private network, you can set it to private.

Once the registry is deployed, you need to take note of the URL to which that registry is

assigned. You will need to add this as an environment variable when deploying the gateway and microservice applications. This URL should look something like this: https://(application name).(randomncharacters).(region).codeengine.appdomain.cloud/

You can find this url using ibmcloud ce application get -n <name>.

Similarly, if you would like to deploy from a prebuilt image, you will need to use the following command, which replaces the  --src tag and adds a registry access secret. If you haven’t created a registry access secret before, take a look at “Accessing Container Registries”:

ibmcloud ce app create --name <name> --image us.icr.io/<your namespace>/<your image name>:latest --registry-secret <your registry secret> --min-scale 1 --port <port>

Deploying the API gateway

Next, create your gateway application. In Eureka applications, the defaultZone field in the application.yml tells the application where to look for the Registry. We can either update this value to be the URL we got from our application above, or we can create an environment variable to overwrite the value. If you choose to create an environment variable, it depends on the version of SpringBoot you are using.

  • Springboot Version < 2.4.5: EUREKA_CLIENT_SERVICEURL_DEFAULTZONE=<registry url>/eureka
  • Springboot Version > 2.4.5: SPRING_APPLICATION_JSON={“eureka”:{“client”:{“serviceUrl”:{“defaultZone”:”<registry url>/eureka”}}}}

If you are deploying from source code, the application create command should be as follows:

ibmcloud ce application create --src . --env <your env> --port <port> --name <name>

Conversely, if you are using a prebuilt image, you can use the following command:

ibmcloud ce app create --name <name> --image us.icr.io/<your namespace>/<your image name>:latest --registry-secret <your registry secret> --env <env variable> --port <port>

Deploying your microservice(s)

The process for deploying a microservice is like what was shown above for the gateway and can be repeated for as many microservices as you have. As shown above, the defaultZone needs to be overwritten in the application.yml file. The environment variable to select is shown below:

  • Springboot Version < 2.4.5: EUREKA_CLIENT_SERVICEURL_DEFAULTZONE=<registry url>/eureka
  • Springboot Version > 2.4.5: SPRING_APPLICATION_JSON={“eureka”:{“client”:{“serviceUrl”:{“defaultZone”:”<registry url>/eureka”}}}}

Additionally, to keep the microservice from having its own URL, so it only accepts requests through the API gateway, the application create command needs to have the --cluster-local flag. This flag makes the application only visible to other applications within the same Code Engine project.

If you are deploying from source, the application create command should be as follows:

ibmcloud ce application create --src . --env <your env> --cluster-local --port <port> --name <name>

If you are deploying from an image, use this command:

ibmcloud ce application create --name <name> --image us.icr.io/<your namespace>/<your image name>:latest --registry-secret <your registry secret> --env <your env> --cluster-local --port <port>

Once your microservice has finished deploying, you can launch your gateway application and test your routing.

Conclusion

Following the steps in this post, you learned how to deploy an API gateway and microservice architecture on IBM Cloud Code Engine

Along with the IBM Cloud CLI, you can also use the IBM Cloud Console to achieve what’s shown above.

If you have any questions, feel free to reach out to me on LinkedIn.

Categories

More from Cloud

Kubernetes version 1.28 now available in IBM Cloud Kubernetes Service

2 min read - We are excited to announce the availability of Kubernetes version 1.28 for your clusters that are running in IBM Cloud Kubernetes Service. This is our 23rd release of Kubernetes. With our Kubernetes service, you can easily upgrade your clusters without the need for deep Kubernetes knowledge. When you deploy new clusters, the default Kubernetes version remains 1.27 (soon to be 1.28); you can also choose to immediately deploy version 1.28. Learn more about deploying clusters here. Kubernetes version 1.28 In…

Temenos brings innovative payments capabilities to IBM Cloud to help banks transform

3 min read - The payments ecosystem is at an inflection point for transformation, and we believe now is the time for change. As banks look to modernize their payments journeys, Temenos Payments Hub has become the first dedicated payments solution to deliver innovative payments capabilities on the IBM Cloud for Financial Services®—an industry-specific platform designed to accelerate financial institutions' digital transformations with security at the forefront. This is the latest initiative in our long history together helping clients transform. With the Temenos Payments…

Foundational models at the edge

7 min read - Foundational models (FMs) are marking the beginning of a new era in machine learning (ML) and artificial intelligence (AI), which is leading to faster development of AI that can be adapted to a wide range of downstream tasks and fine-tuned for an array of applications.  With the increasing importance of processing data where work is being performed, serving AI models at the enterprise edge enables near-real-time predictions, while abiding by data sovereignty and privacy requirements. By combining the IBM watsonx data…

The next wave of payments modernization: Minimizing complexity to elevate customer experience

3 min read - The payments ecosystem is at an inflection point for transformation, especially as we see the rise of disruptive digital entrants who are introducing new payment methods, such as cryptocurrency and central bank digital currencies (CDBC). With more choices for customers, capturing share of wallet is becoming more competitive for traditional banks. This is just one of many examples that show how the payments space has evolved. At the same time, we are increasingly seeing regulators more closely monitor the industry’s…