IBM Multicloud Manager getting started guide

Information about installing IBM Multicloud Manager
Deploy a Helm chart from the Catalog to specific clusters
Deploy an application and view topology
Gather information and move your application
Set-up failover of the application by using the CLI
Applying cluster policy

Information about installing IBM Multicloud Manager

Prerequisites

You need access to an IBM® Cloud Private environment. Learn about IBM Cloud Private and how to set up your environment from the product overview.
You need to install Docker. To install Docker, see Install Docker .
You need the Kubernetes command line tool, kubectl. To install kubectl, see Install and Set Up kubectl .
You need Helm. See Installing the Helm CLI (helm) for IBM Cloud Private to install Helm.
You need the IBM Cloud Private CLI, cloudctl. See Installing the IBM Cloud Private CLI to install the CLI.

See the IBM Multicloud Manager installation overview to install IBM Multicloud Manager and get started with the following basic procedures:

Deploy a Helm chart from the Catalog to specific clusters

From the console, click Overview, then view the summary of the environment.
Click Clusters. Ensure that the details in the cluster table is populated and correct.
Click Pods. Ensure the details in the pod summary table is complete and accurate.
Click Catalog to launch the IBM Cloud Private Helm chart catalog. In the Search bar, for example, enter nginx, then click on the chart that is titled ibm-nginx-dev.
Click Configuration, then enter any Helm release name, such as mynginx. From the Target namespace menu, choose the default namespace, kube-system, for deployment.
Read and agree to the License agreement.
Click Remote Install. Now you can select and view one or multiple Target cluster(s) and click Install.
From Helm Releases, enter nginx in the search bar. View your Helm release.
Navigate to Clusters to locate the cluster that you deployed your Helm chart on. Click launch from the Endpoint column. You are then launched to the console of the target managed-cluster. Enter Username and _Password_and click Log in, if required.
On the console for the managed-cluster, click Workloads > Deployments. Search for the Helm release name and ensure that it exists in the summary table.

Now you created a remote deployment and you can proceed to the next section.

Deploy an application and view topology

Click Applications, then click Create Application.
Type or paste content from your application YAML file and click Create application.
Ensure the application appears in the applications table and the Created field is current.
Click on the Application name and find the application. Click Application Details and verify that the details are correct.
Click on the Diagram tab and confirm that you see topological representation of the application, such as applications, deployables, and charts. You can filter, zoom, and navigate the topology view.

Gather information and move your application with the IBM Multicloud Manager CLI

To view your pods from the IBM Multicloud Manager CLI, you must have the CLI installed. Run the following command to view your cluster:
```
kubectl get pods --all-namespaces
```
To view your applications from the IBM Multicloud Manager CLI, you must have the CLI installed. Run the following command:
```
 kubectl get applications
```
To view your clusters from the IBM Multicloud Manager CLI, you must have the CLI installed. Run the following command:
```
 kubectl get clusters --all-namespaces
```
To get more detailed information about your clusters. Run the following command:

kubectl describe clusters --all-namespaces {: codeblock}
To move your application, edit the placement policy using the kubectl command. Run -n kube-sytem to set the namespace. See the following command:
```
 kubectl edit placementpolicy demo-gbapp -n kube-system
```
The placement policy opens in the editor. Scroll and change the value of clusterReplicas to 2. Edit and quit the editor to push the application to another cluster.
Confirm that the application is running on both clusters by running the following command:
```
 kubectl edit placementpolicy demo-gbapp -n kube-system
```
This opens the placement policy in the editor. Scroll to the status section in the policy. Confirm that the application moved to another cluster, or is running on multiple clusters.

Application Fail-over

For fail-over to work, you need at least two clusters, and the cluster selector in the placement policy for application must be configured so that it selects these clusters. In the following example, clusterReplicas is set to 1.

Confirm that placement policy is configured for failover. Edit the placement policy using the kubectl command and run -n kube-sytem to set the namespace. See the following demo-gbapp command:
```
 kubectl edit placementpolicy demo-gbapp -n kube-system
```
The placement policy should look similar, where the clusterLabel is configured to select more than one cluster. Additionally, the clusterReplicas parameter is set to 1.
```
 clusterLabels:
   matchLabels:
     datacenter: ohio
     environment: Dev
     vendor: ICP
 clusterReplicas:1
 resourceHint:
   type: cpu
 resourceHint: {}
```
If one of the clusters are in an airgap environment, the application automatically moves to the secondary cluster.
Test the fail-over by logging into the virtual machine of the managed-cluster that you want to take offline:

Run the following command:
```
 ssh root@192.168.1.120
```
Next, obtain the Docker container ID of the Klusterlet.
```
 docker container ls | grep mcm-klusterlet
```
Pause the container to temporarily force the cluster offline:
```
 docker pause <container-id>
```
On the hub cluster, confirm that the cluster is offline:
```
 kubectl get clusters --all-namespaces
```
Confirm that the application is running on the secondary cluster by editing the placement policy viewing the status:
```
 kubectl edit placementpolicy demo-gbapp -n kube-system
```
Be sure to resume your managed cluster by running the following command on the virtual machine of your managed-cluster:
```
 docker unpause <container ID>
```

Compliance and policies

Log in to IBM Multicloud Manager management console and navigate to Policies to create and view Cluster Compliances:
Click on Create Compliance. You can type or paste content from your YAML file. Then click on Create Compliance .
Click on the compliance name to view the compliance overview. You will see the individual policies of the compliance and the overall status of the compliance in this view.
You can also create a policy by using the command-line interface. Log into the hub-cluster with the kubectl command:
```
 kubectl apply -f  ./test-compliance.yaml -n mcm
```
To get the compliances, run the following command:
```
 kubectl get compliances --all-namespaces
```
To get the policies, run the following command:
```
 kubectl get policies --all-namespaces
```
Run the following command to get the roles:
```
 kubectl get roles --all-namespaces
```
Because the compliance policy is enforced, the policy should let you delete the operator role in the default namespace. Test the policy with the following command:
```
kubectl delete role operator -n default
```
View roles again to confirm that the operator role still exists:
```
kubectl get roles --all-namespaces
```
The enforced compliance policy is working.

Conclusion

Pods and clusters are visualized under one pane. A user in an ops admin role can quickly identify problems in a single view in both a console and from the command-line tool.

IBM Multicloud Manager helps users manage applications. Application policies can be written by a developer. Placement policies can be managed by an administer who can easily move the application across clusters and set up basic application fail-over.

IBM Multicloud Manager eases compliance. Compliance policies can be written by a security team and enforced on each cluster, allowing all environments to conform to policy.

See IBM Multicloud Manager getting started for more introduction information.