Intro to ioFog Logo
Internet of Things (IoT)

Introduction to ioFog

8 ​​min

ioFog is an edge computing platform for deploying and managing microservices. It is backed by several contributors, most notably the Eclipse Foundation.

In this blog post I want to show you how to set up an ioFog network with its basic components.

Edge Computing

Edge Computing is a pattern in network design that aims to bring computing capabilities closer to where they are needed – in an effort to reduce bandwidth requirements and latency. This design lends itself well to IoT use cases and has often been adopted for IoT networks. The IoT use case sees sensors and other devices connected to edge nodes that are physically close to them. Edge nodes can be powerful enough to run computations such as analytics on the collected data. The results of those calculations are then sent to the controller nodes, either located in the cloud or in an on-location data center.

If you want to learn more about the concept of edge computing, take a look at this blog article.

Getting started

For first trying out ioFog I recommend you start with a local installation which uses Docker to deploy its components. We start by installing iofogctl, the ioFog command line interface. As you can probably guess from the name, it is inspired by kubectl. If you are on a debian-based Linux, you can install it using these commands:

The instructions for other systems can be found here.

A quick iofog version should print out a version number, confirming a successful installation.

Deploying the components

First up is the controller. It is the heart of an ioFog edge network. It handles agents, microservices and users. To deploy the controller, create a file named quickstart.yml and paste in the following content:

Pick your own names, e-mail address (does not have to be a real one) and password. As you can see, the file structure is also very similar to Kubernetes. The other thing to note here is that we are defining two components at once: the controller and an agent named „local-agent“.

Abbildung zu ioFoq Architecture


The agents are the worker nodes of the ioFog edge network. They are responsible for managing the Docker containers and images. Agents are commonly deployed to the very edge of the network, communicating with sensors and providing the means to process your data.

Start the deployment using iofogctl deploy -f quickstart.yml. Give it a few seconds to deploy, then check the output of iofogctl get all. It should look similar to this:

Since we are running a local deployment, both the controller and agent are running locally in Docker containers. If you are curious, take a look at your running containers. docker ps will show three containers related to ioFog.

Additionally to the controller and agent, there is also a container for the router. The router is created automatically and its purpose is to enable microservices to communicate with each other. It also provides proxy services, which are needed to route requests coming from outside of the edge network.

With these steps completed, we have a functional edge computing network.

Deploying microservices

On to deploying our first microservice. The ioFog documentation provides a simple microservice example that generates mock heart rate monitoring data. We will use this template in our deployment. Create a file called quickstart-app.yml and paste in the following:

As you can see, there are two microservices being created. One that generates the mock data and another that displays it. We also create a route to connect these two microservices together. Deploy the microservices using iofogctl deploy -f quickstart-apps.yml. You can check for the status using iofogctl get microservices. After the images have been pulled, the services should become available:

You can now view the heart rate monitor web service at http://localhost:5000. You should see a graph displaying the data that is sent by the heart rate monitor microservice via our route.

Communication between the viewer and monitor microservice is done via the ioFog SDK. You can use the SDK when writing your own microservices. It is available for multiple languages, including C#, C, C++, Go, Java, JavaScript and Python. Microservices do not have to use the SDK but it simplifies communication between ioFog nodes.

Taking it to the cloud

Up until now, our deployment has been local only. If we think in terms of real world scenarios, our agents would be as close to the sensors as possible. That way, latency would be minimized and the aggregated data could be sent off to the controller which is usually hosted in the cloud or a remote data center. Putting the heart rate monitor web service onto a different host (or the cloud) would also make sense. We would then be able to call our heart rate dashboard from anywhere.

Before we continue, it is best to clean up our local deployment using iofogctl delete all. If you do not clean up, you might get errors in iofogctl after deploying the remote controller. Right now, using remote resources together with local resources does not seem to work. It is also not intended to be used like that since the local deployment is more of a demonstration of ioFog.

iofogctl uses SSH to connect to remote hosts. Copy your SSH key to each host you want to connect to. Your user also needs to have root privileges, as some commands that iofogctl issues need it. In order for that to work properly, you also need to have a password-less sudo setup.

Another thing to look out for is that the controller uses the ports 51121 and 80. Take note if you are already running a webserver on this machine.

Again, we will start with the controller: create a file remotecontroller.yml with the following contents:

Fill in the placeholders with your details. Pay special attention to the SSH section. The user and key that you give here has to have access to your remote host. Deploy the changes using iofogctl deploy -f remotecontroller.yml.

Now we need a new agent. We cannot use our existing one, because that one was a LocalAgent. Create a file remoteagent.yml to create a remote agent.

Note that you cannot deploy the agent on the same host that you deployed the controller on. Agents always have to run on their own host.

Now we can deploy the heart rate microservices. We can use the old quickstart-app.yml file with one modification: Replace the agent with your agent name (in our example “agent-1“).

Deploy the microservices as usual with iofogctl deploy.

The microservices are now running on our remote agent and you should be able to access the heart rate viewer on port 5000 on the remote agent.

If you were wondering why the controller needs port 80, try browsing to that address. Use the credentials defined in remotecontroller.yml to log in. You should see the ioFog dashboard giving you a nice overview of your resources.

Where to go from here?

This concludes the basic setup of an ioFog network. If you want to take the next step, consider looking into creating your own microservices. If you need some inspiration, take a look at the example microservices in the ioFog GitHub repository.

Hat dir der Beitrag gefallen?

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert