The instructions here will guide you through the lab step by step.

Step 1: Using GitHub to Access/Modify an Application

In this section, you will navigate to GitHub Enterprise and access the code for your application. IBM has GitHub Enterprise which provides the social coding experience that developers love. In most development environments, there’s a lot of collaboration involved regarding code and changes to code. Enabling a team of developers to manage these changes and subsequent versions requires some form of source control, or git.
In this lab, you will gain some insight on the process, and even make small code changes that will render your application unique.

Reference:

Technologies Used

Your Tasks for Step 1

✅ Access GitHub Enterprise
✅ Review the drone application repository
✅ Make a configuration change
✅ Commit change to the master branch

1.1 Access GitHub Enterprise

The use of GitHub in this project is important because it allows developers to track code changes and version deployments across the entire project. From specific features to full production releases, GitHub can be used for change and management control.

Like logging into IBM Verse and IBM Cloud, you should be able to log into GitHub with your w3id. GitHub Enterprise is where the repository of application’s code resides. To learn more about how IBM uses GitHub Enterprise, visit https://www.ibm.com/garage/method/practices/culture/tool_github.

In your browser window, switch to the GitHub tab. (Repo for the IEL 2020 Lab 1)

1.2 Review the drone application repository

Let’s review the code repository’s structure. Every application has source code which is stored in a repository. A repository contains a set of files, as well as the history of changes made to those files.

Repositories can contain folders and files, images, videos, spreadsheets, and data sets – anything your project needs. At the top level, you notice public and src folders, followed by a set of files. These files typically contain a README.md and can also include licensing info, contributors, deployment configuration, etc. You may even notice that the README.md is open for viewing below the files/folders, where you can learn some facts about this application.

The public folder often contains the HTML file so you can tweak it, for example, to set the page title. You can also add other assets to the public folder, as is the case for this lab repository, where there are some configuration files that allow customization of certain aspects of the user interface. Visit https://github.com/kmindi/special-files-in-repository-root/blob/master/README.md for more information on typical files you’d find in any repository and https://create-react-app.dev/docs/folder-structure/ to learn more about the use of the public and src folder in React development.

Find the public folder (see image below). Within this directory, you will be able to see config.json, a JSON file where certain UI elements can be changed. This data structure was designed to be easily edited and will dynamically change the UI. You will edit the code and deploy that code change soon.

Once in the public folder, you should see config.json file.

GitHub allows users to see code directly in the webpage and even interact with it. You can create, edit, move, and delete files on a GitHub repository from the webpage. GitHub has support for navigation of code for many programming languages like Python, Java, JavaScript, and more. Visit https://help.github.com/en/github/managing-files-in-a-repository/managing-files-on-github to learn about all the capabilities of GitHub and what you can do with your code.

1.3 Make a configuration change

Many developers do not edit code on GitHub directly. Instead, they use a range of different Integrated Development Environments (IDEs) and code editors like Visual Studio Code, XCode, Eclipse, etc. Then, developers use tools like GitHub Desktop, SourceTree or git commands on a command line to push code changes and commits to the remote code repository. However, for this lab, you will edit directly within the GitHub web interface to avoid installing these programs.

Let’s edit the code in the config.json file, your application’s configuration file, which adds customization to your application’s user interface.

In some later example screenshots, you might see that the word "Walkthrough" was added in front of “Remote Operations Console”. Any name or phrase (like the name of your pet, your name, etc.) are options for ConsoleDisplayName. 🙂 For reference, you will later see this phrase at the top of your Remote Drone Dashboard application.

Be careful! Any value you change for a field should contain only alphanumeric characters and/or spaces. Keep your values to under 16 characters total, but at least one character.

You may notice that there are other fields/values also shown in the config.json editor. These fields represent the physical drones that may be available for a given user to operate in their remote drone application console. In the default code, you notice that there are three drones available.

You may edit the values for the fields “friendly_name” and “drone_serial_no” as well (the bolded values below), and the changes will later be reflected in the application.

"friendly_name": "Lab User Drone",
"drone_serial_no": "A12345"

"friendly_name": "Damage Inspection Drone",
"drone_serial_no": "A123456"

"friendly_name": "Surveillance Drone",
"drone_serial_no": "A123457”

NOTE: It is not necessary to change these fields for the lab - but you can if you’d like to.

1.4 Commit change to the master branch

Currently, you are editing directly on the master branch. The master branch is the default branch that your repository starts out with. As you continuously edit your code on your branch, those changes are reflected as commits. Commits include a summary message of what was changed, along with the files that were changed as a result of edited code.

A situation could occur when you want to create different versions of your application - for example, when adding a new feature to the current code, you do not want to interfere with the version that others may be working on. Creating these versions are called branches – you could create a new_feature branch that is based on the master branch. Once satisfied with code changes in the new branch, the new_feature branch could then be merged into the master branch for all collaborators to use as their working copy. Visit https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell for more information on git branch structure and architecture.

You will be committing your change you just made to the master branch.

1.4.2

Once you commit your changes, the page will refresh. In order to be prepared for the coming steps, make sure your GitHub tab is at the root level.

Click on YourLabName-2020-lab near the top, where it says on YourLabName-2020-lab / public / config.json.

You have now completed Step 1 by viewing the root level of your repository with your latest commit. It is ready for the remaining steps of the lab.

Finish Step 1

You successfully made a unique change to your application using relevant development skills and utilizing GitHub.

In the next steps, you will move onto deploying your remote drone dashboard application with RedHat OpenShift through IBM Cloud. In Step 2, you’ll learn about these services, access your project in a cluster, and explore the OpenShift web console.

Step 2: Accessing RedHat OpenShift through IBM Cloud

As mentioned before, prior to when you began this lab, you were given user permissions to the existing IBM Cloud organization for the SBaaS (Sandbox as a Service) environment that was provisioned for this lab. A new project was created specifically for you in the OpenShift cluster within that organization, with all the necessary user policies.

In this section, you will navigate from the IBM Cloud dashboard within that organization to the provisioned IBM Sandbox as a Service workspace. Then, you will access a cluster and open the RedHat OpenShift web console. In addition to exploring the RedHat OpenShift interface on IBM Cloud, you’ll also get an overview of the capabilities that OpenShift provides.

Before you move on, you may want a refresher on what exactly Red Hat® OpenShift® is. Red Hat® OpenShift® on IBM Cloud™ is a managed offering to create your own OpenShift cluster of hosts to deploy and manage containerized apps on IBM Cloud. OpenShift is essentially a layer that's built on top of Kubernetes, and makes working with it much easier: by taking a lot of the difficult tasks (like deploying applications and doing things like day-to-day operations) and building a web console in the CLI, as well as a facade on top of Kubernetes to make all of those tasks more streamlined and easier to do.

Let’s take a moment to review some concepts you will be delving into in the next few steps. Consider the remote drone dashboard application you helped develop by editing in the previous step. You do your work on your laptop and if your dashboard had real life usage and contained a suite of various real-time systems and technologies, your environment might have a specific configuration. Other developers may have slightly different configurations. The application you’re developing relies on that configuration and is dependent on specific libraries, dependencies, and files. Meanwhile, your team has development and production environments which are standardized with their own configurations and their own sets of supporting files. You want to emulate those environments as much as possible locally, but without all of the overhead of recreating the server environments. So, how do you make your app work across these environments, pass quality assurance, and get your app deployed without massive headaches, rewriting, and break-fixing? The answer: containers.

The container that holds your application has the necessary libraries, dependencies, and files so that you can move it through production without all of the nasty side effects. Containers provide a standard way to package your application's code, configurations, and dependencies into a single unit that can run as a resource-isolated process on a server. To run your app in Kubernetes on Red Hat OpenShift on IBM Cloud, you must first containerize your app by creating a container image that you store in a container registry. Container image distribution is agile, small, and portable, and is a lot easier than installing new copies of operating systems – which is an ideal outcome for all.

In the coming steps, you will take your containerized remote drone dashboard application and run it on RedHat OpenShift, which is a Kubernetes deployment that manages container images. It can be easy to confuse the two, but RedHat OpenShift and Kubernetes are different – to put it simply, Kubernetes is the "kernel" of distributed systems, while OpenShift is the “distribution”.

Now that you have been refreshed on what OpenShift and its related components are, there’s an important distinction between the process outlined in this lab, versus other common processes of deployment on OpenShift, which will be outlined in the next steps. For now, let’s start out by exploring the IBM Cloud dashboard and OpenShift interface.

Technologies Used

Your Tasks for Step 2

✅ Access IBM Cloud
✅ Access RedHat OpenShift cluster
✅ Open RedHat OpenShift web console
✅ Explore OpenShift web console

2.1 Access IBM Cloud

You’ll need to access RedHat OpenShift through the IBM Cloud in order to build and deploy your application.

