Manage Our Microservices

In this step of the tutorial we're ready to learn the basics of managing microservices inside our Tutorial project.

Basic Controller CLI Interactions

The Agent daemon runs microservices on our edge nodes locally, but it is controlled remotely by the Controller. Let's learn some of the most common Controller commands.

This tutorial includes 3 microservices already running. We can view any configured microservices using iofogctl:

iofogctl get microservices

Sensors		    RUNNING		local-agent	{}		    Rest API
Rest API	    RUNNING		local-agent	{}						            10101:80
Freeboard	    RUNNING		local-agent	{}						            10102:80

This returns a list of microservices along with their status, the agent it is running on, configuration, routes, volume mapping and port mapping.

The tutorial consists of 3 microservices deployed on top of ioFog stack.

The Sensors microservice pretends to be reading data from a local hardware sensor. The data it produces is published with the SDK and routed through the Connector to the REST API microservice, so that it can be read by other microservices that only understand REST API.

Sensors microservice source code on Github

The REST API is a generic microservice that provides a REST API web server, allowing access to any arbitrary data source connected using the Controller.

REST API microservice source code on Github

Freeboard is the last microservice that provides an HTML dashboard to view the real-time results coming from a rest API data source. In the case of our tutorial, the source of the data is our REST API microservice.

Currently, loading the freeboard dashboard should look similar to this:


The Sensors and REST API microservices are generic. They are not hardcoded to talk with each other, instead, the relationship dictating the flow of data was configured through the Controller. This is in the spirit of the microservice architecture, separating concerns into pieces so that we can combine and interchange them.

To connect microservices together, the Controller has the concept of routes.

Routes can be listed from the iofogctl get microservices or iofogctl describe microservice <name> commands. We can see that a route has already been set up for us: the Sensors microservice has its destination (output) directed to the REST API microservice.

$ iofogctl describe microservice Sensors

kind: Microservice
  name: Sensors
  namespace: default
  uuid: cHttwNHmDnj2rYcX6qypgcr9JDpV2CNR
  name: Sensors
    name: local-agent
      dockerUrl: unix:///var/run/docker.sock
      diskLimit: 50
      diskDirectory: /var/lib/iofog-agent/
      memoryLimit: 1024
      cpuLimit: 80
      logLimit: 10
      logDirectory: /var/log/iofog-agent/
      logFileCount: 10
      statusFrequency: 30
      changeFrequency: 60
      deviceScanFrequency: 60
      bluetoothEnabled: false
      watchdogEnabled: false
      abstractedHardwareEnabled: false
    catalogId: 0
    x86: iofog/sensors:latest
    arm: ""
    registry: remote
  config: {}
  rootHostAccess: false
  ports: []
  volumes: []
  env: []
  - Rest API
  application: tutorial

We'll discover later on how to create and remove routes using iofogctl.

Create Our First Microservice

Next up, we're going to create our very first microservice to run on ioFog.

Continue To Next Step: Create Our First Microservice