1. Explore IBM Satellite

In this step, the first few instructions may seem familiar – you should be comfortable with navigating IBM Cloud based on your completion of the first drone lab. As a reminder, you can always reference the first lab’s instructions guide here https://ielgov.github.io/dronelab1. In this lab, you will focus on IBM Cloud Satellite and its creation of distributed cloud regions anywhere you have infrastructure, e.g., factories, edge environments, on-prem locations, and even your home!

The purpose of this setup was to demonstrate the Satellite technology in order to:

• Build, deliver, and manage your applications across a hybrid multi-cloud environment.
• Bring the best of cloud wherever it is needed to run, while maintaining the simple "as a service" experience.
• Use a common control plane to manage your apps, platform, and security across our multi-cloud platform.

Let’s take a moment to review some concepts that you will be delving into in the next few steps. Consider two parties involved:

1. Public Safety Situational Awareness Operators that use the Remote Drone Operations Console application, and,
2. An organization, "IEL Drones-To-Go", which has private on-prem resource in Coppell, TX that allows piloting and observing of local drones.

IEL Drones-To-Go wants users like Public Safety Situational Awareness Operators to access their drone service, easily manage their access, make sure this connection is done securely so they are not compromised in any way.

The Public Safety Situational Awareness Operators, owners, and users of the Remote Drone Operations Console want to connect the service that IEL Drones-To-Go provides.

You will explore how IBM Satellite Link endpoints can help enable the connection between the Public Safety Situational Awareness Operators in one cloud environment, and the IEL Drones-To-Go services that are running in another cloud environment.

Satellite extends IBM Cloud with the new concept of a "location." Locations refer to any infrastructure where you can run services and applications. Once a location is created, you can start using that location to run IBM Cloud services, such as Red Hat OpenShift on IBM Cloud, IBM Cloud Databases, Continuous Delivery pipelines, AI and more. With Satellite Link endpoints, you can allow any client that runs in your Satellite location to connect to a service, server, or app that runs outside of the location, or allow a client running on an IBM Cloud private network to connect to a service, server, or app that runs in your location.

IBM Cloud Satellite acts as a "Hybrid Cloud Mesh" that creates distributed cloud regions anywhere you have infrastructure. Through this hybrid mesh, you can manage each location from a common control plane. IBM Cloud Satellite does this by attaching remote infrastructure in a remote location to your Cloud Satellite control plane. This location can then be used by IBM Cloud services as deployment targets.

In this next step of the lab, you will learn about how to use Satellite Link Endpoints to bridge a connection between the Remote Drone Operations Console and the on-prem resource at IEL Drones-To-Go. In later steps, you will continue to get more access to the IEL Drones-To-Go service, including accessing APIs and even invoking related flows.

Reference:

1.1 Access IBM Cloud

