Lab 2 - Application Management - ROKS

Note: ‘This lab is to be used for CP4MCM 2.1.X on ROKS.’

IBM Cloud Pak for Multicloud Management provides consistent visibility, automation, and governance across a range of multicloud management capabilities such as cost and asset management, infrastructure management, application management, multi-cluster management, edge management, and integration with existing tools and processes. Customers can leverage Cloud Pak for Multicloud Management to simplify their IT and application ops management, while increasing flexibility and cost savings with intelligent data analysis driven by predictive signals.

Customers can leverage IBM Cloud Pak for Multicloud Management to simplify their IT and application ops management, while increasing flexibility and cost savings with intelligent data analysis driven by predictive signals.

In this tutorial, you will explore the following key capabilities:

As a member of the Cloud Operation team, you are having problems to manage your multicloud hybrid world. Operate your cloud-based services and data across multiple providers is overwhelming your team. Your company is deploying multiple Kubernetes clusters to address their specific needs. Some Dev teams are deploying clusters across public and private clouds, and some are deploying clusters across regions, and some are deploying clusters to support the development and test needs.

As different teams deploy more clusters, new challenges are introduced:

Because of that, you want to explore how IBM Cloud Pak for Multicloud Management, provides consistent visibility, governance and automation of your complex environment.

IBM Cloud Pak for Multicloud Management provides enhanced application management capabilities through an improved application model and deployment options. The concept helps simplify and streamline application life cycle management across clusters.

In this tutorial, you will be using a sample Modresort application to demonstrate how to deploy an application in multiple clusters using channels and subscriptions. The Modresort is a WebSphere Liberty Java application available in Dockerhub.

In this tutorial, you use two Red Hat OpenShift clusters.

You will complete the following tasks:

IBM Cloud Pak for Multicloud Management provides enhanced application management capabilities through an improved application model and new deployment options. The new model and deployment options are designed to unify and simplify the deployment experience for creating and managing your applications across clusters.

The new application management capabilities use Channels and Subscriptions to gain improved continuous and automated delivery of deployables to target managed clusters.

The concept is similar to subscription model of TV channels. In this model, all the applications, which are packaged as helm charts, will be hosted in one or more repositories. The repositories, which contain the application packages, are defined as channels that broadcast across the clusters. If you want to deploy an application, then define a subscription to the channel with the name of the application (one or more) you want to deploy

Channels (Channel.app.ibm.com) define a namespace within the hub cluster and point to a physical place where resources are stored for deployment; such as an object store, Kubernetes namespace, or Helm repository.

In this section, you define Application and Channel resources to deploy the Modresort application. The resources will be created using YAML files. The modresort application is a simple application with only one component.

1.Back to the terminal window, let’s create our YAML files to define Channel, Application, Subscription, etc. To simplify the lab steps, you will clone a pre-created YAML. Don’t worry, because we will understand them. To copy pre-created YAML files, let’s use the Git CLI (if you don’t have Git CLI, check here how to install it). Run the command below:

2.Now you have two folders (modresortchan and modresortapp). Let’s start exploring the modresortchan and use any editor to see the content of the channel.yaml file.

3.Our channel.yaml has the content below.

It is a really simple file. The spec collection defines the type of the channel. In this lab, the channel is of type namespace, meaning that the yaml you create will be deployed and stored in OpenShift namespaces rather than in a Helm chart or Object store. This file is ready, and you don’t need to edit it, go ahead and close the channel.yaml file.

4.The modresort application component consists of a deployment resource definition and a service resource definition.

To enable these components to be used by the channel subscription, each of the resources need to be wrapped by a new custom resource definition (CRD) called Deployable.

Use your editor again and check now the deployable.yaml file.

There are three Deployables defined in the yaml file that wrap the modresort Kubernetes resources

Refer to the online documentation for details on the construct of the Deployable definition.

As you can see, at the end of the file, there is a host attribute. Here you should replace the <your_ingress_subdomain>.

5.To get your Ingress Subdomain, you can access IBM Cloud and check this info in your Multicloud Management Openshift cluster view, or an easier option is: you received an email when you requested your environment (just check to open the email for Multicloud Management Pak environment). In this email there is a Cluster URL link.

In this Cluster detail page, you should see the Ingress Domain.

6.Back to the Terminal window, replace <your_ingress_subdomain>. Save and close the deployable.yaml.

Next section, you learn how to create a subscription.

The subscription to a channel package contains

Applications (Application.app.k8s.io) in IBM Multicloud Manager are used for grouping application components.

Placement rules (PlacementRule.app.ibm.com) define the target clusters where deployables can be deployed. You can use placement rules to help you facilitate the multi-cluster deployment of your deployables. Placement rules can be referenced by deployables and subscriptions.

Subscriptions (Subscription.app.ibm.com) are sets of definitions that identify deployables within channels by using annotations, labels, and versions.

The subscription controller can monitor the channel for new or updated deployables, such as an updated Helm release or a new Kubernetes deployable object. Then, the controller can download the Kubernetes deployable object or Helm release directly from the source location (Helm repository, object store, or namespace) to the target managed clusters.

1.Back to the terminal window, let’s explore the YAML files on modresortapp folder.

2.Now, using your editor again, open the application.yaml. Below is the content of the file:

Here we have the definition of our modresort application. Refer to the online documentation for details on configuring the Application resource.

3.Close the application.yaml file.

4.Use your editor again, to explore the placementrules.yaml file. Below is the file’s content:

Placement Rules defines where and how Helm charts and deployables are deployed. Use placement rules to help you facilitate multi-cluster deployments of your deployables. Refer to the online documentation for details on configuring the Placement Rules resource.

In your case, the placementrules.yaml is defining to deploy the modresortapp in Dev environment only.

5.Close the placementrules.yaml file.

6.Now, let’s explore the subscription.yaml file.

This contains the details of relating the placement rule definition with the application specification. Refer to the online documentation for details on configuring the Subscription resource.

7.Close the subscription.yaml file. All your files are ready to deploy the application.

This completes enabling an existing application with policies so that they can be deployed to any Kubernetes managed cluster. Next section, you deploy the application using the channel and subscription created here.

In this section, you will deploy the application components to their respective Kubernetes namespaces, using the yaml files that you created in the previous task.

1.Back to the terminal window, set the context to use your Hub Cluster.

2.You should be already logged in your Hub Cluster. Run the command bellow to confirm it:

Only if you are not logged in, you can run the command below to log in to Hub Cluster:

3.Execute the command bellow to create two new Openshift projects.

4.Now, let’s deploy the modresortchan. Execute the commands below:

The output of the above command will be similar to the illustration below. The output shows that Channel and Deployables are deployed.

5.The subscription is deployed to a different namespace than the channel. Never deploy the subscription to the same namespace as the channel. Hence, deploy the subscription to the other namespace, modresort-project.

Next section of the lab will walk you through validating the application deployment.

The Application view in Cloud Pak for Multicloud Management console provides graphical view into the applications, channels and subscriptions deployed in the clusters. Let’s validate if the modresort application is deployed correctly.

1.Back to the browser, you should be in your Cloud Pak for Multicloud Management Web Console. If you are not, check here how to open your console page.

2.On the top left of the page, open the Menu (1) and select Manage Applications (2) and click Hybrid applications (3).

3.Click on the modresort101-modresortapp application link to get to the application Overview page.

4.Scroll down to view the application diagram.

Note: It may take a couple of minutes for the application to deploy to the cluster.

When the application is successfully deployed via the subscription, the pod in the application topology view will have a green icon as illustrated below.

Note (Only if you have issues): After a couple of minutes, if your pod has a yellow icon next to the pod, indicating it is in an unknown state, you will need to troubleshoot your yaml files for correctness and redeploy the resources. Verify that your subscriptions are propagated correctly by running the command.

The subscription from the mcm hub should be in the Propagated state.

5.Back to the terminal window, let’s check the pods are in running state.

You should see the devchan-modresort-deployment pod running in the default namespace

6.Use the command line to get the devchan-modresortchan-service NodePort.

Take note of the devchan-modresortchan-service nodePort (on the picture above is 30606), you will use it to access your application.

7.Back to the browser, open a new tab and navigate to:

Congratulations! You have successfully deployed the modresorts application to the local OpenShift Cluster.

Applications deployed using the Subscription model are deployed to clusters based on PlacementRules. The placement rules for deployables can be defined as a stand-alone resource and referenced by the deployable. The placement rules use cluster labels to determine where to place the applications.

In the following steps, you will move the application from the Dev cluster to the QA cluster by changing the placement policy. You also learn how to use cluster replicas.

1.Currently, the application deployed as running on Dev cluster because of the placement values specified in application, as you verified earlier.

You can modify the placement policies from application view by selecting the placement policy and modifying the corresponding values in the yaml file. Let’s do it!

Back to the Multicloud Management page, on the Resource topology chart, click on the modresortapp101 placement policy icon.

2.On the Editor, modify the environment setting from Dev to QA.

3.Apply changes by clicking on update icon as shown below.

4.Within a few minutes, the cluster value changes from hub-cluster to managed-roks, and the application is now running on managed cluster instead of hub cluster.

5.To validate that the application moved from the hub-cluster to the managed-roks, back to the Terminal window and change your kubectl context to use your managed-roks cluster:

6.Check that devchan-modresortchan-deployment pod is running, executing the command below:

7.Execute the command below to get the service port.

Make a note of the nodePort value to access the UI (in the picture below the NodePort is 30970).

8.Now, you need to see the ingress subdomain of your Managed Node (ROKS of Cloud Pak for Apps). Let’s do the same step that you did to get the ingress subdomain of Cloud Pak for Management ROKS. Open the e-mail that you received when you requested the Cloud Pak for Apps environment, and open the Cluster URL Link.

In this Cluster detail page, you should see the Ingress Domain (confirm on the top, that you are on the Cloud Pak for Apps cluster).

9.Open another browser tab and access the application running on managed-roks cluster using the following link:

Great, you moved the application from one cluster to the other.

10.What if you want to run the application on both the clusters? This is possible by changing clusterReplicas and matchingLabel. Let’s do it!

Back to the Multicluster Management page, on the Editor, change clusterReplicas to 2.

11.On the spec matchLabels setting, remove the environment label, and add vendor label with value Openshift.

The label, vendor, exists on both the clusters and the value matches OpenShift.

12.Apply the changes by clicking update icon.

13.Within a few minutes, the resource overview refreshes, indicating that the application is running on both clusters. You can validate by checking the status of pods on both the clusters

Great, now you have your application on both clusters. Next section, you explore Grafana dashboard to visualize the application health across clusters.

You completed the Cloud Pak for Multicloud Management tutorial: Multi-cluster Management. Throughout the tutorial, you explored the key takeaways:

If you would like to learn more about Cloud Pak for Multicloud Management, please refer to: