Install the front-end application on your OpenShift cluster

Prerequisites:

• The Developer Sandbox and your local laptop to deploy the front end and the database, respectively. 
• Podman or Docker installed on your local machine.
• A no-costDeveloper Sandbox account; follow these instructions to set up your sandbox if you haven't already done so. 
• OpenShift command-line interface (CLI) installed on your local machine.

Install the front-end application on your OpenShift cluster

The first step in your process of connecting services across different environments, is to prepare your environment.

1. Log into the Developer Sandbox and copy the login command (Figure 2).

    

   

2. Copy the login token and paste it into your terminal to log into the cluster (Figure 3).

   

3. Deploy the front-end application on your Developer Sandbox cluster using the following commands: 

   oc apply -f https://raw.githubusercontent.com/rpscodes/Patient-Portal-Deployment/main/patient-portal-frontend-deploy.yaml
   
   oc get route patient-portal-frontend -o jsonpath='{.spec.host}{"\n"}'

4. The last command will display the OpenShift route URL for the front-end app. Copy and paste that URL into the browser. The URL will look somewhat similar to the one below:

   patient-portal-frontend-vravula-redhat-dev.apps.sandbox-m4.g2pi.p1.openshiftapps.com

5. You should now be able to see the front end of the patient portal (Figure 4). Patient and doctor names are not currently visible because we have not established the connection with the database.

    

   

Install the database on your laptop

The database contains a list of patients and doctors that will show on the patient portal front-end page once we make the connections using Red Hat Service Interconnect. In a real-world scenario, the database could be on a virtual machine, private data center, or other bare metal environment. 

In this example, we will see how to use either Podman or Docker on your local laptop or computer to deploy the database. (The following steps assume that you have already installed Podman or Docker locally.)

Run the database on your local environment.

To deploy the database on Mac M1:

docker run --name database --detach --rm -p 5432:5432 quay.io/redhatintegration/patient-portal-database-arm64

To deploy the database on AMD64 or x86 environments (e.g., a Mac with an Intel chip):

docker run --name database --detach --rm -p 5432:5432 quay.io/redhatintegration/patient-portal-database

To deploy the database with Podman (e.g. on a Red Hat Enterprise Linux (RHEL) or Fedora) machine:

podman run --name database --detach --rm -p 5432:5432 quay.io/redhatintegration/patient-portal-database

Connect the database to the front end using Red Hat Service Interconnect

Now, your challenge is to enable the patient portal front end deployed on the Developer Sandbox to connect to the database. For obvious reasons, you do not want to expose the database over the public internet, so you need to set up a private, secure link between the Developer Sandbox instance and the database on your computer. 

This can be accomplished with a VPN between the public cloud and the data center. However, VPNs can be hard to set up and require deep networking expertise. It also requires you to request the network admins and go through a time-consuming approval process. 

Red Hat Service Interconnect, on the other hand, creates a dedicated Layer 7 service network, and it is a lot easier to set up. It lets you establish secure interconnection with other services and applications in different environments without relying on network specialists. With Service Interconnect, you can create secure virtual application networks without the cumbersome overhead, complexity, and delays that stem from traditional connectivity solutions.

Follow these steps to connect the database to the front end using Red Hat Service Interconnect:

1. Install Red Hat Service Interconnect by running the below command from the terminal of your local computer:

   curl https://skupper.io/install.sh | sh

   Copy snippet
2. You should see an output similar to the one below. Export the path only if suggested in the output. 
   export PATH="/Users/vravula/bin:$PATH"

3. Double-check that you are still logged in to the OpenShift cluster from your local computer by running the following command:

   oc project

   Copy snippet
4. If you see an output similar to the one below, you can proceed. Otherwise, follow the process from Step 1 and 2 in the first section to log in.
   Using project "user-dev" on server "https://api.sandbox-c4.k1pi.p1.openshiftapps.com:6443

5. Initialize Service Interconnect in your sandbox environment namespace. Run the following command from the terminal of your local computer:

   skupper init --enable-console --enable-flow-collector --console-auth unsecured

   Copy snippet

   You should see an output similar to the one below: 

   Skupper is now installed in namespace 'user-dev'.  Use 'skupper status' to get more information.

   Copy snippet

6. Service Interconnect provides observability out of the box and comes with its own console. The following command should display the URL for the console:

   skupper status

   Copy snippet

   You should see an output similar to the one below: 
   Skupper is enabled for namespace "username-dev" in interior mode. It is not connected to any other sites. It has no exposed services.
The site console url is:  https://skupper-username-dev.apps.sandbox-m4.g2pi.p1.openshiftapps.com

7. Copy the site console URL and paste it in a new browser tab. You should be able to see the sandbox cluster namespace displayed in the console (Figure 5). At the moment, there is not a lot to see because we have only installed one side of the service network.

    

   

Now that you have established a service network (with only one site at the moment), you can expose services from a local machine on the service network. A service network enables communication between services running in different network locations (sites). For example, if you run a database on a server in your datacenter, you can deploy a front end in a cluster that can access the data as if the database was running in the cluster.