Skip to main content

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

potctl get microservices

MICROSERVICE	STATUS		AGENT		CONFIG		ROUTES		VOLUMES		PORTS
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 an AQMP Dispatch Router 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:

Routes​

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 potctl get routes or potctl describe route <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.

potctl get routes

NAMESPACE
default

ROUTE           SOURCE MSVC   DEST MSVC
sensor-to-rest  Sensors       Rest API

potctl describe route sensor-to-rest

apiVersion: datasance.com/v3
kind: Route
metadata:
  name: sensor-to-rest
  namespace: default
spec:
  name: sensor-to-rest
  from: Sensors
  to: Rest API

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

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