Intro to ioFog Logo

Introduction to ioFog

Lesezeit
15 ​​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:

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:

---
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:

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.

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:

---
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:

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:

---
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.

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.

---
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”).

---
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.

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.

Hat dir der Beitrag gefallen?

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

Ähnliche Artikel