Implementing an Intelligent Edge Network using ioFog
In this post, we want to implement a practical edge solution using ioFog platform. To do so, we are going to simulate an intelligent edge network that is in charge of collecting the power usage history of its neighbor urban devices (e.g. cameras) and detect frequent electrical surges that may damage the device in long term.
In this Network we have 3 roles:
Edge Device— Reporting its power usage.Frequent Electrical Surge Detector— Collecting and analyzing power usage reports.Dashboard— visualizing the detector Analysis.
How ioFog Works
ioFog is a microservice friendly platform, which runs your code in an isolated manner on the edge devices. It enables internal communication between edge nodes using predefined routes. A quick note here that might help the reader to better understand ioFog:
ioFog is a tool similar to kubernetes, in many ways. Soon you’ll see why.
With this background information, we are now ready to start our project!
To set up our environment, make sure you have Docker installed (installation guide). Then, take a look at Quick Start Guide of ioFog and only execute the `Deploy ioFog Locally` section commands. When it’s done, execute docker ps in your CLI and you should see ioFog platform running containers.
Implementing Edge Device
Now that we have our environment ready, let’s create our edge-device
app which is shown in the diagram above, by a blue box. We are going to build this application with Node.js. Make sure you have Node.js and npm installed.
Now, execute npm init command in a directory of your choice. When you are asked for project properties, you can name this project edge-device. This will create the Node.js standard project structure. As we want to create an app in ioFog platform based Network, we need to install ioFog Node.js SDK using the following command.
npm i @iofog/nodejs-sdk
After having all the dependencies in place, we need to create an index.js file for this project.
The ioFog Platform supports docker, so to finish implementing our logic and deploy it in ioFog platform, we should define the container structure descriptor which encapsulates our code:
The following command creates the container docker build --no-cache -t natix-io/edge-device:v1 -f ./edge-device/Dockerfile
Just like Kubernetes, in order to deploy our code in ioFog platform, we should create an ioFog App Descriptor file to tell the ioFog platform how to deploy our app.
To examine what we did so far, let’s create a config.yaml file inside the folder.
The final folder structure looks like this:
Note that we have defined two microservices using the same image we have just created, passing different parameters on their config section. We also explicitly connected these two using routes the key which is in the same level of microservices as a child of spec.
Now, if you run iofogctl deploy application -f edge-device/config.yaml, the two edge devices will be running. You will see something similar to the following picture if you run iofogctl get microservices
Then get the Cam2 docker id using docker ps and trace its log using docker logs -f [Cam2 docker id]. You will see messages showing up as the log.
Implementing Frequent Electrical Surge Detector
This application’s role is to analyze and detect surges (anomalies) in power consumption behavior. Notice, in real-world scenarios, it is more practical to broadcast the detected surges as an alarm to the teams in charge by publishing it using an app like Slack. For this demo, we publish its data via an API.
To develop the app, let’s create a folder named usage-anomaly-detector and implement content below, inside a index.py file.
Next, we create a container using the following docker file and command. As a reminder, we need this to encapsulate and prepare our app for ioFog platform.
docker build — no-cache -t natix-io/usage-anomaly-detector:v1 -f ./usage-anomaly-detector/Dockerfile .
Notice the port 5000 is exposed in order to facilitate API access.
Continue by creating a config.yaml file, just like we did before, to test the app. The final structure should be as follows:
Implementing Dashboard
Similar to what we have done before, we initiate the project with these commands:
npm init
npm i @vue/cli
vue create usage-anomaly-dashboardIf you are interested to know more about its structure and how it works, you can visit Vue.js website.
vue create command will create the following structure:
Now we modify the main.js content using the following code:
Change the content of App.vue using the provided code, as well.
To create a component that lists the devices, we need a Vue file ./components/EdgeDeviceSelectDropDown.vue with the following content:
The following Dockerfile and command create a container for this Dashboard
docker build — no-cache -t natix-io/usage-anomaly-dashboard:v1 -f ./usage-anomaly-dashboard/Dockerfile .
Now we need to create .env file in the parent folder ( ../usage-anomaly-dashboard) and add VUE_APP_ANOMALY_REPORT_API=http://[your host ip]:5000/api/raw.
In addition, create a config.yaml file in the parent folder ( ../usage-anomaly-dashboard) and add the following content to it. It does not matter where you place it. Just remember the location in order to pass it to iofogctl command.
Finally, run iofogctl delete -f config.yaml then iofogctl deploy application -f config.yaml and after a few minutes, you can see anomaly-detection API output at http://127.0.0.1:5000 and its dashboard at http://127.0.0.1:7778
You can skip all of the above steps and get a quick look by just checking out the project on GitHub.
To execute the project, you need to simply create .env file in the root folder and add VUE_APP_ANOMALY_REPORT_API=http://[your host ip]:5000/api/raw and then clone the project:
git clone https://github.com/NATIX-io/iofog-urban-ai-example.git
As the last step, execute ./setup.sh and everything will be up and running shortly after.
Conclusion
ioFog is a developer-friendly platform, especially if you have experience working with Docker and Kubernetes technologies. The routes concept is a great facilitator. It handles security concerns by letting developers limit the visibility of the app at runtime via routes. This leads to fewer security concerns as long as you stick with the routes and have no urge to expose some custom ports which makes it a suitable platform to implement urban edge solutions.
DISCLAIMER: This post just reflects the author’s personal opinion, not any other organization. This is not official advice. The author is not responsible for any decisions that readers choose to make.