If you did not do so in the Preliminary steps, you can also log in with your w3id to ( New Tab ⇒ https://cloud.ibm.com) (Single Sign-On Required with w3id)

Once you’ve logged in, 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 apart 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 – IBM account.

2.2 Access RedHat OpenShift cluster

Once you click on 1500867 - IBM, your dashboard will update with Resources that are specific to it. You should see a Resource summary card that currently contains a Resource: Clusters (1).

Click the resource called Clusters.

In Kubernetes, a cluster consists of one or more hosts that are called worker nodes. Worker nodes are managed by a master that centrally controls and monitors all Kubernetes resources in the cluster. So when you deploy the resources for a containerized app, the Kubernetes master decides which worker node to deploy those resources on, accounting for the deployment requirements and available capacity in the cluster. Kubernetes resources include services, deployments, and pods.

You should see now see a Resource list that may contain multiple Cluster resources, but for this lab, you will only need the cluster resource, mycluster-dal12-b3c.4x16. Additionally, in other workspaces or your personal workspace, you may have dozens of other applications, services, storage, developer tools, etc. These resources are all hosted on IBM Cloud. Information such as the offering, location, status can be seen for each resource.

2.3 Open RedHat OpenShift web console

Let’s examine this cluster’s (mycluster-dal12-b3c.4x16’s) overview of the resource.

On the left side is the additional settings menu. In the middle is the the summary card for the cluster. On the right side, you’ll see worker nodes/cluster insights. It includes diagnostics and status information about the cluster. All of this provides a summary of the OpenShift instance before you jump in and work directly inside of it.

Click on the OpenShift web console button in the top right to access the console.

It may take several seconds for this new tab to load completely. The reason for this is that you have moved into a RedHat OpenShift instance. Here you can see which projects and applications are deployed on your cluster.

Before we get too far, let’s make make sure you are in the Developer Perspective for the Project space allocated for this lab:

1) Set your perspective in the left menu by clicking the dropdown and selecting </> Developer (instead of Administrator).

2) Click the dropdown where it says Project (at the top) and make sure "YourLabName-2020-lab-1" is selected.

3) Click Topology on the left menu.

⚠️ My page looks different! / I see an error on the page below! [Click to Troubleshoot]

If you see "Restricted Access: You don’t have access to this section due to cluster policy" along with the error details, "deploymentconfigs.apps.openshift.io is forbidden: User “IAM#...” cannot list resource “deploymentconfigs” in API group “apps.openshift.io" in the namespace “default”, make sure to select the developer perspective and that you are in the correct project. Your project should be "YourLabName-2020-lab-1".

If you do NOT see a page similar to the one below, send an email to gscgov@us.ibm.com with the message, "My Topology view in OpenShift doesn't match the screenshot in Step 2.3.1."

💡 What is the node that is already there in my OpenShift instance? [Click to Read More]

As part of the lab setup for each users, an instance of the default, unchanged remote drone console application was deployed in your OpenShift project to be used as a reference. If you remember in Step 1, you edited config.json, which changed the remote drone console application’s title at the top. In Step 3, you will deploy your own instance based on the unique changes you made in Step 1.

2.4 Explore OpenShift web console

Confirm that you’re in the developer perspective on the top left. You have two perspectives available: developer, and administrator (which is usually the default perspective).

The current view in the OpenShift web console is the Topology view in the Developer perspective. It provides a visual representation of all the applications within a project, their build status, and the components and services associated with them. Review the annotated screenshot below which summarizes the key parts of this view.

You’ll be able to dive into this web console’s functions and take action in the next step. Until then, become familiar with this view. Optionally, you can click the arrow button on the top right of the already deployed instance to see the original dashboard (which does not have your code changes).

Finish Step 2

You successfully accessed and reviewed the OpenShift web console view by logging into IBM Cloud and selecting the available cluster resource.

In the next step, you will finally begin the setup for adding your custom remote drone dashboard application to OpenShift. By linking OpenShift to your GitHub repository, you’ll be able to create and build your application.

Step 3: Creating Application in OpenShift from GitHub

In the last step, you accessed and reviewed the OpenShift web console through the IBM Cloud dashboard. You noticed there was already an instance running there – a default remote drone dashboard application. Remember that in Step 1, you made configuration changes for your own unique remote drone dashboard application. It’s now time to set up deployment of this repository.

Hinted at towards the end of Step 2’s introduction, there’s an important distinction between the process outlined in this lab, versus other common processes of deployment on OpenShift. For this lab, the approach you will take will involve pulling GitHub repository code to build a container image from a Dockerfile. However, this is merely one approach to create an application on OpenShift. In fact, there are multiple ways of creating an application which are not covered in this lab write-up as thoroughly but are useful to learn about.

Options for creating a new application in OpenShift
Click here to read a summary of the several ways of creating a new application in OpenShift (Open a New Window)

Technologies Used

Your Tasks for Step 3

✅ Add an application to OpenShift
✅ Link OpenShift to GitHub repository
✅ Generate token and create application

3.1 Add an application to OpenShift

	As detailed in the Options for creating a new application in OpenShift pop-up section above, you have several options to add an application to OpenShift. In this lab, we are covering how to add an application from Dockerfile. From the OpenShift web console left navigational menu (with Developer perspective selected), click on the + Add option.
3.1.2
A Dockerfile is an instruction document in a GitHub repository. These instructions contain the commands that are needed to assemble a Docker image. Once executed, the Dockerfile utilizes the files in the PATH or URL parameter to start building the image. In this lab, the Dockerfile will be used to build the image on OpenShift. Visit https://nodejs.org/fr/docs/guides/nodejs-docker-webapp/#creating-a-Dockerfile to learn how to make your own Dockerfile for an application.
	Click on From Dockerfile. You will then be redirected to the Import from Dockerfile page form with several fields and values to fill out.

3.2 Link OpenShift to GitHub repository

The following steps will require copying and pasting.

The first field in the Import from Dockerfile form asks for the Git Repo URL*. In Step 1, you made changes to your GitHub repository. Find the link to this URL by going back to your GitHub tab.

You have provided a git URL, which tells OpenShift that the Dockerfile it requires resides in that specific GitHub repository. In the next steps, you will continue to provide OpenShift with the access and permissions necessary to interact with that Dockerfile.

3.2.3
An option to choose the Git Type* should appear. Since you are using GitHub Enterprise, you’ll choose that option for it.
When prompted, change the Git Type* selection to be GitHub.

3.3 Generate token and create application

You may be wondering how OpenShift is able to access the Dockerfile in your GitHub repository, when even you, the owner of that GitHub repository, have to login into GitHub Enterprise with Single Sign-On authentication with you w3ID to see it. That’s where Source Secret comes in.

Source Secret contains credentials for pulling your source code. As the name suggests, it is NOT intended to be used publicly and is something only you can share with applications you fully trust. You will use GitHub’s Personal Access Token to grant access to your GitHub repository to OpenShift.

Click the Show Advanced Git Options to reload the field and display additional options. Under Source Secret, select Create New Secret. A pop-up should open when you click Create New Secret.
3.3.2
	The Create Source Secret pop-up contains fields that will be used to enter your authentication credentials. Your Username will be your IBM email, and your Password or Token will be a token, the Personal Access Token that we will retrieve shortly. In the screenshot to the left, the Secret Name for this lab was entered as "walkthrough". Provide a value to the Secret Name* field (example: walkthrough). Add your IBM email to the Username value. Notice that the next field is Password or Token, which will be explored in the following section. You cannot fill the Password/Token field just yet. But in the next step (3.3.3), you will generate a token that will be pasted into this field. So, don't close this tab just yet, and continue reading the next step.

The preferred mechanism for accessing a private Git repository is to use an SSH connection and a repository SSH key. However, you will use personal access tokens to allow OpenShift to access your private repository.

Personal access tokens are an alternative to the password you would use when accessing your account on the Git repository hosting service. You can think of personal access tokens as “house keys” to letting whoever has the key go into your house, or in this case your repository, and view it. You can designate your “house key” to have predefined privileges such as only letting the person who has that key enter your house - but do nothing when they’re inside of it. Or, the owner of the key can enter the house and do anything the owner of the house can.

Any number of access tokens can be created, and you can create separate tokens for each separate client you may want to use to access your account. By using a separate token per client you can control what level of access each has, including whether they have read-only access, or can update repositories. A token for a specific client can be revoked without affecting other clients. Although what actions a specific client can do can be controlled, it would still be able to see all repositories that you as a user has access to.

Go back to your GitHub repository and navigate to where you’ll be able to create a Personal Access Token.

Click on your GitHub Enterprise account picture in the top right. From the dropdown menu, click Settings. In Settings, click on Developer Settings in the left side menu.

Type in the name of your Personal access token. For this lab, use walkthrough-RH-OpenShift for the name. A descriptive name was used to detail what this token is being used for. This descriptive name will help you distinguish how this token was used in the future when you revisit the Personal Access Token page.

