The RHOCP web console is a browser-based user interface that you can use to interact with RHOCP. You can deploy and manage your applications by using the web console.

The web console provides the Administrator and Developer perspectives. The Developer perspective focuses on the status and management of the deployed applications. The Administrator perspective focuses on the status and management of RHOCP and its resources.

Figure 8.2: The Administrator and Developer perspectives

The Topology view in the Developer perspective provides a visual representation of deployed applications.

Figure 8.3: The Topology view

Command-line utilities (CLI) provide an alternative for interacting with your RHOCP cluster. Developers familiar with Kubernetes can use the kubectl utility to manage an RHOCP cluster. This course uses the oc command-line utility, which is designed to take advantage of additional RHOCP features.

The CLI utilities provide developers with a range of commands that are useful for managing the RHOCP cluster and its applications. Each command is translated into an API call, and the response is displayed in the command line.

The following is a list of the most common oc commands.

The oc utility provides equal functionality to the web console. For a full list of commands, execute oc --help. Additionally, you can execute oc command --help, for example oc logs --help to view the oc logs command documentation.

All RHOCP and Kubernetes objects can be represented as a JSON or YAML structure with common fields. Consider the following pod object in the YAML format:

kind: Pod 
apiVersion: v1 
metadata: 
  name: example-pod
  namespace: example-namespace
spec: 
...definition omitted...
status: 
  conditions:
  - lastProbeTime: null
    lastTransitionTime: "2022-08-19T12:59:22Z"
    status: "True"
    type: PodScheduled
  containerStatuses:
  - containerID: cri-o://e37c....f5c2
    image: quay.io/example/awesome-container:latest
    lastState: {}
    name: podman-quotes-ui
    ready: true
...object omitted...

Every RHOCP resource contains the .kind, .apiVersion, .spec and .status fields. However, when you create an object definition, you do not need to provide the .status field. The .status field is useful, for example, for troubleshooting the reason for a pod scheduling error.

Use the oc explain command to get information about valid fields for an object. For example, execute oc explain pod to get information about possible Pod object fields. You can use the YAML path to get information about a particular field, for example:

[user@host ~]$ oc explain pod.metadata.name
KIND:     Pod
VERSION:  v1

FIELD:    name <string>

DESCRIPTION:
...output omitted...

Labels are key-value pairs that you define in the .metadata.labels object, for example:

kind: Pod
apiVersion: v1
metadata:
  name: example-pod
  labels:
    app: example-pod
    group: developers
...object omitted...

The preceding example contains the app=example-pod and group=developers labels. Developers often use labels to target a set of objects by using the -l or the equivalent --selector option. For example, the following oc get command lists pods that contain the group=developers label:

[user@host ~]$ oc get pod --selector group=developers
NAME                          READY   STATUS    RESTARTS   AGE
example-pod-6c9f758574-7fhg   1/1     Running   5          11d

Storing a pod definition in a file is called the declarative approach for creating RHOCP objects, because you declare the intended pod state outside of RHOCP. This means you can store the pod definition in a version control system, such as Git, and incrementally change your definition as your application evolves.

The following YAML object demonstrates the important fields of a pod object:

kind: Pod 
apiVersion: v1
metadata:
  name: example-pod 
  namespace: example-project 
spec: 
  containers: 
  - name: example-container 
    image: quay.io/example/awesome-container 
    ports: 
    - containerPort: 8080
    env: 
    - name: GREETING
      value: "Hello from the awesome container"

You can create the pod object by saving the YAML definition into a file and then using the oc command, for example:

[user@host ~]$ oc create -f pod.yaml
pod/example-pod created

RHOCP also provides the imperative approach to create RHOCP objects. The imperative approach uses the oc run command to create a pod without a definition.

The following command creates the example-pod pod:

[user@host ~]$ oc run example-pod \ 
  --image=quay.io/example/awesome-container \ 
  --env GREETING='Hello from the awesome container' \ 
  --port=8080 
pod/example-pod created

The imperative commands are a faster way of creating pods, because such commands do not require a pod object definition. However, developers lose the ability to version and incrementally change the pod definition.

Generally, developers test the deployment by using imperative commands, and then use the imperative commands to generate the pod object definition. Use the --dry-run=client option to avoid creating the object in RHOCP. Additionally, use the -o yaml or -o json option to configure the definition format.

The following command is an example of generating the YAML definition for the example-pod pod.

[user@host ~]$ oc run example-pod \
  --image=quay.io/example/awesome-container \
  --env GREETING='Hello from the awesome container' \
  --port=8080 \
  --dry-run=client -o yaml
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: example-pod
  name: example-pod
spec:
  containers:
...output omitted...

The following YAML object demonstrates a service object:

apiVersion: v1
kind: Service
metadata:
  name: backend
spec:
  ports:
  - port: 8080 
    protocol: TCP
    targetPort: 8080 
  selector: 
    app: backend-app

The preceding example defines the backend service. This means that applications can send requests to the http://backend:8080 URL. Such requests are routed to the pods with the app=backend-app label on port 8080.

In RHOCP, the default service type is ClusterIP, which means the service is used for pod-to-pod routing within the RHOCP cluster. Other service types, such as the LoadBalancer service, are outside of the scope of this course.

Similarly to pods, you can create services imperatively by using the oc expose command. The following example creates a service for the backend-app pod:

[user@host ~]$ oc expose pod backend-app \
  --port=8080 \ 
  --targetPort=8080 \ 
  --name=backend-app 
service/backend-app exposed

You can also use the --dry-run=client and -o options to generate a service definition, for example:

[user@host ~]$ oc expose pod backend-app \
  --port=8080 \
  --targetPort=8080 \
  --name=backend-app \
  --dry-run=client -o yaml
apiVersion: v1
kind: Service
metadata:
  name: backend-app
spec:
...output omitted...