Link distributed services across OpenShift clusters using Red Hat Service Interconnect

In this activity, you will connect services distributed across multiple OpenShift clusters using Red Hat Service Interconnect to establish a Virtual Applications Network, also known as a service network. This involves using straightforward Kubernetes annotations to manage which services are securely exposed over the network. This method enables you to seamlessly leverage your existing GitOps workflow for service management.

Install a front-end application on your OpenShift public cluster

Before you can build a service network to connect services, you have to install a front-end application on the public cluster and the database and payment service on the private cluster. You will accomplish both tasks in the subsequent steps.

  1. Log into your Developer Sandbox and click on the terminal icon (Figure 2). The terminal will take a couple of minutes to provision.
    Figure 2: The Developer Sandbox login page.
    Figure 2: The Developer Sandbox login page.
  2. Deploy the front end in the cluster using the terminal: 
    oc apply -f https://raw.githubusercontent.com/rpscodes/Patient-Portal-Deployment/main/patient-portal-frontend-deploy.yaml
  3. Once the deployment is done, click on the route to access the front end. (Figure 4).
    Select the route to access its front end.
    Figure 4: Select the route to access its front end.

    You should now see the front end of the patient portal (Figure 5). Note: There are no patient or doctor names because we have not established the connection with the database.

    The patient portal front end.
    Figure 5: The patient portal front end.
  4. Install Red Hat Service Interconnect on the sandbox (public) cluster:

    curl https://skupper.io/install.sh | sh
    
  5. Set the path:

    export PATH="/home/user/.local/bin:$PATH"
    

Install the database and payment processor on your OpenShift private cluster

Now that you have installed your front-end application on your public cluster, install the database and payment processing service on your private cluster

  1. If you haven’t already done so, provision the other OpenShift cluster using this link (private cluster in our case) (Figure 6).
    To minimize the window, select the Collapse instructions icon.
    Figure 6: To minimize the window, select the Collapse instructions icon.
  2. Create a new project in the private cluster in the terminal:
    oc new-project private
  3. Deploy the database:
    oc new-app quay.io/redhatintegration/patient-portal-database:devnation --name=database
  4. Deploy the Payment Processor:
    oc apply -f https://raw.githubusercontent.com/jbossdemocentral/service-interconnect-sandbox-demo/main/payment-processor-deployment.yaml
  5. Wait for a minute, then check if the database and payment processor pods are running on the OpenShift Private Cluster:
    oc get pods
  6. You should see output similar to this:
    NAME                                 READY   STATUS    RESTARTS   AGE
    database-55578554-68kdb              1/1     Running   0          41s
    payment-processor-6644cdbc94-ng652   1/1     Running   0          31s
  7. Install Service Interconnect on the private cluster:
    curl https://skupper.io/install.sh | sh

This brings us to the end of the installation section. In the next section, we will use Red Hat Service Interconnect to connect all these services to make the patient portal work.

Previous resource
Overview: Link distributed services across OpenShift clusters using Red Hat Service Interconnect
Next resource
Connect the Public Cluster to the Private Cluster

Red Hat Service Interconnect: Link distributed services across OpenShift clusters using Red Hat Service Interconnect

In this activity, you will connect services distributed across multiple OpenShift clusters using Red Hat Service Interconnect to establish a Virtual Applications Network, also known as a service network. This involves using straightforward Kubernetes annotations to manage which services are securely exposed over the network. This method enables you to seamlessly leverage your existing GitOps workflow for service management.