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:
|
1 2 |
curl https://packagecloud.io/install/repositories/iofog/iofogctl/script.deb.sh | sudo bash sudo apt-get install iofogctl=2.0.2 |
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:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
--- apiVersion: iofog.org/v2 kind: LocalControlPlane metadata: name: ecn spec: iofogUser: name: <name> surname: <surname> email: <email> password: <password> controller: container: image: iofog/controller:2.0.1 --- apiVersion: iofog.org/v2 kind: LocalAgent metadata: name: local-agent spec: container: image: iofog/agent:2.0.2 |
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“.
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:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
NAMESPACE default CONTROLLER STATUS AGE UPTIME VERSION ADDR PORT local online 17m46s 17m49s 2.0.1 0.0.0.0 51121 AGENT STATUS AGE UPTIME VERSION ADDR local-agent RUNNING 17m45s 14m13s 2.0.2 localhost APPLICATION RUNNING MICROSERVICES MICROSERVICE STATUS AGENT VOLUMES PORTS VOLUME SOURCE DESTINATION PERMISSIONS AGENTS ROUTE SOURCE MSVC DEST MSVC |
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.
|
1 2 3 4 |
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES ea574d03ed20 iofog/router:latest "/qpid-dispatch/rout…" 12 minutes ago Up 12 minutes 0.0.0.0:5672->5672/tcp, 0.0.0.0:56721-56722->56721-56722/tcp iofog_Tj4gzmwMNzpCJFLNjDNdYJhg8jzh7L7C 3c5d0d5b848b iofog/agent:2.0.2 "sh /start.sh" 14 minutes ago Up 14 minutes iofog-agent e2e8689a48cb iofog/controller:2.0.1 "node /usr/local/lib…" 18 minutes ago Up 18 minutes 0.0.0.0:51121->51121/tcp, 0.0.0.0:8008->80/tcp iofog-controller |
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:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 |
--- apiVersion: iofog.org/v2 kind: Application metadata: name: health-care-wearable spec: microservices: - name: heart-rate-monitor agent: name: local-agent config: bluetoothEnabled: false abstractedHardwareEnabled: false images: arm: edgeworx/healthcare-heart-rate:arm-v1 x86: edgeworx/healthcare-heart-rate:x86-v1 registry: remote container: rootHostAccess: false ports: [] config: test_mode: true data_label: Anonymous_Person - name: heart-rate-viewer agent: name: local-agent images: arm: edgeworx/healthcare-heart-rate-ui:arm x86: edgeworx/healthcare-heart-rate-ui:x86 registry: remote container: rootHostAccess: false ports: - external: 5000 internal: 80 public: 5000 env: - key: BASE_URL value: http://localhost:8080/data routes: - name: monitor-to-viewer from: heart-rate-monitor to: heart-rate-viewer |
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:
|
1 2 3 4 5 6 |
NAMESPACE default MICROSERVICE STATUS AGENT VOLUMES PORTS heart-rate-monitor RUNNING local-agent heart-rate-viewer RUNNING local-agent 5000:80 |
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:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
--- apiVersion: iofog.org/v2 kind: ControlPlane metadata: name: remotecontroller spec: iofogUser: name: <name> surname: <surname> email: <email> password: <password> controllers: - name: controller-1 host: <ip address> ssh: user: <username> keyFile: ~/.ssh/id_rsa |
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.
|
1 2 3 4 5 |
NAMESPACE default CONTROLLER STATUS AGE UPTIME VERSION ADDR PORT controller-1 online - 24m4s 2.0.1 192.168.122.107 51121 |
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.
|
1 2 3 4 5 6 7 8 9 10 |
--- apiVersion: iofog.org/v2 kind: Agent metadata: name: agent-1 spec: host: <ip address> ssh: user: <username> keyFile: ~/.ssh/id_rsa |
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“).
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 |
--- apiVersion: iofog.org/v2 kind: Application metadata: name: health-care-wearable spec: microservices: - name: heart-rate-monitor agent: name: agent-1 config: bluetoothEnabled: false abstractedHardwareEnabled: false images: arm: edgeworx/healthcare-heart-rate:arm-v1 x86: edgeworx/healthcare-heart-rate:x86-v1 registry: remote container: rootHostAccess: false ports: [] config: test_mode: true data_label: Anonymous_Person - name: heart-rate-viewer agent: name: agent-1 images: arm: edgeworx/healthcare-heart-rate-ui:arm x86: edgeworx/healthcare-heart-rate-ui:x86 registry: remote container: rootHostAccess: false ports: - external: 5000 internal: 80 public: 5000 env: - key: BASE_URL value: http://localhost:8080/data routes: - name: monitor-to-viewer from: heart-rate-monitor to: heart-rate-viewer |
Deploy the microservices as usual with iofogctl deploy.
|
1 2 3 4 5 6 |
NAMESPACE default MICROSERVICE STATUS AGENT VOLUMES PORTS heart-rate-monitor RUNNING agent-1 heart-rate-viewer RUNNING agent-1 5000:80 |
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.
