Initialize the gateway

What will I need to complete this activity?

• You will use 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-cost Developer 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.

If you need help

If you get stuck, something isn’t working, or you simply have questions, contact us via email at devsandbox@redhat.com.

Initialize the gateway 

Now that you have set up your service network, it's time to initialize the gateway.

If you’re using Docker on a Mac, create a file with the name simple_docker.yaml and paste the following into it:

name: simple
qdr-listeners:
    - name: amqp
      host: localhost
      port: 5672
bindings:
    - name: database
      host: host.docker.internal
      service:
        address: database:5432
        protocol: tcp
        ports:
            - 5432
      target_ports:
        - 5432

Initialize the Docker gateway:

skupper gateway init --config simple_docker.yaml --type docker

If you’re using Podman on RHEL, create a file with the name simple_podman.yaml and paste the following into it:

name: simple
qdr-listeners:
    - name: amqp
      host: localhost
      port: 5672
bindings:
    - name: database
      host: localhost
      service:
        address: database:5432
        protocol: tcp
        ports:
            - 5432
      target_ports:
        - 5432

Initialize the Podman gateway: 

skupper gateway init --config simple_podman.yaml --type podman

You should see an output similar to the one below:

Skupper gateway: 'username-mac-username'. Use 'skupper gateway status' to get more information.

Your local computer should now appear in the console, as shown in Figure 6.

Though you have linked both the cluster and your local environment, you have not exposed any services yet. By default, none of the services are exposed by Red Hat Service Interconnect, so you have to explicitly mention which services you want to expose over the service network.

Verify your services by going back to the console. Click on the Components tab (Figure 7). You should now see the Patient Portal Front end (patient-portal-frontend) process from your namespace (your site on OpenShift) as well as the gateway process running on your local machine (the “Private Datacenter”).

By going to the Processes tab in the Topology section, you can see the current state of processes in our topology, including the site information (Figure 8).

Expose the database service

Now expose the database service over the service network. This will allow the front end on the public cluster to connect to the database as if it was a local service. In reality, the OpenShift service is a proxy for the real service running on your computer;

Expose the database over the service network:

skupper expose service database --address database --port 5432 --protocol tcp

You should see an output similar to the one below:

service database exposed as database

You have now established a secure link between the sites and exposed the database as a service on your OpenShift cluster (Figure 9). 

In the Processes tab, you can even see more detailed information about the established service connectivity (Figure 10). 

Get a list of services deployed in the sandbox namespace:

oc get service

You should see an output similar to the one below: 

NAME                      TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                               AGE
database                  ClusterIP   172.30.208.188   <none>        5432/TCP                              8m55s
modelmesh-serving         ClusterIP   None             <none>        8033/TCP,8008/TCP,8443/TCP,2112/TCP   7d3h
patient-portal-frontend   ClusterIP   172.30.144.46    <none>        8080/TCP                              77m
skupper                   ClusterIP   172.30.54.88     <none>        8010/TCP,8080/TCP,8081/TCP            47m
skupper-router            ClusterIP   172.30.102.71    <none>        55671/TCP,45671/TCP                   47m
skupper-router-local      ClusterIP   172.30.75.28     <none>        5671/TCP                              47m

The database service is the proxy service created by exposing the database deployment on your local environment over the service network. After a few seconds, go back to the browser tab where you opened the patient portal front end and refresh it (Figure 11). You should now be able to see the list of patients and doctors that you have retrieved from the database. This indicates that you have successfully connected your front end to the database using Red Hat Service Interconnect. 

oc delete pods -l deployment=patient-portal-frontend

Metrics

You can open a detailed view of the processes by clicking on them in the Processes view or listing them from the side menu (Figure 12). That's where you can view the metrics of established connections in your service network:

Conclusion

Congratulations! You built a secure service network between services on two different environments and allowed applications to connect and communicate over the secure network using Red Hat Service Interconnect. To learn more, visit our Red Hat Service Interconnect product page.