Deploying microservices to IBM Cloud

Log in to IBM Cloud by using the ibmcloud command line. When you are prompted to select a region, choose us-south. This allows you to create a free cluster, which is limited to specific regions. Note that if you are using a federated user ID, you will have to use the --sso flag to get a one-time code for single sign-on.

To create a Kubernetes cluster, you need Administrator access to IBM Cloud Kubernetes Service. To confirm that you have Administrator access, navigate to the IBM Cloud Dashboard. Then, navigate to Manage > Access (IAM) > Users > [Your Username] > Access Policies and confirm that Administrator is listed as a policy for all resources in the account or for the Kubernetes service.

Once you have confirmed that you have appropriate permissions, use the following command to provision a cluster.

This command provisions a free cluster that expires in a month if you do not delete it.

Check the current status of your cluster.

Wait until your cluster is in the normal state before proceeding. It will start off in the deploying state.

Next, it will transition to the pending state.

Finally, it will transition to the normal state. It may take a while for IKS to prepare your cluster.

Once your cluster is ready, connect kubectl to the cluster.

Verify that you’re connected to the cluster by checking the cluster’s nodes.

The first step of deploying to Kubernetes is to build and containerize your microservices.

The starting Java project, which you can find in the start directory, is a multi-module Maven project. It’s made up of the system and inventory microservices. Each microservice resides in its own directory, start/system and start/inventory. Each of these directories also contains a Dockerfile, which is necessary for building Docker images. If you’re unfamiliar with Dockerfiles, check out the Containerizing Microservices guide.

To build these microservices, navigate to the start directory and run the following command:

Next, run the docker build commands to build container images for your application:

The -t flag in the docker build command allows the Docker image to be labeled (tagged) in the name[:tag] format. The tag for an image describes the specific image version. If the optional [:tag] tag is not specified, the latest tag is created by default.

During the build, you’ll see various Docker messages describing what images are being downloaded and built. When the build finishes, run the following command to list all local Docker images:

Verify that the system:1.0-SNAPSHOT and inventory:1.0-SNAPSHOT images are listed among them, for example:

If you don’t see the system:1.0-SNAPSHOT and inventory:1.0-SNAPSHOT images, then check the Maven build log for any potential errors.

Pushing the images to a registry enables the cluster to create pods by using your container images. Since it’s a private repository, only users with access to your IBM Cloud account will have access to these images.

The registry you will use is called IBM Cloud Container Registry. Use the container registry plug-in to create a namespace for your container images. The namespace must be unique within IBM Cloud for the region you selected, so choose something relevant that you’ll remember for the duration of the guide.

Use the plug-in again to log in to the container registry.

Next, tag your container images with the relevant data about your registry. Remember to replace [your-namespace] with the namespace you created earlier in the guide.

Finally, push your images to the registry. Remember to replace [your-namespace] with the namespace you created earlier in the guide.

Helm is a package manager for Kubernetes. It allows you to create a package called a chart. You can install a chart on your cluster as a release and then manage the release using Helm.

Set up role-based access control (RBAC) to give Helm’s Tiller server admin access to your cluster. Deploy the service account and cluster role binding that is required for the Tiller.

Next, install Tiller to your cluster. Specify that the Tiller should run under the service account that was created in the previous step.

After the command completes, you will see output similar to the following.

All pods run under a service account. By default, your pod runs under the default service account for your namespace. Helm’s Tiller server is running under the tiller service account. The tiller service account is bound to the cluster role cluster-admin. This role grants access to all resources in your cluster. Therefore, the Tiller server has access to all of your cluster’s resources.

Add the ibm-charts repository to your local list of Helm repositories. Adding the repository allows you to use the ibm-open-liberty chart.

Use Helm to deploy the system microservice. Remember to replace [your-namespace] with the namespace you created earlier in the guide.

Use Helm to deploy the inventory microservice. Remember to replace [your-namespace] with the namespace you created earlier in the guide.

After you run helm install, an output is displayed providing instructions on how to access your deployed microservices. Ignore these instructions for now, you will learn how to access your microservices in the next section.

The --name flag specifies the release name, which must be unique. This is the name that Helm uses to identify this specific deployment of your chart. The following table gives an overview for each of the parameters specified using --set.

The service used to expose our deployments has a type of NodePort. This means you can access these services from outside of your cluster via a specific port. In this case, since nodePort is not specified, the ports are randomized so you must obtain the ports before making requests to the services. You must also obtain the public IP address of our cluster. Note that there are other ways to expose your services such as using a LoadBalancer service type or using an Ingress. In production, you would most likely use an Ingress.

First, find the current context of your cluster.

Take note of the context shown in the command’s output.

Then, substitute the context into the following command to get the public IP address of your cluster.

Take note of the Public IP in the command’s output. This will be the hostname you substitute into commands later in this guide.

Get the node port of the system microservice.

Get the node port of the inventory microservice.

Take note of the IP address and ports. They are required to make the HTTP requests.

To make a request to the system and inventory microservices, curl or visit the following URLs to access your microservices, substituting the appropriate hostname and node ports:

The first URL returns system properties and the name of the pod in an HTTP header called X-Pod-Name. To view the header, you can use the -I option in the curl when making a request to http://[hostname]:[system-node-port]/system/properties. The second URL adds properties from system-service to the inventory.