Reaper uses a backend database to store information on Cassandra repeair. You can configure Reaper to use an in-memory database, PostgresQL, H2, Cassandra or Astra (Datastax's cloud-bassed Cassandra-as-a-Service). In this step, you will configure a keyspace so Reaper can use your Cassandra cluster as its backend store.

Open a bash shell on one of your Cassandra nodes.

kubectl -it exec cluster1-dc1-default-sts-0 -- bash

Start a CQL shell (cqlsh) to execute CQL commands and create the keyspace.

cqlsh

Create the keyspace. Reaper requires a keyspace called reaper_db.

create keyspace reaper_db with replication = {'class':'SimpleStrategy','replication_factor':1};

Run this CQL command to verify that the new keyspace has been created.

describe keyspace reaper_db;

Exit the CQL and BASH shells.

exit;
exit

In this step you will examine the Reaper configuration file and install Reaper.

Click to open reaper.yaml in the Katacoda editor.

Look at spec/template/spec/containers/env in the YAML file. The environment variables specify:

• Cassandra as the backing database
• Connection info for Cassandra (as backing database)
• Authentication for Reaper (disabled)
• Remote JMX credentials to manage Cassandra cluster

Under spec/template/spec/containers/port you will see two ports defined:

• 8081 for the admin UI
• 8080 for the web UI

Click to install reaper.

kubectl apply -f reaper.yaml

Use the watch command with kubectl to view pod info including status. (The watch command will update this info every 2s.)

watch kubectl get pods

Reaper is installed when the READY state of the Reaper pod is 1/1.

Click to send a Ctrl-C to stop following the container's logs.

^C

In this step you will use port-forwarding to expose the Reaper admin UI. Port forwarding exposes a port from the pod. This is just an expirement. At the end of this step you will delete the port mapping.

You will need to get the pod name to do the port forwarding.

Click to view the pod info.

kubectl get pods

Click to use kubectl get pods and grep to extract the name of the Reaper pod.

kubectl get pods | grep -Po "^.*reaper\S*"

Use the kubectl port-forward command to expose port 8081. (The & runs the command in the background.)

kubectl port-forward pod/$(kubectl get pods | grep -Po "^.*reaper\S*") 8081 &

Note: You will not see a command prompt at this time.

Reaper exposes a ping function as part of the admin UI. Click the curl command to invoke the ping command. Look for the pong reponse to verify that Reaper is active.

curl localhost:8081/ping

Click to bring the port forwarding process to the foreground.

fg

Click to send a Ctrl-C to stop port forwarding.

^C

In this step you will create a service for Reaper.

Click to open reaper-service.yaml and examine the service definition in the Katacoda editor.

The cassandra-reaper service exposes the web-ui on port 8080 and the admin-ui on port 8081. In this configuration, there is no targetPort mapping because the internal and external port numbers are the same.

Install the service in the cluster.

kubectl apply -f reaper-service.yaml

Use kubectl to view all the services in our kubernetes cluster. You should see the cassandra-reaper service and ports 8080/8081.

kubectl get svc

In this step you will use a hostname-based Ingress to expose the Reaper admin ui. You will configure the Ingress to map the hostname reaper.foo.com to the cassandra-reaper service.

Click to open reaper-host-ingress.yaml and examine the Ingress definition in the Katacoda editor.

Hostname-based Ingress uses name based virtual hosts in the Nginx ingress controller. Requests come in to the ingress controller and are routed to services based on the hostname in the request. All of the hostnames used in the ingress must map to the IP address of the controller.

Instead of registering reaper.foo.com with a public DNS service, you will modify the servers /etc/hosts file.

Click to view the /etc/hosts file.

clear
cat /etc/hosts

Use sed to insert a new entry to map reaper.foo.com to 127.0.0.1

sed -i '1 s/^/127.0.0.1       reaper.foo.com\n/' /etc/hosts

Click to view the modified /etc/hosts file.

clear
cat /etc/hosts

Next, you will install the ingress.

kubectl apply -f reaper-host-ingress.yaml

Use cURL to access the ping function of the Reaper admin service. You should see the response pong indicating that the ingress and service are working properly.

curl http://reaper.foo.com/ping

In this step, you will create a path-based ingress for Reaper.

Click to open reaper-path-ingress.yaml and examine the ingress

This ingress is configured with the open source web server nginx. The annotations enable regular expressions and cause the ingress to rewrite the URL (before it is passed to the service) with the 2nd regex match.

The path starts with /reaper but because of the regex match and rewite, it will be stripped off. So if the incoming path is /reaper/webui, the path received by the service will be /webui. This path is mapped to the cassandra-reaper service and it exposes Reaper's web console.

Apply the ingress.

kubectl apply -f reaper-path-ingress.yaml

Open the Reaper web console in a new tab. You should see the Reaper web console as shown below.

Important: Return to this tab after viewing the web console!

In this step you will connect Reaper to the Cassandra cluster and explore the Reaper UI.

Isn't Reaper already connected to the Cassandra cluster? Reaper is configured to use the Cassandra Cluster as its working database so Reaper has a connection to the cluster using a driver. In order to manage repair for the cluster, Reaper will need to make a JMX connection to the cluster nodes.

Reaper is running in Kubernetes therefore it will be able to access the cassandra cluster service. Click to view the services runnning in the Kubernetes cluster.

kubectl get services

You should see the cluster1-seed-service service. Remember or write down the name (cluster1-seed-service) because you will need it to connect Reaper to the cluster.

Important After reviewing the rest of the instructions in this step, you will open the Reaper web console and connect to the Cassandra cluster.

When you access the web console, click AddCluster.

Enter cluster1-seed-service as the Seed node. You may leave the other fields blank since Reaper will use the default port and credentials were hard-coded into reaper.yaml. Click Add Cluster

You should see cluster1, The three green squares indicate that there are three Cassandra nodes running in the cluster.

Important When you have finished connecting to the cluster, return to this tab in your browser.

Open the Reaper Web console and connect Reaper to the Cassandra cluster.

In this step, you will deploy the Pet Clinic application in the Kubernetes cluster. The application consist of a Spring Boot microservice that connects directly to the Cassandra cluster and an Angular front-end that runs in the user's browser and makes RESTful requests to the microservice.

Click to open petclinic.yaml in the Katacoda editor.

You should see a Deployment for the petclinic-backend and the petclinic-frontend. The petclinic-backend deployment defines several environment variable that allow the microservice to connect to Cassandra and create a keyspace to store its data. There are also services defined for each deplyment. Finally there is an Ingress defined to expose both the frontend and backend.

Pro Tip: In some applications, a microservice would not be exposed outside of Kubernetes with an ingress. The microservice would be invoked using a service (k8s internal networking) by consumers running in Kubernetes. In this case, the client is an Angular(JavaScript) application that is downloaded and runs completely in the client browser. Since the JavaScript will make RESTful calls from the browser into the Kubernetes cluster, the microservice must be exposed via an Ingress.

Click to install the Pet Clinic application.

kubectl apply -f petclinic.yaml

It will take some time for the microservice to start up and connect to the Cassandra cluster. Run curl with the watch command to try and get data from the microservice at two second intervals.

watch 'curl -X GET http://localhost/petclinic/api/pettypes | jq .'

When you see a JSON array of pet types click to send a Ctrl-C to stop watching the curl command.

^C

Now that the microservice is running,connect to the Pet Clinic app using another tab in the browser.

Important When you have finished connecting to the cluster, return to this tab in your browser.

In this step, you will use the Reaper Web console to start a repair in the cluster. The Pet Clinic sample app you deployed in the previous step created a keyspace called spring_petclinic. You will follow these steps to perform a repair on the spring_petclinic keyspace in the cluster. You will see the steps on this page and then open the Reaper Web console in a new browser tab to actually start the repair.

Note Repairs take a long time to run. In this scenario you will start a repair but it is not necessary to complete the repair.

Select the Repairs menu item in the Reaper Web console.

Reaper can manage multiple clusters, but in this scenario there is only one. Select cluster1, choose the spring_petclinic keyspace and specify an owner. (The owner can be an arbitrary string.) When the form fields have been completed, click the Repair button.

You should see a list of running repairs. The repair you just configured will be the only one in the list. Its state will be NOT_STARTED. In this screenshot you see that the spring_petclinic keyspaces has 5 tables and 0 of 193 segments have been repaired. Click Activate to start the repair.

Once the repair has started, the state changes to RUNNING and you can see the number of segments that have been repaired. In this screenshot 6 segments out of 193 have been repaired. Click View segments for segment by segment status of the repair.

You should now see a list of Running, Done and Not started segments.

Note When you have finished starting a repair, return to this tab in your browser.

Open the Reaper Web console and start a repair in the Cassandra cluster.

In this step, you will use Reaper to schedule a repair for the cluster. Scheduling a repair is like running a repair except you have to pick a start time and frequency. You will follow these steps to schedule a repair on the spring_petclinic keyspace in the cluster. You will also look at the Advanced Settings that are available for both immediate and scheduled repairs.

You will see the steps on this page and then open the Reaper Web console in a new browser tab to actually start the repair.

Select the Schedules menu item in the Reaper Web console.

This dialog is like the one under the Repair menu. Select cluster1, choose the spring_petclinic keyspace and specify an owner. (The owner can be an arbitrary string.) On this form you have to specify a Start time and an Interval in days.

When the form fields have been completed, click the Advanced settings button button.

The Advanced settings form exposes features to fine-tune the repair. Importantly this is where you specify full or incremental repairs.

Close the Advanced settings form. Return to the previous form and click Add Schedule to complete scheduling the repair.

Note When you have finished scheduling a repair, return to this tab in your browser.

Open the Reaper Web console and scheduling a repair in the Cassandra cluster.

Let's review the main points of this learning scenario.

Let's review the main points of this learning scenario.

Let's review the main points of this learning scenario.

Let's review the main points of this learning scenario.

Let's review the main points of this learning scenario.

Let's review the main points of this learning scenario.