You’ll need to access the IBM Satellite Location within the IBM Cloud to configure your application’s endpoint. Begin by signing into IBM Cloud. (New Tab ⇒ https://cloud.ibm.com)

Once you’ve logged in with your credentials, you should be greeted with a dashboard that displays the various resources that IBM Cloud has to offer. From Cognitive APIs to DevOps to Classic Infrastructure resources, IBM Cloud has many offerings to explore. At the top of the dashboard, you’ll see a navigation bar. On the right side of the navigation bar, there is a dropdown for various accounts you may be a part of. Most likely, the default is the last account you opened, if not the only one available. For this lab, you’ll be working in the 1500867 – ITZ – SBAAS Primary account. Click on 1500867 – ITZ – SBAAS Primary in the IBM Cloud’s navigation bar dropdown.

1.2 Access IBM Cloud Satellite

Once you click on 1500867 – ITZ – SBAAS Primary, your dashboard will update with Resources that are specific to it. You should see a Resource summary card. Click on View all in the Resource summary card. You should now see a list of resources that you have access to, within the 1500867 – ITZ – SBAAS Primary account.

Take a look at the resources under the Satellite grouping. You will explore the govlab-satellite-location resource later in Step 1.4.2.

Take a look at the resources under the Devices grouping. You will explore the resources in Devices in Step 1.3.

1.3 Access Satellite Infrastructure collection

Remember that a location is a representation of an environment in your infrastructure provider, such as an on-prem data center or public cloud, that you want to bring IBM Cloud services to so that you can run workloads in your own environment. You create the location by attaching host machines from your infrastructure. In the context of a Satellite location, you can think of host machines as your own VMs, Bare Metal, or privately managed Iaas from your infrastructure. These host machines provide the computing power for running IBM cloud services in the Satellite location - for example, acting as the worker nodes in a RedHat OpenShift cluster. 

To set up a Satellite location, you must first (1) create the location, (2) attach hosts to it, and then (3) create the location control plane.

The location control plane runs resources that are managed by Satellite to help manage the hosts, clusters, and other resources that you attach to the location.

Some important takeaways regarding Satellite Locations include: The end user or business entity controls the collection of infrastructure and services outside of an IBM Cloud data center IBM Cloud is the target for IBM Cloud services The end user or business entity manages hosts within a location Hosts are automatically assigned for IBM Cloud Services An entire location’s capacity is managed by adding or removing hosts You will access this lab’s Location to better understand your location’s infrastructure collection. For your convenience, we have created an infrastructure collection on IBM Cloud, but in most cases, it will be at your data center or your own cloud (Azure, Google Cloud, AWS, etc.). This infrastructure collection consists of virtual servers (running RHEL7 operating system) that are assigned to run on a Satellite control plane and have workloads for the OpenShift cluster service that was provisioned for this lab.

Let’s begin by taking a look at first device – control1.govlab.ibmsbaasonibm.com.

Once you click on this device, you will be able to see its status and details. (You may need to click "View full details" to see all of its information.)

1.4 Access hosts assigned to Lab Satellite Location

The hosts at a location are securely attached and connected to IBM Cloud using Link:

• Each location has a local control plane where Cloud Satellite manages all provisioned services and communicates back to the central Cloud Satellite control plane.
• At least three hosts are required for a minimal control plane (six are recommended).
• Additional hosts are required for each provisioned service.
• Hosts are assigned to a location as either control plane or worker nodes for a service.

A satellite environment requires at least three hosts (recommended six) for a minimal control plane and additional hosts are required for each provisioned service. For our lab satellite environment, we have provisioned a satellite OpenShift cluster service to deploy the drone controller application. And so we have assigned three hosts to the control plane and another three hosts as worker nodes for OpenShift satellite cluster service. As with any other managed cluster, you need to plan for scaling the cluster and design it for resiliency, so at any point of time you can "attach host" and enable the Cloud Satellite control plane to provision more worker nodes as needed.

Let’s go back to see the Satellite grouping on the Resource List. You can do this by clicking the ≡ icon in the top left corner and then click "Resource List".

In the Resource list, you will once again see the resources in the Satellite grouping. Let’s explore the govlab-satellite-location resource you saw earlier. Click the govlab-satellite-location resource in the Satellite grouping.

You should now see the govlab-satellite-location’s Getting started page. Let’s take a look at the hosts at this location.

Look at each host listed, along with its name, status, availability, labels, cluster, worker pool, zone, and IP address. You will notice that control1, control2, and control3 hosts belong to the Control plane cluster, and worker1, worker2, and worker3 hosts belong to the govlab-satellite-satcloudcluster. The numbers at the end of each host name correspond to the zones as well (zone-1, zone-2, and zone-3).

Zone is a deployment area for compute resources such as virtual machines or bare metals. A Satellite location must have at least three zones that are physically separate so that you can spread out hosts evenly across the zones to increase high availability (High availability is a core discipline in an IT infrastructure to keep your apps up and running, even after a partial or full site failure). For example, your cloud provider might have three different zones within the same region (Coppell, Washington, etc) , or you might use three racks with three separate networking and power supply systems in an on-prem environment.

1.5 Access services for a Satellite location

The benefit of IBM Satellite is to bring cloud services to any location you need the service to run. As mentioned earlier, since IBM Cloud Satellite is like a hybrid cloud mesh, it presents all Cloud Satellite locations as just another deployment target for IBM Cloud services. In order to provision a service, it takes three easy steps:

1. Select satellite enabled services from IBM cloud catalog
2. Select the satellite location
3. Create the service!

Click on Services on the left side.

These are the services at this location.

In our lab satellite environment, you can see that two services have already been provisioned: one is the control plane to manage that location, and the other is the OpenShift cluster to deploy lab drone controller application.

Let’s take a quick look at some other Satellite-enabled services that are available today in the IBM Cloud Service Catalog.

There are a lot of offerings on the IBM Cloud catalog, so let’s filter them so only the Satellite-enabled are shown.

Let’s briefly explore a Satellite-enabled service - for example, Databases for PostgreSQL.

Click on the tile for Databases for PostgreSQL.

There are three main options for this Satellite-enabled service to pay attention to:

1. Platform: Satellite is an option.

2. Resource Group: Even though you may be provisioning this service into a remote location, you can still centrally control access with IBM Identity and Access Management. This way all your resource groups, access groups, and individual access policies can be applied quite simply.

3. Location: Drop-down list of Cloud Satellite locations.

1.6 Access Link Endpoints

Link Endpoints provide secure connection between Locations and IBM Cloud. The link provides the following: Control - Allows control of traffic flow across the Link including SRE traffic. Transparency – Provides traffic-level transparency across the Link and access reporting. Audit – Provides service registration and policy-management of traffic-flow. Let’s examine a sample system Link endpoint that was created as part of the satellite cluster creation. To do that, we’ll need to navigate back to the govlab-satellite-location first.

You should now see the Link endpoints page for govlab-satellite-location.

At the bottom of this page, you will see a full list of endpoints. Bear in mind that you may see other lab users’ endpoints as well.

In step 2 of the lab, you will be configuring an endpoint for your drone controller application, but for now, let’s look at a sample endpoint configuration for OpenShift API service deployed in this location.

Click on openshift-api-c7pisqgw0e96bqf631v0. If it’s difficult to find in the long list, use the Search at the top of the list.

Notice the following four areas in this sample endpoint:

1. Destination FQDN or IP: Address where the OpenShift cluster API service is listening for requests

2. Destination port: Port where the OpenShift API service is listening

3. Endpoint address: Address exposed to other services on IBM Cloud

4. Source list: ACL (access control list)

Note: The Link Endpoint Source list limits access to endpoints and controls which clients can access destination resources (at a Satellite location or IBM Cloud) through an endpoint. If no sources are configured, any client can use an endpoint to connect to the destination resource. All of our lab satellite endpoints are not configured with source list for ease of use. Any application can access the satellite location resources from the IBM Cloud or access the IBM Cloud resources from the Satellite location without any restrictions.

Finish Step 1

You have explored Satellite and its key features and gained a better understanding of how it works. You accessed and learned more about some of the key concepts on Satellite - like location, hosts, services, and endpoints.

In the next step, you will learn how to enable a drone controller application running on a satellite location at a end user or business entity's cloud to accept requests from IBM Cloud.

Step 2: Enable access to an application at a location with Satellite Link Endpoints

In the previous step, you learned about Satellite and became familiar with its key features. In this step, you will learn how to enable a drone controller application running on a satellite location at a client’s cloud to accept requests from IBM Cloud. To make this lab simple and more to the point, we have created this client’s cloud on IBM Cloud itself.

The applications running on a satellite location can have access to other applications and data that are private to that location. To access the drone controller application from IBM Cloud, we need to create a link endpoint.

Before you create any link endpoint, you need to know following details:

Is your application on the satellite location invoking a service on IBM Cloud? Or is a service from IBM Cloud invoking it?

What is the transport protocol of the requester and service provider?

What is the port address of the provider?

Do you need to set anything on the access list?

Are there any security certificates that need to be exchanged?

For this lab, you have been provisioned with a few things, as mentioned in the introduction.

In Step 1, you explored govlab-satellite-location. Look at the diagram above and find it. (Green color). This is a classic cluster.

In this Step 2, you will create a Link Endpoint in the govlab-satellite-location. (You saw an example of one in Step 1.6.2).

You will also explore the govlab-satellite-satcloudcluster (diagram above, right side) which contains your project that was provisioned for you. Within your provisioned project, there is a drone controller application that provides the drone service from IEL-Drones-To-Go.

The link endpoint you create will be connected via the route URL from this drone controller application in your provisioned project in the govlab-satellite-satcloudcluster.

Remember, to invoke the drone controller service from the drone console application, you need to create a link endpoint on govlab-satellite-location. Think of it as a wire connecting the private cloud service and the public cloud dashboard application.

2.1 Access the drone controller

In order to quickly navigate to the OpenShift cluster that the drone controller is in, let’s go back to Services.

If you haven’t continued from Step 1, you can also navigate straight to https://cloud.ibm.com/satellite/locations/c7lkj17w0vpdf5solosg/services.

Back in Services for govlab-satellite-location, you will see that the Red Hat OpenShift service is in the govlab-satellite-satcloudcluster cluster. Remember the animated diagram earlier – this cluster contains your provisioned project and drone controller service.

Let’s open the OpenShift web console to access the projects and pods deployed.

When you open this cluster’s web console, you may see a relatively sparse page, another project’s details, or a long list of projects in this cluster. Let’s navigate to your provisioned project. If there is a "Welcome to the Developer Perspective" prompt, click "Skip Tour" for now.

Note: You may see ‘sjchrist’ in screenshots – your lab name (YourLabName) is what you should look for instead.

Make sure you are in Developer mode.

The right panel displays the information for the deployed pod you see: controller-lab-sat. If this view feels unfamiliar or you’d like to revisit what the terms on this panel mean, go back to Drone Lab 1’s Step 4.

At the bottom of the right panel, you should see a grouping for Routes. Remember that a route exposes a service at a host name, such as www.example.com, so that external clients can reach it by name. The route URL here will be used to make the link endpoint you will create soon.

Notice that the route location URL starts with https – the exposed protocol is HTTPS, which has a default port of 443. This will be referenced and used in a later step.

Copy the route location URL and paste it below

2.2 Add and configure a new link endpoint

Now you have collected the drone controller endpoint information, let’s create and configure the link endpoint so that the remote drone console application dashboard can invoke it.

Let’s start by navigating to the list of link endpoints for govlab-satellite-location which you’ve seen before.

The link endpoint creation process starts with asking where the destination resources are running. The drone controller is running at a satellite location and is the destination. Remember that the drone console application runs on IBM Cloud and will invoke it.

Next, you will be prompted to enter the link endpoint’s details regarding the connected resource.

Endpoint name: YourLabName-drone-controller
Destination FQDN or IP: routeLocationURLHere - please go back to step 2.1.4!
Destination port: 443

The destination FQDN or IP is the route location URL you copied earlier.

Make sure the destination FQDN or IP does not start with https:// or end with a forward slash /. The endpoint will not create successfully if you do have these characters.

The destination port is a reference to the exposed protocol mentioned in 2.1.4. The destination port will be 443, which is the default for HTTPS.

In the Protocol step, you will be asked about the source protocol and server name indication. The drone controller application provisioned for your lab uses HTTPS as transport protocol and for simplicity, no authentication certificates are implemented. In a real-world scenario, to securely transmit information, the transactions are secured by certificates and for that case, you must upload the authentication certificates to exchange information between the requestor and the provider.

Source Protocol: HTTPS
Server name indication: routeLocationURLHere - please go back to step 2.1.4!

Make sure the server name indication does not start with https:// or end with a forward slash /. The page will alert you and not let you move on until you remove those characters.

The last step of the link endpoint creation is optional connection settings. You can set an inactivity timeout for your communication. If there is no activity (for the set inactivity timeout value) between the requestor and the service provider, the communication established between the two resources will be terminated and the resources will be freed from memory.

2.3 View the newly created link endpoint and its address

Upon a successful satellite endpoint creation, the satellite will create a link connector that will listen for any request from IBM Cloud and send the request to drone controller application running on satellite cluster on the client’s cloud.

Let’s take a look the newly created link endpoint information.

You can view the details of the link endpoint you just created. Notice the Destination FGQN or IP and Destination port you had just entered.

The endpoint address is available to be copied.

Finish Step 2

You have created a Satellite link endpoint that will connect the drone controller service to the Remote Drone Console Application.

In the next step, you will use another service to demonstrate the value of invoking flows involving other services.

Step 3: Connect to another service with App Connect

In previous steps, you explored Satellite and configured link endpoints. As we consider the "IEL Drones-To-Go", you will now consider how the operators need their Remote Drone Console Application to be able to (1) monitor available and nearby sensors and (2) retrieve the associated sensor data. In this step, you will learn how IBM App Connect allows an API flow to quickly and easily be set up in order to find the current coordinates of the drone and retrieve nearby sensor data (from IBM Cloudant) in the necessary format, and automatically update the data in their drone dashboard. IBM App Connect connects disparate applications very quickly, regardless of whether they are on the cloud or a private network. And significantly, there is no coding required. Using the App Connect Designer on IBM Cloud makes it easy to connect apps, even applications like Salesforce, Marketo, and SAP, so that when an event occurs in one application, or a request is made to an API, the other connected apps are updated automatically.

Below are some common templates used on App Connect. These contain prebuilt flows which can be created for an API, so that when the request is submitted (such as through a mobile or web application), the flow performs all its actions, and then returns a response that either confirms that the actions were successful, or returns the data that was requested.

With every service that is added, your application becomes more powerful due to it being linked to useful resources. In this step, you will learn how to use the latitude/longitude values parsed from the drone's telemetry data in order to retrieve data from a database of sensors, thereby creating a very helpful list of sensors near the drone.

3.1 Explore the sensor database

Before you access the App Connect service, let’s take a look at the database of sensors. In real-life situations, a Public Safety Situational Awareness Operator may want to quickly look at the nearby sensors to gauge the condition of the location they are viewing through the drone.

The sensors’ information is stored in a Cloudant database. IBM Cloudant® is a fully managed, distributed database and is provided as an offering on IBM Cloud. It has already been added to your IBM Cloud account. Once you click on the service, launch the dashboard to view the databases. You will take a look at the databased named sensordb.

Once you click the sensordb database, a list of sensor information will be displayed.

One of the many features Cloudant provides is IBM Cloud Geospatial, or "IBM Cloudant Geo". Cloudant Geo combines the advanced geospatial queries of a Geographic Information System (GIS) with the flexibility and adaptability of IBM Cloudant's database-as-a-service (DBaaS) capabilities. These capabilities include GeoJSON, IBM Cloudant Geo index, and more.

With IBM Cloudant Geo, all of the following are possible:

(1) Enable web and mobile developers to enhance their applications by using geospatial operations that go beyond simple bounding boxes
(2) Integrate with existing GIS applications, so that they can scale to accommodate different data sizes, concurrent users, and multiple locations.
(3) Provide a NoSQL capability for GIS applications, so that large streams of data can be acquired from devices, sensors, and satellites. This data can then be stored, processed, and syndicated across other web applications.

Let’s take advantage of this feature. Sensors have locations that be filtered on – within Cloudant, you’re able to draw polygons on a map and define spatially which sensors to display in a given bounded area. Go ahead and draw a circle on the map to filter sensors.

The circle you drew has filtered the sensors to only return the ones that are located within the boundary. When you click the JSON view, the list of JSON data pertains to the sensor markers shown on the Map view.  While the details returned  at this point is limited to the identifier and coordinates for each individual sensor, this information could then be used to query the type and values for each sensor which is useful in later lab sub-steps.

In the next sub-steps, you will use the location data you were able to return in the end of Step 2 in combination with the information located in the sensors in this database to return a list of sensors nearby.

3.2 Set up App Connect flow

Now that you have a preview of what the sensor database and its information looks like, let’s set up the flow. Close the two tabs you just opened related to the sensor database, and open the App Connect service in your IBM Cloud Resources. Then, click Launch App Connect to begin.

This is the App Connect Home. You may notice that there may been integrations that have already been created – these artifacts reflect connections that other users have made. This dashboard also provides an overview of available functions that App Connect provides.

Let’s start by clicking on the Dashboard icon (you may need to hover to view it) on the black left side menu. In order to add a new flow, you will import its definitions that have been provided for you (similar to Step 2). On the top right corner, click New and then Import flow.

Using the copy to clipboard button, copy your YAML file URL below and paste it into the pop-up’s, "or specify a file URL" field. When you click Add file, it will import the YAML file containing your lab name. Click import to complete the process.

Once the flow has been added (this may take a few seconds), the screen will update with Define view for the flow you created.

At the top, you may see something like "Dashboard / DroneLab_SAT_Prod_3". Let's change it so it's customized for you.

Remember these two functions – retrieveSensordata and getNearBySensors. You will focus on getNearBySensors for the purposes of activities in the next several steps, but you will also be exposed to retrieveSensordata and asked to consider it within the context of the lab’s Production Flow used by the Remote Drone Console application.

Take a look at the various Properties associated with the getNearBySensors – droneid, lat, lon, radius, and response. You will provide a droneid, the latitude and longitude coordinates from the drone, and the radius you are interested in, and get a response. Notice that these properties are strings as well.

You may have noticed that retrieveSensordata has fewer Properties – only droneid and response. This will be explained as you continue through this lab section.

The getNearBySensors API is a simple API flow to demonstrate the capability and simplicity of the App Connect cloud service. For the lab, we developed this flow to show how a web application could get access to Cloudant sensor data that is in close proximity to a given drone’s location by providing the lat/long as input.

The retrieveSensordata may be more typical of a production API flow in that it combines several steps and includes some additional logic. Specifically, this flow is different from the simplified getNearBySensors API flow as it retrieves the drone’s status and telemetry data using the drone controller’s GET/status API (from API Connect), parses the response to find the drone's location (latitude/longitude) information, and then uses those locations details as input to retrieve sensor readings from the Cloudant database that are in the relevant area. This flow is used by the Remote Drone Console application as part of the lab’s Production Flow.

App Connect provides a model-driven, code-free approach that lets you easily implement your API operations as integration flows. For less experienced users, App Connect guides you through making models and integration flows you can use to build robust APIs. For experienced developers, App Connect's powerful tooling lets you extend the flow through code. In either model, the tool then builds well-formed OpenAPI definitions automatically. 

You can preview the flow within App Connect for getNearBySensors by clicking on the Operations tab on the section and then Edit flow (this may appear as "View Flow"). The flow you see is linear – Request > HTTP Invoke method > JSON Parse > Response. As you continue to finish this lab, consider how this flow could be used within the Remote Console Operations application.

You can see that a simple linear visual flow represents the step by step actions that happen within the getNearBySensors API. If you click on each step in the visual flow, you will see the details reflected underneath. For example, the output below shows the details of the HTTP step.

3.3 Start the API

Now that you have set up the flow in App Connect, let’s test it out – but first, you’ll need to start the API and change authentication settings.  Begin by moving to the Manage view.

If you are unable to see or view the Manage tab, refresh the page. You may need to change browsers if this does not work.

Once you’re in the Manage view, you’ll be able to view and change settings related to the API flow.

Scroll down to the Security and Rate Limiting section. Pay attention to the section names as some are named similarly. For this lab, you will turn off "Require application via API key". This lab does not include viewing the usage of the APIs so this authentication isn’t required. It should be noted that for production level implementations, it may be appropriate to require authentication so that applications that use this API would need to authenticate using an API key and secret or API key alone.   This section would thus manage its key sharing and provide visibility into the API usage after the API is online. Make sure you scroll down and save this change once it is turned off.

A pop-up at the top right corner will confirm your changes are saved.

Once this change has been saved, click on the vertical 3 dots at the top next to "Stopped". Clicking Start API will make this flow active. By making this API active, applications will now be able to use the functions that were shown in the previous sub-step. Click on the 3 vertical dots next to Stopped in the top right corner. Then click Start API.

In the Sharing outside of Cloud Foundry organization, you’ll notice the description: To share the API with a developer who is not a member of your Cloud Foundry organization, first create an API key and a companion API documentation link. Then send the key and the link to the developer, who can then use the corresponding page to explore the API and create an API secret (if required).

If the above "Require authentication via API key" was enabled, you would first need to create an API key in order to use the API Documentation link.  Because this isn’t required for this lab, all that is needed is to use the API Documentation Link (from screenshot below) for the remaining substeps.

3.4 Try out the flow

Under the Query section, notice the API input parameters lat, lon, and radius. You’ll enter the location values that you should have gotten back at the end of Step 2 from the drone #1 you specified. Enter the following values in the corresponding fields and click Send to send the request. Scroll down after to view its response.

You should see a sensor reading response below that starts with a 200 OK Response. Congratulations! You were able to test the simplified getNearBySensors flow that you added within App Connect. If you look closely at the JSON results contained in the response, you may notice the type of sensor and current values for this particular device.

Thinking about our Remote Operations Console application, you can consider how App Connect’s flow can expose a single API (via the  /retrieveSensordata Production flow) that retrieves and parses a drone's current location, and then goes on to query the sensors in that immediate geospatial area to bring the values to the user. In the next step, you will visit and review the Remote Operations Console application's updated user interface and consider how these service connections enabled the Multi-Hybrid Cloud application with powerful functionality.

In the next step, you will visit and review the Remote Operations Console application's updated user interface to understand how these service connections  enable that Multi-Hybrid Cloud application with powerful functionality.

Finish Step 3

You successfully used App Connect to add a flow that can take drone location information and find nearby sensors in a given radius.

In the next step, you will revisit the Remote Operations Console application and take a look at the Drone Viewer which incorporates some the services you delved into in previous steps.

Step 4: Explore Remote Operations Console with new flows

In Steps 1, 2, and 3, you learned about IBM Satellite Technology, Satellite Link endpoints, and the App Connect service flows that were integrated with your Remote Operations Console application. Let’s review each briefly:

IBM Satellite creates distributed cloud regions anywhere you have infrastructure. Through this hybrid mesh you can manage each location from a common control plane. Cloud Satellite does this by attaching remote infrastructure in a remote location to your Cloud Satellite control plane. This location can then be used by IBM Cloud services as deployment targets.

IBM Satellite Endpoint Link provides secure connection between Locations and IBM Cloud. The link provides the following:
- Control – Allows control of traffic flow across the Link including SRE traffic.
- Transparency – Provides traffic-level transparency across the Link and access reporting.
- Audit – Provides service registration and policy-management of traffic-flow.

App Connect is an all-in-one tool for easily connecting apps, integrating data, building APIs, and acting on events. Used to invoke flows that can retrieve nearby sensors based on location data of a drone.

Your Remote Operations Console application is connected to the private cloud that hosts the fictional company IEL-Drones-To-Go service, which is hosted in the IBM Industry Engineering Lab in Coppell, TX.

Let’s review the lab’s diagram once more before moving on:

Your Remote Operations Console application is connected to the private cloud that hosts the fictional company IEL-Drones-To-Go service, which is hosted in the IBM Industry Engineering Lab in Coppell, TX.

You may remember that in Drone Lab 1, you saw a list of drones but didn’t go much further than that. In this lab, you will finally get to view what the drone sees, view telemetry data it provides, and see its relevant geospatial information.

If you want to recall specific information regarding the Remote Operations Console, it is recommended you read the instructions for Drone Lab 1, located here: https://ielgov.github.io/dronelab1.

It is worth reviewing Drone Lab 1 Step 5, which you may recall, contains a breakdown of specific parts of the console application UI. This step contains clickable sections of the page that go into detail regarding the function of each widget. This lab will not cover this content again and will go directly to a new section of the console application UI - so if it’s been a while, it is recommended that you go over this step again.

4.1 View configurations made for this lab

Remember in the animated diagram above, there was a cluster on the left side called govlab-satellite-cluster. You were provisioned your own project in this cluster which contains all the deployments necessary for the Remote Drone Console Application. Let’s view these deployed pods.

You can also go directly to https://console-openshift-console.govlab-satellite-cluster-ed9112eb83c761afd4c566b0882eaa3e-0000.us-south.containers.appdomain.cloud/.

Make sure you are in Developer mode.

Within your project, if you aren’t already in the Topology view, select Topology from the left navigation.

As part of the lab provisioning process, the necessary pods to run this lab have already been created. You can see that there are 4 pods (one set for production flow and the other for your lab). They are:

Production Flow
1. ui-prod-sat
2. http-prod-sat

Lab Flow
3. ui-lab-sat
4. http-lab-sat

While the Production Flow is properly set up in http-prod-sat, you will need to update your Lab Flow using http-lab-sat. Let’s take the Satellite Link endpoint address you configured as part of Step 2 and add it to the http-lab-sat environment.

Within the detail panel for http-lab-sat, you will see a grouping for Builds. Let’s take a look at the build configuration for your lab. Click http-lab-sat under Builds (preceded with a BC).

The Build Config has several settings that can be changed. Let’s go to the Environment tab in order to view the environment variables that are assigned for the application during creation. For this lab application, we have created an environment variable "BASE_URL" to set your Lab Satellite link endpoint. The BASE_URL should contain the satellite link endpoint address you made in Step 2.3.2.

Now that you have updated your lab flow configuration with the satellite endpoint link you previously created, it’s a good idea to rebuild. Keep in mind that you have to rebuild in order for the application to use the new environment variable value you set for BASE_URL.

Click on the http-lab-sat to open its detail panel and then click Start Build. This process may take a few minutes. Wait until it says the latest build is complete.

4.2 Explore the lab flow drone viewer modal

When the build is complete, you can then access the Lab Flow UI of the drone console application.

Note: The satellite endpoint link can be accessed from only a server pod running on IBM cloud i.e., web-based applications cannot directly access satellite endpoint link. For this reason, in our lab and production flow, we have created HTTP pods which route traffic from the Drone UI web-based application to the Drone controller application thru satellite endpoint link.

This website should be familiar from Drone Lab 1 - if you would like to review each section of the Remote Operations Console, please revisit Step 5 of the Drone Lab 1 instructions site https://ielgov.github.io/dronelab1. When you’re ready, go to the Available Drones section. Notice that the list of drones each have a status. The drones with the Available status can be connected to. These are the drones provided by the IEL Drones-To-Go service, and thanks to the services you explored earlier, this application is able to get access to these drones. Click on Connect on either of the drones to open its drone viewer modal.

The drone viewer modal may take a few seconds to fully load all of its components. When it’s finished, take a look below at the various parts it has and the descriptions for each. You will focus on the Location section next.

In the Location section, turn on the Sensors in the map layers. You’ll notice that there a few sensors that are near the drone itself – click on one of them to view its information. If you recall earlier in the lab, you enabled access to these drones in the IEL Drones-To-Go private cloud service with Satellite Link and all of the sensors could be filtered to show nearby ones using the flow you added in Step 3. The connections to these services can be observed as you look at this section.

This completes all the steps for Drone Lab 2 – (Satellite) – congratulations! 🎉
Feel free to take a look at the other drone’s viewer modal (DJI Tello or Mavic Mini).

At any point, if you want to explore the production flow, or if you ran into issues and want to see a working version, you go back to the Topology view of YourLabName-lab-sat in the govlab-satellite-cluster. You can access the production flow URL of the ui-prod-sat which is preconfigured with a production Satellite link and tested for accuracy. Click on the top right "Open URL" icon of the ui-prod-sat pod to launch the production version of the Remote Drone Console Application.

Finish Step 4

You explored both the production flow of the Remote Drone Console Application and your own configured lab flow of the Application that uses the Satellite endpoint link you had previously created.

In the next step, you will conclude this lab.