Next, you’ll select what the scope of access this personal access token will have. As mentioned above in the “house keys” analogy, these permissions have fine control access that are given through the token. Scopes for these tokens are powerful, so it’s important to confirm how you provision permissions for your GitHub repository. Visit https://developer.github.com/enterprise/2.19/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/ to learn more about scopes for OAuth Apps in GitHub.

You only need to provide repo scope access for OpenShift to read the Dockerfile and its contents.

Now with your new Personal Access Token, you can move back to the OpenShift Web Console tab to finish the Create Source Secret pop-up form. Switch back to the tab with your OpenShift web console. Paste the Personal Access Token into the Password or token space as shown below. Then click Create.

Once you've hit Create, finish the overall application from Dockerfile. For the remaining fields, default values should be appropriate as-is, which can be reviewed/validated in the screenshot (Resources: Deployment, Advanced Options: Create a route to the application). When you are finished confirming your selections, click Create.

When you click create, OpenShift is taking the Dockerfile from your GitHub repository and using its instructions to build the application image from the current repository code. A new topology instance will appear based on this process.

Finish Step 3

You successfully added an application to OpenShift from a Dockerfile which included configuration such as generating personal access tokens from GitHub.

In the next step, you will finally get to see the aftermath of the actions you took in this step by checking the status and getting to see your changes in the application from Step 1.

Step 4: Building and Verifying Application on OpenShift

In this section, you will explore what became of the application you added in the previous step and explore the post build process for your application.

A build is the process of transforming input parameters into a resulting object. In this case, the process is used to transform input parameters of source code into a runnable image. The OpenShift Container Platform build system provides extensible support for build strategies that are based on selectable types specified in the build API. There are three primary build strategies available:

1. Docker build
2. Source-to-Image (S2I) build
3. Custom build

In previous steps, we used the strategy involving a Docker build using a Dockerfile. The Docker build strategy invokes the docker build command and it expects a repository with a Dockerfile and all required artifacts in it to produce the runnable image.

You will soon monitor the build status and build finish, and finally access the instantiated application.

Technologies Used

Your Tasks for Step 4

✅ Explore topology
✅ Check build status
✅ Access deployed application

4.1 Explore topology

In this step, you will explore the Topology View as your application is building. After you clicked Create at the end of Step 3, the application should have kicked off into the building phase and redirected you to the Topology page as shown below.

The Topology view in the Developer perspective of the web console provides a visual representation of all the applications within a project, including their build status and the components and services associated with them. This is just a reference for now, since you'll explore these features later. After you create an application, you are directed automatically to the Topology view where (eventually) you can: See the status of the application pods Quickly access the application on a public URL (Note that this only works after the build is complete) Access the source code to modify it See the status of your last build Zoom in and out to see more details The application will be in the build stage for a few minutes. In the meantime, you will explore the build status.

Let's explore the build status and logs of the build. The new node, YourLabName-2020-lab1, which is most likely on the left, is what you will be interacting with.

You may notice "ErrImagePull" besides your pod at the top of the side menu. This error does NOT mean there's an error with your pod - in fact, you'll be able to read the logs of the build status to review the status of the build.

This side menu in the Topology view provides the details of the deployed components in the Overview panel. You can use the Overview and Resources tabs to scale the application pods, check build status, services, and routes as follows.

You can use the Overview tab to:

• Scale your Pods using the up and down arrows to increase or decrease the number of instances of the application manually.
• Check the Labels, Annotations, and Status of the application.
• For serverless applications, the Pods are automatically scaled down to zero when idle and scaled up depending on the channel traffic.

You can click the Resources tab to:

• See the list of all the Pods, view their status, access logs, and click on the Pod to see the Pod details.
• See the builds, their status, access logs, and start a new build if needed.
• See the services and routes used by the component.
• For serverless applications, the Resources tab provides information on the revision, routes, and the configurations used for that component.

4.2 Check build status

Now you will drill down into the log stream of your building application. These log files will show you information about the status of build phase of your application. Since the build has just started, the logs can show whether the GitHub authentication with the Personal Access Token was successful in linking the GitHub repository to OpenShift.

Log files are important because they keep track of events in your application from creation, modification, and deletion. Look for a prompt that refers to a successful authentication using your username and Personal Access Token.

In the side menu under Builds, take a look at View logs in order to view the status of the deployment as shown below.

