Deploying a Microservice Architecture on IBM Cloud Code Engine

3 min read

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:

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.

Be the first to hear about news, product updates, and innovation from IBM Cloud