You will be redirected to the Build details page where you should see a Log stream as shown below. This Log stream shows the build log in real time. For this lab, you are looking for Cloning, which is an indicator that your Personal Access Token was step up correctly in Step 3 and that your GitHub repository is successfully being cloned to the RedHat OpenShift instance.

If you do not see this log, scroll up or down in the log file to check carefully once more through the log stream (it may be at the top or bottom of the log). If you still do not see it, you may need to go back to Step 3 and set up your Personal Access Token correctly.

On a successful build, you should see a log similar to this at the end: Successfully pushed image-registry.openshift-image-registry.svc:5000/... Push successful".

Keep in mind, you may not see this final log message for an upwards of over 5 minutes. Please be patient.

4.3 Access deployed application

Now you can check the status of your built application and navigate to your finished application.

The deployment of your application is finished when the green checkmark appears on the deployment node as shown below.

In this Topology View, many visual indicators can show you more information about your deployment.

If in Step 1.3.1, you incorrectly customized your application with a newer set of values, the application may display errors such as "friendly name missing" or "drone serial number missing", along with a pop-up message that reads "There was some issue with the values in config.json..." as show below. You will need to correct the values in the config.json.

Go back to your GitHub tab and edit the code in the config.json file, your application’s configuration file which adds customization to your application’s user interface (like in in Step 1.3.1).

Once back in the GitHub tab, navigate back to your config.json and Click on the Edit button on the right side as shown.

For convenience, copy the highlighted block of code below and then replace the content in your config.json to avoid errors that may have been introduced when you initially edited the code:

public / config.json
{ "ConsoleDisplayName": "Remote Operations Console - Corrected Config", "UserDrones": [ { "friendly_name": "Lab User Drone1", "drone_serial_no": "Lab1_0001" }, { "friendly_name": "Lab User Drone2", "drone_serial_no": "Lab1_0002" }, { "friendly_name": "Lab User Drone3", "drone_serial_no": "Lab1_0003" } ], "DroneOperations": [ "Rescue Coordination", "Damage Inspection", "Safety Analysis", "Stormwater Operations Monitor", "Geothermal Monitor" ] }

Copy to clipboard

Make sure Commit the changes as described in Step 1.4. Then click the Commit changes button.

To have the changes made in Step 4.4 reflected in the application, you will need to redeploy the application. To do this, re-execute Step 4.1.2 and click the Start Build option.

Now you can check the status of your built application and navigate to your finished application. The deployment of your application is finished when the green checkmark appears on the deployment node as shown below.

You should see your own customized remote drone console application in a new tab in your browser as shown below.

Notice the URL of this new tab, which is an endpoint that can be shared with others.

If you see this page, you have successfully deployed your application!

Step 5: Exploring the Application

In this section, you will explore your new custom remote drone dashboard application, along with various industry uses cases to consider.

Technologies Used

Your Tasks for Step 5

✅ Explore user interface
✅ Consider industry use cases

5.1 Explore user interface

If you haven’t done so already, click on the Open URL button on the top right of your new containerized application deployed on Red Hat OpenShift running in IBM Cloud. Your remote drone console application may need a few seconds to load, but should reflect the application you just deployed. At the top, you should be able see that change in the title – ConsoleDisplayName was changed to the value you entered in the config.json during Step 1 of the lab instructions. Your title will have been unique to you.

5.2 Consider industry use cases

Drone technology has massive overlaps in key technology advancements in the recent years. Drones are major talking points in Internet of Things (IoT), edge computing, visual analytics and more. In addition to being pivotal instruments in these technologies, drones have a multitude of use cases.

This subset of a table published by the IDC's Worldwide Robotics and Drones Spending Guide Taxonomy, 2020 report describes Public Market Use Cases and many Additional Operations described in this lab.

Among possible uses for drones equipped with visual recognition and/or thermal imaging:

• Firefighters can attach thermal imaging cameras to a drone and immediately see where the hotspots are in a forest fire.
• Search and rescue teams can use them to look for people using object recognition or heat signatures
• Farmers can use them to determine the health of crops and make decisions affecting crop yield.
• Surveyors can create a 3D visualization of a construction site as the structure is being built.

These are just a handful of use cases that drone technology, edge computing and cognitive analysis are used for. These use cases are focused on the Public Market and can be expanded to many other industries.

Finish Step 5

You reviewed the remote drone dashboard application’s user interface you customized in Step 1 and had deployed in the steps afterward. While this step mentioned some industry use cases, there are certainly many more to consider with the technologies detailed in this lab.

Now that you have successfully completed all steps in the lab, move onto the final summary for closing thoughts.